There’s a great deal of discussion surrounding policy and outbound spam. What do we do with messages marked as spam and how do we treat the organization as whole?
Option 1 – Keep track of the mail disposition and cut off the entire organization
This was my original idea (or rather, it’s the one I originally wrote up in my spec after talking to a few people). The idea is to filter the mail and write the disposition (spam vs non-spam) to an IP stats log for outbound mail but not take any action on the mail regardless of whether or not it is spam so long as the IP is clean. Before relaying the message, the outbound mailer looks up a flag in a database to see if the IP is clean, but if it’s not it bounces the message.
Another watcher agent then continuously inspects the IP stats log for each customer outbound IP that is relaying through us. If the amount of mail marked as spam exceeds some threshold, cut off that IP’s outbound mail by flagging the IP as dirty.
Certain enhancements could be made to this. The spam detection algorithm can keep track of an IP’s history and cut them off earlier if they are a frequent offender. In addition, mails marked as spam could be bcc’ed to an administrator somewhere so they have evidence of why we cut them off. We could also add some mechanisms wherein the first offence cuts off an IP for six hours or so and then releases them automatically.
Advantages – treats the organization holistically, will definitely get results quickly if nobody can send mail out. Leverages a lot of our existing infrastructure. The false positive issue is either greatly reduced or made much worse in that all legit mail either gets through or gets bounced.
Disadvantages – loses individual granularity. Also seems a bit heavy-handed to cut off an organization if only one or two systems in their network is infected. If no one is around in the middle of the night to do something about this, users in remote locations could be out of luck.