Hi list,
sorry for my belated reply.
First of all: thanks for the input to everyone suggesting where / what the
error may be.
What I tried so far:
1) reducing the MTU all the way down to 1400 - no change, error still persists.
2) sniffing the connection: nothing suspicious, one or two RST flags in a bunch
of 1800 packets
3) Uncomment the filters we use, to rule them out as an error cause: this was
partly successful; with every filter uncommented the error still persists
4) deactivate the tcp_window_scaling -> the problem still persists
5) removed the comment from this line:
relay unix - - - - - smtp
# -o smtp_helo_timeout=120 -o smtp_connect_timeout=120
6) Added the following entry to the master.cf
smtp inet n - - - - smtpd
-o content_filter=spamassassin
->> -o receive_override_options=no_address_mappings
However, the error still persists.
I set postfix to log verbosely, to find similarities or differences between
those mails that pass without any problems at all, and those which get stuck in
the queue.
However, the mails which "loose connection" are neither especially big nor very
small, they range from 20445 up to 82680 and sometimes get blocked, sometimes
they don't.
What I could gather from the logs:
- the delay varies massively and apparently has no influence on whether a mail
gets stuck or not
- the mails all hang with the status "dsn=4.4.2, status=deferred"
Thanks in advance for any input regarding this matter.
Niclas
-----Ursprüngliche Nachricht-----
Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
Im Auftrag von Wietse Venema
Gesendet: Montag, 27. November 2017 21:39
An: Postfix users <postfix-users@postfix.org>
Betreff: [MASSMAIL]Re: Duplicate mails in mailq / always_bcc
Niclas Rautenhaus:
> 5086760443 35318 Mon Nov 13 16:04:20
> u...@externaldomain.tld<mailto:u...@externaldomain.tld>
> (lost connection with 192.168.N.NN[192.168.N.NN] while sending end of
> data -- message may be sent more than once)
This is the result of Postfix reading EOF, not a Postfix timeout (that produces
a different error message).
Postfix may read EOF as the result of some other error at a lower layer in the
network stack.
A more precise determination would require a network sniffer. Just the packet
metadata (no data content) might be sufficient.
Wietse
