On Tue, 29 Mar 2005, at 16:12, David MacQuigg wrote:
At 02:42 PM 3/29/2005 -0500, Todd wrote:
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
We make no such claims; we have outgoing spam, and neither SPF
nor any of the competing technologies will solve that problem
for us.
[snip]
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).
The likelihood of any legitimate mail with a sender whose address
ends in @rr.com approaches zero so rapidly as to almost be
non-existent, regardless of the SPF record we publish. We have
seized upon SPF as a standards-based framework for providing the
answer to the human-to-human question that we sometimes receive,
mostly from other ISPs; mainly, "Tell us where your outbound
servers are so that we may identify traffic from them as opposed
to the rest of your space". The naming schemes we have used for
our servers, and the domains in which the PTR records for their
IP addresses reside, have caused some confusion over the years
with those who maintain lists of dynamic space, and some of our
servers have been incorrectly listed as being in dynamic space
from time to time. SPF gives us an easy way to address this
problem in a language that is easily understood, and provides us
a way to provide the answer to anyone who wants it, so long as
they have the ability to issue a simple DNS query.
All that aside, the ~all bit in our SPF record means "SPF
Neutral", as I understand it. This means, as I understand
things, that Road Runner neither confirms nor denies that a
given IP not explicitly mentioned in our SPF record can be a
legitimate source of mail from Road Runner. The receiving
domain doing the SPF checking can either accept or reject email
from an IP not explicitly mentioned in our SPF record, and both
decisions would be correct, as I understand things.
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.
I'm not clear on what you mean when you say, "what happens if the
spammer has an IP assigned by rr.com AND a *subdomain* from
rr.com?". In lieu of my understanding what you mean, and given
that Road Runner's reputation in the anti-spam community is mixed
at best, let me describe the reality of the Road Runner customer
and DNS names associated therewith.
Any customer IP assigned by Road Runner in our residential space
will soon have a PTR record ending in 'res.rr.com'; we're
transitioning all of our residential space to this naming scheme,
and expect to be finished shortly.
What this means is that Joe, a Road Runner customer of the
Milwaukee, WI, Time Warner Cable division, who has IP address
69.76.120.59, will have the following information "associated"
with him:
email address: joe(_at_)wi(_dot_)rr(_dot_)com
PTR record for cable modem: CPE-69-76-120-59.wi.res.rr.com
(Prior to the res.rr.com migration, Joe's IP address would've had
a PTR record of CPE-69-76-120-59.wi.rr.com.)
We do not provide non-default names for residential customers.
No customer will ever have an email address ending in
'res.rr.com'.
The only subdomains of rr.com are names used to indicate either a
Time Warner Cable division or some other Road Runner-specific
indicator; there is no possibility of a name such as
"joesgarage.rr.com" existing, ever.
Business Class customers are given IP addresses whose default PTR
records resolve to one of the following eight patterns, assuming
IP address A.B.C.D:
rrcs-A-B-C-D.central.biz.rr.com
rrcs-A-B-C-D.ma.biz.rr.com
rrcs-A-B-C-D.midsouth.biz.rr.com
rrcs-A-B-C-D.nyc.biz.rr.com
rrcs-A-B-C-D.nys.biz.rr.com
rrcs-A-B-C-D.se.biz.rr.com
rrcs-A-B-C-D.sw.biz.rr.com
rrcs-A-B-C-D.west.biz.rr.com
For those Business Class customers who have their own domains and
wish to have non-default PTR records, we provide that service,
but again, the PTR record would not be "joesgarage.biz.rr.com";
rather, it would be "joesgarage.com", "www.joesgarage.com",
"mail.joesgarage.com", and the like.
Hopefully, that clears things up for you.
--
Todd Herr
Senior Security Policy Specialist/Postmaster V: 703.345.2447
Time Warner Cable IP Security M: 571.344.8619
therr(_at_)security(_dot_)rr(_dot_)com AIM:
RRCorpSecTH