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
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.