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
