It is becoming increasingly popular for agressive Realtime Blocking Lists (RBLs) to blacklist mail servers for sending out NDRs to bogus addresses (known as spam or UCE "backscatter"). Whether or not this is the "right thing to do" is another debate entirely with equally good points on both sides of the argument. I certainly agree that it is a huge problem if your email address happens to be the forged "from" address and it is also highly annoying to see your mail queue just packed full of undelivered NDRs to bogus addresses.
No matter how you feel, blacklisting this behavior is becoming more common and administrators are signing up to these more aggressive lists much more often in an effort to get their spam / UCE problem under some kind of control.
The problem for Exchange admins is that there seems to be a lot of misinformation on how to properly and safely configure Exchange to eliminate the backscatter problem. Most FAQs on the RBL sites point to a KB article at Microsoft's website which explains how to completely disable NDRs altogether (even for local users). This is bad because then your local users may never know when a lot of email is undeliverable because Exchange will no longer support this important feature.
The best solution I've found is to enable the "Filter recipients who are not in the Directory" option under "Recipient Filtering" under "Message Delivery Properties" in the Exchange Server's Global Settings. See image below...
This does have one glaring negative side effect. Before, a spammer could dump off a bunch of bad messages into your SMTP server and it would happily accept them, only later informing the person listed in "FROM" that the message was sent to a non-existent person. Now, the SMTP server will spit back 550 5.1.1 User unknown for every bad email address. The remote server is now responsible for delivering the NDR to the sender, which legitimate SMTP servers will happily do (a good thing). However, it is possible also that an email harvester can use this information to find real addresses on your system by performing a "directory lookup" attack. Whereas, when your server sent the NDR, the FROM address was likely forged, so the spammer never knew whether the address was real or not.
However, in practice, I believe this is a non-issue these days. Harvesters happily get email addresses a zillion other ways, I can't imagine doing a brute force attack on someone's SMTP server to find just a very few new addresses. There is too much work involved and too little reward for this effort. Quantity is the name of the game for spammers -- quality certainly is not.
However, there is a way to prevent (or at least, slow down) this risk: SMTP TarpitTime.
In Windows, there is a registry setting which will cause the SMTP server to insert a pause before sending an error back (5.x.x error) to the remote server during address verification. This is good in two ways!
1. Brute force directory harvesting is slowed down tremendously, to the point of being basically non-effective.
2. It's harder to DOS your email server by blasting emails to thousands of fake recipients, since your server pauses inbetween each bad address verification (the "RCPT TO" step).
Now, it's important to remember that if you are an ISP or some other organization that takes in a VERY large volume of email, you should test this setting carefully before deploying it to production, because you could, at worst, stall legitimate email delivery. However, if you set reasonable pauses using this setting (say, 3, 5, or 10 seconds or so), the likelihood is pretty small. Three seconds doesn't sound like much, but if you walk through every five-character combination with a 3 second pause inbetween each try, it would take approximately SIX YEARS to check every address using a brute-force method (excluding valid addresses where there is no pause). Who knows, by then maybe we'll have solved spam (yea, right).
Since filtering recipients not in the directory, my mail queue has gone from 100s of queued messages at any given time down to just 15-20 messages! Excellent performance improvement!
Here's the KB on how to set up the TarpitTime...
http://support.microsoft.com/kb/842851
I hope this helps some poor Exchange admins that were cursing Microsoft because they thought turning off NDRs altogether was the only way to prevent Exchange backscatter. It's not! :-)
Now, I wonder what new whiz-bang features there are in Exchange 2007 to help this problem... Hmm... Can't wait to play!