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

Top Page
Delete this message
Reply to this message
Author: David Woodhouse
Date:  
To: exim-users
Subject: Re: [Exim] Re: closed connection in response to STARTTLS.
ph10@??? said:
> Hmm. I guess that reading is based on the general rule that the client
> must not try any option that isn't advertised?


Yes. As you say, this behaviour may not be explicitly forbidden, but at
best it's dubious.

> I repeat: that will NOT record which hosts messages are destined for.
> Each message will be delivered independently, but from queue runs
> instead of in immediate delivery processes. (Unless you use -qq to
> start a queue run, as previously stated.)


I'm misunderstanding something; sorry to be so dense. Are you saying that I
must have misconfigured it to get the following observed behaviour?

The messages ended up on the queue, in this case due to a network outage. An
Exim daemon was running with -q1h., but there was a constant supply of
incoming messages which appeared to cause retries to occur more frequently.
The observed behaviour is that it seemed to deliver one message about every
20 minutes, followed immediately by the failed TLS negotiation as discussed,
followed by another backoff period of 20-or-so minutes before it would try
again.

> It may cause mail to be delayed, but I don't believe it causes mail
> to fail to be delivered.


Mail gets bounced after sufficient delay.

In the above situation, we manage to deliver about 72 messages a day to the
host in question. Given an input which is significantly higher in volume,
those messages are just going to build up on the queue. Without intervention
they _would_ have started bouncing after a few days. Admittedly, I'll
normally notice something's wrong if my incoming mail goes down to 72
messages a day, but there are occasional weeks when I wouldn't.

> 3. Change the default for hosts_nopass_tls to be *.
> 4. Replace hosts_nopass_tls with hosts_pass_tls, defaulting unset,


I'd say 3, possibly also 4 if we can support _both_ hosts_pass_tls and
hosts_nopass_tls for compatibility with existing configurations.

To be honest, it doesn't affect me much - I know how to fix it now; I just
have to find the courage to upgrade to Exim 4.

I would definitely say that the default behaviour should be conservative,
and not make potentially hazardous optimisations.

--
dwmw2