spf-discuss
[Top] [All Lists]

RE: Re: IESG evaluation of SPF

2005-04-06 20:02:00

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Frank 
Ellermann
Sent: donderdag 7 april 2005 3:54
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: IESG evaluation of SPF


Mark wrote:

I might be persuaded to have the sentence say:

"Checking other identities against SPF records is
 undocumented."

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).

As Julian said, "not defined" would imply allowing the semantics of those
records to be changed by another specification. And we really want to keep
in something which says NOT RECOMMENDED, either expressed or implied.

... it's the duty of the SPF Council to prevent the
foreseeable damage by a clear statement, no vague "undefined"
or wrong "undocumented".

Exactly, a clear statement is required. :) The irony, however, is that
"undefined", in its vagueness, is exact in putting the finger on the sore
spot, as it tells you that the result of using "v=spf1" records for
anything else than defined, is unpredictable, and has a good chance of not
giving you a result you expected. There are many technical manuals that
refer to a behavior being "undefined", or "undocumented", and meaning
exactly what I described above.

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).
So, that is why I said I might consider meeting them half-way, by saying
the behavior of using "v=spf1" records for anything else than defined, is
"undefined", or "undocumented".

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. But the procedure is really "NOT RECOMMENDED",
as the two may well not match; hence, the result of such a check would be
"undefined" : you may get something accurate, or maybe not. But to say
that it *cannot* work, ever, is too strong. That is why I would really
like to stick to "NOT RECOMMENDED", or "undefined" in the sense I outlined
above.

"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".

Everything is about "fitness for a particular purpose", as a lawyer would
say.
Like you could probably run orange-juice through a coffee-machine; but the
procedure is definitely "NOT RECOMMENDED". :)

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx