In
<1117882918(_dot_)8462(_dot_)37(_dot_)camel(_at_)firenze(_dot_)zurich(_dot_)ibm(_dot_)com>
Jeroen Massar <jeroen(_at_)unfix(_dot_)org> writes:
There is no
'unknown-mechanism' or a description what a SPF client would have to do
with a unknown-mechanism.
"v=spf9 mx habeas pgp -all"
This has been discussed many times over the last couple of years, both
here and on the MARID list. There are lots of people with different
ideas about how to allow SPF to be extended.
There are several problems with allowing unknown mechanisms, such as:
* This allows typos, such as using "ipv4:" instead of "ip4" to not be
detected as typos.
* Things like habeas and pgp can not be done before the body of the
email has been transmitted, which many people would object to.
* There is very little, if anything, that can be done with unknown
mechanisms that can't be done with unknowm modifiers, so disallowing
unknown mechanisms isn't a significant problem.
* There hasn't been a real consensus about what should happen when an
unknown mechanism is encountered. Should it throw a PermError (aka
"unknown" in draft-mengwong-spf-*)? Should it be ignored? Should
there be an extention to the SPF syntax to allow for a default to be
given if the SPF implementation doesn't know what to do with the
mechanism?
In practice, a lot of unknown mechanisms, such as habeas and pgp, have
been suggested, but none have really gone beyond the "wouldn't it be
cool if ...?" stage. In practice, at least one SPF implementation
(the one I originally wrote) rejects all unknown mechanisms, making it
hard for publishers to depend on any support for unknown mechanisms.
Basically, I think it is *far* too late to try and change the SPFv1
spec.
But... can the above be clarified in the draft? As I am assuming the
above and it is not in the ABNF.
I'll try to add something to make the unknown-modifier thing clearer.
The same applies to clients not supporting a certain mechanism for
whatever reason.
I know of no SPF implementation that doesn't support all required
SPFv1 mechanisms.
Other question, what are SPF clients supposed to do when they don't
recognize the version specified in the TXT/SPF record, should they try
to parse it or simply ignore it?
As per section 4.5 "Selecting Records", records with unknown version
numbers are ignored.
in another message, you write:
And what happens to the case where someone comes up with a really cool
new mechanism, will then the version number of spf be updated and thus
invalidate all the old ones, most likely requiring people to have both
spf1 and spf9 or whatever records in their DNS (not that it is a big
burden but... ;)
I would like to see future versions of SPF have better support for
scopes and versions. For example, we could have:
v=spf3/mfrom,helo pgp include:isp.com/mfrom redirect=%{d}/spfv1
and this would would do the pgp checking, use the "mfrom" scope from
isp.com (no matter what the version of that record is) and if neither
of those two matches happen, redirect to the domain's SPFv1 record.
This would allow for extentions in new versions, but not having to
duplicate sender policy that already exists in other SPF records.
The SPF RR currently is simply a TXT record with a different type, why
not have a binary RR? Parsing wise this is easier of course, but DNS
packets will be shorter with a binary one:
TXT "v=spf1 a=192.0.2.0/24 -all" would be:
SPF \# 10 01 06 81 18 c0 00 02 00 02 c0
The subject of binary record formats has also been discussed a bunch.
In the libspf2 implementation (the one I originally wrote), I created
a complete binary format that could have been sent across the net.
Unfortunately, the demand for such a binary record was much less than
I had hoped for.
Again, this is something that I can't see happening for SPFv1.
-wayne