On Thu, 25 Apr 2002, David Woodhouse wrote:
> I'm misunderstanding something; sorry to be so dense. Are you saying that I
> must have misconfigured it to get the following observed behaviour?
I'm saying that we are talking at cross-purposes. :-)
> The messages ended up on the queue, in this case due to a network outage.
OK. That means they *have* been routed, and Exim will have remembered
which message is destined for which host. (You had previously mentioned
queue_only_load - non-delivery for that reason does NOT do the routing.)
> 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.
Yes, that is expected. If I can get the RSET thing to work, it won't
count as a delivery failure, so the delay shouldn't happen.
> Mail gets bounced after sufficient delay.
OK, that's really serious.
> > 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.
If the RSET thing works, 3 & 4 may be irrelevant.
> 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.
Go for it. Lots of people have survived. :-)
> I would definitely say that the default behaviour should be conservative,
> and not make potentially hazardous optimisations.
Had I not made the optimization, nobody would ever have tried it, and we
would never have known. (A bit like the antimalarial pill Lariam I took
last week. Laid me low for several days; I've now got a different one to
try this weekend. Had I not taken Lariam, I would never have known if I
could tolerate it.)
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
