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.