Mailing List Message #15090
From: Bill Cole <>
Subject: Re: postmaster and spam
Date: Tue, 6 Sep 2005 22:39:00 -0400
To: SIMS Discussions <>
At 7:27 AM -0700 9/6/05, Warren Michelsen  imposed structure on a stream of electrons, yielding:
Regarding the acceptance of mail to 'postmaster' at each domain...
Is ALL mail required to be accepted or do the RFCs permit rejection
of obvious spam.

Now, in my SIMS router I have:
<postmaster%*@blacklisted> = [aggregated postmaster account]

to accept mail from blacklisted sources. There may be times when a
non-spammer at a blacklisted domain may need to contact the

Keep in mind that blacklisted *domains* (i.e.domain names you've mapped to error in the router) don't get any second chance. Senders who are blacklisted by domain are rejected at the MAIL FROM command, so there is no way to drill holes for them. The 'blacklisted' super-domain is applied to the recipient addresses on SMTP connections whose IP addresses are in either the local blacklist or a configured DNSBL.

But what about obvious spam? I'm in the process of migrating all my
domains to a new, non-SIMS server which includes built-in spam
filters. Is it 'RFC-legal' to reject obvious spam, even to the
postmaster account?

That depends on who you ask. There are no RFC police or RFC courts, and this is a somewhat unclear area.

Aggressive filtering of the postmaster address that runs a significant risk of catching valid mail is generally considered a bad thing. This means that you are best off limiting the controls on postmaster to the most certain tests. For example, the Spamcop BL, which frequently but usually briefly lists major ISP output points, would be a bad choice however the Spamhaus XBL, which is a composite of lists that very reliably (and also temporarily) list only compromised and abused machines that in nearly all cases send no legitimate mail at all, would be a reasonable layer in front of postmaster. Body filters can be useful, but they have to be used VERY carefully. For example, recently the most popular free AV filter for mail, ClamAV, got a very poorly considered 'improvement' that caused a lot of bad rejections. They started detecting 'phish' mail as well as actual malware, and neglected to put any controls in place to prevent detection of *reports* of phishing. A lot of abuse desks rejected a lot of reports. If you do put any sort of AV in front of postmaster (or any other role account) you need to pay very close attention to the fact that all AV developers seem to have caught the same mission-creeping disease, and corral the software.

A very useful approach is to forget about content filters altogether, and think very carefully about the SMTP-layer filtering as a matter of *policy* rather than looking at the task of protecting postmaster from spam. Using the XBL is a reasonable policy matter: the listed addresses are ones used by insecure machines engaged in abusive behavior. Rejecting all mail from particular networks (China Netcom, for example...) may be something you can justify as a matter of policy, if you keep your eyes open to the risks. For some non-SIMS MTA's (Postfix and Sendmail, for example) it is possible to latch acceptance to unreasonable behaviors like pipelining SMTP commands before the greeting banner is sent or sending absurd commands like 'HELO localhost'. Those sorts of behaviors may not be limited exclusively to pure spam sources, but they certainly correlate to spam and malware and are so far from RFC compliance that any session including them arguably SHOULD fail.

A huge percentage of the spam I personally receive is sent to one or
another postmaster account.

This is a clue towards one efficient way to deal with spammed role accounts: just don't look at it every day.

For example, I use a bunch of DNSBL's (including a local blacklist that outgrew SIMS) and have this router rule:

<postmaster%*@blacklisted> = postmaster-blocked

And an account suitably named. Once every week or two I pull all the messages  in that account into a Eudora mailbox, sort by Subject, and make swift work of the dozens of  extremely similar messages. Having them in big bunches helps, because the patterns leap to the eye. This is particularly useful when you have a training-based filter (e.g. the Bayesian filters in Eudora and Mail) because you can use the big blobs of spam that hit postmaster as rich training material.

Bill Cole

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster