Support of an alternative transactional email services? (Post Mandrill)

[dh1tw]

Hi,

since Mandrill will close down soon, I wanted to ask if you consider supporting an alternative transactional email service?

I love Djrill and it has done an awesome service for the last few years! Would love continue using it with an alternative service.

[medmunds]

The short answer is, yes!

I started looking at this a few days ago. I think it's possible to create a set of interchangeable Django email backends that make it (relatively) easy to switch between transactional ESPs. The new backends would provide a normalized Django API to some common ESP functionality, like attaching metadata to a message, delivery webhooks, etc.

Initially, I'm looking at Mailgun, Postmark and SendGrid (as well as continuing support for Mandrill, to the extent possible). It looks like all of those ESPs support:

• All of the standard email features (from & reply-to, to/cc/bcc, subject, custom headers, html/text bodies, attachments, inline images)
• Some level of tagging and attaching metadata to sent messages
• Delayed sending (Mandrill's send_at)
• Open tracking and (except for Postmark) click tracking
• Delivery webhooks (e.g., sent, bounced, rejected)
• Event tracking webhooks (e.g., opened)
• Inbound email webhooks

So I think the new email backends can easily offer all those features.

Templates will be a little trickier. All the ESPs support some version of templates and merge vars, but there's a lot of variation in approaches. Some support per-recipient merge vars, some support global merge vars (substituted in all messages in the batch), and some support both models. The new backends can normalize some of this, but using templating across ESPs won't be as easy as with the other features listed earlier.

Also, each ESP uses its own template syntax, so moving your templates to another ESP will require some manual porting. (Of course, if you've used Django templates for your Djrill email, none of this will be a problem.)

I'm pulling the basic project together now, and expect to have something people could start playing with (and contributing to) by early next week. Given the short timeframe in Mandrill's announcement, my goal is to get the new backends to at least beta quality as quickly as possible.

In the meantime, for any Djrill users reading this, it would help to know if:

• there are specific Djrill features you rely on that I didn't mention above
• you're using a version of Django earlier than 1.8
• there are other transactional ESPs you'd consider important for the initial release

[luanfonceca]

:heart: :heart: :heart:

[luanfonceca]

For me, the best alternative is the Sendgrid, because it is free with 12k emails and have almost the same features, i will be using it for now in my non-django projects.

[dh1tw]

thanks for the great news @medmunds!

For me personally any of the mentioned providers are fine. I have no personal preference. Almost all of them have a free quota which I haven't max out yet. I have only a low volume of emails and these are usually template free account confirmation / password reset mails...

I would be happy to beta test and provide feedback!

PS: I'm on Django 1.9

[diwu1989]

just to chime in, I'd like to throw in another vote to prioritize the sendgrid backend

as for

Delayed sending (Mandrill's send_at)
Delivery webhooks (e.g., sent, bounced, rejected)
Event tracking webhooks (e.g., opened)
Inbound email webhooks

we implement our own django view to handle those directly, and only use djrill for email sending functionality.

I'd say a very acceptable MVP for us that will cover all of our needs is just email sending functionality. We looked at other libraries that handle sendgrid->django integration and they are not very actively maintained and rely on outdated versions of the sendgrid python library (thus not as enterprise ready as we need)

[medmunds]

OK, it took a little longer than I intended, but an initial version of django-anymail is up on GitHub and PyPI. Thanks for your patience.

Anymail should feel pretty familiar to Djrill users. There are a few notes on migrating in the docs.

Right now, Anymail supports Mandrill and Mailgun, simply because they're both requests-based APIs. A lot of the heavy refactoring was covered by that work, so I hope the other ESPs can go quicker.

I'm starting the SendGrid implementation even as we speak.

Suggest we take further discussion over to that project. I've started sequencing some of the remaining work into milestones in Anymail's issues, and there are at least a couple of areas where additional input would be helpful.

[medmunds]

SendGrid support is now up on PyPI.

[diwu1989]

This is really really amazing, thank you! If you ever come to Redwood City, drop by BetterWorks, we'll treat you to dinner.

[medmunds]

Thanks, appreciate it.

Postmark support is up now, too, and I'm feeling (perhaps foolishly) confident enough to call Anymail an 0.1 release. (You know, without the "dev" part.)

I'm also dogfooding Anymail on my own side project. I'm using SendGrid (they seem to have a lot of the analytics features that I liked from Mandrill), but after digging in deep while implementing Mailgun and Postmark in Anymail, I really don't think you could go wrong with any of those three.

[mallyvai]

Thank you for doing this @medmunds!! I don't mind paying for things but $40 a month for low volume transactional email usage is just silly. Glad to see the flexibility with this well-designed backend.

[medmunds]

Continuing this discussion over at django-anymail.