ph10@??? said:
> In the new process, it will try to start up a new TLS session.
Er, how does it know that the server in question advertised STARTTLS
capability?
For that matter, the server in question 'MUST NOT' have advertised STARTTLS
to the second EHLO according to RFC3207...
4.2. Result of the STARTTLS Command
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting).
<...> The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
<...> A server MUST NOT return the STARTTLS
extension in response to an EHLO command received after a TLS
handshake has completed.
> 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.
All of those are somewhat suboptimal given that this is traffic from my
primary MX box to the place where I actually forward my mail at the moment.
It's not just a 'second' mail - there's quite a lot.
When there's a lot of mail on the queue, does Exim re-exec for _every_
message, or just after the first to turn into a queue runner process which
delivers all the rest? If the latter, perhaps we should just gracefully
close every connection with TLS active before re-exec'ing, rather than
passing the fd to the child?
--
dwmw2
