[Top] [All Lists]

Re: rfc2821bis-01 Issue 14 Continuation of 222 greeting and Issue 15 syntax for multiline replies

2007-04-10 04:54:06

Tony Finch wrote:
On Tue, 10 Apr 2007, Hector Santos wrote:
  - Must all the reply codes be the same?


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?


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.


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.


<Prev in Thread] Current Thread [Next in Thread>