Gmail Relay-Smtp needs `name: mydomain.com` transport settings

[odyodyodys]

📑 I have found these related issues/pull requests

No related issues in uptime-kuma

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

Description

Google supports a relay service for smtp. The only change is to use smtp-relay.gmail.com as a host instead of smtp.gmail.com.

In uptime-kuma this usually fails with the error 421-4.7.0 Try again later, closing connection. (EHLO)

I traced that to be an issue with nodemailer. Its authors seems to have reasons to hate google's smtp

The solution seems to be to include name: mydomain.com when creating the nodemailer transport

A generic solution to this is to allow advanced smtp configuration and add all the fields that nodemailer transport supports. This will greatly improve support for SMTP.

👟 Reproduction steps

Set smtp-relay.gmail.com as the smtp host and use app-passwords for the authentication in google workspace. I am part of a google workspace, no idea if this works for single gmail accounts.

👀 Expected behavior

Send mails

😓 Actual Behavior

Error: 421-4.7.0 For more information, go to https://support.google.com/a/answer/3221692 - gsmtp: 421-4.7.0 Try again later, closing connection. (EHLO)

🐻 Uptime-Kuma Version

1.23.11

💻 Operating System and Arch

debian (official docker image)

🌐 Browser

Firefox 126.0

🖥️ Deployment Environment

• Runtime: Docker 24.0.5 (API: 1.43)
• Database: embedded
• Filesystem used to store the database on: embedded
• number of monitors: 80

📝 Relevant log output

No response

[CommanderStorm]

Please refer to https://github.com/louislam/uptime-kuma/issues/4473#issuecomment-1937004369 I have not found the time to do the nessesary testing. => if you have the time for this...

I don't think that we need to allow users to configure name, as there are alredy way to many settings in said notification provider to make sense of. => defering to the primary base url for the hostname (if configured) seems like a good choice

[odyodyodys]

I agree that we need to keep it simple, though if we set it automatically we are only handling cases where uptime-kuma is public, which I guess is rarely the case. It is usually configured behind a cloudflare tunnel or in a private network. In both cases name should not be the host as in the comment you are mentioning. In my scenario the service is hosted on a private network.

How do you think we can handle those cases?

[CommanderStorm]

What do you mean? The publicBaseUrl is the proper, outwards facing hostname you are getting uptime Kuma from...

It is set in the settings