[Top] [All Lists]

Re: [spf-discuss] Re: Google NOT rejecting on SPF Fail.

2007-12-28 16:15:35
David MacQuigg wrote:
At 06:18 AM 12/28/2007 +0100, Frank Ellermann wrote:
Julian Mehnle wrote:

I got word from an authoritative source within Google that they
generally do NOT reject on SPF Fail.
Hm... :-(

They reject for a few other reasons, such as the SMTP sender
being a dynamically allocated IP address (which seems to be what Frank observed)
Kind of odd that they bother to receive the DATA when the sender
is a dynamic IP producing an SPF FAIL.  Google re-inventing tar-
pitting makes no sense, so do they want the DATA for logging, or
for Googlebot ?  <g>

The reasons are limitless. Whether it's identifying patterns of hosts forwarding mail that would otherwise trigger an SPF fail result, collecting spam signatures, looking for mail that appears to be ham but has a screwed up SPF config, or identifying spam domains so that they can drop them from their search index... it really doesn't matter. It's of no cost to anyone but Google and the networks involved in sending the SPF fail'able mail. With Google's 16 billion network peerings, the networks involved in sending the mail is for the signifcant part limited to the end host's (provider's) network.

SPF Fail contributes as a factor to their spam decision, though.
Let's hope that folks *forwarding* their mail to Gmail look into
their spam folder at least once.  Gmail also offers to poll POP3
mailboxes, and so "traditional forwarding" should be rarely used.

Good point.  We need to educate folks on this.

I'm very pessimistic about "accept SPF FAIL" strategies, they're
at odds with SPF FAIL design principles.

My guess is that Google is seeing a significant amount of "ham" in the SPF 
rejects.  Otherwise, they would not be wasting the resources to transfer the data.

I'm utterly amazed that no one has yet to mention the value in getting the DATA of a spam.

If you, however you wish, generate signatures of spam originating from a bunch of dynamic IPs and then use those signatures against mail received from IPs that you're not sure if they're dynamic or not you can easily identify spam (coming from the not known to be dynamic IPs) that you've already seen copies of from dynamic IP'd hosts. You would not be able to do this if you didn't accept the DATA from the dynamic hosts.

It's free, shall I say, DATA, for their anti-spam systems. If they can afford the bandwidth (and I have no reason to believe that they can't) then why not? Besides, there has been no evidence presented that says that they don't, after accepting the same spam from the same host a bunch of times, start ignoring such hosts for some period of time.

If we want to persuade Google and perhaps a lot of others to follow SPF design 
principles, we'll need data on real mailflows.  What percent of SPF fails are 
spam?  It may be lower than we think, assuming spammers are paying attention to 
SPF records.

Who, aside from Google and people sending SPF fail'able mail, cares if Google (and others) accept the DATA or even the RCPT TO's of messages with envelopes that trigger an SPF fail result. Why would these people care? Why would the SPF project care? It's not like Google is promoting that everyone should do it even if it would be of no benefit to most sites. Even if they were, anyone dim enough to listen and do it is going to do be doing something else dumb that they've heard of anyway. Bandwidth resource management isn't usually that high up on the list of priorities at places with poorly/cluelessly managed mail systems (so accepting or not accepting DATA isn't really going to matter to these people).


Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>