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