Handling the problem of outbound bulk mail

  • Article

When it comes to email, I am our customers’ best friend.  I really am.  I’m the good guy that is always defending the user experience.  But even I have my breaking point.

Over the years, we have put in a ton of outbound spam mitigations from delivering the spam out a different pool (and monitoring it and cutting it off when the rates get too high) to monitoring feedback loops to doing traffic analysis.  However, for years I have resisted putting in throttles based purely on volume.  The reason is that some of our customers use our service to send large volumes of outbound mail, including marketing mail.

I always wanted our email service to be as transparent as possible.  So long as a sender doesn’t send out spam, they can send large volumes of mail.  I even wrote two documents on how to be a responsible sender:

My whole rationale was that the people who are responsible for getting us onto 3rd party blocklists are people who are either intentionally spamming, or are spammers sending from compromised accounts, or are spammers sending from compromised machines.  People who send out newsletters may be sending out large bursts of mail but if the content is not spam, then they are not the issue.  Their content is legitimate.  From my perspective, so long as you send out legitimate content then there was nothing to worry about.  Spam gets us listed on blocklists, not legitimate content.

Thus, I resisted putting any sort of volume limits for regular customers who are not high risk (high risk being someone who has a history of spamming).  If you’re a good sender, then it is likely you will continue to be one.  So why restrict your behavior?  We want to target the spammers, not the people who are sending good mail.

Unfortunately, I have changed my views.

This doesn’t work anymore for two reasons:

  1. We started deep digging into why we were listed on a particular blocklist so often.  As it turned out, some of our customers were sending mail to large mailing lists, but some of the email addresses on these mailing lists were spam traps.  The story has more complexity to it (the mailers were not as negligent as you might think) but the reality was clear – legitimate mailers with legitimate content were getting us onto 3rd party blocklists.

  2. It is too difficult to programmatically tell the difference between a zero-day spam attack and a large mail campaign.  Suppose we see a large spike in mail from a particular client and all of it is marked as non-spam.  What type of mail is it?

    If it is a legitimate mailer, they could be sending out a large mail campaign to their subscriber base.  They only send mail at irregular intervals and the spam filter is calling them non-spam.  Fair enough.  But if it is a spammer, it is a zero-day spam attack and the filter’s definitions have not updated in time.  A compromised account only sends mail at irregular intervals.  From an automated perspective, a zero-day compromise looks like a legitimate bulk mailer.  Remember that we have to automate our monitoring because we don’t have enough people to babysit this stuff.

The two realities above forced me to re-evaluate my stance.  I want to allow customers to send legitimate mail through our service – as much as they want – but I can’t.  The problem of abuse has ruined it for everybody.  Not only that, but we just released a feature to handle inbound bulk mail.

The solution that I am pushing (not yet formalized but the language is coming) is to take a definitive stance our service is not intended to be a bulk mailing service.  There are other companies that are set up to do that sort of thing (ExactTarget, ConstantContact, MailChimp), but we are not one of them.  They do bulk mail services of one-to-many.  Our service is business or personal communication, one-to-one or one-to-a-few.  Occasionally people have cause to send large blasts of mail (such as a professor communicating to his student base) but those are one-offs.  We aren’t set up to handle bulk mailing and monitoring the abuse that goes on there.

In other words, if you want to do bulk mailing, you can use us for inbound mail but you need to find someone else for outbound.

It’s not the most elegant solution, and in the future we may start supporting it (Office 365 customers might have a need to do this).  This would require a re-architecture of our network in order to segregate bulk traffic from normal traffic.  The fact is that if we want to keep the reputation intact of our regular outbound delivery pools of IPs, we need to ensure that good mail goes through there; bulk mail introduces too many variables to mix in with regular email traffic.

This “solution” is anti-climactic.  I tried for years to keep it from occurring, but the fact is if we want to control outbound spam and keep off of blocklists, this requires certain trade offs.  This trade off is one that we are going to have to make.