What Mailchimp Considers an Email Address

Sun 23 July 2017

Recently I've been working with Mailchimp's API. The task was simple: to write a script to keep in sync an internal user list with a Mailchimp mailing list - simple stuff. I set about writing the thing and, bar for the fairly regular API timeouts (don't batch >500), all was good.

And then I ran the thing.

After a couple of hundred users the script encountered an error - apparently one of the email addresses was invalid. At first I thought this was an issue in the unofficial and excellent python-mailchimp3, so I created an issue. Then, while working on a PR to close the issue, I discovered this gem in the Mailchimp documentation:

Although MailChimp can process UTF-8 characters in most parts of our application, we cannot process UTF-8 characters in your subscribers' email address prefixes


UTF-8 email addresses became standard in 2012, Gmail added support for this in 2014, as did postfix. Microsoft dragged their feet for a few years and added support to Outlook 2016.

I totally get that a change from ASCII to UTF-8 is non-trivial when you're dealing with millions of email addresses; so it's understandable that some businesses still don't support this. But Mailchimp? Aren't they meant to be at the forefront of email marketing? How can you run mail campaigns without access to these users? Ridiculous.


Update 26/7/17: change email -> email address as it's correct (thanks HN!).


Sun 01 January 2017



  • Read at least one (non-technical) book
  • Reduce late-night screen usage -> sleep better
  • Walk more


  • Brexit stalls
  • Trump fails to ruin the planet
  • EmDrive tested & proven to work
  • Brighton & Newcaslte promoted to premier league
  • F1 gets more exciting

Agentless Everywhere

Sat 13 August 2016

In a world where everything must be distributed across multiple servers, datacenters and continents the task of managing & monitoring server state has become significantly more complex.

Hundreds of solutions have spawned in recent years - and in general these tools can be split into two groups: those with, and those without, agents on the target servers. I'm writing this post to argue in favour of the agentless tools.


One shouldn't need to install (sometimes closed source!) software on a server to have it managed or monitored. Agents take up precious CPU, memory and disk space which should be reserved for the actual thing the server is meant to be doing. Then there's updates - does it make sense to have to update every server to fix a bug in the agent? With an agentless tool you'd just update a client or have the service provider handle it for you.

Take Sensu for example, it weighs in at ~30MB of package data (via apt) including a full Ruby interpreter. And then there's the check files - every time these change they need to be synced to all the servers that use them. The problem really begins to manifest at scale, where deploying such changes takes a non-trivial amount of time.

Another good example of "agent bloat" is Chef (which also bundles it's own Ruby interpreter) - the base ubuntu Docker image weighs in at a cool 126MB - not too shabby. Want to install stuff on it with Chef solo? You might try the linuxkonsult/chef-solo image - it's 671MB. That's a whopping 545MB of pointless bloat!

Read more →