[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-11 10:46:37

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.

    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:

   HELO/EHO  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.


<Prev in Thread] Current Thread [Next in Thread>