On Wed, 24 Apr 2002, David Woodhouse wrote:
> 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.
> It also says the server
> MUST NOT advertise STARTTLS on that second EHLO. Which one was naughty?
Exim does behave like that when it's a server.
Or, at least, that's the way it's supposed to. Do you have evidence to
the contrary?
> 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.
Good idea. I hadn't thought of that.
> 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,...
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.
If you use the default (style of) configuration, each message that
arrives immediately causes a separate delivery process to run in order
to deliver it. Only if a delivery fails does Exim remember which hosts
it is destined for, in order to send several such messages over a single
connection. If all deliveries are succeeding you can't get "two
deliveries on our queue which are for the same host", at least, not in
the sense you mean. Exim has no record of which message is for which
host until after a delivery has failed (or you used one of the special
options mentioned above).
Exim does NOT have a central process that manages "queues of messages
for hosts" or anything like that. I try to explain all of this in my
book (and to a lesser extent in the reference manual). And, of course,
when I teach courses. <ADVERT> Next one in June. </ADVERT>
When all is going well, each message is handled completely independently
of all others. This is one of the reasons why Exim scales quite well -
the processes do not have to interact with each other very much.
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.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
