Wietse Venema:
> lst_ho...@kwsoft.de:
> Wietse:
> > 3 - Propagate ENVID, NOTIFY, RET, and ORCPT to one result from
> > alias expansion only, and send no DSN. Postfix does this with
> > one-to-one virtual aliases that translate one address into
> > itself.
> ...
> > The only thing I can change without breaking RFC compliance is to
> > do (3) for all one-on-one virtual aliases. That means Postfix will
> > reveal the "hidden" address to anyone who asks for it (and this
> > trick would not work for local aliases because Postfix does not
> > expand local aliases before it decides what DSN to send. That
> > would run local(8) out of memory when sending mail to a large
> > mailing list).
> >
> > The "hidden" address aka alias result will be included as
> > "Final-Recipient" in the DSN, no? Is this field mandatory or may it be
> > ommitted and only "Original-Recipient" sent back? This would be the
> > important recipient anyway because it is the one the message was
> > addressed to.
>
> I have sunk enormous amounts of time into the DSN implementation
> and am very happy that I have forgotten most of it. The important
> decisions are documented in comments, that is why I was able to
> summarize the three choices.
>
> Since you are the one who wants to report selectively, why don't
> you do the home work of finding the text that says what is and what
> is not required.
FYI, the Final-Recipient field is required.
Your best option is to limit the scope of DSN, so that it does not
go across your organizational boundary, as described by Victor.
In the gateway SMTP server, don't announce DSN to the outside world,
and in the gateway SMTP client, ignore DSN announcements from the
outside world.
Wietse
