[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-22 19:50:33

Well, since you have no real mail system design or production experience, I think I will just skip replying to you. Its ashame that vote counts has any weight at all in this critical design issue. You are simply not the right person to comment on the matter.


David F. Skoll wrote:
Hector Santos wrote:

The key difference in this text was the 1yz was literately interpreted
as a "PRELIMINARY code" not a COMPLETION code, which literally means
there more codes are pending.

The interpretation is wrong, as a reading of the RFC will show.

Second, given the fact that 1yx are not currently defined for current
commands, it should be ignored.

Umm... no, I don't think so!

If you're writing a state machine (SMTP client) and it receives some
unknown reply code from the server, the ONLY sane course of action is
to QUIT or RSET.  The poor client has no idea what the server means;
it could be expecting the client to alter its state in some way rendering
subsequent commands useless or dangerous.

As one of the developers in the community and market place, it has been
very clear.  As formally defined in section 4.3 "SMTP Replies" for the
reply code:

   Formally, a reply is defined to be the sequence: a
   three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
   reply (as defined in the same section).

RFC2821, sec. 4.2.1 (my emphasis):

   The format for multiline replies requires that every line, except the
   last, begin with *THE* reply code, followed immediately by a hyphen,
   "-" (also known as minus), followed by text.  The last line will
   begin with *THE* reply code, followed immediately by <SP>, optionally
   some text, and <CRLF>.

Note: all lines must begin with *THE* reply code.  Not "a" reply code, but
*THE* one-and-only reply code.

Therefore, although your 1xy- server happens to work and to "solve"
an engineering problem you're having, I contend that it violates
RFC 2821.

Coupled with the logical suggestive text for handling multiple lines -
look for the first "xyz[sp]" non-continuation line, I don't see how you
can screw that up and practice has shown it hasn't been an issue. Why
would a serious SMTP system go against this?  There is no reason why it

I can see very good reasons why a serious SMTP client would *not* extend
its timeout upon partial receipt of a reply code.  Since this is the only
use case you've offered for the 1xy- hack, I think it's a bad idea.


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