Hector Santos wrote:
This RFC 821 (clone in 2821) "recommendation" in question:
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
It's not a recommendation. It's merely an illustration of one
possible implementation.
Anyway, I read the source code to Sendmail 8.14.0. It's not exactly
easy to follow, but this is what it does: Sendmail uses the reply
code from the LAST line, but the text message from the FIRST line.
So if it receives:
150-One second please
250 Message accepted
it returns a reply code of 250 with a text part of "One second please".
(Yes, this is weird behaviour and could lead to very confusing log messages.)
Also, I stand my engineering that most, if not all, even SENDMAIL until
shown otherwise, will reset their timers when the channel is active again.
In the case of Sendmail, you are correct. It does reset the timer
when it receives a line. But as I wrote, that's an implementation
detail and there are perfectly valid reasons why you should
have an overall timeout.
Permitting different reply codes in a multiline reply is confusing and
of doubtful utility. I do not think it should be blessed in an RFC,
even if it's only in a MAY section. I believe the RFC should be
reworded to make it clear that all reply codes in a multiline reply
MUST be the same code. Then leave it up to an extension to negotiate
keepalive if the client wants it and the server is willing.
Regards,
David.