On Mon, 2012-12-17 at 18:20 +0100, Cyril RUSSO wrote:
Hi,
First, please forgive me as I'm not subscribed to the list. I'm using Dovecot 2 (2.1.7) for serving my local maildir. This maildir is filled by an external process, fetching & merging mails from different sources that's outside this scope (but it's working).
Dovecot is thus acting as a MTA, but more as a MDA. I've a web client running on the server, and it connects to Dovecot to get the mails. I've configured this web client & dovecot to use sieve to filter the mails. I know that since Dovecot does not actually deliver the messages, it's not the expected behavior. Anyway, I can use the "deliver" software in your suite for passing sieve's rules on each message in my maildir, and it's almost working. I've a cron job that run deliver on each message of my maildir, but I'm a bit puzzled now. Basically, I'm not able to figure out if a message was matched by a sieve filter or not.
I'm a bit disappointed by two things:
- Sieve's reject doesn't make "deliver" to return an error, so a sieve rule chain ending in "reject" can't be detected from my cron's script. I wonder it's due to the step deliver is supposed to be run (after a mail is already accepted).
With dovecot-lda -e parameter you could at least in theory use ereject extension (not sure if Pigeonhole implements that now).
Also alternatively the reject command will execute sendmail_path to send the rejection mail. You could catch that and e.g. create some flag file.
- "deliver" doesn't have a method to find out if it processed the given mail as input.
Basically, would it be possible to either add a parameter to "deliver" (for example: "--fail-on-discarding") so it would fail if the sieve rules discard or reject (/ereject) the mail ? That way, I could detect the failure in my script, and know that I don't need to delete the initial mail since it was not filtered.
Or, thought differently, I wonder if "deliver" could open a socket/pipe/file whatever, and write the number of processed mails in there (or using a "--return-processed-mail"), so a sieve rule ending with "delete", would be detectable by my script.
All of this sounds like a rather complex and probably somewhat fragile solution. I don't think I'd want to add such features where there is only one user (you).