Hi all,
I've seen this issue raised in:
https://lists.exim.org/lurker/message/20220216.071725.892984cd.en.html
and
https://lists.exim.org/lurker/message/20220313.200645.624cc373.en.html
but haven't seen a definite resolution as yet.
As per other reports, I have a Debian Bullseye (11.3) system running Exim
4.94.2 #2. It is setup with virtual domains using dovecot for local delivery
and aliases defined for some simple forwarding. I wasn't aware of any
similar issue in Exim 4.92 (on Debian 10). I see log reports similar to
other reports - eg:
/var/log/exim4/mainlog:2022-04-27 07:47:30 1njbGQ-005LxL-M5
H=gmail-smtp-in.l.google.com [2a00:1450:4010:c0e::1a]: SMTP timeout after
sending data block (199774 bytes written): Connection timed out
/var/log/exim4/mainlog:2022-04-27 07:50:10 1njbGU-005Lz8-RV
H=gmail-smtp-in.l.google.com [74.125.131.26]: SMTP timeout after end of data
(246239 bytes written): Connection timed out
This is for both ipv4 and ipv6 connections, and to only Google mail servers,
and only when delivering "large" messages (that are bigger than say about
100kb, though I haven't investigated fully the limits - short, text only is
fine). Eventually, the messages do get through, but with delays of hours in
some cases. As per other reports, delivery of the same mail to all other
hosts works perfectly. This occurs both with firewall rules set to allow
everything, as well as with a "normal" ruleset allowing: all
OUTBOUND/FORWARD, all icmp INBOUND and all TCP INBOUND with ctstate
RELATED,ESTABLISHED (as well as ports opened for relevant services).
If I do: sysctl net.ipv4.tcp_window_scaling=0 , then everything works
perfectly - with tcp_window_scaling=1, the issue is reproduced.
I have a packet capture which is available here:
https://tinyurl.com/742s855d
The Session log from Exim in debug mode is here (with redacted hosts,
addresses, etc) - the message was delivered to the server, and is being
forwarded onto an email in a Google workspace account (following a
forwarding rule in an aliases file)
https://tinyurl.com/22nn887u
Is it possible from these traces to pin down the issue at all and maybe come
up with a workround (without having to turn off tcp_window_scaling) or a
pointer as to where I need to formally raise a bug, and I'll be happy to do
so!
Thanks
Graeme
--
graeme at chromosphere dot co dot uk
