******************************** * SHOULD YOU USE THIS PACKAGE? * ******************************** Since version 4.50, Exim has the content-scanning extension formerly known as "exiscan" built-in. It has a number of advantages and disadvantages compared to SA-Exim. Advantages of built-in content-scanning interface: * One less configuration file to edit. * Spam control policy integrates better with Exim's ACL system. * It's possible to tell SA which user to scan for (the -u parameter of spamc). SA-Exim can't do that (yet). * Finer control over the mail header is possible, but not in a clean way (it involves putting all header fields you might possibly want to add in the report template, and using rather complicated expansion expressions to extract the wanted ones from $spam_report). At any rate, you can choose a prefix different from "X-Spam-". Advantages of SA-Exim: * It is possible to use the report_safe feature, which turns mail deemed to be spam into a message/rfc822 attachment of a report message. (Note however that if you do, then any X-SA-* fields added to help the greylisting module can't be removed.) * All the add_header and rewrite_header options in /etc/spamassassin/local.cf will be obeyed. In other words, everything will be *almost* as if you filtered the mail through spamassassin on the command line. * So-called teergrubing ("tarpitting") is possible in a way that isn't possible with exiscan (I'm not in any way saying that it works as a counterattack against spammers). * You can simply add the sa-exim package to a standard exim4 installation and it should, in principle, instantly work (except you have to uncomment one line in sa-exim.conf). Both alternatives enable you to defer, greylist, reject, and blackhole mail, optionally saving copies, at configurable score levels. ***************** * CONFIGURATION * ***************** This version of the sa-exim package defaults to placing a configuration sniplet in /etc/exim4/conf.d/. Depending on what you have answered to the DebConf questions while configuring Exim4, the module will be loaded automatically, or human intervention is required. To find out what configuration file Exim4 is using, issue: $ exim4 -bV | tail -1 Configuration file is /path/to/configfile If /path/to/configfile shows: - /etc/exim4/exim4.conf You are using the hand-crafted configuration file. See the 'HAND-CRAFTED' section below. - /var/lib/exim4/config.autogenerated You are using the debianized configuration scheme - with either 'split' or 'unsplit' configuration file. See the 'DEBIANIZED' section below. HAND-CRAFTED ------------ Use 'grep "local_scan_path" /etc/exim4/exim4.conf" to see if the sa-exim line is included in the configuration. If grep returns something, check if it matches the following line. If grep returns nothing, you have to manually add the following line to the exim4.conf file and restart exim4. local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so Change or add the line above and manually restart exim4 by issuing 'invoke-rc.d exim4 reload' or '/etc/init.d/exim4 reload' as root. DEBIANIZED ---------- Use 'grep "local_scan_path" /var/lib/exim4/config.autogenerated' to see if the sa-exim line is included in the configuration. If grep returns something, you're set and already using the sa-exim module. If grep returns nothing, we need to figure out a few things: Issue: $ grep "use_split_config" /etc/exim4/update-exim4.conf.conf dc_use_split_config='true' If your result shows 'false' where mine shows 'true', then you're using the unsplit configuration, generated from /etc/exim4/exim4.conf.template. If you haven't customized that file you could edit /etc/exim4/update-exim4.conf.conf by hand, change the 'false' to 'true' and issue 'update-exim4.conf' as root. Then, check again if the sa-exim module line is included. It should. If it still isn't: mail me. If it is, restart exim4 by issuing 'invoke-rc.d exim4 restart' or '/etc/init.d/exim4 restart' as root. If you *have* customized /etc/exim4/exim4.conf.template, then you'd better stick with the unsplit configuration scheme and add the local_scan_path setting by hand, like with the hand-crafted configuration file. *************** * GREYLISTING * *************** Greylisting is implemented as a SpamAssassin module. To enable it you need to add the following five lines to your SpamAssassin configuration: loadplugin Greylisting /usr/share/perl5/Mail/SpamAssassin/Plugin/Greylisting.pm header GREYLIST_ISWHITE eval:greylisting("( 'dir' => '/var/spool/sa-exim/tuplets'; 'method' => 'dir'; 'greylistsecs' => '1800'; 'dontgreylistthreshold' => 11; 'connectiphdr' => 'X-SA-Exim-Connect-IP'; 'envfromhdr' => 'X-SA-Exim-Mail-From'; 'rcpttohdr' => 'X-SA-Exim-Rcpt-To'; 'greylistnullfrom' => 1; 'greylistfourthbyte' => 0 )") describe GREYLIST_ISWHITE The incoming server has been whitelisted for this recipient and sender score GREYLIST_ISWHITE -1.5 priority GREYLIST_ISWHITE 99999 (It is a long-standing bug that the module is installed in the wrong directory, which is why the full path has to be specified on the loadplugin line, but fixing it is probably not worth the disruption of existing installations.) If two messages from the same /24 IPv4 network or /64 IPv6 network (or individual IP address, depending on greylistfourthbyte), with the same sender, with the same list of recipient, and with a score below dontgreylistthreshold are seen at least greylistsecs apart, the triplet will be whitelisted and the GREYLIST_ISWHITE rule will be considered to match thenceforth. That will signal to the local_scan library to raise SAtempreject to let the message through, in addition to the negative spam score it carries. Notice that messages can be permanently rejected (score above SApermreject) and still get a triplet whitelisted if the score is below dontgreylistthreshold. If dontgreylistthreshold or SAtempreject + SAgreylistraisetempreject are less than SApermreject, some mail may be temporarily rejected indefinitely. See README.Greylisting for more details. *********************** * SPAMD CONFIGURATION * *********************** By default, spamd runs as root and assumes the identity of the user it is told it is scanning mail on behalf of by whoever connects to it (see README.spamd.gz in the spamassassin package for a discussion on security). When SA-Exim runs spamc, this user will normally be Debian-exim. You can set the SAspamcUser option in sa-exim.conf to override this, but since a mail can have multiple recipients and is only scanned once, per-user setups are problematic. Also, the greylisting module won't work unless all users can write to the tuplets directory. Thus, when using SpamAssassin together with SA-Exim you may want to run spamd under a specific system account by modifying the OPTIONS variable in /etc/default/spamassassin to include a --username option. However, if you ONLY use SpamAssassin with SA-Exim this is in practice not strictly necessary. You should NOT run spamd as the "nobody" user and/or the "nogroup" group if you configure SpamAssassin to use sa-exim's greylisting module, the bayesian classifier, or any helper module that needs to write files, because nobody/nogroup should be completely unprivileged and thus not own any files. Instead you should create a dedicated account to run spamd under. You can then adjust the ownership of /var/spool/sa-exim/tuplets and the username in /etc/cron.d/greylistclean accordingly. *********************************** * PROBLEMS WITH BAYES AUTO-EXPIRY * *********************************** When scanning mail during the SMTP dialogue there is somewhat limited time before the remote host gives up, even if they should wait for at least ten minutes. To avoid Exim returning a temporary error status, or the remote host giving up prematurely and in some cases for good, SA-Exim overrides Exim's timeout handler and accepts the message if SpamAssassin takes too long, by default 240 seconds. Using SpamAssassin's Bayesian learning module means that it will automatically expire old tokens when its database has grown too large. That can take several minutes. If it takes too long, SA-Exim will abort it, meaning that SpamAssassin will run auto-expiry again next time, and be aborted, and so on... If this happens, you have a few remedies: 1) Set SAtimeout to a higher value in /etc/exim4/sa-exim.conf. 2) Run sa-learn --force-expire periodically. How you run it depends on how you've configured SpamAssassin. Running it as Debian-exim may be sufficient. 2 a) In addition, you can add bayes_auto_expire 0 to /etc/spamassassin/local.cf. This may not be a good idea if SpamAssassin, for whatever reason, is also used as a more traditional filter from e.g. .procmailrc, as all users will need to run sa-learn --force-expire then. 2 b) If you get a lot of mail, consider adding bayes_learn_to_journal 1 to local.cf. See the Mail::SpamAssassin::Conf(3) manual page for more information. ********************************** * NOTICE ABOUT SPAMC CONFIG FILE * ********************************** Recent versions of spamc can read command-line parameters and switches from a configuration file called /etc/spamassassin/spamc.conf. If that file specifies conflicting options, it will prevent SA-Exim from working. For now, you'll have to make sure that it doesn't. -- Magnus Holmgren , Fri, 22 Jul 2016 09:58:32 +0200