Re: bounce, mta, & mua (was Re: sieve draft)

On Wed, 5 Nov 1997, Tomas Fasth wrote:

> > Why shouldn't they?  They have all the envelope information they need.
> > If a message can't be given to the user but was delivered to the mail store,
> > the POP client is probably the only program that knows why.
> Tim, I understand that, with the exception that Return-Path: might
> not be available and you may therefore not be able to conform to the
> following quote from RFC 1894 chapter 2 page 7 2nd paragraph:
> "
>    The DSN MUST be addressed (in both the message header and the
>    transport envelope) to the return address from the transport envelope
>    which accompanied the original message for which the DSN was
>    generated.  (For a message that arrived via SMTP, the envelope return
>    address appears in the MAIL FROM command.)
> "
821 says MTAs write the MAIL FROM address into the Return-Path header.
While I can imagine an MTA that violated this, it's unlikely that a site
would want filtering and be unwilling to upgrade to a slightly more
compliant MTA.

> Anyway, a POP client generating DSN's does not make much sense to me.
> The message has already reached it's destination, nothing can be done
> to prevent a delivery.
But in what context has it hit its destination?

> > No, I don't.  Prohibitions against configuring your mailer to do something
> > dumb are not typically part of protocol documentation.
> Hmm. You might not want to prohibit.
> But you might want to discourage inappropriate usage.
How?  The only thing I can think of is something that suggests users try
avoiding doing dumb things, and that's rather difficult.

-- 
                                           Tim Showalter 
tjs(_at_)andrew(_dot_)cmu(_dot_)edu