From owner-nanog@merit.edu Wed Sep 8 12:05:02 2004 To: nanog@merit.edu Subject: Re: Spammers Skirt IP Authentication Attempts From: Paul Vixie <vixie@vix.com> Date: 08 Sep 2004 16:59:51 +0000

vgill@vijaygill.com (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>