starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Version 2 SMTP checks appear not to respect /etc/hosts #4616

New issue

Open

opened 2026-02-28 04:09:21 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 04:09:21 -05:00

Owner

Originally created by @Stevehans on GitHub (Jan 16, 2026).

Possibly 1822

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

Environment:

Docker running latest v2

Start command:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --add-host mail.mydomain.com:172.30.1.18 --name uptime-kuma louislam/uptime-kuma:2

I have a host override in my /etc/hosts file

connect using docker exec

cat the hosts file I can see that it is there.
ping by name and it correctly uses the IP from the host file
tcpdump -i any port 25 and wait for the test to run, the address being used is the wildcard address for mydomain.com, not the entry in the host file

I have checked with NCSD enabled and disabled to rule this out.

I'll check how the SMTP test resolves the host now and update this if that is the issue.

👟 Reproduction steps

Create an SMTP monitor, set the verification to SMTPS and set the host to mail.mydomain.com (to match the host file)
Connection will not use the IP address in the host file but be resolved by the resolver.

👀 Expected behavior

Should use the IP address from /etc/hosts

😓 Actual Behavior

Appears to perform a lookup on mail.mydomain.com, which is then resolved to the wildcard address as there is no specific entry in the external public dns

🐻 Uptime-Kuma Version

2.0.2

💻 Operating System and Arch

Built container OS

🌐 Browser

Chrome

🖥️ Deployment Environment

Runtime Environment:
- Docker: Version 28.2.2
Database:
- SQLite: Embedded

📝 Relevant log output

Originally created by @Stevehans on GitHub (Jan 16, 2026). ### 📑 I have found these related issues/pull requests Possibly 1822 ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description Environment: Docker running latest v2 Start command: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --add-host mail.mydomain.com:172.30.1.18 --name uptime-kuma louislam/uptime-kuma:2 I have a host override in my /etc/hosts file connect using docker exec 1. cat the hosts file I can see that it is there. 2. ping by name and it correctly uses the IP from the host file 3. tcpdump -i any port 25 and wait for the test to run, the address being used is the wildcard address for mydomain.com, not the entry in the host file I have checked with NCSD enabled and disabled to rule this out. I'll check how the SMTP test resolves the host now and update this if that is the issue. ### 👟 Reproduction steps Create an SMTP monitor, set the verification to SMTPS and set the host to mail.mydomain.com (to match the host file) Connection will not use the IP address in the host file but be resolved by the resolver. ### 👀 Expected behavior Should use the IP address from /etc/hosts ### 😓 Actual Behavior Appears to perform a lookup on mail.mydomain.com, which is then resolved to the wildcard address as there is no specific entry in the external public dns ### 🐻 Uptime-Kuma Version 2.0.2 ### 💻 Operating System and Arch Built container OS ### 🌐 Browser Chrome ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker: Version 28.2.2 - **Database**: - SQLite: Embedded ### 📝 Relevant log output ```bash session ```

deekerman added the

bug

question

A:notifications

labels

2026-02-28 04:09:21 -05:00

deekerman commented

2026-02-28 04:09:24 -05:00

Author

Owner

@Stevehans commented on GitHub (Jan 16, 2026):

https://github.com/nodemailer/nodemailer/issues/1283

This appears to be the issue, nodemailer uses dns,resolve which does not use the /etc/hosts file

For my purposes it would be ideal if there was an extra field for tls.servername, then we could use an IP and everything would work as it should:

From https://nodemailer.com/smtp

When you specify a hostname, Nodemailer resolves it using DNS before connecting. If you use an IP address directly (or a hostname that only exists in /etc/hosts and not in DNS), you should also set tls.servername to the actual hostname. This ensures TLS certificate validation works correctly even when DNS lookup is skipped.

@Stevehans commented on GitHub (Jan 16, 2026): https://github.com/nodemailer/nodemailer/issues/1283 This appears to be the issue, nodemailer uses dns,resolve which does not use the /etc/hosts file For my purposes it would be ideal if there was an extra field for tls.servername, then we could use an IP and everything would work as it should: From https://nodemailer.com/smtp > When you specify a hostname, Nodemailer resolves it using DNS before connecting. If you use an IP address directly (or a hostname that only exists in /etc/hosts and not in DNS), you should also set tls.servername to the actual hostname. This ensures TLS certificate validation works correctly even when DNS lookup is skipped.

deekerman commented

2026-02-28 04:09:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 16, 2026):

Mail servers usually don't need some magic in /etc/hosts, so I would like to not add an option to overide tls.servername.
Usually, your monitoring server is external of what you are trying to monitor -> not the main usecase to use us to send messages directly as you suggested.

If you would still like to contribute this, I think we can accept this if:

it is in an advanced section
clearly documented under which case you might need this
done as a checkbox "Don't resolve hostname via dns" that if checked changes the hostname validation+name and adds a field for the server name with appropirate validation

@CommanderStorm commented on GitHub (Jan 16, 2026): Mail servers usually don't need some magic in `/etc/hosts`, so I would like to not add an option to overide `tls.servername`. Usually, your monitoring server is external of what you are trying to monitor -> not the main usecase to use us to send messages directly as you suggested. If you would still like to contribute this, I think we can accept this if: - it is in an advanced section - clearly documented under which case you might need this - done as a checkbox "Don't resolve hostname via dns" that if checked changes the hostname validation+name and adds a field for the server name with appropirate validation

deekerman commented

2026-02-28 04:09:25 -05:00

Author

Owner

@Stevehans commented on GitHub (Jan 19, 2026):

I'll look at compiling a pull request.

Use case is:-

Uptime kuma monitoring the external SMTP entrypoint is fine
Uptime kuma monitoring the internal relay over a VPN where the internal DNS is not available (the external DNS only provides a wildcard, the internal DNS resolves the names, but the VPN does not have access to the internal DNS).
In the above case, you'd want to monitor via IP address, but TLS will always fail as there is no way currently of passing the correct servername when accessing via IP

@Stevehans commented on GitHub (Jan 19, 2026): I'll look at compiling a pull request. Use case is:- * Uptime kuma monitoring the external SMTP entrypoint is fine * Uptime kuma monitoring the internal relay over a VPN where the internal DNS is not available (the external DNS only provides a wildcard, the internal DNS resolves the names, but the VPN does not have access to the internal DNS). * In the above case, you'd want to monitor via IP address, but TLS will always fail as there is no way currently of passing the correct servername when accessing via IP