North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Spammers Skirt IP Authentication Attempts

  • From: Robert Bonomi
  • Date: Wed Sep 08 14:28:59 2004

> From [email protected]  Wed Sep  8 12:05:02 2004
> To: [email protected]
> Subject: Re: Spammers Skirt IP Authentication Attempts
> From: Paul Vixie <[email protected]>
> Date: 08 Sep 2004 16:59:51 +0000
>
>
> [email protected] (vijay gill) writes:
>
> > ...  That means that if I do get a mail purporting to be from citi from
> > randomgibberish, I can junk it without hesitation.
>
> agreed, that is what it means.
>
> however, and this is the important part so everybody please pay attention,
> if you can junk something "without hesitation," then spammers will stop
> sending that kind of "something."  they make their money on clickthroughs,
> final sales, and referrals, which translates to one thing and one thing
> only: "volume."  if the way to keep their volume up means "put SPF metadata
> in for the domains they use" or even just "stop forging mail from domains
> that have SPF metadata" then that is exactly what they will do.  guaranteed.
>
> there's a bet here.  you could bet that by closing off this avenue, SPF will
> force spammers to use other methods that are more easily detected/filtered,
> and that if you play this cat&mouse game long enough, it will drive the cost
> of spam so high (or drive the volume benefit so low) that it'll just die out.
>

I, for one, don't think that SPF is a FUSSP (tm vernon), or anything close to
it.

I _do_ think that it is _a_step_ 'in the right direction'. I'd *love* to
see SPF-type data returned on rDNS queries -- that would practically put 
the zombie spam-sending machines out of business.

SPF _can_ serve a 'useful function' in spam-fighting. As follows:

   SPF verification query gets returns one of three kinds of result:
     1) MISMATCH on point-of-origin vs domain 'authorized' senders.  *VERY*
	probably spam.  Need a white-list check of the specific sender e-mail,
	and if that fails, an SMTP-session rejection is indicated.
     2) MATCH on point-of-origin for domain vs domain 'authorized' senders.
	'reliable' data-point that the domain owner 'authorized' the use
	of the domain-name.  Now it makes sense to query an _internally_
	_maintained_ database of 'familiar to me' domains, to see what types
	of prior mail from this domain have been seen.   This is a much
	simpler, quicker, less CPU-intensive test than the 'full' set of
	spam checks.  Match on 'known spammer' domain causes immediate 
	SMTP-time rejection; match on 'known NON-ISP, non-spammer' domain 
	and one is quite 'safe' in accepting the message without further
	checks.  Messages from 'unfamiliar' domains, and/or 'ISP' domains,
	get the full spam-check treatment.
     3) NO DATA.  In this scenario, doing the full set of spam checks, is
	unavoidable.  Unless you reject traffic based on the lack of SPF
	data; which is a non-starter strategy, until such time as SPF is 
	near-universally deployed.

If _nobody_ published SPF data, then the situation degenerates into case 3),
as a worst-case scenario. This is no worse than the situation _without_ SPF
checking.  (For the nit-pickers, yes, it is a _little_ worse, by the overhead
of the 100% no-constructive-date SPF queries.)

If a 'non trivial' share of the incoming message traffic falls into case 1)
and/or case 2), then the use of SPF is a net 'win' for the recipient.

*IF* the time comes when SPF deployment is near-univeral, then case 3) drops
out of the picture.  _IN_THAT_CASE_, spammers pretty much _have_ to publish
SPF data for their outgoing mail sources, to have any 'hope' of delivery.
Whereupon, either they're sending from 'known spammer' domains, or the
'unfamiliar domain' handling kicks in.

It aint the (or even 'a') FUSSP,  But it is a _big_ win for places that handle
large volumes of e-mail.  For those big shops, it doesn't take long for a
spammer domain to get out of the 'unrecognied' category, and into the 'known
spammer' class.  Whereupon, one SPF check, plus one internal database dip, and
they can dump the mail as from 'known spammers'.  The savings in system
resources, by using such an approach on several _billion_ pieces of mail per
day is definitely non-trivial.

It takes a while for wide-spread acceptance/implementation, but when that
state of affairs _is_ achieved, large-scale spammers have a serious problem:
  Messages claiming to be from sources lacking SPF validation get rejected.
  Messages with SPF-mismatch get bit-bucketed.
  Messages with SPF-validation from identified spammer domains get bit-bucketed

What's an _honest_ spammer to do?     <muffled snicker>