Some while ago, as a sample for a book, I provided a part-built application that shows how XML and XSL can be used to display information. The source data is an XML document containing a listing of the set of interface members for ASP 3.0, and the application also accepts user feedback - and sends out confirmation email messages when users submit their feedback.
Unfortunately, I left my own email address in the code after testing. You can probably guess the result - I regularly get email messages from people who are testing and playing with the sample to see what it does and how it works. Now, I know that it's useful to get feedback on who is using your applications, how often they run it, and when. But I'd suggest that this is somewhat less than useful when the "From" address in the email is a fictitious one such as "firstname.lastname@example.org", as is the case with this particular sample.
OK, so it wasn't so bad getting the occasional message, and in fact quite heart-warming to see that my sample code is finding some use out there. I set up a rule in Outlook to delete the messages anyway, so there's no real problem. Or at least, that was the case until just after Christmas when I powered up and logged in to see how much email had accumulated over the holiday period, and discovered 88,000 or so of these "feedback" messages in my Inbox. All identical, and all received in batches of a couple of thousand or so within a few seconds of each other.
Had I upset somebody out there, and was under attacked? As it turned out, the most likely explanation is that someone had installed the sample and then proceeded to run some stress tests on it, without changing the email address. The problem I now faced, however, was what to do about the email. I don't know if you've ever tried to work with that many email messages in your Inbox, but my poor old Exchange Server (it runs on a fairly low-spec machine) struggled to cope. Pressing Ctrl-A to select all the messages and then Shift-Delete to delete them just locked up the client. The rules to delete the messages wouldn't run, and nothing else seemed to work. Simply scrolling to the end of the list locked Exchange client up for 10 minutes at a time.
In the end, I had to manually delete blocks of 50 or so messages at a time, which took an age. Thankfully, once the remaining number got to less than 64,000 the rules I hade set up in Exchange took over and - after about an hour - had deleted the rest. It seems like the Exchange rules (and the iHateSpam junk mail control utility I also use) can't cope with more than 64,000 messages at a time.
Having removed the messages, the prime need now was to stop it happening again. After some investigation, it looked like the best plan was to set up SMTP Filtering to block the incoming messages before they reach Exchange. It's quite easy to do, as long as you are aware of the two separate steps that are required, and it seems to work fine. The first step is to set up the filter details. In the Exchange Server Administration tool, open the Global Settings entry, right-click Message Delivery, and select Properties:
In the Filtering tab of the Properties dialog, you can add, edit and remove individual filter entries. Click Add and type in the filter you want to apply. You can use the asterisk as a wildcard, so that *@domain.com will filter all email that has a "From" address of anyone at domain.com. Alternatively, you can specify all subdomains, specific subdomains, or single email addresses, for example *@subdomain.domain.com to filter just email coming from this subdomain, or email@example.com to filter on a specific email address.
The checkboxes below the list of filters allow you to archive the filtered messages for examination later if required (I know what they are, so I don't bother with this), filter out messages with no sender (useful anyway, whether you use specific filters or not), and decide whether to send a Non-Delivery Report (NDR) to the originator when messages are filtered. I chose not to for a few reasons. The most obvious is that it saves on bandwidth, and here in England the wet string we use as a network is expensive so I can't afford to buy much of it. The other point is that, if I am attacked, I don't want the attacker to know that I'm filtering the messages. This would probably just prompt them to use a different "From" address. Finally (in my particular case), the sender probably won't receive the NDR, because the original message generated by the ASP code has a fictitious "From" address anyway.
Having set up the filter(s) you need, the second step is to activate filtering for the SMTP Service. It isn't activated by default, so your filters will not work until you perform this next step. Open the Servers section and expand the list for your server name (the name of our server is not visible here). Expand the Protocols and SMTP entries, then right-click on Default SMTP Virtual Server and select Properties:
Click the Advanced button in the Properties dialog to open the dialog shown on the left in the next screenshot, and make sure that the correct IP address (for the SMTP Service you want to apply filtering to) is selected. Click the Edit button to open the Identification dialog, and set the Apply Filter checkbox. As the caption suggests, this applies and activates filtering for the SMTP Server that uses the specified IP address:
That's it. Oh, and by the way, if you have installed the Wrox ASP Roadmap sample application on your machine, can you please check that you've changed the "To" email address? Thanks.