Subversion Repositories sa-exim

Compare Revisions

Ignore whitespace Rev 6 → Rev 5

/trunk/debian/README.Debian
1,44 → 1,3
********************************
* 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 *
*****************
48,7 → 7,7
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:
To find out what configurationfile Exim4 is using, issue:
 
$ exim4 -bV | tail -1
Configuration file is /path/to/configfile
56,17 → 15,16
If /path/to/configfile shows:
 
- /etc/exim4/exim4.conf
You are using the hand-crafted configuration file.
See the 'HAND-CRAFTED' section below.
You are using the 'monolithic' configuration file.
See the 'MONOLITHIC' 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.
You are using the 'split' configuration file.
See the 'SPLIT' section below.
 
 
HAND-CRAFTED
------------
MONOLITHIC
----------
 
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
76,32 → 34,28
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.
'invoke-rc.d exim4 restart' or '/etc/init.d/exim4 restart' as root.
 
 
DEBIANIZED
----------
SPLIT
-----
 
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:
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.
If your result shows 'false' where mine shows 'true', but the check
earlier showed that you *are* in fact using the split configuration,
then you have to edit /etc/exim4/update-exim4.conf.conf by hand and
change the 'false' to 'true' and issue 'update-exim4.conf' as root.
Next, 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.
 
Next, read all about greylisting and sa-exim:
 
117,9 → 71,8
README.Greylisting for details)
 
 
If you use a version of SA older than 3.0 (if you are, you really,
really should upgrade!), you will need to patch spamassassin's sources
to support greylisting.
If you use a version of SA older than 3.0, you will need to patch
spamassassin's sources to support greylisting.
 
There are two versions of the patches:
- /usr/share/doc/sa-exim/patches/SA-greylisting-2.4x.diff
152,13 → 105,3
You can later set it to install again with:
 
$ echo "spamassassin install" | dpkg --set-selections
 
 
**********************************
* 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.