Set SMTP HELO local domain using APP_URL

[Remoddy]

Describe the Bug

I would like BookStack to send e-mail via Gmail SMTP relay (using my Google Workspace domain).

It fails intermittently, for example first click on "Maintenance->Send test email" works fine, the next one a second later fails. The same for invite e-mail to new users. The error message is:
production.ERROR: Failed to send user invite with error: Expected response code "250" but got code "421", with message "421-4.7.0 Try again later, closing connection. (EHLO)

Steps to Reproduce

Configure SMTP relay in Google Workspace according to https://support.google.com/a/answer/2956491

Configure BookStack to use Gmail relay:
MAIL_DRIVER=smtp
MAIL_HOST=smtp-relay.gmail.com
MAIL_ENCRYPTION=tls
MAIL_FROM=foo@example.org

Try to create a new user and send them invitation e-mail

Observe it sometimes fail with red error pop-up and "production.ERROR: Failed to send user invite with error: Expected response code "250" but got code "421", with message "421-4.7.0 Try again later, closing connection. (EHLO)" in laravel.log

Expected Behaviour

The mail sending should succeed 100% of time

Screenshots or Additional Context

• Google Workspace supports a few methods to send e-mails via them, SMTP relay being the preferred one according to https://support.google.com/a/answer/176600
• 421-4.7.0 is not specific for Gmail, it's their catch-all error code for "may be spam/unauthorized, try later" as per https://support.google.com/a/answer/3726730
• I have found a few people with the similar problem, e.g. https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694 and https://serverfault.com/questions/929559/postfix-error-421-4-7-0-try-again-later-closing-connection-ehlo
• Apparently Google does not like when connecting mail server does not introduce himself properly in HELO/EHLO, but just uses "localhost" or "127.0.0.1"
• I confirmed that with telnet:

$ telnet smtp-relay.gmail.com 587
Trying 142.250.110.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP a640dd1662f3a-a38921cc907sm153220566b.83 - gsmtp
EHLO [127.0.0.1]
421-4.7.0 Try again later, closing connection. (EHLO)
421-4.7.0  For more information, go to
421 4.7.0  https://support.google.com/a/answer/3221692 a640dd1662f3a-a38921cc907sm153220566b.83 - gsmtp
Connection closed by foreign host.
$ 
$ telnet smtp-relay.gmail.com 587
Trying 142.250.110.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP 2810306940e0a-594af1f2ac4sm256491fe81.0 - gsmtp
EHLO foo.example.org
250-smtp-relay.gmail.com at your service, [111.234.56.123]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

• I confirmed with "tcpdump port 587 -s 0 -A" that indeed BookStack says EHLO [127.0.0.1] when talking to Google. Sometimes it works fine and email is sent, sometimes Google replies with error and sending fails.
• BookStack is served at foo.example.org, APP_URL is set to https://foo.example.org
• Editing getLocalDomain() in /var/www/bookstack/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php:132 from "return $this->domain;" to "return 'foo.example.org';" fixed all the problems so far.
• After a quick glance at SMTP RFC https://www.rfc-editor.org/rfc/rfc5321 it looks to me that while IP address may be allowed sometimes, using domain is always preferred if available. I guess most actual mail servers prefer that too. So I would appreciate BookStack using the domain from APP_URL while introducing itself to mail servers.

Browser Details

No response

Exact BookStack Version

25.12.1

[ssddanbrown]

Thanks @Remoddy,
I've recategorised this as an enhancement, just because it's not specifically something we've support before. I've also updated the title to be specific to setting the domain.

Should be easy to implement via our config files, setting the local_domain mail driver option:

BookStack/app/Config/mail.php

Line 42 in d13abc7

'local_domain' => null,

Have assigned to the next feature release, since this could potentially be a breaking change, and we'll need to check potential implications of suddenly sending a domain.

[ssddanbrown]

Thanks again @Remoddy, this has been added in ec3dd85, to be part of the next feature release.

I spent a little time researching the exact use of EHLO, and the implications of changing it.
From what I understand, this should have little chance of breaking existing environments. Looks like for a domain it's generally an externally resolvable domain that's desired, which many BookStack instances may not have, but that should not matter so much in this context since we're talking to SMTP relays, not other SMTP servers for actual sending, so hopefully a domain is better than a generic value.

That said, if this ends up causing a lot of unexpected trouble post release it may be something to revert (with a config option or theme system hack for those in environments which need a EHLO domain).