Article View: comp.mail.headers
Article #198Re: Return-Receipt-To & forwarding...
From: Leslie Mikesell
Date: Mon, 28 Dec 1992 18:50
Date: Mon, 28 Dec 1992 18:50
62 lines
3608 bytes
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!lesReferences:
<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