# Started getting SMTP errors from Gmail relay **URL:** \ **Category:** 📦 Appliances (Docker, Snappy, VM, NCP, AIO)\ **Tags:** docker\ **Created:** [February 12, 2021, 6:16pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694 "2021-02-12T18:16:42Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![KarlF12](https://help.nextcloud.com/user_avatar/help.nextcloud.com/karlf12/32/46873_2.png) [@KarlF12](https://help.nextcloud.com/u/KarlF12)\ **Post date:** [February 12, 2021, 6:16pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/1 "2021-02-12T18:16:42Z")
Good morning, I have some Nextcloud Docker installations that are configured to use the Gmail SMTP relay service that have been working fine up until recently. Suddenly they have started having problems sending email. They report the following error when sending a test email (which does not appear to be correct): > A problem occurred while sending the email. Please revise your settings. (Error: Expected response code 250 but got an empty response) Running a packet capture to see what’s really going on, this is what I see: > SMTP 125 S: 220 [smtp-relay.gmail.com](http://smtp-relay.gmail.com) ESMTP x13sm1833773pjh.14 - gsmtp > SMTP 84 C: EHLO [127.0.0.1] > SMTP 148 S: 421 4.7.0 Try again later, closing connection. (EHLO) x13sm1833773pjh.14 - gsmtp As you can see, there are explicit error codes 421 and 4.7.0 which is indeed _not_ an empty response. [Google’s SMTP error reference](https://support.google.com/a/answer/3726730?hl=en&ref_topic=1355150) says: > 421, “4.7.0”, Try again later, closing connection. This usually indicates a Denial of Service (DoS) for the SMTP relay at the HELO stage. What I’ve found is that **if I use telnet to send an email from the server, it works fine** , so I know the Gmail relay service configuration is correct. However I can also reproduce the above by sending HELO [127.0.0.1] and will receive the same error. So I don’t think the relay has blocked the servers or anything like that as their error code reference suggests. So evidently either they have stopped accepting EHLO [127.0.01], or Nextcloud was previously identifying itself differently and has changed. I’m leaning toward the former but I don’t actually know what changed. What _should_ happen is Nextcloud should identify itself with the domain name it’s configured to send from (`example.com`), not `[127.0.0.1]`. But, I don’t know how to change this. I looked through [the email configuration docs](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/email_configuration.html) and compared against my config.php and everything appears to be set correctly. ``` 'mail_smtpmode' => 'smtp', 'mail_sendmailmode' => 'smtp', 'mail_from_address' => 'nextcloud', 'mail_domain' => 'example.com', 'mail_smtphost' => 'smtp-relay.gmail.com', 'mail_smtpport' => '587', 'mail_smtpsecure' => 'tls', ``` The [Nextcloud documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/email_configuration.html#tls) mentions the ability to set advanced mail options using Swift Mailer’s streamOptions, however the site it links to does not actually have any documentation about a streamOptions parameter that I could find, and a web search of the topic didn’t return anything useful. Anyone know a solution to this? ---
**Author:** ![KarlF12](https://help.nextcloud.com/user_avatar/help.nextcloud.com/karlf12/32/46873_2.png) [@KarlF12](https://help.nextcloud.com/u/KarlF12)\ **Post date:** [February 12, 2021, 9:18pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/2 "2021-02-12T21:18:14Z")
Update: I created a service account and changed to using [smtp.gmail.com](http://smtp.gmail.com) with authentication, and now it works. So Google has evidently changed something and broke their SMTP relay service. I ran a capture on this, and [smtp.gmail.com](http://smtp.gmail.com) will still accept EHLO [127.0.0.1], whereas [smtp-relay.gmail.com](http://smtp-relay.gmail.com) no longer does. I would still like to know how to change the EHLO origin on Nextcloud if anyone knows a way to do it. ---
**Author:** ![kesselb](https://help.nextcloud.com/user_avatar/help.nextcloud.com/kesselb/32/74519_2.png) [@kesselb](https://help.nextcloud.com/u/kesselb)\ **Post date:** [February 26, 2021, 9:39pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/3 "2021-02-26T21:39:44Z")
Bug report on GitHub: [Google Smtp-Relay Error (EHLO) · Issue #25716 · nextcloud/server · GitHub](https://github.com/nextcloud/server/issues/25716) I’ve added some technical details over there. Please let me know a reasonable value instead of 127.0.0.1. ---
**Author:** ![KarlF12](https://help.nextcloud.com/user_avatar/help.nextcloud.com/karlf12/32/46873_2.png) [@KarlF12](https://help.nextcloud.com/u/KarlF12)\ **Post date:** [February 26, 2021, 11:29pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/4 "2021-02-26T23:29:39Z")
@kesselb It should have the sending domain there instead of a loopback address, e.g. EHLO [mydomain.com](http://mydomain.com) ---
**Author:** ![kesselb](https://help.nextcloud.com/user_avatar/help.nextcloud.com/kesselb/32/74519_2.png) [@kesselb](https://help.nextcloud.com/u/kesselb)\ **Post date:** [February 27, 2021, 8:34pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/5 "2021-02-27T20:34:01Z")
> You think it’s okay to use mail\_domain as for ehlo? ---
**Author:** ![KarlF12](https://help.nextcloud.com/user_avatar/help.nextcloud.com/karlf12/32/46873_2.png) [@KarlF12](https://help.nextcloud.com/u/KarlF12)\ **Post date:** [February 28, 2021, 12:08am UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/6 "2021-02-28T00:08:27Z")
@kesselb I had assumed that was already the expected behavior. According to RFC2821: > Extended HELLO (EHLO) or HELLO (HELO) > > These commands are used to identify the SMTP client to the SMTP > server. The argument field contains the fully-qualified domain name > of the SMTP client if one is available. ---
**Author:** ![kesselb](https://help.nextcloud.com/user_avatar/help.nextcloud.com/kesselb/32/74519_2.png) [@kesselb](https://help.nextcloud.com/u/kesselb)\ **Post date:** [February 28, 2021, 9:31pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/7 "2021-02-28T21:31:02Z")
`mail_domain` is not used for the ehlo command. Nextcloud do not set a specific value for the ehlo command. The default by Swift Mailer is 127.0.0.1. I know from some bug reports at GitHub that people use [gmail.com](http://gmail.com) or [outlook.com](http://outlook.com) as mail domain. If we use mail\_domain for the ehlo command we send ehlo [gmail.com](http://gmail.com) for such cases. I don’t know if that works well. > The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in [section 4.1.1.1](https://tools.ietf.org/html/rfc2821#section-4.1.1.1). (quoted from [https://tools.ietf.org/html/rfc2821#section-3.6](https://tools.ietf.org/html/rfc2821#section-3.6)). We may need another configuration option to configure this value. My hope was to use something we already have like mail\_domain or gethostname(). ---
**Author:** ![KarlF12](https://help.nextcloud.com/user_avatar/help.nextcloud.com/karlf12/32/46873_2.png) [@KarlF12](https://help.nextcloud.com/u/KarlF12)\ **Post date:** [February 28, 2021, 11:23pm UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/8 "2021-02-28T23:23:58Z")
> [@kesselb](#): > > I know from some bug reports at GitHub that people use [gmail.com](http://gmail.com) or [outlook.com](http://outlook.com) as mail domain. If we use mail\_domain for the ehlo command we send ehlo [gmail.com](http://gmail.com) for such cases. I don’t know if that works well. That would be a misconfiguration (unless you are sending from a @gmail.com address). EHLO is supposed to be sent with the originating mail domain of the _client_. Except for special circumstances, this would be the same as the mail\_domain set in Nextcloud’s mail options. Isn’t the whole point of the mail\_domain to indicate Nextcloud‘s sending domain? That’s exactly what should be presented with EHLO. By my reading of the RFC, it should _not_ be sending a loopback address under any normal circumstances, so the swift mailer should not be doing this anyway (except, I assume, in the total absense of a known domain or public IP, but we have already indicated the sending domain in Nextcloud). ---
**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\ **Post date:** [December 13, 2024, 6:46am UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/9 "2024-12-13T06:46:29Z")
---
**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\ **Post date:** [December 13, 2024, 6:46am UTC](https://help.nextcloud.com/t/started-getting-smtp-errors-from-gmail-relay/107694/10 "2024-12-13T06:46:30Z")