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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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:
J_bodenheimerAuthor 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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Software Firewalls

From novice to tech pro — start learning today.