On Sat, 2005-06-04 at 08:51 -0500, wayne wrote:
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.
ip4:129.0.2.0/24 does get detected as a typo you mean? :)
(I wanted to type 192.0.2.0/24 - TEST_NET)
But indeed if the mechanism are defined then this could spare one issue.
* Things like habeas and pgp can not be done before the body of the
email has been transmitted, which many people would object to.
In this case I more see the SPF record as a policy description.
Indeed if one needs the body, like with PGP or habeas then one can't do
it at SMTP time and requires the body to be transmitted first, which
many people won't like. But do realize that for
* 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?
As you write that there is no consensus, should there not be a
vote/query/poll for getting this done then?
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.
Ack. will be something for a later one.
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.
That is very good to hear and basically takes quite some 'fears' away :)
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.
Ah there it is ;)
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.
This looks like a great idea. Let's not forget this for the upcoming
version :)
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.
Would it not be better to take the SPF RR part out of the current draft
then? There is afaik no commonly defined RR number anyway and most
likely no implementation or use at the moment, with only the TXT record
being used. SPFv2 or whatever followup could at a certain stage define
this correctly and then, just like your idea above of being able to
define fallbacks from v3 to v1 point to the TXT record of the domain.
Greets,
Jeroen
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part