Re: DSN action code "expanded" with lmtp_assume_final=yes

[lst_hoe02]

Zitat von Wietse Venema <wie...@porcupine.org>:

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.

Totaly aggreed. It's ugly and useless.

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

external.mailaddr...@kwsoft.de --> u...@transport.internal

and have a transport map like

transport.internal lmtp:unix:/path/to/socket

That's the point where the "SUCCESS" get lost before reaching LMTP i guess. We do virtual aliasing (virtual_alias_maps) of the form

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.

This will delegate the generation of DSN downstream. In our case this would be LMTP so "lmtp_assume_final" should get honored?

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

Many Thanks for your help

Andreas

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.

smime.p7s
Description: S/MIME Cryptographic Signature