Enhance cyradm to cover more useful sysadmin features

[brong]

Via email from Anatoli me@anatoli.ws

2. Small sysadmin tasks for typical configurations that now require manual actions or writing one's own scripts. An example: new mailbox creation with particular flags (\Sent, \Junk, \Trash) set for special-use folders (that could be implemented as an extended functionality of the autocreate_inbox_folders option).

At FM you have everything automated for sure with your own customs scripts, but sysadmins with little experience with Cyrus or those that don't write scripts with ease would find some tasks difficult to accomplish, for others that's just an overhead/additional points of failure that could be avoided with small built-in automations.

[brong]

This is a definitely interesting area for enhancement.  The basic tool here is cyradm, and I think what we're really looking for is extending cyradm.

[anatoli26]

I like the idea of extending the cyradm functionality, but here I was referring more to some changes that would not require any manual actions/scripting at all.

Currently, we can instruct Cyrus to automatically create folders with:
autocreate_inbox_folders: Sent|Trash|Drafts|Spam|Notes|folderX

Then if the admin wants for some automatically created folders to have special-use flags (as per RFC6154), currently he/she should write scripts to assign the necessary flags.

What could be an improvement in this area is to extend autocreate_inbox_folders option to handle (and act upon) additional settings the following way:

autocreate_inbox_folders: <folder>[:<special-use flag>][|<folder>[:<special-use flag>]]

Example: autocreate_inbox_folders: Sent:\Sent|Trash:\Trash|Drafts:\Drafts|Spam:\Junk|Notes|folderX

So upon creation of the specified folders, Cyrus would set the special-use flags to 4 of them as specified.

[gdmalet]

Regarding special use flags, we have this in our config, and it's been there for years. I wonder if it came from the mailbox auto-create patches before they were integrated into Cyrus? Which makes me wonder if they still work. We have turned off new account creation on this system though, so I can't test easily.

autocreate_inbox_folders: Drafts|Sent|Trash|SPAM
autocreate_subscribe_folders: Drafts|Sent|Trash|SPAM

# Turn on rfc6154 Special-Use Mailboxes
#specialusealways: 1
xlist-drafts: Drafts
xlist-junk:   SPAM
xlist-sent:   Sent
xlist-trash:  Trash

[anatoli26]

@gdmalet, if I understand it correctly, XLIST was deprecated 2 years after it was introduced and its support was dropped in Cyrus 2.4 or 2.5. Before that it was quite a usable feature, dunno why it was dropped globally, though here Bron explains the reason for XLIST removal from Cyrus: https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2013-April/002781.html. Please let me know if I missed any important detail.

[gdmalet]

@anatoli26 Thanks for the update -- I wasn't aware of the history. I just wanted to make sure people were aware that some work had been done in this area in the past, in case the old code is useful....

[brong]

So... it seems to me that maybe the best thing here is to take advantage of existing config...

So... if you have xlist-(name): Folder and it gets autocreated, it will also get the special-use auto-added now, in 5a1a9b8 and on master (also with a Cassandane test)

[anatoli26]

Oh that looks like the best approach, thanks Bron!

[elliefm]

Added xlist-flag to imapd.conf.5: bc7fd50

@brong did I get the example around the correct way?

[brong]

Indeed you did :)

Probably also add something to say that the naming to is to stay compatible with 2.4/2.5 configs, despite looking kinda bogus.

[elliefm]

I wonder if it's worth adding a less bogus synonym, "autocreate_specialuse-flag" maybe?

Though looking at the implementation (loop over all overflow strings, skip ones that aren't /^xlist-/), maybe that'll get messy if we then need to also check for duplicates/precedence...

[alexis-]

This discussion was very helpful.
I am not a sysadmin, and perusing the documentation hardly gives any info regarding this feature (or perhaps I haven't looked in the right place).
It might be useful to link https://tools.ietf.org/html/rfc6154 in imapd.conf.5
Or perhaps https://developers.google.com/gmail/imap/imap-extensions for a more synthetic overview

What do you think ?