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

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).
Daryl

-------------------------------------------
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: 
http://v2.listbox.com/member/?member_id=2183229&id_secret=80092007-d5a1fc
Powered by Listbox: http://www.listbox.com