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.

Read More

Every once in a while we get an application that wants to do a deep integration with MailChimp. They’ve read our guides and decided that deliverability is way more than what they’ve signed up for. They just want to use MailChimp to send email on behalf of their users. Their needs are simple – just give MailChimp a list of email addresses, give it some content to send, and track stats – that must be what MailChimp’s built for, right?

Well, no. See, MailChimp is, first and foremost, an application for our users and not an API for developers. You can’t just take an application, sprinkle a little MailChimp on top, and be sending emails just like that. Over the years, MailChimp has added a bunch of features for our users beyond just the email delivery part, and wrapping your head around all of that can be too much (have you seen the spec for the templating language?), especially when you’re a busy developer looking for a quick way to knock out a feature. Tack on to that the fact that you can’t create users or lists through the MailChimp API, and it’s enough to get most integrators to go from “Yeah, let’s do this!” to “Ummmm, hmmmmm – we’ll get back to you” in no time flat. Having this happen to us more than once led us to try to search for a solution, and I’d like to share what we’ve come up with.

Read More

For those who don’t like videos: AlterEgo provides an easy way for consumer web applications to extend their security just a little bit beyond the standard username/password combo.  Unlike more traditional two-factor authentication solutions, AlterEgo is designed to be simple, easy, and free for both users and applications.  Using AlterEgo, you add an additional layer of security to your accounts by generating simple one-time codes that must be entered before allowing login into an application.

Presuming that you don’t use the same credentials for AlterEgo that you use for your protected account (and ideally access them from different machines), it makes attacks on your account harder – not impossible, just a bit harder.

Read More

[Update from Ben: 02/08/2011] We wrote this blog post to show that current self-reported “deliverability scores” and “inbox rates” are hard to believe. You have to take the ESP’s word for it that they get “99% to the inbox”. What we need is a truly independent scoring system that anybody can use to verify ESP deliverability claims. We thought we found that (or got pretty darn close) in ReturnPath’s SenderScore.

The first few comments we got were understandably furious. But eventually, the conversation changed. We think we were on the way to a very constructive discussion. I really enjoyed the dialogue I had with people offline as a result of all this, and I want to thank all the email companies who commented here — CritSend, CampaignMonitor, PostMarkApp, and Al Iverson’s A-1 Super Awesome Home DSL Email Service. :-)  I mean, don’t get me wrong. We’re competitors. We’re not going to be singing Kumbaya around the campfire with each other any time soon. It’s just nice talking to people who know their stuff. I wish the discussion could continue.

But my patience has been worn down. ReturnPath is naggi—asking me politely to take this post down, because they “don’t want to arbitrate arguments between their partners.” [I didn't realize we were asking them to arbitrate] I suggested that, as an independent, unbiased scoring system, they should just do what I do: ignore the bastards. Actually, I suggested the complainers needed to “grow some” and that ReturnPath ought to tell them so. But that’s not how ReturnPath rolls (thankfully, I guess).

Anyway, some of the arguments we heard about our posted methodology seemed to go like this: “Your methodology is flawed, because SenderScore penalizes IP addresses that send very low volumes, and that don’t have a high reputation. For example, I have an IP address that has GREAT inbox rates (um, trust me) but that have a low SenderScore.”

Well, yes. We know that low-volume, low-reputation IPs can get great deliverability.

Buuuut we happen to think that an ESP’s very job is to send high volumes of email while simultaneously maintaining a good IP reputation. We send out tons of email through our infrastructure, 24/7. If it were a race car engine, SenderScore’s our tachometer. Does it show actual vehicle speed? No. But it’s extremely indicative of engine performance. If we see our SenderScore drop from 94 to 70, there’s a problem with the engine. It’s time to pull over and get that deliverability fixed.

So to people who say “SenderScore is a bogus number” we respectfully disagree. It may not work for all senders, but it works for ESPs. The ones who send high volume. And want to measure their reputation.

Obviously, I am not concerned with what other ESPs think, or how they respond. But personally, I think that ReturnPath’s naggi — um, polite requests for me to pull this blog post is actually going to work against them. I think they’re defending the very people who are disputing the validity of SenderScore. On the one hand, that concerns me. On the other hand, I’ve always appreciated irony. And I absolutely hate the blinking red voicemail light on my office phone.

So this awesome blog post, which attempted to highlight the usefulness of ReturnPath’s SenderScore, is now officially yanked — at the request of ReturnPath.

Lately here at MailChimp we’ve been trying to bring in more developers to help us keep the innovation coming fast and furious as the application grows in scope and scale. It’s always been difficult for us to hire really good developers, just because of where we are. Our office is here in Atlanta GA, not exactly a hotbed of cool startups in the last few years. On top of that we’re fundamentally an email company, which is far from a sexy problem for geeks to sink their teeth into. But the biggest negative reaction we get when hiring new developers is when we mention the programming language we use.

Ewww, you use PHP? I thought you were cool!

Yes, I’m afraid we have to come clean. We use PHP here at MailChimp. For the non-programmers among you, PHP is a programming language that is extremely popular in dynamic web sites and applications. Even this blog is written in PHP. Despite its popularity, PHP is considered by the programming elite, almost without exception, as one of the worst languages currently in use today. The term “good PHP programmer” is considered an oxymoron.  Yet it’s the primary language we use here for development, and it’s the only language we use for everything touching the production MailChimp application. You can imagine the horror and surprise we see when we try to tell a good developer that we use PHP to solve cool and interesting problems.

So here’s my best answer to that.

Read More