Call it "SPF Classic", "Classic SPF", "SPF Stable", "Stable SPF" or "SPF1"!
Will IETF accept 2 competing drafts?
Since SPF is not yet an accepted standard, I don't care if it is still
changing. But I understand why others do care. I just want the thing to be
accepted as a standard, and work!
I also would prefer to NOT help M$ in any way. About 1 month ago, I did not
really care, but now I think they are being deceptive. And I know they are
evil! If M$ can, they will control email. One day you will get an email
like this, but the money part won't be there!
"My name is Bill Gates. I have just written up an e-mail tracing program
that traces everyone to whom this message is forwarded to. I am
experimenting with this and I need your help. Forward this to everyone you
know and if it reaches 1000 people everyone on the list will receive $1000
at my expense. Enjoy."
Not that you would really get such an email, but the tracking part could be
real someday if M$ takes control.
Guy
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of wayne
Sent: Saturday, October 16, 2004 2:48 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] draft-schlitt-spf-00pre2 now available
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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
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