[Dovecot] Dovecot aspects of fighting spam

[Phil Howard]

On Tue, Jun 1, 2010 at 10:45, Rainer Frey <rainer.frey at 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).