[Top] [All Lists]

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

2007-04-22 12:33:13

Hector Santos wrote:

The ISSUE I have with all this what I think is being inconsistently applied here for this issue and Multiple response lines, is that for some ODD ball reason we don't think locking it down will break code because a few don't think it its being used enough by "superstars" and "common systems" when in fact it was always possible in the 25 year history of SMTP, following a formal specifications (see below), there was NEVER really a concern that it will break a system if you did use it. The concern was simply never there following SMTP allowed to do this without any minor details that it will break a system.

Forgot to write the "see below" to highlight formal declaration in 4.2 for what some say is "suggestive:"

   ....  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 section 4.2.1).  Since, in violation of this
   specification, the text is sometimes not sent, clients which do not
   receive it SHOULD be prepared to process the code alone (with or
   without a trailing space character).  Only the EHLO, EXPN, and HELP
   commands are expected to result in multiline replies in normal
   circumstances, however, multiline replies are allowed for any

   In ABNF, server responses are:

      Greeting = "220 " Domain [ SP text ] CRLF
      Reply-line = Reply-code [ SP text ] CRLF

If any old or current system reads a line:

      Reply-Code "-" [text] CRLF

and return this as a REPLY code is 1) broken and 2) in violation of a 25 year old specification. It will simply come across a transaction where this is a problem for them.

The reality if that most if not all systems do not behave like this. It will be RARE to find one that does.

Why are we supporting this behavior by using a MUST for persistent reply codes or disallowing "1yz-" in attempt to support these broken systems?

The CODE is broken if it reads a continuation line as the response code.


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