On Friday 11 February 2011, Timo Sirainen wrote:
On Thu, 2011-02-10 at 21:26 +0100, Andrea Borghi wrote:
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
But deliver doesn't call antivirus, right? So what's the problem of keeping deliver chrooted? There shouldn't be any need for any libraries or anything inside the chroot.
for the use of deliver, yes. but you're forgetting sieve filter and the ability to program with it the vacation messages, etc. in short, for every action of that type i need a /bin/sendmail in the chroot jail, and if you see the postfix sendmail binary you'll see the plethora of libs it requires. and in this you can see also the conflicts when the mail storage is on a shared media between more servers that can not be aligned in library versions, ecc. ecc.
just a nightmare.
so you're telling i have no other option except to fold over the two parts of the path directly in the LDAP database and reconfigure dovecot (as a whole) to map just one attribute?
Yeah.
ok. i will make the necessary adaptations now that i have a small mailbox number. thank you for this confirmation.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
I've some plans to rewrite LDAP configuration to support this and other things.
it'll be useful to me to know a rough timeframe for this (ex 6 months) to decide to wait on some services (ex. sieve) or to start rewriting the mail system logic in regard to mailbox paths.
thank you Andrea