OK, so after much testing, I had 3 main things that I had to take care of for emails to send through smtp-relay.gmail.com:
- Fix the syntax in the command line in the Laravel Supervisor configuration file (
laravel-worker.conf) from the Laravel docs example and remove thesqsargument afterqueue:work. For some reason, that argument was causing my workers to crash and not recover until a manual restart, thus failing to send my scheduled emails. My command line went from:
command=php /path/to/project/artisan queue:work sqs --sleep=3 --tries=3 --max-time=3600
to:
command=php /path/to/project/artisan queue:work --sleep=3 --tries=3 --max-time=3600
Here is the Supervisor guide:
And
Here is my whole working configuration file for reference:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/project/artisan queue:work --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=user
numprocs=4
redirect_stderr=true
stdout_logfile=/path/to/project/laravel_worker.log
stopwaitsecs=3600
- Starting recently, Gmail SMTP Relay requires a proper EHLO hostname domain to be sent during the SMTP handshake: [127.0.0.1] doesn’t cut it anymore. For that, Laravel has to check for a host domain variable and send it along with the handshake request.
Since the mail.php was updated recently in Invoice Ninja with the following line:
'local_domain' => env('MAIL_EHLO_DOMAIN'), ,
it doesn’t need to be manually edited anymore to fix the failed EHLO requirement. All is now needed is a new line in the .env file: MAIL_EHLO_DOMAIN="server.domain.com". Without this, IN will report an error from Gmail that looks like this:
This is what the mail section looks like in my .env:
MAIL_MAILER="smtp"
MAIL_HOST="smtp-relay.gmail.com"
MAIL_PORT="587"
MAIL_USERNAME="[email protected]"
MAIL_PASSWORD="password"
MAIL_ENCRYPTION="tls"
MAIL_FROM_ADDRESS="[email protected]"
MAIL_FROM_NAME="Invoice Ninja"
MAIL_EHLO_DOMAIN="server.domain.com"
- Last but not least, Invoice Ninja must be able to communicate with the Gmail servers, and that is not a given. If the connection attempt fails because Invoice Ninja cannot reach Gmail, it gives an error like this one:
To make sure that doesn’t happen, for starters, IN should be able to bypass the default mail server and connect directly to SMTP to reduce the complexity of the mailing pipeline and avoid possible errors.
On my system running WHM, I have ConfigServer Security & Firewall (CSF) Installed and it has a specific feature for this under the Fix Common Problems button called SMTP_BLOCK:
A very similar setting is also available directly in WHM through Home > Security > SMTP Restrictions that prevents users from connecting to SMTP without going through the mail server:
It should be disabled.
Now, Gmail servers can still be blocked by the firewall. I could not find a list of all of the IPs used by smtp-relay.gmail.com anywhere, so I ran a bunch of manual DNS checks on several DNS checking websites, and depending on the authoritative DNS servers they were connecting to, I got different IPs, but after a few runs I exhausted all possibilities that exist at the moment (or so it seems). Here are all of the North American (USA & Canada) IPs I gathered:
142.251.163.28
172.253.63.28
172.253.118.28
74.125.24.28
142.250.114.28
142.250.4.28
142.251.12.28
172.217.194.28
142.250.31.28
142.251.167.28
172.253.115.28
I added those as allowed IPs in my firewall config.
The IPs can still change eventually, so I also configured the lfd Dynamic DNS setting in CSF (which edits /etc/csf/csf.dyndns):
There, I added smtp-relay.gmail.com and also smtp.gmail.com for good measure.
For those on a more bare bones system, I think running the following script in a cron job should work to update the iptables with the Google SMTP Relay current IP that the server is trying to connect to (I haven’t tested it, though). The script is supposed to be flexible and allow multiple IPs to be added all at once in the DNS checkup results in several IPs:
#!env /bin/bash
ip=`dig +short smtp-relay.gmail.com`
for n in $ip
do
ipset add allowed $n
done
And finally, Gmail has to be able to accept incoming SMTP connection requests. For Google Workspace users, this is easy to setup in the Google Admin Console:
Step 1: Set up SMTP relay in your Google Admin console
- Sign in to your Google Admin console.
Sign in using an administrator account.
- In the Admin console, go to Menu
Apps
Google Workspace
You can add, edit, and delete the SMTP relay service setting at the top-level organization only. You can view the setting at the child organizational unit level.
3. Scroll to SMTP relay service and click Configure. If the setting is already configured, click Edit or Add another.
4. Enter a name for the setting and set up the following options:
Setting options What to do Allowed senders Choose an option:
Only registered Apps users in my domains—Sender must be a Google Workspace user in one of your domains.
Only addresses in my domains—Sender doesn’t have to be a Google Workspace user, but must be a user in one of your registered domains. This option is useful when you use third-party or custom applications to send messages.
Any addresses (not recommended)—Sender address can be any email address, including addresses outside of your domain. This option makes you more vulnerable to abuse, either by malicious software on your users’ devices or by incorrect SMTP settings.If you use the any address option and send messages from a domain that you don’t own or with an empty envelope-from (for example, bounce messages or out-of-office notifications), set up your mail server to use SMTP AUTH to identify the sending domain or to present one of your domain names in the HELO or EHLO command.If the sender is not in one of your domains, the system changes the envelope sender from user@domain_you_don’t_own to postmaster@your_domain, where your_domain is the domain the system receives from SMTP AUTH or from the HELO or EHLO command.|
|Authentication|Check one or both boxes to set an authentication method:Only accept mail from the specified IP addresses—System accepts only messages sent from IP addresses that you specify.
Require SMTP Authentication—Enforces SMTP authentication to identify the sending domain (connection through TLS required). SMTP authentication verifies the connection by checking the user Google Workspace email address and password.
If you select the specified IP addresses option:
- Click Add.
- Enter a description and the IP address or range in IPv4 or IPv6 format.
Use your own public IP address. You can specify up to 65,536 IP addresses in one range. For security reasons, we recommend that you keep the IP range as small as possible.- Check or uncheck the Enable box to enable or disable the IP address or range.
- Click Save.
- To add more IP addresses or ranges, repeat the steps.|
|Encryption|(Optional) To require TLS for connections between your server and Google, check the Require TLS encryption box.5.Important:* If your email server doesn’t support TLS and you check this box, messages not sent over an encrypted TLS connection are rejected.|
- Click Save.
Changes can take up to 24 hours but typically happen more quickly. Learn more
Source: Route outgoing SMTP relay messages through Google - Google Workspace Admin Help
My recommended settings here are:
- Only addresses in my domains
- Only accept mail from the specified IP addresses > server IP
Require SMTP Authentication > for that I use an app password instead of using the main Google Workspace account password. More info here: Sign in with app passwords - Google Account Help - Require TLS encryption
Source: Route outgoing SMTP relay messages through Google - Google Workspace Admin Help
Then, of course, we have to make sure that all records (MX, DKIM, SPF, DMARC) are properly setup at the DNS host and that the Reverse PTR record is properly pointing to the server IP.
That’s it! Emails should now be properly routed through the Gmail SMTP Relay servers 