System Emails Are Still Sent To Root
I am getting bounced, frozen emails in my mail queue when the system attempts to send email to root@host.mydomain.com (where host.mydomain.com is the hostname of my server). These emails appear to be from:
[LIST]
/var/cpanel/cwaf/scripts/updater.pl
/usr/local/cpanel/scripts/upcp
logwatch@host.mydomain.com
Here is the output of commands to check the configuration:
Here is the output for the hosts file and reverse DNS:
Note that this server was migrated to a new VPS with all the previous IP addreses retained, so the primary IP of the new VPS (64.91.xxx.xxx) doesn't match the reverse DNS (96.30.xxx.xxx, the old primary IP), though all our email seems to be working fine so far. I've looked everywhere I can think of to find why root is still getting system emails. What else could it be?
root@host [4012 13:24:56 ~]# cat /etc/localaliases
cpanel: validemail@gmail.com
nobody: validemail@gmail.com
root: validemail@gmail.com
root@host [4013 13:25:26 ~]# cat /var/cpanel/userhomes/cpanel/.forward
validemail@gmail.com
root@host [4014 14:14:58 ~]# cat /root/.forward
validemail@gmail.com
root@host [4015 14:15:11 ~]# grep validemail@gmail.com /etc/valiases/*
root@host [4016 14:15:45 ~]# grep validemail@gmail.com /etc/vfilters/*
root@host [4017 14:16:11 ~]#
Here is the output for the hosts file and reverse DNS:
root@host [4018 14:18:02 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.122.229 centos6.template.mywebhost.com centos6 Bcast
64.91.xxx.xxx host.mydomain.com host
root@host [4019 14:18:04 ~]# cat /etc/mail_reverse_dns
96.30.xxx.xxx: host.mydomain.com
Note that this server was migrated to a new VPS with all the previous IP addreses retained, so the primary IP of the new VPS (64.91.xxx.xxx) doesn't match the reverse DNS (96.30.xxx.xxx, the old primary IP), though all our email seems to be working fine so far. I've looked everywhere I can think of to find why root is still getting system emails. What else could it be?
-
I thought that WHM's settings would override what's in /etc/crontab, but I looked just to see what the MAILTO was set to, and it is set to "root": MAILTO=root0 -
You should get some sort of clue here: WebHost Manager "Email "Mail Delivery Reports It may be that gmail is rate limiting or blocking the emails. 0 -
The emails are never making it to Gmail. This is what I see when I look at the bounces in the Mail Queue: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: root@host.mydomain.com The mail server could not deliver mail to root@host.mydomain.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries. ...
The messages are sent from the Cron Daemon to root@host.mydomain.com instead of using the email addresses I have set, unless I need to set the MAILTO in /etc/crontab.0 -
Hello, It's normal to see the notifications sent via email to root@hostname initially. The messages are then forwarded to the email address configured for "root" in "WHM >> Edit System Mail Preferences". The mail server could not deliver mail to root@host.mydomain.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries.
Can you verify if the server's hostname is added to the /etc/localdomains file on this system? If not, add the server's hostname to this file and verify it doesn't exist in the /etc/remotedomains file. Then, check to see if the issue continues. Thank you.0 -
It's normal to see the notifications sent via email to root@hostname initially. The messages are then forwarded to the email address configured for "root" in "WHM >> Edit System Mail Preferences".
So it's normal to have the frozen messages sent to root by the cron daemon in the Mail Queue, even with a valid email for root in WHM >> Edit System Mail Preferences as I do? It seems like I could prevent this by setting the MAILTO in crontab to an email address instead of "root"? The server's hostname is not in /etc/localdomains or in /etc/remotedomains. I have added it to /etc/localdomains, and I'll see what happens tonight when the crons run.0 -
So it's normal to have the frozen messages sent to root by the cron daemon in the Mail Queue, even with a valid email for root in WHM >> Edit System Mail Preferences as I do? It seems like I could prevent this by setting the MAILTO in crontab to an email address instead of "root"?
It's not normal for the initial delivery attempt to fail, but it is normal for the system to make the initital delivery attempt to the root@hostname address. The email addresses configured in "Edit System Mail Preferences" are used to determine where the emails sent to root@hostname are forwarded, but don't actually change the use of root@hostname in locations such as cron jobs.The server's hostname is not in /etc/localdomains or in /etc/remotedomains. I have added it to /etc/localdomains, and I'll see what happens tonight when the crons run.
This should address the issue you are facing. Let us know if you encounter any further problems. Thanks!0 -
Thanks! I'll let you know tomorrow after the next round of cron jobs runs. 0 -
It looks like I won't have to wait until tomorrow to tell you that adding my hostname to /etc/localdomains has worked. I just got an email to the Gmail address set in WHM >> Edit System Mail Preferences that is addressed to root@hostname. I'm glad I'm getting the system emails now, but I think I opened a new can of worms. : ) The subject of the email is: Cron cd /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/scripts/ ; /usr/local/cpanel/3rdparty/bin/php cron.php > /dev/null 2>&1
and the body of the email is:/bin/sh: line 0: cd: /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/scripts/: No such file or directory
It looks like I need to comment out the cron for the fantastico script.0 -
It looks like I need to comment out the cron for the fantastico script.
Hello, You'd need to remove that cron job if you no longer use that application, or reach out to their support team to determine the updated cron job to use. Thank you.0 -
I don't use Fantastico, and as far as I can see, it's not even installed, so I just removed that cron job. Thanks for the help. I think it's safe to mark this one "solved". 0
Please sign in to leave a comment.
Comments
10 comments