Article View: comp.mail.headers
Article #199Return and read receipts (was Re: Return-Receipt-To & forwarding...)
From: John R MacMillan
Date: Mon, 28 Dec 1992 17:17
Date: Mon, 28 Dec 1992 17:17
99 lines
5562 bytes
5562 bytes
I apologize for the length, but this is something I feel fairly strongly about. Sprinkle liberally with IMHOs. My position on this is that receipts are only genuinely useful if they are guaranteed. Since we can't get this with the loose email net we have, it's not useful. With return-receipt-to, a lack of response means nothing (your message may or may not have been delivered), and a positive response means there's a good chance your message was delivered, but it's my no means foolproof. So if you really care, you'll ask the recipient for some response, and eventually resort to telephone. If you only would like some indication but it's not critical, ie. return-receipt-to would do, wouldn't a bounce also do? It's only slightly more likely if at all that you won't get a bounce if the mail isn't delivered but would get a return-receipt-to. With read receipts the same scenario applies. If you care, an automated response is not enough, and if you don't care, why bother? If you want to make it easier for recipients, add a feature to send a short acknowledgement message to selected or all mail items. |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. If you do this, please stress in the RFC that a lack of response doesn't indicate anything, and that a positive response may not mean what you think, ie. a return response means that some MTA somewhere thinks they've probably delivered the message to something, which may or may not have discarded, lost or resent it, and a read response means that something that thought it was a mail reader was somehow invoked and may or may not have presented the mail to someone who may or may have not been the recipient. User expectation is perhaps the biggest problem. As a side story, I used to work at a place where the admin staff used a "friendly" mailer that had read receipts. One user got very confused because she would get replies to her mail, and a day or so later get told by the friendly mailer that the recipient had not yet read the mail, even though she'd seen the reply. When the cause was explained, she couldn't see the point of the read receipt feature because she was expecting something more meaningful. |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. But not much, see above. |And, in the scope of a local |authority, it's quite possible to make the negative mean something, too. In a local authority, there's no need for a standard, and you would probably want something much tighter than a standard could be, so that negative responses definitely meant something. Again remember that even in a local authority trying to do this, lack of response does not necessarily indicate the original message was not delivered/read; the response could have been lost. |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. I don't really buy this last claim. If it's not at the honest to goodness last stop, it's not any more useful than if the sending MTA responded, saying, "well, it's on it's way". Perhaps it is better than nothing but not by any valuable amount. |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. Well, if they're automatically matched to the outgoing mail, the annoyance factor is low so that won't help, but I feel bandwidth isn't a big problem anyway. |Read receipts: | |[...] | |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. I don't think it's a matter of paranoid. Thinking I've read my mail may create some sort of expectation in the sender's mind. For example if you sent me a long piece of mail that I received just before I was to go on vacation, and I looked at it (generating a read receipt), decided I didn't have time to deal with it, and left. Now I never got to the part that says "If you can't do this by Tuesday, let me know so I can make alternate arrangements". You think I've read the message, but I don't follow up telling you I can't do it.
Technical Details
Message-ID:
<1992Dec28.171751.25819@chance.gts.org>Path:
arc1-ca.pugleaf.net!sparky!uunet!uunet.ca!wildcan!sq!chance!johnReferences:
<1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0>Show Full Headers
Complete Article Headers
Newsgroups: comp.mail.headers,comp.mail.misc Path: arc1-ca.pugleaf.net!sparky!uunet!uunet.ca!wildcan!sq!chance!john From: john@chance.gts.org (John R MacMillan) Subject: Return and read receipts (was Re: Return-Receipt-To & forwarding...) Message-ID: <1992Dec28.171751.25819@chance.gts.org> Summary: They're not strong enough to be useful Keywords: delivery receipts Organization: $HOME References: <1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> Date: Mon, 28 Dec 1992 17:17:51 GMT Lines: 99