Exim - retry time not reached for any host

[Daniel Lysfjord]

On 22.06.2020 18:13, Mike Clarke wrote:
> 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.

Would be interesting to see what the contents of pkg#2 was compared to 
pkg#2 from the one below. You should reply with an ACK instead of just 
tossing an RST back at him. This means exim just closes the connection, 
for some reason. A "truss -ff" on exim would also be interesting, just 
to see what it's really doing.

> 
> 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.

An intermediate solution would be to put an "exim -Rf" in your crontab, 
if moving to 4.94 is something you really want to do at this point:)

> 
>> 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.
> 

As I said, I was grasping at straws:)

>> 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.
> 

OpenSSL then. As I'm using libreSSL, I've encountered weird bugs like 
this one before:)