Lots of big things going down this week, including some changes to the quota system that affects just about all Mandrill users. Let's break it down.
Templates are now more than just HTML
We originally conceived of templates as a simple way to let non-technical people edit the HTML of their application-delivered messages. We even integrated with our sister product MailChimp to make editing templates even easier. Once the feature was launched, we were inundated with praise for having templates, but you guys wanted more than just HTML - a lot more. So, starting today, templates can control even more of the sending options for your email. You can now specify a subject line, sender address, and text part for messages sent using a template. When you send your messages using the messages/send-template API call, you can now leave off the from_email, from_name, subject, and text parameters from your call and it will fill in the values from the template instead. On top of that, we've overhauled the templates interfaces to reflect this new direction.
Higher starting quotas and better mixed sending
One of the biggest challenges of running an email service is the anti-abuse system. For Mandrill, we use initially low sending quotas that react to user behavior over time as a way to control the risk of bad emails going out. We set the starting quotas very low (25/hour) to be sure that we were protected. With more experience in anti-abuse for transactional email, we're ready to loosen the rules a bit. The sending quota for users with a new or uncertain reputation is now 250/hour for free users and 2,500/hour for paid users. If you're sending low volumes of email or are a relatively new user, you should see your quota increase immediately. Larger users that already have big quotas won't see any significant changes. This part is just for the newbies.
Another critical aspect of Mandrill's anti-spam systems is that it sets your quota relative to your normal sending traffic. This is a pretty common-sense thing - having a good reputation when sending 200 emails per day doesn't mean that you're still being good if you suddenly send 2 million emails. In practice, it had another benefit since more often than not sudden changes in volume were signs of user mistakes. Maybe your website was hacked, or maybe you just sent your developers 200,000 exception emails because of a bug in your app. It even became the most popular support ticket for Mandrill back before we let users clear their own backlog. However, there were a few cases where users with lots of sending volatility would have a hard time warming up their quota - mostly users that were sending both constant volumes of transactional traffic and infrequent bulk traffic in the same account. To be slightly technical, we're now baselining your quota relative to your maximum volume rather than your average volume. If your volume looks like that, you should see your quota jump significantly and be easier to raise.
We've added a feature that gives you some finer-grained control over your quota. It's a boolean flag called "important" for our message sending API calls. When set, this flag will mark the message as more critical than other messages going through your account (think password resets or order notifications). We've reserved extra sending capacity in each account above and beyond your hourly quota just for these messages. If you have a big bulk campaign getting queued into the backlog, we'll reserve an extra 5% of your hourly quota just for important messages. In the future, we plan to do more with message prioritization, but these schemes can get quite complicated and we wanted to start with something simple.
Exposing more webhook data for inbound routes
Inbound routes are a way of directing email traffic to a webhook based on patterns in the recipient email address. Over the past few weeks, we added a bunch of extra debugging features to our webhook interface. That extra information is now also available for inbound routes.
One of the highest value ways for an application to integrate with Mandrill is using webhooks. In fact, it's such a good idea that we did it ourselves and are now sending webhook data from Mandrill to MailChimp for an even tighter integration. This has caused some problems. Users are sometimes confused when webhooks they didn't create suddenly show up in their account due to an integration they installed. To help clarify, we now allow you to add text descriptions to your webhooks so you can signal to the user where the webhook came from.
Message size limit now at 25MB
When we originally set up Mandrill, we set the message size limit to 10MB. That's the default message size limit for Postfix installations and is fairly common, particularly for corporate domains. Looking through the message size support for some of the bigger players, we saw that for major domains like Hotmail and Gmail, 25MB was more common. For maximum compatibility, you should still keep your messages below 10MB if you don't know the limits of the receiving server, but you can now send messages up to 25MB in size through Mandrill.