On Thu, 2004-01-29 at 10:54, Wechsler wrote:
v=spf1 +a/24 +mx +pgp -all
After the discussion on this, a light's gone on in my head: I just now
understand, (though even though I had been told this earlier), that
there would be a difference between:
v=spf1 +a/24 +mx +pgp -all # "pgp" as a nonstandard mechanism
and
v=spf1 +a/24 +mx +pgp= -all # "pgp" as a nonstandard modifier
In the first case clients that reached the pgp mechanism would return an
"unknown", and in the second case clients that reached the pgp modifier
would simply ignore it and thus return "fail".
This means that someone could publish even complex records such as:
v=spf1 +pgp=example.com:v=1:must_have=1:along_with(+a/24 +mx):
onfail_ignore_subsequent(+a/24 +mx) +a/24 +mx
+pgp=example2.com:v=2:musthave=3 -all
A strict spf1 client would of course interpret such a record in the same
way it would interpret:
v=spf1 +a/24 +mx -all
But the publisher of the record could intend bleeding-edge-experimental
clients to take it as meaning something like:
"Emails from my domain have to either:
come from (my mx machines or my /24)
AND pass requirement 1 of version 1 of the pgp method as published
by example.com as well as being from either my mx machines or my /24
OR
pass requirement 3 of version 2 of the pgp method as published by
example2.com
"
The fact that there is such "play" in the spec as-is means that the
extensibility arguments are probably all moot, especially given that
this can all be ignored by strict clients.
Making extensions-in-development be modifiers instead of mechanisms
means that people can experiment with extending the spec in ways that
still predictably fall back to "fail" for strict clients--and the people
who want to extend the spec have the burden of convincing clients (and
domain owners) of the wonderful benefits they'd accrue by using these
new extensions--all the while gaining incremental improvements
themselves as they and others adopt (rational and sensible)
improvements.
They'd also have to make their case in the spf2 discussions of course,
but by then we'd have useful experimental data.
And of course folks could test their proposed updated-spec-suggestions
with "v=spf1+"-type records.
So you get play, experimentally, and extensibility in the spec as-is,
while still pretty much having a strictly-defined deterministic answer.
Woohoo!
I'm much happier. :-)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡