Hi Viktor, Am 10.09.2014 um 23:03 schrieb Viktor Dukhovni: > This trace has an insane level of debugging turned on, to the point > that syslogd is overwhelmed and is losing messages. PLEASE DISABLE > ALL VERBOSE logging. NO "-v" options in master.cf, NO debug_peer_list, > ... Yes, sorry, I cranked up the debug level, since normal logging looks like this:
Sep 11 09:43:31 mail postfix/smtpd[25170]: connect from mail18-21.srv2.de[193.169.181.21] Sep 11 09:43:31 mail postfix/smtpd[25170]: 2C076C4026A: client=mail18-21.srv2.de[193.169.181.21] Sep 11 09:46:33 mail postfix/smtpd[25170]: lost connection after DATA (33290 bytes) from mail18-21.srv2.de[193.169.181.21] Sep 11 09:46:33 mail postfix/smtpd[25170]: disconnect from mail18-21.srv2.de[193.169.181.21] ... Sep 11 10:10:59 mail postfix/smtpd[25537]: connect from quattuorocto.psi.cust-cluster.com[195.140.187.48] Sep 11 10:10:59 mail postfix/smtpd[25537]: 8736FC40A7D: client=quattuorocto.psi.cust-cluster.com[195.140.187.48] Sep 11 10:36:44 mail postfix/smtpd[25537]: lost connection after DATA (36809 bytes) from quattuorocto.psi.cust-cluster.com[195.140.187.48] Sep 11 10:36:44 mail postfix/smtpd[25537]: disconnect from quattuorocto.psi.cust-cluster.com[195.140.187.48] .. Sep 11 10:38:48 mail postfix/smtpd[25913]: connect from smtp-out-127-108.amazon.com[176.32.127.108] Sep 11 10:38:49 mail postfix/smtpd[25913]: 2558DC40458: client=smtp-out-127-108.amazon.com[176.32.127.108] Sep 11 10:41:01 mail postfix/smtpd[25913]: lost connection after DATA (17511 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Sep 11 10:41:01 mail postfix/smtpd[25913]: disconnect from smtp-out-127-108.amazon.com[176.32.127.108] I didn't think that info alone was particularly useful... > Please make sure that the /dev/log syslog socket is a "dgram" not > a "stream" socket, and that mail logging is not synchronous. Logging is not synchronous, the socket is a datagram socket (it has all been set up that way all along). No change, still the same problem, see above. Meanwhile, I've managed to record a tcpdump of such a failed session. What exactly am I looking for there? I don't see anything out of the ordinary, except increasing delays between received packets from the external host, until the host sends a "RST". It seems I simply do not receive any packets. The ones I get are immediately ACK'd, but then there's seconds and later minutes until the next one even arrives, until finally the remote host gives up and terminates the connection. I'll try to get more dumps for comparison, including some from hosts that have no problems delivering. There's no packet filtering or rate limiting on port 25, at least not on my machine. The hosting provider might have something there, I'd have to ask them... Regards, Sean
