ph10@??? said:
> > 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.
> Exim does behave like that when it's a client.
<...>
> Or, at least, that's the way it's supposed to. Do you have evidence
> to the contrary?
No. I only know that the child Exim tried STARTTLS on the socket it
inherited from the parent, which means _someone_ did something wrong.
If, as is usually reasonable, we assume that Exim is behaving correctly,
then we must conclude that the Postfix server to which my box was talking
must have advertised STARTTLS in the EHLO response immediately following the
TLS setup -- which is explicitly forbidden by RFC 3207.
The actual EHLO responses we received aren't in the output of 'exim -d9'.
I will investigate further.
> No, Exim doesn't work like that. At least, not unless you've
> configured it "unusually", that is, with queue_smtp_domains or using
> -odqs or -qq.
Or queue_only_load.
> If you use the default (style of) configuration, <...>
If I use the default configuration, my poor little dual-P200 box falls over
and waggles its little legs in the air when it gets mailbombed.
I tried that; I didn't like it. Now I set queue_only_load :)
> I designed Exim for our general-purpose, always online hosts which are
> handling general user mail. In our environment, 95% or more of
> messages are delivered at the first attempt. All this "remembering
> hosts" stuff applies only to the < 5% exceptional cases. As they say,
> YMMV.
This I understand. Having the queue runner process inherit sockets from the
server is an optimisation for precisely that 5% about which we don't care,
right? The percentage of cases where the the socket can be reused and the
parent Exim process had actually been using TLS on said socket is even lower.
OTOH, this optimisation has been observed to cause mail to fail to get
delivered, because it causes Exim to behave in a way which although not
explicitly forbidden is at best dubious - from my skim-reading of the RFC I
would not infer that taking down TLS and continuing the session is
permitted.
So forget taking down TLS, sending RSET and hoping the other end either
copes with that or kicks us off immediately for it without causing our next
delivery attempt to fail. Let's just (QUIT and) close the socket and forget
about it if we've been doing TLS over it, rather than passing it to the
child.
IOW, I think the semantics of the hosts_nopass_tls option need reversing -
we should explicitly list the hosts which _will_ accept this behaviour,
rather than the hosts which won't. Would you accept that?
--
dwmw2
