We are having a problem with emails that are sent via Exchange 2003 SP2 being retried and retried and finally just being NDR'd after 24 hours. There is seemingly no logical reason. It seems to be domain-dependant, but I cannot find commonality between any of the problem domains. Here is what I have found so far: Some domains work, but others don't The source Exchange server is not blacklisted on any of the blacklist sites. We're not getting back any errors until 2 days (the expiration time for our Exchange queue) and then it says it was returned for an unexplained reason. I've configured and examined the SMTP logs, and it appears the handshaking goes fine until the remote mail server asks for data ("feed me", etc..), then nothing happens. The connection finally times out and the email it put into the Exchang queue. It will retry and retry and finally be bounced back to the sender. I've tried clearing the queues, but the problems persist. The problems started about 4 days ago, and is currently affecting two clients of mine who are completely separate except for the fact that both have ATT as an ISP. I'm not sure that ATT is at fault, because the SMTP logs show connection and mostly normal communication to the remote mail server, up to the point of sending the data. Here is a sample of a "stuck" email from the SMTP log: 2007-12-10 17:59:26 64.18.5.13 OutboundConnectionCommand SMTPSVC1 - EHLO pacbell.net 0 4 0 312007-12-10 17:59:26 64.18.5.13 OutboundConnectionResponse SMTPSVC1 - - 250-Postini+says+hello+back 0 27 0 622007-12-10 17:59:26 64.18.5.13 OutboundConnectionCommand SMTPSVC1 - MAIL FROM:sender@domain.com 0 4 0 622007-12-10 17:59:26 64.18.5.13 OutboundConnectionResponse SMTPSVC1 - - 250+Ok 0 6 0 1092007-12-10 17:59:26 64.18.5.13 OutboundConnectionCommand SMTPSVC1 - RCPT TO:recipient@anotherdomain.com 0 4 0 1092007-12-10 17:59:26 64.18.5.13 OutboundConnectionResponse SMTPSVC1 - - 250+Ok 0 6 0 5312007-12-10 17:59:26 64.18.5.13 OutboundConnectionCommand SMTPSVC1 - DATA - 0 4 0 5312007-12-10 17:59:26 64.18.5.13 OutboundConnectionResponse SMTPSVC1 - - 354+Feed+me 0 11 0 578 There is never a QUIT or OK after the 354 command. Any ideas of where to go with this? Like I said, it's affecting two of my clients at the same time, so I tend to think an AT&T problem, yet given the logs, it seems like it's not their problem. Thank you for any help.

Have you tried to manually send a test email using telnet to one of the failing addresses? Does this work? Do you have an IDS in place? Have you checked those logs if any? Have you spoken with an IT person from one of the companies in question? Have they checked their Spam filters?

I have not tried to manually send an email using telnet. Can you give me some quickie instruction? Not sure what an IDS is, so I doubt we have one! It's not a spam filter thing, because, like the logs show, the servers talk up until the request for message data, and then it stops. Not sure if it is a coincidence or if it's even feasible, but three of my clients are having the problem now, and all three are on AT&T here in San Diego. One of my clients cannot email to my own domain, amongst others! This is very frustrating, as I don't know whether it would be a waste of time calling AT&T and having to deal with their tier 1 support!

Lancorp... Have you had any luck resolving your issue...??? I am experiencing the same problem but with all outbound emails directedto bellsouth.net.... any help would be appreciated... Thanks..

Yes I did, but it had nothing to do with the Exchange server after all. Apparently, there was a network change with AT&T in California that week, that required a change in our Sonicwall firewalls MTU setting (believe it or not!). The default value of 1500 was causing the problem of emails not being delivered. This affected anyone who was on AT&T DSL. The new value of 1404, once changed in the Sonicwall, miraculously fixed the issue at four different location that were affected and having the same symptoms. Not sure if this would affect other appliances than Sonicwall. Never heard of such an odd thing, but I was tipped off by a colleague that suggested I try that, and it worked! Good Luck!

We had a similiar issue with Juniper Firewalls between sites on a Cisco configured VPN. The root cause of that was that Exchange traffic would get fragmented trying to send data, since Exchange likes to send large chunks at once. There was another setting as well but I forget it. What was interesting about that was that the Exchange server could receive e-mail all day long, but would not send, or at least would not send most of the time. They would just sit in the queue. When we switched the circuit back to a Cisco firewall, it would work like a champ.

As of yesterday, I am having the same issue too. I have a client that switched to AT&T DSL and now I have messages sitting in queue that are not going anywhere. So on my firewall, what exactly should be changed? I have a Netgear Prosafe firewall. It seems to be a good firewall with plenty of adjustability. Please help! This client is ready to kill me

Not sure if it works on a Netgear, but on the Sonicwall, I changed the MTU setting (on the WAN) from 1500 to 1404. So, the new setting is 1404. Look in your Netgear and see if the MTU is a settable parameter. Good luck!

Changed the MTU on the WAN side of the router to 1404. Still getting messages stuck in delay. Randomly. Maybe 2 out of 20. Got it figured out - sorta. Need help with this if anyone knows the answer - The problem is Outlook on the client machines keeps changing the default mailbox from the pop/smtp mailbox back to the Exchange mailbox and it's getting stuck in exchange. I want to keep the pop/smtp mailbox the default, but after a while - NOT every time you open and close Outlook. My partner thinks it's a Group Policy Object that changes it back. I looked all over and cant find it. Does anyone know how to change the default mailbox on an Outlook Client and keep it there? I can not delete the Exchange Mailbox because they are sharing calendars and contacts through it.

Are the target domain(s) the same everytime (at least predictable as to which domains aren't being delivered?) Also, have you enabled SMTP logging to see what is going on with the initial SMTP transaction?

The domains are different. I figured out the root of the problem. What's happening is at the clients desktops in Outlook the messages that are getting hung have this at the top of the message: This message will be sent via Microsoft Exchange Server. The messages that are getting out are getting out via their domain server. The domain server is at AT&T. This is a new account - they just switched on last monday from one communications to AT&T. So the problem is that the default email account is the Exchange Mailbox and not the pop/smtp account. I can set the POP/SMTP email account as the default, but sometime during the day it gets changed back. So how do I set the default pop/smtp account as the default and have it stay that way?

Yes Because Cisco is the Best HARDWARE in the world and all the rest is just trouble sometimes down the line.