On Fri, 2011-02-11 at 23:33 +0100, Andrea Borghi wrote:
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.
Oh. This would be solved nicely by having deliver (optionally) send the vacation messages by connecting to SMTP server via TCP instead of executing sendmail binary. I've wanted that for a while already anyway. v2.0 also already has a library that can talk SMTP.
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.
I can't give a timeframe for this. It probably wouldn't take long to implement it, but I've so many other things to do..