Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Douglas Otis <[e-mail]>]

Recommended text is as follows:

4.6.4.  DNS Lookup Limits

Was:
,--
SPF implementations MUST limit the total number of mechanisms and modifiers ("terms") that cause any DNS query to 10 during SPF evaluation.  Specifically, the "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier count against this collective limit.  The "all", "ip4", and "ip6" mechanisms do not count against this limit.  If this number is exceeded during a check, a "permerror" MUST be returned.  The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record evaluation has been completed.
'--

Change to:
,---
SPF does not directly limit the number of DNS lookup transactions.  Instead, the number of mechanisms and the modifier term "redirect" MUST be limited to no more than 10 instances within the evaluation process.  The mechanisms "ip4", "ip6", and "all" and the "exp" modifier are excluded from being counted in this instance limitation. If this instance limit is exceeded during the evaluation process, a "permerror" MUST be returned.
'---

5.  Mechanism Definitions

Was:
,--
Several mechanisms rely on information fetched from the DNS.  For these DNS queries, except where noted, if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism stops and the topmost check_host() returns "temperror".  If the server returns "domain does not exist" (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records.
‘---

Add:
,---
See the recommended limits on "void lookups" defined in Section 4.6.4. DNS Lookup Limits.
‘---

3.4.  Record Size

Was:

,---
Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name.  Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet.
‘---

Change to:
,---
Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name.  Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet DNS Message.
‘---

Add to:
11.5.3.  Macro Expansion
,---
It is not within SPF’s purview whether IPv6 or DNSSEC is being used.  IPv6 (RFC2460) increased the minimum MTU size to 1280 octets.  DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP fallback.  EDNS0 suggests an MTU increase between 1280 and 1410 octets offers a reasonable result starting from a request of 4096 octets.  A 1410 MTU offers a 2.4 times payload increase over the assumed MTU of 576 octets and is widely supported by Customer Premise Equipment.  With increased MTUs being used with DNS over UDP, network amplification concerns increase accordingly.

SPF macros can utilize SPF parameters derived from email messages that can modulate the names being queried in several ways without publishing additional DNS resources.  The SPF macro feature permits malefactors a means to covertly orchestrate directed DDoS attacks from an array of compromised systems while expending little of their own resources.

Since SPF does not make use of a dedicated resource record type or naming convention, this leaves few solutions available to DNS operations in offering a means to mitigate possible abuse.  This type of abuse becomes rather pernicious when used in conjunction with synthetic domains now popular for tracking users without using web cookies.

However, email providers can mitigate this type of abuse by ignoring SPF records containing macros.  Very few domains make use of macros, and ignoring these records result in neutral handling.  Some large providers have admitted they make use of this strategy without experiencing any notable problem.  AOL began their support of SPF by saying they would use SPF to construct whitelists prior to receipt of email.  Clearly, such whitelisting practices tends to preclude benefits derived from macro use.
‘---

Regards,
Douglas Otis