11-28-2016 01:47 PM
Just recently (last week or so)we started to get an usual number of soft bounced emails to domains that worked before. We have not implemented any changes on our end. All soft bounced emails are showing the error: Reason: 4.4.0 - Other network problem ('000', ['[Errno 60] Operation timed out']) []
We are running version 9.6.0-042.
11-28-2016 11:15 PM
I'd suspect that ICMP traffic is blocked, so that Path MTU Discovery (RFC1191) cannot succeed in negotiating the correct MTU size. If the "needs fragmentation" response (ICMP Type 3 code 4) is suppressed by a firewall, the operation times out.
You could run a packet capture to confirm this suspect. Also a domain debug log could help here as typically you'll see in it that the SMTP session is established with EHLO, MAIL FROM and DATA, but after sending the first DATA chunk over the session the session times out after five minutes.
Best regards,
Martin
11-29-2016 02:04 PM
Any reason why it started happening? I have three domains that this is happening too but we were able to get to them before.
11-29-2016 11:31 PM
There are two reasons here:
First, there is an ASA/PIX firewall with ESMTP inspection turned on within the communication path. This will disallow SMTP Authentication as well as TLS communication. The "250 STARTTLS" banner advertisement is changed to "250 XXXA" hence the sender (in this case - your appliance) will never attempt TLS. If the ASA/PIX is within your network perimeter, please consider to disable the ESMTP inspection or SMTP fixup option here.
Second: The TCP retransmission as well as your domain debug log confirms that ICMP traffic is blocked here. A TCP packet with 1368 bytes is not receiving an ACK from the desitination end and requires a retransmission that will never reach it's destination. The EHLO, MAIL FROM, RCPT TO and DATA commands pass through, as the resulting TCP packet size is way below 1368 bytes. The issue starts when the destination requires a lower MTU size than 1368 bytes (this is why some domains work while others do not). The first TCP packet with the mail data after the DATA command will use the manimum MTU size (unless you send a mail with much lower datat content in it
You can solve this in two ways: the correct fix would be to allow ICMP traffic across the network path (at least ICMP type 3 code 4), so that Path MTU discovery can negotiate the correct MTU size for each communicaton path. A "dirty" fix would be to set the ESA appliance to a way lower MTU size under CLI:etherconfig -> mtu and try again if this enables communication to the destination servers.Please do not forget to commit your changes in the CLI with the command "commit".
Best regards,
Martin
11-30-2016 06:11 PM
On my end I do have the ESMTP inspection disabled and asking the other end to do the same each time we run across this isn't feasible.
I also changed the MTU in 200 increments down to 600 and it still do not work.
Any other ideas. Really appreciate the help.
11-30-2016 11:05 PM
I'd recommend to investigate why you have TCP retransmits. It seems that there is no ACK from the remote site for the packets you're sending here.
11-29-2016 03:19 PM
Here is the domain debug with lines some lines omitted
Tue Nov 29 16:37:55 2016 Info: Time offset from UTC: -21600 seconds
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '220 ******************'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'EHLO '
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250- Hello pleased to meet you'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250-SIZE 100000000'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250-PIPELINING'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250-8BITMIME'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250 XXXA'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'MAIL FROM:SIZE=9577'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250 Sender OK'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'RCPT TO:<>'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '250 Recipient <> OK'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'DATA'
Tue Nov 29 16:38:07 2016 Info: 1703711 Rcvd: '354 Start mail input; end with <CRLF>.<CRLF>'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'IronPort-PHdr:
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'X-IronPort-Anti-Spam-Filtered: true\r\n'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'X-IronPort-Anti-Spam-Result:
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'X-IPAS-Result:
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'X-IronPort-AV: E=McAfee;i="5700,7163,8364"; a="6945037"\r\n'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: 'X-IronPort-AV: E=Sophos;i="5.31,717,1473138000"; \r\n d="scan\'208,217";a="6945037"\r\n'
Tue Nov 29 16:38:07 2016 Info: 1703711 Sent: '.\r\n'
08-21-2024 05:26 AM
check the issue at the destination Firewall which is dropping the messages
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide