Re: [spfbis] Updated charter - final review

[Hector Santos <[e-mail]>]

Douglas Otis wrote:

> Fortunately, a
> majority of large providers do not use SPF for message acceptance 
> because they do not wish to deal with complaints arising from 
> assumptions the SMTP Mail From parameter fully describes the path of a 
> message in conjunction with SPF records ending in "-all".

Did you ever consider they were not candidates to use SPF?

I always viewed SPF benefited private user domains, companies, of any 
size, institutions, etc, where there is less to no unknown variables 
in their networking.

But I think that is all depends on your definition for "Large 
Providers."  FaceBook.com and gmail.com can be viewed as "very large" 
Email Providers.  Facebook.com, I presume has a very large pool of 
outbound senders and it has a well defined network with a -ALL final 
result.

On the other hand, gmail.com with its ?ALL is a major overhead and 
resource "waster" - its completely useless for gmail.com to use 
UNKNOWN condition.  Nothing good comes from it:

    MATCH    - IP is on the GMAIL Network - Whoopie!
    NO MATCH - IP is not on the GMAIL NETWORK

In both cases, abuse can and still occurs but with the latter, its 
where major abuse would be with bad guys using gmail.com with a 
wasteful record, and worse, it is always two lookups for what is most 
likely a wasteful yield.

At least with Facebook.com, there is a measurable yield. Its 
protecting itself from any foreign abuse.

Recently, I got a smile when I saw my old employer Mobil Oil (now as 
Exxon Mobil) corporate domain has a HARD FAIL SPF Record!

Processes with hard failure detection mechanism is where the maximum 
benefit is found. A PASS or anything else still generally requires 
even more filter checks and even if you couple it with reputation or 
scoring,  it is still not deterministic unlike a hard fail.

Any system operation, large or small, that can not establish a well 
defined network was never really a candidate for SPF - I think we 
always knew that.


-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com