Incoming connection lost. Message xxxx aborted: Receiving aborted

[Ken Leung]

Greetings!

I am seeing an issue with certain senders whereas they send an email and during the transmission the connection is lost.  The message details on the B10 show this:

we have found the same issue from other incoming msg from other senders. 

04 Aug 2014 13:14:55 (GMT +08:00)	Protocol SMTP interface InboundMail (IP xxx.xxx.xxx.xxx) on incoming connection (ICID 433844) from sender IP xxx.xxx.xxx.xxx. Reverse DNS host ocmas05.netvigator.com verified yes.
04 Aug 2014 13:14:55 (GMT +08:00)	(ICID 433844) ACCEPT sender group UNKNOWNLIST match sbrs[-1.0:10.0] SBRS 5.5
04 Aug 2014 13:14:55 (GMT +08:00)	Start message 227072 on incoming connection (ICID 433844).
04 Aug 2014 13:14:55 (GMT +08:00)	Message 227072 enqueued on incoming connection (ICID 433844) from xxx@netvigator.com.
04 Aug 2014 13:14:55 (GMT +08:00)	Message 227072 on incoming connection (ICID 433844) added recipient (me@company.com).
04 Aug 2014 13:19:56 (GMT +08:00)	Incoming connection (ICID 433844) lost.
04 Aug 2014 13:19:56 (GMT +08:00)	Message 227072 aborted: Receiving aborted

[Andreas Mueller]

Hello uniqueshipping,

this is most likely an MTU problem, there is a five minute gap between the recipient being added, and the connection getting lost. What we see here is a standard TCP timeout, caused by the appliance not seeing any data sent, which happens at the moment when the sender issues the "data" command, to send the main email body. This is when larger packets will be send, and an MTU mismatch between sender and recipient will cause packet truncation. Please check if ICMP is blocked on your firewalls, this needs to be enabled in order to get MTU path discovery, which is responsible for negotiating the correct packet sizes between two hosts. As a temporary workaround, you could also lower the MTU on your incoming interface, but note that this is not considered a permanent solution.

Hope that helps,

Andreas