Time to feed back on this issue I gave this a try, and have been running it for a few weeks now before getting to the point of raising a bug/bugs. In /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp, added:
hosts_try_fastopen = !*.l.google.com Conveniently, when coming to add it, I had a pile of queued messages for delivery via Google MX hosts, and after adding the above config and restarting exim, they all delivered first time. I've not seen any issues of this sort since, both in general day to day running of the server, and in targeted testing. So, it looks like this is a workaround (though, the blog description doesn't match what my packet trace was showing!). Cheers Graeme On 2022-04-30 17:34, Jeremy Harris wrote: > On 30/04/2022 17:43, Adam D. Barratt via Exim-users wrote: > > This is likely to be the result of a known issue with Google's TCP Fast > > Open setup - see e.g. > > https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/ > > Always worth a try, but that blog description doesn't match > what the packet capture showed. > -- > Cheers, > Jeremy > > -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/