On Wed, 16 Mar 2005, at 17:46, Julian Mehnle wrote:
Hello Todd.
Todd Herr wrote:
My name is Todd Herr, and I'm the Postmaster for Road Runner
(rr.com). I'm also the person responsible for our SPF records.
Good to hear from you! :-)
Hello, everyone. Allow me to fill in some context here to make
sense of what Julian has posted to the list.
The "DNS lookup limit?" thread regarding Road Runner's recently
published SPF records was brought to my attention, and I
wanted to clarify one point of the discussion; I contacted
Julian and Radu directly regarding the exchange below:
(I am referring to the thread displayed at this URL:
http://www.gossamer-threads.com/lists/spf/discuss/17934
)
Radu wrote:
>>For a domain that needs this much mail infrastructure,
>>there are a few easy ways to reduce the DNS load:
>>
>>1. implement a real-time DNS lookup table that can be
>>accessed with the exists:%{ir}.mailhosts.rr.com for
>>instance.
>>
>>2. add a single "A" record that resolves to a long list
>>of IPs.
>>
>>3. Use includes and specify the mail servers by IP
>>address, the way hotmail is doing it.
>
Julian wrote:
>
> There is a 4th option I'd like to add:
>
> 4. Use subsidiary domains (florida.rr.com, etc.)
> _directly_ in sender addresses, so the main rr.com
> domain isn't responsible for _all_ sending MTAs.
Radu wrote:
On the envelope sender only, I assume? It would be hard
otherwise to get all of RoadRunner's customers to change
their email address.
So the headers would still be username(_at_)rr(_dot_)com, while the
envelope would be username(_at_)florida(_dot_)rr(_dot_)com
In point of fact, we already implement option #4. No Road Runner
customer has an email address that ends in @rr.com, and only a
few employees (myself included) do. As far as I know, those
employees never send email using their @rr.com address; it's a
legacy leftover for some of the older hands here. Employee email
comes from the @va.rr.com domain.
The reason for the rr.com SPF looking like it does has at its
roots our current de-centralized management of our DNS namespace
(and other customer support services and servers, including
mail). Road Runner has nine data centers scattered throughout
the United States, and each one supports email and DNS for a
subset of all of our customers. We have constructed our SPF
records so that each of these data centers only has to manage one
TXT record; the local customer domains are nothing but redirects,
as shown in the following example:
# dig +sho houston.rr.com txt
"v=spf1 redirect=texas.rr.com"
# dig +sho austin.rr.com txt
"v=spf1 redirect=texas.rr.com"
# dig +sho satx.rr.com txt
"v=spf1 redirect=texas.rr.com"
# dig +sho texas.rr.com txt
"v=spf1 ip4:24.93.47.0/24 ip4:24.28.204.15 ip4:24.28.204.16 +mx ~all"
Given that our customer email addresses would be in the
houston.rr.com, or austin.rr.com, or satx.rr.com domains, do our
SPF records meet the fewer than 10 DNS mechanism guidelines
here?
For example:
| $ dig +sho houston.rr.com TXT
| "v=spf1 redirect=texas.rr.com"
| $ dig +sho texas.rr.com TXT
| "v=spf1 ip4:24.93.47.0/24 ip4:24.28.204.15 ip4:24.28.204.16 +mx ~all"
| $ dig +sho texas.rr.com MX
| 20 orngca-02.mgw.rr.com.
| 30 hrndva-01.mgw.rr.com.
| 30 hrndva-02.mgw.rr.com.
| 10 austtx-01.mgw.rr.com.
| 10 austtx-02.mgw.rr.com.
| 20 orngca-01.mgw.rr.com.
So evaluating the sender policy for houston.rr.com involves at maximum 2
mechanisms/modifiers (one "redirect" and one "mx"), and at maximum 6 MX
lookups for the "mx" mechanism. So, yes, this is well within the limits.
Our rr.com SPF record exists primarily, in my opinion, to give
us a standards-based way to answer the not-infrequent question
we receive from other ISPs. That question is, "Can you tell
me where your outbound mail servers are, so that we may
whitelist them?". Being able to point to the SPF record for
rr.com gives us a way to communicate that information in a way
that most ISPs should understand, we believe.
Agreed, this is not a bad idea. But note that SPF implementations might
have problems evaluating the sender policy for rr.com as this would exceed
the limits. As a result, the highly complex sender policy of rr.com
should not be relied on when sending mail directly from rr.com.
That is, you should not send mail directly from rr.com as long as its
sender policy is as complex as it currently is. Or at least, you should
expect SPF checks to fail due to security limits when doing so.
Sorry for the excessive quoting; wanted to make sure everything
was presented in full context.
--
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