In an effort to prove to myself that I am actually trying to do work
this last month, I’m making a note of all the bugs in 3rd party software I find.
Today is a bug reported to cPanel Inc on the 6th June 2022 under their tracking request ID 94453274 affecting outbound emails sent from servers running their WHM/cPanel software to web hosting customers whose account has an notification.
Initial Bug Report
We’ve got a customer who is migrating (back) to us slowly and hence they currently have their hosting and MX records held at a different provider. Their DNS records have a hard fail SPF setting.
With their new account, cPanel tried to send a notification about a bad SSL certificate: however, the email said it was From: cpanel@ and their notification email address (as setup within cPanel/WHM) is a gmail one. Gmail then rejected the email due to SPF failure.
Outbound emails from the server to customers should either come From: the server hostname or from a server administrator defined one to prevent SPF failures.
Customer domain: example.com
Account email address: email@example.com
The SPF records for example.com:
v=spf1 include:_spf.google.com -all
Our server name: servername.example.net
Fails the DNS SPF test as our IP is not listed in their SPF records: https://www.spf-record.com/spf-lookup/example.com?ip=198.51.100.1&opt_out=on
Example outbound email that failed delivery
Return-path: firstname.lastname@example.org Received: from [127.0.0.1] (port=55864 helo=localhost.localdomain) by servername.example.net with esmtpa (Exim 4.95) (envelope-from email@example.com) id 1nxy4N-0005fZ-6S for firstname.lastname@example.org; Sun, 05 Jun 2022 21:46:00 +0000 Date: Sun, 05 Jun 2022 21:45:59 GMT From: "cPanel on example.com" email@example.com Message-Id: 1654465559.qesod4r5uaMqQrRy@servername.example.net Reply-To: "cPanel on example.com" firstname.lastname@example.org Subject: [example.com.com] ? example.com: SSL certificate expiry on 1/5/20 UTC To: email@example.com X-iContact_locale: en Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="alternative-Cpanel::Email::Object-21794-1654465559-0.567457139056376"
Hope this makes sense!
Around an hour later, I followed it up with further findings:
Oh even better – since they haven’t got a cpanel@ email address configured at Gmail (which hosts their example.com email account) the mail notification of failure to deliver the original email also fails to be delivered(!)
Slightly different issue, but the resolution (as fair as I can tell) is the same: Outbound emails from the server to customers should either come From: the server hostname or from a server administrator defined one to prevent SPF failures.
cwd=/usr/local/cpanel/whostmgr/docroot 4 args: /usr/sbin/exim -v -M 1nxy4O-0005fw-JL
Unfrozen by forced delivery
Sender identification U=mailnull D=-system- S=mailnull
Connecting to ASPMX.L.GOOGLE.com [220.127.116.11]:25 … connected
SMTP<< 220 mx.google.com ESMTP i8-20020a50fd08000000b0041e0cd418dasi7483773eds.115 - gsmtp SMTP>> EHLO servername.example.net
SMTP<< 250-mx.google.com at your service, [198.51.100.1] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 SMTP>> STARTTLS
SMTP<< 220 2.0.0 Ready to start TLS SMTP>> EHLO servername.example.net
SMTP<< 250-mx.google.com at your service, [198.51.100.1] 250-SIZE 157286400 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 SMTP|> MAIL FROM:<> SIZE=43659
SMTP|> RCPT TO:firstname.lastname@example.org
SMTP<< 250 2.1.0 OK i8-20020a50fd08000000b0041e0cd418dasi7483773eds.115 - gsmtp SMTP<< 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser i8-20020a50fd08000000b0041e0cd418dasi7483773eds.115 - gsmtp SMTP<< 503 5.5.1 RCPT first. i8-20020a50fd08000000b0041e0cd418dasi7483773eds.115 - gsmtp SMTP+> QUIT
** email@example.com R=dkim_lookuphost T=dkim_remote_smtp H=ASPMX.L.GOOGLE.com [18.104.22.168] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after RCPT TO:firstname.lastname@example.org: 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. Learn more at\n550 5.1.1 https://support.google.com/mail/?p=NoSuchUser i8-20020a50fd08000000b0041e0cd418dasi7483773eds.115 - gsmtp
Frozen (delivery error message)
A day later, a cPanel representative did reply:
Currently, there is no method to change the sending address of the cPanel notifications.
However, it should be coming from the hostname. If you want to vote for the ability to customize the sending address, please vote for the feature request in the following article.
The knowledgebase article they linked to had just been created and read(s):
Customize the sender of cPanel notification emails
Is there a method to customize the sending email address of notifications sent to cPanel users.
Not at this time. We do encourage you to vote on the existing feature request to implement the ability to customize the sender. The feature request can be found below:
With the subsequent “Feature Request” item dating back 6 years ago.
They asked for server access so they could investigate further.
After server investigation
2 days later (the delay was mainly on my end), the technician replied again:
It looks like I was mistaken earlier. The root notifications come from the hostname. The cPanel notifications come from the domain.
Since you are unable to change the sending address for the notifications you will want to ensure that your cPanel server IP is added to the domains SPF record. Since the domain has DNS managed by a 3rd party you would need to update the TXT record there.
# whois example.com | grep "Name Server"
Name Server: NS1.EXAMPLE.ORG
Name Server: NS2.EXAMPLE.ORG
Name Server: NS3.EXAMPLE.ORG
Name Server: NS4.EXAMPLE.ORG
"v=spf1 include:_spf.google.com -all"
Obviously that didn’t provide me with any useful information that I didn’t already know – in fact, I replied:
Thanks – you’ve confirmed my suspicions (I wasn’t sure if I had a legacy setting which had the cpanel@<account domain> enabled). .
I’ll have to get the customer to get moving in updating things and just endure the bouncebacks until then.
So I think this is a WONTFIX situation 🙁