maildirfolder file created in maildir root during auto-creation with 2.3.4.1 but not 2.2.27
Hello,
as the tin says. I have several servers running 2.2.27 (Debian stretch) and am adding new ones with 2.3.4.1 (Debian buster). The configs were upgraded where needed but neither 10-mail.conf nor 15-mailboxes.conf were changed. 15-mailboxes is all commented out (I guess the default is auto-create, which isn't documented anywhere I could find) and the only non-comments in 10-mail.conf are
mail_location = maildir:%h mail_privileged_group = mail
So yes, no namespaces are explicitly defined/declared.
The 2.3.4.1 version wrongly creates a maildirfolder file in the home directory (maildir root), preventing exim from correctly creating/using maildirsize.
a) Is this expected behavior and can it be changed? b) How can I disable inbox auto-creation if a) doesn't pan out?
Thanks,
Christian
Christian Balzer Network/Systems Engineer
chibi@gol.com Rakuten Mobile Inc.
Hello,
On Wed, 5 Feb 2020 08:58:29 +0200 Aki Tuomi wrote:
Can you provide full doveconf -n output? Also how are you delivering mail?
As pretty much implied, Exim is delivering mails, w/o problems. And if it gets to create the home directory, everything is fine and maildirsize gets put there.
But if the first access is via the newer dovecot the bogus maildirfolder file gets created in the home directory and prevents Exim (and itself?) from putting a maildirsize there.
My bet is that that something in the auto-create logic changed or the "mail_home" needing to be set explicitly instead of defaulting to mail_location if unset, etc.
Redacted and relevant parts only:
2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
Pigeonhole version 0.5.4 ()
OS: Linux 4.19.0-6-amd64 x86_64 Debian 10.2
Hostname: testbox.gol.com
auth_default_realm = gol.com default_client_limit = 16384 default_process_limit = 1024 first_valid_uid = 8 imap_hibernate_timeout = 30 secs imap_idle_notify_interval = 8 mins imap_logout_format = in=%i out=%o head=<%{fetch_hdr_count}> del=<%{deleted}> exp=<%{expunged}> trash=<%{trashed}> session=<%{session}> login_trusted_networks = some.net.work mail_gid = 8 mail_location = maildir:%h mail_privileged_group = mail mail_uid = 8 mailbox_idle_check_interval = 1 mins maildir_very_dirty_syncs = yes
passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { quota = maildir:User quota_rule = ?:storage=200M quota_rule2 = Trash:storage=+50M sieve = file:~/sieve;active=~/.dovecot.sieve }
userdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } verbose_proctitle = yes protocol imap { mail_max_userip_connections = 40 mail_plugins = quota imap_quota } protocol pop3 { mail_plugins = quota }
Regards,
Christian
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Rakuten Mobile Inc.
Hello,
it is now nearly 2 years later and we are running 2.3.13 with this bug still present. Would be nice if it were acknowledged at least if not even fixed. And it was confirmed by other people who contacted me directly after seeing the original report here.
Regards,
Christian
On Wed, 5 Feb 2020 16:13:37 +0900 Christian Balzer wrote:
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Rakuten Communications
Hello,
thanks for the reply.
On Thu, 2 Sep 2021 12:47:43 +0300 (EEST) Aki Tuomi wrote:
Would it be possible to workaround this with:
mail_location = maildir:~/Mail/
Maybe, but that is not feasible in our deployment, which is LDAP driven and thus looks like this: mail_location = maildir:%h
Changing this in-situ by attaching a "/Mail/" to the location for literally hundreds of thousands mailboxes clearly is a no-go, nor would I look forward to go fix up all the other places and scripts that assume a certain directory structure.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Rakuten Communications
participants (2)
-
Aki Tuomi
-
Christian Balzer