Fix message threading when using Amazon SES as a mail provider.
Review Request #11727 — Created July 16, 2021 and submitted
Amazon SES has some non-standard behavior around Message IDs. Normally,
the sender (or an intermediary) will specify a Message ID for tracking
In-Reply-Toheaders, which can be used for bounce management or
automated threading. We depend on this for our threading model, storing
our generated Message IDs and attaching them to any replies.
SES overrides any provided Message ID, which impacts our threading. They
do provide a mechanism to get part of the overridden Message ID, by
using a non-standard addition to the SMTP spec, which is to grab the
250 Okafter sending the e-mail and parsing out what's currently
a UUID after the
smtplibdoes not support getting this information. Nor does
Django's e-mail code. In order to access it, we provide our own SMTP
backend, which is a subclass of Python's, and override the method used
to get the result of sending an e-mail and store that for later
We then subclass Django's backend and pull out this result. If the SMTP
hostname is an SES endpoint, we parse out the region and activate
post-sending logic, pulling in that reply, checking if it appears to
have the first part of a Message ID (the UUID), and then build on the
domain (which will be
email.amazonses.comfor us-east-1, or
<region>.amazonses.comfor anything else) and store it back in the
message, where it can be retrieved.
This works for now, though as Amazon's behavior is non-standard and they
don't offer official guidance, it's always possible this logic will need
to be adjusted down the road.
For anything other than SES, the new backend should not introduce any
Unit tests pass on Python 2 and 3.
Tested with a customer who was running into threading issues with SES.
We confirmed that this patch fixes it.