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