Tony Hansen wrote:
You missed the most important piece of information, the END of the function:
return buffer[0] == okdigit;
You are correct. Exim is broken!! <g> but I guess will correct that to
make it unbroken by changing the specification.
Smail uses the *first* code.
Looking for source. Do you have a URL?
ftp://ftp.planix.com/pub/Smail/smail-3.2.0.121.tar.gz
Ok, I'll trust your review of it.
hMailServer appears to use the *first* code.
Per specification, it looks for the first NON-CONTINUATION reply code,
however, this code is buggy and shouldn't be included in your test. It
only looks for hard coded "250" values and it only supports 1 extra
multiple line from what I can see. This would be the least of its
problems. Throw this one out.
We're both wrong on this one. The state machine of hMailServer *skips*
over *all* continuation lines. It then uses the reply code in the *last*
response line.
This code was little harder to follow on whether it skipped all
continuation lines.
qmail uses the *first* code.
Yes it does - but it should noted it is doesn't care for continuation
lines which is obvious broken code and n violation of the formal
reply-code[sp] specification.
unsigned long smtpcode()
{
unsigned char ch;
unsigned long code;
if (!stralloc_copys(&smtptext,"")) temp_nomem();
get(&ch); code = ch - '0';
get(&ch); code = code * 10 + (ch - '0');
get(&ch); code = code * 10 + (ch - '0');
for (;;) {
get(&ch);
if (ch != '-') break; <---------- BREAK ON NON-DASH
while (ch != '\n') get(&ch);
get(&ch);
get(&ch);
get(&ch);
}
while (ch != '\n') get(&ch);
return code; <--- return first code -- BROKEN CODE!
}
It simply isn't following specs. Do you wish to encourage this behavior?
Excuse me: It's looping over all continuation lines, stopping on the
first non-continuation line, and then returning the code for those
response lines.
Right, I was agreeing with you. You said above it was using the first
code which you were correct. It only parses the first 3 digits in the
buffer, but continues to read/dump, breaking until the 4th digit is no
longer a "dash".
That is definitely following the spec that we've been arguing over. Yes,
it takes a couple of short cuts, only looking for the dash to decide if
it should continue or not and ignoring bad input lines that don't have
either a space or dash in the 4th character of the line, but otherwise
it's following the use-first-code interpretation of the specs.
Hmmmmm, based on the code above, it is parsing the first 3 digits as
numeric, then begins a loop
loop:
- read 4th
- compare with dash, break if not dash
- filter LF
- read 3 characters (with a presumption they are digits)
but it returns the first converted number for 3 digits in the buffer,
thus ignoring the fact that the first line may be a continuation.
Broken per x821? Compliant under 2821bis?
As I said above, your analysis of both Exim and qmail is flawed; my
conclusions on those remains.
Corrected on Exim. Qmail is broken. But it really doesn't matter any
more, the decision was made to endorse the broken behavior.
My conclusions stand: there is code out there that is in popular use
that will BREAK if the reply code on the first continuation line is
different from the final non-continuation line.
Thats a given. So they are BROKEN per x821 specs.
Part of the rules we are following for moving to draft standard is that
we MUST look at how current code has interpreted the proposed standard.
Which is the premise I used to begin this entire issue. Lets make them
compliant now in 2821bis. That should give a few people a pat on the back.
A MUST will support and codify current behavior. A SHOULD will not and
can not.
I disagree with your logic but thats ok. Enough nerves were touch here
with broken BIG software that it is more important to make them
compliant and endorse future similar behavior by virtue of the new draft.
Therefore a MUST is necessary to move 2821bis to draft standard.
So does that mean the ABNF will change? You are endorsing broken
behavior and future designs to ignore continuation lines as unnecessary
other than to terminate a response. Only the first 3 digits in the
received buffer is important.
--
HLS