You posted today that it must not be possible to serve both virtual and system users on a single Dovecot instance. This is wrong.
On Mon, Aug 26, 2013 at 06:11:08PM +0200, Pierre-Philipp Braun wrote:
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:~/
Mbox refers to a file name. Here you have given just a directory.
http://wiki.dovecot.org/FindMailLocation http://wiki.dovecot.org/MailLocation/Mbox http://wiki.dovecot.org/MailboxFormat/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
I think the second passdb should possibly be first, but it should work. You probably also need either "shadow" or "pam" as driver, not "passwd".
userdb: driver: static args: uid=mail gid=mail home=/var/spool/virtual/%d/%n.imap
You forgot your userdb: with "driver: passwd". That must precede the static userdb, because a static userdb, by definition, matches everything.
http://wiki.dovecot.org/AuthDatabase/Passwd
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?
Yes, give them a proper userdb. This won't work on your second server either, without a userdb. If you can get the userdb right there, it would also work here.
[snip]
I tried with uid 999 and even if I update the ownerships on /etc/virtual/ /var/spool/virtual /var/spool/mqueue/ (no need for
I don't know what /etc/virtual is. I presume that /var/spool/mqueue is the Sendmail MTA queue directory. I don't know, but it does not sound right to me that it should be owned by a virtual mailbox owner. Don't go changing ownerships at random. ONLY the virtual mailboxes should be owned by your shared-UID/GID virtual mailbox owner.
/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.
It probably logged why/why not.
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.
http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: