[Dovecot] Dovecot aspects of fighting spam

[Phil Howard]

On Wed, Jun 2, 2010 at 02:39, Rainer Frey <rainer.frey at inxmail.de> wrote:
> On Tuesday 01 June 2010 17:01:16 Phil Howard wrote:

>> I cannot determine how deliver with an empty string give to -m would
>> behave.
>
> This is just what I mean: the behavior of deliver -m has absolutely nothing to
> do with fighting spam. It is the same whether you want to use it for spam-
> tagged mails or any other reason. Therefore you'll not find the description in
> thedovecot wiki bysearching for "fighting spam". You'll find it by searching
> for "deliver" (or LDA).

I found the man page (like) document for deliver just fine.  I did not
limit my search to just the "spam" keyword.  I'm guessing that you are
assuming I never found this document:

http://wiki.dovecot.org/LDA

But now that you know I have read it (and read it long before the
previous post), re-read what I said.  You should conclude that I am
unable to determine fully what -m does from this.  It does not
describe the behavior if the value given is a null string.  This is a
concern because in master.cf for Postfix, there is no means to
dynamically provide or omit the -m option.  You can give it a value
from a variable.  But it may be necessary to give an empty string
value in order to not deliver to a specific folder, and I want to know
if that will get the mail into the INBOX.


> Yes, sieve is mostly (with dovecot: only) used at delivery time (Cyrus IMAP
> might have support for applying sieve scripts with IMAP, but if so, it is an
> exception).

If sieve had been defined in terms of the mail client uploading
scripts via IMAP to a designated special folder, it might have been
easier to have users supply their own scripts.  But at this point I
don't want to have users doing things that will send mail back out
(e.g. vacation scripts) unless and until I can ensure that such
outbound mail only goes to known recipients (e.g. to avoid backscatter
for FN spam with forged sender addresses).


> This is not my experience. Esp. dovecot and postfix are easily managed from
> source. Installing the package 'build-essential' and then 'aptitude build-dep
> dovecot' should provide all you need to compile and install dovecot from
> source (which is documented in the wiki).

My experience with Debian and Ubuntu has several cases of packages
being degraded or corrupted after building them from source code.
Colleagues have reported the same with Fedora.  No such issue has ever
happened with Slackware, either to me, or that I have heard of.  But,
for the time being anyway, I am on Ubuntu without any source builds.
For various reasons, I do need to eventually move mail services off
the current machine and onto a pair of new machines.  At that time,
Slackware will be considered, as will OpenBSD.


> This is why I recommended a combination of different measures. Content
> detection should come in last in that list, but still can be done at SMTP time
> (esp. with latest postfix and amavisd-new).

I'm all for the combination.  But I need to do less rejection and more
tagging for the before-queue tests (after-queue tests would limited to
tagging, only).  That's yet to be explored in Postfix.