Automated cPanel emails marked as spam

Daniel15

Well-Known Member
Oct 7, 2006
86
1
156
Palo Alto, CA (originally Melbourne, Australia)
cPanel Access Level
Website Owner
Twitter
I don't mind posting it on the forum. I'd rather not use tickets as I license cPanel through the data centre, so I don't think I can even create a ticket directly.

Here's the full headers from an upcp email that was marked as spam by Gmail. I've obfuscated the email addresses a bit and removed the message IDs, but the rest of it is exactly as I got it.
Delivered-To: my email
Received: by 10.223.74.139 with SMTP id removed;
Sun, 6 Nov 2011 05:38:54 -0800 (PST)
Received: by 10.236.175.72 with SMTP id removed;
Sun, 06 Nov 2011 05:38:54 -0800 (PST)
Return-Path: <root at quimby.youareaninja.com>
Received: from quimby.youareaninja.com (quimby.youareaninja.com. [66.232.109.157])
by mx.google.com with ESMTPS id removed
(version=TLSv1/SSLv3 cipher=OTHER);
Sun, 06 Nov 2011 05:38:53 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of root at quimby.youareaninja.com designates 66.232.109.157 as permitted sender) client-ip=66.232.109.157;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of root at quimby.youareaninja.com designates 66.232.109.157 as permitted sender) smtp.mail=root at quimby.youareaninja.com
Received: from root by quimby.youareaninja.com with local (Exim 4.69)
(envelope-from <root at quimby.youareaninja.com>)
id removed
for root at quimby.youareaninja.com; Mon, 07 Nov 2011 00:38:52 +1100
From: root at quimby.youareaninja.com (Cron Daemon)
To: root at quimby.youareaninja.com
Subject: Cron <[email protected]> /usr/local/cpanel/scripts/upcp --cron
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <removed@quimby.youareaninja.com>
Date: Mon, 07 Nov 2011 00:37:06 +1100
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - quimby.youareaninja.com
X-AntiAbuse: Original Domain - quimby.youareaninja.com
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - quimby.youareaninja.com
One thing I noticed is that I have SPF records for the domain itself (youareaninja.com) but not for cPanel's hostname (quimby.youareaninja.com). Should I add these?
 
Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
Is the server's hostname a subdomain off a main domain that you have on the machine (as in does it exist in /var/named/maindomain.com.db file as a subdomain) or is it in a separate zone itself (as in /var/named/hostname.db file)? I ask as it depends on which it happens to be for how you might go about getting SPF and DomainKeys set up for that hostname.
 

SrvAdmin

Registered
Nov 9, 2011
2
0
51
cPanel Access Level
Root Administrator
quimby.youareaninja.com is pointed to the IP 66.232.109.157 and the PTR/RDNS record of the IP is emptly. You need to contact your datacentre techs and ask them to set the PTR/RDNS record to quimby.youareaninja.com. It should solve the problem.
 

Daniel15

Well-Known Member
Oct 7, 2006
86
1
156
Palo Alto, CA (originally Melbourne, Australia)
cPanel Access Level
Website Owner
Twitter
quimby.youareaninja.com is pointed to the IP 66.232.109.157 and the PTR/RDNS record of the IP is emptly. You need to contact your datacentre techs and ask them to set the PTR/RDNS record to quimby.youareaninja.com. It should solve the problem.
Huh, that is interesting. It definitely used to be set, but something must have changed recently. Some of my IPs (eg. 66.232.109.159) have the reverse DNS set, but the main IP does not. I'll contact them and get them to fix it.

Even so, this issue has been occuring for quite a while now, even back when the reverse DNS was set correctly.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
I would suggest moving the hostname's separate zone file into the main domain file instead so it isn't a separate zone, then setting the SPF records for it in that file instead. It is typically preferred to have the hostname off the main domain in the same DNS zone file as the main domain over a separate zone file.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
When you enable Domain Keys in cPanel > Email Authentication area if the subdomain is on the account itself, it will do the following for the subdomain entries:

Code:
[email protected] [/var/cpanel/domain_keys/public]# ls -lah
total 16K
drwxr-xr-x 2 root wheel 4.0K Nov 17 08:08 ./
drwxr-xr-x 4 root wheel 4.0K Nov 17 08:06 ../
-rw-r--r-- 1 root wheel  223 Nov 17 08:06 bubba.test
-rw-r--r-- 1 root wheel  223 Nov 17 08:08 cptest.bubba.test

[email protected] [/var/cpanel/domain_keys/private]# ls -lah
total 16K
drwxr-x--- 2 root mail  4.0K Nov 17 08:08 ./
drwxr-xr-x 4 root wheel 4.0K Nov 17 08:06 ../
-rw-r--r-- 1 root wheel  692 Nov 17 08:06 bubba.test
-rw-r--r-- 1 root wheel  692 Nov 17 08:08 cptest.bubba.test
It also creates the record in the zone file (/var/named/bubba.test.db):

default._domainkey IN TXT "k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhANiSu9I14umLRpianE3TVnUkUNEOxcDUzn6JYpOCUWl9rbvX5WXO+iZT26gk6ilHj9V7dtDXFha+6jjaxShrmWEF8kS/lcMfP25yRUECHjB8APXH8YwdmiaoPVBlNzk4qwIDAQAB;"
default._domainkey.cptest IN TXT "k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhANm360BD0NHjI1fTGu8ZNqPGIGbBpJ8DrJre4dXc/QuXSkYNZJLHMig6NQ7HT6spM0M2/qYEzcpkKLKjBgobYO7QUPyfMT4BhrjB4SoUHMbv6BcSwSphUyWZyl02rMrnGQIDAQAB;"
With the hostname, it does treat it differently, since it isn't a subdomain on an account. I tested with the hostname and because it wasn't in cPanel > Subdomain, it did not create those entries.

For normal subdomains, it definitely isn't an issue for subdomains themselves to be covered if you test it, since my results show the subdomains do get it created.

As such, if you want the hostname covered, your best bet is to temporarily change the hostname to another name, put the hostname onto the account as a subdomain, use Email Authentication area to add the SPF and domain keys records, then remove the subdomain manually and change the hostname back to what it was before. It does appear to be a lot of steps simply to get the records added. Right now, I simply can't think of a simpler way to do it.