Hi rob0,
Quoting /dev/rob0 26/08/2013 15:17,
mail_location: mbox:~/mail/:INBOX=/var/mail/%u mail_location: mbox:/var/spool/virtual/%d/%n.imap:INBOX=/var/spool/virtual/%d/%n
This exercise becomes trivial when you follow the advice of the Dovecot wiki and give your virtual users a $HOME. (Well, to be simple, you'd also have to have INBOX in $HOME. An alternative is to specify INBOX for virtual users in your virtual userdb.)
Thank for your answer. Are you referring to the VirtualUsers page? (http://wiki.dovecot.org/VirtualUsers) Ok I tried the mbox:~/ and userdb home= trick,
# dovecot -n # 1.2.17: /usr/local/etc/dovecot.conf # OS: FreeBSD 8.3-RELEASE amd64 protocols: imap ssl: no disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login first_valid_uid: 6 first_valid_gid: 6 mail_privileged_group: mail mail_location: mbox:~/ imap_client_workarounds: delay-newmail netscape-eoh tb-extra-mailbox-sep auth default: passdb: driver: passwd-file args: username_format=%n /etc/virtual/%d/passwd passdb: driver: passwd userdb: driver: static args: uid=mail gid=mail home=/var/spool/virtual/%d/%n.imap
but I end up with the same result, everything is read from the virtual folders, namely /var/spool/virtual. How to also access local users' email?
# 1.2.17: /usr/local/etc/dovecot.conf
Very old! Consider an upgrade to 2.2.
Well if it's the only way to get that double impact feature I need, I will! I won't upgrade today if there is no practical advantage over the 1.2 version.
Hmmm, plaintext AUTH without TLS/SSL could be dangerous. If a spammer can get in a position to sniff those credentials, you could be inundated with spam to relay.
Yes I will deal with that some other time.
I find that first_valid_uid and first_valid_gid don't look pretty but it seems mandatory for the standard 'mail' user and group ownerships to work on the virtual mbox files and folders. I created the user while the group already existed. If you have any advices on that too, I would be pleased.
There is no "standard" UID/GID for virtual mailboxes. In fact there is no need to have them all share the same UID/GID. But on a shared UID/GID virtual system, typically you should set a higher UID/GID such that you exclude all the system accounts (<100 or <500 or maybe <1000 depending on OS. If your OS starts human user accounts at UID 1000, UID 999 would be a good choice for virtual mailbox owner, with that as first_valid_uid also.)
I tried with uid 999 and even if I update the ownerships on /etc/virtual/ /var/spool/virtual /var/spool/mqueue/ (no need for /var/mail/ which get the sticky bit, here) the smtp daemon isn't able to write to the virtual mbox anymore, and I don't know why. I have searched the whole file system for relying '6' UID, nothing wrong is left. I don't see why my smtp deamon won't work once I change the UID _and_ update the file and folder ownerships. Maybe some freebsd system security which is today unknown to me. So I switched back to uid 6.