Re: [PATCH/FEATURE] Per-user XLIST support for cyrus-imapd
On 2013-04-30 09:20, Thomas Jarosch wrote: Hi Bron, On Tuesday, 30. April 2013 08:53:24 Bron Gondwana wrote: Hi - have you looked at all at the special-use support in mainline Cyrus? The xlist-* behaviour is planned to be removed, in favour of using the RFC 6154 mandated annotation. The implementation in git at the moment doesn't quite match the standard, because I wrote it before the RFC was released, but I have a branch which makes it fully compatible. I wrote to this list just the other day asking about it! Eduardo is innocent, we (=Intra2net) needed support for this :) We didn't upgrade to 2.4.x yet, so we needed to develop this for 2.3.16 anyway. As far as I understood it, Outlook 2013 does not implement the RFC properly. I suppose you would then use the Cyrus IMAP internal SPECIAL-USE folder flags storage(?) to represent a response to X-LIST(?) rather than supplying additional configuration that can quickly get out-of-sync with other clients (that do support SPECIAL-USE?) as well as across folders. I haven't actually looked at anything to back up this rambling with, tell me if it makes sense ;-) Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Special-Use and Cyrus 2.5 git
On 2013-04-26 16:17, Bron Gondwana wrote: Is anybody actually using cyrus 2.5 git in production other than FastMail? Yes, though admittedly I should say production. I'm planning to do the mailboxes.db format changes before releasing 2.5, so that we don't have to support a stupid intermediate format. It's been on my todo list for AGES as one of the final blockers to 2.5 being released, and I've finally got some spare cycles away from our internal search code. But it would simplify things considerably if I don't have to write an importer that goes upstream. I'd just manually script a conversion of the FastMail servers, and then toss away the intermediate code. None of our systems with 2.5 in production use special-use, nor are they expected to be upgraded smoothly without manual / scripted sysadmin intervention. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: [PATCH] 2.4 branch does not build anymore
On 2013-05-18 16:34, Thomas Cataldo wrote: As conflict marks were committed. Thanks! Committed and pushed. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Changing LIST (again)
On 2013-05-02 07:29, Bron Gondwana wrote: One of my release goals for Cyrus 2.5 is to be correct in our implementation of every standard that we claim to support. This is why I emailed the list last week asking if anyone is using the intermediate SPECIALUSE representation in git. Since there was no reply, I'm assuming it will be OK :) I've just started testing it into production at FastMail, and will roll it out to all our users later this week. Assuming performance is acceptable, I'll push that upstream. Meanwhile, there's one glaring problem remaining, as evidenced by Timo's imaptest tool. Our LIST-EXTENDED implementation is broken in some places. I've already had reports of users of recent versions of some clients having problems with it. That sucks. Rob M (CC'd) and I had a good talk about it yesterday. We're looking at switching the default at FastMail to use altnamespace - it works better with Outlook 2013 and also with some phones. One problem is that you can't create subfolders of Inbox. We've looked at the standard, and we don't see any reason why we can't allow them, The clients that do create (allow) a sub-folder of the INBOX (to be created) apparently do not adhere to the \NoInferiors flag... Should you make the change to allow sub-folders (of the INBOX) to in fact be created (while using altnamespace), would that eliminate the use of \NoInferiors? Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Changing LIST (again)
On Sun, May 19, 2013, at 08:36 PM, Jeroen van Meeuwen (Kolab Systems) wrote: On 2013-05-02 07:29, Bron Gondwana wrote: One of my release goals for Cyrus 2.5 is to be correct in our implementation of every standard that we claim to support. This is why I emailed the list last week asking if anyone is using the intermediate SPECIALUSE representation in git. Since there was no reply, I'm assuming it will be OK :) I've just started testing it into production at FastMail, and will roll it out to all our users later this week. Assuming performance is acceptable, I'll push that upstream. Meanwhile, there's one glaring problem remaining, as evidenced by Timo's imaptest tool. Our LIST-EXTENDED implementation is broken in some places. I've already had reports of users of recent versions of some clients having problems with it. That sucks. Rob M (CC'd) and I had a good talk about it yesterday. We're looking at switching the default at FastMail to use altnamespace - it works better with Outlook 2013 and also with some phones. One problem is that you can't create subfolders of Inbox. We've looked at the standard, and we don't see any reason why we can't allow them, The clients that do create (allow) a sub-folder of the INBOX (to be created) apparently do not adhere to the \NoInferiors flag... Should you make the change to allow sub-folders (of the INBOX) to in fact be created (while using altnamespace), would that eliminate the use of \NoInferiors? Indeed it would :) Bron.
SETMETADATA: missing annotation value
Hi there, I'm wondering whether it is me (us) doing something wrong, or whether Cyrus IMAP git origin master HEAD is at fault... C: A0019 SETMETADATA INBOX (/shared/vendor/kolab/folder-type mail /private/vendor/kolab/folder-type mail.inbox) S: A0019 BAD Missing metadata value C: A0020 SETMETADATA INBOX (/private/vendor/kolab/folder-type mail.inbox) S: A0020 BAD Missing metadata value or: C: . GETMETADATA INBOX /shared/comment S: * METADATA INBOX (/shared/comment NIL) S: . OK Completed C: . SETMETADATA INBOX (/shared/comment hey) S: . BAD Missing metadata value C: . SETMETADATA INBOX (/shared/comment 'hey') S: . BAD Missing metadata value C: . SETMETADATA INBOX /shared/comment 'hey' S: . BAD Missing metadata entry list Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Changing LIST (again)
On Sun, May 19, 2013, at 11:21 PM, Jeroen van Meeuwen (Kolab Systems) wrote: On 2013-05-19 15:07, Bron Gondwana wrote: On Sun, May 19, 2013, at 08:36 PM, Jeroen van Meeuwen (Kolab Systems) wrote: Should you make the change to allow sub-folders (of the INBOX) to in fact be created (while using altnamespace), would that eliminate the use of \NoInferiors? Indeed it would :) I really, really like calling out stupid clients that do not honour \NoInferiors though... I guess everyone needs a hobby... Can we please keep a sane default of (enforcing) RFC(s)-compliant behaviour? Default, sure. Do you suggest to remove the \NoInferiors flag for deployments with sub-folder of INBOX w/ altnamespace allowed type of configurations, or would you keep it around (and simply behave differently by honouring the request instead of returning an error)? You kind of have to - since you want RFC-compliant clients to be able to create subfolders of Inbox. That's the whole point. Bron.
Re: Changing LIST (again)
On 2013-05-19 21:45, Bron Gondwana wrote: On Sun, May 19, 2013, at 11:21 PM, Jeroen van Meeuwen (Kolab Systems) wrote: On 2013-05-19 15:07, Bron Gondwana wrote: On Sun, May 19, 2013, at 08:36 PM, Jeroen van Meeuwen (Kolab Systems) wrote: Should you make the change to allow sub-folders (of the INBOX) to in fact be created (while using altnamespace), would that eliminate the use of \NoInferiors? Indeed it would :) I really, really like calling out stupid clients that do not honour \NoInferiors though... I guess everyone needs a hobby... *g* Can we please keep a sane default of (enforcing) RFC(s)-compliant behaviour? Default, sure. Thanks! Do you suggest to remove the \NoInferiors flag for deployments with sub-folder of INBOX w/ altnamespace allowed type of configurations, or would you keep it around (and simply behave differently by honouring the request instead of returning an error)? You kind of have to - since you want RFC-compliant clients to be able to create subfolders of Inbox. That's the whole point. Fine with me - I just wanted to understood the changes you were about to make correctly ;-) Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
