Friday Release Notes for March 22, 2013

Just a few feature releases this week. We spent a lot of time setting things up for next week's additions.

Making the API docs executable

Our API has a lot of options and a lot of power behind it, which can make it hard to read the documentation and easily see how the requests are put together. We've added a "Try it" button next to every API call. Right from the docs, you can create a request and run it to see the real response or error that is generated - no custom code required! If you're logged into Mandrill, we'll even auto-fill the request with your API key to make it that much faster to get started. Under the covers, this just uses Mandrill's Javascript API client to make the requests from your browser. You can fire up your browser developer tools to get all the details on how the API requests are sent and processed.

Understanding webhooks better

Webhooks in Mandrill let your app be notified whenever anything happens to your email, like deliveries and bounces or opens and clicks. This feature works great when the receiving servers are up and responding correctly, but we didn't always do a good job of explaining what was going on when your server spews something other than 200 OK.

We've changed that to provide more context about exactly what requests we're trying to send, what the errors are, and when we'll try to send again. We've got even more ideas about how we can improve the process, but this goes a long way toward making things more transparent.

Adding more information to open and click webhooks

This one is really short and sweet. More data is always more better, right? Starting today, open and click webhooks will also include the IP address and user agent string of the recipient. The IP address is available in the event as the key "ip", and the user agent is available in the key "user_agent".

Adding spam filtering to inbound webhooks

We don't care much for spam around here, and we figure you don't either. To make it easier to detect spam in inbound mail, we now include a spam filter report with each message. We run the messages through a standard SpamAssassin rule set, and include the score and details about which rules matched in the information that we post to your webhook. We never discard an inbound message for failing a spam check; that's your decision to make. More information about inbound webhooks.

Behind the scenes: Improving the latency of Gmail delivery

Email delivery is subtle stuff. As a piece of infrastructure, the better your email delivery works, the less you think about it. This is especially true with transactional email, which needs to be fast: if you're waiting on an email so you can reset your password or activate a new account, every second counts.

This week, we made a few improvements to our queue management for Gmail recipients. We identified a specific set of ambiguous SMTP responses from Gmail: the responses included a basic SMTP status code that indicated a temporary server-level problem and an extended SMTP status code that indicated a temporary account-level problem. Our outbound servers were handling this ambiguity by injecting small delays into their queue handling for Gmail.

Most of our traffic wasn't affected by this, but once we adjusted our queue handling, our worst-case delivery times for Gmail dropped from from 2 minutes, 40 seconds to 7 seconds. Average queue times didn't change much, but worst-case delivery times are an equally important metric for time-sensitive transactional email.