1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
SpamPD for Debian
-----------------
SpamPD configuration takes place in /etc/default/spampd as far as the network
connections are concerned. Any more advanced configuration of the the
SpamAssassin part is done in /etc/spamassassin/local.cf as usual with with
SpamAssassin. Additionally, as of Debian package 2.30-5, it is now now possible
to specify an additional configuration file which can override any option given
in the system wide configuration of SpamAssassin.
Running SpamPD in unintended ways
---------------------------------
SpamPD is (like amavisd-new and similar filters) intended to be run as a
_post-queue_ filter in postfix or in a similar way with other MTAs. However,
the following hints might help you to use it as a pre-queue filter or even in
front of your MTA. Both setups really are _not_ recommended though pre-queue
filtering seems to work fine. Running SpamPD in front of your MTA can quickly
turn your mailserver into an open relay if you are not 100% careful with the
setup. It also exposes SpamPD to malicious traffic which is normally caught by
the MTA in front of it. Though SpamPD has no known security holes, it's better
to be careful especially since SpamPD security relies on SpamAssassin being
secure. These notes of caution don't necessarily apply when running SpamPD as
a pre-queue filter though. Anyway, here is as much help as I can give you with
either setup. It's mostly related to network timeouts.
By default, SpamPD times out after 5 minutes if no network paket is
received or after 6 minutes have gone by since start of the SMTP
dialogue. The first parameter isn't directly adjustable, but that shouldn't be
a problem in any case. The second one however can pose a problem for
really slow clients (or extremely large mails).
If you experience such problems (i.e. a client isn't able to send
large mails even though it slowly but steadily sends data), try
passing "--childtimeout=3600" (60 minutes) to spampd using the
ADDOPTS entry in /etc/default/spampd.
SpamPD and SpamAssassin's Auto-Whitelist Feature
------------------------------------------------
There is a known problem with SpamAssasins Auto-Whitelist feature with the
(default) storage in files. Where SpamAssassin creates a mutex early during
load and after Net::Server changes the UID, this mutex can't be accessed
anymore. There is nothing SpamPD can do about this as far as I can tell, and
I recommend using a real DB-Server (MySQL or another server supported by Perl
DBI). Using such a server is documented in the SpamAssassin docs.
Pretty insecure Workaround: Set auto_whitelist_file_mode in your SpamAssassin
configuration to 0666 (default is 0600).
-- Sven Mueller <debian@incase.de>, Thu, 8 Mar 2007 13:07:42 +0100
|
