Home / server / Questions / 1063826
In Process
glts
Asked: 2021-05-18 04:36:17 +0800 CST

What problems are there with the SPF ‘ptr’ mechanism?

  • 772

One of the mechanisms in SPF is ptr. This mechanism checks that a sender using some domain name connects from a (forward-confirmed) IP address pointing to a subdomain of that name.

For example, when sender [email protected] connects from IP address 1.2.3.4, then the ptr mechanism would first do a reverse lookup on 1.2.3.4. If the domain name returned by that lookup (eg mail.example.com) also has IP address 1.2.3.4, and is a subdomain of example.com, then the sender is authorised.

This seems like a useful feature. At the time of writing, the domain yahoo.com uses this mechanism in its SPF records.

However, the SPF specification explicitly discourages using the ptr mechanism (‘SHOULD NOT be published’ [= use may be acceptable in certain circumstances, but only after careful deliberation]). It gives the following explanation:

Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead.

This explanation seems rather fuzzy to me, or at least not strong enough to completely give up on this useful feature. Why is the mechanism ‘slow’ or ‘not reliable’, and how would it place a ‘large’ burden on name servers? Surely doing one additional DNS lookup in a mail server context cannot be a big issue?

Are there strong, practical reasons for not using ptr, or can it be justified using it despite the RFC text?

spf

2 Answers

  1. I would say that it is slow simply because it requires multiple lookups to process; first the PTR lookup based on the connecting IP address, then confirming that response by looking up A or AAAA for the name(s) you got in the PTR result to verify that it actually matches before using the PTR result to decide the SPF outcome.

    Keep in mind that SPF always boils down to specifying a list of allowed IP addresses that a recipient can use to judge whether the incoming mail is being delivered by a legitimate host, and as such the ideal SPF mechanisms are ip4/ip6.
    All the other mechanisms are just indirections that provides some degree of convenience for the SPF publisher at the cost of efficiency for the email recipient; hence why there is a limit of 10 lookups from these indirections to enforce some balance by limiting the cost for the recipient of verifying an incoming email.

    Note that the particular case of the ptr SPF mechanism is an indirection where the publisher of the SPF record does not even know what sequence of lookups they are asking the email recipient to perform (as the initial lookup is based on the connecting IP address!). This in my opinion makes it extra problematic both for speed and reliability.

    As for the burden on the .arpa nameservers, having a mechanism that induces more lookups as part of the mail delivery process would obviously increase it, but it's hard to judge how much of a problem that might be in practice compared to all the other reverse lookups made for other reasons.

    • 3

  2. Indeed, the mentioned problems with ptr seem negligible. I would say that they are unlikely to appear in a performance profile of a mail server setup.

    There is, however, one place where ptr has a distinct disadvantage compared to other mechanisms. Paragraph 5.5 of RFC 7208 says:

    If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues.

    Because of this, a record like the following may evaluate to fail = ‘explicitly not authorised!’ when a DNS error occurs:

    v=spf1 ptr -all

    Whereas for other mechanisms, the DNS error will be indicated with a tempfail result, allowing verification to be retried:

    v=spf1 mx -all

    This to me is the main issue with ptr: The result of such a record can be definitive negative authorisation even though the query just ran into some DNS timeout.

    Nevertheless, since the RFC requires (‘MUST’) that ptr be supported by compliant implementations, and that it only discourages using it (‘SHOULD NOT’), it is still the case that usage of ptr is possible, and may be acceptable once the tradeoffs have been considered.

    • 0