After upgrade to v11 WHM doesn't send e-mails on update...

[dyelton]

With v10 I automatically got an e-mail when cPanel ran nightly updates for the RELEASE tree but after v11 installed I no longer receive an e-mail when cPanel runs nightly updates. I have checked to make sure e-mails are entered correctly for notification.

[cpanelnick]

With v10 I automatically got an e-mail when cPanel ran nightly updates for the RELEASE tree but after v11 installed I no longer receive an e-mail when cPanel runs nightly updates. I have checked to make sure e-mails are entered correctly for notification.

Check the contact manager, you may need to adjust some settings.

[jayh38]

I also had this problem. My fix was a box reboot. Give it a whirl also.

[dyelton]

I also had this problem. My fix was a box reboot. Give it a whirl also.

I already did that option as I did a kernel upgrade after the v10 -> v11 upgrade took place and of course rebooted the machine for that purpose. I have changed the e-mails to go to another account to see if that may be the problem but I will report back tomorrow if the problem still exists.

[dyelton]

I switched e-mail addresses to one outside of the server and I now receive the cpanel update e-mail. I will assume that spamassassin 3.2 was causing the issue and deleting the e-mail. I wonder if 3.1.8 will cause the same issue?

[chirpy]

One thing to check is the ACL section in the exim configuration editor and make sure that the section for:

require verify = recipient

comes before the section for:

require verify = sender

This appears to screw up sometimes on upgrading to v11 now that cPanel use the require statement. A clean exim.conf.local does put these the right way round, but an upgraded server can be incorrectly done, or missing the require statements that preceded the verify:
http://www.configserver.com/blog/index.php?itemid=207

[dyelton]

I checked the exim.conf and require verify = recipient comes BEFORE require verify = sender so that doesn't seem to be it.

[chirpy]

On trick might be to use MAILTO in the root crontab:

crontab -e

at the top put:

MAILTO:you@yourdomain.com

Then exit. If that doesn't work, check /var/log/exim_mainlog when a root job from the crontab runs for errors. One trick is to put:

* * * * * date

as a job which will send a date+time email every minute while you're testing (don't forget to remove it)

[dyelton]

I get all e-mails from the system's cron with the exception of the cpanel update log. I have whitelisted my server in the spam filter for the receiving e-mail account so hopefully that will bypass the problem. Thanks for the assistance.

[mtindor]

Jonathan,

In my case I have a 'require verify = sender' and it comes first. And the recipient line does not contain 'require' - it is simply: verify = recipient.

  require verify = sender
  accept  domains = +local_domains
  endpass
                                                                                                                                   $
  #recipient verifications are required for all messages that are not sent to the local machine
  #this was done at multiple users requests

  verify = recipient

In my case, what should I do?

- Mike

One thing to check is the ACL section in the exim configuration editor and make sure that the section for:

require verify = recipient

comes before the section for:

require verify = sender

This appears to screw up sometimes on upgrading to v11 now that cPanel use the require statement. A clean exim.conf.local does put these the right way round, but an upgraded server can be incorrectly done, or missing the require statements that preceded the verify:
http://www.configserver.com/blog/index.php?itemid=207

[chirpy]

You should leave it as-is (or reset the exim configuration to defaults if you want to). That issue seems only relevant when the both verifications are prefixed with require.

[dyelton]

It looks like the problem is back. I get all e-mails from the system except for the upcp e-mail. This is after I have explicitly white-listed anything from the server. Anything else I can check? This latest issue started happening when I upgraded spamassassin from 3.1.8 to 3.2.1 I believe.