Handling the problem of inbound bulk mail

Over the years, our spam filtering has gotten to be pretty good.  We don’t see a lot of complaints about spam other than the odd escalation (why didn’t your filters stop this “obvious, blatant” spam from coming to my inbox?).

However, that doesn’t mean that everything is fine.  There is still one class of mail that people complain about more than anything else – bulk mail.  Bulk mail is marketing mail and it’s easy to spot: it contains a requirement for an action by the user such as an invitation to a conference or seminar, an advertisement for a product, an opportunity to connect with other like-minded individuals, and so forth.  Frequently, the people who submit these messages call them spam because they didn’t sign up for them. 

But if you open up and look at the newsletter, they fall into the gray area.  If we were to block them at a global level, they would generate lots of false positive complaints. However, they do contain unsubscribes and are compliant with the CAN SPAM (barely).  They are clearly not building their lists in a legitimate manner (such as harvesting them at an industry conference by snatching business cards out of bowls for a free doodad).  Our spam filters say that these mails are non-spam 97.5% of the time but people still complain about them.  It’s hard to say whether or not these mailers honor unsubscribe requests; given that they built their mailing lists in an illegitimate manner, whose to say that they would depopulate their lists in a legitimate way?

This is a dilemma for us – if we block them outright, people will submit them as false positives because our spam rules are implemented globally.  If we don’t block, people will complain and submit them as spam.  In fact, these types of bulk messages are the number one spam complaint that we get today.  So what to do?  The answer that we came up with is to do a personalized antispam experience.

Since we are an in-the-cloud antispam experience, we don’t have control over the user’s inbox.  There is no switch to accept or reject bulk mail because the mail passes through us and then downstream to the end user.  They cannot navigate to a UI like Gmail or Hotmail to turn on or off the reception of bulk mail.  Instead, what we do is stamp inbound bulk mail with a header.  If mail comes from a known bulk mailer, we stamp the x-header and then the user can create a rule in their mail client to move it to the Junk Mail folder (they could also create a Bulk Mail folder and move it there if they so desire).

And that’s what we did.  We now maintain a list of bulk mailers that we identify by going through our abuse inbox (or responding to manual escalations).  If the spam complaint is actually bulk mail and not spam, then we add it to the bulk mailing list.  We also published documentation on how to create a rule in Outlook to move it to your Junk Mail folder for an individual user, and how to create an Exchange Transport rule to do the same thing for an entire organization (if you want to read up on it, see Bulk Mail Filtering in FOPE).  There are other mail clients than this, but we only documented Microsoft software.  Other admins are smart enough to figure out how to do it on other platforms.

This creates a customized experience for end users.  If you want to receive bulk mail, don’t do anything.  If you don’t want to receive these types of messages, follow the instructions above.  If you don’t want to receive any bulk mail except for a few, then block bulk mail but set up a safe sender for the ones you want to receive mail from (or create an exception in the Outlook rule).  This is mentioned in the link above.

When we first looked into the feature, I was concerned about two things:

1. Would people adopt it?
2. Is setting up Exchange Transport rules or Outlook rules too clunky of a user experience?

I ended up coming up with some preliminary design to integrate with our Admin Center (accessed via the web) where the admin of an organization could navigate and opt users into or out of the bulk mail filtering feature.  We also thought about integrating with Outlook and Exchange so we could sync it automatically (it would be a new feature in a future version of Outlook and Exchange).  We ended up cutting this part and just doing the basics for the first release because we wanted to get it out quickly.

However, since it has been released, I have not received any complaints that the UI (creating rules) is too difficult to use.  Instead, the only things I have heard are the following two “complaints”:

1. How do I add mail from so-and-so to the bulk mailers list?
2. How do I get myself off the bulk mailers list?

The answer to the first question is simple.  When customers submit to our abuse inbox, or manually create support tickets complaining about spam that is really bulk mail, we go through those and add them to our bulk list.  It’s part of the standard process.

The second question is something that I hadn’t considered ahead of time.  If people are complaining about someone’s mail and we take a look and see (i.e., manually inspect) that it is bulk, we add it to the list.  To avoid getting onto the list, a mailer should use good sending practices. 

The following is my own, personal rule-of-thumb.  The best way to do this is to get onto ReturnPath’s Sender Certified List.  I scrub the IPs I add to the list once in a while and if they are on ReturnPath, then obviously they have worked with them to do the things that legitimate bulk senders do – send mail to double-opted-in receivers, have valid unsubscribes, etc.  This bulk mailers is a gray mailers list.  ReturnPath is a legit senders list so it’s kind of like outsourcing it.

This isn’t official.  But I do it because I don’t want to add people to the bulk mailers list that needn’t be on there but I am also not going to waste my time doing manual verification of everything.  Hotmail uses ReturnPath (differently than I described above) and if you want to deliver to Hotmail, get on ReturnPath’s list.  If you don’t want to be labeled a bulk mailer by us, then get on ReturnPath’s list, too.

That’s our bulk mailing feature in a nutshell.  From start to finish it took about two months to code, test, and release and we shall see how it is received by the outside world.