David F. Skoll wrote:
Hector Santos wrote:
Under most scenarios, servers SHOULD use the same reply
code for each multiline response line when it is going to
be displayed at the same time. However there are scenarios
(Keep Alive Client Timeout issues) where servers MAY use
"150-" as an alternative reply code in a continuation line
when the server needs to issue a heartbeat to keep the client
alive during unsual delayed backend processing:
I don't like that. There's no reason to assume that parts of a multiline
response will have any effect on the client timeout. It might not reset
its timer just because it gets part of a reply back. Maybe many current
implementations do, but that's just good luck.
I believe that a proper negotiated ESMTP extension for "keepalive"
intermediate replies should be developed. We shouldn't try to hack
I agree 100% and this issue began a few years back including during the
last previous call out for 2821bis discussions where I brought the "Keep
Alive" consideration. So John is very aware this isn't a first time
discussion. I might just go ahead and write a I-D finally. Back then I
had never written an I-D. But with a few under my belt now, I am more
familiar with the process and more comfortable writing one if need be.
However, for 2821bis, I just would like make sure that it doesn't
pre-empt such new efforts. Thats really all I would like to seek here
and thus I go back to my original post to Frank with a suggested text,
which was really just a starting point and would be very happy for a
documentation person to reword it appropriately:
Only the final or last reply-code is important in a multiline
response. The client MUST|SHOULD use the final line as the ultimate
server response. It is possible for a server to use a
preliminary reply code 150- as part of multiline response
with a final non-continuation completion code.
354 Please Start sending....
[ client uploads message ]
451 Sorry, Rejected, try again later
I think the 1st and 2nd sentences are just a clarification of what is
already implied in 4.2.1 (as you pointed out) in:
In many cases the SMTP client then simply needs to search for a line
beginning with the reply code followed by <SP> or <CRLF> and ignore
all preceding lines.
If this is sufficient, I can agree with that. But I do think it should