Date: Mon, 22 Jun 2020 23:03:53 +0200 From: Daniel Lysfjord <lysfjord.daniel@smokepit.net> To: freebsd-questions@freebsd.org Subject: Re: Exim - retry time not reached for any host Message-ID: <e3aa92c3-28e9-9f3d-68ef-29b62ccf5b41@smokepit.net> In-Reply-To: <1854884.R0FQcr2YjX@curlew> References: <2534646.NQNxk83B2J@curlew> <2063278.3V7qYkmoPJ@curlew> <f9413c03-db27-52de-6a1d-48c2d55df04f@smokepit.net> <1854884.R0FQcr2YjX@curlew>
next in thread | previous in thread | raw e-mail | index | archive | help
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:)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e3aa92c3-28e9-9f3d-68ef-29b62ccf5b41>