Re: Upgrading to v2.3.X breaks ssl san?
On 07/08/2019 00:37 Joseph Tam via dovecot < dovecot@dovecot.org> wrote: On Tue, 6 Aug 2019, telsch wrote: if i cat ssl_ca and ssl_cert into one file and only use ssl_cert it's working with 2.3.X ssl_ca = In the words of Montoya, "I do not think it means what you think it means", referring to "ssl_ca". That file is not used to to establish the trust chain to your server certificate, but rather, to your client's certificates (e.g. if you run a local CA to issue user certificate for mutual authentication, you would put your local CA certificate here). (Maybe this config variable should be renamed "ssl_client_ca".) ... except there already is ssl_client_ca_* settings used to validate connections from dovecot. Appending intermediate and server certificates is what you're supposed to do. Joseph Tam < jtam.h...@gmail.com> --- Aki Tuomi
Re: Upgrading to v2.3.X breaks ssl san?
On Tue, 6 Aug 2019, telsch wrote: if i cat ssl_ca and ssl_cert into one file and only use ssl_cert it's working with 2.3.X ssl_ca = In the words of Montoya, "I do not think it means what you think it means", referring to "ssl_ca". That file is not used to to establish the trust chain to your server certificate, but rather, to your client's certificates (e.g. if you run a local CA to issue user certificate for mutual authentication, you would put your local CA certificate here). (Maybe this config variable should be renamed "ssl_client_ca".) Appending intermediate and server certificates is what you're supposed to do. Joseph Tam
Re: Problem Solr and centos 7
On 8/5/2019 12:02 PM, HTMLServices.it via dovecot wrote: Given that I am not an expert, I am doing tests with Solr, I installed following the guide but I have no benefits on the search, the search on the body on 28000 mails takes a few minutes and then goes to timeout. If the problems you're having are with Solr itself and not fts_solr, then the Solr mailing list or IRC channel is probably a better place to get help. https://lucene.apache.org/solr/community.html#mailing-lists-irc The following info, combined with your document count of 28000, will be very useful: https://cwiki.apache.org/confluence/display/solr/SolrPerformanceProblems#SolrPerformanceProblems-Askingforhelponamemory/performanceissue When gathering the screenshot, be sure that the process listing is sorted as described. With no other info to go on, I suspect that maybe your Solr install is still configured with a 512MB heap and that the heap size needs to be increased to handle the index you've built. I did several tests but I can't get it to work, this is the test server link: http://5.39.2.59:8987/solr/#/ If you have configured fts_solr with a URL that contains a # character, it's never going to work. URLs containing # are only usable in a browser and will not function correctly anywhere else. Thanks, Shawn
Re: Dovecot replication and userdb "noreplicate".
On 06.08.2019 23:17, Reio Remma via dovecot wrote:
On 24.06.2019 16:25, Reio Remma wrote:
On 24.06.2019 8:21, Aki Tuomi wrote:
On 22.6.2019 22.00, Reio Remma via dovecot wrote:
Jun 22 16:55:22 host dovecot: dsync-local(u...@host.ee)<>: Error:
Remote command returned error 84: ssh -i /home/vmail/.ssh/vmail.pem -l
vmail backup.host.ee doveadm dsync-server -D -uu...@host.ee
PS: Getting SSH for Dovecot to work with SELinux on CentOS 7 was fun
as usual. :)
Dovecot under selinux works, as long as you do it the way the policy
writer intended, seehttps://linux.die.net/man/8/dovecot_selinux
Aki
For replication over SSH I had to add the following module:
module selinux-dovecot-replication-ssh 1.0;
require {
type ssh_exec_t;
type ssh_home_t;
type dovecot_t;
class file { open read execute execute_no_trans };
class dir { getattr search };
}
#= dovecot_t ==
allow dovecot_t ssh_exec_t:file { open read execute execute_no_trans };
allow dovecot_t ssh_home_t:dir { getattr search };
allow dovecot_t ssh_home_t:file { open read };
ssh_exec_t to allow Dovecot to use ssh executable in the first place
and ssh_home_t:dir + ssh_home_t:file for it to be able to read
known_hosts from /root/.ssh
Reio
To cut down on selinux exceptions I put the destination host in
/etc/ssh/ssh_known_hosts and dovecot successfully replicates, however
I get the following log entry for every replicator action:
Aug 6 22:25:59 turin dovecot: doveadm: Error: Could not create
directory '/root/.ssh'.
Replication is set up with the user vmail (/home/vmail and SSH key in
/home/vmail/.ssh) and the minimum selinux rule to get Dovecot to read
the key is:
allow dovecot_t ssh_exec_t:file { execute execute_no_trans open read };
Is there a way I can change from root to vmail user for creating the
SSH connection?
Doveconf below:
# 2.3.7.1 (0152c8b10): /etc/dovecot/dovecot.conf
service doveadm {
inet_listener http {
address = localhost
port = 8080
}
}
service doveadm {
user = vmail
}
This seems to have fixed it. Here's hoping for no unforeseen
side-effects. :)
I still need allow dovecot_t ssh_exec_t:file { execute execute_no_trans
open read }; for selinux, but there are no more errors in maillog and it
can read both the key and known_hosts (from either
/home/vmail/.ssh/known_hosts or /etc/ssh/ssh_known_hosts).
Reio
Re: Dovecot replication and userdb "noreplicate".
On 24.06.2019 16:25, Reio Remma wrote:
On 24.06.2019 8:21, Aki Tuomi wrote:
On 22.6.2019 22.00, Reio Remma via dovecot wrote:
Jun 22 16:55:22 host dovecot: dsync-local(u...@host.ee)<>: Error:
Remote command returned error 84: ssh -i /home/vmail/.ssh/vmail.pem -l
vmail backup.host.ee doveadm dsync-server -D -uu...@host.ee
PS: Getting SSH for Dovecot to work with SELinux on CentOS 7 was fun
as usual. :)
Dovecot under selinux works, as long as you do it the way the policy
writer intended, seehttps://linux.die.net/man/8/dovecot_selinux
Aki
For replication over SSH I had to add the following module:
module selinux-dovecot-replication-ssh 1.0;
require {
type ssh_exec_t;
type ssh_home_t;
type dovecot_t;
class file { open read execute execute_no_trans };
class dir { getattr search };
}
#= dovecot_t ==
allow dovecot_t ssh_exec_t:file { open read execute execute_no_trans };
allow dovecot_t ssh_home_t:dir { getattr search };
allow dovecot_t ssh_home_t:file { open read };
ssh_exec_t to allow Dovecot to use ssh executable in the first place
and ssh_home_t:dir + ssh_home_t:file for it to be able to read
known_hosts from /root/.ssh
Reio
To cut down on selinux exceptions I put the destination host in
/etc/ssh/ssh_known_hosts and dovecot successfully replicates, however I
get the following log entry for every replicator action:
Aug 6 22:25:59 turin dovecot: doveadm: Error: Could not create
directory '/root/.ssh'.
Replication is set up with the user vmail (/home/vmail and SSH key in
/home/vmail/.ssh) and the minimum selinux rule to get Dovecot to read
the key is:
allow dovecot_t ssh_exec_t:file { execute execute_no_trans open read };
Is there a way I can change from root to vmail user for creating the SSH
connection?
Doveconf below:
# 2.3.7.1 (0152c8b10): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.7.1 (db5c74be)
# OS: Linux 4.4.186-1.el7.elrepo.x86_64 x86_64 CentOS Linux release
7.6.1810 (Core)
# Hostname: turin.mrstuudio.ee
doveadm_api_key = # hidden, use -P to show it
dsync_remote_cmd = ssh -i /home/vmail/.ssh/vmail.pem -l %{login} %{host}
doveadm dsync-server -u %u
mail_gid = vmail
mail_home = /home/vmail/%d/%n
mail_location = maildir:~/Maildir
mail_log_prefix = "%s(%u): "
mail_plugins = quota notify replication
mail_uid = vmail
mbox_write_locks = fcntl
namespace inbox {
inbox = yes
location =
mailbox "Deleted Messages" {
auto = no
special_use = \Trash
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Junk {
auto = no
special_use = \Junk
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox "Sent Messages" {
auto = no
special_use = \Sent
}
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix = INBOX.
separator = .
type = private
}
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
plugin {
mail_replica = remote:vmail@replica
}
protocols = imap lmtp
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service doveadm {
inet_listener http {
address = localhost
port = 8080
}
}
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
port = 993
ssl = yes
}
}
service lmtp {
executable = lmtp -L
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0600
user = vmail
}
}
service stats {
unix_listener stats-writer {
mode = 0666
}
}
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
default_fields = uid=vmail gid=vmail
driver = sql
}
protocol lmtp {
mail_plugins = quota notify replication
}
protocol imap {
imap_capability = +SPECIAL-USE
imap_metadata = yes
mail_max_userip_connections = 50
mail_plugins = quota notify replication imap_quota
namespace inbox {
location =
mailbox Ham {
autoexpunge = 365 days
}
mailbox Spam {
autoexpunge = 365 days
}
mailbox Trash {
autoexpunge = 180 days
}
prefix =
}
}
Thanks!
Reio
Re: Upgrading to v2.3.X breaks ssl san?
> On 06/08/2019 22:49 telsch via dovecot wrote: > > > Hello, > > using letsencrypt ssl certs with san works perfectly with 2.2.34, but > after uprading to 2.3.4.1 it couldn't verified (also tried v2.3.7.1). > > i connect to imap.myserver.lan > > the cn of the cert is myserver.lan and has the san imap.myserver.lan > > openssl s_client -connect imap.myserver.lan:993 > CONNECTED(0005) > depth=0 CN = imap.myserver.lan > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = imap.myserver.lan > verify error:num=21:unable to verify the first certificate > verify return:1 > --- > Certificate chain > 0 s:CN = imap.myserver.lan > i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > > > if i cat ssl_ca and ssl_cert into one file and only use ssl_cert it's working > with 2.3.X > > ssl_ca = ssl_cert =
Upgrading to v2.3.X breaks ssl san?
Hello, using letsencrypt ssl certs with san works perfectly with 2.2.34, but after uprading to 2.3.4.1 it couldn't verified (also tried v2.3.7.1). i connect to imap.myserver.lan the cn of the cert is myserver.lan and has the san imap.myserver.lan openssl s_client -connect imap.myserver.lan:993 CONNECTED(0005) depth=0 CN = imap.myserver.lan verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = imap.myserver.lan verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:CN = imap.myserver.lan i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 if i cat ssl_ca and ssl_cert into one file and only use ssl_cert it's working with 2.3.X ssl_ca = ssl_cert =
Re: [BUG?] Double quota calulation when special folder is present
On Tue, Apr 9, 2019 at 9:52 PM Aki Tuomi wrote:
>
> On 10 April 2019 05:00 Mark Moseley via dovecot
> wrote:
>
>
> On Wed, Apr 3, 2019 at 9:37 PM Mark Moseley < moseleym...@gmail.com>
> wrote:
>
>
> On Wed, Mar 20, 2019 at 2:13 PM Mark Moseley < moseleym...@gmail.com>
> wrote:
>
> Just hoping to get some dev eyes on this. I'm incredibly reluctant to
> throw the word 'bug' around
> (since 99 times out of 100, it's not -- it's almost always the config),
> but I can't think of any way
> that this could be a config issue, esp when the pre-2.2.34 version works
> as expected.
>
> I noticed during troubleshooting that dovecot errors out if I try to
> create a subfolder called
> 'INBOX' but it'll happily create a subfolder called INBOX.SomethingElse
> (i.e. a folder called
> INBOX.INBOX.SomethingElse - resulting in a directory called
> .INBOX.SomethingElse on the
> filesystem, and leading to the problem described below). Is that
> sub-subfolder creation (where
> the top level subfolder matches the namespace name) supposed to be
> allowed? It seems
> odd that 'INBOX' (as a subfolder of INBOX) would be blocked but
> INBOX.SomethingElse (as
> a subfolder of INBOX) would be allowed. I'd expect INBOX.SomethingElse
> (i.e.
> INBOX.INBOX.SomethingElse) would be blocked as well.
>
>
> On Wed, Mar 13, 2019 at 4:46 AM Bernd Wurst via dovecot <
> dovecot@dovecot.org> wrote:
>
> Hello,
>
> we're operating dovecot on a small server. Some years ago, we migrated
> from courier IMAP to dovecot. Therefore, we defined our default
> Namespace "inbox" with prefix "INBOX." to have this compatible. I found
> this in some migration docs those days. Generally, everything worked as
> expected.
>
> Our only namespace is configured like this:
>
> namespace inbox {
> separator = .
> prefix = INBOX.
> inbox = yes
> }
>
> Regularly, there is no folder named INBOX or .INBOX in the file system,
> I suppose this is correct. But I found a special corner case today when
> it comes to quota calculation.
>
> When - for whatever reason - a folder .INBOX.foo (for arbitrary values
> of foo) exists, the whole mailbox is counted twice in quota
> recalculation. Just creating .INBOX does nothing but a subfolder
> triggers the problem.
>
> This is my shell view (replaced username and file path and deleted
> unnecessary debug output)
>
> $ cat maildirsize
> 268435456S
> 14697 17
> $ maildirmake .INBOX.foo
> $ sudo doveadm -D quota recalc -u
> [...]
> doveadm(): Debug: Namespace inbox: type=private, prefix=INBOX.,
> sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes
> location=maildir:/home/.../test
> doveadm(): Debug: maildir++: root=/home/.../test, index=,
> indexpvt=, control=, inbox=/home/.../test, alt=
> doveadm(): Debug: Namespace : type=private, prefix=, sep=,
> inbox=no, hidden=yes, list=no, subscriptions=no location=fail::LAYOUT=none
> doveadm(): Debug: none: root=, index=, indexpvt=, control=,
> inbox=, alt=
> doveadm(): Debug: quota: quota_over_flag check: quota_over_script
> unset - skipping
> doveadm(): Debug: Quota root User quota: Recalculated relative
> rules with bytes=268435456 count=0. Now grace=26843545
> doveadm(): Debug: Namespace INBOX.: Using permissions from
> /home/.../test: mode=0700 gid=default
>
> $ cat maildirsize
> 268435456S
> 29394 34
>
>
> So the used quota has exactly been doubled by just creating an empty
> subfolder.
>
> Do you have any pointers for fixing my configuration or is this a bug in
> dovecot?
>
>
> I coincidentally resurrected a months-old thread with this same issue a
> few days ago. I'm seeing the exact same after upgrading from 2.2.32 to
> 2.2.36.
>
> The original poster (who also narrowed it down to something in 2.2.34)
> mentioned a workaround that does indeed work, namely setting
> mailbox_list_index=no:
>
> > doveadm -o 'mailbox_list_index=no' quota recalc -u myuser
>
> I've been staring at diffs of 2.2.33 and 2.2.34 without anything jumping
> out at me (not a C guy, sadly). Maybe src/lib-storage/index/index-storage.c
> or src/lib-storage/list/mailbox-list-fs-iter.c or
> src/lib-storage/list/mailbox-list-index-iter.c
> or src/lib-storage/list/mailbox-list-index.c?
>
> The latter few have some added strcmp's against "INBOX". Then again,
> there's a lot of new code in the diffs under src/lib-storage that
> references INBOX specifically.
>
>
> Can the Dovecot team confirm whether this is indeed a bug or not? I've
> not yet been able to test 2.3.x to see if the problem exists there as well.
>
>
> I've bisected this down to this commit:
>
> git diff
> 7620195ceeea805137cbd1bae104e385eee474a9..97473a513feb2bbd763051869c8b7b83e24b37fa
>
>
> diff --git a/src/lib-storage/list/mailbox-list-index-iter.c
> b/src/lib-storage/list/mailbox-list-index-iter.c
> index c9afc7a..49cd941 100644
> --- a/src/lib-storage/list/mailbox-list-index-iter.c
> +++ b/src/lib-storage/list/mailbox-list-index-iter.c
> @@ -90,13 +90,18 @@ mailbox_list_index_update_info(struct
> mailbox_list_index_iterate_context *ctx)
>
Re: Dovecot Sieve doesn't move spam to Junk folder in maildir
Am 2019-08-06 15:04, schrieb Nagy Tibor via dovecot: I have an *Ubuntu 16.04* mail server with postfix/spamassassin/*dovecot-2.2.2**2* with virtual mailboxes in maildir format. The whole process is working excellently since a year. Spams are marked with "*SPAM*" in subject and with "X-Spam-Flag: YES" in email header. I tried now to add sieve to dovecot to move the SPAM messages into the Junk folder without any success, I don't see any sign that sieve does something at all. The output of "dovecot -n": [ ... ] Jul 30 20:05:13 zg-3 postfix/cleanup[4450]: 5F7FEA3CBC: message-id= Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 5F7FEA3CBC: from=, size=3304, nrcpt=1 (queue active) Jul 30 20:05:13 zg-3 postfix/virtual[4455]: 5F7FEA3CBC: to=, relay=virtual, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir) Your Postfix does not deliver via dovecot's LDA, thus sieve never gets called. Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 5F7FEA3CBC: removed What can be wrong? Alexander
Dovecot Sieve doesn't move spam to Junk folder in maildir
I have an *Ubuntu 16.04* mail server with
postfix/spamassassin/*dovecot-2.2.2**2* with virtual mailboxes in maildir
format. The whole process is working excellently since a year. Spams are marked
with "*SPAM*" in subject and with "X-Spam-Flag: YES" in email header.
I tried now to add sieve to dovecot to move the SPAM messages into the Junk
folder without any success, I don't see any sign that sieve does something at
all. The output of "dovecot -n":
# 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.13 (7b14904)
# OS: Linux 4.4.0-72-generic x86_64 Ubuntu 16.04.2 LTS ext4
auth_mechanisms = cram-md5
auth_verbose = yes
base_dir = /var/run/dovecot/
info_log_path = /var/log/dovecot.info
log_path = /var/log/dovecot
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:/home/vmail/%d/%n
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
mime foreverypart extracttext
namespace {
inbox = yes
location =
prefix =
separator = /
}
passdb {
args = /etc/dovecot/passwd
driver = passwd-file
}
plugin {
sieve = /etc/dovecot/sieve/default.sieve
}
protocols = imap pop3
service auth {
executable = /usr/lib/dovecot/auth
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
user = root
}
service imap-login {
chroot = login
executable = /usr/lib/dovecot/imap-login
inet_listener imap {
port = 0
}
user = dovecot
}
service imap {
executable = /usr/lib/dovecot/imap
}
service pop3-login {
chroot = login
executable = /usr/lib/dovecot/pop3-login
inet_listener pop3 {
port = 0
}
inet_listener pop3s {
port = 0
}
user = dovecot
}
service pop3 {
executable = /usr/lib/dovecot/pop3
}
ssl_cert = The test SPAM message is marked as SPAM, but not moved to the folder Junk. I
don't see anything in mail.log that is associated to sieve.:
ul 30 20:05:12 zg-3 postfix/smtpd[4446]: connect from
smtp4.enternet.hu[62.112.192.37]
Jul 30 20:05:13 zg-3 postfix/smtpd[4446]: 3C4CC9F570:
client=smtp4.enternet.hu[62.112.192.37]
Jul 30 20:05:13 zg-3 postfix/cleanup[4450]: 3C4CC9F570:
message-id=
Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 3C4CC9F570: from=,
size=918, nrcpt=1 (queue active)
Jul 30 20:05:13 zg-3 postfix/smtpd[4446]: disconnect from
smtp4.enternet.hu[62.112.192.37] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1
commands=7
Jul 30 20:05:13 zg-3 postfix/pickup[3949]: 5F7FEA3CBC: uid=1003
from=
Jul 30 20:05:13 zg-3 postfix/pipe[4451]: 3C4CC9F570: to=,
relay=spamassassin, delay=0.15, delays=0.05/0.01/0/0.1, dsn=2.0.0, status=sent
(delivered via spamassassin service)
Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 3C4CC9F570: removed
Jul 30 20:05:13 zg-3 postfix/cleanup[4450]: 5F7FEA3CBC:
message-id=
Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 5F7FEA3CBC: from=,
size=3304, nrcpt=1 (queue active)
Jul 30 20:05:13 zg-3 postfix/virtual[4455]: 5F7FEA3CBC: to=,
relay=virtual, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent
(delivered to maildir)
Jul 30 20:05:13 zg-3 postfix/qmgr[1557]: 5F7FEA3CBC: removed
What can be wrong?
Re: Emails not visible after renaming folders
Hi guys.
Does anyone have problems with a similar configuration (mdbox)?
Just tested with latest version (stage servers installation: dovecot 2.3.7),
also affected.
Not critical, but have complaints from users, 1-2 per month.
26.06.2019 12:05, Aleksandr пишет:
> Copying or moving with email client: thunderbird, roundcube (webmail), mutt
> or any other email client via imap protocol.
>
> 25.06.2019 22:10, Germán Herrera пишет:
>> Are you copying/moving the emails with {cp|mv} or with "doveadm {copy|move}"?
>>
>> On 2019-06-25 12:00, Aleksandr via dovecot wrote:
>>> Hello,
>>>
>>> I have strange problem with "losing" emails after rename mail
>>> folder(s) (via imap client: thunderbird, roundcude, etc..)
>>>
>>> How to reproduce:
>>>
>>> 1. Create some folder name, like TEST
>>> 2. Create sub-folder under TEST (like SUBTEST)
>>>
>>> Structure:
>>>
>>> TEST
>>> |--SUBTEST
>>>
>>>
>>> # doveadm mailbox list -u postmaster@testmailbox
>>> Spam
>>> Trash
>>> Sent
>>> Drafts
>>> INBOX
>>> TEST
>>> TEST/SUBTEST
>>>
>>> 3. Move (or copy) mails from INBOX to SUBTEST (all looks fine, and
>>> mails visible under SUBTEST)
>>> 4. Rename TEST folder to any new name, NEWTEST
>>>
>>> Let`s try to view mails in mail client in NEWTEST-SUBTEST, folder have
>>> no emails :(
>>>
>>>
>>> mailsrv# doveadm -f table mailbox status -u postmaster@testmailbox
>>> "messages vsize" NEWTEST*
>>> mailbox messages vsize
>>> NEWTEST 0 0
>>> NEWTEST/SUBTEST 0 0
>>>
>>> If doveadm force-resync postmaster@testmailbox, mails will be visible in
>>> INBOX
>>>
>>> mailsrv# doveadm -f table mailbox status -u postmaster@testmailbox
>>> "messages vsize" INBOX*
>>> mailbox messages vsize
>>> INBOX 2 28
>>>
>>> Dovecot installation: CentOS x86_64 Linux 7.5.1804
>>>
>>> Storage: HDD Local Partition - XFS filesystem / multi-dbox (mdbox) as
>>> mail_storage (this problem is not reproduced with the settings as
>>> Maildir storage !)
>>> somthing wrong with mapping indices.
>>>
>>>
>>> [start]
>>>
>>> # dovecot -n
>>>
>>> # 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
>>> # Pigeonhole version 0.4.21 (92477967)
>>> # OS: Linux 3.10.0-862.2.3.el7.x86_64 x86_64 CentOS Linux release
>>> 7.5.1804 (Core)
>>> # Hostname:
>>> auth_mechanisms = plain login digest-md5 cram-md5
>>> base_dir = /var/run/dovecot/
>>> default_client_limit = 2
>>> default_login_user = dovecot
>>> default_process_limit = 1
>>> dict {
>>> quota = redis:host=127.0.0.1:prefix=user/:timeout_msecs=1000
>>> }
>>> disable_plaintext_auth = no
>>> first_valid_gid = 90
>>> first_valid_uid = 90
>>> imapc_features = rfc822.size fetch-headers
>>> imapc_host =
>>> imapc_user = %u
>>> lda_mailbox_autocreate = yes
>>> lda_mailbox_autosubscribe = yes
>>> login_greeting = .
>>> login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c
>>> login_trusted_networks = 10.0.1.0/24
>>> mail_access_groups = mail
>>> mail_debug = yes
>>> mail_fsync = never
>>> mail_gid = 97
>>> mail_location =
>>> mdbox:~/mail/mailboxes:FULLDIRNAME=mBoX-MeSsAgEs:INDEX=~/mail/index:CONTROL=~/mail/control:INBOX=~/mail/mailboxes/inbox
>>> mail_log_prefix = "%{session} %Us(%u): "
>>> mail_max_lock_timeout = 30 secs
>>> mail_plugins = quota zlib
>>> mail_prefetch_count = 20
>>> mail_privileged_group = mail
>>> mail_uid = 97
>>> managesieve_notify_capability = mailto
>>> managesieve_sieve_capability = fileinto reject envelope
>>> encoded-character vacation subaddress comparator-i;ascii-numeric
>>> relational regex imap4flags copy include variables enotify environment
>>> mailbox date index ihave duplicate mime foreverypart extracttext
>>> vacation-seconds editheader
>>> mbox_lock_timeout = 30 secs
>>> mbox_very_dirty_syncs = yes
>>> mbox_write_locks = fcntl
>>> namespace inbox {
>>> inbox = yes
>>> list = yes
>>> location =
>>> mailbox Drafts {
>>> auto = subscribe
>>> special_use = \Drafts
>>> }
>>> mailbox Sent {
>>> auto = subscribe
>>> special_use = \Sent
>>> }
>>> mailbox Spam {
>>> auto = subscribe
>>> }
>>> mailbox Trash {
>>> auto = subscribe
>>> special_use = \Trash
>>> }
>>> prefix =
>>> separator = /
>>> type = private
>>> }
>>> passdb {
>>> args = /etc/dovecot/dovecot-ldap.conf
>>> driver = ldap
>>> }
>>> plugin {
>>> cgroup_basedir = /usr/sys/cgroup
>>> hostingAccount = default
>>> quota = dict:User quota::proxy::quota
>>> quota_grace = 0%%
>>> quota_over_flag_value = TRUE
>>> quota_over_script = account-quota mismatch %u
>>> quota_rule = *:storage=4T
>>> quota_warning = storage=101%% account-quota block %u
>>> quota_warning1 = -storage=100%% account-quota unblock %u
>>> sieve = file:~/sieve;active=~/.dovecot.sieve
>>> sieve_before = /home/sieve/%d/
>>> sieve_extensions = +editheader +vacation-seconds -body
>>> sieve_max_redirects = 200
>>> sieve_vacation_min_period = 1s
>>> trash_folder = Trash
>>> zlib_save = lz4
>>> zlib_save_level = 6
>>> }
