Amazon SES about django-anymail HOT 18 CLOSED

[Anyone else wanting Amazon SES support in Anymail, please use GitHub's "thumbs up" reaction to vote for this issue.]

By the way, there are already at least two packages that implement SES EmailBackends for Django: django-ses and django-amazon-ses. Is there some reason neither of those meets your needs?

It would help me to understand if there are some specific Anymail features you're looking for from an SES integration. (The last time I checked, SES didn't offer most of the "value-added transactional" features Anymail exposes from its current supported ESPs.)

from django-anymail.

Just a thought, but I think one of the use cases would be for someone to have a backup ESP in case their main ESP is having issue (surprisingly it does happen and when it does, critical transaction emails are either lost or stalled, which is obviously not so good). Having a single abstraction for email handling would mean more consistency, less work and maintenance. Even without the disaster event, the ability to seamlessly switch ESP any time would be super useful.

from django-anymail.

from django-anymail.

Released in Anymail 2.1

from django-anymail.

For me, the the decision revolves around whether it's worthwhile and acceptable to have another dependency, with another set of opensource maintainers.

Maybe it's worthwhile asking the django-ses group whether they'd like to be absorbed by anymail, where the larger community of maintainers could work on maintenance and upgrades collectively.

Also, I suppose it begs the question as to whether anymail wishes to be the defacto standard and "one-stop-shop" for mail across all providers. If so, a more fully-fledged offering for SES is certainly one that needs to be considered.

I don't know the answer to these questions, by the way, but this is how I would look at the situation when considering how to proceed.

from django-anymail.

A nearly complete Amazon SES implementation is now available, if anyone feels like some real-world testing or feedback.

Pre-release installation instructions and docs.

from django-anymail.

@medmunds - Is anyone working on this branch, and is there any way we can help?

from django-anymail.

@thongly coincidentally, I was just looking at SES again yesterday. Looks like Amazon recently added a bunch of tracking and notification features that make SES more similar to the other ESPs in Anymail.

One thing that would still be helpful (from any of the upvoters reading this) is understanding why django-ses or django-amazon-ses isn't a good fit -- I don't want to duplicate those projects unnecessarily.

It'll be at least a couple of weeks until I get a chance to look at SES again. If anyone wants to take a crack at it before then, the help is always welcome! Just add a note to this issue when you start, and feel free to post work-in-progress/incomplete PRs for collaboration.

Dump of what I (think I) learned about SES yesterday...

• Simpler SES SendEmail API doesn't support attachments, so probably use SendRawEmail instead -- takes a fully composed MIME message. (Good news: Django's EmailMessage objects are really good at serializing themselves into fully composed MIME messages, since that's what Django's SMTP backend needs.)
• Just let boto3 deal with AWS credentials, etc.
• Message-ID is assigned by SES and returned from send call. Unclear what happens if we also provide a Message-ID header.
• SES doesn't have ESP templates or batch send. (Can ignore merge.)
• SES doesn't support delayed send_at.
• Tags and metadata: SES uses AWS's common key:value tags, which are more like Anymail's metadata than Anymail's list-of-str tags. Anymail metadata should probably become SES tags directly. For Anymail tags=['tag1','tag2'], could either handle as SES tag1:True, tag2:True, etc., or create a single SES tags:tag1,tag2 tag. Opinions?
• track_opens and track_clicks: SES supports as of last month, but there doesn't seem to be a direct API option to enable/disable on an individual message. Looks like you have to use an SES ConfigurationSet. Probably treat Anymail track_opens and track_clicks attrs as unsupported.
• Document (and test) how to select SES ConfigurationSet in Anymail's esp_extra
• Test SES EasyDKIM works on SendRawEmail (without Anymail needing to compute DKIM -- don't want to get into that)
• Webhooks: new SES "event publishing" feature covers send, deliver, reject, bounce, complaint (spam), open, click; use SNS for webhook delivery

from django-anymail.

any updates on this?

from django-anymail.

@kodeine I'm still waiting for feedback (from anyone) on why the existing django-ses or django-amazon-ses packages aren't sufficient for using SES with Django.

If those packages work fine, I don't want to needlessly duplicate effort going into them. Or if there are specific Anymail features that those packages don't or wouldn't want to offer, then an Anymail SES implementation makes sense—and knowing those features would help make sure the implementation covers them.

Without any responses since I originally asked about this, I've figured those other SES packages are solving the problem, and people maybe just weren't aware of them before finding them linked here.

from django-anymail.

@VuongN and @thongly thanks for the feedback—it's really helpful to have some user input.

I've had a chance to look a little more closely at django-ses and django-amazon-ses, and can see how it would be useful to also add SES support to django-anymail.

If you're just sending email, switching from Anymail to another EMAIL_BACKEND should be pretty straightforward. (That's the whole point of Django's EmailBackend abstraction.)

But if you're also handling email tracking webhook events (bounces, etc.), then it'd be helpful to have normalized SES events so you can reuse your existing Anymail signal handlers. (django-ses supports SES events, but defines its own signal API which is, naturally, somewhat different from Anymail's.)

On the other hand, django-ses supports some features that aren't likely to show up in django-anymail (like an admin reporting panel, and a sleep-based delay to throttle sends). The packages have different goals, and there's plenty of room for them to coexist.

I'd welcome a PR for SES support in Anymail. (My own focus is on finishing inbound support first.) The PR doesn't have to be fully baked—work-in-progress is fine, and probably better for something like adding a new ESP.

I would suggest basing it on boto3 (like django-amazon-ses) rather than boto2 (like django-ses). The two botos can run side by side, and I believe boto3 is preferred for new code.

from django-anymail.

I started with django-anymail for my project with Mailgun as an ESP, but now would like to switch to Amazon SES to cut costs. If it was just a matter of changing the settings under django-anymail then it'd have been really great, since I don't want to have a different dependency within my project (django-ses, etc.).

And of course, if we later decide to switch back to Mailgun due to it's extensive features, then we would like to do it with relative ease. Hence, it's better to have a switching capability within django-anymail.

from django-anymail.

@thongly thanks!. Btw, I finally added some developer notes on adding new ESPs. They're pretty rough, but might fill in some missing details.

from django-anymail.

from django-anymail.

Yeah, I thought SNS was required for webhooks, but it's been a while since I looked. Is there some other way to get SES "event publishing" to post to an URL?

(Also, my comment upthread has a bunch of SES->Anymail feature mapping notes from my research last fall.)

from django-anymail.

@thongly just checking in on your SES implementation. I'll have some time available to help starting next week, if you're ready to open a work-in-progress PR.

from django-anymail.

from django-anymail.

@thongly no worries. I'll start working on SES in the next few days, and will post a partial PR as I get going.

from django-anymail.