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

• 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 #4473 (comment)
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