On Tue, Jun 1, 2010 at 10:45, Rainer Frey <rainer.frey@inxmail.de> wrote:
I guess you'll have the mental transfer of "fight spam" into "cause dovecot to perform this and that action" yourself. The possible actions are, in general, documented.
I cannot determine how deliver with an empty string give to -m would behave. OTOH, I don't know that an empty string would what would even happen, since I have yet to explore how the spam status from one of the spam detections would trickle through to setting up the transport variables in Postfix. I don't even know if -m is considered the appropriate means to deliver to a specific box in the case of junk spam. If it is, obviously someone must be using it.
You need to configure the MTA to accept and tag spam messages, e.g. with Amavis D_PASS policy and appropriate tag levels. Then the most flexible way to put the mails into a spam folder is to use the deliver plugin for sieve, which can sort and filter mails depending on many different conditions, like presence and/or value of any header. You can deploy a single system wide default script for all users, which can be complemented or overwritten by individual users (depending on configuration).
OK, so a delivery-time sieve.
See http://wiki.dovecot.org/LDA/Sieve If you use dovecot 1.2, using the new Dovecot Sieve plugin is highly recommended above the old CMUsieve. See http://wiki.dovecot.org/LDA/Sieve/Dovecot
Ubuntu has me at Dovecot version 1.1.11. Ubuntu has turned out to be difficult for managing upgrades when packages it has are instead compiled from source. So being "up to date at the source level" is going to have to wait until I get some Slackware running here (originally Ubuntu was chosen because of the wider variety of ready-to-install packages).
The really recommended way nowadays is different though: *reject* as much spam as possible in the MTA in the receiving SMTP dialog, with a combination of blacklists, sender validation (e.g.DKIM), potentially greylisting (as you deem appropriate) and lastly content scanning with s.th. like amavis+spamassassin. I'd not expect a noticable amount of false positives, and in the rare cases the sender will be notified. The false positives rate of users scanning through a folder of tagged mail will be higher.
I've had periodic high FPs with content detection in the past (on other mail servers I didn't control). So greylisting for that is what I will likely be doing, at least at first. How much I shift to blacklisting will depend on the feedback from my own users ("hey, my Junk-spam folder has too much spam" or "How can I find that one false positive if there are a million spams in there").
Tagging ... yeah, clearly I would do that for anything not rejected at SMTP time. How to get Dovecot deliver to put those ... well, OK, I'll look into Sieve instead of writing my own shim.
A howto-like page to describe the usage of some dovecot features in an anti- spam context wouldn't hurt, OTOH there is not much anti-spam specific stuff at all at the dovecot side.
Unfortunately, a good document would likely have to be specific to the LDA, MTA, and spam tools. Given so many combinations, that's a lot documents, or a rather complex one. I can certainly use my notes from my own solutions and make something specific to Dovecot and Postfix and whatever spam tools I use (could be more than one).