Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199505312018.QAA21061@CS.UTK.EDU>
Date:        Wed, 31 May 1995 22:08:31 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: getting started
To: drums@CS.UTK.EDU
In-Reply-To: Message of Wed, 31 May 1995 16:08:13 -0400 from moore@cs.utk.edu

On Wed, 31 May 1995 16:08:13 -0400 Keith Moore <moore@cs.utk.edu> said:

>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.

I agree.

>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.

That one  is a very controversial  issue. If you ask  mail administrators
they'll usually agree with that. If  you ask users it varies, and mailing
list  owners  will  strenuously  disagree  because  they  get  dozens  of
misdirected messages  a day from MS  Mail users (MS Mail  does just that,
use the  MAIL FROM:  address for the  one-size-fits-all origin  field). I
know a site that had MS customize MS Mail for them so it wouldn't do that
and instead  would send everything to  the reply address. I  have no idea
how much they had  to pay for that but I imagine  it wasn't cheap. Anyway
it clearly shows  that some sites feel very strongly  about this issue. I
doubt you will reach a consensus :-(

>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.

Yes this  is a design  we can  definitely recommend, because  it improves
compatibility and  interoperability without impacting  usability, however
in some cases it is just not  implementable because the recipient is on a
remote host on the target network.

  Eric