On Wed, 11 Apr 2007, Hector Santos wrote:
Tony Finch wrote:
...
Absolutely not. You CANNOT break running code like this.
That should not break running code, but merely highlight that SENDMAIL and
EXIM didn't follow a 25 year old RFC 821 specification to begin with:
In many cases the sender-SMTP then simply needs to search for
the reply code followed by <SP> at the beginning of a line, and
ignore all preceding lines. In a few cases, there is important
data for the sender in the reply "text". The sender will know
these cases from the current context.
That's a description of a possible implementation strategy and not a
requirement that implementations only use the reply code in the final
line. How can it be a requirement when it doesn't say when it applies?
Note again the use of "the reply code" in that text, implying that the
same reply code must be used. If more than one reply code could appear in
a multiline reply, then the text would have used "a reply code" to reflect
their multiplicity, or maybe "one of the reply codes". Indeed, the very
description of multiline replies seems like the strongest argument that
the same code must be used:
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>.
How can there be different reply codes when _the_ reply code is at the
start of every line? If there had been any conception of using different
reply codes on some or all continuation lines, that text would have
referred to "a reply code" or "some reply code".
How can sendmail and exim fail to comply when there's no suggestion that
the last reply line may be different in any way but rather evidence to the
contrary?
It makes them non-compliant.
I obviously disagree.
I think the NEW sentence for the NEW SPEC
should include a clarification such as:
The client SHOULD use the final line as the ultimate
server response.
Huh. So, you think an implementation that doesn't use the final line
doesn't comply with 821, but you want to add text so that they *would* be
(conditionally) compliant to the new spec. That means that using
different reply codes in continuation lines would fail to interoperate
with conditionally compliant client implementations, so they would be
impossible to use reliably. You seem to be sabotaging your goal.
Philip Guenther