David MacQuigg wrote:
All this talk about compiling records puts us back to where we were at
the beginning about needing to do more to/on DNS servers than just add a
record to a zone file, the ease of which is another reason SPF has wide
mindshare.
I just don't understand the pessimism here. What is wrong with the
proposed solution - an SPF compiling daemon that runs alongside the
nameserver and gives us the best of both worlds? On the user-interface
side we have a full-featured syntax for describing any possible SPF
setup, and on the nameserver side a very efficient record that allows
any SPF check to be done in one query. There is not even a migration
problem. ISPs with simple records, like "+mx -all" will leave things as
is. Those that decide to install the new SPF daemon will continue to
use the same SPF syntax, but actually find it easier than creating
complex records with a text editor.
What Radu has done is taken a concern which seemed to many like pure
FUD, and showed that it is at least plausible. Whether that
plausibility is only 1 in 10 or near certainty doesn't matter, because
the cost of the solution is so low. In fact, I can't see any
significant cost to making an SPF compiler/daemon widely available.
I think it is time to move forward with the solution, and not worry
whether Radu's numbers are correct on the magnitude of the problem.
Thank you for the summary, Dave,
I think that if we were to move on with the solution, we would need to
ammend it into the draft. The critical parts of the solution are:
- a lower DNS lookup limit
- limiting the number of {i} and {l} expansions to 1 mechanism.
And since the mask modifier appears to have so much benefit for so
little cost and risk:
- the mask modifier should be added. Andy is the only one with serious
objections, so once we've cleared up what's best, we'll know if
we should add the m= modifier, or just use the exists: statement.
Radu.