Subversion Repositories

?revision_form?Rev ?revision_input??revision_submit??revision_endform?

Rev 1 | Go to most recent revision | Details | Compare with Previous | 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)