Rev 67 | Details | Compare with Previous | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
6 | magnus | 1 | ******************************** |
2 | * SHOULD YOU USE THIS PACKAGE? * |
||
3 | ******************************** |
||
4 | |||
5 | Since version 4.50, Exim has the content-scanning extension formerly |
||
6 | known as "exiscan" built-in. It has a number of advantages and |
||
7 | disadvantages compared to SA-Exim. |
||
8 | |||
9 | Advantages of built-in content-scanning interface: |
||
10 | |||
11 | * One less configuration file to edit. |
||
12 | * Spam control policy integrates better with Exim's ACL system. |
||
13 | * It's possible to tell SA which user to scan for (the -u parameter of |
||
14 | spamc). SA-Exim can't do that (yet). |
||
15 | * Finer control over the mail header is possible, but not in a clean |
||
16 | way (it involves putting all header fields you might possibly want |
||
17 | to add in the report template, and using rather complicated |
||
18 | expansion expressions to extract the wanted ones from |
||
19 | $spam_report). At any rate, you can choose a prefix different from |
||
20 | "X-Spam-". |
||
21 | |||
22 | Advantages of SA-Exim: |
||
23 | |||
24 | * It is possible to use the report_safe feature, which turns mail |
||
25 | deemed to be spam into a message/rfc822 attachment of a report |
||
26 | message. (Note however that if you do, then any X-SA-* fields added |
||
27 | to help the greylisting module can't be removed.) |
||
28 | * All the add_header and rewrite_header options in |
||
29 | /etc/spamassassin/local.cf will be obeyed. In other words, |
||
30 | everything will be *almost* as if you filtered the mail through |
||
31 | spamassassin on the command line. |
||
32 | * So-called teergrubing ("tarpitting") is possible in a way that |
||
33 | isn't possible with exiscan (I'm not in any way saying that it |
||
34 | works as a counterattack against spammers). |
||
35 | * You can simply add the sa-exim package to a standard exim4 |
||
36 | installation and it should, in principle, instantly work (except |
||
37 | you have to uncomment one line in sa-exim.conf). |
||
38 | |||
39 | Both alternatives enable you to defer, greylist, reject, and blackhole |
||
40 | mail, optionally saving copies, at configurable score levels. |
||
41 | |||
1 | magnus | 42 | ***************** |
43 | * CONFIGURATION * |
||
44 | ***************** |
||
45 | |||
46 | This version of the sa-exim package defaults to placing a configuration |
||
47 | sniplet in /etc/exim4/conf.d/. Depending on what you have answered to the |
||
48 | DebConf questions while configuring Exim4, the module will be loaded |
||
49 | automatically, or human intervention is required. |
||
50 | |||
6 | magnus | 51 | To find out what configuration file Exim4 is using, issue: |
1 | magnus | 52 | |
53 | $ exim4 -bV | tail -1 |
||
54 | Configuration file is /path/to/configfile |
||
55 | |||
56 | If /path/to/configfile shows: |
||
57 | |||
58 | - /etc/exim4/exim4.conf |
||
6 | magnus | 59 | You are using the hand-crafted configuration file. |
60 | See the 'HAND-CRAFTED' section below. |
||
1 | magnus | 61 | |
62 | - /var/lib/exim4/config.autogenerated |
||
6 | magnus | 63 | You are using the debianized configuration scheme - with either |
64 | 'split' or 'unsplit' configuration file. |
||
65 | See the 'DEBIANIZED' section below. |
||
1 | magnus | 66 | |
67 | |||
6 | magnus | 68 | HAND-CRAFTED |
69 | ------------ |
||
1 | magnus | 70 | |
71 | Use 'grep "local_scan_path" /etc/exim4/exim4.conf" to see if the sa-exim |
||
72 | line is included in the configuration. If grep returns something, check |
||
73 | if it matches the following line. If grep returns nothing, you have to |
||
74 | manually add the following line to the exim4.conf file and restart exim4. |
||
75 | |||
76 | local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so |
||
77 | |||
78 | Change or add the line above and manually restart exim4 by issuing |
||
6 | magnus | 79 | 'invoke-rc.d exim4 reload' or '/etc/init.d/exim4 reload' as root. |
1 | magnus | 80 | |
81 | |||
6 | magnus | 82 | DEBIANIZED |
83 | ---------- |
||
1 | magnus | 84 | |
6 | magnus | 85 | Use 'grep "local_scan_path" /var/lib/exim4/config.autogenerated' to |
86 | see if the sa-exim line is included in the configuration. If grep |
||
87 | returns something, you're set and already using the sa-exim module. If |
||
88 | grep returns nothing, we need to figure out a few things: |
||
1 | magnus | 89 | |
90 | Issue: |
||
91 | $ grep "use_split_config" /etc/exim4/update-exim4.conf.conf |
||
92 | dc_use_split_config='true' |
||
93 | |||
6 | magnus | 94 | If your result shows 'false' where mine shows 'true', then you're |
95 | using the unsplit configuration, generated from |
||
96 | /etc/exim4/exim4.conf.template. If you haven't customized that file |
||
97 | you could edit /etc/exim4/update-exim4.conf.conf by hand, change the |
||
98 | 'false' to 'true' and issue 'update-exim4.conf' as root. Then, check |
||
99 | again if the sa-exim module line is included. It should. If it still |
||
100 | isn't: mail me. If it is, restart exim4 by issuing 'invoke-rc.d exim4 |
||
101 | restart' or '/etc/init.d/exim4 restart' as root. If you *have* |
||
102 | customized /etc/exim4/exim4.conf.template, then you'd better stick |
||
103 | with the unsplit configuration scheme and add the local_scan_path |
||
104 | setting by hand, like with the hand-crafted configuration file. |
||
1 | magnus | 105 | |
106 | |||
107 | *************** |
||
108 | * GREYLISTING * |
||
109 | *************** |
||
110 | |||
67 | magnus | 111 | Greylisting is implemented as a SpamAssassin module. To enable it you |
112 | need to add the following five lines to your SpamAssassin |
||
113 | configuration: |
||
1 | magnus | 114 | |
67 | magnus | 115 | loadplugin Greylisting /usr/share/perl5/Mail/SpamAssassin/Plugin/Greylisting.pm |
116 | |||
117 | 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 )") |
||
118 | describe GREYLIST_ISWHITE The incoming server has been whitelisted for this recipient and sender |
||
119 | score GREYLIST_ISWHITE -1.5 |
||
120 | priority GREYLIST_ISWHITE 99999 |
||
121 | |||
122 | (It is a long-standing bug that the module is installed in the wrong |
||
123 | directory, which is why the full path has to be specified on the |
||
124 | loadplugin line, but fixing it is probably not worth the disruption of |
||
125 | existing installations.) |
||
126 | |||
76 | magnus | 127 | If two messages from the same /24 IPv4 network or /64 IPv6 network (or |
128 | individual IP address, depending on greylistfourthbyte), with the same |
||
129 | sender, with the same list of recipient, and with a score below |
||
130 | dontgreylistthreshold are seen at least greylistsecs apart, the |
||
131 | triplet will be whitelisted and the GREYLIST_ISWHITE rule will be |
||
132 | considered to match thenceforth. That will signal to the local_scan |
||
133 | library to raise SAtempreject to let the message through, in addition |
||
134 | to the negative spam score it carries. |
||
67 | magnus | 135 | |
136 | Notice that messages can be permanently rejected (score above |
||
137 | SApermreject) and still get a triplet whitelisted if the score is |
||
138 | below dontgreylistthreshold. If dontgreylistthreshold or SAtempreject |
||
139 | + SAgreylistraisetempreject are less than SApermreject, some mail may |
||
140 | be temporarily rejected indefinitely. |
||
141 | |||
142 | See README.Greylisting for more details. |
||
143 | |||
144 | *********************** |
||
145 | * SPAMD CONFIGURATION * |
||
146 | *********************** |
||
147 | |||
148 | By default, spamd runs as root and assumes the identity of the user it |
||
149 | is told it is scanning mail on behalf of by whoever connects to it |
||
150 | (see README.spamd.gz in the spamassassin package for a discussion on |
||
151 | security). When SA-Exim runs spamc, this user will normally be |
||
152 | Debian-exim. You can set the SAspamcUser option in sa-exim.conf to |
||
153 | override this, but since a mail can have multiple recipients and is |
||
154 | only scanned once, per-user setups are problematic. Also, the |
||
155 | greylisting module won't work unless all users can write to the |
||
156 | tuplets directory. |
||
157 | |||
158 | Thus, when using SpamAssassin together with SA-Exim you may want to |
||
159 | run spamd under a specific system account by modifying the OPTIONS |
||
160 | variable in /etc/default/spamassassin to include a --username option. |
||
161 | However, if you ONLY use SpamAssassin with SA-Exim this is in practice |
||
162 | not strictly necessary. |
||
163 | |||
164 | You should NOT run spamd as the "nobody" user and/or the "nogroup" |
||
165 | group if you configure SpamAssassin to use sa-exim's greylisting |
||
166 | module, the bayesian classifier, or any helper module that needs to |
||
167 | write files, because nobody/nogroup should be completely unprivileged |
||
168 | and thus not own any files. Instead you should create a dedicated |
||
169 | account to run spamd under. You can then adjust the ownership of |
||
170 | /var/spool/sa-exim/tuplets and the username in |
||
171 | /etc/cron.d/greylistclean accordingly. |
||
172 | |||
46 | magnus | 173 | *********************************** |
174 | * PROBLEMS WITH BAYES AUTO-EXPIRY * |
||
175 | *********************************** |
||
1 | magnus | 176 | |
46 | magnus | 177 | When scanning mail during the SMTP dialogue there is somewhat limited |
178 | time before the remote host gives up, even if they should wait for at |
||
179 | least ten minutes. To avoid Exim returning a temporary error status, |
||
180 | or the remote host giving up prematurely and in some cases for good, |
||
181 | SA-Exim overrides Exim's timeout handler and accepts the message if |
||
182 | SpamAssassin takes too long, by default 240 seconds. |
||
1 | magnus | 183 | |
46 | magnus | 184 | Using SpamAssassin's Bayesian learning module means that it will |
185 | automatically expire old tokens when its database has grown too large. |
||
186 | That can take several minutes. If it takes too long, SA-Exim will |
||
187 | abort it, meaning that SpamAssassin will run auto-expiry again next |
||
188 | time, and be aborted, and so on... |
||
1 | magnus | 189 | |
46 | magnus | 190 | If this happens, you have a few remedies: |
1 | magnus | 191 | |
46 | magnus | 192 | 1) Set SAtimeout to a higher value in /etc/exim4/sa-exim.conf. |
1 | magnus | 193 | |
46 | magnus | 194 | 2) Run sa-learn --force-expire periodically. How you run it depends on |
195 | how you've configured SpamAssassin. Running it as Debian-exim may |
||
196 | be sufficient. |
||
1 | magnus | 197 | |
46 | magnus | 198 | 2 a) In addition, you can add |
1 | magnus | 199 | |
46 | magnus | 200 | bayes_auto_expire 0 |
1 | magnus | 201 | |
46 | magnus | 202 | to /etc/spamassassin/local.cf. This may not be a good idea if |
203 | SpamAssassin, for whatever reason, is also used as a more |
||
204 | traditional filter from e.g. .procmailrc, as all users will need to |
||
205 | run sa-learn --force-expire then. |
||
1 | magnus | 206 | |
46 | magnus | 207 | 2 b) If you get a lot of mail, consider adding |
6 | magnus | 208 | |
46 | magnus | 209 | bayes_learn_to_journal 1 |
6 | magnus | 210 | |
46 | magnus | 211 | to local.cf. See the Mail::SpamAssassin::Conf(3) manual page for |
212 | more information. |
||
213 | |||
6 | magnus | 214 | ********************************** |
215 | * NOTICE ABOUT SPAMC CONFIG FILE * |
||
216 | ********************************** |
||
217 | |||
218 | Recent versions of spamc can read command-line parameters and switches |
||
219 | from a configuration file called /etc/spamassassin/spamc.conf. If that |
||
220 | file specifies conflicting options, it will prevent SA-Exim from |
||
221 | working. For now, you'll have to make sure that it doesn't. |
||
46 | magnus | 222 | |
76 | magnus | 223 | -- Magnus Holmgren <holmgren@debian.org>, Fri, 22 Jul 2016 09:58:32 +0200 |