Email copy of message to user

[randylubin]

This branch enables users to send a copy of their message to themselves.

It adds a checkbox on the Compose page and uses the AWS SES API to send the message.

The AWS keys need to be added to Config. The EFF email address needs to be added to eff-aws-ses.js

I would strongly advise a code review as my knowledge of the backend is rusty and I did some cargo-cult coding based on how we implemented the ‘subscribe to EFF mailing list’ feature (we should check to make sure that feature still works).

I haven't added any tests, though I'm not sure I needed tests for the sections I worked on. I would also like a quick check to see if the error handling is correct.

Thanks!

[wioux]

Thanks @randylubin! I've added notes on some things I think should be addressed before we merge (email config and error handling).

[randylubin]

Thanks @wioux – I'll try to get to these tonight or this weekend

[mfb]

Does this do bounce handling? for https://act.eff.org we have an endpoint to receive bounce notifications from AWS and add to list of bad email addresses - see https://github.com/EFForg/action-center-platform/blob/master/app/controllers/bounce_controller.rb

I'm not sure of the details for how we handle bouncing addresses - I would guess they need to be stored for some period of time N rather than permanently, after which we could attempt delivery again.

[randylubin]

@mfb Right now there isn't any endpoint for bounce handling; I think we'd need to use AWS SNS service.

These aren't critical emails and they're only sent once, whereas the Action Center might send multiple emails. It might be fine to ignore bounces in this case.

Another option would be use the shared list with the Action Center bounce list. Depending on how things are configured, that list might start getting the bounces from D.io with the current setup.

[mfb]

The problem is that AWS will shut us off if we send emails to a bouncing address at too high a rate, to protect sending reputation. This happens when someone is pentesting or otherwise attacking a site. That's why Mailgun is easier to setup than SES - they automatically ignore delivery attempts to bouncing addresses.

[randylubin]

Ah, makes sense. The best solution might be to have just one EFF SES service that handles requests from all other EFF projects.

It seems we have a few options, let me know which makes sense.

• I'm happy to recode it for Mailgun if EFF has an endpoint
• I'm can have the server check a shared bounce list if you have an endpoint for me to hit
• I can look into setting up SNS + an expiring email list in Redis. We already have an IP throttling set up that I can reference. This is a bigger project and I may need some help.

[mfb]

The redis bounce list sounds fine (as long as it has good uptime, because we'd need it to last longer than the IP throttling). AWS doesn't disclose what is the maximum bounce rate: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/e-faq-bn.html A shared bounce list sounds neat but overly complex because we have to figure out more APIs for apps to talk to each other.

We haven't starting lining up another email delivery provider but it's doable.

[randylubin]

A possible quick solution: how about a captcha? That should mitigate the risks of pentesting / attack, right?

[sinak]

I think we should stick with the Redis. A captcha would work, but some users already need to fill in one or more captchas, so adding in another seems like a bit much.

@randylubin If the redis piece is a heavy lift on your end @l12s or @wioux might be able to help.

[randylubin]

I've started exploring the work around email bounces and it's a lot for me to bite off. I haven't done any work with Redis or Amazon SNS endpoints, though I'm sure I can learn. It might make sense to pair with someone in EFF who has access to the AWS console so we can get the notifications settings right.

I'm heading out on vacation for a week and can try to dive into this when I return (around Feb 25th).

Otherwise, this feature is ready to launch. We could also just launch now and disable the feature if our bounce rate is too high but that might be too high risk.

[sinak]

@wioux Would be awesome to get this feature live, as it's the single thing we get the most requests for. Any chance you have bandwidth to rake over getting the email bounces issue sorted?