[feature] Add a mechanism to filter out email addresses matching regex

[fubarhouse]

This PR adds a feature to prevent emails being sent when the from field matches a given regex which is provided to the environment via environment variable in a similar way you've got certificates and authorisation established.

I'll submit an issue to associate with this one.

[fubarhouse]

Just been informed the scope of work also includes to, so I'll have it updates shortly

[blueimp]

Thanks again for your contribution @fubarhouse and @tobybellwood!

Quoting the use case you've posted in #10:

We've a case where it would be ideal to configure the relay (running on k8s) to filter out emails if they contain problem email from addresses - which can be very useful for platform managers when managing client and platform reputation.

If possible, could you expand a bit on your use case?

I am trying to understand how you have untrusted user input (from email addresses) getting unfiltered to the SMTP relay?

The current configuration of the SMTP relay assumes only a trusted client can connect (via the single user authentication), since it's possible to send any kind of email content as any sender to any recipient.

If you want to allow specific users to only use specific from addresses, it's probably better to implement your own AuthHandler that can verify users and their assigned emails based on their authentication data (e.g. by accessing a user database).

There might still be good reasons to reject incorrect sender addresses (e.g. to prevent misconfiguration), so I'm open to implement filtering, but I would definitely prefer an allow-list regular expression to filter out sender email addresses. Could you also expand on your use case of a deny-list?

[tobybellwood]

Thanks @blueimp - we actually needed the functionality to suppress sending to certain domains (not possible with AWS suppression lists) or email addresses following a pattern (individual addresses if known can be added to suppression lists, but it can't support regex).

from suppression is usually handled by AWS verification, but we figured that we could use the same mechanism to suppress the relay from even trying for addresses we know aren't verified (or ever will be).

[tobybellwood]

for context - we know of at least one domain that is commonly used to fill in certain webforms on sites (with bogus info), and then submit large volumes of emails that also send a copy to the submitter. Gradually that domain uses a combination of email addresses that they know bounce and also they submit complaints - all to try to get your AWS SES service blocked - we'd like to stop this before it becomes an issue.

[blueimp]

Thanks for the explanation @tobybellwood, I understand your use case better now (the original use case description was only referring to from addresses and not mentioning sender addresses).

Some improvement suggestions:

• I think it would be better to have separate regexes for sender and recipient email addresses.
• For the sender email addresses, I think it would be preferable to have an allow-list, since there should only be a limited list of verified senders.
• For the recipient email addresses, a deny-list makes sense given your use case.
• I would prefer to provide any option as command-line argument, as those can be discovered via --help (or providing an incorrect argument). I've only used environment variables for secrets, since those should not appear in any process logs.
• I think the filter logic should be shared between the SES and Pinpoint versions.
• There should be additional tests for this functionality.

Since I am asking for a lot of changes and I also had some outstanding refactoring tasks, I've created a new pull request: https://github.com/blueimp/aws-smtp-relay/pull/12

Please have a look at this version and let me know if this solves your use cases.

[fubarhouse]

Was looking at something similar in my first draft, but I honestly wasn't sure how you'd like it.

Noting you've opted to use environment variables exclusively for secrets, I'll keep that in mind for next time. I love the implementation, especially given how well this application is tested.

[blueimp]

Thanks @fubarhouse, I'll add this to the master branch then.

[blueimp]

Sorry, I first merged your changes here by mistake, have now reverted master and merged the changes I was proposing. Sorry for the confusion!