SMTP UX Improvements #61
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
unclear if it makes more sense to write this in chicken scheme, or maybe Go instead. Likely Go has much better support for OAuth, SMTP, mime handling
maybe, just intercept the requests to inject the correct smtp config and then send it on to an existing open source SMTP relay?
Actually, it seems like this might be possible with https://github.com/simonrob/email-oauth2-proxy
even better, it seems like cloudflare could be used to actually deliver the email https://www.cloudflare.com/products/email-service/
The user connects their domain to Nassella (which utilizes Cloudflare DNS).
During the Ghost or Nextcloud deployment, Nassella programmatically provisions the necessary DNS trust records (SPF, DKIM, DMARC) and requests a scoped sending token from Cloudflare in the background.
Nassella writes these credentials directly into the application's configuration files.
The Result: When Ghost or Nextcloud triggers a password reset or notification, it hands the email to the local application layer, which securely relays it via standard SMTP to Cloudflare. Cloudflare signs it with the correct DNS keys and delivers it reliably to the recipient's inbox.
Unfortunately the cloudflare email service requires a paid account and would not be fully "no touch" by end users.
Thinking about this a lot more, I think Nassella should actually have a "master" email service account that users can use and is the default option. Ideally, nothing is tied to Nassella so user's can maintain their complete independence, but this seems impossible with email deliverability. Nassella could always provide the option though for users to manually input SMTP settings for their own email provider, so they still wouldn't be locked in. But google and microsoft have a stranglehold on emails and they have made it impossible to self-host mail sending. The only way to get emails delivered is to utilize an email service platform that can manage IP reputation. Since this is a fundamental issue that Nassella can't solve alone, I think it is reasonable that Nassella provides an easy-to-use option that is no worse than any other option while still allowing users to move to another option if they want.
This is not ideal but seems like the best solution that still generally meets Nassella's goals of not having vendor lock-in and being easy to use.
Going to integrate Postmark. Postmark allows us to have a separate "server" (folder) for each of the Nassella users. This will allow us to fully segregate each Nassella account. For user's that don't want to "bring their own" SMTP, we will create a "server" for them on Postmark and fully configure it for sending emails, including setting up the corresponding DNS, via API. Then we will configure SMTP for a user's apps to use the configured Postmark setup.
This should allow those users that don't want to bring their own SMTP config to have seamless transactional emails configured for them out of the box.