Mark Kramer wrote:
Maybe you might be also persuaded, that "undocumented" is the
same bullshit as "undefined".
Actually, yes. :) But the IESG suggested "not defined" ("within this
document"), not "undefined" (as a stand-alone phrase). The former simply
means: "not described within this document"; the latter is much closer
in meaning to "unpredictable" (hence, unrecommended).
Even more hairs splitting. There is no substantial difference between the
meanings of "not defined" and "undefined".
However, there _is_ a substantial difference between the meanings of "is
undefined" and "must stay undefined forever", the latter being what I
think the SPFv1 should (and currently does) imply.
OTOH it's not the job of a v=spf1 draft to say what PRA does
with spf2.0/pra policies, that's why I proposed to use "v=spf1"
and "MUST NOT" instead of "NOT RECOMMENDED":
"MUST NOT", of course, is much more forbidding, RFC-wise, than "NOT
RECOMMENDED". The IETF even tries to tone down our "NOT RECOMMENDED" to
"not defined within this document" (which we believe to be much too
weak).
I have suggested s/NOT RECOMMENDED/MUST NOT/ several times myself, because
I think technically it is the right thing to do.
So, that is why I said I might consider meeting them half-way,
Why?
As long as there is no significant technical merit to outweigh the massive
negative implications of loosening the restriction of "v=spf1" records to
RFC 2821 identities, I don't see how that could possibly be justified.
Just pleasing the IESG isn't, and shouldn't ever be, enough.
It goes without saying that this assessment is based on the assumption
that RFC 2821 identities differ significantly from RFC 2822 ones in a
significant number of cases. Anyone who wants to challenge that
assumption is free to do so based on empirical data.
by saying the behavior of using "v=spf1" records for anything else than
defined, is "undefined", or "undocumented".
Well, I'd agree to saying:
| Checking other identities [than RFC 2821 ones] against SPF[v1] records
| is not defined in this document, and must not ever be defined elsewhere.
But that's just really convoluted while it essentially means the same as
the current wording. And I'd be surprised big time if the IESG were
satisfied by that.
The three things that simply *cannot* generally work are:
1 - check PRA against v=spf1 or spf2.0/mfrom policies
See, here is where "MUST NOT" is really too strong. Because the PRA
might be identical to the MAIL FROM entity, and thus successfully be
checked against a "v=spf1" record.
This is like saying that ignoring traffic speed limits is alright because
people might incidentally drive slow enough. You are ignoring the cases
where your assumption doesn't hold.
"Other identities MUST NOT be checked against v=spf1 records,
this can have misleading or unintended results."
You already say it yourself: "CAN have misleading results," an
uncertainty, which, IMHO, is adequately covered by "NOT RECOMMENDED".
"can have misleading results" implies "in a significant portion of cases",
which means it is a significant problem.
Everything is about "fitness for a particular purpose", as a lawyer
would say.
This is politics, and I would rather not like the SPF spec to be
influenced by politics.
Like you could probably run orange-juice through a coffee-machine; but
the procedure is definitely "NOT RECOMMENDED". :)
In a real world user manual there is no point in saying "MUST NOT" because
you know people generally have no incentive to follow your advice just for
the sake of it. With a technical RFC this is different. Either you are
compliant or you ain't.