How to reclaim your sender reputation, part 4 – More options

Option 3 - Keep track of the mail disposition and cut off the entire organization

This was one of the original ideas proposed to solving the outbound spam problem.  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 generally 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.

The advantage of this approach is that it treats the organization holistically. Furthermore, if nobody can deliver mail it will get results quickly.  It also leverages a lot of our existing infrastructure. 

The disadvantage is that it loses individual granularity.  It is also 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. The false positive issue is made much worse in that all legit mail either gets through or gets bounced.

On to the next option.

Option 4 – Route outbound spam differently than good outbound mail

The option that we finally ended up deciding on is routing outbound mail differently.[1] For years, we have had a dedicated pool of IPs that send out bounce notifications, referred to as our NDR[2] pool. Customers who bounce messages back through us have this mail go through the NDR pool. Thus, the mail going through this pool is of a lower quality. Bounce messages can also be backscatter and so sometimes this pool can send outscatter.

All outbound spam messages are routed through this pool. Thus, the problem of outbound spam through our good IP pool is solved. Good outbound mail is always delivered out through us, and spam goes through the lower quality pool of IPs. Customers can check to see if the mail was delivered or rejected because we keep logs on whether or not mail was 250’ed (accepted), 450’ed (temporarily rejected) or 550’ed (permanently rejected). Thus, the good pool is kept clean while the grey/black pool is doing what it is supposed to do – sending mail through it that is of lower quality. When one customer starts spamming, their spam is isolated from the rest of the good mail.

Another advantage to this approach is one of false positive mitigation. Some mail will go through this pool because content filters can make mistakes; sometimes legitimate mail is marked as spam. However, this mail is not being blocked by us. We are still delivering it. Furthermore, administrators have the option of bcc’ing outbound spam from their organization to a postmaster alias. If these are legitimate false positives they can forward them to our spam team for filter correction.

Not only this, but other spam filters can start to use this in their reputation scoring.  If they can figure out that we send our mail through two different pools of IPs, then that assists others in their own mail filtering.

The one drawback to this method is that it is dependent on the content filters. If a new spam campaign begins that the content filters cannot detect, then until the filters are updated the spam will go through the outbound pool.

Figure 7 - FOSE outbound spam routing

Routing outbound spam such that it doesn’t affect other customers is half the story. We have now saved our support team from a flood of angry calls. The other half of the story is what to do once we detect that a customer is spamming, and how quickly can we get them to stop.[3]

[1] We ended up discussing several other options which I have cut from this discussion for the sake of brevity.

[2] An NDR is a Non-Delivery Receipt. Another term for it is a Delivery Status Notification, or DSN.

[3] It is also good Internet etiquette to not send any outbound spam at all. We wish to have a reputation as an organization that does not send out spam, not merely one that routes it through a different pool and doesn’t care how clean it is.