Reverse DNS does not match SMTP Banner

UPDATE: WHM/cPanel removed support for in version 11.50, so changes below are not valid for versions 11.50+


If you make an SMTP test on you might be getting a following error shown in the test results “Reverse DNS does not match SMTP Banner”.

This error is showing because your SMTP greeting message is not matching the PTR records for the IP of the SMTP server used in test.

Following files need to be used and configured properly, for SMTP banner to match reverse DNS records.


Configure Exim to use mailhelo and mailips file

Go to WHM to Home »Service Configuration »Exim Configuration Manager and in Basic Editor on Domains and IPs tab set following settings:

Send mail from account’s dedicated IP address: OFF
Reference /etc/mailhelo for outgoing SMTP HELO: ON
Reference /etc/mailips for outgoing SMTP connections: ON

Configure necessary values in configuration files

Edit or create  /etc/mail_reverse_dns file and set the following in it for needed IPs.

x.x.x.x: rdns of the IP x.x.x.x
y.y.y.y: rdns of IP y.y.y.y

Edit or create /etc/mailhelo file and set following in it for the domains that you want to setup SMTP banner for. reverse dns of the IP used for domain
*: default SMTP HELO for unconfigured domains

Edit or create /etc/mailips file and set following in it: x.x.x.x #x.x.x.x is the IP used for outgoing mail for domain
*: y.y.y.y #y.y.y.y is the default IP that will be used for unconfigured domains

Configure exim.conf to use correct SMTP Banner

Following values need to be configured in exim.conf for SMTP Banner to be set to rDNS values set in /etc/mail_reverse_dns.


Be default only smtp_banner is set on cPanel servers, and it has a different value then needed.

[email protected] [~]# egrep "smtp_active_hostname|message_id_header_domain|smtp_banner" /etc/exim.conf
smtp_banner = "${primary_hostname} ESMTP Exim ${version_number} \

smtp_banner will probably look like this on your cPanel server.

"${primary_hostname} ESMTP Exim ${version_number}  \#${compile_number} ${tod_full} \n   We do not authorize the use of this system to transport unsolicited, \n   and/or bulk e-mail."
Configure values in exim.conf over shell

Locate the line smtp_banner and change its value so it looks like following:

smtp_banner = "${smtp_active_hostname} ESMTP Exim ${version_number} \"

Add smtp_active_hostname line value to exim.conf to look line following:

smtp_active_hostname = ${lookup{$interface_address}lsearch{/etc/mail_reverse_dns}{$value}{$primary_hostname}}

Add message_id_header_domain line to exim.conf to look like following:

message_id_header_domain = $smtp_active_hostname

In the end related values in exim.conf should look like this:

[email protected] [~]# egrep "smtp_active_hostname|message_id_header_domain|smtp_banner" /etc/exim.conf
smtp_banner = "${smtp_active_hostname} ESMTP Exim ${version_number} \"
smtp_active_hostname = ${lookup{$interface_address}lsearch{/etc/mail_reverse_dns}{$value}{$primary_hostname}}
message_id_header_domain = $smtp_active_hostname

Restart exim with /scripts/restartsrv_exim and SMTP tests should now pass without the SMTP banner warning.

Configure values in exim.conf over WHM

In your WHM go to Home »Service Configuration »Exim Configuration Manager and go to Advanced Editor.

Search for the smtp_banner field and change default value to:

"${smtp_active_hostname} ESMTP Exim ${version_number} \"


Edit smtp_banner in WHM
Edit smtp_banner in WHM

Find the “Add additional configuration setting” button and add two new configuration settings smtp_active_hostname and message_id_header_domain.

additional configuration settings
Add additional configuration setting in WHM

For smtp_active_hostname set the following value:


For message_id_header_domain set the following value:



How to Install ionCube Loader 5 on cPanel/WHM server

At this moment cPanel does not support ionCube Loader 5 on WHM/cPanel servers, which will cause issues for client running files made with ionCube v9.

cPanel currently installs ionCube PHP Loader v4.7.5, when you install PHP using cPanel EasyApache utility.

Your standard php -v output on cPanel server might look something like this.

[email protected] [~]# php -v
PHP 5.4.45 (cli) (built: Dec 14 2015 17:18:43)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd.

If you want to install, or upgrade current ionCube PHP Loader on your server to version 5, you can do so manually by downloading the latest version from, and editing your global or account custom php.ini file.

How to install ionCube Loader manually on cPanel or standard Linux servers with no control panel.

Download the latest loader to your server from

If you are running 32 bit server used the following command:


If you are running 64 bit server use the following command:


Unpack the package:

On 32 bit server:

tar xvzf ioncube_loaders_lin_x86.tar.gz

On 64 bit server:

tar xvzf ioncube_loaders_lin_x86-64.tar.gz

It will create ioncube folder in the same directory where you downloaded the file.

If you need to install ionCube Loader for PHP 5.4  you will use ioncube_loader_lin_5.4* files, and if you need to install it for PHP 5.5 you will use ioncube_loader_lin_5.5* files, and similar for other PHP versions.

[email protected] [~]# ls ioncube
./                   ***
../                  **  LICENSE.txt***     loader-wizard.php***  README.txt******  USER-GUIDE.txt***
[email protected] [~]#

To replace the ionCube Loader for all the users on the server, you can just replace the extension file defined in the global php.ini at /usr/local/lib/php.ini

[email protected] [~]# grep zend_extension /usr/local/lib/php.ini
[email protected] [~]#

You can rename the original file, for restore purposes, if something goes wrong, and place the new version file from ioncube folder that was created with package extraction.

mv /usr/local/IonCube/ /usr/local/IonCube/ioncube_loader_lin_5.4_ts.so_cporig
mv /usr/local/IonCube/ /usr/local/IonCube/ioncube_loader_lin_5.4.so_cporig
cp ioncube/ /usr/local/IonCube/
cp ioncube/ /usr/local/IonCube/

You can confirm the new version of ionCube Loader with php -v, and look for “ionCube PHP Loader” part of the output.

[email protected] [~]# php -v
PHP 5.4.45 (cli) (built: Dec 14 2015 17:18:43)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured) v5.0.19, Copyright (c) 2002-2015, by ionCube Ltd.
[email protected] [~]# php -v | grep "ionCube PHP Loader"
    with the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured) v5.0.19, Copyright (c) 2002-2015, by ionCube Ltd.
[email protected] [~]#

Upgrade to ionCube Loader 5 on one cPanel account.

If you wanted to change the ion Cube Loader version for only one cPanel account, you can place the ioncube_loader_lin* files for the PHP version used by your client to some custom folder, and define zend_extension values inside a custom php.ini folder on a specific cPanel account.


ionCube Loader can be installed manually on any Linux server with following steps:

  1. Download latest version of ionCube Loaders from
  2. Unpack the downloaded package
  3. move the ioncube_loader_lin_* files for your PHP version to your extension folder.
  4. Point to the corresponding file in your php.ini file, example


ConfigServer Internal Server Error 500, after cPanel update: fixed

This is a repost of a post from an old blog, made on June 29, 2013, that used to be on:

Original post:

After the WHM/cPanel update to 11.38 you might get the an error like this in your browser:

Internal Server Error
No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_csf.cgi): subprocess exited with status 2

And something like this in /usr/local/cpanel/logs/error_log:

BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/ line 15.
Compilation failed in require at /usr/local/cpanel/Cpanel/Template/Plugin/ line 12.
BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/Template/Plugin/ line 12.
Compilation failed in require at /usr/local/cpanel/Cpanel/ line 53.
BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/ line 53.
Compilation failed in require at /usr/local/cpanel/Whostmgr/ line 12.
BEGIN failed–compilation aborted at /usr/local/cpanel/Whostmgr/ line 12.
Compilation failed in require at /usr/local/cpanel/whostmgr/docroot/cgi/addon_cmc.cgi line 25.
BEGIN failed–compilation aborted at /usr/local/cpanel/whostmgr/docroot/cgi/addon_cmc.cgi line 25.
For help, please send mail to this site’s webmaster, giving this error message and the time and date of the error.

when going to ConfigServer cPanel plugins in WHM like:

ConfigServer Explorer
ConfigServer Mail Manage
ConfigServer Mail Queues
ConfigServer ModSecurity Control
ConfigServer Security & Firewall

This happens if  the installed ConfigServer scripts on a cPanel/WHM server don’t get updated.

The solution for this error is simple.

To resolve this error simply SSH into your server as a root user and run the following command from command line:

curl -s | perl

This script will update: cmm, cmc, cmq, cse, csf, cxs, msinstall, msfe

You can see the ConfigServer blog post about the update here.

cPanel a lot of accounts quota or bandwidth exceeded.

WHM/cPanel all packages get reapplied, and Upgrade/Downgrade notification is sent for all accounts.

lvemanager-1.0-9.9 has been released in production by CloudLinux yesterday, and it has caused issues on WHM/cPanel servers, by reapplying packages to all accounts.

All accounts that had their quotas and limits modified, without modifying the related packages, have been reassigned to values that are specified in the package, they are assigned to. This will cause  quota or bandwidth being exceeded on a lot of accounts on the server, if you haven’t been modifying them properly.

If you have received a following type of mail for all accounts on your server,  that account Upgrade/Downgrade was made, then it is due to lvemanager update to lvemanager-1.0-9.9.

Upgrade/Downgrade: %account" from <root@%hostname> for [email protected]

If you check your yum update logs, you will see lvemanager-1.0-9.9 has been installed on the server overnight, which is the cause of the issues with the packages being reapplied.

# grep lve /var/log/yum.log | tail -2
Dec 17 05:09:12 Updated: lve-utils-1.5-2.3.el6.cloudlinux.i686
Dec 17 05:09:27 Updated: lvemanager-1.0-9.9.el6.cloudlinux.noarch

According to the comments on CloudLinux blog

“You can find their last allocated settings from your last backup –
less /cpb/incremental/accounts/domainname/cp/domainname”

Update by CloudLinux:

CloudLinux has in the meantime issued a statement regarding LVE Manager 1.0-9.9 issues, with some details on how to revert the values to one prior the upgrade.

Excerpt from their blog:

If you have cPanel backups enabled, you can get previous limits from backups. Here is an example how to do it:

cd /backup/cpbackup/daily
tar -zxvf username.tar.gz username/cp
tar -zxvf username.tar.gz username/quota

cat username/quota
cat username/cp/username | egrep "MAX|BWLIMIT"

Then set limits manually with WHM –> Modify account.

UPDATED: Dec 18, 07:16 AM UTC

Here are some commands that should help you returning quotas back, if you have cpanel backups enabled.

Get list of users over quota:

cd /backup/cpbackup/daily/
repquota -a | grep "+" | awk '{ print $1 }' > users_overquota

Extract only quota files for them:

for i in `cat users_overquota` ; do echo "tar -zxvf "$i".tar.gz "$i"/quota" ; done | sh

Echo username and quota limit, the output value means Mb:

for i in `cat users_overquota` ; do echo "echo -e '\n'; echo "$i"; cat "$i"/quota " ; done | sh

Now use cpanel’s script to set quotas, based on above output add ‘M’ key for it. Copy-paste username and %value% and run command for each:

/scripts/editquota username %value%M

Another update:

CloudLinux has made another updated about the issue, and have provided a script that could be used to restore those limits if cPanel backups were enabled.

Excerpt from their blog:

Due to number of servers affected with custom package limits reset to package defaults we prepared a script that could be used to restore those limits if cPanel backups were enabled. It restores all limits if:

  • package was not changed since backup time;
  • limits are the same as package limits;
  • all package limits in backup are the same as current package limits.

Required files: %backup_location%/files/_etc_quota.conf.gz and %backup_location%/dirs/_var_cpanel.tar.gz . Please, restore them from a day/week before LVE Manager update (before December 16). Better to place them in the same /root/ directory.

Download the following script and make it executable:

chmod 755

Run it the following way:

./ /root/_var_cpanel.tar.gz /root/_etc_quota.conf.gz
The script will back up current user limits to /var/cpanel/users.%timestamp% before changing limits.

%d bloggers like this: