🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.mail.headers
Article #198

Re: Return-Receipt-To & forwarding...

#198
From: Leslie Mikesell
Date: Mon, 28 Dec 1992 18:50
62 lines
3608 bytes
In article <sdorner-271292095054@0.0.0.0> sdorner@qualcomm.com (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
  les@chinet.chi.il.us
Technical Details
Message-ID: <BzzGC8.4Gr@chinet.chi.il.us>
Path: arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!linac!att!mcdchg!chinet!les
References: <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!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!linac!att!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: Return-Receipt-To & forwarding...
Message-ID: <BzzGC8.4Gr@chinet.chi.il.us>
Organization: Chinet - Public Access UNIX
References: <1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0>
Date: Mon, 28 Dec 1992 18:50:31 GMT
Lines: 62