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 , Thu, 8 Mar 2007 13:07:42 +0100