David F. Skoll wrote:
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.
Like we have many to choose from :-)
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.)
I just downloaded it (Chef Boraydee <g>).
What I see is:
- checks for valid lines ("XYZ" "XYZ-" or "XYZ ")
and ignores the rest (continues reading). Junk
lines are ignored.
- does an atoi() to get the reply code which has a natural
delimiter for non-digits
- if the code is less 100, continue reading
- breaks on the non-continuation line, which coupled with the
above, it returns the last reply code.
So from this, as I expected, SENDMAIL does not error out with
continutation lines (i.e, 150-) when reading reply lines for ALL states.
What it probably interested here is that its uses a non-standard less
than 100 code for "informational", so something like this is valid under
SendMail.
099-Informational
099-Informational
099-Informational
099-Informational
250 whatever
Very interesting.
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.
I'll say it again this way: this is a common "method" concept in C/S
(Client/Server) designs, especially in a TCP/IP environment. The point
here is that C/S (or even P2P) communication timeouts is generally based
on channel idleness. Hence, I wasn't surprise SendMail also falls in
the same group. We can call it an implementation detail if we like, we
are not going to find too many systems that deviate from this
fundamental design concept.
Yes, overall timeout is fine, That is an implementation detail that is
not found across the board. A great idea to have, but I would not be
surprise if its not utilitzed across all systems.
In my SMTP design experience, the basic overall concern has been
unexpected or ungraceful DROPS and not really trying to regulate how
long a session is taken simply because there is no hard core rule on how
long a total session should take. But I agree, this are necessary
considerations.
If we wanted to juggle this idea, we can say that a maximum transaction
time for a CLIENT would be:
GREETTING 5
HELO/EHO 5
MAIL FROM 5
RCPT TO 5
DATA 10 (5 for 352 response, 5 for upload response)
QUIT 5
Or 25 or 35 minutes if how you want to include DATA/QUIT.
Permitting different reply codes in a multiline reply is confusing and
of doubtful utility.
The only current useful I see is KEEP ALIVE. I can't think of any other
need. But as you can see from SENDMAIL it obviously found a need for
what it calls "informational" reply lines.
I believe the RFC should be
reworded to make it clear that all reply codes in a multiline reply
MUST be the same code.
That would be an unnecessary restriction. Clients or servers doen't
require this tightness.
Then leave it up to an extension to negotiate
keepalive if the client wants it and the server is willing.
IMV, this is backwards. This is a server driven control concept. The
client may have restrictions but it is the server that will drive this,
not the client. The server determines if its something it would want to
do to process the transaction.
--
HLS