Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
1 | magnus | 1 | COPYRIGHTS |
2 | ---------- |
||
3 | SA-Exim was written by Marc MERLIN <marc_soft@merlins.org> |
||
4 | You can find the latest version here: |
||
5 | http://sa-exim.sf.net/ |
||
6 | or here: |
||
7 | http://marc.merlins.org/linux/exim/sa.html |
||
8 | |||
9 | greylisting was written by and is copyright Mark Lawrence <nomad@null.net> |
||
10 | |||
11 | |||
12 | INSTALL |
||
13 | ------- |
||
14 | See the file named INSTALL for installations instructions (either compiled |
||
15 | in exim, or as a stand-alone shared library) |
||
16 | |||
17 | If you got sa-exim prepackaged (like on debian), you have to make sure that |
||
18 | your exim supports a dynamically loadable local_scan (which is true on debian |
||
19 | and probably on other distros too if they shipped sa-exim as a package), and |
||
20 | that your exim4.conf file contains the following: |
||
21 | local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so |
||
22 | If you are using the split configuration file on debian with the sa-exim deb |
||
23 | package, you'll be fine. If you're using the monolithic file, you are on your |
||
24 | own until/unless the sa-exim packages try to do an in place edit (i.e. you have |
||
25 | to add the above configuration line yourself) |
||
26 | |||
27 | |||
28 | UPGRADING |
||
29 | --------- |
||
30 | Deleting greylisting tuplets pre-4.2.1: |
||
31 | If you are installing this package yourself, and ever installed the old |
||
32 | greylistclean.cron which contained the complicated shell commands to clean |
||
33 | old tuplets, you should stop using those commands and upgrade to greylistclean. |
||
34 | Upgrading Greylisting.pm should also create safer tuplets without whitespace, |
||
35 | but it's better to get rid of the old shell cron jobs either way |
||
36 | |||
37 | |||
38 | PRIVACY WARNING |
||
39 | --------------- |
||
40 | SA-Exim can add a header with the list of recipients in an Email (including |
||
41 | Bcced folks). |
||
42 | X-SA-Exim-Rcpt-To is used to allow you to see who a spam went to easily (i.e. |
||
43 | without scanning the exim logs), and to write SpamAssassin rules on the envelope |
||
44 | To (like adding a score if there were too many recipients or a recipient who you |
||
45 | know only receives spam) |
||
46 | X-SA-Exim-Rcpt-To is not added anymore by default, you need to enable it by |
||
47 | setting SAmaxrcptlistlength to a value up to 8000, but if you do add it, |
||
48 | you should consider removing it in exim's system_filter or in a transport. |
||
49 | If SARewriteBody is true you should also consider setting |
||
50 | SAaddSAEheaderBeforeSA to false (see the config) as all the recipients |
||
51 | will be visible in the attached spam, note that this disables the |
||
52 | ability to write SpamAssassin rules based on X-SA-Exim-Rcpt-From/To. |
||
53 | In real life, who a spam was sent to isn't really a problem, but it could be if |
||
54 | a private message is mis-categorized as spam |
||
55 | Note however that if you disable X-SA-Exim-Rcpt-To by setting |
||
56 | SAmaxrcptlistlength to 0, you will not be able to use greylisting, which |
||
57 | depends on this header (however you'd still be welcome to remove the header in |
||
58 | system_filter) |
||
59 | |||
60 | |||
61 | CONFIGURATION |
||
62 | ------------- |
||
63 | You should read sa-exim.conf, all the options there should be well |
||
64 | documented. |
||
65 | |||
66 | Note that the code will not act on any mail before it is flagged as SPAM by SA. |
||
67 | |||
68 | Having SA flag the mail however doesn't mean the code rejects it or throws |
||
69 | the alleged spam away, you control what you want to do depending on the score. |
||
70 | The only restriction is that things happen in this order (for increasing SA |
||
71 | scores) |
||
72 | |||
73 | - Save in SAnotspamsave if enabled |
||
74 | - Save in SAspamacceptsave if enabled |
||
75 | - Temporarily reject and optionally save if enabled |
||
76 | - Permanently reject and optionally save if enabled |
||
77 | - Accept, drop the mail, and optionally save if enabled |
||
78 | - Teergrube (i.e. stall) the sender to waste his resources (and yours) |
||
79 | |||
80 | Note that you cannot set a teergrube threshold of 12, and a permreject |
||
81 | threshold of 20 (not that it would make much sense anyway). |
||
82 | Threshold scores should decrease as you apply the highest to the lowest penalty |
||
83 | (i.e. the rules are run in this order: teergrube, devnull, permreject, |
||
84 | tempreject) |
||
85 | |||
86 | Now, as of SA-Exim 4.2, things get slightly more complicated as scores are |
||
87 | actually full exim conditions, and therefore you could have: |
||
88 | SAteergrube: ${if and { {!eq {$sender_host_address}{127.0.0.1}} {!eq {$sender_host_address}{127.0.0.2}} } {25}{1048576}} |
||
89 | This means that if your condition succeeds, the teergrube score is set to 25, |
||
90 | and if the condition fails, the teergrube score is set to 2^20, which for all |
||
91 | intents and purposes, disables teergrubing. |
||
92 | Regardless of what your scores end up being after the conditions are evaluated, |
||
93 | sa-exim still tests them in this order: teergrube, devnull, permreject, |
||
94 | tempreject) |
||
95 | |||
96 | |||
97 | |||
98 | |||
99 | CONFIGURING SPAMASSASSIN |
||
100 | ------------------------ |
||
101 | A good example of spamassassin configuration would be: |
||
102 | |||
103 | report_safe 0 |
||
104 | use_terse_report 1 # for SA < 3.x |
||
105 | |||
106 | This will put a non-verbose SPAM-report in the headers, but leave the |
||
107 | message itself intact for easy analyzing and for easy feeding to |
||
108 | sa-learn when mis-flagged as spam or ham. The only way to see the |
||
109 | message is spam, is by looking in the headers. |
||
110 | |||
111 | If you have an older version of SpamAssassin (<= 2.50), you'd probably |
||
112 | want to add 'report_header 1' to that list. But this is default and |
||
113 | un-needed in new versions of SA) |
||
114 | |||
115 | If you set 'report_safe' to a true value, you might also want to set |
||
116 | use_terse_report to a false value, in case you'll get the long header |
||
117 | which might be friendlier to your users. |
||
118 | |||
119 | For SA before 3.x, add 'always_add_report 1' to always have a spamcheck report |
||
120 | put in the message. This might be useful to test rules. |
||
121 | For SA 3.x onward, the syntax you'd want, is: |
||
122 | add_header all Report _REPORT_ |
||
123 | |||
124 | Since SA is usually configured to pass messages on that are beyond the SA |
||
125 | spam threshold, it can make sense to rewrite the subject line. |
||
126 | To achieve this, you would use this for SA 2.x: |
||
127 | rewrite_subject 1 |
||
128 | subject_tag SPAM: _HITS_: |
||
129 | |||
130 | For SA 3.x, the syntax is: |
||
131 | rewrite_header Subject SPAM: _HITS_: |
||
132 | |||
133 | |||
134 | If you are using SA 2.50 or better, by default, you should probably set: |
||
135 | report_safe 0 |
||
136 | |||
137 | Now, if you are willing to take a small speed and I/O hit, you can have |
||
138 | sa-exim read the body back from SA, and replace the original mail with |
||
139 | the new body. |
||
140 | |||
141 | You would use this if you want to set SA's report_safe to 1 or 2 (in |
||
142 | which case you also have to set SARewriteBody: 1 in SA-Exim's config) |
||
143 | |||
144 | Note that if you do so, unfortunately archived messages will have the |
||
145 | body modified by SA. This is not very trivial to fix, so if you archive |
||
146 | anything, you may not want to use SARewriteBody |
||
147 | |||
148 | |||
149 | Important: |
||
150 | You want to run spamd as such: |
||
151 | /usr/sbin/spamd -d -u nobody -H /var/spool/spamassassin/ |
||
152 | |||
153 | It may not work if you run spamd with -c (debian default), |
||
154 | (you shouldn't run spamassassin as root for this purpose anyway (there |
||
155 | is no reason to, so why take the risk) |
||
156 | |||
157 | You can edit this in /etc/default/spamassassin (debian) and probably |
||
158 | /etc/sysconfig/spamassassin (redhat) |
||
159 | |||
160 | With SA 3.x is better, the updated syntax would look like this: |
||
161 | /usr/sbin/spamd --max-children 50 --daemonize --username=nobody --nouser-config --helper-home-dir=/var/spool/spamassassin/ |
||
162 | |||
163 | |||
164 | |||
165 | CONFIGURING EXIM4.CONF |
||
166 | ---------------------- |
||
167 | This code works without anything in the exim conf, but you probably want to use |
||
168 | some knobs to disable scanning for some users (like setting X-SA-Do-Not-Rej |
||
169 | or X-SA-Do-Not-Run in the rcpt ACL and removing those headers in the right |
||
170 | places) |
||
171 | |||
172 | See http://marc.merlins.org/linux/exim/#conf and more specifically |
||
173 | http://marc.merlins.org/linux/exim/exim4-conf/exim4.conf |
||
174 | |||
175 | Note that obviously if you set those headers, spammers can set them too, so |
||
176 | if you are concerned about this, you can either change the header name, or set |
||
177 | it to something else than 'Yes' and check for that value in sa-exim.conf |
||
178 | (or as a 3rd option, you can use exim ACL variables to pass values to SA-Exim |
||
179 | without generating headers; see the section contributed by Chirik, lower in |
||
180 | this file) |
||
181 | |||
182 | |||
183 | |||
184 | EXIM4 INTEGRATION / NOT SCANNING YOUR OWN MAILS |
||
185 | ----------------------------------------------- |
||
186 | For a very complete exim4 config, including settings for SA, you should |
||
187 | look at sa-exim.conf and play with: |
||
188 | |||
189 | SAEximRunCond: ${if and{ \ |
||
190 | {def:sender_host_address} \ |
||
191 | {!eq {$sender_host_address}{127.0.0.1}} \ |
||
192 | {!eq {$h_X-SA-Do-Not-Run:}{Yes}} \ |
||
193 | } \ |
||
194 | {1}{0} \ |
||
195 | } |
||
196 | |||
197 | You may also want to look at my exim4.conf config if you haven't done so yet: |
||
198 | http://marc.merlins.org/linux/exim/#conf |
||
199 | |||
200 | The check_rcpt ACL has: |
||
201 | warn message = X-SA-Do-Not-Rej: Yes |
||
202 | local_parts = +nosarej:postmaster:abuse |
||
203 | |||
204 | warn message = X-SA-Do-Not-Run: Yes |
||
205 | hosts = +relay_from_hosts |
||
206 | |||
207 | warn message = X-SA-Do-Not-Run: Yes |
||
208 | authenticated = * |
||
209 | |||
210 | Then, you'll want to strip SA headers for messages that aren't local |
||
211 | This means you should strip them at least in the remote_smtp transport |
||
212 | with this configuration snippet: |
||
213 | |||
214 | # This is generally set on messages originating from local users and it tells |
||
215 | # SA-Exim not to scan the message or that the message was scanned. |
||
216 | # Let's remove these headers if the message is sent remotely |
||
217 | headers_remove = "X-SA-Do-Not-Run:X-SA-Exim-Scanned:X-SA-Exim-Mail-From:X-SA-Exim-Rcpt-To:X-SA-Exim-Connect-IP" |
||
218 | |||
219 | |||
220 | You can also use another option, which can't be spoofed by a spammer, but |
||
221 | won't show you why a mail didn't get scanned if it was sent to multiple |
||
222 | people (which is why I personally prefer the above, even if it's spoofable) |
||
223 | |||
224 | Contributed by Chirik <chirik@castlefur.com>: |
||
225 | ---------------------------------------------------------------------------- |
||
226 | I have the following: |
||
227 | |||
228 | SAEximRunCond: ${if !eq {$acl_m0}{do-not-scan} {1} {0}} |
||
229 | SAEximRejCond: ${if !eq {$acl_m0}{do-not-reject} {1} {0}} |
||
230 | |||
231 | Then, in my recipient ACL, I have: |
||
232 | |||
233 | ##### Checks for postmaster or abuse - we'll scan, still, but not reject |
||
234 | ##### Don't reject for certain users |
||
235 | warn local_parts = postmaster : abuse |
||
236 | set acl_m0 = do-not-reject |
||
237 | |||
238 | ##### Check for situations we don't even scan (local mail) |
||
239 | ##### Don't scan if hosts we relay for (probably dumb MUAs), |
||
240 | warn hosts = +relay_from_hosts:127.0.0.1/8 |
||
241 | set acl_m0 = do-not-scan |
||
242 | |||
243 | ##### Don't scan non-smtp connections (empty host list) |
||
244 | warn hosts = : |
||
245 | set acl_m0 = do-not-scan |
||
246 | |||
247 | ##### Don't scan if authenticated |
||
248 | warn authenticated = * |
||
249 | set acl_m0 = do-not-scan |
||
250 | ---------------------------------------------------------------------------- |
||
251 | |||
252 | |||
253 | |||
254 | TEERGRUBING: SAteergrube |
||
255 | ------------------------ |
||
256 | The idea is for mail that you know for sure is spam (I use a threshold of 25), |
||
257 | you can stall the spammer for as long as possible by sending a continuation |
||
258 | line every 10 seconds: |
||
259 | 451- wait for more output |
||
260 | 451- wait for more output |
||
261 | 451- wait for more output |
||
262 | (...) |
||
263 | |||
264 | You can go there for details: |
||
265 | http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html |
||
266 | |||
267 | What should you know? |
||
268 | 1) This is obviously going to use up some of your resources |
||
269 | 2) You should not teergrube SMTP servers that relay mail for you, be |
||
270 | courteous (set a condition in SAteergrube like in the example |
||
271 | provided). Besides they are real mail relays, so they will diligently |
||
272 | try to send you the spam over and over for days) |
||
273 | (note that you should probably not teergrube mailling lists you subscribed |
||
274 | to either, or you risk getting unsubscribed) |
||
275 | See a sample in sa-exim.conf for example syntax. |
||
276 | 3) Because of limitations in the current exim code, teergrubing will not work |
||
277 | over TLS. |
||
278 | This shouldn't be a problem since real spammers should not be using TLS, |
||
279 | and you shouldn't teergrube relays that do TLS with you. |
||
280 | If you do teergrube a TLS connection, it will break the connection and you |
||
281 | will see this in your logs: |
||
282 | 18640m-0000Vb-00 SSL_write error 5 |
||
283 | TLS error (SSL_write): error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number |
||
284 | This is not ideal, but in real life, that's ok. |
||
285 | |||
286 | |||
287 | |||
288 | GREYLISTING |
||
289 | ----------- |
||
290 | See README.greylisting |
||
291 | |||
292 | |||
293 | |||
294 | READING ARCHIVED SPAMS |
||
295 | ---------------------- |
||
296 | Spams are optionally saved in individual files in a 'new' subdirectory |
||
297 | of some place like /var/spool/sa-exim/SAteergrube. |
||
298 | |||
299 | There are two ways to read them: |
||
300 | 1) cat new/* > /tmp/mailbox, and use the resulting file as a standard |
||
301 | mbox file with any mail client (if SAPrependArchiveWithFrom is true) |
||
302 | 2) Use a maildir capable mail client, like mutt, and run something like |
||
303 | 'mutt -f /var/spool/sa-exim/SAteergrube'. This will read the messages in |
||
304 | place, since what sa-exim creates looks like a valid Maildir spool. |
||
305 | |||
306 | If you configured SA-Exim to set X-SA-Exim-Rcpt-To, you can even resend |
||
307 | archived refused messages to the users they were meant for |
||
308 | |||
309 | Note that sa-exim runs with the same uid/gid than the exim daemon (something |
||
310 | like mail, exim, or Debian-Exim), so /var/spool/sa-exim/SAteergrube must exist |
||
311 | and be writeable by exim. |
||
312 | SA-Exim will then create (sub-)directories with the permissions 0770 as |
||
313 | needed (those permissions aren't a configuration option, but you can change |
||
314 | them after the fact or pre-create the directories with the permissions of your |
||
315 | choice) |
||
316 | Files are created with 0664 permissions so that anyone who has directory access |
||
317 | can read (and maybe write) the files. |
||
318 | If you chgrp the parent 'new' directory to a group of your choice, and give it |
||
319 | permissions 2770 or 2775, the files will be created with that group instead of |
||
320 | the default exim group |
||
321 | |||
322 | |||
323 | |||
324 | LOG AND SMTP OUTPUT |
||
325 | ------------------- |
||
326 | As of SA-Exim 3.0, SMTP output does not contain the spam score anymore, |
||
327 | and you can change the messages or re-add the score by changing the |
||
328 | runtime SAmsg* variables |
||
329 | |||
330 | All SA-Exim log now looks like this: |
||
331 | - "SA: PANIC: " -> severe errors |
||
332 | - "SA: Warning: " -> config file parsing errors |
||
333 | - "SA: Notice: " -> misc info on what SA-Exim is doing or not doing |
||
334 | - "SA: Action: " -> what action SA-Exim took on a mail after scanning |
||
335 | - "SA: Debug[X]: " -> misc debug info if enabled |
||
336 | |||
337 | Marin Balvers has written a nice log parser here: |
||
338 | http://nossie.addicts.nl/projects/sa-exim-stats/ |
||
339 | |||
340 | |||
341 | |||
342 | FAQ |
||
343 | --- |
||
344 | Why do I get this in my exim logs? |
||
345 | |||
346 | 2004-05-15 12:43:57 1BP54T-0002gV-Nu TLS send error on connection from internalmx1.company.tld (internalmx.company.tld) [192.168.1.1]:51552: Error in the push function. |
||
347 | 2004-05-15 12:43:57 TLS recv error on connection from internalmx1.company.tld (internalmx.company.tld) |
||
348 | [192.168.1.1]:51552: The specified session has been invalidated for some reason. |
||
349 | |||
350 | This is because you are teergrubing a host that is doing TLS. Teergrubing does |
||
351 | not work with TLS, and people doing TLS with you are probably known relays which |
||
352 | you should exclude from your teergrube list (SAteergrubecond) |