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.
|
|