Re: [ietf-smtp] DSNs

[Ned Freed <[e-mail]>]

> John Levine writes:

> > In article <[e-mail]> you
> > write:
> > >> In general I agree but there are still situations where an MTA (mine
> > >> for example) accepts a message intending to forward it somewhere else
> > >> and then the forward fails.  Either send a DSN or drop it on the floor
> > >> at that point.
> > >
> > >Well, yes. You take ownership of that message by the act of forwarding, you
> > >now own it, from the point of forwarding. If you don't want to disclose the
> > >forwarded-to address, that's your responsibility, so either set the sender's
> > >address to <>, or to some other address where you want the bounces to go.
> >
> > Huh?  If I send a DSN it includes the original delivery address but it
> > doesn't have to include the forwarded-to address.

That depends on the type of forwwarding. Forwarding that doesn't change
envelope return address is reflected in the change of the final recipient
address only; the DSN request semantics generally do not change.

> I'm talking about the forwarding system. Whatever's forwarding the message,
> it can easily reset the return address to <>, or to some bit bucket.

Yes, and if this happens as far as the DSN status of the message is 
concerned you have essentially delivered one message and things are
now proceeding with a new one.

All of this is covered in detail in RFC 3461 section 5.2.7. The terminology
may be a bit archaic but the required semantics are pretty clear.

				Ned