Mailing List Archive

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>

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

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

> Frank, can you please update your "Google" page on the SPF
> website?

Yeah, later, I'll replace my reject example by your evidence in
<http://permalink.gmane.org/gmane.mail.spam.spf.discuss/23733>.

> I think we can rename the page to "Google SPF implementation"
> or "Google and SPF" or something. Where on the website do you
> want to link it from?

No idea, just move it to an "ordinary" page, maybe below FAQ ?

Frank

-------------------------------------------
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=79840683-b9d11e
Powered by Listbox: http://www.listbox.com

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

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.

Maybe we could post this data on Greg HewGill's http://spf-all.com.

-- 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=79859033-0a23bb
Powered by Listbox: http://www.listbox.com

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

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.

It seems you got me wrong (perhaps because I worded badly). If the
sending IP address is a dynamically allocated one, they still do reject,
even it's an SPF Fail. What I was trying to say is that an SPF Fail in
itself will never be the cause for a rejection by GMail.

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

I don't think they weight SPF Fails all too negatively. They rather use
SPF Pass for their internal reputation system:

"Sender Reputation in a Large Webmail Service"
http://www.ceas.cc/2006/19.pdf

> > Frank, can you please update your "Google" page on the SPF website?
>
> Yeah, later, I'll replace my reject example by your evidence in
> <http://permalink.gmane.org/gmane.mail.spam.spf.discuss/23733>.

I'd rather just say that "GMail does not reject on SPF Fail but uses it in
their spam decision". Something like that. Forget the evidence -- given
the facts, it's of little interest.

> > I think we can rename the page to "Google SPF implementation" or
> > "Google and SPF" or something. Where on the website do you want to
> > link it from?
>
> No idea, just move it to an "ordinary" page, maybe below FAQ ?

"Moving it to an ordinary page" -- that's what I meant. OK, let's make it
a FAQ entry. "FAQ/Google and SPF"?

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

iD8DBQFHdOA0wL7PKlBZWjsRAq10AJwMvYpgZYM7M3Yt9pQ9Ruqc8l4UOgCgxK3x
TYaeW83cvRo8XSuujxOVynw=
=Pn8H
-----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=79864292-6f954b
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Frank Ellermann wrote:
>
>> Julian Mehnle wrote:
>>
> <snip>
>>> Frank, can you please update your "Google" page on the SPF website?
>>>
>> Yeah, later, I'll replace my reject example by your evidence in
>> <http://permalink.gmane.org/gmane.mail.spam.spf.discuss/23733>.
>>
>
> I'd rather just say that "GMail does not reject on SPF Fail but uses it in
> their spam decision". Something like that. Forget the evidence -- given
> the facts, it's of little interest.
>
No, please don't "forget the evidence". Leave it there, somewhere,
perhaps a link to the detail evidence on a separate page to reduce
clutter. But things can change, and so the claim based on current
evidence must be documented as substantiated because after all systems
are subject to change without notice.

Terry

<snip>

-------------------------------------------
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=79868823-2479a4
Powered by Listbox: http://www.listbox.com

On Fri, 2007-12-28 at 03:43 -0700, 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>
> >
> >> 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.
>
> 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.
>
> Maybe we could post this data on Greg HewGill's http://spf-all.com.
>
How can I post data to spf-all.com

-------------------------------------------
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=79870138-45b46d
Powered by Listbox: http://www.listbox.com

On Fri, Dec 28, 2007 at 03:43:57AM -0700, David MacQuigg wrote:
> At 06:18 AM 12/28/2007 +0100, Frank Ellermann wrote:
> >Julian Mehnle wrote:
> >
> >> 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.

If that means saving your POP3 password at gmail.com, then this is
exactly what we do NOT want here. Yet another reason to support
traditional forwarding, at least here.

--

Steven F. Siirila Office: Univ Park Plaza, Room 750
Internet Services E-mail: sfs@umn.edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593

-------------------------------------------
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=79937439-db9ba9
Powered by Listbox: http://www.listbox.com

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

Terry Fielder wrote:
> Julian Mehnle wrote:
> > I'd rather just say that "GMail does not reject on SPF Fail but uses
> > it in their spam decision". Something like that. Forget the
> > evidence -- given the facts, it's of little interest.
>
> No, please don't "forget the evidence". Leave it there, somewhere,
> perhaps a link to the detail evidence on a separate page to reduce
> clutter. But things can change, and so the claim based on current
> evidence must be documented as substantiated because after all systems
> are subject to change without notice.

The thing is, the current "claim" isn't based on empirical evidence such
as a few SMTP transactions. It's based on a statement by an authorita-
tive source within Google. Proving through empirical evidence that GMail
never rejects due to SPF Fail is equally as difficult as is proving
through empirical evidence that the Flying Spaghetti Monster doesn't
exist. That's why I decided to ask the GMail people in the first place.

More importantly though, do we really want to create a list of case
studies for all the big ESPs out there including detailed evidence for
their SPF-related behavior? If not, why do so for Google/GMail?

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

iD8DBQFHdRhBwL7PKlBZWjsRAjYUAJ4yEwool+M7pQrz98yBWSqZ6inNeQCeJqed
UCScrJjFkw036FvwZIOYZGg=
=2cQX
-----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=79941285-fe291b
Powered by Listbox: http://www.listbox.com

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

Steven F Siirila wrote:
> On Fri, Dec 28, 2007 at 03:43:57AM -0700, David MacQuigg wrote:
> > At 06:18 AM 12/28/2007 +0100, Frank Ellermann wrote:
> > > 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.
>
> If that means saving your POP3 password at gmail.com, then this is
> exactly what we do NOT want here. Yet another reason to support
> traditional forwarding, at least here.

Just for the record: If the alternative is forwarding all your mail from
your other account to GMail, then they're already getting all the
information behind your password! So where's the problem with giving
them your POP3 password so they can fetch your mail actively?

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

iD8DBQFHdRjTwL7PKlBZWjsRAgg6AJwJMygfAfXIALwqIDxwBkgfqpKgwQCg08Xn
6dWujD6MsMB/iH3sLwGj5aU=
=460G
-----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=79941551-df132e
Powered by Listbox: http://www.listbox.com

On Fri, Dec 28, 2007 at 03:40:03PM +0000, Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Steven F Siirila wrote:
> > On Fri, Dec 28, 2007 at 03:43:57AM -0700, David MacQuigg wrote:
> > > At 06:18 AM 12/28/2007 +0100, Frank Ellermann wrote:
> > > > 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.
> >
> > If that means saving your POP3 password at gmail.com, then this is
> > exactly what we do NOT want here. Yet another reason to support
> > traditional forwarding, at least here.
>
> Just for the record: If the alternative is forwarding all your mail from
> your other account to GMail, then they're already getting all the
> information behind your password! So where's the problem with giving
> them your POP3 password so they can fetch your mail actively?

Two assumptions are being made here. First, that ALL mail is being forwarded.
Second, that the account being forwarded is ONLY used for e-mail.

--

Steven F. Siirila Office: Univ Park Plaza, Room 750
Internet Services E-mail: sfs@umn.edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593

-------------------------------------------
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=79946349-0fe400
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Terry Fielder wrote:
>
>> Julian Mehnle wrote:
>>
>>> I'd rather just say that "GMail does not reject on SPF Fail but uses
>>> it in their spam decision". Something like that. Forget the
>>> evidence -- given the facts, it's of little interest.
>>>
>> No, please don't "forget the evidence". Leave it there, somewhere,
>> perhaps a link to the detail evidence on a separate page to reduce
>> clutter. But things can change, and so the claim based on current
>> evidence must be documented as substantiated because after all systems
>> are subject to change without notice.
>>
>
> The thing is, the current "claim" isn't based on empirical evidence such
> as a few SMTP transactions. It's based on a statement by an authorita-
> tive source within Google.
Isn't that the evidence necessary to justify the claim?
> Proving through empirical evidence that GMail
> never rejects due to SPF Fail is equally as difficult as is proving
> through empirical evidence that the Flying Spaghetti Monster doesn't
> exist.
True enough.
> That's why I decided to ask the GMail people in the first place.
>
Fair enough.
> More importantly though, do we really want to create a list of case
> studies for all the big ESPs out there including detailed evidence for
> their SPF-related behavior? If not, why do so for Google/GMail?
>
Right. I stand corrected.

Although I still feel nervous about unsubstantiated claims being used of
context in "troll" like discussions. Not that evidence stops mis-usage,
it just gives a person a leg to stand on to refute the mis-usage.

Terry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHdRhBwL7PKlBZWjsRAjYUAJ4yEwool+M7pQrz98yBWSqZ6inNeQCeJqed
> UCScrJjFkw036FvwZIOYZGg=
> =2cQX
> -----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/?&
> Powered by Listbox: http://www.listbox.com
>
>

-------------------------------------------
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=80017881-6ad302
Powered by Listbox: http://www.listbox.com

Steven F Siirila wrote:

> Two assumptions are being made here. First, that ALL mail is
> being forwarded.

Yes, POP3 polling vs. forwarding is "pull" instead of "push",
it also avoids the SPF problem with "traditional forwarding".

When the "forwarder" is actually a "redistributor" rewriting
the envelope sender address, then POP3 "pull" has no advantage.

> Second, that the account being forwarded is ONLY used for
> e-mail.

Otherwise giving your password to a 3rd party would be a bad
idea, sure. E.g. for T-online (a division of T-Com) giving
your password away would violate their AUP - and likely it
won't work, their normal POP3 accounts can be used only when
you're logged into their network: T-Online is an ISP, not
only an e-mail provider.

Frank

-------------------------------------------
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=80036398-c65831
Powered by Listbox: http://www.listbox.com

Julian Mehnle wrote:

> the current "claim" isn't based on empirical evidence such as
> a few SMTP transactions.

Your header showing an accepted FAIL with correct SPF-Received
and Authentication-Results is as good as my old "reject" log.

> do we really want to create a list of case studies for all
> the big ESPs out there including detailed evidence for their
> SPF-related behavior? If not, why do so for Google/GMail?

Google attracted my attention when they "forged" my SPF FAIL
protected @xyzzy address associated with my Google account
(before I had a Gmail address) in a mail to GMX, where it was
immediately rejected (GMX rejects SPF FAIL when you want it).

It ended up as bounce in my @xyzzy catch-all mailbox, no harm
done, and I signed up for a Gmail address to avoid this issue.

After that experience I tried to figure out what they actually
do with SPF, as a generally interesting non-trivial example.
Not as "SPF showcase" of course, that would be GMX.

Frank

-------------------------------------------
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=80039224-bc3aca
Powered by Listbox: http://www.listbox.com

On Fri, 28 Dec 2007, Frank Ellermann wrote:

> it also avoids the SPF problem with "traditional forwarding".

There are *no* SPF problems caused by "traditional forwarding".
True, correctly checking SPF requires taking any such forwarders
into account since they become mail gateways for the recipient domain - and
this is more difficult for a large ESP, since it involves getting accurate info
on the forwarders from millions of users who have likely forgotten that they
ever requested forwarding. This is why large ESPs like gmail tend to punt and
not reject outright on FAIL.

However, I and countless other small domain owners reject on FAIL
with zero false positives. Why? Because we don't use traditional
forwarders. Or, as in my case, we do have a few, but simply
list them in our SPF config. There is simply no problem other than
the usual problem of getting non technical users to configure stuff
correctly - and that is not a specifically SPF problem.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
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=80083103-4ba09b
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:

>> it also avoids the SPF problem with "traditional forwarding".
> There are *no* SPF problems caused by "traditional forwarding".

We likely agree, but JFTR I really consider *accepting* SPF FAIL
as dangerous. Most of the time this will be spam with a forged
envelope sender address, users might put it in an (unread) spam
folder where it's automatically purged after say 30 days. They
could miss SPF FAIL "false positives" caused by their unilateral
forwarding arrangements. Neither the admin of the forwarder nor
the admin of the next hop at a 3rd party (in this example Gmail)
necessarily know what's going on. And unlike rejecting SPF FAIL
accepting SPF FAIL can go wrong (legit mail rots in spam folder
until purged).

> more difficult for a large ESP, since it involves getting
> accurate info on the forwarders from millions of users who
> have likely forgotten that they ever requested forwarding.

Exactly...

> This is why large ESPs like gmail tend to punt and not reject
> outright on FAIL.

...with the worse outcome for clueless users, as explained above.

Unlike the senders, who are supposed to know what SPF FAIL is,
these receivers are IMO entitled to be clueless. Accepting FAIL
is the contrary of helpful in "clueless forwarding" scenarios.

> There is simply no problem other than the usual problem of
> getting non technical users to configure stuff correctly - and
> that is not a specifically SPF problem.

ACK. In the case of Gmail "use POP3 polling if you can" is the
best solution. Did you ever read Google FAQs (outside of their
various "API" topics for developers) ? They always limit their
answers to a text fitting on a postcard using very simple words.

Frank

-------------------------------------------
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=80102178-5e9551
Powered by Listbox: http://www.listbox.com

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