In <006901c4ee45$3c2aab80$6401a8c0(_at_)hdev1> "Hector Santos"
<winserver(_dot_)support(_at_)winserver(_dot_)com> writes:
In section 2.5.4 Fail:
There are two issues:
1) The perception that extended response code is recommended and should be
used.
Good point, I've added "if supported" before the references to the DSN
codes.
2) The reality of senders who don't properly handle multiple response lines.
I understand your concernse with the real-world situation. However, I
think that most implementors that understand these problems will not
be lead to think that an example means that they have to give a
multi-line response.
What do others think? Should I add more verbage here?
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.
I think it is useful to recommend specific codes so that implementors
don't have to dig around for the appropriate ones. I don't think we
should say that the MUST use any particular code because there are
always situations that we can't anticipate.
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.
I think the dictionary definition of "transient" is all that we need.
The actual cases when TempError is generated should be all spelled out
in the spec. (As Willaim noted, this wasn't true for PermError in the
cases of process limits.)
Basically, I think this is clear enough, but if others disagree,
please let me know.
Thats it for now :-)
Thanks Hector for these, and previous, comments about the draft. Keep
them coming!
-wayne