Trouble shooting delayed mail

[mikesid]

For the past week I have had a few people complain of delayed mail. Some by a few hours and a couple by a few days. I do not see where the exchange server would hold messages. But is there a way for me to check this out? We do have a firewall and a Mcafee web shield and perhaps one of the two is holding the message or something. I was checking to see if there are any logs or anything i could check or enable. Since it doesnt happen on a regular basis the logs would have to be on for a while since it only started happening last week. And i am not sure when it will do it again.

 

[wallst32]

Look in ESM, mail server, protocols, SMTP. The queues will show you what domains have been recenlty contacted for outgoing SMTP. A blue icon indicates some type of problem, so you can right click and select properties to show status (usually it's going to be remote rejecting connection, or remote could not be contacted). This only helps with recent messages.

If you need to go back in time, you probably should turn on Message Tracking and keep the logs for a week to 4 weeks. It won't help you with the past messages if it wasn't turned on, but will for future troubleshooting. Right click on your server from ESM, Properties, and enable message tracking.

BTW, is this Mike Sid formerly of Context I?

 

[mikesid]

thank you for the info. I do have message tracking enabled. This is my fault since I forgot to mention, but this is for incoming mail. Outgoing mail seems to be fine. However incoming mail for the past week has been sporadic. Some messages bounce back to our clients saying that the user has exceded thier mailbox quota (currently we do not have any file size limitations for incoming or data storage for emails). Some clients do not even get a bounce back message and assume we got the message when we did not and call us up and ask why we have not responded to thier email. and some are delayed. I am not sure if thier is a way to view incoming mail to check if we have recived email from a certain domain or email address. I do not see where exchnage would be holding the message and I am thinking maybe our we shield, firewall or ISP is to blame. But without logs I am not sure where to begin.

Nope, sorry. I have never heard of Context I. My last name is sidnam (unusual last name). Do you know if the person to whom you are refering has the last name sidnam or something else? There aren't many sidnams that i know of.

 

[Modeverything]

Hi mikesid,

We had this problem happening in our organization with email being delayed when being delivered.

Whenever the exchange server receives new mail for a user's mailbox, it sends out a UDP packet to the user's machine with a New Mail Notification. Unfortunately, this packet can be sent on any port range from 1024 to 65535, making it impossible to just allow access to the necessary port; you have to just open up a huge range of UDP.

It turns out that our client firewalls were blocking UDP ports from the server so our clients would not receive their new mail until they initiated contact with the exchange server, such as a manual send and receive or to send mail or something.

Try opening up UDP port range 1024-65535 on your client firewalls to see if this solves your problem.


Hope this helps

 

[mikesid]

I guess it is happening to me to because I came here to see if anyone left a reply and I saw yours but i got no email notification (unless tek-tips email is down).

My only issue with opening those ports is that i would be opening it up to the world correct? Also our email server is behind our firewall and so are we so shouldnt it be opened already? The email server should be able to send any port number to the ports on our client computers. Or is it an issue with the firewall not releasing the mail to the email server.

BTW, what type of firewall do you have? We are using a watchguard firewall. I think its a firebox x. thanx again for your help.

 

[Modeverything]

I'm not suggesting that you open up these ports to the internet. I assume that you have some type of hardware firewall between your inside network and the internet. If your email server and your client machines are both behind the same firewall, then you will not need to open any additional ports on your perimeter. I'm only suggesting that you open up the UDP ports on your client machines; that will allow UDP traffic that is inside your network already ranging from ports 1024-65535 to get to your client machines. You will still be protected from the internet from your perimeter.

I'm suggesting that you may be blocking the UDP notification from your email server to your clients; then you would only have to open up any UDP ports that are on that path, which is likely to just be your client firewall.

What you are probably experiencing is this, someone sends email to a user on your server. The server places the email in the user's mailbox. The server then sends out a notification to the client machine on UDP port 1024-65535 to inform them that they have new mail. The firewall on your client machine blocks the packet and doesn't get the notification of new mail, so no mail is received by the client at that time. The next time the client initiates converstation with the email server, it receives its new mail. The issue is most client side firewalls act as a diode, meaning anything can go out, but nothing comes in. So outside traffic coming in is blocked by default, unless the communication is iniated by the client machine first.

We are currently using the ZoneLabs Integrity firewall, which we are very unhappy with. It has lots of problems with it, although I'm not the administrator for it. We are looking to rollout Cisco's CSA agent soon to take care of our client firewall needs.