Spammers Skirt IP Authentication Attempts

Wed Sep 8 12:21:30 UTC 2004

On Mon, Sep 06, 2004 at 07:19:01PM -0400, Mark Jeftovic wrote:
> I'm not sure the people behind this concept (SPF, RMX, et al) ever
> intended it to be the FUSSP, but a lot of the ensuing enthusiasm
> built it up to that.

Consider that the people behind SPF made this statement (upon
introducing it):

	"Spam as a technical problem is solved by SPF."

If, therefore, there is an overabundance of enthusiasm for that concept,
then it seems to be very clear where full responsibility for that rests.

> I've *never* viewed SPF as an "antispam" methodology, but considered
> it an inevitable utility of the DNS system. Other methods are
> evolving to deal with spam, don't confuse them with what SPF is,
> which is essentially an authentication/identification framework
> that has the ability to mitigate one of the more popularly used
> spam obfuscation techniques.

I'll agree with you that it may mitigate one of the more popularly
used spammer obfuscation techniques, but that particular technique is
a minor problem (considering spam/abuse as a whole) and not all that
worth solving -- since *other* spammer obfuscation techniques which
SPF (and DomainKeys and SenderID et.al.) don't address are already
available and being used.  (Why aren't they used more?  Spammers haven't
needed to.  But if pressed, they will.  Rapidly.)

The bigger problem isn't the spammer obfuscation technique: it's the
backscatter from all the mail systems which bounce instead of reject,
Bouncing was not all *that* unreasonable until we started to operate in an
environment with massive SMTP forgery (from spam/viruses/etc.) -- several
years ago.  It's now much more desirable to reject whenever possible,
saving everyone bandwidth/cycles/grief.  I don't think I like the idea
of wallpapering over this problem with SPf/DomainKeys/etc.: I think I'd
rather see those mail systems fixed to deal with the environment they
find themselves in.

	[ Especially because the other spammer obfuscation techniques
	I referred to are available, and will be used if and when SPF
	or DomainKeys or any of these are widely deployed.  Thus, mail
	systems will *still* inhabit an environment of massive forgery
	and should be prepared to deal with it as best they can...where
	I think one approach to that is "don't make it any worse". ]

Yeah, that may be a lot of work to complete -- although there are a
myriad of simple techniques available to at least mitigate it, if not
eliminate it entirely, and any relief would be welcome.

> That spammers are publishing SPF records is in no way indicative
> of an inherent flaw in SPF's objectives or a failure in its
> implementation, in fact, I welcome spammers who publish SPF
> data detailing the originating points of their email. If
> more "known spam domains" did this, a handy DNSBL could be
> constructed out of such data (with a few caveats of course,
> it would also potentially open the door to a type of DoS attack).

RHSBLs (i.e. DNSBLs which list domain names instead of IP addresses, thus
"Right-Hand-Side BL's") have already been built.  See www.surbl.org and
www.ahbl.org, for example.

But this tactic doesn't work -- as an anti-spam technique -- as well
as we might hope, for three reasons:

	1. Spammers have an [effectively] infinite supply of domains.

This won't change because spammers who burn through domains rapidly
(and thus need to purchase more) are some of the registrars' best customers.
They're also early adopters of "obfuscated registration", so much so that
it's becoming increasingly likely that any domain thus registered is
declaring "intent to abuse". [1]

	2. Spammers control a large -- as in tens of millions -- number
	of zombies. [2]

This won't change because none of the three entities who could do anything
about it (the zombies' former owners, consumer broadband ISPs, Microsoft)
are willing to step up, admit there's a problem, and do whatever it takes
to fix it.

	3. Mail from a forged sender is operationally indistinguishable
	from mail from an unforged but unknown sender. [3]

This won't change either.  And because of #1, spammers have an essentially
infinite number of domains to do it with, and because of #2, they have a
large number of systems to do it from.

And as a result, a *lot* of things that we could try, not just
SPF/DomainKeys/et.al., just won't work.  (Example?  Oh, take the various
"hashcash" ideas that have been floated: getting into a computing cycle
contest with spammers is a guaranteed loss.)

---Rsk

[1] For example, one group of pirate-software spammers appears to be
burning through domains at the rate of one every 24-48 hours, and has
been doing this for months.

[2]  It's hard to know how many systems are zombies, but "tens of millions"
is probably the right order of magnitude.  I did a back-of-the-envelope
calculation a few months and came up with 10 to 20 million; Carl Hutzler
(of AOL Policy Enforcement) provided an estimate of 50-100 million on Spam-L.
We went back and forth a little bit about this, and while I don't want to
try to speak for Carl, I think we agreed that the true number is probably
in the middle: so let's say, 40 million just so we have a number to argue about.

[3] This may not be clear, so let me illustrate by example.  Consider
two incoming pieces of SMTP traffic, which claim to be from:

		frooblebonker at yahoo.com
and
		joe at 56trf5.com

respectively.  If I tell you that the first one is forged -- and that the
putative sender doesn't exist (or isn't really the person sending the
message) and that the second one is unforged (and is actually correct)
-- did I just do you any good *with respect to stopping spam*?

For the first one: sure.  You reject it, 'cause it's forged.  Heck,
even if it's not spam, and it may not be, you may decide to reject
it anyway: using the anti-SMTP-forgery technlogy of your choice: SPF,
DomainKeys, it doesn't matter.

For the second one: no.  Because knowing that sender is unforged/real
doesn't, in and of itself, do you any good *with respect to stopping spam*.
You ALSO need a way to know that 56trf5.com is a spam source domain.

And you don't know that.  Yet.

So suppose I tell you that, too: "56trf5.com is probably controlled by
a well-known spammer and so you might want to block traffic from it."
Did I just do any good?  Not really.  Because tomorrow you will get
SMTP traffic from:

	sam at 78jh89.com

and none of the things that you learned today *in and of themselves* are
going to help you figure out what to do with that.  Oh, it's unforged:
it really IS from 78jh89.com.  You can even confirm it with your
favorite anti-SMTP-forgery technology, if you like.

So what?

It doesn't do you any good until I also tell you that 78jh89.com
is another spammer-controlled domain.

Lather, rinse, repeat hundreds of thousands (or more) times.