[Top] [All Lists]

Re: SPF and IPv6 (was: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited characters in addresses)

2008-01-09 13:43:06

On Jan 8, 2008, at 9:40 PM, Frank Ellermann wrote:

Douglas Otis wrote:

The show 12.6% of domains with name servers publish SPF records.

"Percentage of domains" and "percentage of mails" (incl. spam) are different. Not all domains send mails (really or forged, I'm not going to explain again why forging domains that can't receive mails is likely not what the spammer wants). The SPF deployment for "relevant domains" (defined by Alexa) is good enough, see < >

Agreed. The distribution of SPF use is heavily biased toward larger domains. However, this distribution should increase concerns pertaining to targeted DDoS permitted by SPF macro exploits, owing to the typical size of networks utilizing SPF. : (

When 4% of those then offer a possibility for FAIL, this represents less than half a percent of domains overall.

It is likely better measured in "mails" instead of "domains". If folks dare not publish FAILing IPs their PASSing IPs are still relevant. After a PASS receivers can delay their spam analysis and bounce later without causing backscatter.

This strategy still results in DSNs being dropped for a majority of the domains! The size of a domain does not alter the importance of a DSN. Even for those domains registering their IP address path, a significant portion of email is forwarded, where being off the registered path reduces the integrity of DSNs when SPF PASS represents an added requirement.

Alternatively, TPA-SSP represents a path independent, single transaction (by-name) means for ensuring DSNs are not dropped. TPA- SSP avoids inducing a DDoS risk, and remains compliant with RFC 1123.

SPF does not use different record types to verify IPv6 or IPv4 SMTP client authorizations.

SPF supports both IPv4 and IPv6 natively. Its job is to match the IP (IPv4 or IPv6) of an alleged sender (HELO or envelope sender) against an enumeration of "permitted" or "forbidden" IPs to get a PASS or FAIL result.

SPF combines everything into one response, without a specific initial record type, and without a means to segregate records sets for IPv4 and IPv6 clients. SPF's lack of resource record certitude means not finding TXT or type 99, or A or AAAA must be accommodated.

Even if a "no answer" or "no domain" limitation were to become specified as a recommended limitation for SPF parsing routines, the number of transactions occurring per cached SPF must still accommodate this protocol's inherent lack of record type specificity. The number of transactions that can be induced by a cached SPF record remains critically relevant to a DDoS concern that results from an SPF macro related exploit. Again, this exploit does not require an attacker to expend their resources. Instead the attacker is able to leverage the resources of larger networks utilizing SPF. : (

It's no rocket science to look at AAAA records when trying to match an IPv6, or at A records for an IPv4, as far as a policy contains any "by name" mechanisms. For the two SPF "by address" mechanisms matching IPs is straight forward.

While a routine parsing SPF records should know whether finding an IPv6 or IPv4 address is desired, SPF remains a exploitable mixed set. There is not any indication whether an MX mechanism host names resolves IPv4 or IPv6 addresses, or how SPF CIDR masks should be applied when a mixture of addresses is returned. SPF did not considered how its macro feature could be exploited, or the impact of combining both IPv4 and IPv6 records into one sequence of SPF records.