Actually, the aliases for postmaster and mailer-daemon are as follows:
postmaster: root+postmaster mailer-daemon: root+mailer-daemon
The problem is that the mail isn't going *to* Mailer-Daemon, it is coming *from* Mailer-Daemon *to* postmaster. So, setting the alias to mailer-daemon isn't going to matter here.
The relevant sendmail.cf configuration is as follows:
# who (if anyone) should get extra copies of error messages #O PostmasterCopy=Postmaster
# where do errors that occur when sending errors get sent? #O DoubleBounceAddress=postmaster
I find it a bit confusing, as PostmasterCopy is commented out, which according to the docs means that it is undefined and thus does not send copies of error messages to the postmaster. The DoubleBounceAddress option is also commented out, which means that errors generated from already bounced e-mails will be sent to postmaster by default. This may be the culprit for our large amount of mail, and we can uncomment it and set it to nothing (i.e. remove 'postmaster') in order to not have e-mail sent to postmaster.
Assuming that I was forced to stick with Sendmail, I'd try explicitly setting both of those values to nothing. And if that didn't work, I'd try setting them to devnull. (And ensure that there's a "devnull: /dev/null" alias.)
The big question I am asking is what other people are doing. Are they turning it off (via configuration options or forwarding to /dev/null) or are they employing some filtering to throw away the bad in order to see the good? From what I am seeing in the messages, it isn't the easist thing in the world to come up with a good sieve filter to do it for me.
What I did, long ago, was abandon Sendmail in favor of Exim. I find Exim to be more flexable, more powerful, and easier to configure. And the code is well written; so you don't have to worry about when the next root exploit will be discovered...
Exim's default handling for undeliverable (after a configurable set of retries) messages with a null envelope sender is to freeze them on the queue for a few days and then make one more attempt to deliver before deletion. (Frozen messages are not retried during queue runs.) There are easy utilities to list and manipulate frozen messages. (Or non-frozen messages, for that matter.)
By the way, wouldn't it be better to disable the sending of those e-mails instead of forwarding to /dev/null. I am guessing that this would save on both CPU and IO if these e-mails weren't being generated to begin with. We receive easily over 500K messages a day, and it pains me to think that 25K of these are messages that we are throwing away, whether it be dumping them to /dev/null or manually deleting them.
You may be able to avoid generating them yourself; but you can't control what somebody else sends to you. It is arguably better to block them instead of accepting and forwarding to /dev/null; but the later is easier to configure and handles both locally and remotely generated messages. (And is very easy to 'switch off' for debugging purposes.)
Note that Exim never uses mailer-daemon as a localpart; so there's no need for a mailer-daemon alias or mailbox at all. (It uses the RFC mandated null sender address '<>' for bounce messages to avoid bounce loops.) [ And it also recognizes /dev/null as a special case and just drops the message instead of actually writing it to the null device. ]
Another advantage of Exim is that if using LMTPd over TCP/IP for Cyrus delivery, you can use a 'verify recipient/callout' ACL to both test for the existance of virtual users and also to detect Over Quota situations and issue a temporary failure code at SMTP RCPT time instead of accepting the message and leaving it in the MTA queue or trying to bounce it.
-Pat
