Scott Kitterman wrote:
So it isn't surprising we'd learn some things that ought to
be folded into the AUTH48.
Good point, but we also need some "lessons learned" for the
future PS, don't use them all for the "experimental AUTH48" ;-)
If we say anything other than "MUST be identical", then
implementation complexity will jump considerably.
Not necesarily, my favourite example is:
IN TXT some crap
IN TXT "v=spf1 450-sizeof(crap)"
IN SPF "v=spf1 same-as-TXT-plus-logging-and-or-exp="
In that case the TXT size is reduced by space for "some crap".
The SPF version uses it for something that isn't essential.
The strategy for receivers would be "use whatever you get
first, if in doubt use SPF, do NOT check identity".
We can eliminate this scenario by a decree, that's as it is
now. I'm less sure about "identical modulo case", if there
are cases when the SPF-version somehow arrives as the lower
variant of the TXT-version.
IMHO we should delete step 2 in 4.5 (check identity and
throw PermError if not). If you think that this is a bad
idea I'd recommend to use a case insensitive comparison.
In other words that's how I'd implement it no matter what
the spec. says, unless Florian's "DNS guru" tells me that
I'm an idiot.
I really suggest that we not make any changes to the
requirements for SPF record publishers.
ACK. And no new modifier for any SPF vs. TXT purposes.
My thought is that an answer always beats no answer.
Indeed, use whatever you get first, and if you have both
discard TXT, that's as it is in step 3 of 4.5.
3. Has SPF and not TXT
IMHO we can ignore this for some time (= years), it's an
obviously bad idea.
4. Has both types and not identical
Dito, only interesting for SPF validators if we keep the
MUSTard. See above. In practice this case is invisible
if we delete step 2 in 4.5, because step 3 eliminates it.
5. Has no SPF record on TXT and no response on SPF
Yes, that's Stuart's example, see separate message.
6. Has TXT and no response on SPF
Use whatever you get first, ready.
If this has any legs,
It has seven legs, so let's cut one... ;-) Bye, Frank