dmquigg-spf at yahoo
Dec 23, 2007, 9:44 AM
Post #4 of 6
One other surprise I just noticed. Google's Received-SPF header is *below* their Received header!
Received: from smtp110.plus.mail.sp1.yahoo.com (smtp110.plus.mail.sp1.yahoo.com [18.104.22.168])
by mx.google.com with SMTP id a8si5500255poa.2.2007.12.23.09.27.32;
Sun, 23 Dec 2007 09:27:33 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning spamtrap [at] box67 does not designate 22.214.171.124 as permitted sender) client-ip=126.96.36.199;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning spamtrap [at] box67 does not designate 188.8.131.52 as permitted sender) smtp.mail=spamtrap [at] box67
Received: (qmail 9320 invoked from network); 23 Dec 2007 17:27:31 -0000
Received: from unknown (HELO phred.box67.com) (david_macquigg [at] 69 with login)
by smtp110.plus.mail.sp1.yahoo.com with SMTP; 23 Dec 2007 17:27:31 -0000
We had a thorough discussion of proper header order a year ago http://www.emaildiscussions.com/showthread.php?t=46632, and ended up changing our Border Patrol MTA to place these headers as expected by most "header readers" (not in strict chronological order).
>At 02:42 AM 12/23/2007 +0000, I wrote:
>>Julian Mehnle wrote:
>>> Julian Mehnle wrote:
>>> > Frank Ellermann wrote:
>>> > > I think [Google] reject FAIL, [...]
>>> > >
>>> > > See also <http://www.openspf.org/Frank_Ellermann/Google>, if it's
>>> > > generally interesting I could move it to an "ordinary" openspf
>>> > > page.
>>> > Before we consider that, how can we be sure that the rejection
>>> > demonstrated on that page is actually due to an SPF Fail?
>>> Here's an indication to the contrary from 2007-12-03:
>>And here's the result of me sending an SPF-spoofed message to a GMail
>>account I created ad-hoc:
>>| Received: by 10.150.202.10 with SMTP id z10cs28334ybf;
>>| Sat, 22 Dec 2007 18:18:36 -0800 (PST)
>>| Received: by 10.65.73.16 with SMTP id a16mr4520780qbl.36.1198376315518;
>>| Sat, 22 Dec 2007 18:18:35 -0800 (PST)
>>| Return-Path: <julian [at] mehnle>
>>| Received: from earbone.schlitt.net (openspf.org [184.108.40.206])
>>| by mx.google.com with ESMTP id h7si3376335roe.17.2007.12.22.18.17.59;
>>| Sat, 22 Dec 2007 18:18:35 -0800 (PST)
>>| Received-SPF: fail (google.com: domain of julian [at] mehnle does not designate 220.127.116.11 as permitted sender) client-ip=18.104.22.168;
>>| Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of julian [at] mehnle does not designate 22.214.171.124 as permitted sender) smtp.mail=julian [at] mehnle
>>I.e., no SMTP-time rejection.
>This *is* a surprise!! I get exactly the same result sending from a yahoo.com account to a gmail.com account, using a box67 return address with a -all SPF record.
>Received: from smtp118.plus.mail.sp1.yahoo.com (smtp118.plus.mail.sp1.yahoo.com [126.96.36.199])
> by mx.google.com with SMTP id n40si5215300wag.34.2007.12.23.00.19.04;
> Sun, 23 Dec 2007 00:19:06 -0800 (PST)
>Received-SPF: fail (google.com: domain of honeypot [at] box67 does not designate 188.8.131.52 as permitted sender) client-ip=184.108.40.206;
>Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of honeypot [at] box67 does not designate 220.127.116.11 as permitted sender) smtp.mail=honeypot [at] box67
>So even if we are in that brave 3% publishing -all, our policy is likely to be ignored by large ESPs!
>I tried it in the other direction - from Gmail to Yahoo, and it also went through. In this case, however, I see that the envelope return address was my actual gmail account, not the box67 address that I set up in Gmail's "Send mail as" account setup page. It seems Google is doing the right thing for SPF, although I think some of their users would be surprised to know that their real email address is not secure.
>Here is my latest theory about what Google is doing. They actually, in spite of their lack of communication and response to complaints, are trying to do the right thing. The huge number of IP addresses in their SPF record is because they actually have legitimate mail coming from webmail accounts, blogger accounts, whatever, and the machines running those services can be anywhere in their worldwide network. They could do a better job of detecting and limiting outgoing spam, but the status quo is good enough. Improving the reputation on their outgoing mail is not worth the cost of routing it all through a few special servers.
>As for the ~all in their own SPF record, they are apparently concerned about false rejects that can occur with -all (due to the "forwarding problem"). A softfail ~all will hopefully get someone's attention at the receiving end, perhaps even a notification back to Google, where a -all will more likely get a reject with notice only to the forwarder.
>I wish I could be more confident that the -all in my SPF record isn't causing a problem. It is hard to know when a message is lost, and even harder to track down the cause.
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=78979542-3cb7f1
Powered by Listbox: http://www.listbox.com