I've had a Mandrill account for about 3 years, and a Mailchimp account for about 4. I just cancelled my Mailchimp account and listed the reason as how poorly they handled this situation and how they screwed a customer over. I can't in good conscience support a company that could do this. I'll take my business elsewhere.
Mandrill’s Betrayal
71–80 of 157 posts
Re: Mandrill’s Betrayal
#72[deleted]
Re: Mandrill’s Betrayal
#73What a mess and no way to treat the 'power' users who value you most (i.e. developers).
I've always found MailChimp's editor to be a complete and utter nightmare to use, for formatting — it's so buggy — not to mention random shut-downs of other sub-services (such as the advanced editor).
They really need to sort out their developer evangelism.
Re: Mandrill’s Betrayal
#74Big win for Mailgun, huge loss for MailChimp. They just stabbed developers in the back. Take note kids: this is a shining example of how not to market such a large product/service change. What a fiasco. Directly going against their About Page, failing to update their pricing page to indicate the change.. it's all bad. I'm in the camp of everyone else where the TOS change is forcing my startup leave. The net negative…
Thanks, after reading this I was just looking for a service to migrate to from Mandrill, and Mailgun looks great!
fyi, i use sendgrid, it has a pretty good free tier.
Re: Mandrill’s Betrayal
#75As a replacement consider mailgun ( http://www.mailgun.com ). I have used their free tier before when I had to send mail for a side project.
+1 for Mailgun! Reliable and really developer friendly mature API.
Re: Mandrill’s Betrayal
#76Does any other provider (Mailgun? SendGrid?) support EU standard clauses and send them on request? Mandrill does this. EU startups are out of options otherwise.
Re: Mandrill’s Betrayal
#77Some head-to-head comparisons of Mailgun and SendGrid, for those trying to find an alternative provider. - Free Tier : Up to 10k emails/mo with Mailgun, up to 12k with SendGrid. - Low Volume : To send 100,000 emails/mo on a shared IP, you'll pay $45 with Mailgun or $20 with SendGrid. - High Volume : To send 300,000 emails/mo on a dedicated IP, you'll pay $204 with Mailgun or $199 with SendGrid. - Deliverability : In…
The Mailgun spam rate of 37.5% [1] seems both awful and unusual as no other provider seems to suffer from this. Does anyone know if this data is flawed, or what's the story here? [1] As reported by https://www.inboxtrail.com/compare
Email from Mailgun's shared IPs is being flagged as spam by Hotmail and AOL, which may indicate insufficient warmup with those services (e.g. Hotmail is not familiar with some of their shared IPs yet, and suspects them of sending spam until proven otherwise).
Methodology: a mock verification email with properly structured markup, a verification button, and no marketing content, sent to each provider. https://www.inboxtrail.com/compare#how
Re: Mandrill’s Betrayal
#78Mailchimp has a made a terrible mistake. Firstly: Before, you could get "up to 12k emails per month" for free. Now, you get 2k free sends once (for dev), and then have to pay $9.95/mo. This all sounds actually great, so far (although, I think $4.95/mo would have been a better bottom-tier plan - the goal is to get rid of users that don't pay anything but send 12k emails per month). $9.95/mo is affordable to any startu…
Couldn't agree more. I was sending a couple of thousand emails a month with mandrill for free. Would have happily paid 9.95 a month. But when I got their email, and read their blogpost, it was completely unclear what I had to pay. The message I got from them was, "sorry, don't want your business."
With this, and Kimono, in one week, I am moving to amamzon ses, though it has very few reporting features. Sorry Sendgrid/Mailgun, but TWICE burnt, and all that...
Re: Mandrill’s Betrayal
#79Big win for Mailgun, huge loss for MailChimp. They just stabbed developers in the back. Take note kids: this is a shining example of how not to market such a large product/service change. What a fiasco. Directly going against their About Page, failing to update their pricing page to indicate the change.. it's all bad. I'm in the camp of everyone else where the TOS change is forcing my startup leave. The net negative…
This is where we're at too. We've long been evangelizing Mailchimp and Mandrill in our product, and as a result have sent plenty of customers their way. In fact, our product almost relies on them as a pair. Now, because of the ToS, we have to remove it from our product and port our users somewhere else...and fast. We also have to port our own servers to another service, and fast. I remember the day we finally had eno…
> We also have to port our own servers to another service, and fast.
Once you've done that you should look at what other services you rely significantly upon and see about mitigating the risk there by having an alternative ready to go (or even sharing the load).
At a previous startup we realised we relied wholly upon Mandrill and so reimplemented the sending code so that half of the emails went out via Mandrill and the other half by SendGrid. A stunt like the above just requires a quick reconfigure to make all emails go via the alternative provider whilst we (with less panic) add another new alternative provider to share the load. It also helps build up a positive reputation before cutting over straight away.
(This wasn't about splitting the emails amongst free tiers to keep it free, we were far away from moving up to a paid tier even with all emails going through one provider.)
Re: Mandrill’s Betrayal
#80Was very disappointed with Mandrill as I've been using them reliably for the last couple of years. I did a bit of research as soon as the news was announced. And found Sendgrid the most on par with what Mandrill was offering. It seems a tad slow, but it's ok. Someone mentioned SparkPost, but quite a few emails from them were going to SPAM folders.
I work on SparkPost's app dev team - I know you've decided on another route but would love to understand what you were seeing. If you'd be willing to share details with developers@sparkpost.com or on http://slack.sparkpost.com we'd really appreciate it.
Additionally, we have an awesome deliverability team over here and we work very closely with our users to diagnose and resolve problems like this efficiently. They'd be happy to chat with you about inbox placement should you decide to re-investigate :)