12-21-2011 10:57 PM
Hi,
can anybody help me.
I saw this error while i show detail on message tracking. the email is not sent to address.
pls help.
12-23-2011 04:14 AM
Hello Mustapha,
that a quiet generic error, I'd suppose it's a rather large message that did not make it within the fixed five minutes timeout we have for message delivery. Could you post all lines starting from "New SMTP DCID" for the message in question?
Regards,
Andreas
01-10-2012 05:56 PM
Protocol SMTP interface Data2 (IP ironport) on incoming connection (ICID 13018752) from sender IP enel server. Reverse DNS host mailsvr.ums.edu.my verified yes. | |
03 Jan 2012 01:57:41 (GMT +08:00) | (ICID 13018752) RELAY sender group RELAYLIST match my network SBRS rfc1918 |
---|---|
03 Jan 2012 01:57:41 (GMT +08:00) | Start message 5984691 on incoming connection (ICID 13018752). |
01-10-2012 11:57 PM
Hello Mustapha,
that's an incoming connection (ICID) that you show here, the error however is generated on an outbound connection (DCID). See my previous request.
Regards,
Andreas
02-07-2012 12:02 AM
ops. sorry mistake..
02-13-2012 06:54 AM
Hello Mustapha,
sory, still not sufficient. Note my original request:
Could you post all lines starting from "New SMTP DCID" for the message in question?
So there should be multiple entries for a single DCID, where I can see if the timeout is based on the message taking to long to get delivered.
Regards,
Andreas
02-23-2012 12:12 AM
like this
02-27-2012 04:57 AM
OK, if you check the time delivery starts, and the time the error occurs, you'll notice that it is always 5 minutes, which is the fixed delivery intervall AsyncOS is set to. Most likely the remote host is lacking bandwith, lthough the file here is only 130k, so it might also be an MTU issue on their end, considering your delivery with other hosts works without problem. I suggest that you set up a domain debug log with the domain in question, and check how far delivery goes. If the log only shows the message headers, and stops at the "data" section, then an MTU problem is the cause, so thei'd need to fix their firewall to allow ICMP path discovery trough. If you see data transmitted after the header part, then their bandwith is too slow. In this case it sometimes helps to configure a destination control entry for that domain, which limits the number of concurrent connections to one, or two at most - even if that sounds like a drastic change (however, 5 minutes to get 130k trough...not much of a choice I'd say).
Hope that helps,
Andreas
02-06-2013 08:06 PM
What is best practice from cisco?
02-12-2013 12:47 AM
Hello Mustapah,
is your question related to the delivery errors above? Just asking because that discussion is one year old already, and I am not sure what you mean by best practice in this matter.
Regards,
Andreas
03-13-2013 05:34 PM
Hi Andrea.
"I suggest that you set up a domain debug log with the domain in question, and check how far delivery goes. If the log only shows the message headers, and stops at the "data" section, then an MTU problem is the cause, so thei'd need to fix their firewall to allow ICMP path discovery trough. If you see data transmitted after the header part, then their bandwith is too slow. In this case it sometimes helps to configure a destination control entry for that domain, which limits the number of concurrent connections to one, or two at most - even if that sounds like a drastic change (however, 5 minutes to get 130k trough...not much of a choice I'd say)."
can u guide me above ur mention...
03-14-2013 04:34 AM
Hi Mustapah,
go to Administration->Log subscription and create a new log of type "Domain Debug Log". State the domain you are having problems with, and make the number of SMTP sessions at least 20. Once you are running in the problem again, download that log and check the content for the events mentioned in my earlier explanation.
Hope that helps,
Andreas
09-15-2016 11:34 PM
09-15-2016 11:44 PM
Hello Avaneesh,
have you tried the above recommendations regarding setup a domain debug log? If so, do you face the issue highlighted in this thread? Typically the timeouts are caused by ICMP traffic being blocked so that Path MTU Discovery (RFC 1191, see http://www.ietf.org/rfc/rfc1191.txt) is disabled.
Best regards,
Martin
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: