EMail (SMTP) Notification doesn't work with IPv6 anymore

[tb1402]

📑 I have found these related issues/pull requests

A search for the keywords 'smtp' and 'ipv6' didn't find something related.

🛡️ Security Policy

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

📝 Description

I switched from version 1.23.17 to 2.0.2 recently, without any migration. As I don't have that many monitors, I just installed v2 and entered all the data again.

For some monitors in v1 I selectively filtered A or AAAA record with Adguard Home, as the HTTP monitor didn't had address family support back then. A domain filtered (allowing only AAAA) was the one of my mailserver, which is also used as a SMTP notification type.

Right after the new install of v2 the filters were still in place and returned only an IPv6 address for my mailserver domain, which resulted in a connection error while testing the connection in the Notifications section in the settings. As soon as i removed the filter, the IPv4 address was used by kuma to connect to the mailserver and to send the test EMail. So it seems like the functionality for SMTP Notification over IPv6 is somehow broken in v2.

👟 Reproduction steps

• setup kuma v2
• add a new notification with type EMail (SMTP) which uses a SMTP server domain that only has an IPv6 AAAA record in DNS
• try to test the connection in the notification setup dialog
• a connection error notification will be shown

👀 Expected behavior

As it was in v1, kuma should automatically pick the IP family for the SMTP notification and not use fixed IPv4.

😓 Actual Behavior

If the SMTP notification is used with an IPv6 only domain a connection error will show up.

🐻 Uptime-Kuma Version

2.0.2

💻 Operating System and Arch

Debian 13 arm64

🌐 Browser

Firefox 141

🖥️ Deployment Environment

• Runtime Environment:
  • Node.js: Version 20.19.2
• Database:
  • SQLite: Embedded
• Database Storage:
  • Filesystem:
    • Linux: ext4
  • Storage Medium: SSD
• Uptime Kuma Setup:
  • Number of monitors: 11

📝 Relevant log output

[louislam]

I think we haven't changed the SMTP logic since then, it is still using nodemailer to connect your SMTP.

Can you check inside the container if:

• the AAAA record is available
• it is able to ping your smtp?
• Really AAAA record only. No A record.

https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

Also it was an explanation from nodemailer's maintainer: nodemailer/nodemailer#1743 (comment)

[tb1402]

Thanks for the clarification.
I did some further testing and the linked explanation from nodemailer's maintainer exactly described the behavior I observed.

I still don't really understand why it somehow worked before kuma v2.
I also did a Debian upgrade (12 to 13) before installing kuma v2, maybe that somehow changed the handling of the 0.0.0.0 address (returned due to the adguard home filters) in the connection process of nodemailer.

My initial thought was that something happened during the kuma version upgrade, but that seems not be the case.
Since the install I fully adjusted my setup and reduced DNS filters, as v2 has IP family selection on HTTP monitors.
The kuma server can now reach my mailserver via IPv4 without any filters.
Sorry for bothering you and thanks again for your answer and for providing kuma!