In order to help put this issue to bed, I'd like to get more input from
actual SMTP deployments.
For example, we've heard from one of the Exim developers that it uses
the first code returned. And sendmail's & Hector's code reportedly uses
the last.
So I decided to check out some of the accessible open source code bases,
focusing on the server code that *sends* email to the next MTA.
I verified that sendmail definitely uses the last code and the Exim code
definitely uses the *first* code of the response set.
AT&T's own MTA's code uses the last code, ignoring the code on all
previous continuation lines.
Smail uses the *first* code.
hMailServer appears to use the *first* code.
qmail uses the *first* code.
postfix appears to use the *last* code.
jsmtp uses the *last* code.
Courier generally uses the *first* code. In some cases it actually
treats 1yz, 2yz and 3yz as equivalent and will totally miss any
subsequent 4yz/5yz.
The use of the first response code appears to be used just as often as
the last response code. The codes in between seem to be universally ignored.
Other than ours and sendmail, I can't say much about how much all of
these code bases are used, but some of them are certainly used with
multiple millions of messages daily, and I think the sample is large
enough to draw some conclusions:
It clearly indicates to me that at least the first and last reply codes
need to be the same. If they are NOT the same, >>>CODE BREAKS<<<. This
translates, to me, as indicating that we *NEED* to use "MUST" and not
"SHOULD".
Tony Hansen
tony(_at_)att(_dot_)com
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 the enough "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.
But instead of at least making these two issues a SHOULD, it is
incomprehensibly made a MUST - a lock down - which essentially does
three things:
1) It now makes any system that is using this in a published
and unpublished way, NON-COMPLIANT, including "superstars."
2) If any new SMTP developer followed 2821bis or the new standard
the would come from this work, inevitably, they will come across
a system where they will have a problem reading 1yx response lines.
The end result is that they need to CHANGE their code to support
these "legacy" systems,
3) It literally makes it a SHOW STOPPER for current and future work in
this area - OPES is now completely dead - won't have any chance of
maximizing adoptability.
So never mind about changing a 25 year old written functionality, from
an engineering and practical stand point, it makes absolutely NO sense
to lock down these items simply on the basis that SOME believe it isn't
being used - it isn't simply true.