Date: Mon, 22 Jun 2020 17:13:02 +0100 From: Mike Clarke <jmc-freebsd2@milibyte.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Exim - retry time not reached for any host Message-ID: <1854884.R0FQcr2YjX@curlew> In-Reply-To: <f9413c03-db27-52de-6a1d-48c2d55df04f@smokepit.net> References: <2534646.NQNxk83B2J@curlew> <2063278.3V7qYkmoPJ@curlew> <f9413c03-db27-52de-6a1d-48c2d55df04f@smokepit.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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, =46or some reason the service provider quotes mail3.gridhost.co.uk in their= email setup instructions=20 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 t= est while monitoring=20 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=09 25272 > 465 [SYN] Seq=3D0 Win=3D65535 Len=3D0 MSS=3D1460 WS=3D64 SACK_PER= M=3D1=20 TSval=3D3438884996 TSecr=3D0 2 0.021859743 95.142.156.18 192.168.1.13 TCP 74=09 465 > 25272 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D43440 Len=3D0 MSS=3D1452 SAC= K_PERM=3D1=20 TSval=3D4269392837 TSecr=3D3438884996 WS=3D2048 3 0.021872274 192.168.1.13 95.142.156.18 TCP 54=09 25272 > 465 [RST] Seq=3D1 Win=3D0 Len=3D0 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 m= y surprise the email=20 was sent No. Time Source Destination Protocol Length Info 1 0.000000000 192.168.1.13 95.142.156.18 TCP 74=09 12424 =E2=86=92 465 [SYN] Seq=3D0 Win=3D65535 Len=3D0 MSS=3D1460 WS=3D64 SA= CK_PERM=3D1=20 TSval=3D2845252007 TSecr=3D0 2 0.021910067 95.142.156.18 192.168.1.13 TCP 74=09 465 =E2=86=92 12424 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D43440 Len=3D0 MSS=3D14= 52 SACK_PERM=3D1=20 TSval=3D4253626233 TSecr=3D2845252007 WS=3D2048 3 0.021923963 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D1 Ack=3D1 Win=3D66752 Len=3D0 TSval=3D28452= 52029 TSecr=3D4253626233 4 0.033580346 192.168.1.13 95.142.156.18 TLSv1.2 364=09 Client Hello 5 0.055654137 95.142.156.18 192.168.1.13 TCP 66=09 465 =E2=86=92 12424 [ACK] Seq=3D1 Ack=3D299 Win=3D45056 Len=3D0 TSval=3D425= 3626267 TSecr=3D2845252041 6 0.064630882 95.142.156.18 192.168.1.13 TLSv1.2 1506=09 Server Hello 7 0.065507499 95.142.156.18 192.168.1.13 TCP 1506=09 465 =E2=86=92 12424 [PSH, ACK] Seq=3D1441 Ack=3D299 Win=3D45056 Len=3D1440 = TSval=3D4253626276=20 TSecr=3D2845252041 [TCP segment of a reassembled PDU] 8 0.065515730 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D299 Ack=3D2881 Win=3D65344 Len=3D0 TSval=3D= 2845252073=20 TSecr=3D4253626276 9 0.065646720 95.142.156.18 192.168.1.13 TLSv1.2 823=09 Certificate, Server Key Exchange, Server Hello Done 10 0.066717836 192.168.1.13 95.142.156.18 TLSv1.2 192=09 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 11 0.088334588 95.142.156.18 192.168.1.13 TCP 66=09 465 =E2=86=92 12424 [ACK] Seq=3D3638 Ack=3D425 Win=3D45056 Len=3D0 TSval=3D= 4253626299=20 TSecr=3D2845252074 12 0.088559696 95.142.156.18 192.168.1.13 TLSv1.2 117=09 Change Cipher Spec, Encrypted Handshake Message 13 0.188244024 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D425 Ack=3D3689 Win=3D66752 Len=3D0 TSval=3D= 2845252196=20 TSecr=3D4253626300 14 0.209855921 95.142.156.18 192.168.1.13 TLSv1.2 132=09 Application Data =2E.. 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=20 again. This time the first 'exim -Rf' failed to release the email but a sec= ond attempt worked. So it looks as if, for me at least, exim 4.94 has a high probability of fai= ling to set up a SSL=20 connection, especially on it's first attempt. The wireshark output for the successful connection shows the same pattern a= s I see with 4.93=20 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). >=20 > 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 m= ade with 95.142.156.18,=20 probably just the luck of the draw that it was that one that came up first = that time. There were just=20 as many failures with that address as with the other three over repeated re= tries in the test in my=20 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=20 assume it will be the standard version in base. =2D-=20 Mike Clarke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1854884.R0FQcr2YjX>