Monthly archives: April 2007

Timothy

Eliminating Exchange 2003 Spam / UCE Backscatter WITHOUT Disabling NDRs

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

Screenshot of Message Delivery Properties in Exchange 2003

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!

Timothy

RD Tabs 1.1.4 is now available

More info in the forums... http://forums.avianwaves.com/Default.aspx?g=posts&t=20
Timothy

RD Tabs 1.1.3 released! Big bug fixes!

RD Tabs 1.1.3 is now out.  Lots of bug fixes.  Check out the forum post here...

http://forums.avianwaves.com/Default.aspx?g=posts&m=38

Blog

Search Posts

Recent Comments

  1. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Brian: Thank you so much Edward! :-)

  2. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Tom: Thank you Edward! After beating my head against a wall for days, tried your suggestion out and lo and...

  3. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Mike: DPM 2016 setup will fail if you have SQL Server Management Studio (SSMS) V17.x installed. Re-Install...

  4. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Rob: Edward, thanks man! you were a lifesaver. My scenario was Win Server 2016 from scratch, SQL 2016 (N...

  5. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Edward: It also crashes with the 4387 error if you have the SQL Management Studio 17 tools installed. Installing...

  6. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Ram: Hi - I followed richsmif instruction and was able to successfully install DPM 2016 on SQL 2016. Completed...

  7. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Neighborgeek: Thanks for the post, this is exactly the issue I am running into. I'm disappointed to see that you didn...

  8. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    richsmif: I have DPM 16 working with SQL 16. Install SQL 16 first, don't touch, install DPM 16 , upgrade to ...

  9. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    ptbNPA: That should have been *ID 810*, not 820

  10. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    ptbNPA: For anyone else coming across this in the future and have an ID 820 error: For some strange reason...

Archive

Tag Cloud