In <x4k6r57fdl(_dot_)fsf(_at_)footbone(_dot_)schlitt(_dot_)net> wayne
<wayne(_at_)schlitt(_dot_)net> writes:
Unlike previous versions, I intend to submit this as an I-D to the
IETF. In particular, I hope to submit it on Monday just to get it
into the I-D queue [...]
As promissed, I have submitted draft-schlitt-spf-02 to the IETF as an
individual I-D.
Until the I-D shows up on the IETF site, the documents can be found at:
http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.html
http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.txt
http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.xml
I still need to go through the draft again and see what I can delete.
Suggests would be very welcome. In particular, I'm eyeing the
examples in the Received-SPF section.
I also need to go through and document the *semantic* changes from
spf-draft-200406. I've tried very hard to make draft-schlitt-spf-02
very compatible with spf-draft-200406 and change things only when they
will have no practical effects on the installed base of SPF.
(e.g. elimination of unknown mechanisms). However, creating such a
document should make things clearer to everyone where this draft
stands.
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.
-wayne