Douglas Otis wrote:
SPF combines everything into one response
Yes, in other words it's a tool to put all IPs (IPv4 and IPv6)
into one of three classes PASS, FAIL, or "DUNNO" (the latter
is an over-simplification for NEUTRAL, SOFTFAIL, and "error",
anything that doesn't help for one or both of the tasks at
hand, match given IP against "permitted" or "forbidden" IPs)
SPF's lack of resource record certitude means not finding
TXT or type 99, or A or AAAA must be accommodated.
I can't parse this. If a receiver doesn't find a policy, or
doesn't try it, or it's impossible (e.g. domain literal) to
find a policy, then the receiver continues as usual following
some receiver policy. That MAY be a "best guess" evaluation
of "v=spf1 a/24 mx/24 ?all", add/replace IPv6 CIDR depending
on the receiver, and toggle ?all into ~all or -all as desired.
Hint: the a-mechanism means AAAA if you try to match an IPv6.
Of course that is a "receiver policy", and RFC 4408 discusses
only "sender policy", not creative "best guess" uses of the
checkhost-algorithm for related purposes. Receivers could do
what "a/24 mx/24" means also without SPF, if they think it is
a good "best guess".
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 that can be induced by a cached SPF
record remains critically relevant to a DDoS concern
The proposed 2..5 limit in the "rebuttal" (one way to implement
an existing SHOULD in RFC 4408) reduces your worst case of 100
bogus overlong attack-queries to 2..5. Implementation details,
after reaching 3..6 just trying this *again* for the next mail
of the attacker is not the smartest thing to do.
Your "fast flux local parts" idea selects malicious MX records,
but after reaching 3..6 once it's clear that the policy is up
to no good, or something on the side of a legit sender has to
be fixed a.s.a.p.
There is not any indication whether an MX mechanism host names
resolves IPv4 or IPv6 addresses
That's unnecessary, you get a set of names (+ priorities), and
if you try to match an IPv6 query AAAA, and for an IPv4 query A.
or how SPF CIDR masks should be applied when a mixture of
addresses is returned.
That is clear, look for <ip4-cidr-length>, <ip6-cidr-length>,
and <dual-cidr-length> in the collected ABNF. In a nutshell
x/y//z means IPv4 CIDR y or IPv6 CIDR z, short forms of this
are x//z (no IPv4 CIDR), x/y (no IPv6 CIDR), and x (no CIDR).
Exception: For a "by number" mechanism x (either ip4 or ip6)
<dual-cidr-length> makes no sense, therefore ip4:x/y works as
always, and ip6:x/z has only a single slash <ip6-cidr-length>.
Admittedly it took me some time (MARID 2004) to figure it out,
more or less the only tangible result of MARID for v=spf1 was
a serious clean-up of the ABNF. Credits to Jutta Degener...
Well, and you contributed to the current processing limits ;-)
Frank