On Fri, 13 Apr 2007, Philip Hazel wrote:
> +PH/44 I found a way to check for a TCP/IP connection going away before sending
> + the response to the final '.' that terminates a message. At this time,
> + there should not be any pending input - the client should be waiting for
> + the response. Therefore, a select() can be used: if it shows that the
> + input is "ready", there is either input waiting, or the socket has been
> + closed. Both cases are errors. (It's a bit more complicated than this
> + because of buffering, but that's the essence of it.) Previously, Exim
> + would have sent an OK response which the client would never have see.
> + This could lead to message repetition. This fix should cure that.
This is incorrect. RFC 2920 says:
The actual transfer of message content is explicitly allowed to be
the first "command" in a group. That is, a RSET/MAIL FROM sequence
used to initiate a new message transaction can be placed in the same
group as the final transfer of the headers and body of the previous
message.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
