Similar to the intentions of SPF records and DomainKeys, DKIM is intended to authenticate a sender by using a public/private key pair to digitally sign email, therefore increasing deliverability. At this point in time, while SPF records and DomainKeys are supported in cPanel, outgoing authentication with DKIM is not. That being said, please keep the following points in mind while following this tutorial:

1. The cPanel developers indicated that DKIM auth will be a feature in 11.32, therefore, when 11.32 is released it’s possible that a few steps in this guide will become obsolete
2. cPanel does not recommend or provide support for some of the changes this tutorial will ask you to make.  As usual, make these changes at your own risk or use our server consultation services for help

Upgrade Exim

DKIM is supported in Exim 4.70 and higher – the version current at the time this article was written is 4.69. Therefore, you will need to upgrade.  Hop over to the below URL, locate the latest version of Exim 4.7x, and navigate to the folder that corresponds with your operating system to find the RPM:

http://httpupdate.cpanel.net/exim/

In this case, we downloaded the RPM from:

http://httpupdate.cpanel.net/exim/4.70-4/centos/5.6/exim-4.70-4_cpanel_maildir.i386.rpm

On your server, run the following command (replace the URL with the one corresponding to the RPM you found)

rpm -Uvh http://httpupdate.cpanel.net/exim/4.70-4/centos/5.6/exim-4.70-4_cpanel_maildir.i386.rpm --nodeps

Now, verify the version:

root@server [~]# rpm -qa |grep -i exim
exim-4.70-4_cpanel_maildir

You’ll also want to keep cPanel from running an Exim update and reverting the version back to 4.69:

touch /etc/eximupdisable

 

If you have existing domains on this server, make sure to move local and remote domains files back:

mv -f /etc/localdomains.rpmsave /etc/localdomains
mv -f /etc/remotedomains.rpmsave /etc/remotedomains

*If you have trouble installing the RPM due to fetchmail or a conflict with the previously-install Exim package, do

yum remove fetchmail

rpm -e exim-4.69-29_cpanel_maildir (replace with the actual name of the old Exim package)

Install DomainKeys

The topic of how to install DomainKeys was previously covered in this article. Install the keys for each user, or run a loop as shown in the article to install them for all users.  The keys will be in: /var/cpanel/domain_keys/[public|private]/$domain .

Configure Exim

Open /etc/exim.conf and near the top, add the following lines:

DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /var/cpanel/domain_keys/private/${lc:${domain:$h_from:}}
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}

Then scroll down until you see these lines:

remote_smtp:
driver = smtp

Replace this with:

remote_smtp:
driver = smtp
dkim_domain = DKIM_DOMAIN
dkim_selector = default
dkim_private_key = DKIM_PRIVATE_KEY
dkim_canon = relaxed
dkim_strict = 0

Now, restart Exim:

service exim restart

The additions to exim.conf will use a domain’s key, if the domain has one, to sign each message with DKIM.

Now, keep in mind that cPanel will overwrite these changes during cPanel updates. You have the following options:

• Run chattr +ia /etc/exim.conf, OR:
• Copy /etc/exim.conf to /root/exim.conf and create a file called /scripts/posteximup (and chmod to 700) containing the following code:

scp -p /root/exim.conf /etc/exim.conf
service exim restart

Verify

The easiest way to verify the functionality of your new DKIM setup is to send an email from your server to check-auth@verifier.port25.com . You’ll get an autoresponse back letting you now that everything is working (note that with DKIM, DomainKeys are obsolete so a status of “neutral” is normal)

SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

A common request we get is how a user can automatically BCC outgoing email to another address. This is most often requested by law firms that need to be able to retain copies of communication. Forwarding incoming email is easy – there’s already a section in cPanel for it. However, if you want to forward outgoing email there’s a small twist.

First, go to WHM > Exim Configuration Editor, then click “Advanced Editor” at the bottom. Don’t make any changes, just click “save”. This should create a file on the server called /etc/exim.conf.local.  From command line as root, you’ll need to edit /etc/exim.conf.local and add some options to the @CONFIG@ and @TRANSPORTSTART@ sections. The end result would look like this (plus any edits you may have already made):


@AUTH@

@BEGINACL@

@CONFIG@
system_filter_directory_transport = local_copy_outgoing

@DIRECTOREND@

@DIRECTORMIDDLE@

@DIRECTORSTART@

@ENDACL@

@RETRYEND@

@RETRYSTART@

@REWRITE@

@ROUTEREND@

@ROUTERSTART@

@TRANSPORTEND@

@TRANSPORTMIDDLE@

@TRANSPORTSTART@
local_copy_outgoing:
driver = appendfile
delivery_date_add
envelope_to_add
return_path_add
group = cpaneleximfilter
user = cpaneleximfilter
mode = 0660
maildir_format = true
create_directory = true

Now, make a copy of the existing system filter file to a custom location, so cPanel updates don’t mess with it:

cp  /etc/cpanel_exim_system_filter /etc/cpanel_exim_system_filter_custom

Edit /etc/exim.conf.localops and change the “systemfilter” option to match our new file:

systemfilter=/etc/cpanel_exim_system_filter_custom

Now, open /etc/cpanel_exim_system_filter_custom and add the following block of code to the end of the file:

if $header_from: contains "@senderdomain.com"
then
unseen deliver "other@emailaddress"
endif

Replace the blue text with the sender domain (or email address)  and the email address that outgoing mail should be copied to.

Apply these new settings to the exim.conf and restart:

/scripts/buildeximconf
service exim restart

Now when you send email from the email address or domain specified in the filter file, it will be copied to the other email address.

The cPanel security team found an issue in Exim that can potentially allow a user on the system to potentially run commands as the root user. Luckily, cPanel has already released a patch which is available for immediate download via their Exim upgrade script. If your system is set to update cPanel automatically, you may already have the patch. To verify, run:

rpm -qa |grep -i exim

The version should be 4.69-25 – if it’s not, you need to upgrade. You can simply run:

/scripts/eximup

Click the link below to read cPanel’s advisory:

http://mail.cpanel.net/pipermail/news_cpanel.net/2010-December/000060.html

cPanel 11.28 introduces an way to easily implement your own RBLs for Exim to perform lookups against.  To get started, log into WHM > Exim Configuration Editor and click on the RBLs tab, then Manage custom RBLs.

From here, enter in the information for your RBL as follows:

The DNS list would be the hostname of the server that Exim will do DNS lookups against, and the info URL is generally what appears in bounceback messages where senders can go to either look up their IP, or find out more information on the RBL.

Once you’ve saved, go back into the Exim Configuration Editor under RBLs, and select “On” next to your RBL name.

Automation

You can also automate this by using an RBL template, rather than going through WHM. This is particularly useful for server setup scripts, or applying this change across multiple servers.

First, go into /var/cpanel/rbl_info (if the folder doesn’t exist, create it), and create a file called yourdnsbllist.yaml

The YAML file would look something like this:

---
dnslists:
- dns.myrbl.org
name: myrbl
url: http://fakeurl.org/checkmyip.php

Now in /etc/exim.conf.localopts, add the following:

acl_myrbl_rbl=1

Of course, the myrbl part would reflect the name of the actual RBL you created.

To rebuild the Exim config, run /scripts/buildeximconf

One of the most common problems that hosting providers face is the issue of user email not being delivered to other mail servers.  Not only does it annoy the end user, but it’s extremely frustrating for the server administrator to deal with since there’s not always a clear indication of why email doesn’t get delivered successfully.   In this post I’ll explain a few tips for helping improve the reliability of your mail server, and some tips you can give to your end users that send mailing lists.’

Note: You can’t control the incoming email policies of remote mail servers or RBL’s. However, most email providers will not intentionally inconvenience their own users by blocking legitimate email, so if you continue to have problems, I’d recommend contacting the email administrator of the remote server.

1. Do you look like a spammer?

First of all, if you’re sending out massive mailing lists, whether you consider it spam or not, you’re asking for it.  Out of a list of 100,000 people, you can expect that a couple hundred of them are going to prompt spam complaints to your email provider, especially of the emails are of a “spammy” nature.  If you’re not sure where you sit on the line between spam and email marketing, take a look at this post.

2. Practice proper mailing list etiquette

As a mailing list grows, you’re occasionally going to have email addresses that become invalid, or users that no longer want to receive your email.  Don’t think that by hiding your opt-out link, you’re going to keep a subscriber. The recipient is more likely to mark your email as spam than hunt around for a way to remove their email address from your list, so make things easier by putting your opt-out link at the top with a reminder of why you are sending the email. For example:

You are receiving this newsletter because you purchased a product on mywebsite.com and requested to receive notifications. If you no longer want to be part of this mailing list, please click <here>

That being said, it’s extremely important that you promptly honor opt-out requests, and regularly check for bounced email for addresses that may no longer exist.

In addition to this, when sending email locally, your SMTP hostname should simply be “localhost”.

3. Limit outgoing email

If you’re a hosting provider and aren’t specifically catering to users that do bulk mailing, you may want to limit how much email each users can send, and advise users with large mailing lists to use services like Constant Contact.  Tweaking a mail server to effectively send huge amounts of email without issue can be very difficult, and isn’t something I’d recommend even offering for shared hosting platforms.  In a shared environment where the actions of one user can affect many, outgoing email should be limited and then allowed on a per-case basis. There are two simple ways to do this:

• In WHM > Tweak Settings, set the outgoing mail limit . You can specifically allow domains to send more by adding them to /var/cpanel/maxemails on versions 11.26 and lower, or adding a MAX_EMAIL_PER_HOUR option to /var/cpanel/users/$user for cpanel 11.28 and higher.
• In exim.conf, set the following options:

recipients_max_reject = true

recipients_max = 50

The best way to do this so the change is retained over cPanel and Exim updates is to add the options in /etc/exim.conf.local under @CONFIG@, then run /scripts/buildeximconf

Exim considers each email as one email, regardless of how many recipients are in it.  This may be an inconvenience to some users, but in reality any mailing list should be sent as one recipient per email.  For larger organizations that use mailing lists for discussion, a listserv software like Mailman is a better solution.

4. Tighten up your mail server

If you’ve ever wanted to be the target of a spam hack, allowing PHP nobody mail is the best way to accomplish this.  Hopefully by now you’re running suPHP, but if you’re still running PHP as a DSO, whenever a PHP script uses the mail() function to send email it’s going to do so as the user “nobody”, or whatever user that Apache runs as.  Since the user “nobody” is a system user, it bypasses mailing limitations that you may have already set up via cPanel or exim.conf. This means that a rogue mailing script on your server can send out unlimited amounts of email and cause your server to get blacklisted. You can adjust this setting in WHM > Tweak Settings.

You’ll also want to make sure that SMTP Tweak is turned on:

/scripts/smtpmailgidonly on

It’s also a good idea to require sender verification, which can be enabled in WHM > Exim Configuration Editor

5. Always use SMTP

Similarly, mailing list software should be configured to use SMTP with a valid email address, username, and password. Don’t rely on sendmail or the php/perl mail functions – you need to send as a valid authenticated user.  Most mailing list software supports the use of SMTP, and using PHP or perl it’s very easy to incorporate SMTP authentication.

6. Use DomainKeys and SPF records

You want other mail servers to know that when they get mail from you, it’s actually from your server and not spoofed.  Consider using DKIM and SPF records to allow remote mail servers to authenticate your email. You’ll find that this may instantly improve your email delivery to services like Yahoo, MSN, and Hotmail.

See: Installing DomainKeys and SPF Records

7. Subscribe to Feedback loops

It’s very important for email administrators and hosting provides to subscribe to feedback loops.  Many remote mail and blacklist providers offer them, and they can be a very useful tool for identifying possible spammers on your network, as well as preemptively resolving issues with mailing lists.  If you don’t have an Abuse contact set up your domain and IP addresses, you should do that now – and register your IP(s).   AOL, Hotmail, Yahoo, and Spamcop are excellent ones to be on.  It’s also important to have your abuse@domain.com address set up so people can contact you if they want to report spam from your server or network.

8. Monitor your IPs

As easy as it is to get blacklisted on the various RBL’s out there, you’ll want to be checking if your IPs may be listed and therefore causing your email to bounce.  RBLmon.com is a good way to get started, or you can implement blacklist checking into your existing monitoring solution.  The goal is to know when your IPs are blacklisted as soon as possible.

9. Use different IPs for email

By default, when you send email your email will go out on the main IP of the server. For sites that send large amounts of email, consider putting them on separate IPs so that they don’t affect the mail delivery of other users on the server, or the network in general.

See: Changing Exim’s Sending IP

10. Set up your DNS properly

It should go without saying that whatever IP you use to send mail should have a proper reverse DNS record, and the forward DNS of that PTR should match. For example, if your mail server is named mail.mydomain.com and points to 5.6.7.8, then the PTR for 5.6.7.8 should also be mail.mydomain.com.  Ideally these records should match the EHLO/HELO name given by your MTA (Exim). This name can be altered in /etc/mailhelo if you have this option checked in WHM > Exim Configuration Editor.

In your Exim logs you may see errors like this:

Warning: ACL "warn" statement skipped: condition test deferred: ratelimit database not available

temporarily rejected connection in ?connect? ACL: ratelimit database not available

This likely means the Exim cache databases are corrupted. You can clear them by running:

rm -fv /var/spool/exim/db/*

Then restart Exim.

The files in question are:

• /var/spool/exim/db/ratelimit
• /var/spool/exim/db/ratelimit.lockfile
• /var/spool/exim/db/retry
• /var/spool/exim/db/retry.lockfile
• /var/spool/exim/db/wait-dk_remote_smtp
• /var/spool/exim/db/wait-dk_remote_smtp.lockfile
• /var/spool/exim/db/wait-remote_smtp
• /var/spool/exim/db/wait-remote_smtp.lockfile

In cPanel 11.25, you may be seeing errors like this in /var/log/exim_paniclog:

2010-04-15 12:33:27 failed to expand condition "${if exists {$home/etc/$domain/quota}{${if > {${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}{0}}}{0}{${if eq {${if exists {$home/mail/$domain/$local_part/maildirsize}{1}{0}}}{0}{${if > {${run {/usr/local/cpanel/bin/eximwrap GETDISKUSED $local_part $domain}}}{${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}{0}}}{true}{false}}}{${perl{checkuserquota}{$domain}{$local_part}{$message_size}{${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}}}{$home/mail/$domain/$local_part/maildirsize}}}}}{false}}}{false}}" for virtual_user_maildir_overquota router: absolute value of integer "10485760000" is too large (overflow)

To fix this, run :

/scripts/reset_mail_quotas_to_sane_values –force –confirm –verbose

cPanel’s stock installation of Exim includes a Tailwatchd driver called Antirelayd . Antirelayd is a daemon that checks /var/log/maillog for POP3 and IMAP logins and keeps track of valid logins for SMTP relaying. It reads /etc/relayhosts file automatically which is dynamically-updated, so any IPs that you add to this file will not be retained.

By default on all cPanel servers, authentication is required to send email via SMTP. Exim lets you authenticate two ways:

• Directly through SMTP with a valid username/password
• Through POP3 login, which allows the user to relay through the mail server for 30 minutes without re-authenticating

To always force SMTP authentication regardless of POP authentication, type the following command via SSH as root:

/usr/local/cpanel/bin/tailwatchd –disable=Cpanel::TailWatch::Antirelayd

To reverse this setting back to the default:

/usr/local/cpanel/bin/tailwatchd –enable=Cpanel::TailWatch::Antirelayd

You can alternatively disable/enable Antirelayd in WHM > Service Manager.

It’s generally not a good idea to allow open relaying through your mail server unless you want to get blacklisted.  There may be situations where you need to permanently let another server send mail through your server without authentication, in which case you can add their IP to /etc/alwaysrelay . A post in the cpanel forums suggests an alternate solution as well:

In WHM > Exim Configuration Editor > Advanced Editor, find this section:

accept hosts = +auth_relay_hosts
endpass
message = $sender_fullhost is currently not permitted to \
relay through this server. Perhaps you \
have not logged into the pop/imap server in the \
last 30 minutes or do not have SMTP Authentication turned on in your email client.
authenticated = *

Appended to this suggestion is changing:

accept hosts = +auth_relay_hosts

to

accept hosts = /etc/exim_smtp_whitelist

There are minor tweaks you can make to exim.conf to remove SMTP authentication altogether, but you won’t find that information here. We don’t want to encourage bad mail server setup that will make the SPAM problem on the Internet even worse.

You can test to see if your server is open relay by sending an email via Telnet and getting a 550 error:

:~$ telnet thecpaneladmin.com 25
Trying 69.174.52.38...
Connected to thecpaneladmin.com.
Escape character is '^]'.
220-thecpaneladmin.com ESMTP Exim 4.69 #1 Tue, 23 Feb 2010 20:37:54 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
helo thecpaneladmin.com
250 thecpaneladmin.com Hello myserver.com [x.x.x.x]
mail from: admin@thecpaneladmin.com
250 OK
rcpt to: test@test.com
550-mail1.thecpaneladmin.com (thecpaneladmin.com) [xx.xx.xx.xx] is
550-currently not permitted to relay through this server. Perhaps you have not
550-logged into the pop/imap server in the last 30 minutes or do not have SMTP
550 Authentication turned on in your email client.

When I was in technical support, I got at least a dozen or more calls a week about clients who couldn’t send email, but had no problem receiving. When incoming mail works fine but the client can’t connect to the SMTP server, 99.9999% of the time it’s being caused by the ISP blocking remote SMTP/port 25 connections.  You can tell your customers this, but by now you probably know that your customers only care about what you can do for them. You know the ISP isn’t going to budge, and you can’t really blame them – the influx of SPAM has forced a lot of ISPs, webhosts, and email providers to change their protocols. And you need to as well.

Luckily cPanel offers an easy solution for opening additional ports for Exim, so your clients that can’t use standard port 25 can still send email through your mail server.

To enable the second port, all you need to do is log into WHM > Service Manager and check both boxes next to “exim on another port” and enter the port (one that is not already used) in the box, then save the settings. If you have a firewall, you also need to make sure the port is open so your users can connect to it.

Anyone running a shared hosting server is probably now accustomed to dealing with constant complaints about blacklisting. It’s exim’s default setup on a cPanel server to use the shared IP of the server to send email, which means that all your clients on one server are sending out email on the same IP.  All it takes is for one spammer to send out a mailing list or one customer to get hacked and run a Darkmailer script, and suddenly everyone on your server seems to be complaining about getting their mail bounced.

You can change the server’s IP address for sending email. Assuming you already have an IP set up on your server with a valid PTR, you probably already saw on the cPanel forums or some other location that you can simply change the interface lines in your /etc/exim.conf file and restart exim:

remote_smtp:
driver = smtp
interface = ${if exists {/etc/mailips}{${lookup{$sender_address_domain}lsearch*{/etc/mailips}{$value}{}}}{}}
helo_data = ${if exists {/etc/mailhelo}{${lookup{$sender_address_domain}lsearch*{/etc/mailhelo}{$value}{$primary_hostname}}}{$primary_hostname}}

dk_remote_smtp:
driver = smtp
interface = ${if exists {/etc/mailips}{${lookup{$sender_address_domain}lsearch*{/etc/mailips}{$value}{}}}{}}
helo_data = ${if exists {/etc/mailhelo}{${lookup{$sender_address_domain}lsearch*{/etc/mailhelo}{$value}{$primary_hostname}}}{$primary_hostname}}
dk_private_key = "/var/cpanel/domain_keys/private/${dk_domain}"
dk_canon = nofws
dk_selector = default

In the above example, all you’d do is comment out the interface lines and replace them with:

interface = xx.xx.xx.xx

However, this tends to be a band-aid fix, as a cPanel update or any change made in WHM’s Exim Configuration Editor will regenerate the Exim config and overwrite your change. To make this more permanent, you’ll want to use the /etc/mailips file.

To set this up initially, go into WHM > Exim Configuration and enable this option:

** Send outgoing mail from the ip that matches the domain name in /etc/mailips (*: IP can be added to the file to change the main outgoing interface) [?]

Or, in /etc/exim.conf.localopts, add/change this line:

per_domain_mailips=1

Then run

/scripts/buildeximconf
service exim restart

*The /etc/mailips file should be root:exim, chmod 440  if it doesn’t already exist.

chattr +i /etc/mailips

Now for actually changing the IP:

Changing the IP Globally

If you want everyone on the server to send out on the same IP, just add the following to /etc/mailips:

*: xxx.xxx.xxx.xxx

Then add the IP and it’s matching PTR to /etc/mail_reverse_dns:

xxx.xxx.xxx.xxx hostname.tld

This will tell Exim to use that IP for any sender on the server.

Changing the IP Per Domain

If you want your users with dedicated IP addresses to be able to use those IPs to send email as well, you can add them to /etc/mailips. cPanel actually now has documentation on how to do this properly:

http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/EximDifferentIps

If you have multiple dedicated IP domains already, I’ve devised a simple loop you can use to populate /etc/mailips automatically:

while read line ; do DOMAIN=`echo -e $line |awk '{print $2}'` && IP=`echo -e $line |awk '{print $1}' |cut -d: -f1` && echo "$DOMAIN: $IP" >> /etc/mailips ;done < /etc/domainips

You’ll always want the wildcard line to be in there to account for any domain not listed in the file, whether it is the main server’s IP or another that you have assigned for email:

*: xxx.xxx.xxx.xxx

Then:

cp /etc/domainips /etc/mail_reverse_dns

This will set all the existing sites on dedicated IPs to send out mail on those IPs.