Mandrill changes

Last week Mandrill announced that they were discontinuing their free services and all customers would be required to have a corresponding paid Mailchimp account.

Going forward, all Mandrill users will be required to have a paid monthly MailChimp account and verify ownership of all sending domains. Important changes to Mandrill

mc-logo-2380f23aOn March 16th all new Mandrill users will be required to create a Mailchimp account and existing Mandrill users will be able to merge their Mandrill and Mailchimp accounts. All users will have to merge accounts by April 27th.

When I saw the announcement I didn’t think it was that big a deal. Mandrill, for better or worse, has been a source of spam for a while and I knew that Mailchimp would be taking some action to clean it up. To me, this change seems really all about being able to hold customers accountable. Mandrill users will need to have real contact information, be able to verify their domains and have a valid credit card. This is a step that was, at least to me, obvious.
sparkpostWhat I wasn’t expecting was the number of companies who think this is a dumb idea and that Mandrill is giving up valuable customers. I have no doubt that Mailchimp knows exactly which customers are going to walk and has a good handle on how much revenue this will cost them. Personally, I don’t think it’s actually that much revenue. To me, the majority of companies who will be walking away are those who can’t or won’t pay $10 a month for a Mailchimp account.
I suppose there are going to be customers who are already paying and who are going to walk just because they don’t want to be restricted to having to have a real account. Or customers who don’t want to (or can’t) pass Mailchimp’s anti-fraud protections. Or customers who’ve been terminated from MC but snuck back as a Mandrill customer. These customers, to me, feel like way more trouble than they’re worth.
My viewpoints aren’t shared by a lot of other companies in the industry. The good folks over at Sparkpost, have jumped at the opportunity to provide services for companies leaving Mandrill. They’re even offering to honor Mandrill’s pricing for companies migrating. I know Sparkpost has a great team of compliance and abuse desk folks, and I hope they have thought ahead to how they’re going to deal with problems that come with freemium services. Only time will really tell if it’s enough, though.
 
 
 
 
 

Related Posts

Services, abuse and bears

A couple weeks ago I wrote a post about handling abuse complaints. As a bit of a throwaway I mentioned that new companies don’t always think about how their service can be abused before releasing it on the unsuspecting internet.
Today’s blog post by Margot Romary at the Return Path In the Know blog reminds me that it’s not always new companies that don’t think about abuse potential before launching services.

Read More

January 2016: The Month in Email

Jan2016_blogHappy 2016! We started off the year with a few different “predictions” posts. As always, I don’t expect to be right about everything, but it’s a useful exercise for us to look forward and think about where things are headed.
I joined nine other email experts for a Sparkpost webinar on 2016 predictions, which was a lot of fun (see my wrap up post here), and then I wrote a long post about security and authentication, which I think will be THE major topic in email this year both in policy and in practice (see my post about an exploit involving Trend Micro and another about hijacked Verizon addresses). Expect to hear more about this 2016 continues.
My other exciting January project was the launch of my “Ask Laura” column, which I hope will prove a great resource for people with questions about email. Please let me know if you have any questions you’d like to see me answer for your company or your clients — I’ll obscure any identifying information and generalize the answers to be most widely applicable for our readers.
In other industry news, it’s worth noting that Germany has ruled it illegal to harvest users’ address books (as Facebook and other services do). Why does that make sense? Because we’re seeing more and more phishing and scams that rely on social engineering.
In best practices, I wrote about triggered and transactional emails, how they differ, and what to consider when implementing them as part of your email program. Steve describes an easy-to-implement best practice that marketers often ignore: craft your mails so the most important information is shown as text.
I re-published an older post about SMTP rules that has a configuration checklist you might find useful as you troubleshoot any issues. And a newer issue you might be seeing is port25 blocking, which is important if you are hosting your own email senders or using SMTP to send to your ESP.
Finally, I put together some thoughts about reporting abuse. We work closely with high-volume abuse desks who use our Abacus software, and we know that it’s often not worth the time for an individual to report an incident – but I still think it’s worthwhile to have the infrastructure in place, and I wrote about why that is.

Read More

Who pays for spam?

A couple weeks ago, I published a blog post about monetizing the complaint stream. The premise was that ESPs could offer lower base rates for sending if the customer agreed to pay per complaint. The idea came to me while talking with a deliverability expert at a major ESP. One of their potential customer wanted the ESP to allow them to mail purchased lists. The customer even offered to indemnify the ESP and assume all legal risk for mailing purchased lists.
While on the surface this may seem like a generous offer, there aren’t many legal liabilities associated with sending email. Follow a few basic rules that most of us learn in Kindergarten (say your name, stop poking when asked, don’t lie) and there’s no chance you’ll be legally liable for your actions.
Legal liability is not really the concern for most ESPs. The bigger issues for ESPs including overall sending reputation and cost associated with resolving a block. The idea behind monetizing the complaint stream was making the customer bear some of the risk for bad sends. ESP customers do a lot of bad things, up to and including spamming, without having any financial consequences for the behavior. By sharing  in the non-legal consequences of spamming, the customer may feel some of the effect of their bad decisions.
Right now, ESPs really protect customers from consequences. The ESP pays for the compliance team. The ESP handles negotiations with ISPs and filtering companies. The cost of this is partially built into the sending pricing, but if there is a big problem, the ESP ends up shouldering the bulk of the resolution costs. In some cases, the ESP even loses revenue as they disconnect the sender.
ESPs hide the cost of bad decisions from customers and do not incentivize customers to make good decisions. Maybe if they started making customers shoulder some of the financial liability for spamming there’d be less spamming.

Read More