On Wed, 24 Apr 2002, David Woodhouse wrote:
> I've just observed Exim 3.35 reporting the same error - but only after
> delivering one message. Prior to attempting to send the second message,
> Exim sends 'STARTTLS' again, and the receiving server immediately
> disconnects.
>
> It looks like we're trying to take down the TLS session and restart it for
> each message - Postfix evidently doesn't seem to like this. Is it permitted?
OK, this is a known problem.
Exim isn't designed to handle this gracefully. I didn't know about TLS
back in 1995. When Exim has sent a message to a host and notices that it
has another message for the same host that failed previously, it starts
a new delivery process in order to deliver the second message, passing
it the connected TCP/IP socket.[*] However, because it re-executes Exim, it
cannot pass on all the state needed for TLS. Therefore, it calls the
appropriate OpenSSL function that closes down encryption beforehand.
In the new process, it will try to start up a new TLS session. If both
ends of the connection are running Exim, this works. For other servers,
it doesn't. I don't know if it is "permitted" - I don't think the RFC
about STARTTLS says anything one way or another. However, OpenSSL does
support it if you call it in the appropriate manner.
I don't know what to do about this. The workaround is to set
connection_max_messages = 1
on the smtp transport (in Exim 4), which stops it ever sending more than
one message over one connection. Or you can use hosts_avoid_tls to avoid
using TLS to the hosts that give this problem (if you know which they
are). Or you can just live with the fact that this is going to happen
occasionally. Eventually, the second message will get delivered by some
other queue runner.
-----------------------------
[*] Remember, I designed Exim for situations where messages that can't
be delivered immediately are rare.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
