On 9.4.2012, at 16.25, Wietse Venema wrote: > Timo Sirainen: >> There's a problem with aliases that LMTP server can't solve. Lets >> say I have two aliases: >> >> info@domain -> shared@domain >> sales@domain -> shared@domain >> >> The LMTP server sees RCPT TO:<shared@domain> for mails that arrive >> to both of them. If the sender sent the mail to only one of them, >> the original address can at least in theory be read from the >> Received: lines. If the sender sent the mail to both of these >> aliases, the LMTP server won't see the originating address anywhere >> at all. > > I wonder if careful use of the DSN extension would help. With DSN, > the SMTP/LMTP client sends the original recipient with: > > RCPT TO:<final-rcpt> ORCPT=rfc822;orig-rcpt ...
Does Postfix already send this if LMTP server advertises DSN? > One problem is that DSN hands off the responsibility to notify the > sender about successful delivery. I don't know if that is desirable. Not necessarily a problem, but I can't seem to find any discussion on how it should interact with Sieve. This is clear: * NOTIFY=FAILURE + Sieve discard: Don't send DSN But nothing else is. I'm guessing perhaps: * NOTIFY=SUCCESS + Sieve discard: Send a success DSN * NOTIFY=FAILURE + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=SUCCESS + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=FAILURE + Sieve ereject: Reject the mail on DATA reply, no DSN * NOTIFY=SUCCESS + Sieve ereject: Reject the mail on DATA reply, no DSN RET=FULL also seems like it could only be abused..
