Page MenuHomePhabricator

Amazon is retiring SMTP V3 Signatures
Closed, ResolvedPublic


Per PHI1844$460

Needs to be updated to use the V4 Signature model instead of the v3 model AWS3-HTTPS

To enhance the security of Amazon SES customers, beginning October 1, 2020, support for Signature Version 3 will be turned off (deprecated) in Amazon SES, and only Signature Version 4 will be supported going forward. Amazon SES customers who are currently using Signature Version 3 must migrate to Signature Version 4 by September 30, 2020. After that, Amazon SES will only accept requests that are signed using Signature Version 4. For more information, see the Signature Version 4 signing process in the AWS General Reference [1].

Event Timeline

aeiser updated the task description. (Show Details)
epriestley triaged this task as Normal priority.
epriestley added a subscriber: epriestley.

I think every other AWS interaction already uses v4, since D14978 (January 2016).

We currently use a small, mostly-pointless piece of third party code ("SimpleEmailService.php") to interact with the SES API. The simple fix here is to just replace it with first-party code using the common AWS infrastructure, which was desirable anyway:

An adjacent change which is also desirable -- but significantly more complicated -- is to also move to a first-party SMTP client. The SES API is, roughly, a little bit of metadata wrapped around an SMTP-formatted mail body (there may be some more specific name for this "raw mail" format, but I don't know it if there is one):

Progress can be made toward T12404 while resolving the signature version issue without going all the way: SES only needs the code to format the mail body properly, not the code to speak the rest of the SMTP protocol. So an ideal version of this change is probably:

  1. Move the API call to a new "SESAPIFuture", completing T13235 and updating the signature algorithm.
  2. Move SMTP body construction to a new first-party class, completing some of the work in T12404.
  3. Test the changes concurrently.

This presumably worked. T12404 survives it, but that task captures everything remaining here.