Exim - retry time not reached for any host

Mike Clarke jmc-freebsd2 at milibyte.co.uk
Sun Jun 21 21:34:32 UTC 2020


On Saturday, 20 June 2020 01:07:04 BST Daniel Lysfjord via freebsd-questions wrote:
> On 19.06.2020 17:57, Mike Clarke wrote:
> [..]
> 
> > So it looks very much like the problem lies somewhere in my system even
> > though there's been no changes made recently. I'd appreciate suggestions
> > on how I should go about tracing and fixing the cause of this problem.
> 
> Have you tried to start exim with "-bd -d+all" to get some debug output?


OK, I've done that now and it's highlighted what's happening, though I'm not sure if it helps to 
explain why;


To summarise it looks like the SSL connection fails but eventually succeeds after a number of 
retries although the delay could be an hour or more.


As a workaround I've reverted exim from 4.94 to 4.93.0.4 which does not appear to suffer from this 
problem.


And now for the details:


16:50:53  3161 Connecting to mail.gridhost.co.uk [95.142.156.28]:465 ... 95.142.156.28 in 
hosts_try_fastopen? yes (matched "*")^M
16:50:53  3161  TFO mode connection attempt to 95.142.156.28, 0 data^M
16:50:53  3161  connected^M
16:50:53  3161  ?considering: $primary_hostname^M
16:50:53  3161  ???expanding: $primary_hostname^M
16:50:53  3161  ??????result: curlew.milibyte.co.uk^M
16:50:53  3161 95.142.156.28 in hosts_avoid_esmtp? no (option unset)^M
16:50:53  3161 95.142.156.28 in hosts_require_ocsp? no (option unset)^M
16:50:53  3161 95.142.156.28 in hosts_request_ocsp? yes (matched "*")^M
16:50:53  3161 setting SSL CTX options: 0x42004000^M
16:50:53  3161 Diffie-Hellman initialized from default with 2048-bit prime^M
16:50:53  3161 Initialized TLS^M
16:50:53  3161 95.142.156.28 in tls_verify_hosts? no (option unset)^M
16:50:53  3161 95.142.156.28 in tls_try_verify_hosts? yes (matched "*")^M
16:50:53  3161 tls_verify_certificates: system^M
16:50:53  3161 95.142.156.28 in tls_verify_cert_hostnames? yes (matched "*")^M
16:50:53  3161 Cert hostname to check: "mail.gridhost.co.uk"^M
16:50:53  3161 Calling SSL_connect^M
16:50:53  3161 SSL_connect: before SSL initialization^M
16:50:53  3161 SSL_connect: error in SSLv3/TLS write client hello^M
16:50:53  3161 TLS error '(SSL_connect): error:00000000:lib(0):func(0):reason(0)'^M
16:50:53  3161 TLS session fail: (SSL_connect): error:00000000:lib(0):func(0):reason(0)^M
16:50:53  3161   SMTP(close)>>^M
16:50:53  3161 set_process_info:  3161 delivering 1jn2FA-0000ow-Uy: just tried mail.gridhost.co.uk 
[95.142.156.28]:465 for REDACTED at gmail.com:
result DEFER^M
16:50:53  3161 added retry item for T:mail.gridhost.co.uk:95.142.156.28:465: errno=-37 
more_errno=0,A flags=2^M


This was repeated for the other 3 IP addresses for mail.gridhost.co.uk


Then followed periodic attempts to deliver:


17:10:45  3445 Connecting to mail.gridhost.co.uk [95.142.156.8]:465 ... 95.142.156.8 in 
hosts_try_fastopen? yes (matched "*")^M
 
17:10:45  3445 SSL_connect: error in SSLv3/TLS write client hello^M 
 17:30:45  3493 Connecting to mail.gridhost.co.uk [95.142.156.8]:465 ... 95.142.156.8 in 
hosts_try_fastopen? yes (matched "*")^M  
 
17:30:45  3493 SSL_connect: error in SSLv3/TLS write client hello^M 
 
And eventual success after 1 hour and 20 minutes


18:10:45  3840 Connecting to mail.gridhost.co.uk [95.142.156.18]:465 ... 95.142.156.18 in 
hosts_try_fastopen? yes (matched "*")^M
18:10:45  3840  TFO mode connection attempt to 95.142.156.18, 0 data^M
18:10:45  3840  connected^M
18:10:45  3840  ?considering: $primary_hostname^M
18:10:45  3840  ???expanding: $primary_hostname^M
18:10:45  3840  ??????result: curlew.milibyte.co.uk^M
18:10:45  3840 95.142.156.18 in hosts_avoid_esmtp? no (option unset)^M
18:10:45  3840 95.142.156.18 in hosts_require_ocsp? no (option unset)^M
18:10:45  3840 95.142.156.18 in hosts_request_ocsp? yes (matched "*")^M
18:10:45  3840 setting SSL CTX options: 0x42004000^M
18:10:45  3840 Diffie-Hellman initialized from default with 2048-bit prime^M
18:10:45  3840 Initialized TLS^M
18:10:45  3840 95.142.156.18 in tls_verify_hosts? no (option unset)^M
18:10:45  3840 95.142.156.18 in tls_try_verify_hosts? yes (matched "*")^M
18:10:45  3840 tls_verify_certificates: system^M
18:10:45  3840 95.142.156.18 in tls_verify_cert_hostnames? yes (matched "*")^M
18:10:45  3840 Cert hostname to check: "mail.gridhost.co.uk"^M
18:10:45  3840 Calling SSL_connect^M
18:10:45  3840 SSL_connect: before SSL initialization^M
18:10:45  3840 SSL_connect: SSLv3/TLS write client hello^M
18:10:45  3840 SSL_connect: SSLv3/TLS write client hello^M
18:10:45  3840 SSL_connect: SSLv3/TLS read server hello^M
18:10:45  3840 SSL verify ok: depth=2 SN=/C=US/O=SecureTrust Corporation/CN=SecureTrust 
CA^M
18:10:45  3840 SSL verify ok: depth=1 SN=/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, 
Inc./CN=Trustwave Organization Validation SHA256 CA
, Level 1/emailAddress=ca at trustwave.com^M
18:10:45  3840 SSL authenticated verify ok: depth=0 SN=/CN=*.gridhost.co.uk/O=Paragon 
Internet Group Limited/L=Hayes/ST=England/C=GB^M
... snip ...
18:10:45  3840   SMTP<< 250 2.0.0 Ok: queued as 6BB47221B18C1^M
 
Previous tests have followed a similar pattern but with different times before successful delivery.


Exim was upgraded from 4.93.0.4 to 4.94 a few weeks ago so it's possible this might have been 
happening since then. I don't often look at the exim log so wouldn't have noticed the long delays in 
sending emails.


As an experiment I reverted to 4.93.0.4 and performed more tests with all emails being successfully 
delivered on the first attempt.


This now leaves the question as to whether this is a new bug in 4.94 or if there's some less than 
ideal setting in my configuration which I've managed to get away with over the last few years but is 
causing a problem with the new version.


In case it's relevant here's what I expect to be the appropriate snippets from my exim 
configuration:


milibyte_route:
   driver = manualroute
   domains = !+local_domains
   transport = remote_auth_smtp
   condition = ${if match_domain{${domain:$h_From:}}{milibyte.co.uk}{yes}{no}}
   route_list = * mail3.gridhost.co.uk
   no_more


remote_auth_smtp:
  driver = smtp
  protocol = smtps
  hosts_require_auth = $host_address
  hosts_require_tls = $host_address



More information about the freebsd-questions mailing list