[Kolab-devel] horde as kolab's web frontend or not

[Bernhard Reiter]

Am Freitag, 7. Juli 2006 22:54 schrieb Richard Bos:
> Op vrijdag 7 juli 2006 11:19, schreef Jan Schneider:

> > There I several points I still see valid.
> > Regarding security: administration users are still used both for LDAP  
> > and IMAP access. As Gunnar explained it's probably not necessary for  
> > LDAP but still for IMAP to allow IMAP annotations on shared folders.
>
> But why does a client like kmail not need the administration user (in case
> of the iMAP annotations, I assume that kmail supports IMAP annotations on
> shared folders)?

Yes, KMail supports annotations on shared and anonymous (aka global) folders.
Cyrus IMAP also allows all users to write that have the permission set in the 
ACL of the folder.

Both for LDAP and IMAP, only user priviledges should be enough.
There is a larger point behind this:
The code running in the process should only have users priviledges
and if the code is broken, only the data of one user should be subject
to attack.

Of course, this users need to save some configuration variables
and the cache in a personal store, but the savety of this store should be
secured by an indepentent layer.
Just like Cyrus and OpenLDAP secure the savety of the information 
of the users.

Thus Horde probably will need to use a storage somewhere per user
and also only access this via user priviledges.
This storage could be a file-system (easy, simple) or a database (more 
complex.)

> > Regarding performance: The Kolab code in Horde is not using any IMAP  
> > cache at all at the moment.
>
> Does this really make a difference in case the imap folder resides on the
> same system as the webserver?  

Yes, it does.
Each additional IMAP request puts load on the server,
it would be my requirement that any Kolab webclient should run on a completely 
seperate server anyway to not drain load for regular users.
Running compley IMAP commands like search on the server for each update
will (roughly) lead to an increase of two magnitudes of load on the IMAP 
server.

> I believe that this can be added later to 
> horde, after the other points described above by Jan have been solved.

If you do step by step development, of course this can be a milestone,
but it looks like a larger desing issue to me (from very far away).

> Dimap is probably very usefull in case the imap server is a different one
> and the user uses the agenda groupware functionality.

Using groupware is all this is about... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060721/e93bc392/attachment.sig>