On Thu, 3 May 2007, Kjetil Torgrim Homme wrote:
> 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?
I do not know, but I suspect probably not. I am completely ignorant of
how the various layers work. The code does whatever select() does on the
operating system you are running.
> 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.
Sounds like it's a "minor infelicity" that we can probably live with.
The benefit of suppressing unwanted multiple deliveries outweighs it, I
think.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
