NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/mail/headers/378

Internet Message Format | 1992-12-29 | 5.4 KB

Xref: sparky comp.mail.headers:378 comp.mail.misc:4121
Newsgroups: comp.mail.headers,comp.mail.misc
Path: sparky!uunet!uunet.ca!wildcan!sq!chance!john
From: [e-mail] (John R MacMillan)
Subject: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Message-ID: <[e-mail]>
Summary: They're not strong enough to be useful
Keywords: delivery receipts
Organization: $HOME
References: <[e-mail]> <[e-mail]> <sdorner-271292095054@0.0.0.0>
Date: Mon, 28 Dec 1992 17:17:51 GMT
Lines: 99

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.