At 01:04 AM 12/22/2007 +0000, you wrote:
>WebMaster@commerco.net wrote:
>> Getting back to the original point of the thread, why Google
>> apparently wants folks to specify "~all" rather than "-all", perhaps
>> in their case (because they offer a huge email service), they don't
>> wish to reveal all the possible outgoing SMTP servers to avoid some
>> type of attack on GMail. Personally, I think there are better ways
>> of handling such things even in huge scale email service environments.
>
>An interesting theory of yours, but I think if that was their motivation,
>they would have been bright enough to use an "exists:" mechanism to hide
>their infrastructure. :-)
Actually, I was only half joking in my last post. While there may be some "propaganda" motivation in these huge SPF records we see from some large companies, I don't think Google is playing that game. They want to avoid abuse of their servers, but they don't want to make it difficult for new users to sign up for their email service. Putting restrictions on new accounts, like rate-limits which would discourage spammers, is not something they are willing to do. The only thing they require for a new account is a "word verification", i.e. being able to type the word you see on their signup screen.
Originally, their SPF record showed: 'v=spf1 ptr ?all', which had the effect of authorizing all of their netblocks. That resulted in a huge amount of spam from their authorized servers. Sending them spam reports would only get an automated denial - "someone is forging our name". Following up with "No its not a forgery. It came from a server authorized by the PTR method you specified." got only a discussion with a robot whose job was apparently to sandbag complaints. Twice we had to take google.com off our whitelist, and they have remained in that status since July 07. A check of our recent log files shows we are still getting lots of spam from their servers.
I see now they have changed their SPF record from ptr to an explicit list of netblocks. 9 blocks totaling 147456 IP addresses is still way too much, but we need to encourage them in this effort. If I were Google, and really wanting to be a good citizen, I would authorize maybe 8 blocks of 8 addresses each to say HELO this is google.com. This should be more than enough for a worldwide network of well-connected servers. Then I would move the new accounts to a different HELO name, limit the new accounts to maybe 100 recipients per day, and watch for patterns of abuse. After a few weeks of normal use, a new account could be migrated to one of the regular servers.
Google, are you listening?
-- Dave
************************************************************ *
* David MacQuigg, PhD email: macquigg at open-mail.org * *
* President, Open-Mail dot org phone: USA 520-721-4583 * * *
* Postmaster, Box67 dot com * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
************************************************************ *
-------------------------------------------
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=78780266-1a1ea7
Powered by Listbox: http://www.listbox.com
>WebMaster@commerco.net wrote:
>> Getting back to the original point of the thread, why Google
>> apparently wants folks to specify "~all" rather than "-all", perhaps
>> in their case (because they offer a huge email service), they don't
>> wish to reveal all the possible outgoing SMTP servers to avoid some
>> type of attack on GMail. Personally, I think there are better ways
>> of handling such things even in huge scale email service environments.
>
>An interesting theory of yours, but I think if that was their motivation,
>they would have been bright enough to use an "exists:" mechanism to hide
>their infrastructure. :-)
Actually, I was only half joking in my last post. While there may be some "propaganda" motivation in these huge SPF records we see from some large companies, I don't think Google is playing that game. They want to avoid abuse of their servers, but they don't want to make it difficult for new users to sign up for their email service. Putting restrictions on new accounts, like rate-limits which would discourage spammers, is not something they are willing to do. The only thing they require for a new account is a "word verification", i.e. being able to type the word you see on their signup screen.
Originally, their SPF record showed: 'v=spf1 ptr ?all', which had the effect of authorizing all of their netblocks. That resulted in a huge amount of spam from their authorized servers. Sending them spam reports would only get an automated denial - "someone is forging our name". Following up with "No its not a forgery. It came from a server authorized by the PTR method you specified." got only a discussion with a robot whose job was apparently to sandbag complaints. Twice we had to take google.com off our whitelist, and they have remained in that status since July 07. A check of our recent log files shows we are still getting lots of spam from their servers.
I see now they have changed their SPF record from ptr to an explicit list of netblocks. 9 blocks totaling 147456 IP addresses is still way too much, but we need to encourage them in this effort. If I were Google, and really wanting to be a good citizen, I would authorize maybe 8 blocks of 8 addresses each to say HELO this is google.com. This should be more than enough for a worldwide network of well-connected servers. Then I would move the new accounts to a different HELO name, limit the new accounts to maybe 100 recipients per day, and watch for patterns of abuse. After a few weeks of normal use, a new account could be migrated to one of the regular servers.
Google, are you listening?
-- Dave
************************************************************ *
* David MacQuigg, PhD email: macquigg at open-mail.org * *
* President, Open-Mail dot org phone: USA 520-721-4583 * * *
* Postmaster, Box67 dot com * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
************************************************************ *
-------------------------------------------
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=78780266-1a1ea7
Powered by Listbox: http://www.listbox.com