SPAM - Finding the culprit who sold your e-mail address

One of the (very many) things that annoys me in the IT world is spam. Even more annoying is working out which of the multitude of Web forms I've filled in has then either had its mailing list stolen or sold.

Most of the time I don't bother - I add my Gmail account as the e-mail address to the forms. However there are those Web forms that don't accept hosted e-mail accounts and want you to use your corporate or personal e-mail address.

If you can easily add e-mail aliases to your corporate or personal e-mail address then you might be interested in the following technique.

I run my own mail server, so I've recently taken the step of adding a suffix of ".spamtrack.source.<website>" to my business e-mail address to create a new alias, where <website> is the site that wants my business e-mail address.

So if my e-mail address is me@example.com, then my new alias for a Microsoft Web form becomes me.spamtrack.source.microsoft@example.com.

It's a bit longwinded and fancy looking - I wanted something that looked like an automated system handles it. It also means I can add that later if I bother scripting something to take care of it and auto-mail abuse@ to tell them that my e-mail address has either been stolen or sold. I could possibly even extend it to be something like me.spamtrack.source.microsoft-dont-sell-my-email-you-sods@example.com.

So now I'm able to see who's selling my e-mail address or who has had their mailing lists stolen. And if the spam levels climb up, then I can simply kill the alias.

Stopping Sophos PureMessage 3.0 from Generating an NDR Storm

I upgraded to the latest version of Sophos PureMessage (v2.6.1 upgrade to v3.0) on an SBS 2003 server.

The upgrade went smoothly as per usual. Hats off to Sophos for providing good quality products and excellent documentation.

This version now includes AD integration and allows for recipient validation. I enabled this, as well as verifying the upgraded settings. I kept an eye on progress for about 90 minutes as I was performing other administrative tasks.

When I came back to it the next morning, the server was being sluggish. Investigation showed that the were several thousand NDRs queued up, and further investigation revealed that the Exchange journal mailbox was bouncing Read Receipts with a Permission Denied error back to PureMessage. Unfortunately, the Read Receipts had no From header, so PureMessage was generating an NDR and trying to send it to an address of '<', which is a completely invalid address. This was then escalating an alert message to the Alert address, which had filled up the resulting mailbox. The mail bounce that was occuring was also generating an unscannable error due to too many nested attachments, which also queued up an alert message.

The remedial action was to remove the administrator alert address. This stopped the queuing. I then turned off administrator alerts for the On Unscannable action for the Exchange Store scanning and the Transport scanning. This helped stopped further NDR flooding.

The final action I performed that finally killed the NDR storm was to fire up the Exchange System Manager, go into the SmallBusiness SMTP Connector properties, go into Content Restrictions and turn off System Messages.

I also opened up the Delivery Restrictions placed on the mailbox that I'm using for Exchange Journalling until I can verify what the appropriate restrictions should be on the mailbox such that it works with PureMessage 3.0, seeing as the previous settings worked fine with PureMessage 2.6.1 (which was only accept messages from the Exchange Journalling mailbox).