Hello, I am trying to determine if this error, which happens randomly
and fortunately not often, is caused by some data corruption on the
wire (so to speak, it would probably be some firewall appliance at my
provider network, a farm of virtual servers).
I have found reference to this error in relation to curl, which
points to:
http://www.openssl.org/support/faq.html#PROG10
10. Can I use OpenSSL's SSL library with non-blocking I/O?
Yes; make sure to read the SSL_get_error(3) manual page!
A pitfall to avoid: Don't assume that SSL_read() will just read from
the underlying transport or that SSL_write() will just write to it --
it is also possible that SSL_write() cannot do any useful work until
there is data to read, or that SSL_read() cannot do anything until it
is possible to send data. One reason for this is that the peer may
request a new TLS/SSL handshake at any time during the protocol,
requiring a bi-directional message exchange; both SSL_read() and
SSL_write() will try to continue any pending handshake.
I looked in exim code and the only occurrence of SSL_set_accept_state
is when the secure connection is established. Is this correct? I am
absolutely no SSL expert.
My gut feeling that this is not a problem with exim, or that at least
this problem shows itself rarely under normal conditions. On the
server in question for instance there has been a period of over a
month without this error happening.
Maybe others can look up "SSL_write error 5" in their logs.
The most affected server is running a normal exim-4.60 on Debian
(don't send me to the Debian list, I always stay clear of distro
specific packages except for the basic ones. And this is my only
Linux, not by choice or it would be FreeBSD!).
Thanks
Giuliano
