cyrusimap / cyrus-imapd

Cyrus IMAP is an email, contacts and calendar server
http://cyrusimap.org
Other
548 stars 150 forks source link

ANNOTATEMORE Multiple vendor support #679

Closed brong closed 14 years ago

brong commented 20 years ago

From: Stephan Buys Bugzilla-Id: 2458 Version: 2.2.x Owner: Ken Murchison

brong commented 20 years ago

From: Stephan Buys

Cyrus IMAPd ANNOTATEMORE currently only has support for /vendor/cyrus, multiple vendors should be supported (/vendor/*)

Herewith a patch that adds support for multiple vendors to ANNOTATEMORE.

--- annotate.c.old 2004-07-02 18:13:13.000000000 +0200 +++ annotate.c 2004-07-03 10:20:17.000000000 +0200 @@ -1598,6 +1598,11 @@ { NULL, 0, ANNOTATION_PROXY_T_INVALID, 0, 0, NULL, NULL } };

+const struct annotate_st_entry vendor_entry =

brong commented 19 years ago

From: David Faure

Please consider this patch for inclusion - it is very much needed for the Kolab project. We have support for this in clients already (kmail) - using patched cyrus-imapd servers, but that's inconvenient.

brong commented 19 years ago

From: Derrick

Can we get it as an attached diff, rather than inline in the report?

brong commented 19 years ago

Attachment-Id: 333 From: Stephan Buys Type: text/plain File: annotate.patch

Add multi-vendor support to ANNOTATEMORE

brong commented 19 years ago

From: Ken Murchison

My biggest problem with this patch is that it forces ALL /vendor annotations to have the same type and access controls, not to mention the fact that an admin has no control over what annotations s/he wants to support. With this patch in place, a client could store ANY /vendor annotation it wants and bloat the database considerably.

Ideally, we'd have a parsable text file which lists the /vendor annotations that should be supported (with appropriate type and ACL) which would be read at runtime. This seems to give us the most flexibility.

brong commented 19 years ago

From: Martin Konold

I think that the patch is sane as authenticated users are able to abuse the system anyway.

What is really needed in the future is that the annotation db is related to the mailbox or folders not to the entire imapd server.

In addition support for ACLs and quotas on annotations is useful for a generic annotation facility.

Basically imap annotations have the potential of being extremly useful for scalable solution which want to use imap for much more than plain email. Doing so needs an efficient, secure and flexible mechanism to add metadata to an imap folder and an imap mailbox.

brong commented 18 years ago

From:

Any news on this?

brong commented 18 years ago

From: Ken Murchison

Nope. My concerns about limiting the scope of what the client is allowed to store still exists.

brong commented 18 years ago

Attachment-Id: 462 From: Type: text/plain File: annotations.diff

Just 3 /vendor/ annotations, enough for Kolab2 clients.

brong commented 18 years ago

From:

There is a very preliminary patch implementing run-time configuration of annotation names at http://vman.de/cyrus/ It's very likely nowhere close to being suitable, but in case anyone else has the same problem I had...

Kind regards

Thomas

brong commented 17 years ago

From:

I tested Thomas' patch in a production environment, with version 2.3.8 of the imapd, using Toltec Connector as a kolab client, and it works perfectly! What does it need to merge this patch?

I added annotation_definitions: /etc/kolab.cyrus.txt to imapd.conf, and used the attached file as the definitions.

brong commented 17 years ago

Attachment-Id: 525 From: Type: text/plain File: kolab.cyrus.txt

Annotation definitions for using cyrus-imapd as a kolab server

brong commented 17 years ago

From: Ken Murchison

The patch looks reasonable to me, but I need to give it a closer look before I commit it.

brong commented 17 years ago

From: Gunnar Wrobel

Any progress on this patch? Any help needed?

brong commented 15 years ago

From: Andres Freund

Anything users of this patch can do to increase the adoption probability?

Andres

brong commented 14 years ago

From: Andreas Mack

Any chances that this patch goes in soon? We have it in production for some time now on a patched centos imapd with the kolab annotations without any problems.

brong commented 14 years ago

Attachment-Id: 1242 From: Martin Konold Type: text/plain File: imapd.annotation_definitions

Annotation definitions for using cyrus-imapd as a kolab server (a suitable default which does not hurt)

brong commented 14 years ago

From: Martin Konold

(In reply to comment #12) > The patch looks reasonable to me, but I need to give it a closer look before I > commit it.

Hi Ken,

please have a look at patch. This stuff is in production without any problem reports since many years now.

Regards, -- martin

brong commented 14 years ago

From: Gunnar Wrobel

@andreas, martin: Nice to see some activity here. Nevertheless after years of inactivity I doubt anyone on the Cyrus team is really interested. As we got the same stuff into dovecot and it is easier to maintain it there I'd suggest we focus our activities on that server. Or is there anything dovecot is still missing concerning Kolab?

brong commented 14 years ago

From: Ken Murchison

Are we talking about Thomas' patch which allows external annotation definitions, with yours as the defaults needed for Kolab?

brong commented 14 years ago

From: Andreas Mack

Hi Ken,

yes, I meant Thomas' patch, comment #12 from you seems to reference it.

brong commented 14 years ago

From: Martin Konold

@Gunnar: I have seen very interesting recent developments in Cyrus Imapd which are really worth a closer look.

@Ken: Yes, it is about allowing annotations beyond the already existing. For your understanding the following points are important:

  1. These third party vendor annotations like "/vendor/kolab/folder-type,mailbox,string,backend,value.shared value.priv,a" are not for controlling the server like "/vendor/cmu/cyrus-imapd/sharedseen" but intended for clients to add metadata to a mailbox.

As an exampple in the above case the client can store the purpose of the mailbox e.g. if it is used to store groupware data like addresses (vcard or XML), events, notes,....

  1. The server administrator has full control about which 3rd party vendor annotations are allowed.

  2. The Kolab patches to Cyrus Imapd are available from http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/cyrus-imapd-2.3.14/

The current Kolab patches which are potentially relevant to Cyrus Imapd are:

KOLAB_Groups2.patch Cyrus Imapd makes a useless reference to /etc/groups which does not make sense simply because the cyrus user database is not related to /etc/passwd either. This trivial patch adds support for an optional /etc/imapd.group with a backwards compatible fall-back to /etc/group if /etc/imapd.group is not available. This patch is in production since more than 6 years. Download: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/imapd/patches/cyrus-imapd-2.3.14/KOLAB_cyrus-imapd-2.3.14_Groups2.patch?rev=HEAD&content-type=text/plain

I consider moving groups to a imapd db to be the best approach for the future but still applying the above patch makes imho a lot of sense.

KOLAB_Annotations2.patch This patch supports server and mailbox scopes. It allows the server administrator to define which 3rd party annotations are explicitly allowed, which scope they refer to and if they are to be relevant to proxy, server or both. Download: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/imapd/patches/cyrus-imapd-2.3.14/KOLAB_cyrus-imapd-2.3.14_Annotations2.patch?rev=HEAD&content-type=text/plain

KOLAB_Cyradm_Annotations.patch This patch adds support to set annotations with cyradm. Download: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/imapd/patches/cyrus-imapd-2.3.14/KOLAB_cyrus-imapd-2.3.14_Cyradm_Annotations.patch?rev=1.1

KOLAB_Logging.patch This patch adds some further logging to LOG_DEBUG which proved to be useful in the past. Download: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/imapd/patches/cyrus-imapd-2.3.14/KOLAB_cyrus-imapd-2.3.14_Logging.patch?rev=1.1

KOLAB_Folder-names.patch Cyrus Imapd is over zealous in defining GOODCHARS for foldernames. This patch adds further charactes which are safe. Download: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/imapd/patches/cyrus-imapd-2.3.14/KOLAB_cyrus-imapd-2.3.14_Folder-names.patch?rev=1.1

KOLAB_UID.patch This patch adds ldap support to allow login using an email address/uid stored in ldap. I guess you do not like this patch.

brong commented 14 years ago

From: Martin Konold

Hi Ken,

what needs to be done to avaid having this issue being delayed for another 5 years?

Yours, -- martin

brong commented 14 years ago

From: Ken Murchison

I will take a look before the holidays

brong commented 14 years ago

From: Ken Murchison

I have the patch integrated with more verbosity for imapd.conf(5). I'm waiting for Thomas to get back to me on his Copyright notice before I can commit

brong commented 14 years ago

From: Martin Konold

(In reply to comment #24)

> I'm waiting for Thomas to get back to me on his Copyright notice before I can commit

Thomas: Can you please resolve this asap.

Thanks, -- martin

brong commented 14 years ago

From: Ken Murchison

Applied to CVS. Will be in upcoming 2.3.16 release.