A few comments: I apologize if this was already addressed:
In section 2.5.4 Fail:
There are two issues:
1) The perception that extended response code is recommended and should be
used.
2) The reality of senders who don't properly handle multiple response lines.
Even though it does say *SHOULD*, it is described as if extended DSN CODE
is a requirement. With the only example shown,
550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
a developer might get the idea that SPF is "enforcing" or encouraging
extended responses codes, when in fact, the following is also perfectly
valid:
550- SPF MAIL FROM check failed:
550- The domain example.com explains:
550 Please see http://www.example.com/mailpolicy.html
I say this because not all software is ready to support extended response
codes, including our own at the moment. If we were to add it for SPF, then
we will force to add it for everything else, not something we wish to focus
on at this time. The point is, this is not required for SPF
compliance/purposes.
In addition, a single response line is very appropriate as well. There are
many spammers who are using software who simply do not honor multiple
response lines and might happen is that they will retry again and again
causing unnecessary overhead.
I don't think it is worded right and there are 4 possible implementations
1) Must use a 55x response code range
2) Should (recommend) use a specific 550 response code
3) Optionally using extended DSN codes,
4) Using single or optionally multple response lines.
It should be clear any are appropriate response methods from an SPF
compliancy standpoint. The "extra' stuff is still that - extra and
optional.
In 2.5.6 TempError
A example of what "transient error" means. I presume this means a DNS
lookup error. Correct? In either a case, transient error needs to be
defined.
Thats it for now :-)
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Cc: "ted hardie" <hardie(_at_)qualcomm(_dot_)com>; "Scott Hollenbeck"
<sah(_at_)428cobrajet(_dot_)net>; "spf council"
<spf-council(_at_)moongroup(_dot_)org>
Sent: Monday, December 27, 2004 6:29 PM
Subject: [spf-discuss] draft-schlitt-spf-02 now available and submitted to
the IETF
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
-------
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