In the fight to combat spam there are many different methods that can be employed to prevent these unwanted solicitations. Although no single solution is perfect, implementing various combinations of these methods can greatly improve the amount of spam mail that a domain or an account receives. When managing a server there are two fronts in which this battle against spam is fought: The prevention of incoming spam for the users on the server, and the internal security of the server and site scripting to ensure that a site’s data is not exploited by an outside source in order to send spam, which can cause the server’s IP(s) to be blacklisted and can harm its overall reputation on the internet. In this article we will focus on the prevention of incoming spam.
Mitigating incoming spam on a WHM/cPanel server:
There are 3 specific levels of the network and server environment where incoming spam can be filtered or prevented outright.
1. Network level (Iron Port)
2. Server level (Exim Configuration)
3. Account level (Spam Assassin and Mail Filters)
Network Level Spam Filtering:
The first level of spam filtration is at the network level using an IronPort server. IronPort technology is a physical server that all email traffic for a domain can be routed through to filter mail by updating the domain’s MX records in DNS. This server filters mail based upon the sender’s IP reputation with http://senderbse.org. While this technology does an excellent job at filtering the most obvious and egregious spam, it does have a few drawbacks. Most importantly, users cannot monitor what the system is filtering and what it is not. It simply stops mail that it determines is spam and does not deliver it through the network and to the user’s server. There are no reports sent and users cannot tweak the system to better suit their specific needs as this is a system shared by all it’s users on the network. The only way to inquire as to whether or not the system is improperly filtering a legitimate message or the reasons why it may be letting some spam messages through is by submitting a ticket to our administrators to have them check the IronPort server logs. If spam is still coming through after being placed behind the IronPort server, a ticket can be submitted with the full headers of the suspicious messages or the senders address on messages not arriving so that the systems administrators can analyze these headers.
Secondly, because the spam filter works mostly on the IP reputation of the sender, spam sent from a clean IP will not always be filtered by this system. It generally does not take long for the IP to be reported as a spam source and thus these messages are eventually filtered, but some unwanted messages may still get through this system. The main drawback to using the Ironport server is that there is no user access or control which may be troublesome to some users who would like to have a detailed analysis as to what mail is being filtered and the reasons behind it, though we have found that this is generally not required and that the technology provides most customers with suitable spam filtering. A ticket needs to be submitted through the Customer Dashboard in order to request that mail is routed through the IronPort sever.
Server Level Spam Filtering:
The second level of spam filtration is at the server level, with included software in the WHM panel and various mail server configurations that can be used to prevent or filter incoming spam. Most of these features are enabled by default but there are many settings that, while they will block spam, they can also cause false positives and block legitimate mail that users expect to be receiving. Having a full understanding of the pros and cons of these settings is necessary for users and server administrators to properly determine whether or not to enable some of these features. Many times, the drawbacks must be weighed against the advantages and the final decision about how to configure these settings can only be made by those managing the sites on the server as there is no universal configuration that will work for everyone and in every circumstance. In all of these configuration pages, be sure to click the save link after making any changes to ensure that they are applied on the server.
The Tweak Settings server configuration page has a number of different options that can be enabled and/or adjusted in order to combat incoming spam. To access this section of the panel type tweak into the search bar in the upper-left hand corner of the WHM panel. The first option it brings up should be Tweak Settings under the Server Configuration category:
Click on the Tweak Settings link and then click the Mail tab:
In this tab there are a number of options for strengthening the server against unwanted spam. Please keep in mind that these are server wide configurations though some of these settings will also need to be enabled/configured at the user’s level in order to be applied to that specific domain or email account. They are not always universally applied to all domains/users on the server.
1. Enable the BoxTrapper Spam trap.
The BoxTrapper is a system that requires all unknown senders to reply to a verification email upon their first attempt to send to the server. Once the sender has verified that they are legitimate they will be able to send mail to the server from that point on. Any address that a user has already sent mail to while the BoxTrapper is enabled will automatically be considered a valid sender by the BoxTrapper system and will not be forced into this verification process. The option must be enabled in this section in order for the domains and users on the server to enable this on their individual domains and accounts. To enable the Box Trapper ensure that the On option is selected in the following section of the Tweak Settings Mail tab:
Please keep in mind that this type of verification has been known to irritate senders and block messages sent from mailing lists and other similar automated systems so discretion must be used when determining whether or not to use this system. It also takes additional processing power to run and has been known to unnecessarily use up disk space so we recommend that, if a user insists that this functionality is enabled, it is only used in conjunction with the SpamAssassin mail filter to cut down on excessive resource usage. Additionally, due to problems with the BoxTrapper system that have been reported by many cPanel users, we recommend using this only if all the other options discussed in this article have been exhausted.
Please also keep in mind that enabling the BoxTrapper in this section only makes it available for users to enable at their discretion on a per domain basis. Having the option set to “On” here does not apply this globally to all domains on the server.
Please note that the Old Style Spam System setting in WHM’s Exim Configuration Manager interface must be disabled for BoxTrapper and Apache SpamAssassin to work together properly. This setting can be found by typing exim into the search bar in the upper left-hand corner of the panel. The first option it brings up should be the Exim Configuration Manager:
Click the Exim Configuration Manager link and then click on the Apache SpamAsssassin Options tab:
The setting should be set to Off by default, but this should be verified just in case. If it is enabled, disable it to ensure that running the two filters will not cause any conflicts.
2. Enable SpamAssassin.
SpamAssassin is a Bayesian mail filter that comes included with cPanel and Apache servers that runs each message it scans through hundreds of tests to analyze the message headers, text, HTML encoding, and it also checks domains and IP addresses against blacklists and filtering databases. Based upon the configuration of the filter, SpamAssassin will either reject messages that fail these tests outright, move them to a specific directory on the server for further review by the user, or will deliver the messages normally but append ***SPAM*** into the subject line of the message to inform the user that it has scored the message as spam. This allows the user to decide how to handle the message from that point.
Understanding how the SpamAssassin scoring system works is vital to properly configuring and using this filter to effectively combat spam without losing legitimate mail to false positives. The scoring system weighs hundreds of different aspects of the message, so many that going into all of them specifically would be unproductive. In a general sense, most messages will start out with a neutral (0) score. As the system runs through the various checks it will assign a positive or negative number to the message for each one based upon whether it passes or fails the analysis. At the end of the scan there will be a total number assigned to the message based upon these tests. If this score is higher than the threshold set by the user, the message will be marked as spam and handled accordingly depending on how the filter is configured. If the score is lower than the set threshold, the message will be deemed legitimate and passed through to the recipient. When setting the score threshold users must keep in mind that this setting is a benchmark against the score assigned to the message by the filter. The higher the score, the more likely that the scanned message is a spam message. By setting the threshold to a lower number, this effectively increases the “strength” of the filter. It is important to keep this in mind when setting global options within the SpamAssassin system. As a general rule, it is better to have a lower score on individual account’s scoring benchmarks and a higher score on global scoring benchmarks. More information about the specific checks run on messages in the scan can be found here:
There are two options for enabling SpamAssassin in the WHM panel. It can be forced globally, which will scan all mail on the server regardless of the choices of the individual domains and users, or it can be enabled as such to give users the option of using this feature or not. To force the server to always use SpamAssassin you must go into the Exim Configuration Manager. To access this type exim into the search bar in the upper left-hand corner of the panel. The first option it brings up should be the Exim Configuration Manager:
Click the Exim Configuration Manager link and then click on the Apache SpamAsssassin Options tab:
In this section set the Apache SpamAssassin: Forced Global ON option to On to enable this system globally:
To enable SpamAssassin but not force it globally on the server you must first make sure that the previous setting in the Exim Configuration Manager is set to Off, which is the default setting. Once that is confirmed go the Tweak Settings section to enable the SpamAssassin filter in a manner that will allow users to decide whether or not they wish to use this feature. To access this section of the panel type tweak into the search bar in the upper-left hand corner of the WHM panel. The first option it brings up should be Tweak Settings under the Server Configuration category:
Click on the Tweak Settings link and then click the Mail tab:
To enable the SpamAssassin mail filter, make sure that the Enable Apache SpamAssassin spam filter option is set to On, which is the default setting:
This will allow users to enable SpamAssassin on their accounts individually through their cPanel without effecting how other user’s mail is handled on the server.
3. Enable the Apache SpamAssassin spam box
When utilizing SpamAssassin it is recommended that the spam box be enabled as well. The spam box is a directory that will be created on the server which Exim will move messages to that are marked as spam by SpamAssassin at the time of delivery. This is a better course of action in comparison to the Auto Delete spam feature as it will allow the users on the server to see what messages are being filtered and allow them to make sure that they are not missing legitimate mail that they expect to be receiving.
To enable the spam box set the Enable Apache SpamAssassin Spam Box delivery for messages marked as spam (user configurable) setting to On. This directory can be accessed either by going into the web mail system and viewing the contents of the directory directly on the server or by setting up an additional POP email account in a mail client with the user name format “firstname.lastname@example.org/spam” and the same password as the main account. It is recommended that this box be cleared regularly by downloading the messages via POP, by deleting them from the /spam directory in web mail, or by clicking the Clear Spam Box button the SpamAssassin configuration panel in the user’s cPanel. This will prevent unnecessary resource consumption on the server.
There are a number of settings in the Exim mail server configuration that can be enabled or adjusted to improve the server’s defenses against spam. These are applied globally and most are enabled by default. There are some settings that are not enabled by default due to certain negative repercussions and the server administrator must weigh the positives and negatives of enabling these functions as they can cause the server to reject legitimate mail outright with no notifications sent to notify the intended recipient that the message was rejected and for what reason. Only the administrator of the mail system and its users can make the final determination on the benefits and drawbacks of enabling these features based upon their use and expected functionality of the mail system.
To access the Exim Configuration Manager type exim into the search bar in the upper left-hand corner of the panel. The first option it brings up should be the Exim Configuration Manager:
Click the Exim Configuration Manager link and then click on the ACL Options tab:
This tab has various options for setting the server to reject spam outright on delivery and caution must be used when enabling these features as to avoid rejecting legitimate mail that the users on the server expect to be receiving. In these cases there will be no notification sent to the recipient that a message sent to their address was marked as spam and rejected and this can cause many disruptions in communications.
1. Enable the Apache SpamAssassin reject spam score threshold setting
This setting will cause the server to outright reject messages at the time of delivery based upon the score that it receives in the SpamAssassin filter. It is disabled by default and it is recommended that this be left disabled in order to avoid globally rejecting legitimate messages coming into the server. The better option is to allow the messages through and let the spam box and other user account and email client filters move messages scored as spam into a junk/spam folder for further review by the user.
There are options for individual domains to enable this type of auto reject/delete feature within SpamAssassin in their individual cPanel control panels if they desire this type of functionality. There is also the option of setting this auto-reject threshold to the highest spam score possible, which will ensure that only the most egregious spam messages are outright blocked while messages that are scored to a lesser degree will still be let through to ensure that the user has the opportunity to review them. Please keep in mind that, unlike the general Spamassasin score setting which commonly encourages setting the score to a lower threshold to increase the strength of the spam filter, in this case the highest reasonable number would need to be set (5+) to ensure that false positives are not rejected and only the most highly scored messages would be rejected outright.
2. Verify that dictionary attack protection is enabled
Dictionary attack protection will cause the server drop connections from and rate limit hosts with more than 4 failed deliveries due to an incorrect or nonexistent recipient address. This feature is enabled by default and it is recommended that this be left enabled to prevent spammers from using the Backscatter from your server to get a better idea of the legitimate addresses and account name formats on the server.
3. Enable the Reject remote mail sent to the server’s hostname setting
This setting is disabled by default, though it is recommended that you enable this setting as spammers are increasingly employing this method for attempting to get unwanted spam delivered to the server.
4. Verify that the Ratelimit suspicious SMTP servers setting is enabled
This setting will protect the server against senders that violate email RFC standards, are listed in RBLs, or have attacked the server previously. It is enabled by default and this is implemented by ratelimiting the connections from servers that violate the policy.
5. Enable the Apache SpamAssassin: ratelimit spam score threshold setting
By default the server will not use SpamAssassin scoring in general ratelimiting of senders. This option can be enabled and set with a specific score to force the mail server to rate limit connections from servers that are sending messages that meet or exceed this score. It is recommended that this is set to a higher score (5+) to ensure that only the most egregious violators of this policy are effected and this will not inadvertently cause ratelimiting of legitimate mail senders.
6. Verify that the Ratelimit incoming connections with only failed recipients setting is enabled
This setting will ratelimit connections from servers who have sent 5 messages to invalid recipients in a span of one hour. This is measured per connection and not measured against a message with multiple recipients.
7. Enable SPF and DKIM checks
SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), are DNS records that can be configured in Exim and within the domain’s DNS records to allow the receiving server to verify the mails origination. These records can also be created for accounts sending mail from the server in order to identify themselves at remote recipients servers in this same fashion. They are helpful in preventing spoofing, backscatter spam techniques, and general spam delivery as a result of messages with forged sender addresses being sent to the server. Setting up SPF specifically will also eliminate most backscatter spam as recipient servers will fail messages forged with a fake sender and not bounce those messages back to the forged domain. Please keep in mind that in order for SPF and DKIM to work properly both servers in the mail transaction need to have SPF and DKIM enabled in DNS and configured for server side cross checking.
What is Spoofing and Backscatter?
Spoofing is a technique that spammers will use that involves forging the senders address either as the recipient that the message is intended for, or as a recipient that it is believed will be an allowed sender at the recipients mail system. This is also done to make spam messages appear as if they are coming from a legitimate server even if the messages are being sent from an automated system with no actual email accounts configured. Another approach of this spam technique is to spoof the senders address knowing that most of the spam sent out as that user will bounce back to them and not the originating server. The bounces may be let through mail filters with the content of the original message in tact, effectively spamming the forged senders address without ever actually sending that user a message directly. This is called “backscatter” spam. In order to protect accounts on the server from having their addresses forged in the context of spoofing and backscatter certain DNS configurations need to be enabled at the domain level which will be covered later in our account level spam filtering instructions.
To ensure that the mail server will run these verification for incoming mail the following three options need to be enabled in the Exim configuration:
These are not enabled by default, and administrators must keep in mind that certain legitimate messages may fail these validations if the SPF record is incorrectly configured on the senders side, if the DKIM signature is modified by mail transport software, or if the message is sent from an automated system where the source server doesn’t match the senders domain which is common with these systems. If it is found that certain messages are failing due to these checks the sender’s IP address can be whitelisted using the Trusted SMTP IP addresses in the Exim Configuration to circumvent the checks.
8. Whitelisting and Blacklisting
There may be times where a sender’s IP will need to be whitelisted in order to avoid the previously mentioned system protections that do sometimes block legitimate mail, and other times which administrators may want to blacklist specific IP addresses and networks outright. This can be done in the Access Lists tab in the Exim Configuration Manager:
To whitelist an IP click the Edit button in the Trusted SMTP IP addresses section:
This will bring up a window to place IP’s in the whitelist:
Add the desired IPs to the whitelist, one per line, and then click Save. Please keep in mind that adding IPs to this whitelist will circumvent all SMTP-time recipient, sender, spam, and relay checks so please use caution when whitelisting IPs and only add trusted networks to this list.
There is also a blacklist that IPs can be added to in the same manner in order to prevent problematic IPs from connecting to the server. The blacklist option is found in the same section as the whitelist and the IPs can be added in the same fashion by clicking the Edit button in the Blacklisted SMTP IP addresses section:
Just as with the whitelist, add the desired IP’s to the blacklist, line by line, and then click Save.
9. Verify that the Attachments: Filter messages with dangerous attachments setting is enabled
This setting is enabled by default and will reject messages with attachments containing the following file extensions:
.ade .adp .bas .bat .chm .cmd .com .cpl .crt .eml .exe
.hlp .hta .inf .ins .isp .js .jse .lnk .mdb .mde .msc
.msi .msp .mst .pcd .pif .reg .scr .sct .shs .url .vbs
.vbe .wsf .wsh .wsc
To verify that this is enabled or if this needs to be disabled for any reason this option can be accessed by clicking on the Filters tab in the Exim Configuration Manager.
10. Setting the SpamAssassin Subject rewrite on scored spam:
Part of the way that SpamAssassin works is by appending the subject line on messages that it scores as spam with a specific string of text. Based upon how the filter has been set to handle messages it deems as spam, as was discussed previously, this may or may not be an important factor when configuring local mail client rules to filter these messages. This setting is enabled by default and the default string that is added to the subject line for messages scored as spam is ***SPAM***. It is good practice leave these settings as is to assist domain users who may be using local mail client rules to filter out spam messages instead of using the spam Box or setting the filter to reject messages it scores as spam outright. While it is rare to change, WHM does give the user the option to disable this or change the string that is appended to the subject when a message is scored as spam.
This setting is enabled/disabled with the following option:
The text appended to the subject can be set in this option:
11. Set the Apache SpamAssassin™: bounce spam score threshold
This setting is similar to the previously discussed SpamAssassin settings that will globally reject mail for the whole server based upon the score it receives from the filter. This is disabled by default and it is recommended that this be left disabled to allow individual domains and email accounts to filter these messages after delivery by creating mail rules to filter messages labeled with “***spam***” into a separate directory for a later review or by utilizing the spam Box feature in SpamAssassin. If this is enabled it is recommended that the score be set to a higher number (5+) to ensure that legitimate messages are not rejected by the filter.
12. Sender Verification and Sender Verification Callouts
Sender Verification and Sender Verification Callouts are methods for the Exim mail server to verify that a sender’s domain and email account actually exist prior to delivering the message to the recipient on the server. Enabling these checks can cause legitimate mail to be rejected due to the internal build of the sending server’s network or if the message is being sent off of an automated list that utilizes a generic “email@example.com” address. Caution must be used when deciding to enable these options in WHM. Sender Verification is enabled by default but the Sender Verification Callouts are not, and this is for good reason. Sender Verification only checks that the domain on the senders email address actually resolves in DNS, but the Sender Verification Callouts will actually attempt to open an SMTP connection with the sending server and verify that the sending account actually exists. It is recommended that the default settings be left as is with these two options because the Sender Verification Callouts will cause many messages to fail, especially automated messages coming from a mailing list whereas the standard Sender Verification only checks to ensure that the domain resolves. These settings can be found in the Mail tab in the Exim Configuration Manager:
13. Enable RBL checks:
WHM comes with the ability to force the Exim server to check the IPs of incoming SMTP connections against a set of common RBLs (Real Time Blackhole List) and then reject those messages if the source IP is present on one or more of the lists. While RBLs are not perfect and some are more beneficial than others based upon their policies, how they blacklist IPs, and how they allow de-listing requests, they can help tremendously in eliminating the most egregious spam that comes into the server. There are hundreds of various RBL services on the web and some can be very effective, while others may have a detrimental effect due to overly aggressive listing techniques on their part causing users to inadvertently block legitimate incoming mail. Only the server administrator can properly determine specifically which RBLs to use and why.
WHM has the two most popular and most well respected RBLs added to the panel by default. Our recommendation is to use only these two RBLs but administrators do have the option of adding additional RBLs of their own choosing based upon their preference. To access the section of the Exim configuration to enable the default RBLs or add custom RBLs, click on the RBLs tab from the Exim Configuration Manager:
To enable the default RBL’s set the two options RBL: bl.spamcop.net and RBL: zen.spamhaus.org to On.
If additional RBLs need to be added click the Manage button in the Manage Custom RBLs section. It will bring up the following page:
The following credentials will be needed to add a new RBL:
RBL Info URL
The owner of the list should be able to provide the necessary credentials needed to add the RBL to the WHM server. Once the proper credentials have been added click Add to add the RBL. Please keep in mind that it will not be enabled by default and the newly added RBL will need to be enabled in the previous section in order to activate it on the server.
14. Enable Greylisting:
The Greylisting feature is only available on WHM version 11.50 builds or newer. If this option is not present in the WHM panel it is likely that the system needs to be updated the newest stable version in order to use this function.
Greylisting is a feature in the WHM panel that will force the mail server to temporarily defer email messages from unknown sources for a brief period time, but will accept the message if it is resent after the specific deferral time set within the greylisting configuration has expired. This combats spam based upon the knowledge that many spam messages are automated and that the system sending the messages will simply move on to a different target server vs. attempting to resend the message to the same user or domain after the initial deferral. Setting up a spam mail server to wait for deferrals and attempt retries can severely bog down the system due to the high volume of mail and most spam sources will not do this, so this is a very effective method for preventing spam. This system works by analyzing three pieces of data on incoming mail connections:
The source IP of the sending server
The sender’s address
The recipient’s address
If any one of the three pieces of data, referred to as triplets, is unknown than the message will be pushed into the greylisting process. Once the message is re-sent and accepted on the server the triplet data will be added to the “Trusted Hosts” list in order to prevent further greylisting of messages from the domain. Please note that when greylisting is initially enabled the known IPs from the following services are automatically added to the Trusted Hosts list:
Google (Gmail, Google Mail)
Microsoft (Hotmail, Live, Outlook)
Yahoo (Yahoo, Yahoo Mail)
To access the Greylisting portion of the panel type grey into the search bar in the upper left hand corner of the WHM panel:
This will bring up the Greylisting option in the Email portion of the panel. Click on this link to access the greylisting configuration:
By default, greylisting is disabled on the server and the page that is brought up when initially accessing this portion of the WHM panel should be displayed as follows:
Click the Off link to switch the service to On. Once it is enabled you will see the various options available to tweak the greylisting system to suit your specific needs, though the default settings have been found to be highly effective in combating spam:
15. Customizing the Greylisting Configuration, Adding IPs to the Trusted Hosts Whitelist, and Adding the Server’s Neighboring IP’s
Once the Greylisting service is enabled additional options will be available to the user to tweak the configuration, add IPs for servers that need to circumvent this process, and check reports that contain data about IPs being deferred in this system
The Configuration Settings tab:
This tab is where users can configure how long messages are initially deferred, how long a server has to resend and validate the message, and how long validated hosts are kept in the Trusted Hosts database. There are four options in this tab to configure the behavior of the greylist:
Initial Deferral Period (in minutes):
This number represents the period of time (in minutes) that a message is deferred from a remote server by the greylist. Once this amount of time has expired, messages from the same triplet will then be accepted and added to the Trusted Hosts database. The default setting is 10 minutes and this is the recommended time for this deferral.
Resend Acceptance Period (in minutes):
This number represents the period of time (in minutes) that the message from the initial deferral has to be resent in order for the system to add the IP to the Trusted Hosts database. The default setting for this is 240 minutes (4 hours) and is the recommended time to set the system to wait on a reply.
Record Expiration Time (in minutes):
This number represents the period of time (in minutes) that a confirmed sender who has passed the deferral process will be considered a Trusted Host. During this period of time they will not have messages deferred due to the greylisting process. The default setting for this 4320 minutes (3 days) but we recommend setting this to the max number of 43200 minutes (30 days) to ensure that senders who pass the verification do not have to frequently repeat this process.
Bypass Greylisting for Hosts with Valid SPF Records:
This setting will force the greylist to ignore hosts with valid SPF records. It is recommended that this be disabled as many spam sources will have valid SPF and enabling this setting could cause the greylist to allow even obvious spam through the system. It is better to greylist all unknown senders and add the IPs of frequent senders into the Trusted Hosts list in order to circumvent the greylisting for those specific domains.
The Trusted Hosts tab:
The Trusted Hosts tab is where users can add the IPs of hosts that mail the server frequently and are known trusted senders that do not need to pass this verification. When accessing this tab for the first time after enabling the greylist WHM should prompt the user with a message stating that the neighboring IP’s on the network have not yet been added and will ask the user if they would like to add them. Click the Add to Trusted Hosts link in this prompt to add the neighboring IP’s on the network to the Trusted Hosts list. This will help to ensure that domains on the server can send to each other and will not have to go through the greylisting process:
If the user is not prompted with this message they can do this manually by clicking the gear icon and selecting the option Add Neighboring IP Addresses:
The same steps can be used to remove the Neighboring IPs if it is determined that this is needed.
As mentioned previously WHM should automatically add the IPs of the most common mail providers to the Trusted Hosts list at the time that the service is enabled, but this can sometimes fail. If that occurs a list of the most recently known IPs for major email providers and ISP’s can be found here in the cPanel documentation:
To add IP’s to the Trusted Hosts database, add them line by line in the follow field and click Add:
The Reports tab:
The reports tab allows users to monitor triplets currently in the greylisting system and the status of the IP’s. These reports are most commonly used to find senders that users would like to add to the Trusted Hosts database in order to circumvent greylisting.
16. Request the addition of an rDNS record
rDNS (Reverse DNS) is a DNS record that sometimes needs to be added to the DNS zone for a domain as certain mail providers may reject mail coming from a server that does not specifically identify itself in DNS. By default DNS for VMs on the network will reverse back to a generic network address and not the specific host name of the server which can cause the server to be mistakenly viewed as a spam source at recipient networks. If it is found that the lack of a proper rDNS record is causing mail failures, users can submit a ticket to request that the proper reverse DNS record be added to correct this. This can only be done by our administrators as changes need to be made on the network as well as the user’s server to properly configure rDNS.
The third level of spam protection occurs at the user account level on the cloud server. There are a number of options in the user’s cPanel that will allow them to further tweak the systems that were enabled in the server configuration previously discussed, as well as standard domain and user level mail filters that can be configured to filter mail based upon specific content present in the message subject and body. If users are unable to find any of these options in their cPanel, please be sure that they are enabled at the server level in the WHM panel.
SpamAssassin offers many different configuration options that the user can enable or disable outside of the overall configuration on the server and does require some amount of user oversight in order to be effectively implemented on a domain. To access the SpamAssassin options click the following icon in the cPanel:
This will bring up the following screen to allow users to enable or disable certain functions. The panel will list which of these function are already enabled or disabled here as well:
This setting will set the SpamAssassin filter to auto delete spam that is scored at a certain level and can be enabled by clicking the Auto-Delete Spam button.
If users decide to enable this feature it is recommended that the score threshold set on the auto-delete function be set at the higher end of the scale to ensure that only the most egregious spam are automatically deleted. Users must take caution when enabling this feature as the messages that are removed are done so without notification or any chance for the user to review what is being deleted. Our recommendation is to leave this feature disabled and instead utilize the Spam Box so that users will at least have the option of accessing and reviewing the messages that the filter is scoring as spam. To disable this feature click the Disable Auto-Delete Spam button.
Enabling the Spam Box will cause the filter to move all messages scored as spam to a separate directory within the mail account labeled /spam and this allows for users to review the messages being scored as spam. If it is found that the filter is scoring legitimate messages as spam the user can then adjust the strength of the filter and/or white list domains or accounts accordingly to ensure that they are receiving legitimate messages that are being sent to them. To enable the spam Box click the Enable Spam Box.
To review these messages users can either access the webmail system to find the /spam directory, or these messages can also be downloaded into a local mail client such as Outlook or Thunderbird by setting up a separate mail account in the local software with the user name format firstname.lastname@example.org/spam and the same password for the account. The Clear Spam Box button can be clicked to empty the contents of the box as well.
The are a number of additional configurations for SpamAssassin that can be found by clicking the Configure Apache Spam Assassin button:
This section is where users can adjust the spam score threshold for the filter, whitelist and blacklist domains and addresses, and also do some additional fine tuning in how the filter scores various elements of the messages it scans. Generally speaking the filter fine tuning does not need to be modified but the option is there for users who wish to experiment with tweaking this system
The spam score defined here is the threshold that is set for when a message will be deemed as spam by the filter. The lower this threshold is the more aggressive the filter will be in labeling messages as spam
The whitelist and blacklist options are rather straightforward. Simply add addresses into the empty fields and click to add them to the blacklist or the whitelist. Then click save to save them in the SpamAssasin software. There are initially only 5 empty fields available for each of these but as addresses are added and saved more fields will be added to accommodate the addition of more addresses or domains. Wildcards will work in this system as well and can be added in the following formats:
email@example.com: Blacklists or whitelists a single email address.
*@example.com: Blacklists or whitelists all of the addresses at example.com.
?firstname.lastname@example.org: Blacklists or whitelists a single character in an address at example.com (for example, email@example.com, but not Auser@example.com).
2. Account-Level Filtering
Cpanel gives users the ability to set up mail filters similar to mail rules that are prevalent in mail client software like Outlook or Thunderbird. The Account-Level Filters option will apply the filters configured to all mail accounts on the server. To access the Account-Level Filters section of the panel click the Account-Level Filtering link in the cPanel home screen:
To add a new filter click the Create a New Filter button:
This will bring up the following filter configuration screen:
The filters work on a basic If/Then logic format and can be applied to various aspects of incoming email messages such as the message subject, the body, the recipient, the sender, etc. There are also various actions that can be taken once a message has qualified for the filter such as discard message, redirect to another address, fail with message, pipe to program, etc. The + and - buttons will allow users to add multiple qualifiers and actions within the same rule:
In this example I have created a filter that will Discard any messages where the subject or body contains the word Viagra:
The basic logic of this is IF the subject or the body EQUALS Viagra THEN Discard Message
Each condition contains many options for how to qualify for the filter and what the server is to do when the message has content that meets these qualifications. It is a very flexible and effective system but may take some experimentation to get the proper rules set for the most effective means of filtering messages based on the content of the message:
Please take note that there are options in the rules that pertain to the SpamAssassin filter which will allow more control over what the server should do with messages scored as spam by the filter. If the Spam Box is found to be limiting or additional actions need to be taken with these messages it is within this section of the panel where that can be tweaked more specifically. Once the filter is configured, click Create to add the rule.
3. User-Level Filtering
The User-Level filtering is the exact same system as the Account-Level Filtering. The only difference being that the user must first select the account that the filters will be applied to and then click the Create Filter button, which will bring them to the same screen discussed in the Account-Level Filtering. The filters here are configured in the same fashion as the Account-Level Filtering.
4. Email Authentication (SPF and DKIM)
Email authentication in cPanel will configure SPF and DKIM for the domain to improve mail delivery and to prevent email spoofing. To ensure that SPF and DKIM are enabled on the domain click the following link in the cPanel:
This will bring the user to the configuration screen for Email Authentication. Depending on how the domain was initially setup this may or may not be enabled the first time that this portion of the panel is accessed. In this example the user has not activated SPF and DKIM on the domain. Next to each section is an Enable button. Click this button for each service to enable these features:
For both services the default settings should be sufficient in effectively combating spam and Spoofing. There are some additional configuration options for SPF that may or may not need to be tweaked depending on how the mail is handled on the domain:
There is no additional configuration necessary for DKIM:
In a general sense, SPF identifies what servers, hosts, and IP’s should be sending mail as the domain by defining these variables in DNS so that recipient servers can verify the legitimacy of incoming mail and handle it accordingly. Recipient servers that check SPF will reject messages coming from servers that claim to host a domain but are not identified as sender in SPF. Most users will only send mail from their actual server and these settings do not need to be modified, but there are circumstances where third parties are used to send mail as the domain. For instance, some online entities will use a separate service for email marketing purposes and in these cases the host names of these services where the email actually originates would need to be added to the SPF configuration to prevent those messages from being rejected by servers that check SPF.
The warnings that appear on these example images can be disregarded. They are there because an unregistered domain was used for the testing server.
Greylisting is enabled and configured at the server level in WHM as previously discussed but individual users will have the option of disabling this service on a domain if they do not wish to use the greylisting feature. To access this click the Configure Greylisting link in the cPanel:
To disable Greylisting on a domain click the On/Off icon to switch the services to off.
Please keep in mind that there are some problems that can arise from using the BoxTrapper. It has been known to cause high load on the server, can be viewed as an overly aggressive spam prevention tactic by senders, and will cause messages coming from automated systems to be rejected by the server. With all the other options available for fighting spam in WHM and cPanel, users should only enable the BoxTrapper as a last resort option.
Even when the BoxTrapper is enabled on the server via its configuration in WHM, it must also be enabled on a per account basis in the domain’s cPanel. To access the BoxTrapper click the BoxTrapper link in the cPanel:
This will bring up the following screen allowing users to enable the BoxTrapper on individual accounts as needed by the users. To enable the BoxTrapper on an account first click the manage link on the list of accounts:
On the next screen there will be a number of options for the BoxTrapper and an Enable button. Click the Enable button to activate the BoxTrapper:
Once enabled there are a number of user configurable options for controlling the behavior of the BoxTrapper.
In the BoxTrapper Configuration there are a number of different variables that can be modified to adjust how the BoxTrapper system handles incoming mail. To access the configuration settings click the Configure Settings link on the main menu for the BoxTrapper.
This will bring up the following screen:
Email addresses for this account:
Add any email accounts that forward mail to the domain in this field, separated by commas, to ensure that messages forwarded to the account are passed through the BoxTrapper.
Enter your name here.
The number of days that you wish to keep logs and messages in the queue:
The default setting is sufficient here. We do not recommend setting this any higher than 15 days to avoid unnecessarily using up the server’s resources.
Minimum Apache SpamAssassin Spam Score required to bypass BoxTrapper:
This is the spam score threshold that is set to instruct the BoxTrapper to pass messages through the system and directly to the user when the score does not exceed the defined value. The default setting is sufficient here and should be left as is.
Enable Automatic Whitelisting:
BoxTrapper will always automatically whitelist email address that a user sends messages to, regardless of whether or not this setting is checked or unchecked, but it is recommended that this be left enabled to ensure that the system is not overly restrictive.
Automatically whitelist the To and From lines from whitelisted senders:
As with the previous setting, it is recommended that this be left enabled to ensure that the system is not overly restrictive to senders.
Edit Confirmation Messages:
These are the templates for the messages sent by the BoxTrapper upon the sender’s initial contact with the sever. There are 4 different messages that the system will send for confirmation. To review or edit these templates click on the Edit Confirmation Messages link on the main menu for the BoxTrapper.
This will bring up the follow screen with links to the 4 return message templates. Each of these templates can be edited by clicking the Edit button and they can be reset by clicking the Reset to Default button:
The BoxTrapper responds with this message when it received an email from an address not on it’s whitelist. The message requests a response from the sender to confirm the validity of the message and to add the sender to the whitelist.
The BoxTrapper responds with this message once the sender has replied to the initial verification message.
The BoxTrapper responds with this message when the verification fails.
The BoxTrapper responds with this message when a blacklisted address sends mail to it.
The following variables are used in the templates to have the system automatically fill in specific details about the specific message and the sender:
%email% – The sender’s email address.
%fromname% – The recipient’s name.
%subject% – The subject of the sender’s email.
%acct% – The recipient’s username.
%msgid% – The message ID of the sender’s email.
%headers% – The heading information of the sender’s email.
%if can_verify_web% and %endif% – These tags enclose a section that allows BoxTrapper to verify senders through a web link.
DO NOT alter the “verify#%msgid%” variable in the subject line of the message as this is necessary for the BoxTrapper to function properly.
Edit Whitelists, Blacklists, and Ignore Lists:
Every new message that is received will be checked against these lists. Email addresses on the Whitelist will be passed through the BoxTrapper and delivered. Email addresses on the Blacklist will be rejected and a notification message will be sent. Email addresses on the Ignore List will be rejected without a notification being sent. To access these lists click the Edit Whitelists, Blacklists, and Ignore Lists link on the main menu for the BoxTrapper.
Click on the corresponding link for the list to edit the blacklist, whitelist, or ignore list:
This list allows the user to add additional email addresses that whitelisted email messages will be forwarded to in addition to the primary account. Add the addresses where messages should be forwarded once they are whitelisted by the BoxTrapper and click Save.
The Review Log will show the user the email activity in BoxTrapper for the addresses that utilize this feature. To access this click the Review Log link in the main menu for the BoxTrapper:
The Review Queue will show users email that is currently pending verification through BoxTrapper and allows for the user to whitelist, blacklist, and deliver messages currently in the queue. To access this click the Review Queue link in the main menu for the BoxTrapper:
These are the systems provided by cPanel in order to combat incoming spam on the server. Having good understanding of each of these systems, their advantages and disadvantages, and their intended use can enable a server administrator to effectively combat spam without resorting to paid and 3rd party services. We would also encourage administrators to push local client level filters that users can configure locally to add an extra layer of protection to the email accounts on the server.