Update (3/16/16): Mandrill is now an add-on for paid monthly MailChimp accounts, and is no longer available as a standalone service. Existing Mandrill users have until April 27, 2016 to merge their Mandrill account with a MailChimp account. See this article for additional details, including pricing information and instructions for merging your accounts.
Update (3/4/16): SparkPost has offered to take on any departing Mandrill users and to honor Mandrill’s pricing for those users.
Update (2/25/16): We’ve published an FAQ article in Mandrill’s Knowledge Base that provides more information about the transition. We’ll continue updating that article as new questions arise.
Today, we’re emailing our customers to announce some significant changes to Mandrill.
Going forward, all Mandrill users will be required to have a paid monthly MailChimp account and verify ownership of all sending domains. Here’s the timeline: Starting 3/16, all new Mandrill users will create accounts through MailChimp, and current Mandrill users can merge their existing Mandrill account with a monthly MailChimp account. Current users will have until 4/27 to merge their accounts.
Why we’re making this change
The MailChimp team built Mandrill in 2012 as a transactional email tool. It was a startup within MailChimp that functioned as a completely separate product. Mandrill is now becoming an optional add-on to paid MailChimp accounts. This is a strategic change we’re making to close the gap between the two products. MailChimp is designed for marketing, and Mandrill is designed for transactional messages. Each is powerful on its own, and offering Mandrill as an add-on makes MailChimp even more powerful for our small business and e-commerce customers. Our CEO and cofounder Ben Chestnut wrote more about the changes on the MailChimp blog.
We're pushing a change today, August 4, 2015 at 12:00pm UTC (see this in your time zone), that makes domain verification mandatory when you add a new sending domain and set up SPF and DKIM. This change won't be applied retroactively, so if you added a domain to your Mandrill account before today and set up SPF and DKIM, we'll still sign your mail as usual. However, we still urge you to verify any sending domains for your account.
Earlier today, we notified some of our customers of a security vulnerability we discovered in Mandrill’s infrastructure. At this time, we’re confident that no customer data was compromised as a result of the vulnerability, but we feel it’s our responsibility to let our customers know exactly what happened and what we’re doing about it.
Since this issue only applies to Mandrill accounts that were used between February 6 and March 10, we emailed everyone who may have been affected. If you didn’t get an email from us today, that means you weren’t affected. For other Mandrill users and affected users who choose to notify their own customers about the vulnerability, this post explains what happened.
Update December 17, 2014, 4:55pm EST: As with most changes in Mandrill, we rolled this one out using a progressive migration from our smallest region to our largest region while monitoring server loads, error rates, and user feedback through support channels. While our initial estimation that a fraction of users would be impacted was correct, the severity of that impact in some cases was more greater than anticipated.
The initial changes we made included updates to both our root certificate and intermediate certificate chain, so that everything used SHA-2. This resulted in errors, particularly for users in shared hosting environments where SHA-2 is supported, but the root cert bundles couldn't be updated in a timely fashion. We've partially rolled back this change to a configuration with a SHA-1 root, and SHA-2 intermediate certificates, which should address the majority of issues users were reporting. We'll continue to monitor the status of this, and provide further updates if necessary.
Next Wednesday, December 17, 2014, we’re making some updates to Mandrill’s SSL certificates to ensure they’re no longer using SHA-1 hashing algorithms for signing. The change is anticipated to impact a very small number of users — those using an older server, and more specifically, an older SSL client library.
Yesterday, Google released information about POODLE, a serious vulnerability in SSL version 3.0. This vulnerability can't be used to gain unauthorized access to the Mandrill infrastructure, but in theory a malicious network operator could use it to eavesdrop on encrypted communications. We're updating Mandrill's infrastructure to protect against this vulnerability by completely disabling support for the SSLv3 protocol.
2014 brought the announcement of several high-profile vulnerabilities in specific widely-used encryption libraries. But POODLE is different—it's a flaw in the protocol itself. SSLv3 was released in 1996, and should be considered obsolete and unsafe. TLSv1, the successor to SSLv3, was released in 1999—15 years ago. Newer versions of TLS are preferable, but TLSv1 provides an acceptable, safe baseline.
Unfortunately, disabling SSLv3 may cause compatibility problems for a very small amount of traffic on the Internet—well under 1%. We don't take this lightly: breaking compatibility is always a serious concern. In this case though, leaving SSLv3 enabled would risk exposing our users to eavesdropping by malicious actors, and we're simply unwilling to take that risk.
As of Wednesday, October 15 at 20:00 UTC, SSLv3 was disabled for all API and SMTP traffic received by Mandrill. SSLv3 for webhooks was disabled on Thursday, October 16 at 17:00 UTC. We're evaluating the impact of disabling SSLv3 for all outbound mail that uses opportunistic encryption, and will post an update once that is complete.
Email is serious business. We take pride in being the fastest-growing email as a service platform, but we put just as much work into security as we put into the features and performance that drive that growth.
Between the ongoing revelations about widespread communications surveillance, and recent high-profile security issues such as the Heartbleed OpenSSL vulnerability, we're happy to announce a handful of significant new security features at Mandrill. We'll also talk a bit about the security-centric philosophy that has guided product development at Mandrill for the past two and a half years.
We recently enabled opportunistic TLS for all mail sent via Mandrill. This means that we'll attempt to use an encrypted connection for every message that we send. Internet surveillance typically involves widespread collection of data as it is being transmitted, which is ineffective if encrypted connections are used. Unfortunately, while support for TLS is growing, it isn't everywhere yet. Some recipient servers don't support TLS at all, and others are misconfigured—in these cases, we'll fall back gracefully to an unencrypted connection.
Google's Email encryption transparency report is one method of verifying TLS support for the mail we send.
Two years ago Mandrill began as a skunkworks project at The Rocket Science Group. Chad wrote about the risky decision to build a separate team and a new product. Sensible people would just tack on some new APIs or bolt some seemingly-new features on to an existing product instead of conceiving a new team or platform. Sensible people would set small, attainable goals instead of ones that start with being the best and most widely-used Email As a Service product. Fortunately, we’re not sensible people.
Two years in
In just two years, Mandrill grew from a skunkworks project to a product that outperforms similar services and beats the competition in a feature by feature comparison. Today marks a milestone in Mandrill’s growth as we sign up our 250,000th active user, making Mandrill the largest EAAS platform by a fairly wide margin. Mandrill’s active user count isn’t just ahead of our competitors; our user growth rate consistently outpaces competitors, pushing Mandrill further ahead of the pack. According to data from Datanyze, Mandrill is the fastest growing EAAS platform since February 2013.
Not bad for two years.
You might think most of those 250,000 users come from MailChimp's 6 million users. We thought the same thing! When Mandrill started, we expected a lot of crossover. Turns out the audiences are completely different, and we had to re-think our entire approach. Mandrill’s a team that likes challenges though: this one just meant Mandrill had to earn these users on our own.
Ultimately, our users are this milestone, and we're grateful for each of you who have joined us, whether you joined when Mandrill was in beta, signed up today, or somewhere in between. If you used Mandrill in the last two years, thank you. If you gave us a high five, reported a bug, offered your feedback, or shared your business or idea with us to figure out how Mandrill could fit in to your vision, thank you. Thank you for letting us earn you as a user. We know that’s just the first step, and we’ll also need to continue to earn your support and trust.
While this growth is exciting, we’re far from claiming success. We know there are more features, more improvements that we can build to improve our service offerings. We accomplished a whole lot in two years, but we’re buckling down (and hiring) so we’re ready for what the next two years mean for Mandrill and our customers.
On Monday, the OpenSSL project released an update to address a serious security vulnerability nicknamed "Heartbleed". This vulnerability impacts the encryption used for internet communications and could allow access to decrypted HTTPS traffic. Like many service providers, once Mandrill became aware of Heartbleed, we moved to address, and evaluate the impact of, this vulnerability. We know that our users share our concern for security and privacy, so we want you to be aware of the specifics of Heartbleed vulnerability as it relates to Mandrill.
First and foremost, we have no evidence that the Heartbleed vulnerability was used to obtain any Mandrill data or to access Mandrill services.
Mandrill's relay and application servers were using affected versions of OpenSSL. Patches have been applied to all impacted servers, a process which was completed and confirmed by 14:00 UTC on April 8th. Although Mandrill utilizes Amazon EC2, we don't use the disk images provided by Amazon that were found to be affected. Nevertheless as a precaution, we've replaced our private key and SSL certificate since it's plausible that Mandrill's certificates could have been exposed.
What you should do
While there's no indication that Mandrill user data has been impacted, we strongly recommend that users update their Mandrill account passwords. Since API Keys are used for accessing your account via the API and SMTP, we also recommend deactivating old keys and replacing them with new keys.
Many of our users have sites or applications hosted which store their Mandrill credentials or other sensitive data. So, we also recommend auditing all services you may use to determine if they are also vulnerable, taking steps to repair any vulnerable services, and replacing SSL certificates once the vulnerability has been removed.
The Mandrill team has spent the last several months adding a bunch of great features each week, like resending messages, subaccounts and demographics. We've also added some pretty innovative features that you don't normally find for transactional emails, like the rules engine, split testing and our executable API docs. With each release we've worked hard to make sure the interface for using them is well designed and easy to use, whether you're accessing them through the Mandrill web application or the Mandrill API.
However, one problem we've encountered with the speed we've been releasing is that some features have been available through the Mandrill UI a week or two before they're accessible through the API (and sometimes vice versa). While we have some big, new features in the works, we also want to kill that time gap when they're ready. In order to do that, we're going to slow down for a couple of months and work on a making Mandrill's foundation even better for future innovation.
UPDATE: As of 2015-07-15, Mandrill's pricing has changed. See our pricing page for current details.
Yesterday we changed Mandrill's pricing model. It's pretty significant and we think you'll be happy to see simplified and more cost-effective pricing for all senders. No more monthly plans. No more figuring out whether you want to keep a monthly plan even if you're sending less mail. Just consistent rock-solid features for all users, predictable pricing, and volume discounts built in (still no negotiation needed).
...And lower pricing for everyone.
But how much lower? Let's look at a few of examples of monthly sending:
Old Price: $ 9.95
New Price: $ 2.60
Old Price: $ 23.45
New Price: $ 8.60
Old Price: $ 171.45
New Price: $ 47.60
Old Price: $ 526.95
New Price: $ 197.60
Old Price: $ 1,745.95
New Price: $ 1,048.80
Today we're excited to announce that we've partnered with our friends over at Codecademy to help new and seasoned developers learn to use the Mandrill API.
Mandrill generally operates on a continuous deployment model, meaning that as new features and bug fixes are complete (and tested by man and machine) we can deploy them to you. We deploy in small batches, continually monitoring changes and production load. Being able to quickly add features requested by users and fix bugs as we find them, instead of on a set development schedule, means that Mandrill can quickly adapt to be better and faster at sending your email. Lots of users have been excited for expanded attachment support, so we rolled out changes yesterday to include support for inline images and more attachment types.
A few months ago, we had a customer come in complaining of slow sending speeds. Even the simplest of emails was taking 2 or 3 seconds to deliver. That may not seem like a lot, but if you're sending thousands of messages on a single thread, it can quickly add up to hours. Our servers routinely spent about 50 milliseconds processing their mail, so that was eliminated as a possibility. The customer's servers were in France and had a 250 millisecond ping time to our servers in Texas. That's pretty far, but still far short of 3 seconds.
The problem: SMTP is chatty
The key to this little puzzle is that the customer was using SMTP to send their mail. That's not too surprising; about 60% of the email that goes through Mandrill is sent using SMTP. The problem is that SMTP is designed as what we nerdy types like to call a chatty protocol. To send a single email using SMTP, you have to send multiple separate commands to the SMTP server and wait for a response on each one. The farther you are from the SMTP server, the longer you have to wait for each response. Here's a basic breakdown of a simple SMTP conversation (see wikipedia or the SMTP RFC for more detail):
Last week, we conducted some planned maintenance to move some data around and generally make things faster and more reliable for our users. While we were at it, we also rolled out a small update for templates, added some API calls related to Mandrill's inbound email processing, and added API logging for messages transmitted via SMTP.
I just passed Ben (MailChimp's CEO) on the stairs. All I heard was him chanting "blog post, blog post, blog post."
"When are you going to update the Mandrill blog?" "What are you guys working on?" "Is Mandrill dead?"
No, Mandrill isn't dead - it's very much alive. But, see, that last blog post that Chad made? It's sort of a hard act to follow. We've been busy adding new features and beefing up functionality but few of these features seemed to warrant a full blog post. Plus, the Mandrill blog is sort of a nerd's blog, which means code and the command line and...well, more on that later. Time to rip off the band-aid. Here's a little bit of what we've been up to:
About a year ago, we launched STS - a transactional email service built on top of Amazon SES. In that time, we've seen the integration grow to a moderate success, now sending on average over 100,000 messages every day. While we're happy with the cool things people have built on top of our integration, we've received a ton of requests from customers for features that we felt we really couldn't accomplish on top of a limited platform like Amazon's. We've also spent years building a world-class platform for email delivery and analytics, so the devs were constantly saying "why don't we use this platform to build an email service that's MailChimp through-and-through?" That thought turned into a prototype labs project called Mandrill which we are excited to announce has graduated to public beta.
At its core, Mandrill is similar in functionality to our STS integration, but using the same optimized delivery engine that MailChimp uses for the delivery of our bulk newsletters - slightly modified for one-to-one email. You still need to be a programmy nerd to use it, so if you're not comfortable with code and APIs, you'll need to find someone who is before you get started using Mandrill.