On 2022-04-29, Graeme Coates via Exim-users <exim-users@???> wrote:
> 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!
make sure that your DNS and return-path MX are working, we recently
had some sort of firewall issue that was unrelated to SMTP causing
timeouts on deliveries to gmail. removing the firewall rules cleared
it up.
--
Jasen.
