Exim - retry time not reached for any host
lysfjord.daniel at smokepit.net
Mon Jun 22 21:03:59 UTC 2020
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
> 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 220.127.116.11).
> I have replaced mail3.gridhost.co.uk with 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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 18.104.22.168 TCP 66
> 12424 → 465 [ACK] Seq=1 Ack=1 Win=66752 Len=0 TSval=2845252029 TSecr=4253626233
> 4 0.033580346 192.168.1.13 22.214.171.124 TLSv1.2 364
> Client Hello
> 5 0.055654137 126.96.36.199 192.168.1.13 TCP 66
> 465 → 12424 [ACK] Seq=1 Ack=299 Win=45056 Len=0 TSval=4253626267 TSecr=2845252041
> 6 0.064630882 188.8.131.52 192.168.1.13 TLSv1.2 1506
> Server Hello
> 7 0.065507499 184.108.40.206 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 220.127.116.11 TCP 66
> 12424 → 465 [ACK] Seq=299 Ack=2881 Win=65344 Len=0 TSval=2845252073
> 9 0.065646720 18.104.22.168 192.168.1.13 TLSv1.2 823
> Certificate, Server Key Exchange, Server Hello Done
> 10 0.066717836 192.168.1.13 22.214.171.124 TLSv1.2 192
> Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
> 11 0.088334588 126.96.36.199 192.168.1.13 TCP 66
> 465 → 12424 [ACK] Seq=3638 Ack=425 Win=45056 Len=0 TSval=4253626299
> 12 0.088559696 188.8.131.52 192.168.1.13 TLSv1.2 117
> Change Cipher Spec, Encrypted Handshake Message
> 13 0.188244024 192.168.1.13 184.108.40.206 TCP 66
> 12424 → 465 [ACK] Seq=425 Ack=3689 Win=66752 Len=0 TSval=2845252196
> 14 0.209855921 220.127.116.11 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
>> 18.104.22.168(mail.gridhost.co.uk), but fails at
>> 22.214.171.124(mail1-a.eqx.gridhost.co.uk) and
>> 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 126.96.36.199,
> 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 188.8.131.52.
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:)
More information about the freebsd-questions