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

Internet Message Format | 1992-12-28 | 3.5 KB

Xref: sparky comp.mail.headers:377 comp.mail.misc:4118
Newsgroups: comp.mail.headers,comp.mail.misc
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!linac!att!mcdchg!chinet!les
From: [e-mail] (Leslie Mikesell)
Subject: Re: Return-Receipt-To & forwarding...
Message-ID: <[e-mail]>
Organization: Chinet - Public Access UNIX
References: <[e-mail]> <[e-mail]> <sdorner-271292095054@0.0.0.0>
Date: Mon, 28 Dec 1992 18:50:31 GMT
Lines: 62

In article <sdorner-271292095054@0.0.0.0> [e-mail] (Steve Dorner) writes:

>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.

How about picking one of the existing formats for a change?  As you
mentioned, it's already being done.

>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.

The real problem with both of these is that they necessarily apply to
all recipients, where you may want a receipt from only one or a few.

The AT&T PMX-mailers add "/receipt" to specific To: or CC: lines to
request receipts individually.  The receiving program may not
recognize the name in the address due to aliasing or forwarding, so
the sending side provides another header ">To: address  /receipt" on
each copy where the receipt was requested.  The PMX-mailers are
pretty dumb about this and make a separate copy for each To: or CC:
line in the message, but a smarter approach would be to make just
the number of copies you need (1 if all addresses are the same, 2
if some request receipts and some don't).  Of course you could use
Read-Receipt-Requested: this way too.

>Objection 2.  Where do you draw the line at what is "final" delivery?  What
>about POP and POP-like systems?

The AT&T packages that are more or less "on-line" and able to send at any
time generate the receipt when the message is displayed on the screen
(that is, the user selects "read").  The dial-up versions (access-plus
and the windows and mac equivalents) generate the receipts as the messages
are transferred out to the remote machine since they will be off-line
as they are read.  The wording of the receipt is different to indicate
the condition.

>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.

More to the point, it saves a phone call, and if you have to call to
check on the email, why bother with the email in the first place?

>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.

And then you're back to the phone calls.  Unless you only use
email for things that don't matter.  So why bother?

Les Mikesell
  [e-mail]