RFC Errata
RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014
Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616
Source of RFC: spfbis (app)
Errata ID: 5227
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Garfield
Date Reported: 2018-01-04
Section 5.5 says:
The <ip>'s name is looked up using this procedure: o Perform a DNS reverse-mapping for <ip>: Look up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 address and in "ip6.arpa." if it is an IPv6 address. o For each record returned, validate the domain name by looking up its IP addresses. To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied. If they are exceeded, processing is terminated and the mechanism does not match. o If <ip> is among the returned IP addresses, then that domain name is validated. Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match. 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. This mechanism matches if o the <target-name> is a subdomain of a validated domain name, or o the <target-name> and a validated domain name are the same. For example, "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not.
It should say:
The <ip>'s name is looked up using this procedure: o Perform a DNS reverse-mapping for <ip>: Look up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 address and in "ip6.arpa." if it is an IPv6 address. Check all domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain. If any do, this domain name can be validated. If no domain name can be found, or if none of the domain names match or are a subdomain of the <target-name>, this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. This mechanism may match if o the <target-name> is a subdomain of a domain name, or o the <target-name> and a domain name are the same. For example, "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. The domain names received must also be validated for the mechanism to match. o For each matched record, validate the domain name by looking up its IP addresses. To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied. If they are exceeded, processing is terminated and the mechanism does not match. o If <ip> is among the returned IP addresses, then that domain name is validated. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues. The mechanism matches if a domain name is found that properly matches the target name and can be properly validated. While these tests can be done in either order, performing the match before validating prevents needless DNS queries being performed.
Notes:
As specified, the RFC calls for all names to be validated, even those that can be immediately discarded because they do not match. The RFC should call for the local-only operation to be done first. While it may be argued that the RFC doesn't require the order, implementers shouldn't be misled.
My corrected text probably needs editorial work.
I have not fixed errata 4751 in my corrected text.