Amazon SES v2
1oglop1 opened this issue · comments
Hi, this is just a heads-up.
I've noticed that AWS released SESV2 API which is a bit different from V1 implemented in anymail.
There is a change that "Raw" email method is changed to parameter of SendEmail
See affected methods:
V1
SendRawEmail
SendBulkTemplatedEmail
V2
SendBulkEmail v2
SendEmail v2
This also results in IAM permissions changes
V1
"ses:SendRawEmail",
"ses:SendBulkTemplatedEmail",
V2
"ses:SendEmail",
"ses:SendBulkEmail"
PS. Feel free to close this issue if you do not plan to update because it may be unlikely that AWS is going to deprecate standard SES API any time soon.
Thanks for the pointers. I'm… not exactly sure how to handle this.
It looks like AWS introduced SES v2 over a year ago, but there's (still) a surprising lack of information (official or otherwise) on why they created a new API, or when you'd want to choose v2 over v1.
FWIW, the "guide" section of the Amazon SES docs seems to still be using SES v1 for all of its examples: https://docs.aws.amazon.com/ses/latest/dg/send-email-api.html
It looks like one big advantage of the SES v2 API is the ability to send and receive larger messages—up to 40 MB (increased from 10 MB send and 30 MB receive). This was just changed a few weeks ago. [Edit: nope, this is unrelated to v2; see next comment]
Also, there's apparently a "deliverability dashboard" that's only available when using v2? Or only configurable using the v2 API, but maybe applies to email sent using either API? (It's not really clear. But either way, the deliverability dashboard involves a substantial additional monthly fee.)
Other than that, there doesn't seem to be any change in sending capabilities. (The v2 SendBulkEmail only works with templates, so seems to be exactly equivalent to v1's SendBulkTemplatedEmail. And v2's SendEmail seems to just combine the functions of v1's separate SendEmail, SendRawEmail, and SendTemplatedEmail.)
Anymail should probably support SES v2, if for no reason other than the ability to send larger attachments [Edit: if someone identifies a need for it; see next comment]. I think the safest way to do this (to avoid breaking existing code/config) is to introduce a new amazon_sesv2 EmailBackend and (I guess?) tracking and inbound webhooks, while keeping the existing v1 versions around in parallel. (So I'm going to treat this as a request to support a new ESP.)
Actually, looks like the 40 MB limit is also available with SES v1. (And the announcement I linked above was about them extending these limits to v2.)
So I'm back to being confused about the differences between the SES v1 and v2 APIs. It kind of feels like v2 is an early developer preview to experiment with some new features, but which is missing a bunch of functionality from v1. (E.g., v2 doesn't seem to have any of the receipt-rule actions needed for setting up inbound email through SES. And v2 adds a new "contact list" capability, which seems to be aimed at managing bulk mailing lists, like MailChimp or Marketo. But I don't see any way to send email to a contact list—the v2 SendBulkEmail action takes an array of individual recipient emails.)
If anyone wants or needs to use the Amazon SES v2 API with django-anymail, please add a comment here explaining the use case. (Or if Amazon releases some guidance, that'd be helpful too.) Until then, I'm probably not going to take any action on this.
It's difficult to say whether it's a preview or not, I also spent some time trying to find out any news but had no luck there.
I think that V2 is refactored and restructured to match the new UI, also methods and responses are more clear to me.
I'm not sure what's the story with recipient rules (receiving e-mails is limited to some regions).
I also like the idea of a separate backed amazon_sesv2.
I've been on a support thread with AWS for some days now about trying to raise the attachment size limit to 40 MB on SES v1. I'm not sure if they're going to be able to help or not, but it's clear that this is a non-standard request for them. I sent them the announcement link that @medmunds provided - thanks very much for that link!
I'll update here with what I learn from AWS support, but I think the takeaway so far is that adding support for SES v2 would be a good idea - it doesn't seem like 40 MB attachments on v1 are a trivial thing to turn on.
After further discussion with AWS Support, it turns out that v1 does not support the 40 MB limit. Only v2 supports larger attachments.
I don't have the bandwidth at the moment to write the v2 adapter (I wish I did!), so this is just a note that a v2 adapter for Anymail would provide benefit over the current v1 adapter.
I've started work on an SES v2 backend. It should be a drop-in replacement (unless you're using API-specific esp_extra params), but will considered a breaking change because of the need to update IAM permissions for the new API.
The plan is to make the SES v2 backend available alongside the existing SES v1 backend (opt-in) at first, and then later this year do a breaking-change release where the v2 backend replaces v1. Assuming v2 can do everything v1 does, Anymail would also drop support for the SES v1 API at that time.
Amazon SES v2 API support has been released in Anymail 9.1. It's not currently the default; to opt in, add "v2" to your EMAIL_BACKEND setting:
EMAIL_BACKEND = "anymail.backends.amazon_sesv2.EmailBackend"You may need to update your IAM permissions. See Migrating to the SES v2 API in the Anymail docs for more info.
(In my testing, IAM permissions for v1 ses:SendRawEmail seem to also allow v2 ses:SendEmail, at least as used by Anymail. But you'll definitely need to update IAM to add v2 ses:SendBulkEmail if you use Anymail with SES templates or batch sending.)
(Also, watch out for misleading IAM error messages that reference the v1 API names for permissions problems calling the v2 APIs. This suggests that the v2 APIs might be forwarding to the v1 APIs under the hood—or at least reusing a lot of v1 code.)
Please open new issues for any problems you discover using the SES v2 backend. I'm currently planning to make v2 the default, and drop support for v1, sometime late in 2023.