[Top] [All Lists]

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

2007-04-11 08:57:49

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.



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