In <20041120033121(_dot_)GQ16336(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
Use of both IP-based and crypto-based schemes can be
described by SPF:
v=spf1 a mx dk -all
I had always envisioned the need for a "dk" or "iim" or some
other such mechanism: hence the very specific language about
bailing out with "unknown", but also not bailing out until
the unknown mechanism was encountered.
I understand why you have long wanted unknown mechanisms to be
allowed. There are, however, many problems with them.
First, unknown mechanisms do not add any descriptive power to SPF
that can not be done with unknown mechanisms.
Take your example above. The trailing "dk -all" part has the
semantics of "if an SPF implementation doesn't understand the 'dk'
mechanism, return Neutral. If the SPF implementation does understand
the 'dk' mechanism, then return Pass if there is a valid domain key
signature, otherwise return Fail." Yeah, that is a lot of semantics
wrapped up in a short "dk -all" encoding.
The unknown modifier equivalent to the "v=spf1 a mx dk -all" record
could be "v=spf1 a mx ?all dk=asdf". The semantics of the "dk=asdf"
modifier is "An SPF implementation that understands the 'dk' modifier
would do the following check: if there is a valid domain key signature
then return Pass, otherwise return Fail." Yes, the "asdf" part is
arbitrary and not descriptive, but wait until point 5.
So, "v=spf1 a mx dk -all" says the exact same thing as "v=spf1 a mx
?all dk=asdf". You can argue about which is "more logical" or
"clearer", but let's leave that for now.
Second, unknown mechanisms don't extend well when there are two or
more of them.
Consider "v=spf1 a mx dk smime -all". This, on the surface, looks
like if either a valid domain key signature is found, or the email is
properly validated via s/mime, then the result is Pass, otherwise the
result is Fail.
The problem is that in order for the smime mechanism to even be
checked, the SPF implementation has to implement the dk mechanism. If
the order is reversed (e.g. "smime dk"), then the implementation that
only knows about the 'dk' mechanism won't work as expected.
An unknown modifier equiv might be "v=spf1 a mx ?all dk=asdf
smime=asdf". Both the "dk=asdf" and "smime=asdf" modifiers could be
defined as having the above semantics of: "An SPF implementation that
understands the 'dk'/'smime' modifier would do the following check: if
there is a valid dk/smime signature then return Pass, otherwise if all
other special modifiers don't match, return Fail."
Now, you might notice that there is a slight problem with this: we
don't say what all "special modifiers" there are, and since SPF
implementations can't know about future "special modifiers", we need
to explicitly list them.
So, the real unknown modifier version would need to be:
"v=spf1 a mx ?all special=dk,smime dk=asdf smime=asdf"
Ok, that record will work right for all SPF implementations, it does
the right thing when an SPF implementation only implements one of the
dk or smime special checks, and it will work correctly if a new SPF
implementation comes along and implements an iim or pgp special check.
This simply can not be done with unknown modifiers.
Third, the modifiers that are built into SPF right now are basically
all the mechanisms that you can do before the SMTP DATA command. Any
SPF implementation that implements a dk: or smime: mechanism can't do
its work before the message has been received. Now, some people don't
care about this, but many people do. Using unknown modifiers, we get
an "SPF-classic" result at the pre-DATA time, and the special
overrides for dk/iim/smime/pgp happen later. You might even want to
call the result something other than the SPF result.
Fourth, allowing unknown modifiers reduces the reliablity of SPF
records because typos are not caught early and consistently. There
are a heck of a lot more SPF records out there with things like
"ipv4:1.2.3.4" and "prt" than ones with unknown mechanisms.
(Actually, the last time I've check there aren't any SPF records with
unknown mechanisms that appear to be intentional.)
Fifth, unknown modifiers can better express the idea that "all email
from this domain must be DK signed". Instead of "dk=asdf", you could
have things like "dk=required" or "dk=optional". To express such
things with unknown mechanisms you would need to do something like
"v=spf1 dk -nodk a mx -all", with the "fail on no domainkey" (-nodk)
up front before the "a" or "mx" mechanism has a chance to match.
This, of course, renders the SPF record useless for all the
implementations that don't understand both the "dk" and "nodk"
mechanisms.
While I understand why Meng wants unknown mechanism, and I agree that
extentions are very useful, I just don't see any good reason for
them. Everything that can be done with unknown mechanisms can be done
with unknown modifiers, and generally it can be done better.
-wayne