Started getting SMTP errors from Gmail relay

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
1

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 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 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 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 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?

2

Update: I created a service account and changed to using 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 will still accept EHLO [127.0.0.1], whereas 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.

3

Bug report on GitHub: Google Smtp-Relay Error (EHLO) ¡ Issue #25716 ¡ nextcloud/server ¡ GitHub

I’ve added some technical details over there. Please let me know a reasonable value instead of 127.0.0.1.

4

@kesselb It should have the sending domain there instead of a loopback address, e.g.

EHLO mydomain.com

5

You think it’s okay to use mail_domain as for ehlo?

6

@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.

7

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 or outlook.com as mail domain. If we use mail_domain for the ehlo command we send ehlo 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.

(quoted from 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().

8

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).