postmaster mail

[Pat Lashley]

--On Wednesday, January 21, 2004 16:30:54 -0500 Scott Adkins <adkinss at ohio.edu> wrote:

> 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