Re: [exim-dev] [exim-cvs] cvs commit: exim/exim-doc/doc-txt …

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Tony Finch
Ημερομηνία:  
Προς: exim-dev
Παλιά Θέματα: [exim-cvs] cvs commit: exim/exim-doc/doc-txt ChangeLog exim/exim-src/src functions.h globals.c globals.h receive.c smtp_in.c tls-gnu.c tls-openssl.c tls.c exim/exim-test/confs 0559 2029 2150 exim/e
Αντικείμενο: Re: [exim-dev] [exim-cvs] cvs commit: exim/exim-doc/doc-txt ChangeLog exim/exim-src/src functions.h globals.c globals.h receive.c smtp_in.c tls-gnu.c tls-openssl.c tls.c exim/exim-test/confs 0559 20
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}}