Potential patch to filter mailboxes depending on annotation for non Kolab email clients

[Bron Gondwana]

Sorry you missed the rest of the call and we didn't get to talking about your thing yet!  It was on the agenda for tonight.

We did talk about it, and figure that the correct thing is to make this more generic:

1) add an annotation called "/hidden" to the mailbox which you can set with a name
2) if a normal LIST command or even EXTENDED list command is run that doesn't support LIST=HIDDEN then don't show those mailboxes (or even show that they exist)
3) if you say LIST RETURN HIDDEN then they all get shown:

TAG LIST (HIDDEN) "" "%" RETURN (HIDDEN)
* LIST (\HasChildren \Subscribed) "/" "Foo"
* LIST (\HasNoChildren \Subscribed \Hidden) "/" "Moo" (HIDDEN ("kolab.com"))

The LIST=HIDDEN aware client can then choose which of these folders to show based on the hidden tag.

If there are hidden children then you might get multiple HIDDEN items like this:

TAG LIST (HIDDEN) "" "%" RETURN (HIDDEN)
* LIST (\NonExistent \Hidden \HasChildren) "/" "TopLevel" (HIDDEN ("fastmail.com" "kolab.com"))
TAG OK

TAG LIST (HIDDEN) "" "*" RETURN (HIDDEN)
* LIST (\Hidden \HasNoChildren) "/" "TopLevel/FastMail" (HIDDEN ("fastmail.com"))
* LIST (\Hidden \HasNoChildren) "/" "TopLevel/Kolab" (HIDDEN ("kolab.com"))
TAG OK

I think that would match your needs much more powerfully than just a client "ID" match, and be flexible for other vendors.

TAG CREATE TopLevel/FastMail
TAG NO [HIDDEN] A hidden mailbox exists with this name

Cheers,

Bron.

On Mon, 7 Nov 2016, at 07:57, Bron Gondwana via Cyrus-devel wrote:
> I'm happy for something like this. I have some ideas for using client quirks for this as we already do for iOS with the fuzzy search quirk.
> 
> Are you able to join the Cyrus development calls? They are at a very convenient time for Europe!
> 
> Bron.
> 
> On Sat, 5 Nov 2016, at 18:39, Timotheus Pokorra via Cyrus-devel wrote:
> > Hello,
> > 
> > we have this discussion in Kolab [0] about whether to have an
> > additional proxy (Guam) to process the data that comes from Cyrus
> > imapd, or to patch Cyrus imapd itself.
> > 
> > What do you think about the attached patch?
> > It checks if the email client identifies with Kolab in its name, and
> > if not, only mailbox folders with annotation containing "mail" are
> > published with the LIST command. If there are no folder annotations,
> > the folder is published as well.
> > 
> > Are there any flaws with that patch? My C knowledge is quite rusty...
> > 
> > Would this patch be suitable for merging upstream? Or is this
> > something we should keep in the Cyrus package packaged for Kolab?
> > 
> > Thank you, and have a nice weekend,
> >   Timotheus
> > 
> > [0]: https://lists.kolab.org/pipermail/devel/2016-November/015490.html
> > Email had 1 attachment:
> > + cyrus-imapd.filterfolders.patch
> >   2k (text/x-patch)
> 
> 
> -- 
>   Bron Gondwana
>   brong at fastmail.fm


-- 
  Bron Gondwana
  brong at fastmail.fm