Let's take a look back at the features and improvements released for Mandrill in the last week.
Rules engine now available to all
For many of our users, one of the great appeals of Mandrill is how easy it is to get started. Since we accept mail using plain old SMTP, there's a pretty good chance that your platform already supports Mandrill without writing any custom code. But, if you want to really take advantage of Mandrill's powerful platform, you need to write code.
So this week after months of beta testing, we're exposing some tools that make it easy to customize your Mandrill email behavior without writing any code. It's all part of someting we call the Rules Engine.
The rules engine allows you to take actions when events or messages meet particular criteria. You can think of rules as following the sentence structure "if the email matches this then do that." For example, "if the email is sent from email@example.com then add the notifications tag." A rule can have multiple criteria and the criteria can contain wildcard pattern matches, so you can really get creative with creating custom logic for your emails.
Because rules can make automated changes to the emails you send, it's important to be sure that the rules only match the emails you intend. To help with that, Mandrill will tell you how many emails you've sent in the past seven days that match the criteria. Obviously, we can't tell you whether emails you haven't sent yet will be changed (no psychics on the payroll, unfortunately), but we find it to be a valuable gut check before clicking save.
Now this might get a bit mind-bending, but because rules can both change the content of messages and match on the content of messages, it's important that they are applied in a consistent order. To take an example, you might have one rule that matches emails with a particular sender address that sets the template to my-template. You may also have another rule that matches emails using my-template and adds the tag my-tag.
Whether or not the email has my-tag depends on whether the rule to add the template is applied before or after the rule that adds the tag. To help control this, Mandrill lets you sort your rules, and they will be applied consistently from the top of the list to the bottom. This can give you a lot of power by creating rules that prepare for other rules further down the list.
Hopefully this gives you a sense of the powerful custom logic that the rules engine lets you create without writing any code or using the API at all. We're really excited to see what you do with this, so stay tuned for future blog posts going into cool use cases with more detail.
Speed improvements redux
For the third week in a row, we've managed to improve the performance of sending with Mandrill. When you hand off a message to Mandrill, either via SMTP or the API, that message gets passed between several servers before we deliver it to the recipient's ISP. For large batches of messages, we've always taken advantage of keepalive connections for this internal communication, in order to minimize connection handshakes and reduce the impact of network latency. We've now built a way to allow single-recipient message to benefit from these same optimizations, and in the process we shaved about 200 milliseconds off of the time it takes to send a message.
This brings the median total sending time, from the moment the request leaves your servers to the moment it hits the inbox, to under one second. Not bad! For our next series of optimizations, we're looking into ways to change the speed of light inside our datacenters. Stay tuned.
We've added an optional authentication mechanism for webhooks. Webhooks are a powerful way to integrate Mandrill directly into your application, but because webhook URLs have to be publicly accessible, you may want to be able to verify that webhook requests are actually coming from Mandrill and not an unauthorized third party.
We now generate a cryptographic signature with each webhook request and pass it along in a X-Mandrill-Signature header. Your application can use this signature to verify the authenticity of the request. And because this authentication mechanism is entirely optional, if your application isn't dealing with sensitive information, you can keep on handling webhooks the way you always have.
More on webhook authentication: http://help.mandrill.com/entries/23704122-Authenticating-webhook-requests