In <x41xg0ze83(_dot_)fsf_-_(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne
<wayne(_at_)midwestcs(_dot_)com> writes:
This "SPF" spec that I have written may be of use to other people, so
I'm publishing a rough draft today. This is *not* finished, I still
need to go over it with a fine toothed comb and check for things like
spelling errors in the stuff that I have added. I am releasing them
now under the "release early, release often" F/OSS philosophy. Expect
another release Friday.
Well, I've gotten quite a few comments about errors in this first
draft-schlitt-spf-00pre1 draft, most of which appear to also be in
draft-lentczner-spf-00.
This newest version is still a rough draft, I still have quite a bit
of checking to do to make sure that it conforms with previous SPF
specs (in particular, spf-draft-200406.txt).
Two administrative points before I detail the changes:
First, I would like to apologize to Meng and Mark for leaving their
names in as authors without checking with them first. I intended to
discuss this in my initial announcement yesterday, but it was late and
I forgot. Sorry. As per their requests, I have removed them as
authors and added them into the credits section.
Secondly, I'm not sure what to do about the name "SPF". While my
documents are *far* more similar to earlier SPF drafts in
functionality (in particular, spf-draft-200406), SPF is whatever Meng
and Mark say it is. If they say SPF uses XML, then SPF uses XML.
So, should I change the name of this document? If so, does anyone
have any suggestions?
After announcing the initial draft last night, I received enough
comments to keep me busy editing tonight. This is why I haven't
finished all the stuff I want to do before I declare the document
final. I may be able to get another release out this weekend, I'm not
sure.
You can obtain copies of draft-schlitt-spf-00pre2 at:
http://www.midwestcs.com/spf/draft-schlitt-spf-00pre2.html
http://www.midwestcs.com/spf/draft-schlitt-spf-00pre2.txt
http://www.midwestcs.com/spf/draft-schlitt-spf-00pre2.xml
Changes since -pre1:
* Meng and Mark removed as authors.
* More restoration of the semantics of non-existance domains and
malformed domains from spf-draft-200406.txt.
* Bad domain references within an SPF record cause check_host() to
return PermError, not Fail.
* Bad domain references passed into check_host() cause check_host() to
return None, not Fail.
As per all earlier SPF specs, the only thing that causes a Fail
result is a domain owner saying so.
* Restored the ability of SPF implemenations to provide default
explanation strings when no exp= modifier is found in the SPF
record.
* cleaned up inconsistencies in the ABNF code
* cleaned up a several of typos and gramatical errors
* fixed a bunch of xref's that weren't reverse-engineered correctly.
* In order to make the ABNF unambigous with respect to CIDR notations,
Mark made some perfectly valid domain names unsupported, such as those
used by RFC2317. I re-did the ABNF for the domain spec so that
these domain names would again be supported and yet keep the CIDR
notiation unambiguous.
Basically, all domains must end in either a macro variable or a dot
followed by at least one letter. The CIDR blocks, if any, starts
after the end of the domain. These are effectively checks that
libspf2 has been doing for about 6 months now and giving warnings if
domains are found that don't conform. As a result of this ABNF
change, things like "a:1.2.3.4" and "a:smpt-out" are now syntax
errors.
* the 't' macro variable specification was tightened up a bit.
* When a macro string is expanded to more than 255 characters, the
spec now says to truncate until it is less than *or equal* to 255
* The ABNF and wording for invalid percent escapes has been cleaned
up, but I'm not sure if I like it.
Right now, if you say "%a", which is an invalid percent escapement
(only %-, %_ and %% are allowed), implementations are instructed to
interpret it as the string "%a" instead of a syntax error. Domain
owners are told to never depend on this. As a result, you have a
bunch of messy standardization that doesn't really do much of
anything.
I would need to double check the actual deployed SPF records, but I
strongly suspect that we could declare such constructs as syntax
errors and not invalidate more than a handfull (if any) deployed SPF
records. It would certainly clean up the spec a little bit.
Welp, that's all for tonight.
-wayne