• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 634
  • Last Modified:

Mail delay notifications and exchange queueing

Currently there are 10 mail queues in exchange.  Over the last week we've noticed 15-20 delayed messages per day or from the server notifying us of delayed emails being sent, or not sent.  Some eventually send, other do not send at all.  We're unable to see a pattern; the delayed messages can happen on a newly created email, they can also happen in the middle of a correspondence after several mail exchanges have taken place.  What causes this, and how do we fix this so it will not continue?

The problem appears to be very similar to this MS article and weve applied the fix yet were still experiencing the mail delay issues.

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.exchange.admin&mid=df7bcd16-0306-4787-a358-3888c4e1198f
0
breynolds01
Asked:
breynolds01
  • 7
  • 6
1 Solution
 
SembeeCommented:
There is a greylisting bug in Exchange 2003, however it does not show in the way that you have identified. When messages are caught in the greylisting but they do not appear in the queues.
Furthermore greylisting can be ruled out if the correspondence has been regular as any decent greylisting application should white list addresses that internal users have sent messages to.

The first question has to be whether you are sending email directly or via the ISPs (or other) smart host/smtp server.
The next question should be whether there is any pattern in the domains being sent to.
The third key question is what else is on the machine? This can be an indication of third party interference, AV, Antispam, firewall etc.

What you are seeing, while not normal is not unusual and in many cases it is down to a factor that is out of your control. If you were using a smart host to send email and the problem was with the recipient then the messages would queue on the smart host instead of your server.

Simon.
0
 
breynolds01Author Commented:
We are sending the messages directly from our exchange server.   There are ten domains listed currently, and several of the domains have multiple emails queued.  One domain in particular has 11 messages queued.  Currently SMSME, Ninja Mail Security, Symantec Backup Exec 11d, Symantec AV, and Timberline are installed on the server.  Symantec AV is configured with the default exceptions recommened by Symantec.
0
 
SembeeCommented:
Well my standard practise when a Symantec product is involved is to blame that. Their AV and antispam products cause more problems than any other I know. There is only one remedy which is to remove them. Disabling them is not enough to confirm that they are not the source of the problem.

If you click on one of the queues, what reason does it give for the connection issue?

Do some nslookup and telnet tests to confirm the DNS is correct and you can connect. My guide on that is here: http://www.amset.info/exchange/smtp-diag-outbound.asp

Simon.
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
breynolds01Author Commented:
I did everything on your walk through and also ran a report on DNSSTUFF.COM, only one red mark and that's under test NS FAILED Open DNS Server which by the IP lists our ISP's DNS server.  Here's the error message:

ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are:

Server 206.124.64.1 reports that it will do recursive lookups. [test] Server 206.46.254.13 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.

Here's a quick list of some of the stuck queues:

adarchitects.com  -  No additional information available.
barnescps.com  -  The semaphore timeout period has expired.
cochraninc.com  -  The connection was dropped by the remote host.
detemple.com  -  The connection was dropped by the remote host.
harrisworksystem.com  -  The semaphore timeout period has expired.
0
 
SembeeCommented:
Two of the domains, the ones with the semaphore errors, don't appear to exist, so could be a typo by the users.

The DNS errors you have flagged will not be the cause of the error message.

On the dnsreport were there any errors in the mail server section?

Simon.
0
 
breynolds01Author Commented:
In the mail section there are two warning messages:

1:  WARN Mail server host name in greeting WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.

mail.domain.com claims to be host domain.com [but that host is at 64.33.22.X (may be cached), not 70.96.182.X]. <br />

2: WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).  

0
 
breynolds01Author Commented:
Update:  Just checked the mail queue's and all the messages queued from the 26th to yesterday are gone.   The queue's have cleared up.  The only thing I changed yesterday was the ondeman scanning of the local AV client on the server.  I read in one of the documents from an above posting that could cause issues.  Any way to tell if the issue has been resolved or do I need to wait until users come back on Monday and start using the systems again?
0
 
SembeeCommented:
The mail host warning that you have flagged above should really be fixed.
That is a simple fix.
ESM, Servers, <your server>, Protocols, SMTP. Right click on the Default SMTP VS and choose Properties. Click on Delivery and then Advanced. In the FQDN change the box from domain.com to mail.domain.com. Don't bother with check dns. Apply/OK out.

Otherwise you will have to wait.

Simon.
0
 
breynolds01Author Commented:
Could this be the issue for the delayed messages?  I've since made the change.  Thank you for your help!
0
 
breynolds01Author Commented:
Update: I had to change the mail.domain.com back to domain.com as all mail stopped routing into the server.  I did a test from an outside account and sent an email to user@domain.com and the email failed:

The original message was received at Sun, 30 Sep 2007 21:45:30 -0700
 ----- The following addresses had permanent fatal errors -----
 ----- Transcript of session follows -----
.. while issuing MX query to 127.0.0.1
554 Domain not found

Once I changed back to domain.com the emails started routing again.
0
 
SembeeCommented:
The change I have outlined should have had nothing to do with the routing of email, unless you have something else on your network that uses the name and it is getting confused.

Simon.
0
 
breynolds01Author Commented:
This is a SBS2003 which everything is wizard driven.  When I change the domain.com to mail.domain.com this also changes the setting in Exchange you recommended changing.  This change using the CEICW changes the email server to then address all users email from user@domain.com to user@mail.domain.com
0
 
SembeeCommented:
I know this is SBS. I didn't say to change it in the wizard. You can make the change manually in the location I specified, you just need to remember to change it back after running the wizard again. You don't have any choice, you have to make the change. It is just unfortunate that Microsoft set it to just domain.com by default meaning a manual change is required.

That still wouldn't account for the error that you have received above, unless you have something else on the SBS Server. The presence of 127.0.0.1 which is localhost in the error is a concern. Do you have something that is scanning SMTP traffic perhaps?

Simon.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now