2 issues, Outbound mail not leaving domain, SonicWall Firewall constantly dropping UDP packets

We are running an environment with Microsoft Exchange 2003.  We can send mail to each other, but mail sent outbound of the office is being rejected. Here is the error message generated by Exchange:

The message cannot be delivered due to a configuration error on the server. Please contact your Administrator.
  <mail.xxxxxx.org #5.3.0 smtp;553 5.3.0 <jason@xxxxxx.org>... Access Denied_due to spamming>

For a week or so, the problem was alleviated by by power-cycling the SonicWall TZ-170 Appliance that we use as our Firewall.  Our Public IP Address that is provided by AT&T starts at the SonicWall and specific ports are forwarded to our internal server. (standard practice I imagine).  The problem has returned, but now, I cannot allievate the problem by power-cycling the equipment anymore.

Here is what I've tested:
- I've called AT&T to make sure that they aren't blocking our email due to spamming.  The technician on the other end verified that there wasn't an issue with our ISP.
- I plugged my laptop in directly to the T-1 gateway and configured my outgoing mail server settings to match what the ISP required to send out mail and EVERYTHING went out no problem.
- I powercycled both the servers and the sonicwall appliance.  For a week or so, that resolved the problem.

Other information:
I've reviewed the firewall logs and it also looks like some bastards in India are trying to port-scan their way into our network.  I'm not sure if the Sonicwall is being overwhelmed with this information and is freezing up... I would gather it isn't freezing the Sonicwall, otherwise why could we still connect with the VPN clients to the device and send/recieve internet traffic through the device.  Here is a clip from the SonicWall Log:

11/12/2008 16:33:54.096 UDP packet dropped, 52685, WAN, 53, WAN    
11/12/2008 16:32:16.320 UDP packet dropped, 38814, WAN, 53, WAN    
11/12/2008 16:31:05.544 UDP packet dropped, 51565, WAN, 53, WAN
11/12/2008 16:27:28.752 UDP packet dropped, 38814, WAN, 53, WAN    
11/12/2008 16:25:54.064 UDP packet dropped, 38811, WAN, 53, WAN    
11/12/2008 16:23:58.224 UDP packet dropped, 49107, WAN, 53, WAN  

Any and all help in resolving this would be appreciated.  I'm a basic administrator for Exchange, Definately not an expert.

Who is Participating?
J_bodenheimerConnect With a Mentor Author Commented:
This issue turned out to be the outbound relay with Sbcglobal.net.  They were rejecting our outbound mail due to a mail spam relay.  We changed it so the outbound mail was leaving our exchange server directly, bypassing the relay.  We did several other things to protect our server from attacks, but this was the solution.
Could be one of two things. First check your routes using the winroute tool to make sure that the routes are correctly replicated between servers and routing groups.

If that all looks good try this.

Exchange Server 2003 has a feature that permits Exchange 2003 to operate without the Message Transfer Agent (MTA). If a message was sent incorrectly by using the MTA route, this delivery status notification is returned to the sender.

Although Exchange 2003 can operate without the MTA, Microsoft does not recommend or support this configuration.

To turn on this feature and to prevent the messages from queuing to the MTA, follow these steps:
1.      Disable the MTA service.
2.      Set the DWORD value to 0 in the following registry subkeys for every information store database and public folder store:
HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway In Threads

HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway Out Threads
When you do this, you are making store resources that are associated with MTA delivery available.
3.      Restart the information store.

The port scans have nothing to do with it.  They happen 24/7/365.  Perhaps you just never read your logs until now.  Port 53 is for DNS, so those particular entries are probably looking for susceptible DNS servers to poison.  If the traffic is dropped, should be a non-issue.  You can't stop them, only drop them.

Have you looked through the SonicWall configuration (or talked to the firewall admin) to see what restrictions are put up?

Any information specific to the SMTP traffic in your SonicWall logs?
Are you allowed to send outbound port 25 traffic on your internet connection?
Is your IP address/block is listed with any of the RBLs?

Here's your IP on Projet Honeypot:  http://www.projecthoneypot.org/ip_207.105.8.2

On a cursory check, I don't see that IP listed anywhere else.

I would suspect you've got an issue between your outbound relay (Exchange) and the SonicWall configuration.
"...due to a configuration error on the server."

Is your WAN (public IP) listed under a block assigned for dynamic addresses?  Spam filters will reject the message based upon that alone, before you get past HELO.
Or, your server is sending out a different name that rDNS.  Anti-spam rules on the receiving relay may be rejecting that as well.

See here:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.