Mailing List Archive

At 02:42 AM 12/23/2007 +0000, you 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@mehnle.net>
>| Received: from earbone.schlitt.net (openspf.org [76.79.20.188])
>| 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@mehnle.net does not designate 76.79.20.188 as permitted sender) client-ip=76.79.20.188;
>| Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of julian@mehnle.net does not designate 76.79.20.188 as permitted sender) smtp.mail=julian@mehnle.net
>
>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 [69.147.95.81])
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@box67.com does not designate 69.147.95.81 as permitted sender) client-ip=69.147.95.81;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of honeypot@box67.com does not designate 69.147.95.81 as permitted sender) smtp.mail=honeypot@box67.com

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.

-- Dave

-------------------------------------------
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=1311532&id_secret=78935681-496550
Powered by Listbox: http://www.listbox.com

On Sun, Dec 23, 2007 at 02:47:58AM -0700, David MacQuigg wrote:

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

I wrote to test messages to a gmail account and did notice a difference
when I used the web interface to view them:

A host matched by -all: sender name displayed in red
A host matched by mx/24: sender name displayed in green

I have little time right now so I rushed it, but I think there is no
other difference than the SPF match.

HTH
Alex

-------------------------------------------
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=1311532&id_secret=78943933-fe7d53
Powered by Listbox: http://www.listbox.com

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 [69.147.95.73])
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@box67.com does not designate 69.147.95.73 as permitted sender) client-ip=69.147.95.73;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning spamtrap@box67.com does not designate 69.147.95.73 as permitted sender) smtp.mail=spamtrap@box67.com
Received: (qmail 9320 invoked from network); 23 Dec 2007 17:27:31 -0000
Received: from unknown (HELO phred.box67.com) (david_macquigg@69.9.25.232 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).

-- Dave

>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@mehnle.net>
>>| Received: from earbone.schlitt.net (openspf.org [76.79.20.188])
>>| 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@mehnle.net does not designate 76.79.20.188 as permitted sender) client-ip=76.79.20.188;
>>| Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of julian@mehnle.net does not designate 76.79.20.188 as permitted sender) smtp.mail=julian@mehnle.net
>>
>>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 [69.147.95.81])
> 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@box67.com does not designate 69.147.95.81 as permitted sender) client-ip=69.147.95.81;
>Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of honeypot@box67.com does not designate 69.147.95.81 as permitted sender) smtp.mail=honeypot@box67.com
>
>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.
>
>-- Dave

-------------------------------------------
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=1311532&id_secret=78979542-3cb7f1
Powered by Listbox: http://www.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David MacQuigg wrote:
> One other surprise I just noticed. Google's Received-SPF header is
> *below* their Received header!
> [...]
> 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).

For the record, section 7 of RFC 4408 explicitly also recommends that the
R-SPF: header field be prepended _above_ the corresponding Received:
field:

| The Received-SPF header field is a trace field (see RFC 2822 Section
| 3.6.7) and SHOULD be prepended to the existing header, above the
| Received: field that is generated by the SMTP receiver.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHbqlBwL7PKlBZWjsRAqdgAJ47eJN2FetQ+bWUO7T1Mwql7968VACgkjyj
gF1gXfr15esj2535xvrc02M=
=gO5N
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311532&id_secret=78981043-023a60
Powered by Listbox: http://www.listbox.com

At 06:30 PM 12/23/2007 +0000, you wrote:
>David MacQuigg wrote:
>> One other surprise I just noticed. Google's Received-SPF header is
>> *below* their Received header!
>> [...]
>> 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).
>
>For the record, section 7 of RFC 4408 explicitly also recommends that the
>R-SPF: header field be prepended _above_ the corresponding Received:
>field:
>
>| The Received-SPF header field is a trace field (see RFC 2822 Section
>| 3.6.7) and SHOULD be prepended to the existing header, above the
>| Received: field that is generated by the SMTP receiver.

Our Border Patrol MTA is now in compliance. Looks like Google is not.

-- Dave

-------------------------------------------
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=1311532&id_secret=78983437-a75fd2
Powered by Listbox: http://www.listbox.com