Re: meaning of connect immediately followed by disconnect in mail log
On Thu, Apr 16, 2009 at 10:27:33AM -0400, Kevin Murphy wrote: postfix 2.1.5 (Mac OS X 10.4.11, Tiger), logging set to debug level: Out of curiosity, what do empty connect/disconnect pairs in the mail log mean? I.e.: Mar 19 09:50:19 jupiter postfix/smtpd[1452]: connect from mx3.westat.com[198.232.249.38] Mar 19 09:50:20 jupiter postfix/smtpd[1452]: disconnect from mx3.westat.com[198.232.249.38] In this example, the user at westat.com was told by his mail server that his email could not be delivered to our mail server. However, I see no indications of errors in the mail log. In the prior minute there were only 5 connects, so load on the box was small. I see lots of these connect/disconnect pairs in my logs, at least 17% of all connections. Over 99% of westat's connections to our mail server over the last month had this result. Firewall brain-damage? Does your server have ECN enabled, is window-scaling on by default? I find that a public mail-server can rarely afford to have modern TCP options enabled and still send/receive mail to/from systems behind random vendor's firewall. So on Linux 2.6 systems, I have: net.ipv4.tcp_adv_win_scale = 0 net.ipv4.tcp_ecn = 0 the second is the default for now, but the first is needed, because the default window scale is 0. This problem is resolved via tcpdump... -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: meaning of connect immediately followed by disconnect in mail log
* Victor Duchovni victor.ducho...@morganstanley.com: Firewall brain-damage? Does your server have ECN enabled, is window-scaling on by default? I find that a public mail-server can rarely afford to have modern TCP options enabled and still send/receive mail to/from systems behind random vendor's firewall. Amen to that!!! -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de Don't judge too fast! Some are gurus, but most of us mortals just read the documentation that comes with the TLS patch.-- Patrick Koetter
Re: meaning of connect immediately followed by disconnect in mail log
Victor Duchovni: On Thu, Apr 16, 2009 at 10:27:33AM -0400, Kevin Murphy wrote: postfix 2.1.5 (Mac OS X 10.4.11, Tiger), logging set to debug level: Out of curiosity, what do empty connect/disconnect pairs in the mail log mean? I.e.: Mar 19 09:50:19 jupiter postfix/smtpd[1452]: connect from mx3.westat.com[198.232.249.38] Mar 19 09:50:20 jupiter postfix/smtpd[1452]: disconnect from mx3.westat.com[198.232.249.38] In this example, the user at westat.com was told by his mail server that his email could not be delivered to our mail server. However, I see no indications of errors in the mail log. In the prior minute there were only 5 connects, so load on the box was small. I see lots of these connect/disconnect pairs in my logs, at least 17% of all connections. Over 99% of westat's connections to our mail server over the last month had this result. Firewall brain-damage? Does your server have ECN enabled, is window-scaling on by default? I find that a public mail-server can rarely afford to have modern TCP options enabled and still send/receive mail to/from systems behind random vendor's firewall. So on Linux 2.6 systems, I have: net.ipv4.tcp_adv_win_scale = 0 net.ipv4.tcp_ecn = 0 the second is the default for now, but the first is needed, because the default window scale is 0. This problem is resolved via tcpdump... As of 20090109, Postfix 2.6 supports a workaround. Below is a quote from the Postfix 2.6 release notes. Wietse Specify tcp_windowsize = 65535 (or less) to work around routers with broken TCP window scaling implementations. This is perhaps more convenient than collecting tcpdump output and tuning kernel parameters by hand. With Postfix TCP servers (smtpd(8), qmqpd(8)), this feature is implemented by the Postfix master(8) daemon. To change this parameter without stopping Postfix, you need to first terminate all Postfix TCP servers: # postconf -e master_service_disable=inet # postfix reload This immediately terminates all processes that accept network connections. Then you enable Postfix TCP servers with the updated tcp_windowsize setting: # postconf -e tcp_windowsize=65535 master_service_disable= # postfix reload If you skip these steps with a running Postfix system, then the tcp_windowsize change will work only for Postfix TCP clients (smtp(8), lmtp(8)). Of course you can also do postfix stop and postfix start, but that is more disruptive.
