On 18 November 2015 at 16:18, Wietse Venema <wie...@porcupine.org> wrote:
> > This ends with: > > Nov 18 10:28:52 mailserver postfix/smtpd[31664]: < unknown[1.1.1.1]: > RCPT TO:<test-2cb1eaec-bcba-4cc2-b76e-974bf87b2...@mailinator.com> > ... > Nov 18 10:28:52 mailserver postfix/smtpd[31664]: > unknown[1.1.1.1]: > 250 2.1.5 Ok > ... > Nov 18 10:28:52 mailserver postfix/smtpd[31664]: smtp_get: EOF > Nov 18 10:28:52 mailserver postfix/smtpd[31664]: lost connection after > RCPT from unknown[1.1.1.1] > > Something broke the SMTP connection after Postfix replied with "250 > 2.1.5 Ok". I suspect that you have some spambot detection system > that interferes with SMTP. > > > [4] TCP stream decoded acket capture of above session > > http://pastebin.centos.org/36261/ > > This ends with: > > RCPT TO:<test-2cb1eaec-bcba-4cc2-b76e-974bf87b2...@mailinator.com> > 250 2.1.5 Ok > RCPT TO:<test-5f6f7a2d-d5f8-402e-8314-f6ef3dc46...@mailinator.com> > Note that the last RCPT TO command was not delivered to Postfix. I > therefore suspect that you have some anti-malware system that breaks > connections when a client sends suspicious email. > > I checked the hardware firewall config, which does have a threat detection & shunning capability but nothing was popping up in the logs during the session. I've placed a test client on the same network LAN as the Postfix server and repeated the test with the same result. My next step was, using a console telnet client, to repeat the commands sent by the client in the packet trace (http://pastebin.centos.org/36261/) by literally pasting from one putty client to another. I thought that at human-speeds this may alleviate any time-critical internal funtionality that Wieste mentioned, copied below. [1] As soon as I get the 100th RCPT TO, bam, the connection drops out: Nov 20 16:08:04 mailserver postfix/smtpd[2254]: timeout after RCPT from unknown[192.168.11.50] Nov 20 16:08:04 mailserver postfix/smtpd[2254]: disconnect from unknown[192.168.11.50] I know that ClamAV exists on the server but I'm not sure it's involved scanning email, wouldn't this be configured in main.cf? Thanks, [1] Wieste's comment. Perhaps you're sending invalid recipients and triggering error delays. Or you have a slow virtual alias table lookup table (SQL, ...) and by the 100th recipient the pipeline between smtpd(8) and cleanup(8) stalls because cleanup recipient rewriting is not keeping up. ...
