Hi Aki
I really appreciate that overview. I'm going to migrate my mail servers soon
from Dovecot 2.3 to 2.4 and finally upgrade them to Debian Trixie.
I'm still a bit confused about mail_home. Is that conversion correct?
<= 2.3
mail_home = /var/vmail/%d/%n
mail_location = sdbox:~/sdbox
mail_uid = vmail
mail_gid = vmail
=> 2.4
mail_driver = sdbox
mail_home = /var/vmail/%{user | domain}/%{user | username}
mail_path = %{home}/sdbox
mail_uid = vmail
mail_gid = vmail
I'm asking because I have an environment with mixed usernames, legacy usernames
without domain (e.g. web123p1) vs. regular email usernames (e.g.
[email protected]).
With above 2.4 mail_home config, would POSIX path normalisation care about the
// on legacy usernames?
It should match my existing structure (running for over 6yrs on Dovecot):
web123p1 -> /var/vmail/web123p1
[email protected] -> /var/vmail/example.com/foo
So, I would not need to care about the resulting double slash
(/var/vmail//web123p1) because of the missing domain in web123p1?
I also depend on auto-creation of mailbox directory structure when a new
virtual user is accessed the first time (authenticated via MySQL passdb). Will
that magically just work with above config, without enabling any extra
"auto-create" flag?
Somewhere in your docs, I read about relative paths not being "future-proof".
Can those two be equally used und ~ is not considered "relative"?
mail_path = %{home}/sdbox
vs.
mail_path = ~/sdbox
(will probably never ever change the home of vmail system user, but who
guarantees that this config is really read by vmail and not root?)
Thanks a lot.
Cheers,
Philip
> On 10 Dec 2025, at 13:10, Aki Tuomi via dovecot <[email protected]> wrote:
>
> Hi!
>
> We've been noticing that many people are configuring mail_inbox_path.
>
> I assume that for most people this is because debian decided to include it in
> their default config, so that it would use /var/mail boxes for user INBOXes.
>
> If your inbox *does not* reside in some weird location, you should *not* set
> this setting to any value, instead you can either ensure it's commented out,
> or set to empty value. IN PARTICULAR, IT IS **NOT** REQUIRED SETTING.
>
> Setting it to some random weird value like '.' will just cause Problems,
> setting it to $MAIL_HOME/ or something else will just be either pointless or
> cause problems.
>
> Some most common conversions (please adjust to your environment)
>
> mail_home= /home/vmail/%u
> =>
> mail_home = /home/vmail/%{user}
>
> mail_home = /home/vmail/%d/%u
> =>
> mail_home = /home/vmail/%{user|domain}/%{user|username}
> or some variant of this.
>
> mail_location = maildir:~/
> =>
> mail_path = ~/
> mail_driver = maildir
>
> mail_location = maildir:/var/srv/foo/%d/%u
> =>
> mail_path = /var/srv/foo/%{user|domain}/%{user|username}
> mail_driver = maildir
>
> In addition you might want to convert
>
> INDEX=~/.index
> =>
> mail_index_path=~/.index
>
> CONTROL=~/.control
> =>
> mail_control_path=~/.control
>
> LAYOUT=fs
> =>
> mailbox_list_layout=fs
>
> A minimal working config is
>
> mail_home=/home/vmail/%{user}
> mail_driver=maildir
> mail_path=~/maildir
> mail_uid=vmail
> mail_gid=vmail
>
> ##
>
> If you have settings like
>
> namespace other {
> location = maildir:/foo/bar
> }
>
> this converts into
>
> namespace other {
> mail_path = /foo/bar
> # optional, if this is matches your top level
> mail_driver = maildir
> }
>
> Hope this clears out some of the confusion.
>
> Aki
>
> _______________________________________________
> dovecot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
