Since outbound spam was poisoning our reputation, we decided that there were two angles we had to approach:
- Disable customers from using our outbound service when we detected they were spamming.
- Neutralize the effects of their spam so that other customers were not affected.
These really are the key issues. If you want to reclaim your sender reputation, you have to address both of them. Even though both problems are related, we decided to tackle (2) first. How do we mitigate the effects of outbound spam and isolate that small trickle from the larger outbound traffic of legitimate mail?
This option is the simplest option. The flow is as follows:
- Scan all outbound mail
- If (mail == spam), drop the message (ie, don’t deliver it)
This is a suggestion that many people suggest. It’s also completely unrealistic and doesn’t work in the real world.
To begin with, it assumes that a content filter is completely effective at avoiding false positives. This is not the case, false positives occur all the time. They are most likely to occur for large mailing campaigns. Some customers have SPF records misconfigured, which can also contribute to FPs. Sometimes people put spammy content into a message, like a short message with repetitive content that mimics spam. The point is that legitimate messages get flagged all the time. Blocking these messages would cause serious problems. While people do want their outbound spam blocked, they want their legitimate mail delivered even more.
Worse still, silently blocking the message would generate many support calls. With inbound mail, if a message is blocked it either goes to the spam quarantine or it is rejected in SMTP. In either case, both the sender or receiver get notification that message was not delivered. In the case of a silent drop, a sender can transmit a message, have it vanish into thin air and there is no notification at all. There is no way to troubleshoot a problem without having to call up support and having them search through logs. Even then, reconstructing the problem is difficult because the original message is gone. Without the original message, spam analysts who are responsible for maintaining the content filters cannot diagnose which spam rules are causing the issue.
Blocking spam messages outright doesn’t work; it isn’t pragmatic in real life. A more elegant solution needs to be found.
Option 2 – Treat outbound mail the same as inbound mail
Another option for outbound mail filtering is to treat outbound mail the same as inbound mail. If a message is scanned and detected as spam, send it to the user’s spam quarantine. Except, rather than quarantining based on the recipient, we must quarantine based on the sender.
Spam notifications are the same. We send notices to users about what spam they have in their spam quarantine; it’s a list of messages with the subject line, sender and date sent. They would then receive a similar notification for spam filtered in their outbound quarantine.
The advantages of this approach are that it reuses a lot of the existing infrastructure. Spam is spam no matter where it comes from so simply store and filter it the same way we do for inbound mail. It doesn’t require fundamental changes to the way we think about spam.
However, the drawbacks of this approach are substantial. First of all, there is the time delay. We send spam quarantine notifications by default every three days, but a user can elect to receive them every day. Still, a day’s wait is completely unacceptable. If you send a message and have to wait 24 hours to determine that your message was flagged as spam and not delivered, I would think you’d be infuriated (I know I would be).
Another drawback is in the case of messages with spoofed senders. Whose quarantine do you send it to? To a user that does not exist?
This also requires changes to our spam quarantine – we have to store mail based on the sender instead of recipient, and divide the quarantine into inbound and outbound. For customers who don’t have quarantine logins, they will have to talk to an admin to get their message released. That would be an awful headache and would generate a ton of support calls.
This option doesn’t work.
 A false positive is also abbreviated FP.