Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199505312008.QAA12493@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
cc: drums@CS.UTK.EDU, moore@CS.UTK.EDU
Subject: Re: getting started 
In-reply-to: Your message of "Wed, 31 May 1995 21:18:28 +0200."
             <199505311934.PAA16627@CS.UTK.EDU> 
Date: Wed, 31 May 1995 16:08:13 -0400
Sender: moore@CS.UTK.EDU

> >1. When a  MTA needs to generate  a bounce message, what  is the correct
> >   address to use?  (answer: envelope FROM). Granted  there are gateways
> >   which  destroy  this out-of-band  address,  but  they should  not  be
> >   allowed to coexist with the Internet mail system.

> It's easy for you to make this kind of demand, but there are MANY
> popular mail systems that don't have a concept of "errors go to
> address 1, replies go to address 2". So you have two options.  You
> can gateway them imperfectly, or not gateway them.

Ay, there's the rub.

I think our primary goal should be: anyone who takes the time to read
the documents should very clearly understand what the correct behavior
is.  At least then they won't fail because of ignorance.

And while we want the mail system to be able to tolerate broken
systems, we should not "legalize" the behavior of broken gateways.

Finally, for the really hard cases, we might want to recommend a
design choice.  That is, it's better for replies to go to the envelope
return address, than it is for bounces to go to the header from or
reply-to address.

Keith

p.s. There are also techniques that can be employed to make sure that
bounce messages don't go to the wrong place.  For example: a gateway
that reliably rejects bogus addresses at the RCPT TO command, will
generate far fewer nondelivery reports (maybe none at all), and thus
will cause less harm even if it does send them to the wrong place.