[cobalt-users] Fw: Why (anti-spam) SPF rocks

["Franklin S Werren" <fswerren@xxxxxxxxxxxx>]

Hi All;

This SPF is being harpped real LOUD at
news://news.grc.com   in there grc.spam
As you know Steve Gibson of www.grc.com is a real vocal
about different ideas... and usually he is right...

No one said much except they do not think it will fly
and it was not a good idea....
But with spam growing out of control
I have to look at all possibilities....
Even Microsoft (No Flames) is getting in on the act

Franklin S. Werren  www.bagpipes.net   www.chautauqualake.net
www.franksradio.net http://stvef.chautauqualake.net
http://rtcw.chautauqualake.net

----- Original Message ----- 
From: "Steve Gibson" <support@xxxxxxx>
Newsgroups: grc.news,grc.spam
Sent: Monday, March 01, 2004 12:34 PM
Subject: Why (anti-spam) SPF rocks


> Everyone,
> 
> My last post to grc.news here talked about Microsoft's patented 
> "eMail CallerID" scheme.  The fact that Microsoft's scheme is 
> patent-encumbered (though presumably only to be defensive and 
> prevent abuse), is needlessly bloated by the use of a complex 
> XML schema, and doesn't offer anything more than the already 
> existing SPF (Sender Policy Framework see http://spf.pobox.com) 
> caused me to look much more closely at SPF.
> 
> What SPF does:
> 
> Simply stated, SPF is a minimal and simple system to allow valid 
> domains, like aol.com or grc.com, to publish the IP addresses of 
> their servers from which eMail from their domains may originate.
> 
> We already know that the source IP of TCP connections can not be 
> spoofed, since IP packets must make round-trips between valid IP 
> endpoints in order to "connect".  This means that when remote 
> eMail server 'A' connects to server 'B' in order to transfer 
> some eMail to it, the receiving server 'B' knows the connection 
> IP address of the sending server 'A'.
> 
> With the addition of the simple SPF specification, the receiving 
> server 'B' can make a standard DNS TXT query of the domain from 
> which server 'A' claims to be sending eMail and receive a list 
> of the domains "official" machines and IP addresses which are 
> valid originators of eMail for that domain.  Receiving server 
> 'B' can then check to see whether the TCP connection IP is 
> within those which are valid for this domain and take whatever 
> action it chooses.
> 
> There are many variations and complications to a mature 
> implementation of this system, you can see a diagram here:
> http://www.libspf.org/images/mailflows-l.png
> 
> As of the posting of this note, at least 8,076 domains are 
> participating in this system, grc.com among them, and the 
> numbers are growing rapidly.
> 
> Aol.com was an early adopter of SPF.  So this means that as soon 
> as MY server -- for example -- has been updated to query for a 
> remote domain's SPF records, we would be able to detect and drop 
> any SPAM being spoofed as originating from AOL, when in fact it 
> is coming from non-AOL servers.  And similarly, since we are now 
> publishing SPF data for grc.com, any SPF-aware servers which 
> receive eMail ostensibly from grc.com will be able to verify 
> whether that eMail originated from our server.
> 
> SPF is not a total cure-all for the SPAM problem, but it's 
> inexpensive and trivial to implement. By providing a simple and 
> lightweight means for authenticating the remote IPs of 
> connecting eMail servers, it will probably quickly grow to 
> become another tool in the fight against SPAM.
> 
> It's not difficult to imagine a day in the near future, once SPF 
> adoption is widespread, where eMail servers may refuse to accept 
> any eMail from non-SPF publishing domains.
> 
> Here's another page of interesting info ...
> http://spftools.infinitepenguins.net/register.php
> 
> -- 
> ______________________________________________________________
> Steve Gibson,                    at work on: < SpinRite v6.0 >