dovecot as alternative

[Mihai Badici]

On Sunday 02 June 2013 17:33:37 Jeroen van Meeuwen wrote:
> On 2013-05-31 07:36, Klos, Paul wrote:
> > So it gets a little bit more complex. I'm thinking we could have kolab
> > depend on an imap server (either cyrus, which would be the default, or
> > dovecot, or anything else).
> 
> Please don't do that - on a clean system, "yum install kolab" or
> "aptitude install kolab" should continue to install cyrus-imapd, as it
> is properly supported.


Totally agree. I don't want to broke kolab :)
> 
> One could make the "kolab-imap" sub-package depend on cyrus-imapd ||
> dovecot, but the preference is Cyrus IMAP. It should really only have a
> satisfied dependency if and when dovecot has been installed prior to the
> installation of Kolab.
> 
> Also, the dovecot package that gets installed should already provide the
> METADATA plugin for it. I'm not sure whether on Debian it does, but IIRC
> upstream dovecot 2.1+ should be shipping it. It could be though, that a
> ./configure switch is not included in the Debian packages.
> 
> Also, Kolab is untested with Dovecot - the Kolab daemon, for instance,
> has a habit of attempting to create user mailboxes (and default folders
> when configured), for which it uses an administrator login. Dovecot,
> AFAIK, does not have the concept of an administrator login (but does
> have "login as" functionality). I'm not sure how Kolab is supposed to
> behave in this context;
> 

There are lot of differences.
But will be good if we can play with  for testing purposes.

What I want in fact is to allow me to install dovecot after I installed kolab. 
I could simply stop cyrus (disable it) and start dovecot.

I will be on my own after, for sure. 


> - when/how does Dovecot understand that a valid login is (or is not)
> necessarily a valid mailbox, and if it creates the mailbox for the user
> on successful login, does this go for administrator "login as" as well?
> 
> - one of the features of Dovecot being the (application of) filesystem
> quota for a user (the mailbox could count towards it), in the su-type of
> unsealed system, does it need to have the mail directory created prior
> to finding the mailbox is a valid mailbox? Would this not include the
> requirement to all Kolab users to be POSIX accounts?

> 
> - Would the Kolab daemon not need to ignore the LDAP 'mailQuota'
> attribute unless the mailbox resides on a different filesystem from the
> one a home directory is on, and instead use the filesystem quota (not
> 'mailQuota', if at all from LDAP), or use 'mailQuota' to set file system
> quota?
> 
> I'm willing to entertain a "--with-imap=dovecot" switch to setup-kolab
> (note I've already added a --without-ldap, a --with-openldap, and a
> --with-ad), but these things need to be figured out if Kolab is ever to
> fully support Dovecot.

At the momment I think nobody talk about supporting dovecot, but about the 
possibility to play with and see .
Dovecot is popular and there are chances to have more features in the future.
I'm interested if basic features are working well, after that we can focus on 
details. 

> 
> When taking in to consideration how much time I have available to
> actively contribute towards full Dovecot support, I'm afraid I have to
> conclude that, unless Kolab Systems gets involved commercially, those
> that wish to run with Dovecot are largely on their own.
Well... that's the ideea. 
I first want to test on my test server, after that possibly at a small company 
with 5 users and a single domains... and so on. That's why I (we) need a point 
to start.

I tested on Slackware, but that's not really a kolab server, there are 
manually assembled parts :)


> 
> While I perfectly well understand some of you have a need for Dovecot, I
> suggest that, if you do and you are willing to contribute towards Kolab
> support for it but are unable to do so in code, even if just your
> proverbial $10,-, you contact Kolab Systems.
> 
> Thanks for your patience,
> 
> Kind regards,
> 
> Jeroen van Meeuwen
-- 
Mihai Badici
http://mihai.badici.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20130602/0e71ae44/attachment.html>