Make emails easily accessible in dev environment

[patcon]

Right now, emails get sent out for password reset, and for data exports, and perhaps others things. For the latter, it's after some processing in the math component, which calls back to server to send email afterwards.

It would be great if email bodies/metadata could be inspected during development without trying to send a real email via Mailgun SaaS (currently the only way to send).

An alternative approach would be to try to send it via postfix, but printing to logs seems simplest.

I think this is where this would need to be added:
https://github.com/pol-is/polisServer/blob/806e77e508cd8c27a8c372502c111359fdd8b28e/email/sendEmailSesMailgun.js#L63-L73

Off the top of my head, this could be enabled in one of two ways:

1. setting devMode to true, and always printing to logs when in this mode, or
2. added a config like emailServer which could be one of logs or mailgun (or some future SaaS)

[joshsmith2]

+1! This would be super useful

[patcon]

Potential other option, perhaps in a separate docker container: https://github.com/maildev/maildev

[colinmegill]

Agree, this needs to be handled for local and non mailgun scenarios

[patcon]

@joshsmith2 Heads up -- Data export might not be working rn anyhow: #39 (comment)

[patcon]

From gitter chat: https://gitter.im/pol-is/polisDeployment?at=5eb2cacb7975db7ebfe99d9f

@crkrenn is +1 to suggestion on using nodemailer and transport plugins

[colinmegill]

Data export is not working. Cc Chris

…

On Wed, May 6, 2020, 5:40 PM Patrick Connolly ***@***.***> wrote: From gitter chat: https://gitter.im/pol-is/polisDeployment?at=5eb2cacb7975db7ebfe99d9f @crkrenn <https://github.com/crkrenn> is +1 to suggestion on using nodemailer and transport plugins — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/pol-is/polis-issues/issues/137#issuecomment-624905669>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANQGGJ7HSQGTC75XR47543RQHKMZANCNFSM4MROUXDA> .

[patcon]

I've got this working on a feature branch:

Currently, we fall through catches from AWS SES (first choice) and mailgun as a backup. Should we just fall through to trying to send to maildev if no AWS or Mailgun is configured? Alternatively, we could ditch the fall-through approach that's currently in there, and just set a config toggle between aws-ses, mailgun or maildev (or something)

[patcon]

Here's the pending branch for spinning up with a dev mailserver (from above screenshot):
dev...patcon:feature/231-dev-email

Still needs some work. The way it was set up before (pre-monorepo), SES was first priority and fallback was mailgun. This was hardcoded. Thinking it's be nicer to pass it a config that sets the mailer, including order of attempts. So, for example, in envvars:

EMAIL_TRANSPORT_TYPE=maildev would need no config, as just sends to the development mailbox in another docker container. This is what my branch does rn, which obviously isn't good enough for anything except dev :)

EMAIL_TRANSPORT_TYPE=mailgun would expect other config to be set, like MAILGUN_API_KEY and MAILGUN_DOMAIN. If that fails, then mail doesn't go out.

EMAIL_TRANSPORT_TYPE=aws-ses,mailgun would expect additional config as well, and would try SES first, but if it fails, it will then try mailgun. (this is what the old code did, but without ability to choose from amongst mail providers)

Thoughts?

[ballPointPenguin]

Thoughts?

I like this whole approach. I'd really like to leave the door open for other configurations, as much as possible, e.g. sendgrid. Maybe default to maildev, and for now allow for the others to be user-specified "mailgun", "aws-ses", or combo.

I wonder how necessary a fallback mail service really is. Does it ever get used? I've never set up an api to fall back to a second service personally. But hey, if it was working already, I'm not going to make a fuss.

[patcon]

I wonder how necessary a fallback mail service really is. Does it ever get used?

good call. would you know, @metasoarous? it does add more logic, and better to have less :)