Message-Id: <199603222335.RAA03349@ornette.uchicago.edu>
Reply-To: ckk@uchicago.edu
From: ckk@uchicago.edu
To: drums@cs.utk.edu
Subject: Condemning user replies going to envelope sender
In-reply-to: Your message of "Fri, 22 Mar 1996 14:21:00 EST."
             <"2444 Fri Mar 22 15:39:56 1996"@bnr.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 22 Mar 1996 17:35:26 -0600
Sender: ckk@ornette.uchicago.edu

I've been "lurking" and learning a great deal from your discussion and I don't want to distract you from the good work, but let me ask about one of my pet peeves, whether you think it's worth putting in a new, explicit statement about it in 822bis.

We all know how most LAN mail message formats have room for only one originator field (a single "From:" header), and how most LAN mail SMTP gateways these days (offenders I know of include MS-Mail, cc:Mail, Quickmail, even some VMS Mail products like Multinet) will drop the RFC 822 "From:"/"Reply-To:" headers down to comments, and instead copy the SMTP envelope MAIL FROM return path into their LAN mail "From:" header.

The effect is that their systems will send all user-initiated replies back to the RFC 821 envelope sender return path, not to the reply address mailbox determined by RFC 822.

I haven't seen an RFC (821/822/1123) chapter/verse yet where this specific action (user initiated reply goes to the envelope sender return path) is mentioned, either tolerated, deprecated, or prohibited.

(their argument that I've heard is that there still may be new errors generated, within the LAN system, even after the SMTP Gateway is done handling the message, so it is more important to preserve the SMTP envelope return path than the RFC 822 originator, if they have to choose one or the other)

I'm looking at RFC 1123 section 5.3.7 "Mail Gatewaying" which sounds like the appropriate place to find a discussion of this. In paragraph (A) it suggests copying the SMTP envelope information into new header fields ("X-SMTP-MAIL" and "X-SMTP-RCPT" are the given examples) which will require changing the LAN mail software to understand it. Note that this paragraph (A) doesn't even mention the fate of the RFC 822 originator headers.... and this is the crucial omission!

Again, as we know, all the current common LAN mail implementors copy the RFC 822 headers into comments instead, and instead copy the SMTP envelope information into the new "From:" header.

Also paragraph (E) after that says "The translation algorithm....SHOULD try to ensure that error messages .... are delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field of the RFC-822 message."

So this means that non-delivery error messages SHOULD NOT go to the From: header. But what about user-initiated replies going to the SMTP envelope sender, this is not mentioned anywhere? and it is such a common thing nowadays.

Would you consider adding a "MUST NOT", or "SHOULD NOT",  to clarify this, thereby declaring that existing MS-Mail, cc:Mail, Quickmail, VMS mail etc. gateways are in violation? Acknowledge what they do, but suggest a better way instead?

For example in RFC 822, 4.4.4 AUTOMATIC USE OF FROM / SENDER / REPLY-TO it specifically says 'The "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message.'

How about a similar phrase somewhere about how the "SMTP envelope return path should NEVER be used automatically in a recipient's reply message"?

Forgive me if this is beyond your agenda...

Chris Koenigsberg (CMU postmaster before John Myers took over :-)
U. of Chicago Academic Computing Services
ckk@uchicago.edu, more permanently ckk@pobox.com
http://www2.uchicago.edu/ns-acs/ckk/index.html
(more permanently http://www.pobox.com/~ckk)