Hello, I am having a new problem with my exchange server (Exchange 2003 SP2). People are getting messages such as the one below, but not always, and they seem to be consistent with certain domains. From: postmaster@company.com <postmaster@company.com> To: First Last Sent: Sat Jun 26 00:43:22 2010 Subject: Delivery Status Notification (Delay) This is an automatically generated Delivery Status Notification. THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipients has been delayed. user@company.com Researching all the Delay Status notifcications here on Technet, I followed the DNS, SMTP and TELNET suggestions for troubleshooting. Using NSLookup I am able to see every and all problem Domain names and their Email DNS/MX records. Using Telnet to do a test, all of them result in this error: 554 mx.company.com Connection to host lost Doing this from any server in the domain results in the same problem. Doing the telnet from servers outside the domain environment yields normal results and tests. So the problem seems to be on my end. I am not that savvy with Exchange so any advanced troubleshooting would be welcomed! Thanks!

BTW we have rebooted the Exchange server only, and the problem persists still.

On Sat, 26 Jun 2010 16:20:13 +0000, venom66 wrote: > > >Hello, > >I am having a new problem with my exchange server (Exchange 2003 SP2). People are getting messages such as the one below, but not always, and they seem to be consistent with certain domains. > >From: postmaster@company.com <postmaster@company.com> To: First Last Sent: Sat Jun 26 00:43:22 2010 Subject: Delivery Status Notification (Delay) This is an automatically generated Delivery Status Notification. THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipients has been delayed. user@company.com > > > > > >Researching all the Delay Status notifcications here on Technet, I followed the DNS, SMTP and TELNET suggestions for troubleshooting. Using NSLookup I am able to see every and all problem Domain names and their Email DNS/MX records. > >Using Telnet to do a test, all of them result in this error: > >554 mx.company.com > >Connection to host lost > >Doing this from any server in the domain results in the same problem. Doing the telnet from servers outside the domain environment yields normal results and tests. > >So the problem seems to be on my end. I am not that savvy with Exchange so any advanced troubleshooting would be welcomed! Thanks! Looks like they don't want to talk to you. Unfortunately, the status code and explanatory text aren't specifica about the reason. It may be that your address (or network) is listed in sme DNSBL. Or it may be that you have no PTR record for your IP addresses. Or it may be that your IP addresses (or network, or domain) has a poor (or bad) reputation and is listed in one, or more, reputation servers. I don't see your IP address or domain name in the information you posted so all anyone can do is guess what the casue might be. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thank you for the reply and you hit on some very important issues. Let me provide some more detail but I think I have my answer based on your response. Using MXTOOLS and doing a diagnostic, all the SPF and PTR records are fine, no issues there. Using Spamhaus and CBL we are not on any Blacklists either. However, last week we had a virus that a user received via Outlook that spewed out spam galore and blacklisted us on Spamhaus, Spamcop, CBL and others. I was able to clear this up in under 6 hours and after 12 hours we were removed from all blacklists and remain clear to this day. By the end of last business week (roughly yesterday and 5 days after our virus/blacklist issue) we started receiving these delay notifications and they are isolated and consistent (3 domains that I am aware of). I am providing the info of the client if anyone can assist with troubleshooting further: mail.urbanco.com 70.36.198.18 *Also why is the Telnet failing from the above client to the designated email server that we get delays from? *Why is their a delay? If we are blacklisted by them, wouldn't we just get denied completely? Thanks again for your, and anyone's help!

On Sat, 26 Jun 2010 18:40:48 +0000, venom66 wrote: > > >Thank you for the reply and you hit on some very important issues. Let me provide some more detail but I think I have my answer based on your response. > >Using MXTOOLS and doing a diagnostic, all the SPF and PTR records are fine, no issues there. Using Spamhaus and CBL we are not on any Blacklists either. However, last week we had a virus that a user received via Outlook that spewed out spam galore and blacklisted us on Spamhaus, Spamcop, CBL and others. I was able to clear this up in under 6 hours and after 12 hours we were removed from all blacklists and remain clear to this day. > >By the end of last business week (roughly yesterday and 5 days after our virus/blacklist issue) we started receiving these delay notifications and they are isolated and consistent (3 domains that I am aware of). > > > > > >I am providing the info of the client if anyone can assist with troubleshooting further: > >mail.urbanco.com > >70.36.198.18 Your problem happend last Wednesday, right? http://www.trustedsource.org/query/70.36.198.18 Sites that use IronPort appliances might be your problem: http://www.senderbase.org/senderbase_queries/detailip?search_string=70.36.198.18 Reputation servers usually clear these transient problems pretty quickly (at least that was my experience with CyperTrust, SecureComputing, and McAfee), Cisco may be slower to adjust the reputation. The best way to approach this would be to contact one or more of the problem domains and find out what the problem is. I found that having a customer of the reputation service calling and asking for a reassessment of the IP address usually resulted in a quicker reaction from the reputation service provider. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, the problem occurred I believe last Monday night and we worked on it Tuesday in which the blacklists appeared, so early last week the problems began as you have noticed. So with these Reputation Services, that would cause a Delay in the email? That seems odd but I am very unfamiliar with Reputation Services though they are somewhat self explanatory. Would you say that I should wait for this to clear up or go forward with contacting the problematic domains come Monday and as you suggested hashing it out with them. If there are more than the 3 known domains, this could be very time consuming. Thanks again for answering so quickly, especially on a Saturday, which as we all know in I.T., means nothing.

On Sat, 26 Jun 2010 19:20:53 +0000, venom66 wrote: > > >Thanks Rich, the problem occurred I believe last Monday night and we worked on it Tuesday in which the blacklists appeared, so early last week the problems began as you have noticed. > >So with these Reputation Services, that would cause a Delay in the email? It's not the reputation servers that are responsible (or the DNSBLs), it's the way the e-mail systems that use them respond to senders that's a problem. Instead of responding with a 5xx status code (which is a permanent failure), they respond with a 4xx status code (a transient error), or simply drop the connection. So you server continues to retry the transmission until the time in the queue exceeds the expiry limit. >That seems odd but I am very unfamiliar with Reputation Services though they are somewhat self explanatory. They're only slightly different to a DNSBL. A DNSBL responsd to a query with an address, typically in the 127.0.0.0/24 range. The last octet is usually the "reason" why the IP address is in the DNSBL. A reputation server may respond with, say, 127.0.0.X, where "X" is a value from 0 to 100 that represents the spamminess of the IP address. They may also respond with 127.1.0."X" where "X" is a value in the range of 0 to 100 that represents the "goodness" of the IP address. The value "X" is added (or subtracted) from the spam "score" for a message. Since the reputation of an IP address is not an binary yes-or-no-block-it-or-not answer it's much better to use when determining if a message is spam or not. >Would you say that I should wait for this to clear up or go forward with contacting the problematic domains come Monday and as you suggested hashing it out with them. If there are more than the 3 known domains, this could be very time consuming. Since you don't know what the problem is, if I were you I'd pick the mose important domains and find out what they're doing. Chances are that fixing it for one will fix it for many (or maybe all). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks again Rich! I will see what I find next week and report back here as it may help someone in the future.

I looked at our Message Que's and noticed about 7 domains with emails that are in the Retry state. Will these ever resolve? Some are from 6/24/2010 and 3 of the domains I recognized as receiving "Delayed" email messages from so I suspect this is all related to the above issues.

On Sat, 26 Jun 2010 23:15:43 +0000, venom66 wrote: >I looked at our Message Que's and noticed about 7 domains with emails that are in the Retry state. Will these ever resolve? Resolve? They'll be returned as undeliverable when the delivery time is exceeded, if that's what you mean. >Some are from 6/24/2010 The default is to try to deliver the message for two days before they're returned as undeliverable. >and 3 of the domains I recognized as receiving "Delayed" email messages from so I suspect this is all related to the above issues. Could be. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP