This article will show you how to replicate most of the functionality of a Barracuda Spam Firewall on you cPanel server. The BSF has 12 layers that messages would be process through as illustrated in the graphic below. I’ll show you how to replicate most of these steps using customizations to the Exim and Spam Assassin. This guide assumes you have a basic working knowledge of cPanel, Linux, Exim, and Spam Assassin.

I’m going to outline my steps slighly differently than on the Barracuda so you get a better idea of what steps is configured where.
Connection Management:
- Step 1 – Network Denial of Service Protection
- Step 2 – Exim Rate Control
- Step 3 – IP Reputation Analysis
- Step 4 – Recipient Verification
- Step 5 – Sender Verification
Content Scanning:
- Step 6 – Content (Virus and Spam) Scanning
- Step 7 – Fingerprint Analysis
- Step 8 – Intent Analysis
- Step 9 – Image Analysis
- Step 10 – Bayesian Analysis
- Step 11 – Rule-Based Scoring
- Step 12 – Custom Policy
The text in bold type at the start of each step comes from the Barracuda Spam Firewall Email Filtering Whitepaper
Step 1: Network Denial of Service Protection
Built on a hardened and secure operating system, the Barracuda Spam Firewall receives email on behalf of the organization, insulating the organization’s email server from receiving direct Internet connections and the associated threats.
As filtering is being done on your cPanel server there is probably not going to be any front end device on your network to do DOS prevention. If not then I would recommend trying out the script at: http://deflate.medialayer.com/
Step 2: Rate Control
Automated spam software can be used to send large amounts of email to a single email server. To protect the email infrastructure from these flood-based attacks, the Barracuda Spam Firewall counts the number of incoming connections from a particular IP address and throttles the connections once a particular threshold is exceeded.
Organizations that relay email through known servers or communicate frequently with known partners can and should add the IP addresses of those trusted relays and good email servers to the Rate Control exemption list.
There’s several things we can do to control the rate at which Exim accepts connections. At Main >> Service Configuration >> Exim Configuration Editor you want to set:
Dictionary attack protection – On
Ratelimit suspicious SMTP servers – On
SpamAssassin™: ratelimit spam score threshold – <choose a score, I use 15> # This limits the rate a an IP can send mail at to 1/hr if the sent mail scores above the value set.
Log sender rates in the exim mainlog – On
Maximum message recipients (soft limit) # This isn’t set by default
Maximum message recipients before disconnect (hard limit) # This isn’t set by default
I also suggest putting in an SMTP banner delay to help stop ratware. At At Main >> Service Configuration >> Exim Configuration Editor, click on the Advanced Editor button, then find add this line to these lines to the top box:
acl_smtp_connect = greetdelay
smtp_enforce_sync = true
Then scroll down to the begin acl section and above acl_mail: you would add these lines:
greetdelay:
accept delay = 15s
Feel free to put whatever delay you want, but keep in mind, Exim’s default timeout for sender verification checks is 30s, so if you put a longer delay than 20s in your connect, you run the risk of failing other servers’ sender verification checks to you.
To make the delay effective you also have to use the previously mentioned smtp_enforce_sync option. cPanel defaults to not configuring Exim to enforce sync. If you have “smtp_enforce_sync = false”, then even with an accept delay in the connect ACL, what will happen is that your server will still wait 15s to put up the 220 response, but it will save the input from the sender in the meantime and then run all the SMTP commands. With “smtp_enforce_sync = true”, Exim will drop the sender if they start spewing commands before getting the 220 response from you server. Any legitimate MTA will wait for a response before sending mail, it is almost always spambots that don’t wait for your server to respond after each SMTP command.
Step 3: IP Reputation Analysis
- Barracuda Reputation. Barracuda Reputation is maintained by Barracuda Central and includes a list of IP addresses of known, good senders as well as known spammers. Updates to the Barracuda IP Reputation database are delivered to the Barracuda Spam Firewall via Barracuda Energize Updates.
- External block lists. The Barracuda Spam Firewall enables administrators to take advantage of external block lists which are also known as real-time block lists (RBLs) or DNS block lists (DNSBLs). Several organizations maintain external block lists, such as spamhaus.org.
- Customer-defined policy for allowed IP addresses. The Barracuda Spam Firewall enables administrators to define a list of trusted email servers by IP address. By adding IP addresses to this list, administrators can avoid spam scanning of good email, both reducing processing requirements and eliminating the chances of false positives.
- Customer-defined policy for blocked IP addresses. The Barracuda Spam Firewall also enables administrators to define a list of bad email senders. In some cases, administrators may choose to utilize the IP block lists to restrict specific email servers as a matter of policy rather than as a matter of spam protection.
I’m not sure what the BSF does for HELO checks, but I’m including HELO checks and DNS RBL (Real-time Block List) checks into one step.
There are several settings that now need to be enabled at Main >> Service Configuration >> Exim Configuration Editor:
Blacklist: Reject remote mail sent to primary host – On
Require HELO before MAIL – On
Require remote (hostname/IP) HELO – On
Require remote (domain) HELO – On
Require RFC-compliant HELO – On # Requires a HELO to be dotted like server.domain.com instead of just ‘server’
Through trial and error, I’ve found the best RBLs to use are b.barracudacentral.org (BSF’s publicly available list), cbl.abuseat.org, combined.njabl.org, and zen.spamhaus.org. All lists are publicly usable, however with SpamHaus if you run a commercial business you will need to pay. I recommend that if you have over 1000 user accounts, you should really go ahead and use rsync to copy down the lists so that way your MX server(s) are contacting your local RBL server instead of sending all those requests out to other servers on the internet. Setting up an RBL server is beyond the scope of this article, but you can use a program called rbldnsd to do it and can use instructions at the RBL providers to get started.
To enable RBLs in cPanel, to go Exim Configuration Editor, then set:
RBL: zen.spamhaus.org – On
(I do not recommend enabling SpamCop as it falses a lot)
Next click on “Manage Custom RBLs”. We now want to add a few custom RBLS. WHM asks for the RBL name, DNS list, and Info URL. On mine server I user the following:
Your mileage may vary, but those have worked well for me, especially having b.barracuda and zen.spamhaus.
Unfortunately cPanel’s Exim isn’t built with the dnsdb lookup function so the following no reverse DNS check will not work. You an verify if your Exim is built with dnbsb with “exim -bV | grep Lookups”. If that returns a line with dnsdb in it then the no reverse check in Exim below will work, if not, tough.
<begin future use config>
Next will be a No Reverse DNS check. We will be looking up the reverse PTR for the sending IP and if it doesn’t exist then you have 3 choices, you can send a “warn message” if you just want to accept the mail but put a header into the message so you can score it with Spam Assassin, you can “drop message” if you want to just outright reject any mail from a sending IP without a reverse, or you can “defer message” which will allow the originator time to fix the problem and have their server resend the message.
If you wish to defer the message so it’s not accepted and the sender’s server logs the failure but still tries to deliver it later, then you would add the following section to the Advanced Editor under “[% ACL_RBL_BLOCK %]“, that way you can DENY using the RBL checks the IPs that don’t have reverse PTR’s AND are in an RBL.
defer message = No Reverse DNS for $sender_host_address, \
please fix your reverse PTR -- for questions email <your abuse email address>
!local_parts = abuse : postmaster
condition = ${lookup dnsdb{defer_never,ptr=$sender_host_address}{0}{1}}
If instead you wish to add a header to the message and score it with SpamAssassin instead you would add this block:
warn message = No Reverse DNS for $sender_host_address
add_header = X-No-Reverse: No Reverse PTR for $sender_host_address
!local_parts = abuse : postmaster
condition = ${lookup dnsdb{defer_never,ptr=$sender_host_address}{0}{1}}
Then in /etc/mail/spamassassin/local.cf you would add these lines to create a custom test for X-No-Reverse:
header NO_REVERSE_PTR X-No-Reverse =~ /\bPTR\b
score NO_REVERSE_PTR 1.0
<end of future use config>
Step 4: Recipient Verification
Many spammers attack email infrastructures by harvesting email addresses. The Barracuda Spam Firewall verifies the validity of recipient email addresses through multiple techniques.
- Protocol compliance. Similar to Sender Authentication, a recipient is first validated for being specified properly. An example of an enforcement policy includes, forcing RFC 821 compliance.
- Custom policies. Organizations can define their policies based on allowed recipient email addresses for which spam scanning should be disabled. They can also define their own block lists based on email addresses. Note that allow lists override block lists.
- LDAP recipient verification. Customers of Barracuda Spam Firewall models 300 and higher can choose to reject messages if the recipient email addresses do not appear in the LDAP directory.
- SMTP recipient verification. By default, the Barracuda Spam Firewall rejects messages if the downstream mail server does not accept mail for that recipient.
- Domain Keys. The Barracuda Spam Firewall enables administrators to inspect email messages for DomainKeys (DKIM) and take action when messages fail signature verifcation.
Now that the sender has given a proper HELO, they are not in a blacklist, now we need to see if the address they are sending to exists. So that you understand the importance of recipient verification, let me give you a quick example situation. Let’s say a spammer is blasting out garbage using the address john@doe.com. Without recipient verification, what will happen is that your server will accept the message regardless of whether the recipient exists and try to deliver it. If “john@doe.com” is sending to address “jane@smith.com” and the jane address doesn’t exist, your server will then generate a mailerdaemon bounce and send it back to john@doe.com. Unfortunately for the REAL john@doe.com, he is going to get a lot of these type of non-existent user messages. Exim will hold the connection open from the sender and contact your mail host to see if jane@smith.com actually exists. If she does then the message will continue to be checked in Exim (we’re still only on step 4 now), but if jane@smith.com does not exist, Exim will spit back a Recipient Verify Failed message to the sending host therefore the real John@doe.com never gets a ‘fake bounceback message’
cPanel servers can do recipient verification. The first thing to do is to go to Tweak Settings and check the value of “Initial default/catch-all forwarder destination”. It defaults to “System account” instead of “Fail”. Change this to Fail, that way mail to non-existent users will be rejected at SMTP time and recipient verification will work correctly. Do be aware though that cPanel accounts can change that option in their interface at cPanel >> Default Address.
Step 5: Sender Authentication
Declaring an invalid “from” address is a common practice by spammers. The Barracuda Spam
Firewall utilizes a number of techniques to both validate the sender as well as apply policy.
- Protocol compliance. First and foremost, the sender is validated for being specified properly. Examples of enforcement policies include, forcing RFC 821 compliance or requiring fully-qualified domain names.
- DNS lookup. To prevent senders from faking a “from” domain, a DNS lookup is performed on the sender domain to ensure that the domain exists.
- Sender spoof protection. The Barracuda Spam Firewall has the option to prevent “spoofing” of an organization’s own domain by disallowing emails using that domain name to be sent from outside the organization. Note that sender spoof protection should not be enabled if the organization sends messages from outside their internal email infrastructure (e.g., in the case of marketing bulk-mail services).
- Custom policies. Organizations can define their own allowed sender domains or email addresses. They can also define their own block lists based on sender domains or email addresses. Note that allow lists override block lists.
- Sender policy framework (SPF). SPF is a proposed standard with growing momentum, designed to prevent spoofing of email domains. SPF provides a means for organizations to declare their known email servers in their DNS records so that email recipients can validate the identity of the sender domain based on the IP address of the sending email server. The Barracuda Spam Firewall enables email administrators to block or tag messages on failed SPF checks.
Yes I know, the BSF has Sender Authentication before Recipient Verification. I prefer doing a sender verify check AFTER the recipient verify check, because otherwise, you are checking to see if senders exist when they may be sending to non-existent users on your sysem (ie. dictionary attack). By reversing their order, we’re verifying that a recipient exists before we waste a call out to the sender’s MX to see if they exist. cPanel servers have two options here to consider, the first is “Sender Verification Callouts”, the second is “Sender Verification”. I used to recommend that Sender Verification Callouts be enabled so each sender would be validated, however that now will get your server blacklisted very quickly. I do however still recommend that “Sender Verification” be enabled as that option will just verify the existence of the sending domain without verifying the specific sending email address exists in their MX server.
Next you will want to set “Blacklist: SPF Checking” to On.
Step 6: Virus Scanning
Virus Scanning takes precedence over all other Mail Scanning techniques and is applied even when mail passes through the Connection Management layers. As such, even email coming from “whitelisted” IP addresses, sender domains, sender email addresses or recipients are still scanned for viruses and blocked if a virus is detected.
This section will give you MIME checking, file extension blocking, virus scanning, and spam filtering. I used Clam Antivirus because it’s free and I’m familiar with it. You can certainly use whichever one you wish. What you’ll need to do is first uncomment these 2 lines in your Exim.conf:
In WHM, go to Main >> cPanel >> Manage Plugins, then check the box “Install and keep updated ” next to ClamAV and click save, that will then install ClamAntivirus and configure Exim to use it.
The next thing is back at the Exim Configuration page, you want to enable the options to do attachment and mime scanning:
System Filter File – /etc/cpanel_exim_system_filter
Attachments: Filter messages with dangerous attachments – On
Step 7: Custom Policy (User Specified Rules)
Administrators can choose to define their own policies, perhaps for compliance or governance reasons, which take precedence over spam blocking rules delivered to the system automatically through Barracuda Energize Updates. The Barracuda Spam Firewall enables administrators to set custom content filters based on the subject, message headers, message bodies and attachment file type. In general, administrators do not need to set their own filters for the purposes of blocking spam, as these forms of rules are delivered to Barracuda Spam Firewalls automatically through Barracuda Energize Updates.
In this section I would recommend that you reject messages that score greater than 15. I’ve found 15 is a good value as I’ve not seen any legitimate mail score over 10. I recommend the following:
SpamAssassin™ reject spam score threshold – 15
Automatically whitelist known mobile device providers – On
There are several Access Lists that you can use to put IPs in to bypass certain checks:
Blacklisted SMTP IPs
# IPs from which SMTP connections are dropped unconditionally
Sender verification bypass IPs
# IPs for which to bypass SMTP-time sender verification checks
Only-verify-recipient SMTP hosts/IPs
# Hosts/IPs for which to bypass all SMTP-time checks except recipient verification
Trusted SMTP IPs
#IPs for which to bypass all SMTP-time recipient/sender/spam/relay checks
Backup MX hosts
# Hosts with reverse DNS from which connections are allowed regardless of rate limits.
Step 8: Fingerprint Analysis
A message “fingerprint” is based on commonly used message components (e.g., an image) across many instances of spam. Fingerprint analysis is often as a useful mechanism to block future instances of spam once an early outbreak is identified. Engineers at Barracuda Central work around the clock to identify new spam fingerprints which are then updated on all Barracuda Spam Firewalls through hourly Barracuda Energize Updates.
There’s several different plugins for Spam Assassin that check against a database of messages reported as spam. We’ll be setting up DCC, Pyzor, Razor, and iXhash. All of those plugins will need to be installed from source as they are not available in the CentOS / Red Hat repositories and cPanel doesn’t support third party repositories.
DCC -Distributed Checksum Clearinghouses
cd /usr/local/src
wget http://www.rhyolite.com/dcc/source/dcc.tar.Z
tar -zxvf dcc.tar.Z
cd dcc-1.3.141
./configure
make
make install
Uncomment “loadplugin Mail::SpamAssassin::Plugin::DCC” in /etc/mail/spamassassin/v310.pre
Add these 2 lines to /etc/mail/spamassassin/local.cf:
use_dcc 1
dcc_timeout 10
Pyzor – collaborative, networked system to detect and block spam using identifying digests of messages
cd /usr/local/src
(wget it from sourceforge.net)
tar -zxvf pyzor*.tar.gz
cd pyzor-0.5.0
python setup.py build
python setup.py install
/usr/bin/pyzor discover
You can verify pyzor is able to contact it’s server with the command “/usr/bin/pyzor ping” which should return “public.pyzor.org:24441 (200, ‘OK’)”
Uncomment “loadplugin Mail::SpamAssassin::Plugin::Pyzor” in /etc/mail/spamassassin/v310.pre
Add these 2 lines to /etc/mail/spamassassin/local.cf:
use_pyzor 1
Razor – distributed, collaborative, spam detection and filtering network
cd /usr/local/src
(wget it from sourceforge.net)
tar -jxvf razor-agents*.bz2
cd razor-agents-2.84
perl Makefile.PL
make
make test
make install
Uncomment “loadplugin Mail::SpamAssassin::Plugin::Razor2” in /etc/mail/spamassassin/v310.pre
Nothing needs to be added to local.cf for this.
iXhash – Similar in function to the above plugins
cd /usr/local/src
(wget it from sourceforge.net)
tar -zxvf ihash*.tgz
cd iXhash-1.5.5
cp iXhash/iXhash.cf /etc/mail/spamassassin
cp iXhash/iXhash.pm /etc/mail/spamassassin
spamassassin -D IXHASH < iXhash.eml # This will test to see if it works, look for IXHASH in the X-Spam-Status line
Put the following into /etc/mail/spamassassin/local.cf:
loadplugin Mail::SpamAssassin::Plugin::iXhash /etc/mail/spamassassin/iXhash.pm
body GENERIC_IXHASH eval:ixhashtest(‘generic.ixhash.net’)
describe GENERIC_IXHASH iXhash found @ generic.ixhash.net
tflags GENERIC_IXHASH net
# adjust score as you seem fit
score GENERIC_IXHASH 2
body NIXSPAM_IXHASH eval:ixhashtest(‘ix.dnsbl.manitu.net’)
describe NIXSPAM_IXHASH iXhash found @ ix.dnsbl.manitu.net
tflags NIXSPAM_IXHASH net
# adjust score as you seem fit
score NIXSPAM_IXHASH 2
Step 9: Intent Analysis
All spam messages have an “intent” – to get a user to reply to an email, visit a Web site or call a phone number. Intent analysis involves researching email addresses, Web links and phone numbers embedded in email messages to determine whether they are associated with legitimate entities. Frequently, Intent Analysis is the defense layer that catches phishing attacks. The Barracuda Spam Firewall features multiple forms of Intent Analysis.
- Intent analysis. Markers of intent, such as URLs, are extracted and compared against a database maintained by Barracuda Central, and then delivered to the Barracuda Spam Firewall via hourly Barracuda Energize Updates.
- Real-time intent analysis. For new domain names that may come into use, Real-Time Intent Analysis involves performing DNS lookups against known URL block lists.
- Multilevel intent analysis. Use of free Web sites to redirect to known spammer Web sites is a growing practice used by spammers to hide or obfuscate their identity from mail scanning techniques such as Intent Analysis. Multilevel Intent Analysis involves inspecting the results of Web queries to URLs of well-known free Web sites for redirections to known spammer sites.
Intent analysis is done with the URIDNSBL plugin. URIDNSBL looks up URLs found in the message against several DNS blocklists. cPanel already enables this option in /etc/mail/spamassassin/local.cf.
Step 10: Image Analysis
Today, image spam represents about one third of all traffic on the Internet. While Fingerprint Analysis captures a significant percentage of images after they have been seen, the Barracuda Spam Firewall also uses Image Analysis techniques which protect against new image variants. These techniques include:
- Optical character recognition (OCR). Embedding text in images is a popular spamming practice to avoid text processing in anti-spam engines. OCR enables the Barracuda Spam Firewall to analyze the text rendered inside the images.
- Image processing. To mitigate attempts by spammers to foil OCR through speckling, shading or color manipulation, the Barracuda Spam Firewall also utilizes a number of lightweight image processing technologies to normalize the images prior to the OCR phase. More heavyweight image processing algorithms are utilized at Barracuda Central to quicklygenerate fingerprints that can be used by Barracuda Spam Firewalls to block messages.
- Animated GIF analysis. In addition, the Barracuda Spam Firewall contains specialized algorithms for analyzing animated GIFs for suspect content.
There are several plugins to do this, I used to use fuzzy_ocr, but it’s no longer maintained. Other plugins that looks to be active haven’t been updated in several years either.
Step 11: Bayesian Analysis
Bayesian Analysis is a linguistic algorithm that profiles language used in both spam messages and legitimate email for any particular user or organization. To determine the likelihood that a new email is spam, Bayesian Analysis compares the words and phrases used in the new email against the corpus of previously identified email.
To get bayesian filtering working you first need to add the following lines in /home/user/.spamassassin/user_prefs:
bayes_ignore_header X-MailScanner
bayes_ignore_header X-MailScanner-Information
bayes_ignore_header X-MailScanner-SpamCheck
bayes_ignore_header X-MailScanner-SpamScore
use_bayes 1
You may also then want to adjust the scores for BAYES_95 and BAYES_99 so that mail that has such a large percentage chance of being SPAM is scored higher:
score BAYES_95 5
score BAYES_99 7
Now you need to go to http://iandouglas.com/sa-trainer/ and put in your cPanel account username and domain name. This will create a script you run to train the spam filter, updating the bayesian token database. You can put it in /home/user/bin and then add a cron job through cPanel to run the command daily. For your IMAP accounts, if you put SPAM mail that isn’t caught and tagged with ***SPAM*** in a folder called ‘SPAM’ and mail that is tagged but shouldn’t be in ‘HAM’, the script will then use those messages to train the filter so it performs better.
Step 12: Rule-based Scoring
Beyond absolute blocks that a single filter can apply, the Barracuda Spam Firewall also includes a sophisticated scoring engine that weighs multiple factors where a single filter may result into restrictive policy. By combining multiple rules with known weightings, the Barracuda Spam Firewall can deliver a strong confidence interval for spam messages. The Barracuda Spam Firewall enables administrators to set global spam scores. Certain models of the Barracuda Spam Firewall also support per domain and per user thresholds.
Spam Assassin custom plugins and tests can be enabled by editing /etc/mail/spamassassin/local.cf. You can also set custom scores in the same file. For cPanel users themselves, they can adjust scores by adding the proper line to /home/user/.spamassassin/user_prefs, but they cannot enable a plugin that way or add custom tests.