* Describe the bug
Using Google’s SMTP relay results in intermittent email errors. It seems to be related to this Nodemailer bug report.
It’s worth noting that I’m using Google’s SMTP relay in a few other apps (unrelated) and I’m not having problems. Just to say that I understand how to create a separate password (in Google Account 2-Factor Auth section, etc.) so I don’t think the problem is fundamentally with my settings.
* Environment
- NocoBase version: 1.7.15; since at least 1.5 or so
- Database type and version: MariaDB
- OS: Docker within Windows 11
- Deployment Methods: docker compose
* How To Reproduce
As you can see, I’m using SMTP relay with port 587 and “secure” set to false. When the emails are rejected, I’m getting the following message:
{
“code”: “ECONNECTION”,
“response”: “421-4.7.0 Try again later, closing connection. (EHLO)\n421-4.7.0 For more information, go to\n421 4.7.0 About SMTP error messages - Google Workspace Admin Help 3f1490d57ef6-e7f7352f44csm831688276.30 - gsmtp”,
“responseCode”: 421,
“command”: "EHLO"Blockquote
}
Screenshots
Breakdown of the Error Message
"code": "ECONNECTION": This is an error code from the Nodemailer library itself, indicating that the underlying TCP connection failed. In this context, it failed because the remote server deliberately closed it."responseCode": 421: This is a standard SMTP (Simple Mail Transfer Protocol) status code. The 4xx series of codes indicates a temporary failure. The specific meaning of 421 is “Service not available, closing transmission channel.”"response": "421-4.7.0 Try again later, closing connection. (EHLO)": This is the human-readable message from the server.
Try again later: This explicitly tells you it’s a temporary issue and retrying later might succeed.closing connection: The server is actively terminating the session.(EHLO): This is the most critical piece of information! The error occurred during the EHLO command. EHLO is the very first step where the client “greets” or introduces itself to the server. Failing at this stage means the problem is not with the email content, recipient, or sender address, but with the connection behavior itself.
gsmtp: This confirms that you are connected to a Google SMTP server.
The Core Issue
The core problem is that your server/application made too many or too frequent connection requests to the Google SMTP server in a short period, triggering Google’s rate limiting and security policies.
Google’s servers monitor metrics like connection frequency and the number of concurrent connections from a single IP address. When they detect unusual patterns (e.g., a sudden burst of new connections, or connections that are immediately dropped), they temporarily “graylist” the IP and return a 421 error to protect their service from what looks like potential abuse.
Thanks for the helpful reply!
As you can see by the previous screenshot, however, it doesn’t seem possible that my
server/application made too many or too frequent connection requests to the Google SMTP server in a short period, triggering Google’s rate limiting and security policies.
Two things:
- My public IP from Spectrum hasn’t changed in 5 years, so at least I’m not hopping around (don’t know if their security policies care, just mentioning it)
- 12 emails over the course of a week doesn’t seem like that should cause any problem. Also my reason for including that forum post from Nodemailer is simply to bring attention to another person that had the exact same error message, and switching from Nodemailer to emailjs solved their problem. Not that I’m suggesting that has to be the only solution, but maybe that there is something about Nodemailer that could be causing the problem. I just cross-posted over at Nodemailer.
As an included data point here, I received an email from Google Support—after many back-and-forth tries—that rather typically blames ‘the other guy’, but it seems like there could be truth to this:
Upon checking your case with my internal team, they’ve informed me that the error you’re encountering isn’t related to Google. To resolve this, please contact your third-party application’s support to investigate the issue further.
We’ll see what happens over at the Nodemailer team…?
A Nodemailer forum member posted the following:
You might need to explicitly set the name property SMTP transport | Nodemailer - it needs to be a valid hostname (the hostname of the sending server). Nodemailer defaults to os.hostname() , but Docker has non-standard hostnames (usually just a bunch of hex chars), and some SMTP servers might not like it.
In a Docker instance of NocoBase, where would Nodemailer grab it’s hostname from, and how could I modify that to be more appealing to Google, if this is the case?
Based on the information you provided, could you try to set the hostname field to the service part of docker-compose.yml file? May like this:
services:
app:
image: nocobase/nocobase
hostname: <your-custom-hostname>
Because os.hostname() will try to get it, and we can not request Nodemailer to change this.
The highest of fives! 
When I changed my docker-compose.yml to include
app:
image: nocobase/nocobase:latest
# Without a correct/reputable hostname, some SMTP servers may intermittently reject outgoing emails
hostname: myhost.mycompany.com
All the problems went away.
I wonder if putting this information in the Notification: email page and/or including the comments in the default docker-compose.yml example files might be helpful to the next person?
(That’s above my pay grade 
)
Good idea! We will update our docs.
