Re: Success DSNs From Come to Postmaster
On 30 Jan 2012, at 22:20, Wietse Venema wrote: Ralf Hildebrandt: * Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com: Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? Here's what happens. First, mail to the null address goes to MAILER-DAEMON by default: empty_address_recipient (default: MAILER-DAEMON) The recipient of mail addressed to the null address. Postfix does not accept such addresses in SMTP commands, but they may still be created locally as the result of configuration or software error. Second, it's common to have an alias MAILER-DAEMON - postmaster, so that explains why the mail for ends up there. Right. This makes sense. And the To: field in notifications is empty itself, too. I've set empty_recipient_address to double-bounce, which seems to do what I want, send these to bit heaven. (BTW: it isn't documented anywhere that double-bounce works arbitrarily like this, nor that it's accepted in SMTP as 'double-bounce'.) Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. Are these internally-generated bounce messages distinguishable from mail that is actually injected with SMTP or the sendmail command as 'mail from:' or 'sendmail -f '? I assume one of two things must be true in order to receive a double bounce for such mails, either that this is really the case or the bounce handling code follows through, first for a single bounce and then a double bounce, such that a failed message injected with is included directly in the double bounce, rather than inside a single bounce which is included in the double bounce. I never saw the latter, leading me to believe the former assumption, which is that internally generated mail is special. This handling of fail/delay notifications satisfies the RFC's requirement of never responding to the sender address. However, the code that handles NOTIFY=SUCCESS fails to satisfy that RFC requirement. It was written several years earlier to implement support for sendmail -bv and sendmail -v, and was not updated when it was put into service to also handle SUCCESS notifications. I'll make the NOTIFY=SUCCESS handling consistent with fail/delay. Thank you! Cheers, Sabahattin
Re: Success DSNs From Come to Postmaster
Sabahattin Gucukoglu: Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. Are these internally-generated bounce messages distinguishable from mail that is actually injected with SMTP or the sendmail command as 'mail from:' or 'sendmail -f '? I assume one of Just like non-bounce messages, internally-generated single-bounce and double-bounce messages are indistinguishable from externally-generated mail except, for programs that make detailed examination of Received: headers, parse DKIM signatures, analyze logfiles, etc. In any case, the success notifier now distinguishes between bounce and non-bounce messages, similar to the fail/warn notifiers. Wietse
Success DSNs From Come to Postmaster
Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? I vote bug. :-) Any workarounds to prevent this in the meantime? Cheers, Sabahattin
Re: Success DSNs From Come to Postmaster
Ralf Hildebrandt: * Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com: Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? Here's what happens. First, mail to the null address goes to MAILER-DAEMON by default: empty_address_recipient (default: MAILER-DAEMON) The recipient of mail addressed to the null address. Postfix does not accept such addresses in SMTP commands, but they may still be created locally as the result of configuration or software error. Second, it's common to have an alias MAILER-DAEMON - postmaster, so that explains why the mail for ends up there. Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. This handling of fail/delay notifications satisfies the RFC's requirement of never responding to the sender address. However, the code that handles NOTIFY=SUCCESS fails to satisfy that RFC requirement. It was written several years earlier to implement support for sendmail -bv and sendmail -v, and was not updated when it was put into service to also handle SUCCESS notifications. I'll make the NOTIFY=SUCCESS handling consistent with fail/delay. Wietse
