Using filter in an imapsieve script?

[Stephan Bosch]

Op 4/5/2017 om 11:48 AM schreef Tobi:
> Hello list

OK, I know why this is happening now.

> I currently have an issue with an imapsieve script on my dovecot server
>
> CentOS Linux release 7.3.1611 (Core)
> Dovecot 2.2.26.0 (23d1de6)
> Pigeonhole 2.2.26.0
>
> The goal is to "fire" an imapsieve script upon mailclient saves message
> to sent folder
> I setup the following in 90-plugin.conf:
>
> plugin {
>     sieve_plugins = sieve_imapsieve sieve_extprograms
>     sieve_extensions = +vnd.dovecot.filter +vnd.dovecot.pipe
> +vnd.dovecot.execute
>     sieve_filter_bin_dir = /etc/dovecot/sieve-filters
>     sieve_pipe_bin_dir = /etc/dovecot/sieve-filters
>     sieve_execute_bin_dir = /etc/dovecot/sieve-filters
>     sieve_filter_exec_timeout = 10000
>     sieve_pipe_exec_timeout = 10000
>     sieve_execute_exec_timeout = 10000
>     imapsieve_mailbox1_name = Sent
>     imapsieve_mailbox1_causes = COPY APPEND
>     imapsieve_mailbox1_before =
> file:/home/vmail/domain/user/dovecot-crypt-sent.sieve
> }

This is all OK.

> and the content of the sieve script is:
>
> require ["environment", "vnd.dovecot.filter", "variables", "imapsieve",
> "vnd.dovecot.pipe", "vnd.dovecot.execute"];
>
> if anyof (environment :is "imap.cause" "APPEND", environment :is
> "imap.cause" "COPY") {
>   filter "gpgit" "myuser at mydomain.tld";
> }

This is not, because from https://tools.ietf.org/html/rfc6785#section-3.1:

   For all cases that fall under IMAP events in Sieve, the implicit keep
   means that the message is treated as it would have been if no Sieve
   script were run.  For APPEND and COPY, the message is stored into the
   target mailbox normally.  For flag changes, the message is left in
   the mailbox.  If actions have been taken that change the message,
   those changes are considered transient and MUST NOT be retained for
   any "keep" action (because IMAP messages are immutable).  No error is
   generated, but the original message, without the changes, is kept.


So, your implicit "keep" will ignore the changes made by the filter command.

> gpgit is a perl script that encrypts a given message using the users pub
> key and returns back the encrypted message
> As a sieve script for lmtp/lda it works fine and encrypted messages show
> up in the mailbox. But it does not work if it is used as imap sieve script
> There is nothing in the logs that indicates a problem with the imap
> sieve script.
> Is it possible that 'filter' is not supported for imapsieve as it
> changes the content of a message?

In the simplest case, it looks that way, yes.

However, there may be a way around that. Unlike "keep", the "fileinto"
command will store the changed message.

I tested the following Sieve script in place of yours:

require "variables";
require "fileinto";
require "imapsieve";
require "environment";
require "vnd.dovecot.filter";

# Obtain the destination mailbox name
if environment :matches "imap.mailbox" "*" { set "mailbox" "${1}"; }

# No need to check imap.cause like you did, since the condition you
formulated is always true with your
# configuration.

# Encrypt
if filter "gpgit" {
        # Create an encrypted copy of the message
        fileinto "${mailbox}";

        # Since implicit keep is canceled, original saved/copied message
is marked as \Deleted, soon to be expunged.
        stop;
}

# If encryption fails, the original message is kept in place

This works.

However, I now remember I tested this in the past and there was one
snag. The effect of this is that the message is stored twice in the Sent
mailbox:

- The first is the original message. Since it was discarded, it has the
\Deleted flag set and it will disappear at the next EXPUNGE
- The encrypted message stored with "fileinto".

When I tested this a little more than a year ago, Thunderbird got
confused and kept showing the original message in the Sent folder and
not the encrypted one. Only a restart of Thunderbird would fix that.
Other mail clients may have similar issues. This is valid IMAP behavior
(think other client deleting the message right after it was saved), so
the server is not to blame.

Regards,

Stephan.