The issues of version numbers and the "unknown mechanism = unknown
result" has cropped up several times on this list. I wanted to give
the logic behind these design decisions. I'm sorry if I'm being a
little wordy or overly pedantic here, but I want everyone to
understand:
-- On Version Numbers --
On Feb 9, 2004, at 12:16 AM, Greg Connor wrote:
I'm going to agree with Julian on this one. The syntax and the
protocol are both indicated by the "version" tag "v=spf1". This
provides an assurance to anyone choosing to implement it now that
their domain won't break mysteriously down the line.
Precisely. This is exactly what we were thinking when we dropped the
dotted-version syntax: It doesn't buy much in this context: In what way
would 1.2 be compatible with 1.0? Would this be different than the way
that 2.0 is or isn't? Would we really have different rules for
handling unknown mechanisms if the major number of the record and the
client were the same versus different? We didn't think so.
-- On Unknown Mechanisms --
On Feb 9, 2004, at 12:16 AM, Greg Connor wrote:
"Unknown mechanism = error" provides an assurance of stability, at the
expense of denying small incremental changes. BUT, what choice do we
realistically have? If you receive a mail message and go to look up
its SPF record and find "v=spf1 a mx mystery:4C57E6F8 -all" then what
is the proper behavior for the unknown mechanism?
Exactly again! Since there is a formal logic to an SPF statement -
there is very little choice about what to do with an unknown mechanism
that keeps the logic of the SPF statement consistent.
In fact, in the specific case cited, there is no logically correct
choice - you must return with unknown when you hit the mystery: If you
don't know that the message passes the mystery test, you can't ever
give a definite fail. What other option would the domain want? If the
domain wants it to fail, then the messages that pass the mystery test
are pass on some systems and fail on others - inconsistent and makes
the mystery test useless. If the domain wants it to pass, then they
have just effectively written "+all" instead of mystery. By having
mean unknown, the domain gets messages that only pass the mystery test
to be a pass on newer systems and unknown (which isn't as bad as fail)
on older ones.
Now it turns out that there is another consistent way to handle unknown
mechanisms, but it only helps with contrived records like: "v=spf1
-mystery:4C57E6F8 -a:foo.bar.org mx -all". Basically, in cases where
there a mechanism with the same prefix as an immediatly preceeding
unknown mechanism, if the message passes it the second test, then you
can return a more definite result. When you consider the several
return codes, and the logic of the 'thrown' return codes, you might
imagine the rather complex function table that results. In fact, I
worked out the table, but Meng and I discarded this whole line of
thought as being very difficult to describe and justify, especially
when it doesn't really add any practical expressive power to SPF.
In particular, there is no practical reason to write
v=spf1 a mystery:4C57E6F8 mx -all
over
v=spf1 a mx mystery:4C57E6F8 -all
and the later can be handled as best as it can be by "unknown mechanism
= unknown result" rule.
In cases like
v=spf1 -mystery:4C57E6F8 -a:foo.bar.org mx -all
or worse
v=spf1 -mystery:4C57E6F8 +a:ok.foo.bar.org -a:foo.bar.org mx -all
There really isn't much one can do. A more complicated rule would
allow parsers that didn't understand mystery to additionally reject a
small class of messages, but they would never be able to give a clear
positive. And we couldn't come up with real use case for such a thing
anyway.
Remember, it isn't that the SPF community cna't come up with more
conceptually complete or flexible schemes - it is that we all have to
constantly weight the utility of such changes against the complexity it
adds to the scheme. If the use cases are only theoretic, then it isn't
worth adding.
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_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.7.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡