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
command.
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.
--
HLS