From: dplatt@ntg.com (Dave Platt)
Subject: Re: return receipt
Organization: New Technologies Group, Inc.  Palo Alto CA
Date: Tue, 25 Aug 1992 17:56:19 GMT

>Actually, this counts as a strike against Return-Receipt-To: in my book.
>
>I would like a return receipt to mean "your message has been seen by
>the user", kind of like a certified US Mail letter.  If sendmail does the
>responding, all I really know is that the mail went "somewhere"; this
>information I could infer from the fact that I didn't get a bounce
>message.  It doesn't tell me anything about whether my mail is likely
>to be read or not.  All it tells me is that there wasn't a transport
>failure.

But... when you think about it... a U.S. Mail certified-mail return
receipt doesn't indicate that the message has been read, either.  All it
indicates is that the trusted mail-delivery agent (the Post Office) has
turned the message over to the responsibility of the user.  Admittedly,
the user must take an explicit action for this to occur... so you (the
sender) know that the recipient has taken legal custody of the message
and can be "presumed" to have read it... but it may not actually have
been read.

>For example, I currently have a small mound of mail sitting in a UNIX
>account, and I have no intention of ever looking at that mail, because
>nobody was supposed to send mail to me at that account.  Sendmail's
>return-receipt-to: processing is "way off" in this case, at least
>by my standard.
>
>It seems to me that it should be the MUA who sends the return message,
>when and if somebody actually looks at the mail.
>
>Comments?  Am I missing the point?

I've used (and helped implement) systems which use both methods, and I
appreciate the advantages of both.  In one system I implemented, the
receipt was sent by the MUA... but was sent automatically the first time
that the RR'ed message was read, and the recipient had no way to
interrupt the receipt-sending.  The mailbox files on that system were
secured via operating-system access controls... they could be read only
by the mail program, and not via any sort of text editor or file editor.
This prevented unscrupulous users from reading their mail via a text
editor, deleting it from their mailbox without reading it, and claiming
to have never received or read it.

The advantages to the sendmail approach are

[1] the receipt is sent by a portion of the "trusted" mail-delivery
    system, and occurs at the same time that the mail is delivered into
    the user's mailbox.  It's difficult for the recipient to subvert the
    receipt process (i.e. prevent the receipt from being returned to the
    sender).

[2] the receipt tells the sender that the message got through the
    transport system... indicating that the mail system has "done its
    job".  If the recipient later claims that the mail was never
    received, the sender can point to the fact that it _was_ delivered,
    and thus the loss is (in a technical and/or moral sense) the fault
    of the recipient.

The advantages to the MUA-receipt approach are

[1] it informs the sender that the message has actually been _read_ (by
    a human or by a script).

[2] it allows (potentially) the addition of extra information to the
    receipt... i.e. it can be treated as an "auto-reply".

but it has the disadvantages that

[a] it allows the recipient to "reject" mail in a covert way... by
    deleting it before it's read.  This leads to a situation which
    "looks like" transport failure, in that no receipt of any kind is
    returned to the sender.

[b] it allows the recipient to read the mail without sending a receipt,
    simply by using a MUA which doesn't implement the receipt feature or
    permits it to be overridden.

I haven't yet implemented either transport-level or MUA-level receipt
sending in uupc or Fernmail.  I'm tempted to do one or both.  What I
might do, is implement both - uupc would send back a "delivery receipt"
when the message is delivered locally, and Fernmail would pop up an
"auto-reply" window when the user read the message.
-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303