SMTP Queue's filling up

We are running exchange 2000. Our SMTP queues are filling up with what looks like spam. We are set up not to relay and from what we've read we are not forwarding these emails but exchange is trying to send out NDR's for these emails but the addresses are probably fake so they sit in our queue for 3 days till they are deleted. The problem is we have 10's of thousands of emails in our queue taking up space. My question is how can we prevent these emails from getting to our queue. Is there some setting in Exchange or do we have to use a 3rd party spam program. Any help would be appreciated.
Thank You
Tyler TechAsked:
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.

Everytime people ask this, I tell them it's a dictionary harvest attack and other people come on and yell about the sky falling and say your system has been compromised.

Just to satisfy those who are sure to come, please go to this link and check your relay:

Now, on to your problem.  You can identify the sender of these messages using your logs and keep them from connecting, if they don't change their IP, and they will.  Probably not a great solution.

Exchange happens to be a really bad Internet email gateway.  Deploying sendmail or something made for email routing might be a better idea.  You could even put IIS SMTP out there to help deal with the problem.

One strategy you could use is to limit the number of recipients.  This limit will make it harder to launch these attacks as a new SMTP session will have to be recreated once the recipient limit is reached.  

My best suggestion is to deploy a proper MTA between Exchange and the Internet.

We have solved this problem by putting an SMTP Filter in front of the server (Filter listens on port 25 and forwards the mails to an internal port, so exchange will not longer listen on port 25). This filter is able to detect spam relay and rejects the mails without sending any NDR. This protects the server against some usual tricks used by spamers. One of these products is ie. McAfee SMTP Virus Scan or the newer McAfee Spam Filter. But there may be a lot of other tools doing the same.  
Here are another couple of things to check:-

1)  The local Guest account may be enabled - allowing any credentials to successfully authenticate (therefore allowing them to relay)


2)  A compromized local account on the box (in some cases a domain account, but this machine was a member of the domain).

Check the local accounts on the box - reset passwords and ensure guest is disabled. If the machine is in a domain - check the guest account and all other accounts for suspicious activity.

Generally, I've been able to pin the issue down to a previous infection by Code Red (the IIS worm) - one of it payloads (in some versions) is enabling the guest account..

Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

I have the very same problem here.

OneHump: Do you recommend a way to deploy a proper MTA? What do you think of third party products like GI MailEssentials?

Bembi: I don't see how your solution is preventing NDR's. Isn't the filter forwarding every email to your Exchange server?

mehranalmasi: The sense of a filter is to filter, means, only mails, which are passing the filter a delivered, others are rejected and you can disable sending NDRs for rejected mails. The filter accepts mail relay, destroys the mail and nobody gets any NDR.
i'd like to have something clarified please. and maybe i am just misunderstanding the context filter is being used in here, but:

..."and you can disable sending NDRs for rejected mails",

by that do you mean only the NDRs that are generated due to filter restrictions can be turned off?  all other NDRs such as exceeding set message size limit , or mail to a non existent mailbox would still be generated? or did you mean just turning off all NDRs in general?

if one can turn off NDRs just from filter rejected mails i'd certainly like to know how.

Thanks in advance!
No, off course, turning off sending NDRs for filtered mails will only affect excactly these mails. All other NDRs will of couse reach their recipients.

How to do it:
In Exchange, have a look at "Global settings" - Message Transfer - Properties - Filter. There you have a senders filter and can disable sending NDRs for filtered mails.
The filter options are a little bit enhanced in EXCH 2003.
Within ISA Server, you have an additional SMTP Filter.
Other filters with options do disable NDRs for filtered mails are GFI Mail Security or McAfee SMTP WebShield
we do have 2003, and i tried to follow your instructions but being that it is somewhat different i cannot find that specific area. could you give instructions on how to turn off NDRs for filter rejected messages in 2003 please?

Thanks in advance!
- Exchange Management Console
- Global Settings
- Message Transfer (second line) - right click - properties
You find three filters there
1. sender filter
2. connection filter (for blacklists)
3. recipient filter

for the sender filter, you can either select "reject connection" or "accept message, but do not inform sender" at the bottom of the dialog.

(Note: the descriptions are translated as my system is german, may be they are a little bit different).
ok we checked "drop connection if address matches filter". the other options is actually grayed out so we're not able to check it.

 so this should stop NDRs being sent for messages that are getting rejected due to filter restrictions then?

btw the only thing that's translated differently is "message transfer" is called "message delivery".

thanks for the instructions!
The option is grayed out, because you have selected "drop connection". Disable it and you can select the other option.

This setting affects NDRs, produced by the sender filter, if it affects the other two filters, I'm not sure, but I think it is easy to check out by using a web mailer. But it will definitely not affect NDRs, which are produced by other restrictions or errors
sorry to be such a pest.

but while looking around in that area i also came across another setting i am interested in. under the "recipient filtering" tab is a check mark labled "filter receipients who are not in the directory".

does this mean someone trying to send a message to an account that is no longer in the AD it would not even receive the message let alone create an NDR? we have quite a few accounts that get deleted due to the employee leaving. but they got on some message list and now we continue to get NDRs. i was hoping marking that check mark should stop the message from making it to the server let alone an NDR being created? if that is not the case here, IS there a setting elsewhere in 2003 that would stop NDRs from being generated for old accounts that are no longer valid or even accounts that never existed?
Not sure if you can block these NDRs, my 2003 Server is a backend server, therefore hadn't checked out yet. But mark this option and send a mail from a web mailer like GMX to your server addressing one of your old accounts, there you can see if you get an NDR.
This option results in a 5xx error code being returned to the calling MTA - NDR'ing the message there (as opposed to the Exchange Server acceptiong the message - and then NDR'ing when it fails to locate the mailbox to deliver to).

I don't like this option - as it allowes spammers to 'harvest' your domain for email addresses..

Better to use the Recipient Filters for departed email addresses - and configure that to not send an NDR.. I also ann the SMTP alias to an internal mail enabled public folder - just so that if anybody tries to add the alias back they get the error 'EMail Address already exists'..
>Better to use the Recipient Filters for departed email addresses - and configure that to not send an NDR

If it was there in 2000, I think they've killed it in Exchange 2003.  You can't tell it to not send NDRs only if a certain filter is activated.  I really want to ONLY send an NDR only if the sender is authenticated.

I can disable NDRs entirely under Global Settings > Message Formats, even on a per domain basis (the default domain is *).

I'm thinking to create two Internet Message Format rules: and *.  Our Domain would be configured to NOT generate NDRs.  So, the millions of incoming spam attempts to old accounts would not generate them.  Then, * would be configured to allow NDRs.

Would * override, or vice versa?  If it worked as expected, there would still be the problem that if an internal, authenticated user mis-addressed a message to another internal user, they'd never get an NDR.  This shouldn't be an issue because they're all using Outlook and utilize the GAL and Check Names feature so it's checked before it even leaves.  

So, this should work.  To summarize:  NDRs would be enabled on the * domain, but not on  Outlook client would ensure recipient validity prior to sending for internal messages.  NDRs would only be sent if the message is addressed to someone on an external domain, and the only people allowed to email that is... authenticatd users!

An added bonus of this is, if you suddenly do see a bunch of NDRs, you know that a client or username has been compromised.

I just tried this - and it seems to work!  My server quit generating 5 NDRs per minute from the moment I enabled this.  One curious thing though - attempts to send from an authenticated Outlook user to still results in an NDR!  I think this is because these local messages are routed differently because it's all internal, and those Internet Message Format rules never kick in.  I can't be sure though.


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
Just a follow up on my accepted answer.

I later didn't think this was working after I tried it.  Message Tracking would show that the Postmaster is still sending hundreds of NDRs per hour.

However, on closer inspection, if you look at the Message History (by clicking the tracking log entry) you'll notice that the NDR messages go only two steps in - as far as SMTP:  Message submitted to categorizer - and they die there.

Somewhere else probably has a log indicating that they were dropped and why (due to the rule in place) but I'm not sure where that is.

RJLSB - could you please elaborate for everyone exactly what you did, and how it worked out?
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

From novice to tech pro — start learning today.