dovecot - Mar 2015 - Released Pigeonhole v0.4.7.rc1 for Dovecot v2.2.16.rc1

On 3/10/2015 8:11 PM, E.B. wrote:
>> Last time I had a few stupid problems in the releases, so
>> I'll follow
>> Timo's example and I release an RC first.
>>
>> The highlights include the implementation of the index and
>> metadata
>> extensions. Quite a few bugs are fixed as well.
> When I compiled and installed this, Sieve scripts were being ignored. Not
> sure if it's my own stupid mistake, but when I put v0.4.6 back in
place, it
> worked fine. No configuration changes, only make install on the different
> sources and restart dovecot.
Could you show your dovecot -n output?

Also, if you enable mail_debug, what sieve-related debug lines are shown?

Regards,

Stephan.

> >> Last time I had a few stupid problems in the releases, so
> >> I'll follow
> >> Timo's example and I release an RC first.
> >>
> >> The highlights include the implementation of the index and
> >> metadata
> >> extensions. Quite a few bugs are fixed as well.
> > When I compiled and installed this, Sieve scripts were being ignored.
Not
> > sure if it's my own stupid mistake, but when I put v0.4.6 back in
place, it
> > worked fine. No configuration changes, only make install on the
different
> > sources and restart dovecot.
>
> Could you show your dovecot -n output?
>
> Also, if you enable mail_debug, what sieve-related debug lines are shown?
OK, I re-tested and it's still ignoring personal scripts (but not
global ones).  No .svbin gets generated, no errors, just nothing.
However, I do see that Sieve was accessing the user home directory
because for some reason now it just created a ".pki" directory
therein, which inside of it has an empty "nssdb" directory.  That
never happened before...?  Not a big problem, but I'd prefer not
to have that there.

Re: mail_debug, this relates to another post I made that didn't get any
replies - can I not override settings such as that (and log_path) from
a userdb lookup?  Hmm, I WAS able to override mail_debug from userdb,
but not log_path?

Sieve-related mail_debug, then?

This looks like the relevant log info:

dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve:
file storage: Storage path `/vmail/example.com/testuser/sieve' not found
dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: No
default script configured for user
dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve:
User has no personal script

I'll check on 0.4.6 and report if I see anything interesting,
but I will assume for the moment that since personal scripts
work in 0.4.6 that this log info won't be there. It is correct that
there is no "sieve" file or directory in the user's home dir. 
This
wasn't a problem in 0.4.6.  Is it a requirement?

Also, if you didn't see my post a few days ago, while I have your
attention, I thank you for the extdata plugin and vote to keep it
alive.  Only caveat is I hope to see the dict mechanism in Dovecot
become more flexible... at a minimum, would like to be able to pass
at least one parameter (beside the implicit username) and indicate
what field to test it against (I would like at least a simply-configured
WHERE clause) if not full query customization.  :)  Perhaps not easy
stuff, but extdata as is still helps me out.


doveconf -n


# 2.2.16.rc1: /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.7.rc1 (c74220e16e0f+)
# OS: Linux 3.10.0-123.20.1.el7.x86_64 x86_64 CentOS Linux release 7.0.1406
(Core)  xfs
dict {
  sieve = mysql:/usr/local/etc/dovecot/pigeonhole-sql.dict.ext
}
mail_location = mdbox:/vmail/%d/%1Mn/%1.1Mn/%n
mail_plugins = " zlib"
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
namespace inbox {
  inbox = yes
  location   mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Junk {
    auto = subscribe
    special_use = \Junk
  }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  }
  prefix }
passdb {
  args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
  driver = sql
}
plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /usr/local/var/dovecot/sieve/
  sieve_execute_bin_dir = /usr/local/var/dovecot/sieve-extscripts/
  sieve_extdata_dict_uri = proxy::sieve
  sieve_global_extensions = +vnd.dovecot.extdata +vnd.dovecot.execute
  sieve_plugins = sieve_extdata sieve_extprograms
  zlib_save = gz
  zlib_save_level = 9
}
service auth-worker {
  user = $default_internal_user
}
service dict {
  unix_listener dict {
    group = vmail
    mode = 0660
  }
}
service imap-login {
  inet_listener imap {
    address = 127.0.0.1
  }
}
service lmtp {
  inet_listener lmtp {
    address = 127.0.0.1
    port = 24
  }
}
ssl_cert = </path/to/my/server/cert
ssl_key = </path/to/my/server/key
userdb {
  driver = prefetch
}
userdb {
  args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
  driver = sql
}
protocol lmtp {
  mail_plugins = " zlib sieve"
}

On 3/11/2015 3:16 AM, E.B. wrote:
>>>> Last time I had a few stupid problems in the releases, so
>>>> I'll follow
>>>> Timo's example and I release an RC first.
>>>>
>>>> The highlights include the implementation of the index and
>>>> metadata
>>>> extensions. Quite a few bugs are fixed as well.
>>> When I compiled and installed this, Sieve scripts were being
ignored. Not
>>> sure if it's my own stupid mistake, but when I put v0.4.6 back
in place, it
>>> worked fine. No configuration changes, only make install on the
different
>>> sources and restart dovecot.
>> Could you show your dovecot -n output?
>>
>> Also, if you enable mail_debug, what sieve-related debug lines are
shown?
> OK, I re-tested and it's still ignoring personal scripts (but not
> global ones).  No .svbin gets generated, no errors, just nothing.
> However, I do see that Sieve was accessing the user home directory
> because for some reason now it just created a ".pki" directory
> therein, which inside of it has an empty "nssdb" directory.  That
> never happened before...?  Not a big problem, but I'd prefer not
> to have that there.
Sieve doesn't do that. I don't think Dovecot does that either, but I am
not sure.
> Re: mail_debug, this relates to another post I made that didn't get any
> replies - can I not override settings such as that (and log_path) from
> a userdb lookup?  Hmm, I WAS able to override mail_debug from userdb,
> but not log_path?
>
> Sieve-related mail_debug, then?
>
> This looks like the relevant log info:
>
> dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA:
sieve: file storage: Storage path `/vmail/example.com/testuser/sieve' not
found
> dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA:
sieve: No default script configured for user
> dovecot: lmtp(testuser at example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA:
sieve: User has no personal script
>
> I'll check on 0.4.6 and report if I see anything interesting,
> but I will assume for the moment that since personal scripts
> work in 0.4.6 that this log info won't be there. It is correct that
> there is no "sieve" file or directory in the user's home dir.
This
> wasn't a problem in 0.4.6.  Is it a requirement?
Well, since your config says the following:

sieve = file:~/sieve;active=~/.dovecot.sieve

It expects a sieve storage directory at ~/sieve (created when
ManageSieve is used to upload a script).
Also, a symbolic link pointing to the active script will be located at
~/.dovecot.sieve once a script is activated (i.e. through ManageSieve or
doveadm sieve).

I wonder how this would have worked before with 0.4.6. Is the
~/.dovecot.sieve a normal script file perhaps (rather than a symlink)?
This would mean that the following config would work (e.g. if you don't
use ManageSieve):

sieve = file:~/.dovecot.sieve

> Also, if you didn't see my post a few days ago, while I have your
> attention, I thank you for the extdata plugin and vote to keep it
> alive.  Only caveat is I hope to see the dict mechanism in Dovecot
> become more flexible... at a minimum, would like to be able to pass
> at least one parameter (beside the implicit username) and indicate
> what field to test it against (I would like at least a simply-configured
> WHERE clause) if not full query customization.  :)  Perhaps not easy
> stuff, but extdata as is still helps me out.
I haven't looked at that plugin in a while. I could add it to the main
pigeonhole package, since it doesn't depend on anything else. It is
still a work in progress though, so don't expect the syntax of the
extensions to remain the same in the future when I would continue
development.

I don't know whether it is acceptable to change the dict functionality
like that. Timo will know...

Regards,

Stephan.