Document that smtp_smarthost does not support port 465

[rdiez]

The Alertmanager documentation for setting smtp_smarthost should state that port 465 is not supported, as explained here:

https://stackoverflow.com/questions/63557145/alertmanager-not-able-send-mails-via-port-465

This has caused me some unnecessary head scratching. After all, that issue has been known for years.

Sending e-mails over port 465 is very common. I have been using it for a long time without any issue, the first problem I ever had was actually with Prometheus' Alertmanager.

Some big providers recommend port 465, for example:

https://www.cloudflare.com/learning/email-security/smtp-port-25-587/

[sysadmind]

That stack overflow question is about 5 years old. That doesn't seem to be the case anymore. Alertmanager very explicitly tries to handle TLS for port 465 here: https://github.com/prometheus/alertmanager/blob/main/notify/email/email.go#L133.

If you are having problems with a current version of Alertmanager, can you please open an issue with some details and steps to reproduce? I don't think the stack overflow question is still relevant.

[rdiez]

Thanks for the information.

I just looked at the change log here:

https://github.com/prometheus/alertmanager/blob/main/CHANGELOG.md

and I found the following:

0.8.0 / 2017-07-20 [ENHANCEMENT] Enable sending mail via smtp port 465 (#704)

But I had this problem recently with Ubuntu 22.04, which packages Alertmanager 0.23.0 .

I looked at pull request #704, and I found this comment:

you need to explicitly supply "require_tls" to false, in order to work with smtp port 465

Is this setting now called smtp_require_tls? Should the documentation say then that it needs to be turned off for TLS connections (usually with port 465)?

Last time I tried with Ubuntu 20.04, which packages Alertmanager 0.15.3, turning off smtp_require_tls did not help, I got error message "*smtp.plainAuth failed: wrong host name", which looked like a different bug: https://github.com/h44z/wg-portal/issues/13. Next time around, I'll try it again with a newer version.

An additional problem is that setting name smtp_require_tls is misleading. It probably actually means "Force STARTTLS on an unencrypted connection". Can you confirm this? The documentation for that setting looks like this, which seems kind of wrong or at least misleading if you consider the case with port 465:

# The default SMTP TLS requirement.
# Note that Go does not support unencrypted connections to remote SMTP endpoints.
[ smtp_require_tls: <bool> | default = true ]

[rdiez]

I think I understand the situation better now. E-Mail clients like Thunderbird have an SMTP option like:

Connection security: None
                     STARTTLS
                     SSL/TLS

But Prometheus Alertmanager lacks such an option.

Option smtp_require_tls lets you choose between None and STARTTLS. However, like I mentioned in #4505, None is not really supported outside localhost, so you are forced to set up encryption even in an internal LAN or virtual network.

It is documented as "Note that Go does not support unencrypted connections to remote SMTP endpoints", but it is probably not really Go, only the mail library Prometheus uses.

There is no clean way to select SSL/TLS. Because that was a problem, Prometheus implemented a quick hack: if the port number is 465, then it hard-codes the connection type to SSL/TLS. And that is not documented.

Is that right?

[sysadmind]

It is the Go language standard library that is used for SMTP transport. It requires TLS or localhost when using authentication. You could potentially have a remote server that doesn't require authentication and therefore you could have a plaintext session with the SMTP server. https://pkg.go.dev/net/smtp?utm_source=godoc#PlainAuth

I think that require_tls is a misnomer. What that setting actually controls is forcing the connection to use STARTTLS https://github.com/prometheus/alertmanager/blob/main/notify/email/email.go#L176.

All of this to say that currently you can use

• No encryption
• STARTTLS via require_tls
• TLS via port 465

I think it would be an improvement to add an option to use TLS even without port 465, but the misnomer of require_tls would require a breaking change to fix so it may not be worth the effort.