Mark wrote:
But the IESG suggested "not defined"
It's an RfC-editor note, not an IESG or IANA note. So one of
the main questions is, does the RfC-editor know what this is
about ? I've tried to get in contact with the RfC-editor three
times so far (twice about a potential error in RfC 2069, once
about this issue), and got no reply so far. OTOH it's less
than three days.
Maybe some more questions help. There must be a reason why the
RfC-editor wants to introduce this dangerous change in the SPF
draft. Please try to get in contact with him (as SPF Council).
Actually it's no "him", you know what I mean.
There are many technical manuals that refer to a behavior
being "undefined", or "undocumented", and meaning exactly
what I described above.
I know, but we're not talking about a mere technical document
and something like an undefined bit, we're talking about the
one and only result of MARID if it had any result.
One of the IESG [discuss] comments clearly indicates that the
reader was confused about "SPF 1" vs. "SPF 2". Unlike us they
don't know the complete MARID desaster, and why v=spf1 is in
fact compatible with spf2.0/mfrom, but not with spf2.0/pra.
OTOH spf2.0/pra and spf2.0/mfrom depend on parts of v=spf1, and
a future draft-lyon-senderid-core-01 would probably reference
the SPF RfC. Therefore it's important that v=spf1 is as clear
as possible about what it really does in "stadalone mode". Its
policies can be _incompatible_ with PRA. Not only _undefined_
or _undocumented_ - that's a fundamental difference.
"MUST NOT", of course, is much more forbidding, RFC-wise
Yes, that's the idea. "We" created this mess (Meng, MARID, MS,
this list, Mark L, Wayne, you, and me), so now let's at least
be clear.
The IETF even tries to tone down our "NOT RECOMMENDED"
Not "the IETF", they have no idea what this problem is about.
It's the RfC-editor. And maybe he also has no idea what the
problem is (otherwise he should publicly state his reasons).
I might consider meeting them half-way
There's no "half-way", it's a blind and stupid bureaucracy. If
some of them intentionally screw-up then the SPF Council should
implement Plan B and go renegade. What Phil and Chuck proposed
in December. But this confrotation must be clear and open,
after all we know that this MUST NOT RECOMMENDED is essential.
I'd go to the public and say that the IESG is corrupt if and
only if it is, not because of a silly communication breakdown.
the PRA might be identical to the MAIL FROM entity
No, it's not identical, it's a completely different definition.
Its _value_ (mailbox address) can of course be identical, and
in many cases it it, but in other cases it's _systematically_
different (BATV. SES, SRS, Sympa, etc., etc.)
Therefore the PRA algorithm MUST NOT be applied on a sender
policy designed for v=spf1. And vice versa. It's a fatal
error to try this. And that it _apparently_ works in many
cases only makes it much worse.
But the procedure is really "NOT RECOMMENDED"
It's not only NOT RECOMMENDED, it's definitely wrong. Like a
procedure claiming that all odd numbers are primes. It works
for 3, 5, 7 and infinitely many other primes, but it does not
work for 1, 9, 15, 21, and infinitely many other odd numbers.
you may get something accurate, or maybe not. But to say
that it *cannot* work, ever, is too strong.
It's a fact. How do you judge _any_ result of applying PRA on
v=spf1, a whois lookup and ask the domain owner what he meant ?
How do you define any relation between PRA and MAIL FROM or
HELO ? What does "v=spf1 -all" mean ? It's perfectly okay to
say "-all" for HELO and MAIL FROM, but still use the FQDN in a
2822 From / Sender / Message-ID / etc.
It's a clear case of MUST NOT if the outcome is undefined and
dangerous. If somebody wants a pseudo random generator to
delete mails he should not read v=spf1 but one the PRG RfCs.
Everything is about "fitness for a particular purpose", as a
lawyer would say
IANAL, don't use v=spf1 cum PRA to get entropy for /dev/random.
Bye, Frank