lst_ho...@kwsoft.de:
> we are trying to improve the DSN support of our environment and have
> set "lmtp_assume_final=yes" at our final mailstore using Cyrus and
> LMTP over socket.
> The resulting DSN still set
>
> Final-Recipient: rfc822; x...@kwsoft.de
> Original-Recipient: rfc822;x...@kwsoft.de
> Action: expanded
> Status: 2.0.0
> Diagnostic-Code: X-Postfix; alias expanded
Wietse:
> This really means what it says: some alias was expanded *before*
> LMTP got involved (this includes virtual aliasing. local
> aliasing, and ~/.forward file expansion).
lst_ho...@kwsoft.de:
> Ok, this means i can't get a "final" DSN if alias expansion happens
> before the LMTP delivery, no?
Postfix tries to minimize the damage from DSN. Postfix compares
the result of virtual alias expansion, and it reports "alias
expanded" ONLY when the alias produces a different result (the
result is more than one address, or the result is only one address
but it differs from the original one).
RFC 3461 allows three options:
1 - Don't propagate DSN attributes down-stream, and send a "relayed"
DSN. Postfix does not do this because it is too ugly.
2 - Propagate ENVID, (NOTIFY minus SUCCESS), RET, and ORCPT to the
result from alias expansion and send an "expanded" DSN. This
is what Postfix does (except for one-to-one virtual aliases
that translate one address into itself).
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).
Wietse
