Re: [Exim] Re: closed connection in response to STARTTLS.

ph10@??? said:
> The first Exim tells it! It's all documented; see the -MCT option.

RFC3207 says that when starting TLS, the first Exim MUST discard previous
knowledge of ESMTP extensions previously advertised by the server, and that
it SHOULD send a second EHLO immediately afterwards. It also says the server
MUST NOT advertise STARTTLS on that second EHLO. Which one was naughty?

When we take down the encryption, could we send a RSET immediately
afterwards? That way, if the server doesn't revert to a working unencrypted
session as we expect, we lose still lose the connection but harmlessly. And
if it _does_ accept the RSET, we can be reasonably justified in getting
upset if it doesn't accept STARTTLS again.

> This is a consequence of what was originally envisaged as a relatively
> rare exception case (handling messages that couldn't be immediately
> delivered) escalating into a primary delivery method. I'm afraid my
> fallback position is going to have to be "I didn't write it for that
> kind of use".

Do we even need an outage of the target server to trigger this? What if we
just happen to get two messages on our queue which are for the same host?
The second one will fail when we violate RFC3207 and the server kicks us
off, we'll back off and collect more mail in our queue before we retry,...

--
dwmw2