spf-discuss
[Top] [All Lists]

Re: RE: rr.com and SPF records

2005-03-16 12:13:32


Radu Hociung wrote:
Hello Todd,

Todd Herr wrote:

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.


Julian is correct; I ran a summary here for the other sources you mentioned:

Domain               |Queries min-max|  TXT  | PTR   |   A   |  MX   |
austin.rr.com        |     02-09     | 01-01 | 00-00 | 00-06 | 00-01 |
houston.rr.com       |     02-09     | 01-01 | 00-00 | 00-06 | 00-01 |
texas.rr.com         |     01-08     | 00-00 | 00-00 | 00-06 | 00-01 |
va.rr.com            |     02-05     | 01-01 | 00-00 | 00-02 | 00-01 |
rr.com               |     02-76     | 01-09 | 00-00 | 00-56 | 00-10 |


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.


The trouble with a very expensive SPF record @rr.com is that mail that is forged to appear from rr.com is very expensive to resolve. The recipient of the forged piece has to do all the lookups in order to come to the conclusion the mail may not even be legitimate.

rr.com takes 76 lookups to resolve as 'softfail'. This may land your domain on blacklists as it really looks like a DoS attempt. Depending on individual mail admins, it may mean that as long as rr.com is blacklisted, the subdomains should be blacklisted as well. I think this is a very likely scenario, and would introduce needless headaches for you.

If you need to publish the full list of mail sources, I would not do it as an SPF-resolvable record, but some other way. Perhaps provide a exp= (explanation message) that points to your own why.html web-page, and put the list of IPs there.

I forgot to mention this, and I believe it's worthwhile:

The other problem with the expensive record at rr.com is that if some employees do wish to use their rr.com address, their mail will likely not get through to domains that check SPF records, if those recepients enforce a limit on their DNS lookups by returning "PermFail: Too many DNS lookups".

In effect this means that @rr.com cannot be used to send reliable email.

Regards,
Radu.