Re: [Dovecot] local AND virtual mail locations ?
Well, first of all, why are you using mbox?
truncated output from my doeveconf -n
# for Local users
mail_location = maildir:~/Maildir
For SQL users
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
default_fields = uid=vpopmail gid=vchkpw mail_location=/usr/local/virtual/%u
driver = sql
}
Notice that using default_fields I am able to respecify the mail_location for
the sql users. You should be able to do something similar, right?
Of course, you are using dovecot 1.x, so maybe it's more difficult?
Still, mbox is bad. No one should use mbox.
Ok I've switched to Dovecot version 2 which indeed allows to use a per
userdb mail location (mail= instead of mail_location). As for maildir
versus mbox I was able to turn to maildir for the local users which
messages are delivered by procmail. For the virtual users,
unfortunately for now, my smtp daemon, postoffice smtpd, is only mbox
capable with no alternate LDA possibility.
# 2.2.5: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 8.3-RELEASE amd64
disable_plaintext_auth = no
first_valid_gid = 6
first_valid_uid = 6
mail_privileged_group = mail
passdb {
args = *
driver = pam
}
passdb {
args = username_format=%n /etc/virtual/%d/passwd
driver = passwd-file
}
protocols = imap
service auth {
user = root
}
ssl = no
userdb {
args = blocking=yes
driver = passwd
override_fields = mail=maildir:~/Maildir/
}
userdb {
args = uid=mail gid=mail
driver = static
override_fields =
mail=mbox:/var/spool/virtual/%d/%n.imap/:INBOX=/var/spool/virtual/%d/%n
}
protocol imap {
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}
Thanks to all!
Re: [Dovecot] local AND virtual mail locations ?
Since I've got no answer since my previous message about that, I suppose it isn't that trivial to serve both, local and virtual users at the same time with Dovecot. I think I'll use two separate servers. Thanks for the hints, anyway. P.Ph
Re: [Dovecot] local AND virtual mail locations ?
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:
Re: [Dovecot] local AND virtual mail locations ?
Quoting /dev/rob0 30/08/2013 17:11, You posted today that it must not be possible to serve both virtual and system users on a single Dovecot instance. This is wrong. I don't say it is impossible, I'm just saying it isn't as trivial as you supposed in your first answer. In fact, I got it _almost_ working, the only quirk is about mail_location parameter being shared among all kinds of users, local and virtual, which causes the troubles I try to explain hereby. When I use, mail_location = mbox:~/ * YES this is the best way, afaict, to get the mboxes within the userdb defined home= variable * the problems are: 1) local users' home dir is served, which is not appropriate as I want them to have other files, not only emails, especially the ~/.forward file, 2) I need to setup the smtp daemon or its LDA to write to local users' ~/inbox or make a link to /var/(spool/)mail/%u. Otherwise the local users don't get any INBOX as the :INBOX= part is missing in the mail_location declaration. (everything is fine for virtual users) When I use, mail_location = mbox:~/mail/ the problems are: 1) I have to create the 'mail/' folder in virtual users' imap folder and move the content to it for every virtual user, 2) I need to setup the smtp daemon or its LDA to write to local users' ~/mail/inbox or make a link to /var/(spool/)mail/%u. Otherwise the local users don't get any INBOX either as the :INBOX= part is missing in the mail_location declaration. When I use, mail_location = mbox:~/mail/:INBOX=/var/mail/%u it just won't work as the virtual and local users don't share the same locations for inboxes and this cannot be set with the userdb home= trick. So here is it, finally (still got the ssl part to fix). I am probably going to use the second mail_location possibility, it just bothers me to add a useless folder to virtual users' mail path (/var/spool/virtual/domain/username.folder/*mail/*). # 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:~/mail/ imap_client_workarounds: delay-newmail netscape-eoh tb-extra-mailbox-sep auth default: username_format: %Lu passdb: driver: pam args: * passdb: driver: passwd-file args: username_format=%n /etc/virtual/%d/passwd userdb: driver: passwd args: blocking=yes userdb: driver: static args: uid=mail gid=mail home=/var/spool/virtual/%d/%n.imap option as I didn't couldn't find Pierre-Philipp
Re: [Dovecot] local AND virtual mail locations ?
On 30 Aug 2013, at 12:52 , Pierre-Philipp Braun pbr...@nethence.com wrote:
mail_location = mbox:~/
Well, first of all, why are you using mbox?
truncated output from my doeveconf -n
# for Local users
mail_location = maildir:~/Maildir
For SQL users
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
default_fields = uid=vpopmail gid=vchkpw mail_location=/usr/local/virtual/%u
driver = sql
}
Notice that using default_fields I am able to respecify the mail_location for
the sql users. You should be able to do something similar, right?
Of course, you are using dovecot 1.x, so maybe it's more difficult?
Still, mbox is bad. No one should use mbox.
--
Is that a star? Nah, that's Ted Danson.
Re: [Dovecot] local AND virtual mail locations ?
On Mon, Aug 26, 2013 at 02:50:54PM +0200, Pierre-Philipp Braun wrote:
I would like to use Dovecot not only for virtual mboxes, but also for
local users. In other words, I would like to use different
mail_locations depending on passdb passwd-file versus passwd.
I believe that the default mail_location would be overridden by
userdb, not passdb.
I need that as the smtp daemon I am using (david parsons' postoffice
smtp server) serves both but is only able to process messages through
procmail on local users. Here are the two mail_locations I would
like to use:
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.)
depending on those passdb stanzas, respectively:
passdb passwd-file {
args = username_format=%n /etc/virtual/%d/passwd
}
passdb passwd {
}
Any help would be appreciated.
Here's my Dovecot version and current working configuration for
virtual users only:
# dovecot -n
dovecot -n
# 1.2.17: /usr/local/etc/dovecot.conf
Very old! Consider an upgrade to 2.2.
# OS: FreeBSD 8.3-RELEASE amd64 ufs
protocols: imap
ssl: no
disable_plaintext_auth: no
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.
login_dir: /var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
first_valid_uid: 6
first_valid_gid: 6
mail_location:
mbox:/var/spool/virtual/%d/%n.imap:INBOX=/var/spool/virtual/%d/%n
imap_client_workarounds: tb-extra-mailbox-sep
auth default:
user: mail
passdb:
driver: passwd-file
args: username_format=%n /etc/virtual/%d/passwd
userdb:
driver: static
args: uid=6 gid=6
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.)
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] local AND virtual mail locations ?
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.
