Prev: change return-path to custom value
Next: Postfix (Ubuntu 9.10 x64) said: 421 4.4.1 Connection timed out(in reply to end of DATA command)
From: "Ioannis Tsouvalas" on 28 May 2010 05:09 Dear everyone, It's my first posting on mailing list so please accept my apologies for any "gaps" that may appear until I get the hang of the "way things should be said" Case Scenario Esxi implementation hosting the following Zone OS ( url of implementation if any) ==== ============================================================== net fw Ubuntu 9.10 x64 running shorewall as a three interface firewall ( http://www.shorewall.net/three-interface.htm ) dmz Ubuntu 9.10 x64 running shorewall and a postfix mail server with spamassasin and amavis ( http://flurdy.com/docs/postfix/ ) loc Windows SBS 2008 running exchange 2007 using postfix as a smart host. All the systems are using the vmxnet3 NIC with 10Gb links (MTU on all systems are set on 1500) e-mail goes in and out like a charm, in most cases, in some cases we get the following errors with mails getting stuck to be sent again and again without delivery on the Postfix mail queue: said: 451 Requested action aborted: local error in processing (in reply to end of DATA command) said: 451 Temporary local problem - please try later (in reply to end of DATA command) said: 421 4.4.1 Connection timed out (in reply to end of DATA command) said: 421 4.4.2 mxfront39.mail.yandex.net Error: timeout exceeded (in reply to end of DATA command) (lost connection with mx1.mail.eu.yahoo.com[77.238.177.9] while sending end of data -- message may be sent more than once) E-mails that get stuck are mostly with attachments, but not all the receiving mail servers have the same problem. (E.g. mail from the corporate network to my own mail server with a 2mb attachment (gentoo - postfix) arrive with no errors whatsoever.) The interesting part, is that one of the errors is within the corporate network, from postfix to exchange 2007. So far I disabled the window scaling, in /etc/sysctl.conf, and I even disabled amavis. Still the problem persists. It seems to be an issue with e-mails bigger than a simple text message since in other occasions test messages has gone through without an issue on the same destination, or on the same corporate network (@acompanyname.com), but I wouldn't want to point you on the wrong direction. My guess so far is to go and lower the link speed between the Shorewall, Postfix, and maybe even SBS2008, and that's because similar problems having been encountered where the MTU is bigger than 1500. Now, the only reason I haven't done it so far, is that the MTU is already set at 1500, and I'm not sure if dropping the link to a lower speed or replacing the vmxnet3 with vmxnet2 that supports lower speed, would do any good. I'm all ears, hit me with suggestions, corrections, or by pointing out a different way I should be saying things Kind regards Ioannis __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: "Ioannis Tsouvalas" on 28 May 2010 07:41 reply Stan Hoeppner put forth on 5/28/201 5:42 AM: >The vmxnet 'NIC' is a virtual device, strictly a software driver. The >vmxnet driver communicates with the ESX kernel at the speed of system >memory, which on modern servers is over 10x faster than the 10 Gbe >signaling rate. There is no such thing as "link speed" in this >scenario as the interfaces are all software. Ethernet link speed, more >correctly called a link pulse synchronization, is generated by hardware >devices called PHYs. Link pulse is a hardware phenomenon. It doesn't >exist in phantom software drivers, in this case the vmxnet drivers. >Your issue is unrelated to the vmxnet "link speed" settings, unless >there is a bug in the vmxnet driver code. If you send an email from an >instance of Postfix running on a Linux guest to an instance of Exchange >running on a Windows guest, both guests running on the same ESX >physical machine, any communication between the two MTAs will occur via >direct memory copy. The data will never be sent to the physical NIC in >the server. The communication takes place through the ESX virtual >ethernet switch, which again is strictly software. > >-- >Stan Stan thanks for the reply, as well as the insight regarding the difference between soft and hard nic devices. The only reason I'm pointing out the link pulse as well as the MTU, is that my search so far points me towards that direction. Now if there is a bug within the driver, then I guess more communication errors would have occurred, and the issue wouldn't be isolated on the smtp communication. That unfortunately, leads me back to where I started, without even some hope on getting closer to the solution. Looking forward to further insight, - Ioannis __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: "Ioannis Tsouvalas" on 28 May 2010 07:54 >Are there any firewalls between the Postfix and Exchange Server ? > >Mihira Yes there is, shorewall as implemented on the link provided http://flurdy.com/docs/postfix/ -- Ioannis __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: "Ioannis Tsouvalas" on 28 May 2010 07:57 >>Are there any firewalls between the Postfix and Exchange Server ? >> >>Mihira > >Yes there is, shorewall as implemented on the link provided >http://flurdy.com/docs/postfix/ > >-- >Ioannis As well as the shorewall in the three interface firewall http://www.shorewall.net/three-interface.htm __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com
From: "Ioannis Tsouvalas" on 28 May 2010 09:25
Stan Hoeppner put forth on 5/28/2010 06:41 AM > >Per the list welcome messages, you should post the complete output of >"postconf -n". This will aid members in solving your issue, if the cause of >your problem is indeed related to your Postfix configuration. > >-- >Stan Postconf -n output: alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases append_dot_mydomain = no biff = no config_directory = /etc/postfix delay_warning_time = 4h disable_vrfy_command = yes inet_interfaces = all local_recipient_maps = mailbox_size_limit = 0 masquerade_domains = mail.mydomain.gr www.mydomain.gr masquerade_exceptions = root maximal_backoff_time = 8000s maximal_queue_lifetime = 7d minimal_backoff_time = 1000s mydestination = mydomain = aplawyers.gr mynetworks = 192.168.1.1 192.168.100.20 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mynetworks_style = 192.168.100.20 host myorigin = aplawyers.gr readme_directory = no recipient_delimiter = + relay_domains = mysql:/etc/postfix/mysql_relay.cf relayhost = smtp_data_xfer_timeout = 600s smtp_helo_timeout = 60s smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client dnsbl.njabl.org smtpd_data_restrictions = reject_unauth_pipelining smtpd_delay_reject = yes smtpd_hard_error_limit = 12 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_limit = 16 smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit smtpd_sender_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit smtpd_soft_error_limit = 3 smtpd_tls_cert_file = /etc/postfix/postfix.cert smtpd_tls_key_file = /etc/postfix/postfix.key smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes transport_maps = mysql:/etc/postfix/mysql_transport.cf unknown_local_recipient_reject_code = 450 virtual_alias_maps = mysql:/etc/postfix/mysql_alias.cf virtual_gid_maps = mysql:/etc/postfix/mysql_gid.cf virtual_mailbox_base = /var/spool/mail/virtual virtual_mailbox_domains = mysql:/etc/postfix/mysql_domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox.cf virtual_uid_maps = mysql:/etc/postfix/mysql_uid.cf standing by, Ioannis __________ Information from ESET Smart Security, version of virus signature database 5152 (20100528) __________ The message was checked by ESET Smart Security. http://www.eset.com |