Article View: comp.mail.headers
Article #196Re: Return-Receipt-To & forwarding...
From: Steve Dorner
Date: Sun, 27 Dec 1992 16:15
Date: Sun, 27 Dec 1992 16:15
72 lines
3847 bytes
3847 bytes
In article <19921225.001@erik.naggum.no>, erik@naggum.no (Erik Naggum) wrote: > No one has bothered to write > up a specification for it and submitted it as an RFC. I think it is high time that some form of standard return receipt were available in Internet mail. It's one of the few functional areas where the Internet lags behind practically ever proprietary mail system, and X.400 to boot. Suppose one were contemplating writing such an RFC (one is in fact contemplating exactly that :-)). What should it be? Bear in mind that it must be practical to implement and provide some useful amount of function. My initial leaning is to enshrine "Return-Receipt-To:" as a standard for successful delivery, since it has some utility and is also not going to go away anytime soon (rampant fantasies of sendmail haters aside :-)). But I would also suggest a "Read-Receipt-To:", to be generated by the MUA (and ONLY the MUA) when the message is actually read. Let me enumerate some of the objections I've heard to this type of feature, and rebut them: Delivery receipts: Objection 1. Since not every mail system implements it, it's meaningless. Failing to receive the receipt does not mean the message was not delivered. Rebuttal 1. While it is true that the negative is of questionable value, the positive does indeed mean something. And, in the scope of a local authority, it's quite possible to make the negative mean something, too. Objection 2. Where do you draw the line at what is "final" delivery? What about POP and POP-like systems? Rebuttal 2. Who cares? :-) You do at least know that the message was delivered to some maildrop. It's better than nothing. Objection 3. Bandwidth. Return receipts would eat the Internet alive. Rebuttal 3. The annoyance factor to the receipt-ee is high enough that I don't personally feel this is a problem. Read receipts: Objection 1. See above. Rebuttal 1. See above. Objection 2. See above, but replace '"final" delivery' with '"really" read'. Rebuttal 2. See above, but replace 'delivered to some maildrop' with 'examined by the user or some direct agent of the user'. Objection 3. See above. Rebuttal 3. See above. Objection 4. It's none of your business when or if I read my mail. Rebuttal 4. MUA's can provide you the option of suppressing read-receipts, if you're paranoid. This lessens the meaning of a negative, but again leaves the positive unsullied. Objection 5. A user-generated reply is the best return receipt. Rebuttal 5. True. But why not automate the process for the recipient's benefit? I would be perfectly happy if my MUA could acknowledge things for me, so I could then get around to them in my own good time without seeing repeated "Did you get my message?" queries. Objection 6. Various quibbles about exactly what the US Postal Service does or does not mean by or do with a return receipt, and various arguments about how they could or could not be implemented in the Internet. Rebuttal 6. Who cares? If we wanted to emulate the USPS exactly, we'd build a random mail misdirection system, and intentionally rude and stupid MTA's. (Comments about sendmail not invited :-).) -- Steve Dorner, Qualcomm, Inc.
Technical Details
Message-ID:
<sdorner-271292095054@0.0.0.0>Path:
arc1-ca.pugleaf.net!sparky!uunet!gossip.pyramid.com!olivea!charnel!rat!usc!cs.utexas.edu!swrinde!network.ucsd.edu!qualcom.qualcomm.com!NewsWatcher!userReferences:
<1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!gossip.pyramid.com!olivea!charnel!rat!usc!cs.utexas.edu!swrinde!network.ucsd.edu!qualcom.qualcomm.com!NewsWatcher!user From: sdorner@qualcomm.com (Steve Dorner) Newsgroups: comp.mail.headers Subject: Re: Return-Receipt-To & forwarding... Message-ID: <sdorner-271292095054@0.0.0.0> Date: 27 Dec 92 16:15:35 GMT References: <1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no> Sender: news@qualcomm.com Followup-To: comp.mail.headers,comp.mail.misc Organization: Qualcomm, Inc. Lines: 72 Nntp-Posting-Host: dorner.slip.uiuc.edu