How to run a mail sending service that will probably never send spam

June 9, 2018

I have written any number of times before that mail sending services could take steps that would make sure almost no spam would be sent through them, but they don't bother (eg on Amazon, on modern mailing list services in general and earlier). However, I have not written down my view of these steps, partly because I have considered them obvious in the community in general. For various reasons, I now feel like writing these steps down. So here is an incomplete list of obvious steps to take that would mostly gut sending spam through such a service.

In no particular order:

  • Charge people a decent amount of money for your service, possibly with a deposit up front. Don't have a free or a cheap tier, because it attracts the wrong sort of customer (Patrick McKenzie has written at length on how too-low or free pricing is a bad idea in SaaS in general).

  • Force people to put their address lists on your service, not just funnel their email through in bulk sending. Forced uploads allow you to scan the address list in advance to look for known warning signs, such as definitely nonexistent domains or known-bad addresses that never accept your email.

  • Require all email addresses submitted to you by a particular customer to be confirmed. The gold standard would be confirming separately for every alleged mailing list the customer sets up; the silver standard is confirming once when the customer first submits the address as part of any list and then assuming that the customer has the right to use that address in other lists. As part of requiring confirmation, provide an extra link that communicates to you 'I have never heard of these people and I do not know why they have my email address'. Even a moderate level of use of this link is a warning sign.

    It should go without saying that having more than a trace level of bounces or email rejections during confirmation should be a big warning sign.

    Probably the silver version is the most realistic, since these days customers may not have distinct 'mailing lists' as such, if they're using you to deliver event-based notifications to people's email and so on.

    (Even sending an initial notification email to people saying 'your address has been added to our system by <customer>' would be a step forward. These days a mail sending service could claim it was a GDPR requirement.)

  • Run all submitted mailing list messages through all of the available free open source anti-spam and anti-virus systems, and perhaps at least one of the commercial ones. If any of the systems flag the message, don't send the email and surface this in an alert both to the customer and to your abuse handling team.

    (It's not a service to the customer to let them send out email that you know will trip spam alerts for some recipients. Legitimate customers will likely thank you for such a pre-check service, and may even want a way to submit draft messages to it.)

  • Make it trivial for people to report unsolicited email and spam, and to 'unsubscribe'.
  • Pay attention to bounces, SMTP rejections in general, unsubscribes, and spam complaints. Mine them for addresses to add to your list of warning addresses. Rejections after SMTP DATA are probably an especially bad warning sign, because they suggest it was content filtering that caused the rejection.

    (As part of this, you should obviously recognize and parse the various SMTP 4xx and 5xx messages that major email providers use when they're dealing with questionable email messages. But this is so obvious that I suspect that any mail sending SaaS that wants to be successful is already doing it.)

I'm assuming as a baseline that you will do things like accept bounces and replies and properly implementing SMTP. These days you may want SPF, DKIM, or DMARC in order to pacify various large email providers who are getting increasingly insistent on it, but that's more in the realm of 'competently operating a commercial service'.

I'm pretty confident that any mail sending service that implemented all of these would send almost no spam, and I'm reasonably confident that it would still have a business. But of course it wouldn't have a business that's as big as you'd get by not bothering to do some of these things (especially confirming email addresses), and it would cost more to operate, and you wouldn't have as many customers because a certain number of the more shady people would stay away (as would all of the cheap people).


Comments on this page:

I wonder if you can charge a premium for “if you send your mail through us it won’t end up in spam filters”, perhaps specifically marketing that “we charge you extra for the operating cost of making sure that all our clients are legit, which your mail reaps the benefits of”. More to the point I wonder if such a premium could add up to (a sufficient fraction of) the low-margin business you lose. I suspect there is a significant cohort of smaller businesses (or perhaps more generally non-hypergrowth-oriented ones) that would gladly pay the extra for such a guarantee if it was available and affordable to them.

I suppose maybe the real problem is bootstrapping… even if the answer to whether the market exists is yes. As in, you’d have to build that reputation somehow before you could capitalise on it, and I don’t know how one would go about that without a really long and slow haul.

This really feels like something that should exist… I almost want to go and start it myself, before realistically realising I’m not the person to make it happen. (“This really should exist” is the impulse behind most of my projects… especially, unsurprisingly, the ones that never go anywhere.)

I believe that ConstantContact and the like already do deal in the business of "charging a premium for not being spammers."

They are in the business of sending bulk email, and they require you to vouch, when adding each email address to a list, that you either have implicit or explicit permission to send. I do not believe they actively confirm the email addresses upon entry, but they add all the courtesy "Unsubscribe" links and so forth. I would assume that they are proactive about stomping on spammers, because their entire business model is having clients that are able to send mass communications to legitimately harvested addresses. Being caught in only a few spamtraps would severely hamper their ability to sell a service.

They are a front-end service, and I do not know what ISP(s) they use on the back-end.

Our organization pays a couple hundred dollars a year for a minimum service level, which is mostly based on the rate of sending email messages during the billing cycle.

We also use Flocknote, which is a less fully-featured service that accomplishes about the same thing. Flocknote can send emails and/or SMS messages, and it makes real sure that the SMS numbers are confirmed in advance. Emails, it simply trusts us when we add them, although there may be some silent vetting by either service that we haven't run afoul of, yet.

I would suggest applying some restrictions on the SMTP envelope from to avoid issues with the client domain's SPF records.

I'd make sure that (text/)HTML messages also have a corresponding text/plain section. Try to make sure the sections are similar. (I've seen cases where the text/plain part was a completely different message.)

Try to get SWIP configured on the IP space.

Use VERP

Make sure the client understands the implications of DMARC and the necessary alignment on both the envelope from and the from header.

I'd require SPF, DKIM (sign it yourself even if the original sender doesn't sign it), and DMARC. I'd likely also add ARC.

Sign up for email feedback loops. Try to reach out to RBLs and establish communications with them. Demonstrate that you want to be proactive and be responsive to things.

Written on 09 June 2018.
« Networks form through usage and must be maintained through it
What ZFS messages about 'permanent errors in <0x95>:<0x0>' mean »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Jun 9 00:27:22 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.