Exim - retry time not reached for any host

[Mike Clarke]

On Monday, 22 June 2020 11:27:30 BST Daniel Lysfjord via freebsd-questions wrote:

> In your route_list, you have mail3.gridhost.co.uk, not that it should
> matter,

For some reason the service provider quotes mail3.gridhost.co.uk in their email setup instructions 
despite it advertising itself as mail.gridhost.co.uk.

> but you could try changing that to mail.gridhost.co.uk (or,
> possibly 95.142.156.18).

I have replaced mail3.gridhost.co.uk with 95.142.156.18 and tried another test while monitoring 
with wireshark. The output showed only 3 packets being transmitted:

No.	Time	Source	Destination	Protocol	Length	Info
1	0	192.168.1.13	95.142.156.18	TCP	74	
25272  >  465 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 
TSval=3438884996 TSecr=0
2	0.021859743	95.142.156.18	192.168.1.13	TCP	74	
465  >  25272 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1452 SACK_PERM=1 
TSval=4269392837 TSecr=3438884996 WS=2048
3	0.021872274	192.168.1.13	95.142.156.18	TCP	54	
25272  >  465 [RST] Seq=1 Win=0 Len=0

And that was all there was, absolutely nothing after the RST packet.

I then tried your earlier suggestion of 'exim -Rf @gmail.com' and much to my surprise the email 
was sent

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000000	192.168.1.13	95.142.156.18	TCP	74	
12424 → 465 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 
TSval=2845252007 TSecr=0
2	0.021910067	95.142.156.18	192.168.1.13	TCP	74	
465 → 12424 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1452 SACK_PERM=1 
TSval=4253626233 TSecr=2845252007 WS=2048
3	0.021923963	192.168.1.13	95.142.156.18	TCP	66	
12424 → 465 [ACK] Seq=1 Ack=1 Win=66752 Len=0 TSval=2845252029 TSecr=4253626233
4	0.033580346	192.168.1.13	95.142.156.18	TLSv1.2	364	
Client Hello
5	0.055654137	95.142.156.18	192.168.1.13	TCP	66	
465 → 12424 [ACK] Seq=1 Ack=299 Win=45056 Len=0 TSval=4253626267 TSecr=2845252041
6	0.064630882	95.142.156.18	192.168.1.13	TLSv1.2	1506	
Server Hello
7	0.065507499	95.142.156.18	192.168.1.13	TCP	1506	
465 → 12424 [PSH, ACK] Seq=1441 Ack=299 Win=45056 Len=1440 TSval=4253626276 
TSecr=2845252041 [TCP segment of a reassembled PDU]
8	0.065515730	192.168.1.13	95.142.156.18	TCP	66	
12424 → 465 [ACK] Seq=299 Ack=2881 Win=65344 Len=0 TSval=2845252073 
TSecr=4253626276
9	0.065646720	95.142.156.18	192.168.1.13	TLSv1.2	823	
Certificate, Server Key Exchange, Server Hello Done
10	0.066717836	192.168.1.13	95.142.156.18	TLSv1.2	192	
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
11	0.088334588	95.142.156.18	192.168.1.13	TCP	66	
465 → 12424 [ACK] Seq=3638 Ack=425 Win=45056 Len=0 TSval=4253626299 
TSecr=2845252074
12	0.088559696	95.142.156.18	192.168.1.13	TLSv1.2	117	
Change Cipher Spec, Encrypted Handshake Message
13	0.188244024	192.168.1.13	95.142.156.18	TCP	66	
12424 → 465 [ACK] Seq=425 Ack=3689 Win=66752 Len=0 TSval=2845252196 
TSecr=4253626300
14	0.209855921	95.142.156.18	192.168.1.13	TLSv1.2	132	
Application Data

... and continued with more traffic until completion.

Just in case I'd got lucky with the random way that retries appear to work I tried the same process 
again. This time the first 'exim -Rf' failed to release the email but a second attempt worked.

So it looks as if, for me at least, exim 4.94 has a high probability of failing to set up a SSL 
connection, especially on it's first attempt.

The wireshark output for the successful connection shows the same pattern as I see with 4.93 
which always connects successfully at the first attempt.

> It seems like your successful attempt are at
> 95.142.156.18(mail.gridhost.co.uk), but fails at
> 95.142.156.8(mail-beta.gridhost.co.uk),
> 95.142.156.16(mail1-a.eqx.gridhost.co.uk) and
> 95.142.156.28(mail4-e.eqx.gridhost.co.uk).
> 
> Could it be that you're finding a corner case in exim, because of that
> circular dns resolving? mail.gridhost.co.uk does have multiple A
> records, one of those has a PTR back to mail.gridhost.co.uk, where the
> rest does not.

I don't think there's any significance of the successful connection being made with 95.142.156.18, 
probably just the luck of the draw that it was that one that came up first that time. There were just 
as many failures with that address as with the other three over repeated retries in the test in my 
earlier post in this thread. Anyway my latest tests restricted exim to use only 95.142.156.18.

> What SSL library is your exim compiled with?

I installed exim from packages and can't see any obvious reference to which SSL library it uses but I 
assume it will be the standard version in base.

-- 
Mike Clarke