Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199505311936.PAA12316@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Dave Barr <barr@math.psu.edu>
cc: drums@CS.UTK.EDU, moore@CS.UTK.EDU
Subject: Re: getting started 
In-reply-to: Your message of "Wed, 31 May 1995 14:49:50 EDT."
             <199505311849.OAA00967@augusta.math.psu.edu> 
Date: Wed, 31 May 1995 15:36:21 -0400
Sender: moore@CS.UTK.EDU

> >Our first order of business should be to identify problems with the
> >existing mail protocol documents.
> 
> Putting my mailing list hat on, I can identify some serious present
> sources of confusion:
> 
> 1. When a MTA needs to generate a bounce message, what is the correct
>    address to use?  (answer: envelope FROM).  

IMHO, this is already clear from 821 and 1123.  However, given the
huge number of implementations that are broken in this area, it
wouldn't bother me if the revised 821 devoted an entire page to this,
with that text indented, vertically centered, double-spaced, and in
capital letters.  (Maybe also with a skull and crossbones?)

As an aside, Errors-To has to be deprecated.

> Granted there are gateways which destroy this out-of-band address,
> but they should not be allowed to coexist with the Internet mail
> system.

I don't know how we can police things.  I have some plans jotted down
for an active mail tester, which will do things like send messages to
both valid and invalid recipients at your site, with different
addresses for the envelope return-path, from, reply-to, errors-to,
return-receipt-to, and whatnot.  Then it looks at which ones of those
addresses got mail and complains if your mailer isn't up to spec.
That will let users find out what's wrong with their mail programs,
and then they can complain to their vendors.

> Having bounces go to
>    the Reply-To address has been a source of much pain and suffering.

Not to mention the From address, Errors-To, etc.

> 2. When a person activates the "reply" function of their MUA, what addresses
>    should go in the header?  Must the MUA support a "reply-all" function?
>    (IMHO yes)  If so, what addresses should go in the header?

Agreed that this is a problem.

Given our charter, I wonder how much we can specify of UA
functionality.  822 specifies how a UA should address replies, so I
guess we can clarify that much.  But this could potentially be a real
rathole...

> 3. What should be done with the current return-receipt-to mechanism?

I suggest: "MTAs MUST NOT honor the Return-Receipt-To header field".

Return-receipt-to has caused a number of problems, which is the reason
that the NOTARY request for delivery notifications is in the SMTP
envelope rather than the header.

The 822 extension model tacitly assumes that since everything in the
header is for the benefit of the recipient's user agent, nothing you
put in a header should be able to affect transport or delivery.  This
needs to be stated explicitly.

Keith