From: sdorner@qualcomm.com (Steve Dorner)
Newsgroups: comp.mail.headers
Subject: Re: Return-Receipt-To & forwarding...
Date: 27 Dec 92 16:15:35 GMT
Followup-To: comp.mail.headers,comp.mail.misc
Organization: Qualcomm, Inc.

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.
Xref: sparky comp.mail.headers:393 comp.mail.misc:4169