The email service made a conscious break with the SQS notification
structure, to make the recipients array more uniform. Rather than
sometimes being an object with an `emailAddress` property and other
times being a string, it makes the items plain strings on all
notification types.
When I added code for the new notification queue to this repo, I forgot
about that and just ported the SQS logic verbatim. This fixes it to
always expect plain strings in the recipient arrays.
Fixes#2633.
Once the email service starts handling bounce and complaint events we
will need a way for it to tell the auth server to emit metrics. This
change adds a handler + config for a new SQS queue to that end. It
duplicates some of the code from other handlers but that's intentional,
we plan to remove those queues eventually.
Different mail servers format the addresses in their bounce messages
in different ways, not all of them strictly RFC compliant. This change
makes us more lenient in what we accept, so that we don't error out
when receiving a bounce from a noncompliant server, so long as the result
ends up looking like a valid email address.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1393961
This settles our dance of `Buffer` vs `String` down to simply this:
> You have a `String`. You should (almost) never have a `Buffer`.
Buffers are useful for talking about a specific set of bytes, without an
encoding. In our app, the places where this is useful are:
- crypto
- mysql
We don't actually speak MySQL in this repo anywhere, so that leaves us
with only crypto. Instead of requiring the mental overhead of "Do I have
a buffer or a string?" throughout all our code base, we can just push
that completely into the crypto code.
This *should* reduce bugs where we aren't sure if we have a `Buffer` or
a `String`. If you're not in crypto, you should just have a `String`.
hritvi
Shane Tomlinson
Phil Booth
Vlad Filippov
Vijay Budhram
Ryan Kelly
Sean McArthur
Divya Biyani