Tony Finch wrote:
On Tue, 10 Apr 2007, Hector Santos wrote:
- Must all the reply codes be the same?
Yes.
Sorry if I missed this, but where is this stated? Is it implied?
Even then, wouldn't be inconsistent with the 150 description? and it
doesn't match the current MUA support?
- If not, the final return code (last line) is valid code?
Undefined.
Well, same as above, shouldn't it be defined? Doesn't this fall into
the documentation "nit" department yuns are trying to clear up?
- 150 SHOULD/MUST NOT be used without extended status codes?
It must not be used at all.
Explain?
It's completely outside the spec,
whether or not you support ehnanced status codes.
I don't see how EXTENDED status codes are even related. The current
description is:
1yx Positive Preliminary reply The command has been accepted, but
the requested action is being held in abeyance, pending
confirmation of the information in this reply. The SMTP client
should send another command specifying whether to continue or
abort the action. Note: Unextended SMTP does not have any
commands that allow this type of reply, and so does not have
continue or abort commands.
I "believe" the last note had the intention to NOTE that 150 would be
used as a response that the client will REACT too. The "Unextended
SMTP" implies they will be ignorant on how to react. i.e, an ESMTP spec
might define this.
However, it is still in play for normal 2821 operations. Imagine. If
the client begins the transaction with EHLO, it might be said that the
server and client may be SAFE in using 150. If the client used HELO,
then the server might not use it.
Nonetheless, there is no indication whatsoever whether the server
SHOULD/MUST/NOT use it.
I don't understand the resistance in clearing this up.
--
HLS