similar to: Empty argument in "executable = script ..." service

> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote: > > >> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >> >> >> >> On 19.01.2018 04:35, Adam Weinberger wrote: >>> Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled. >>> It seems to be happening when I use

Op 1/21/2018 om 4:34 PM schreef Stephan Bosch: > Op 1/20/2018 om 11:01 PM schreef Adam Weinberger: >>> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote: >>> >>> >>>> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >>>> >>>> >>>> >>>> On 19.01.2018 04:35,

Op 1/20/2018 om 11:01 PM schreef Adam Weinberger: >> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote: >> >> >>> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >>> >>> >>> >>> On 19.01.2018 04:35, Adam Weinberger wrote: >>>> Since upgrading to 2.3.0 / 0.5.0.1, incoming

> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > > > > On 19.01.2018 04:35, Adam Weinberger wrote: >> Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled. >> It seems to be happening when I use vnd.dovecot.filter. When I comment >> out the block, things come through fine. >> >> My filter block looks like

On 19.01.2018 04:35, Adam Weinberger wrote: > Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled. > It seems to be happening when I use vnd.dovecot.filter. When I comment > out the block, things come through fine. > > My filter block looks like this: > require "vnd.dovecot.filter"; > filter "bogofilter_filter"; > >

Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled. It seems to be happening when I use vnd.dovecot.filter. When I comment out the block, things come through fine. My filter block looks like this: require "vnd.dovecot.filter"; filter "bogofilter_filter"; if header :contains "X-Bogosity" [ "Spam,

Hello, Sorry for a bit offtopic but it seems the bogofilter community is just as dead as dspam is. I trying to switch from DSPAM to bogofilter on a server where if I turn bogofilter on I run into the following issue: Certain users have sender and recipient bcc maps setup in postfix. This is for forwarding copy of an email to other address for example: Incoming lclude at company.com ->

Hi, on my small Xen-virtualised server with 48 MiB RAM I use Postfix and Dovecot, because the Debian administrators dislike qmail [1], which is in my opinion despite some maintainability and code quality issues a quite well designed software, because it mostly follows the UNIX principles. Postfix is not able to sort my E-Mail into different Maildir folders and after I looked at procmail's

DEBIAN package information: ii dovecot-common 0.99.11-3 ii dovecot-imapd 0.99.11-3 ii bogofilter 0.93.1-1 Apologies for cross-posting, but I think the problem lies somewhere in here. Maybe someone can tell me something useful. Now, I've confirmed the following: I received a mail message that was not spam, of size 2132 originally. clamav scanned it and bumped the size up to 2356

> On 21 Dec, 2017, at 14:37, Stephan Bosch <stephan at rename-it.nl> wrote: > > Op 12/19/2017 om 8:41 AM schreef Adam Weinberger: >> I'm getting a behaviour with pigeonhole that I wasn't expecting. Am I >> misunderstanding the design? >> >> I run my messages through a vnd.dovecot.filter. It's essentially this: >> >> filter

Op 12/22/2017 om 3:43 AM schreef Adam Weinberger: >> On 21 Dec, 2017, at 14:37, Stephan Bosch <stephan at rename-it.nl> wrote: >> >> Op 12/19/2017 om 8:41 AM schreef Adam Weinberger: >>> I'm getting a behaviour with pigeonhole that I wasn't expecting. Am I >>> misunderstanding the design? >>> >>> I run my messages through a

# 2.2.12: /etc/dovecot/dovecot.conf # OS: Linux 3.15.4-x86_64-linode45 x86_64 openSUSE 12.3 (x86_64) Short version: 1) I filter out spam by using a dovecot sieve filter to act based on a header inserted by bogofilter 2) In some cases, sieve fails to correctly file based on this header 3) Testing with sieve-test indicates that it's testing the wrong header 4) Suggestions? Am I doing

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dovecot gurus, I have a couple of questions for which I haven't found answers in the docs (which may be well more a limitation of my capabilities than anything else). Here they go: - Is it OK to move mailboxes around from under Dovecot? Case in point: I'm using procmail to pass incoming mail through bogofilter (the standard recipe

Can someone suggest anything that will help with the following ext3 performance problem? (It's a Berkeley db issue at bottom, but the ext3 part is worth looking at, I think.) First, two paragraphs of background: A Bayesian spam filter called bogofilter uses Berkeley db to maintain two database files of identical format: one containing words found in spam email and for each word the number

I've tried to use sieve-filter for my inbox (~6000 messages). It failed after some work with this backtrace: sieve-filter(kas): Error: socketpair() failed: Too many open files sieve-filter(kas): Panic: file script-client-local.c: line 155 (script_client_local_disconnect): assertion failed: (pid >= 0) sieve-filter(kas): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x66a71)

I'm using maildrop to filter mail like: xfilter "/usr/bin/spamc" xfilter "/usr/bin/bogofilter -ep" I want to change to deliver (so I can use sieve) but can deliver do this?

Just discovered the Pigeonhole Sieve Extprograms plugin (https://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Extprograms <https://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Extprograms>)? I currently have Postfix configured to run a script to store all incoming messages into a Mysql DB and a batch job that retrieves the messages in the DB, processes them and delivers them to the

I use bogofilter and a script or two to manage junk mail on my home box (fetchmail from POP3, postfix and procmail to local maildirs, mutt for MUA). Since these mails are just files I figured it never mattered that I moved them from one folder to another via a bash script, but some posts on this list make me think I shouldn't do that on a server running dovecot (IMAP). What I currently have

On 20/10/2020 23:37, @lbutlr wrote: > On 20 Oct 2020, at 13:46, @lbutlr <kremels at kreme.com> wrote: >> It looks like what I need to do is enable and use vnd.dovecot.filter > error: require command: unknown Sieve capability `vnd.dovecot.filter'. > > Is this not available to a user? I guess I can put the in global, but ick. You need to include the extprograms plugin:

The sieve-extprograms extension strips Return-Path headers before passing mail off to the external program. The patch to remove this behavious is trivial (and attached), but since it appears to be deliberate I felt I should investigate further. I believe this is basically a cut-and-paste error. The code to strip Return-Path has been there since the sieve-pipe plugin for Dovecot 1.x, and I believe