Closed mastercactapus closed 1 year ago
I think this feature can be enabled via CLI flags/env vars.
Flag | Type | Description |
---|---|---|
--smtp-listen-tls | string | Listen address:port for the SMTP server with TLS. |
--smtp-tls-cert-data | string | Specifies a PEM-encoded certificate for the SMTP server. Has no effect if neither --smtp-listen-tls nor --smtp-listen are set. |
--smtp-tls-cert-file | string | Specifies a path to a PEM-encoded certificate for the SMTP server. Has no effect if neither --smtp-listen-tls nor --smtp-listen are set. |
--smtp-tls-key-data | string | Specifies a PEM-encoded private key for the SMTP server. Has no effect if neither --smtp-listen-tls nor --smtp-listen are set. |
--smtp-tls-key-file | string | Specifies a path to a PEM-encoded private key file for the SMTP server. Has no effect if neither --smtp-listen-tls nor --smtp-listen are set. |
--smtp-listen | string | Listen address:port for the SMTP server without TLS (though STARTTLS will be enabled if cert/key is specified). |
--email-integration-domain | string | This flag is required to set the domain used for email integration keys when --smtp-listen or --smtp-listen-tls are set. |
--smtp-allowed-domains | string | Comma-separated list of additional destination domains allowed for SMTP. |
Some notes on implementation:
app/cmd.go
at the bottom and get parsed into app/config.go
.smtpsrv
or smtpint
just so it doesn't clash with the smtp
package(s) being used elsewhere.dedup
value) the same as in mailgun/mailgun.go
RCPT TO
address right away as an integration key.
What problem would you like to solve? Please describe: Currently, email-based alert creation in GoAlert is only supported via Mailgun webhook. This feature request aims at providing a cost-effective alternative by allowing GoAlert to work as a basic SMTP server that only receives emails.
Describe the solution you'd like: I propose an SMTP server configuration for GoAlert that enables receiving of mail. This will require admins to configure an MX record for their GoAlert domain. This would function as any other API endpoint, but with a separate port and unique syntax/protocol.
This solution would also mean that we have multiple potential providers of a single service (Email integration keys) for the first time. Multiple providers would need to be managed, either by only allowing one to be enabled at a time, setting a preferred provider, or requiring domains to be identical.
Describe alternatives you've considered: The current alternative is continuing to use Mailgun webhooks for all email-based alerts. This option carries potential costs and fewer customization options.
Additional context: Additional considerations include ensuring that all documentation is updated accordingly, and that the "preferred" provider's domain is used in any in-app links. Potential forward compatibility issues might arise, so it may be beneficial to support both methods of alert creation for migrating from one to the other.