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.
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.
To keep outbound email in check, we recommend limits on both a per-DA-User basis (
/etc/virtual/limit) and per-Email basis (
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.
- "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.
- Newer versions of the exim.conf SpamBlockeropen in new window with better tricks/filters is also recommended.
Easy Spam Fighteropen in new window is a tool for
exim.conf4.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.
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.
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.
If you're running CustomBuild 2.0, it can install these things for you (please make sure pre-requisites for SpamAssassin are installed before executing the commands below):
cd /usr/local/directadmin/custombuild ./build update ./build set eximconf yes ./build set eximconf_release 4.5 ./build set blockcracking yes ./build set easy_spam_fighter yes ./build set spamd spamassassin ./build set exim yes ./build exim ./build set dovecot_conf yes ./build dovecot_conf ./build spamassassin ./build update ./build exim_conf
Where we recommend recompiling Exim before doing
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).
The 4.3.0+ version of SpamBlocker supports custom variables and custom strings.
- Custom strings (text shown in smtp output) should be taken from:
and for any changes you want to overwrite, add your desired changes to
Do not edit 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.
- Custom variables (changes to the Exim behavior/functionality) should be added to:
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:
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.