Some email stuck in Exchange 2003 queue

55 pts.
Tags:
Exchange Enterprise Edition
Microsoft Exchange
Microsoft Exchange 2003
Microsoft Exchange errors
TCP
Hi All,

We have a single Exchange 2003 Enterprise server with about 150 users.  Lately - over the last month some emails have begun to languish in the queue until delivery failure.  Other emails from the same senders to the same recipients go through, and internal emails are sent as well.

During troubleshooting, I was able to do a packet trace and see that for a normal email, after about 4 fragments, we begin to receive TCP ACKs from the other server.  With the problem emails, we also receive the ACKs, but the RST flag is set as well.  The TCP window is also widening, so it appears the external server really is ready for more.

It seems that if the user forwards an email that has this issue, the forwarded message also has the issue, and if they put the same content into a new email, it goes through. This gives us a work-around, but I would like to know if this is a known issue?



Software/Hardware used:
Exchange 2003 Enterprise

Answer Wiki

Thanks. We'll let you know when a new response is added.

My guess would be that it is just a consequence that the forwarded email has the problem, unless the receiving email server is intentionally rejecting emails which share a thread id for some reason.

You’ll need to work with the admin of the remote email server to resolve this issue

i think it may problem with remote so please coordiate.

Discuss This Question: 11  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • petkoa
    Could it be an issue related to some graylisting on the remote server?
    3,120 pointsBadges:
    report
  • TimMarks
    Don't really think it is a graylisting issue, but I could be wrong. I thought that the facts pointed in a different direction. The sender is not blocked, as he can send to the same recipients with the same subject line, as long as it's a new mail.
    55 pointsBadges:
    report
  • petkoa
    Graylisting is not about blocking senders - there is a "recent connections table" with the connection source IP for the last, say, 2hr (table entry TTL); every incoming connection is looked up in this table and if the source IP is there, mail is accepted - else, a "service temporarily unavailable" is returned and sending server IP is written to the table... If a second connection is made during the TTL of the table entries, the message is accepted. Thus spam bots which are not queuing temporarily returned mail are filtered out. So if the the queue processing interval is too long (longer than tipical TTL of the entries in graylisting tables) the messages are not going to be delivered - the same, if your server is not properly processing "service temporarily unavailable" message and immediately gives up and returns the message to sender. For me, your symptoms point to a graylisting issue. And, BTW, I assume that graylisting - and for that matter, all spam filtering on the servers - is the worth thing that could happen to a internet mail system (not intended to start a flame war, I had a couple of real wars on this subjects with clients).
    3,120 pointsBadges:
    report
  • petkoa
    the worst , not the worth, of course :o))
    3,120 pointsBadges:
    report
  • TimMarks
    I understand what you mean, but could this be the case even when there are more than one message in the queue and the previous email message to the same server gets through? I mean: TCP handshake -> SMTP session start -> sender, recipient sent (of previous message) -> message data starts -> (series of TCP ACK from other server) -> SMTP Reset (ready for next email) -> sender, recipient sent (of failing message) -> message data starts -> (TCP ACK + RST from other server).
    55 pointsBadges:
    report
  • TimMarks
    Another thing I notice: When the email is sent to multiple domains, it fails on all the domains, not just one or two. Probably should have mentioned before, but if the recipient list is "user1@a.com; user2@b.com; user3@c.com", it will fail at a, b, and c, the same way each time, RST and ACK together.
    55 pointsBadges:
    report
  • petkoa
    > TCP handshake -> SMTP session start -> sender, recipient sent (of previous > message) -> message data starts -> (series of TCP ACK from other > server) -> SMTP Reset (ready for next email) -> sender, recipient sent > (of failing message) -> message data starts -> (TCP ACK + RST from other > server). Well, this still could be consistent with graylisting issue - in case if some rate-limiting mechanism is implemented there... > When the email is sent to multiple domains, it fails on all the domains, > not just one or two. This is another thing - odds are against all addressees having "weird" servers... What's happening if you address message to a list of addresses, one of them erroneous (may be intentionally, for the test)?
    3,120 pointsBadges:
    report
  • Guardian
    Is this happening to all users or just a select few? When mail is sent to other domains a, b & c are these the same domains the users normally send mail to and receives from but sometimes messages delivery fails? As mentioned earlier have you communicated this to the remote server admin and your ISP?
    900 pointsBadges:
    report
  • TimMarks
    >Is this happening to all users or just a select few? When mail is sent to other >domains a, b & c are these the same domains the users normally send mail to and >receives from but sometimes messages delivery fails? So far I have noticed the issue on 4 users in our organization of about 200. Other users also email the same recipients, and even these 4 users are able to communicate with the recipients in some cases. When I had the users start a new email, instead of "forward" or "reply all" on the stuck messages, the new emails went through. >As mentioned earlier have you communicated this to the remote server admin and >your ISP? I have contacted the main recipients' administrator, but we haven't been able to resolve the issue. I didn't contact the ISP, mainly because one of the main recipient domains is one with which we have a direct fiber connection with no ISP equipment between.
    55 pointsBadges:
    report
  • Guardian
    what email application are you using for those 4 clients are there any other applications clogging the client system when they send the email/s? I'm ruling out restrictions here as you have highlighted that when resent the email is relayed & delivered. For those messages queued what does the NDR say? Can we rule out AD related problems and DNS here. This could relate to a bigger problem (if it escalates) or could not. Do these failed deliveries occur randomly or at particular intervals (or time of sending - like sent during the morning) since resending the message is at a different time (after failed delivery) Monitor the routing engine and remote delivery queue are other message delivery slowing down or are there large sized emails at the same time? Also messages are categorized by exchange for the particular server so this might be cause delay or failure to send the message What type of mail server does the recipient use?
    900 pointsBadges:
    report
  • TimMarks
    The four clients all use Outlook 2007, but I think that we might have a misunderstanding. When the clients take the same message that is not going out, and forward it, the forwarded message does not go either. If they just try to resend the same message, it will not go. Only if they start a new email message, even if they copy the content from the old message and paste it into the new email, it will go. I have not tried to copy the old recipient list and paste it, because I just told them to retype that part. Since I have discovered that starting a new message bypasses the issue, we have no more messages being stuck. I am trying now to see if I can determine the cause. The failures do not seem to follow any time pattern, just that when the failure occurs, it goes through retries for the next 3 days, never has success, and then sends out an NDR with the following for each recipient in the domain, a separate NDR for each domain: Your message did not reach some or all of the intended recipients. Subject: RE: Status Sent: 05/15/2011 5:54 PM The following recipient(s) cannot be reached: a@B.COM on 10/17/2010 5:59 PM Could not deliver the message in the time limit specified. Please retry or contact your administrator. <server.domain.com #4.4.7> b@B.COM on 10/17/2010 5:59 PM Could not deliver the message in the time limit specified. Please retry or contact your administrator. <server.domain.com #4.4.7> Other messages to the same domain are going through fine, no slow downs, it will fail about 3 times with the failing message, then connect to the same server again and send all the other mail in the queue for that domain. The message tracker of System Manager is also of little help, saying "SMTP:Started Outbound Transfer of Message" followed by "Message transferred to *************** through SMTP" once for each failed retry. (Actual *s, not server name or anything that I am removing) Our main Communication partner also uses Exchange 2003. Any help is greatly appreciated. I basically had this role thrust upon me a couple of months ago, and have no prior knowledge of Exchange or AD administration other than create a user...
    55 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following