[TAG] (forw) Spam Prevention by Enforcing Standards

[Rick Moen]

Quoting Ben Okopnik (ben at linuxgazette.net):

> Since I'm not an SMTP guru, I'm mystified. Spammers harvest email
> addresses off the Web; why would they need to know what the MX is for a
> given domain when they have the actual address? If they do manage to get
> a useful result out of 'dig -tmx <domainname>', what does that actually
> get them?

Certainly, those address lists are built in part through Web-spidering
and harvesting mailto: hyperlinks -- not to mention the equally common
practice of grabbing addresses from virus-infected Wind0ws hosts via
MAPI address-book calls and grepping through the MSIE Web cache.  That's
part of what builds the CDs of believed-good addresses that the _real_
pros sell to spammers.  (The real pros, who also develop mass-mailing
software dummied down enough so that even spammers can use them, are
probably the only ones actually making money from this industry.
Spammers themselves -- most of them -- are the technological equivalent
of Herbalife distributors.  Losers.  Criminal-leaning luftmenschen.[1])

However, Sabahattin's point is that the spammers mass-mailing tools 
have to _not only possess_ a large list of mailbox targets to hit, but
then must actually _deliver to them_.  And those tools tend to be very
badly written, by people who don't give a damn about SMTP RFCs but just
want to push stuff out the door.

The fact that spammers' software characteristically ignores RFCs can be
used against them:  Just make sure that your receiving MTA enforces the
RFCs, and reject any mail from a non-compliant host.  (He had a specific
idea, in that area:  I'm building up to that.)

I already do follow that general strategy, using "callouts":  The RFCs
require that any domain doing SMTP mail accept mail to two standard
mailboxes for administrative reasons, postmaster and abuse.[2]  My own MTA,
at any time when a delivering MTA has a pending SMTP session open to
drop off mail and mine hasn't yet accepted it, does a return SMTP
side-session to the claimed delivering domain's mail server and
initiates a test message to postmaster and one to abuse.  If the other
side indicates that those are acceptable delivery addresses, my MTA
considers the domain to pass that test (and drops the test mails without
completing their delivery).  Otherwise, my MTA issues a 550 SMTP
permanent refusal code on the incoming delivery attempt, including an
explanatory error code telling the sender why his/her sending mail
system needs to comply with the RFCs.

Some accuse me of being too militant in this area:  I've had sysadmins
write back complaining that they'd manually disabled acceptance of
postmaster and abuse mail, because they've become spam-targets.  (In
other words, they've adopted the "hide from spammers" strategy.)  My
response is "Sorry, but you really do need to follow the RFCs" -- though
I also do whitelist their domains, exempting them from the callout
check.[3]  I also point out to the complaining sysadmins that their
strategy _will_ make their systems look like spam-sources, and so they
might want to consider switching strategies, to implementing better
spam-rejection instead of hiding.

Getting back to Sabahattin's suggestion:  One of RFC 2821's fine points
is that, although the primary means in the DNS of specifying where a
domain's mail goes is "MX" entries, there's also an implicit fallback:
If a domain (or fully qualified domain name) lacks an MX entry, the 
sending SMTP system is supposed to fall back on the "A" (forward lookup)
entry.

Spammers' software tools being designed in an arrogantly RFC-ignorant
fashion, they will often fail to be -able- to deliver mail to domains
lacking MX records.  Thus, Sabahattin's suggestion was:  Remove your MX 
entry.  Doing so will trip up a signficant fraction fo spammers, while
it should not sabotage any but a very few legitimate mailers.


[1] Yiddish is the only language with quite the requisite degree of
disdain, in this context.  Quoting Leo Rosten's _The Joys of Yiddish_:

  luftmensch

   Pronounced LOOFT-mensh.  German:  Luft "air"; Mensch "man".

   1.  Someone with his head in the clouds.
   2.  An impractical fellow, but optimistic.
   3.  A dreamy, sensitive, poetic type.
   4.  One without an occupation, who lives or works ad libitum.

Except, luftmenschen would typically be harmless, likeable people, in
which category spammers do not qualify.

[2] A fair reading of the RFCs is that the addreses must accept
_reasonable_ mail related to their purposes, e.g., they're not obliged
to accept arbitrary content or spam.

[3] All common SMTP daemons default to handling those two mailboxes as
valid incoming addresses:  The sysadmin who have trouble are those
who've manually acted to disable that RFC-required feature.
Additionally, I am told that some releases of Microsoft Exchange have
not bothered to be RFC-compliant.