In my previous post, I mused about what it takes to do outbound spam filtering. If customers use us for outbound mail and start relaying spam, it damages our reputation and credibility. Ergo, we need to come up with a solution wherein we don’t deliver spam. But the problems are not trivial:
- How do we actually filter outbound mail? Do we assume it works the same as inbound? For example, suppose one part of our filters tends to be overly aggressive. Should we leave it as the same behaviour as inbound filtering? Skip that filter? Raise the threshold at which point we make a decision that a message is spam?
- Suppose that we decide that the filter should be different for outbound as for inbound. This means we have to maintain two different roles for mail filter deployment. This means we have to engage Network Operations who run our deployment and tell them to pay special attention to outbound filters. Do we want to go through all that trouble? Is there a better technical solution?
- What should we do with mail we identify as spam? Quarantine it? Bounce it? Drop it? All three have implications that need to be dealt with.
- How do we notify the user that we are identifying their mail as spam? By email? How many times per day? As soon as we identify it, should we notify the user? Or, should we wait a period of time?
- Are there exceptions to spam filtering? Should certain senders (like a Legal team discussing a spam website for which we have a delete-all-spam-if-URL-is-mentioned rule) always be allowed to send? In other words, is there an outbound Safe Senders?
These are the major issues surrounding policy. We’re still in the beginning stages of how we want to treat outbound spam – we can either implement policies that behave upon individual spam messages and senders, or we can implement policies that affect the domain and sending IP as a whole.