On Fri, 2007-04-13 at 16:29 +0100, Philip Hazel wrote:
> Then it struck me that there is no need to mess with signals. A simple
> call to select() can also detect this situation. I have therefore
> implemented code to do this (with some extra features for the "input
> sent too soon" case, because of buffering), and my tests seem to show
> that it works nicely, with and without TLS.
does this code handle the case where there is data available on the
socket, but it's not in the upper layer? in TLS, the client can request
a re-handshake at any time. from the manual pages of OpenSSL:
If the underlying BIO is blocking, SSL_read() will only return, once
the read operation has been finished or an error occurred, except when
a renegotiation take place, in which case a SSL_ERROR_WANT_READ may
occur. This behaviour can be controlled with the SSL_MODE_AUTO_RETRY
flag of the SSL_CTX_set_mode(3) call.
Exim seems to return EOF for the SSL_ERROR_WANT_READ case which you get
when there has been a renegotiation, and that causes Exim to drop the
message.
it's not a big problem since this should be very rare, and the delivery
should be retried later, and it's unlikely the renegotiation would
happen at the exact same spot once more.
--
Kjetil T.
