RE: Standard Authentication Query

At 02:42 PM 3/29/2005 -0500, Todd wrote:

> On Tue, 29 Mar 2005, at 12:25, David MacQuigg wrote:
>
> > I can even see a large ISP clustering all their servers so their SPF record
> > might be nothing but a few masks.  As long as spammers can't get access to
> > the addresses within the mask blocks, the masks alone are good enough.
> >
> > A typical top record might look like this one for rr.com:
> > v=spf1
> > 
> m=24.30.203/24,24.28.200/24,24.28.204/24,24.30.218/24,24.93.47/24,24.25.9/24,
> > 65.24.5/24,24.94.166/24,24.29.109/24,66.75.162/24,24.24.2/24,65.32.5/24 ...
> > -all
> > The ... redirects and such might never be needed if rr.com decides it can
> > clean out the zombies in each of those /24 blocks.
>
> Our servers already _are_ clustered in the /24s we list; we list so
> many /24s because we have our servers located in nine different
> geographically dispersed data centers stretching from New York to
> California, and the rules of the game as they apply to routing and
> so forth do not allow us to put all nine data centers into that
> many fewer /24s than what we have listed.  The first four /24s
> listed above are all in one geographic location, but in-house
> political reasons do not allow them to be collapsed into one
> /24.
>
> The /24s in our SPF record are reserved for data center usage;
> servers, network gear, etc.  No customers are put in those /24s.
> The zombies that are on our network are not in the /24s listed in
> our SPF record.  Zombies that are configured to route their spew
> from the infected host through the smarthost configured on the
> infected host's mail client will be rate limited, as a matter of
> policy, to 1,000 messages per day.
This is good policy.  Do you have any numbers on how well it is 
working?  AOL claims to have *no* outgoing spam.  I checked their claim 
with a sample of reports from SpamCop, and it looks good.  See my chart 
Domain Ratings at http://purl.net/net/edatools/email  It looks like AOL is 
100X better than Charter or Sprint.  Unfortunately, I can't bug my contact 
for any more data, and I don't know how to extract it from any public 
reports.  This is a very small sample, and I'm not even sure if the 
"methodology" is correct.  Seems like SpamCop can't make any distinction 
between an authorized sending IP and one which is merely in your address 
space.  If we are going to promote SPF as having a benefit to email 
*senders*, we need to not ding them for anything other than the spam coming 
from their authorized servers.
> Note too that our SPF record currently ends in ~all, not the -all
> you listed here.  Unless and until our AUP changes (and there's
> no promise that it ever will), our SPF record will likely never
> end in -all.  We have customers who wish to run their own mail
> servers in our residential space, and some of them even send
> email from their $foo.rr.com addresses; we currently allow this
> practice and make no promises that we will ever change this.
If the /24 blocks above are *exclusively* for your own servers, and 
*cannot* contain a customer IP, then there should be no problem with 
zombie-generated spam spoiling the reputation of rr.com.  As long as they 
can't hijack an authorized server, they can't claim to be sending on behalf 
of rr.com (at least to anyone who bothers to check your SPF record).
One thing that isn't clear to me, and perhaps someone else can comment, 
what happens if the spammer has an IP assigned by rr.com AND a *subdomain* 
from rr.com?  My guess is the subdomain will inherit the reputation of 
rr.com, and will also have the opportunity to ruin it.  It seems like 
rr.com would be wise to put these residential mail servers under a 
different name, maybe rrhome.com, or if they are a serious business, have 
them use their own name.
-- Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *