In <427AF108(_dot_)3B39(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
I may even add a change history from
draft-mengwong-spf-0[01]
This could be a good idea, but don't say something like this:
x "Include_subdomains=yes zone cut" added,
x+1 "Include_subdomais=yes" removed
x+4 "zone cut" removed
a change history from those and the previous dozen drafts.
It's not for "me". I can sing this stuff for the past year.
It's for the IESG, and only if you really want it for some
of the more dubious points in Andy's "spf-considerations".
I wouldn't recommend holding your breath waiting for this
though. :-/
Ok, this is *not* what Frank requested, but I think it might be useful
anyway. Earlier today, I consolidated all the change logs from the
since draft-lentczner-spf-00 was released. Yeah, this isn't as usefull as
a consolidated list of changes since draft-mengwong-spf-0[01], but
what the heck.
Announcement: draft-schlitt-spf-00pre1
For the most part, the difference between draft-lentczner-spf-00 and
draft-schlitt-spf-00pre1 fall into three areas:
* Stuff that was in the last SPF-classic draft before it was mangled
into SenderID. (spf-draft-200406.txt)
* Stuff that I submitted to Meng for inclusion into
spf-draft-200405.txt, but was rejected.
* misc cleanup of draft-lentczner-spf-00.
Things restored from spf-draft-200406.txt:
* restored HELO checking option
* restored NXDOMAIN result to "Unknown"
* restored zone cut
* Received-SPF header restored
Things rejected by Meng for spf-draft-200405.txt
* added verbage to SoftFail definition
* SPF records that are too long MAY be ignored
* all syntax errors MUST be detected
* Unknown mechanism are syntax errors
* process limits placed so that SPF clients can not be used for DDoS attacks
* clearer specifications for what should happen when DNS errors occur
* unknown macro variables are syntax errors
--------------------------
Announcement: draft-schlitt-spf-00pre2
Changes since -00pre1:
* 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.
--------------------------
Announcement: draft-schlitt-spf-00pre3
no change log, but I did post the following email:
I just announced another release of my doc on the SPF-discuss list.
Basically, Mark and I have agreed that we aren't going to work on
merging our specs right now, but may in the future. (After IETF-61
maybe?)
In <4008(_at_)rama(_dot_)pamho(_dot_)net> "Roger Moser"
<Roger(_dot_)Moser(_at_)rama(_dot_)pamho(_dot_)net> writes:
I did not check the grammer or spelling because I leave that to a native
English speaking person.
Please let me know about any spelling or grammar errors. These are
things I am *very* bad at and I shouldn't trip up non-native English speakers.
I have following comments:
2.1 The HELO Identity
The check_host() function is mentioned without saying "(see section 4.)".
fixed.
2.4 Checking Authorization
If the "HELO" identity is tested, then the <domain> is the "HELO" identity.
I think I have this fixed.
5.6 "ip4" and "ip6"
Why is <dual-cidr-length> declared in this section? It is not used here.
<dual-cidr-length> wasn't mentioned anywhere else, and this looked
like the best place to put it.
6. Modifier Definitions
I would not mention the "default" modifier.
deleted
8.1 Macro definitions
I would define <domain-end> as follows (more for political reasons than for
technical reasons):
domain-end = ( "." 1*macro-literal2 ) / macro-expand
macro-literal2 = %x21-24 / %x26-2E / %x30-7E
; visible characters except "%" and "/"
I left it as is, although I would probably change it if others object
to requiring alpha-only TLDs.
In following points my implementation is different to your specification:
The non-existing RR type "SPF" is not suported.
I have no intention of supporting the SPF RR type in libspf2 until
such time as there are a non-trival number of domains that only
publish SPF RRs. Personally, I don't see SPF RRs ever taking off, but
the IETF won't let a standard go forward with out this.
If the <domain> is not a fully qualified domain name, check_host()
immediately returns the result "None" and the reason "Malformed domain".
Similarly for "Domain does not exist" or "Literal domain" (if no PTR).
This is actually how libspf2 responds right now too. I've changed the
spec to match, but I could be persuaded to change it back. The older
SPF drafts have been inconsistent about this and I'm not sure what is
best.
Domain literals are accepted and the SPF record of the PTR record is
examined.
I don't understand what you mean by this. Could you give an example?
If there is more than one "exp" modifier, then no explanation is returned.
The result is not "PermError" but "Fail".
Hmmm... I think PermError is probably the right thing to do.
The version string does not have to be _exactly_ "v=spf1", rather it is
case-insensitive.
Actually, it isn't really clear in the old SPF specs, but this has
always been the case. It is part of the definition of ABNF.
The 'p' macro expands
to the responsible-domain if present in the list of PTR records,
otherwise a subdomain of the responsible-domain if present,
otherwise the first domain in the list of PTR records.
Fixed, although I only said "SHOULD" in the draft, not "MUST". I've
always liked this idea, but it has never been in any of the drafts.
The "%/" (or "%!") macro expands to "/".
I was not able to find a single domain that used this stuff in their
SPF records. So, I'm happy to leave things as they are.
Thanks again for all your comments and such.
--------------------------
Announcement: draft-schlitt-spf-00pre4
* The "HELO" identity is explicitly defined
* I say that the SPF-classic spec has not been changing much since
last winter.
* cosmetic changes:
* MAIL FROM vs Mail From -- most RFCs use the capitalized form
* Domain name vs host name -- host names are a subset of domain names.
* restored HELO checking from spf-draft-200406
* NXDOMAIN causes a "None" result rather than a "fail". Note that
resolvers will return NXDOMAIN when presented with a malformed
domain names.
This is kind of messy. The various SPF classic specs have been
inconsistent on this subject, and the various implementations that
I've checked have not been consistent. *sigh*.
* The only thing that causes a "fail" result is a domain owner having
mechanism in their SPF record that says so.
* warning added about domain names with source routes, percent hacks
and bang paths.
* note about what a Pass result is useful for
* note about what you should do with a SoftFail
* The examples in the spec use TXT RRs instead of SPF RRs
* restored zone cuts from spf-draft-200406
* deleted section that says "additional records" should use _spf.%{d}
* process limit: DNS packets that are too large MAY be ignored.
* examples and text encourage use of the implicit + on mechanisms.
e.g. "mx:foo.com" instead of "+mx:foo.com".
* note that the definition of the check_host() function will likely
need more arguments in real life than what is shown in the spec.
* deleted redundant explanation of results codes in section 4.2
* all syntax errors must be detected, not just when they are
"encountered".
* removed support for unknown mechanisms.
* redundant descriptions of modifiers removed from 4.6.3
* the ptr: mechanism and the %{p} macro ignore DNS errors instead of
triggering TempError.
* process limits: a limit of 10 MX name lookups per mx: mechanism
evaluation.
* process limits: a limit of 10 PTR lookups per ptr: mechanism
evaluation.
* explicitly say that IP address of 10.23.45 is invalid and not just
the same as 10.23.45.00/24
* allow other specifications to use unrecognized modifiers, not just
newer versions of SPF. (e.g., accredit= and ses=)
* SPF implementations can provide a default explanation string if no
exp= modifier is found.
* process limit: no more than 10 mechanisms that do DNS lookups.
* process limit: removed limit on the number of include: mechanisms
because that is a subset of 10 mechanism limit.
* restored Received-SPF: header from spf-draft-200406
* ABNF cleanup. (Including allowing the "/" in domain specs again.)
* Unknown % escapes are now syntax errors. Trying to get the old
semantics working with ABNF was really messy.
* Unknown macro variables are syntax errors.
* restored %{h} macro variable
* The %{p} macro variable should favor returning the sending domain.
* minor %{t} macro variable clarifications.
* give a suggestion about using "tracking exists: mechanisms" for finding
your outgoing mail servers.
* section 9.2 "implications for mailing lists" replaced with a note
that you have to follow the stuff that RFC2821 tells says you MUST
do.
* security consideration: don't let data provided by third parties
cause problems.
* 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
--------------------------
Announcement: draft-schlitt-spf-00
no changes listed, maybe it was the same as spf-00pre4?
--------------------------
Announcement: draft-schlitt-spf-01
Today I noticed yet another item dealing with SPF-classic HELO
checking that was absent from draft-lentczner-spf-00 that was in
spf-draft-200406. Even the hints that SPF records must be published
for the domains used in the HELO/EHLO commands were removed.
spf-draft-200406 not only had a few hints sprinkled here and there,
but it had an entire section (8.3) dedicated to the subject.
While I didn't create a new section, I did make it clear in the
section on publishing SPF records (3.1 in schlitt-spf) that SPF
records are needed for sending MTAs. This requirement is still in
lentczner-spf, but you have to read section 2.1 "Mail From Identity"
very closely and understand all the implications.
Roger Moser pointed out a couple of other problems.
* IPv4 mapped IPv6 addresses need to be treated as IPv4 addresses.
(libspf2 has done this since last spring, and I'm guessing RMSPF has
too.)
* The ABNF for the Received-SPF: headers needs to use LWSP instead of
SP.
--------------------------
Announcement: draft-schlitt-spf-02pre1
The major differences between this schlitt-spf-02pre1 spec and my last
published schlitt-spf-01 spec are:
* Editorial changes, many of which were suggested by Frank Ellerman
* If the SPF record from the zone cut is used, the %{d} is reset as if
it there was a redirect= modifier that was executed. Apparently,
most of the uses of %{d} in the wild are for tracking exists: and
the earlier semantics worked ok, but studying the other cases,
changing the %{d} domain looks like it will work better.
* I've taken another stab at the ABNF for the Received-SPF header.
What I have come up with should allow Received-SPF headers generated
by the currently deployed systems to remain valid, but it will allow
future SPF implementations to generate nicer and more consistent
headers.
* The ABNF for the domain spec has been cleaned up to give a more
widely used definition of the valid TLDs. (e.g., I use the same
ABNF as defined in RFCs describing URLs and such.)
--------------------------
Announcement: draft-schlitt-spf-02
The major differences between this schlitt-spf-02 spec and my last
published schlitt-spf-02pre1 spec are:
* Meng has been added back as a co-author as I have received a
confirmation from Meng that it is ok to do so. I haven't heard back
from MarkL yet but, considering it is the holiday season, I'm not
surprised.
* Several editorial changes, mostly those suggested by Alex van den
Bogaerdt.
* A note that checking SPF records against other identities than what
they are designed for is NOT RECOMMENDED.
* STMP error code clean up
* I've gone through and double checked the SMTP reply codes.
Reviewing things, I have decided that 451 is probably better than
the 450 replies. After checking the web for graylist results, I
found a few references to 451 working better (e.g. some MTAs
generate immediate retries on a 450).
* I've added enhanced DSN codes for each case where an SMTP reply
code is given. The DSN codes I've used are 5.7.1 for "fail",
4.3.0 in the example case in "softfail", 4.4.3 for "TempError",
and 5.5.2 for "PermError".
* I've changed the reply codes from "MUST"s to "SHOULD"s. In
particular, there could be other DSN codes used for "PermError"
depending on what exactly triggered the error.
* ABNF has been doubled checked using the ABNF verifier found on the
IETF website.
--------------------------
Announcement: draft-schlitt-spf-classic-00
The major differences between this schlitt-spf-02 spec and my last
published schlitt-spf-classic-00 spec are:
* Near the top of the draft, there was a claim that all references to
things like "return-path" and "reverse-path" instead of "MAIL FROM"
would only be used in conjunction with a normative reference. I've
updated the draft to make this actually so. ;-)
* As noted in other replies, editorial changes made by William,
Hector, Alex, etc. were applied. Check the diff for the exact
wording that I used.
* A wildcard example used names like "X.COM" instead of "X.COM.". (I
probably should change these to example.com, but...)
* A bunch of spelling errors were found by my spell checker, but I'm
sure a bazillion grammatical errors remain.
--------------------------
Announcement: draft-schlitt-spf-classic-01pre[1-3]
These were not publicly announced and no change logs were made.
Changes were announced in -01pre4
--------------------------
Announcement: draft-schlitt-spf-classic-01pre4
The major differences between this schlitt-spf-classic-00 spec and
schlitt-spf-classic-01pre4 spec are:
* The zone cut specification, as described in
draft-mengwong-spf-01.txt, has been removed. This part of the SPF
is not widely implemented, it was one of the most recent additions
to the SPF spec, and it raised strong objections in the IETF DNS-ext
working group. I have long said that this was the thing I would be
most willing to remove, and I guess I would still be willing to
bring it back if someone can give convincing reasons why it is
required.
* Most of the changes have been editorial in nature, rather than any
changes to the actual semantics of the protocol. This wordsmithing
includes not just spelling and grammatical fixes, but also
clarifications about the intent and meaning of various parts of the
spec.
* Sections have been re-ordered in so that they conform to the
instructions2authors.txt document. All required sections and
arrangements are included, and only the "Security Considerations"
section is not in the suggested order. Since the Security
Considerations is such an important part of the spec, it has been
moved before the Acknowledgement section.
This makes the diffs much larger than the actual changes content
would create.
* It is now RECOMMENDED that SPF clients check the HELO identity,
instead of just saying that they MAY.
* The "Processing Limits" has been merged into the "Security
Considerations" section, eliminating duplicate information.
* The "Security Considerations" section has been reorganized and broken
up into subsections.
* A "Privacy Exposure" subsection to the "Security Considerations"
section has been added.
* An IANA section on the Received-SPF header has been added. (Thanks
Frank!)
--------------------------
Announcement: draft-schlitt-spf-classic-01pre5
Changes from -01pre4:
* I discovered that the .txt file created by xml2rfc differs slightly
from the .txt file created from the .nr files that xml2rfc creates.
Since the RFC-editor will want the nroff file, the .txt file that
I'm publishing is now generated from the .nr file and formatting
issues are now tweaked to make the .nr files look right.
* I have tweaked the formatting so that the .html file generated by
xml2rfc look a little better, but it still has a lot of ugly parts.
Since the .html file is not a controlling document, I'm not worrying
too much about it.
* The title of the I-D has been tweaked to look more like other RFC
titles.
--------------------------
the -01pre6 draft is currently being edited.
-wayne