Google Smtp-Relay Error when installed on a subdomain (EHLO)
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Details of the issue
This issue is basically a duplicate of #25716 but with a twist: if the Nextcloud install is on a subdomain. I think the implementation of the initial fix in #27306 is incorrect, when you have Nextcloud installed on a subdomain. For example, I have it installed on cloud.mydomain.tld, and the overwrite.cli.url config is set to https://cloud.mydomain.tld, so the domain that will be set in the EHLO header will be cloud.mydomain.com.
Problem is, the Gmail SMTP relay expects the domain in the EHLO header to be mydomain.tld.
The value set in the EHLO command should be the top domain, or a new config (like maildomain for example) should be added to be able to customize the value and not have to rely on an automatically generated one, that could be incorrect.
Steps to reproduce
- Install Nextcloud on a subdomain (ex: cloud.domain.tld)
- Use Google Smtp-Relay (smtp-relay.gmail.com) Service to deliver mails.
Expected behaviour
Mails are delivered.
Actual behaviour
Mails are refused by the Google SMTP relay.
Server configuration
Nextcloud version: 22.1.1
Where did you install Nextcloud from: Official Docker Image
Any idea?
It seems that Gmail now supports subdomains in EHLO|HELO commands, or at least it seems to work for me.
However, I agree that relying on overwrite.cli.url as implemented in #27306 is not a correct fix. According to docs that setting is meant for overriding the domain in any links that NextCloud generates and is for use in situations where NextCloud is behind a proxy and can't figure out its external domain on its own.
Seems to me the mailer configuration doesn't necessarily need to be related to the proxy/external domain configuration.
In my case I didn't need to set overwrite.cli.url as I'm not running behind a proxy. In the docs there's no mention of which setting can be used to override the mailer domain. IMO mail_domain would be a logical choice here.
How about using overwrite.cli.url if set, otherwise falling back to mail_domain? This isn't ideal, but wouldn't break existing configurations.
You can also add the domain of your Nextcloud as a domain within Google Workspace. You'll have to verify it with the TXT records Google requires, but you don't have to assign all users to have aliases in it or anything.
Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
This seems to be working for me now, on 25.0.2. I don't know whether it was a NextCloud change or a Google change, but it's working.
Thanks for verifying!