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:
<[EMAIL PROTECTED]> = [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
postmaster.
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:
<[EMAIL PROTECTED]> = 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
[EMAIL PROTECTED]
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
