-----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
Julian Mehnle
Sent: donderdag 7 april 2005 14:29
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] IESG evaluation of SPF
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".
But there is between "not defined within this document" and "undefined"
(as a stand-alone phrase to denote a behavior or result).
So, that is why I said I might consider meeting them half-way,
Why?
If the wording "NOT RECOMMENDED" were to become the proverbial sand the
IESG digs its heels in to make a stand, then yes, I might be willing to
say results of such tests are considered "undefined" (or words to that
effect). For one, because it's rather a blanket-statement to say "MUST
NOT" against other uses of "v-spf1" records than intended, when with
'other uses' we mean both current techniques and all thinkable future
uses. I mean, it is not unthinkable that something will come along that,
as part of its overall scheme, checks against a header element they know
is set to the same value as the MAIL FROM entity (for which "v-spf1"
records could well be used). "NOT RECOMMENDED" therefore still feels
adequate enough to me.
I still see "NOT RECOMMENDED" as saying: "Please, don't; unless you really
know what you're doing." Like the manual of my ASUS motherboard tells me
that overclocking the CPU is "NOT RECOMMENDED" (but still offer many ways
to do so, btw).
Just pleasing the IESG isn't, and shouldn't ever be, enough.
As "not giving in to the IESG for the sake of not wanting to give in to
the IESG" is not a good enough reason to derail the process, either. I
believe in picking one's battles.
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.
No argument there.
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.
No, it is like saying that, in the absence of traffic speed limits, driving
too fast is "NOT RECOMMENDED". :)
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.
I am baffled by this statement; as "fitness for a particular purpose" is
precisely about using the right tool for the right job, and therefore
wholly a technical matter. How you see politics in that, is beyond me.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx