General information

SPAM mitigation tools in DirectAdmin

DirectAdmin has a variety of features and options that can help you filter and block spam, both for incoming and outgoing messages.

  1. The most common tool that is enabled to filter incoming spam, is SpamAssassin. We recommend letting CustomBuild install it for you, but still require you to ensure that all perl/cpan modules are present first.

  2. To keep outbound email in check, we recommend limits on both a per-DA-User basis (/etc/virtual/limit) and per-Email basis (/etc/virtual/user_limit).

  3. Exim can use a feature called RBL Blocking which scans public blocklists for sending IPs that have recently been known for sending spam. Some consider this a bit too aggressive, as this will reject all emails from IPs that are in these lists.

Note that SpamAssassin in (#1) also checks these lists, but gives them a score in consideration with many other things, so only use RBLs via Exim if SpamAssassin alone can't keep up.

  1. "User Level -> SPAM Filters" are a very basic Exim filter that lets you drop messages which Exim has already accepted. This is less effective for general spam, but can be handy if a message is always getting through when it contains one specific word you don't like, or simple blocks of that nature.

Note that Exim itself can be customized via /home/user/.spamassassin/user_prefs to have extra custom rules or score changes, which is an alternative way of blocking words.

  1. Newer versions of the exim.conf SpamBlockeropen in new window with better tricks/filters is also recommended.

Points (#6)open in new window and (#7)open in new window refer to SpamBlocker modules for exim.conf 4.3.1+.

  1. Easy Spam Fighteropen in new window is a tool for exim.conf 4.3.1+ that combines the score of SpamAssassin, in addition to other important checks like SPF, DKIM, reverse IP, etc.. to block email at smtp-time, so Exim never accepts the spam.

  2. BlockCrackingopen in new window is a tool for exim.conf 4.3.1+ that monitors outbound emails from your accounts/scripts. It counts the number of failed addresses that a given item (account or script path) has sent to. The logic is that spammers will typically blast out to accounts that often don't exist, as they don't check the list to ensure it's valid.

  3. General PHP security is important for your PHP scripts. See tip #2 from the Basic System Security guide, So that poorly written PHP scripts have an extra layer of security, disable functions that are too powerful for hackers.

SpamBlocker install and extra modules

Newer versions of SpamBlockeropen in new window support several new features, giving you more control to prevent spam, both inbound and outbound.

Many of the changes are listed hereopen in new window.

Click for more info on easy_spam_fighter (ESF)open in new window and BlockCracking (BC)open in new window.

If you're running CustomBuild 2.0, it can install these things for you:

cd /usr/local/directadmin/custombuild
./build update
./build set eximconf yes
./build set blockcracking yes
./build set easy_spam_fighter yes
./build set spamd rspamd
./build set exim yes
./build exim
./build set dovecot_conf yes
./build dovecot_conf
./build rspamd
./build update
./build exim_conf

Where we recommend recompiling Exim before doing

./build exim_conf

to ensure it has SRS compiled in.

SpamAssassin can also be somewhat tricky to install, so we also recommend that before installing EasySpamFighter (which requires SpamAssassin to be running).

Custom Variables

The 4.3.0+ version of SpamBlocker supports custom variables and custom strings.

  1. Custom strings (text shown in smtp output) should be taken from:

/etc/exim.strings.conf

and for any changes you want to overwrite, add your desired changes to

/etc/exim.strings.conf.custom

Do not edit the exim.strings.conf directly.

Also, the exim.strings.conf.custom MUST use == instead of = for its values, to let Exim know that we want to overwrite the defaults. It will error out if you use a single = character for a string when it's already been set.

  1. Custom variables (changes to the Exim behavior/functionality) should be added to:

/etc/exim.variables.conf.custom

They can be values that already exist in /etc/exim.variables.conf.default, or extra variables from the top section of the /etc/exim.conf. Once you've set your exim.variables.conf.custom, they need to be merged into /etc/exim.variables.conf by using:

./build exim_conf

We used he merge method because Exim does not allow a variable to be set twice (== does not work), and also because we may want to add more default variables in the future, but still allow you to overwrite the values you want.

It's important to use the correct method of customizing the data, so that your changes remain when the exim.conf rewrite happens.

Last Updated: