How to set a sane SMTP Helo

[sebix]

⚠️ Please verify that this question has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

For SMTP connections, the app uses the bogous HELO 127.0.0.1, not the hostname.
How can the SMTP Helo be set, or set to the hostname?

📝 Error Message(s) or Log

EHLO [127.0.0.1]

🐻 Uptime-Kuma Version

1.23.3

💻 Operating System and Arch

Debian 10 amd64

🌐 Browser

Firefox

🖥️ Deployment Environment

• Runtime: Docker 20.10.17
• Database:
• Filesystem used to store the database on:
• number of monitors:

[CommanderStorm]

When you are refering to bogous HELO you are refering to the smtp extention discovery mechanism.
See https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Extension_discovery_mechanism:

Clients learn a server's supported options by using the EHLO greeting, as exemplified below, instead of the original HELO. Clients fall back to HELO only if the server does not support EHLO greeting.[24]

Modern clients may use the ESMTP extension keyword SIZE to query the server for the maximum message size that will be accepted. Older clients and servers may try to transfer excessively sized messages that will be rejected after consuming network resources, including connect time to network links that is paid by the minute.[25]

Users can manually determine in advance the maximum size accepted by ESMTP servers. The client replaces the HELO command with the EHLO command.

=> this is neither configurable, nor should it as far as I can tell.
=> I am going to close this as resolved. We can reopen if this is actually an issue and not just smtp working as intended ^^

As for this issue, please take the time to write proper issues (include the configuration, what you tried, where you got the log message from (this does not look like one produced by us), ...)
Remember that writing bad issues leads to you getting bad support

[sebix]

In the SMTP standards the HELO/EHLO are used for sending the own hostname.
You can read that also on the page you have linked:

The client initiates its dialog by responding with a HELO command identifying itself in the command's parameter with its FQDN (or an address literal if none is available). (rfc5321-21)

Btw, verifying the HELO name (e.g. comparing with reverse record) is part of anti-spam measures.

where you got the log message from (this does not look like one produced by us

This is an excerpt of the SMTP connection. There were no entries in /app/data/error.log

[CommanderStorm]

The name parameter should be set to the hostname of the machine by default according to nodemailer
See https://nodemailer.com/smtp/#connection-options

We currently don't set this parameter.
I currently don't have the time (exams) to propose a PR with the needed testing (attach screenshots) that this works.

If you want to change the current behaviour:
The primary base url (see settings, not guaranteed to be there) of the uptime kuma can be gotten via await setting("primaryBaseURL").
Our contribution guide is here: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

The relevant configuration is here:

uptime-kuma/server/notification-providers/smtp.js

Lines 15 to 22 in 56aa81e

	const config = {
	host: notification.smtpHost,
	port: notification.smtpPort,
	secure: notification.smtpSecure,
	tls: {
	rejectUnauthorized: !notification.smtpIgnoreTLSError || false,
	}
	};

[sebix]

Thanks, I will have a look!

[apio-sys]

Maybe I can help to clarify this "issue".

@sebix You are talking about outgoing connection to send email notifications right ? You are correct an email server should have proper hostname configuration, sending an appropriate HELO/EHLO corresponding to that hostname and having a PTR record that points it's IP to that host. Then you can start communicating with the rest of the world. However, I don't think it is within the scope of Uptime Kuma to act as an email server but just as a "client". Hence we use authenticated SMTP to have our (remote) SMTP server accepting the mail from us and forward it on where ever needed (he is the "mail server" not us on the app side). So the helo to there doesn't matter very much.

You could compare with your local Thunderbird or whatever mail client sending via same SMTP server to which you authenticate. If you have a local MTA - as I do - it is still the same really. You dump you local mail() command from whatever app, and up to your MTA or mail server to decide if you are auth to do that and then send on. Other discussion about that here #2793 .

In any case, and IMHO, you should not seek to have the node server behind UK to send email directly to the outside world but either relay via an authenticated SMTP of yours or your local MTA which should be configured to the outside world. This is not the role of an/any app.

Does this help clarify a bit?