[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1525
  • Last Modified:

Delivery Status Notification (Delay)

I have several employees that are getting undeliverable messages due to delays such as:

-----Original Message-----
From: Administrator
Sent: Tue 5/16/2006 5:19 AM
To: xxxxx xxxxx
Cc:
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.

       xxxxxxx@digitalcontainers.com

and the status is 4.4.7

When I look at the Queues under the Default SMTP Virtual Server in the Exchange System Manager I notice that almost all are set to Retry and only about 5 of 50 are in a ready connection state and the rest alternate between active and retry connection state.  This problem just started yesterday and nothing has changed on the Server.  

0
cvbgadmin
Asked:
cvbgadmin
  • 4
  • 4
  • 2
  • +1
1 Solution
 
amaheshwariCommented:
Hi,

Cause: The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This NDR may also indicate that a message header limit has been reached on a remote server or that some other protocol timeout occurred during communication with the remote server.

Check this:
http://support.microsoft.com/?kbid=284204
http://support.microsoft.com/?kbid=895857
0
 
cvbgadminAuthor Commented:
Any insight as to why almost all of my queues keep retrying?
0
 
SembeeCommented:
The delay message is close to useless. It just tells you that there is a delay without any reason for the delay.
You need to wait for the failure message to see what the NDR says.

Most common reasons for delay messages...

- the remote site is trying to use greylisting, but has bodged it.
- the remote site is trying to block your connection, but has bodged it.
- connection failure - that could also be a firewall causing a problem.
- DNS failure.

Any patterns to the messages sitting in the queues?
Do you use a smart host to send email, or try to send them directly?

Simon.
0
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

 
cvbgadminAuthor Commented:
I'm not really seeing any pattern, there's just about 75 or so that are in retry status and some have several msg's that are needing to go out.  Also, we are trying to send them directly.  We don't use any type of smart host.  I just thought it was weird that so many of these couldn't send at once.
0
 
SembeeCommented:
I would check your DNS configuration as the first step.

The DNS configuration is very simple.
All servers, including the Exchange servers should be pointing to domain controllers ONLY for DNS. No external DNS should be configured.
The domain controllers should be pointing to themselves.

The dns server applet on the domain controllers should be configured to use forwarders, which are your ISPs DNS servers.

If you are currently using that format, then check that the ISP hasn't changed their DNS servers. If they offer others, then try changing them.

You could also do an MX lookup test on the Exchange server to see if that throws up any errors.

Simon.
0
 
upul007Commented:
For an external dns report on your domain, use www.dnsreport.com and by the way, in the exchange queue, when you just click an email which states retry, is there a remark at the bottom of the queue window. Also check if you relay through www.dnsstuff.com.
0
 
cvbgadminAuthor Commented:
I finally got a failed message but still no real help.  It just specifies # 4.4.7 which I already know that the reason is due to a delay.  I just don't know why or how to fix the problem.  I did go to dnsreport.com and it showed our ISP as our parent DNS.  Here is a link of the results I received: http://www.dnsreport.com/tools/dnsreport.ch?domain=cvbg.tv  I'm not quite sure if some of the fialures have anything to do with our delay.  I also know that we are currently listed on sorbs, and our ISP is in the works of getting us delisted as it is an IP address range of theirs that we happen to fall into.  Although I think that if it were due to the sorbs listing then we would just be getting the rejections from the recipients server which we have gotten a few of and not just all getting delayed.  If anyone has any further insight as to how this can get fixed I would appreciate it.
0
 
cvbgadminAuthor Commented:
Oh, and the MX record is correct.
0
 
SembeeCommented:
If the problem was your blacklist error, then the message should bounce back immediately, not give a delay message.
Your reverse DNS doesn't match what the server is announcing itself as, and the server is announcing as something else other than what is in the DNS records. Again if that was causing a problem I would expect an immediately rejection - not a delay then timeout.

Timeouts are almost always down to connectivity or DNS. Everything else should result in immediate failure.

Simon.
0
 
upul007Commented:
Hi Simon,

If the server is set to drop a connection should a name match an email address, wont this happen?

Upul
0
 
SembeeCommented:
If the server has been set correctly to drop the connection, it should be seen as permanent failure and the message is NDR. My home Exchange server is on a residential internet connection and as such I see plenty of NDR messages when the message is blocked. I always get the NDR back immediately. I hardly ever have messages hang around in the queue, unless I have made a typo.

If something is interfering with the SMTP traffic, so that Exchange doesn't see the failure message, then that can cause messages to hang in the queues. It may not be the sending side that has the problem with SMTP interference. It could be the recipient. Firewalls are a classic cause.

The point is - messages in the queues means that the message hasn't been delivered - for some reason. If the message delivery had failed, then the message would not be in the queue.

Simon.
0

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

  • 4
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now