Email Service - Add a postmarkapp Email provider and switch to it.

[flea89]

We're currently using Mailchimp transactional emails (mandril) to send notification emails in web3.storage. We should use postmarkapp instead.

Context

Mailchimp transactional is pretty bad. It has a poor UX, has quite a few limitations (see https://github.com/web3-storage/web3.storage/blob/main/packages/cron/src/lib/email/README.md) and @hugomrdias suggested to migrate to http://postmarkapp.com/ which he's using https://github.com/nftstorage/ucan.storage and it's proving quite good.

Notes

We should be adding a new EmailProvider for postmarkapp, make it default and use it in our crons.

[jchris]

What is the level of effort to move the old email templates over? Is it worth punting on this or will consolidating on postmark app lower our maintenance burden in the longer term when the old API (this) is in maixtenance mode?

[flea89]

I haven't used Postmark, but @hugomrdias suggested it's pretty good.

You're correct, while in the short term the switch wouldn't have a direct impact on actual functionality/users, if postmark is good as advertised by Hugo, it would defo represent an improvement over Mailchimp, in particular by making changes and new email templates easier to manage. Makinig this ticket particularly relevant if we plan to expand the types of emails we send to users. That said if we are not planning to update email templates and add new ones I reckon Mailchimp is a bit painful to use but still "good enough" for now.

Let us know if you'd like us to estimate this.

[JeffLowe]

@mbommerez During website initiative, we determined we'll be utilizing postmark for the blog subscription services in nft and web3. We might consider rescoping this ticket to be switching any storage related crons to use the new postmark. In the immediate term, nothing is needed (mailchimp can still be used). But in the longer term transitioning over to postmark will likely be desired. Let's sync after we implement it for the blogs to coordinate on implementing for the storage related emails.

[mbommerez]

@JeffLowe @dchoi27

We have built the current email service for the storage limits in a solid and reusable, abstract way, inside a class in the current Storage Limit cron package. We believe it would be best to add a Postmark integration for that, rather than building a new email service from scratch.

Definitely worth testing out Postmark for the blog subscription services. We have learnt in the meantime that it's quite painful to make changes to the template and it's very error prone. So it might be worth integrating Postmark with what we have built for storage limits and find a way to refactor this to make it reusable across packages or even for both products. Might be worth investigating as it could save us quite some time.