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. -- <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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}} -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
