On Wed, Jun 2, 2010 at 02:39, Rainer Frey <rainer.frey@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:
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.