A while ago while testing, I inadvertently had a bug that resulted in non-alphanumeric characters in a keyword for a particular mailbox. This exposed a bug in the libetpan IMAP client library where it could no longer access this mailbox due to a parsing error in the library, since this malformed keyword would ever after appears in the PERMANENTFLAGS response when the mailbox was selected. However, the larger issue was there is no current mechanism in the IMAP protocol to purge such a malformed keyword from a mailbox. I was fortunate I could contact the server operator by email (small local mail server) and ask him to remove the keyword. However, in the real world, most users do not have this luxury or ability.
The underlying "problem" is that IMAP as a protocol does not dictate the mailbox storage format. maildir++ is a common one, and one that is the focus here. When keywords are removed from messages using the STORE command, the server is not obligated to remove this keyword from it keyword mapping for that mailbox, even if no messages are using it - certainly, neither my IMAP server implementation nor the one used by the server mentioned above do this. This creates a small window of opportunity for things to go very bad for a user - even though it's the library's fault for choking on a PERMANENTFLAGS it doesn't expect, in the spirit of robustness, it should be possible to fix these after the fact. The only remedy today is quite nuclear: manually remove the keyword from all messages using STORE, move them to another mailbox, and then delete the original mailbox, renaming the new mailbox afterwards. This may not always be possible or practical in all circumstances.
To remedy this, I propose two new IMAP keywords, RENAMEKEYWORD and DELETEKEYWORD. Strictly speaking, only DELETEKEYWORD is necessary, since a keyword can be deleted and recreated automatically as needed by the IMAP server. However, a user may find it advantageous to be able to rename a keyword for servers using the maildir format, which normalizes keyword names to a single letter or identifier. However, this is implementation dependent, so RENAMEKEYWORD support is optional by the server, and these capabilities will be advertised separately.
Both commands are only possible in the selected state for a particular mailbox. The DELETEKEYWORD command will accept, as a single argument, the keyword to delete. The RENAMEKEYWORD command accepts as arguments the old keyword name and the new keyword name. Standard IMAP responses apply - BAD, NO, and OK, depending on the outcome. If there are messages that are currently using a keyword, the server SHOULD automatically remove this keyword from all such messages as if a STORE operation were issued prior.
It is not the author's intention that mail clients generally offer a graphical facility for using these keywords, which are intended more as a debugging and administrative mechanism for troubleshooting and maintenance purposes. Any skilled user could connect to their IMAP server in a terminal session and issue these commands manually to get them out of a jam. However, nothing certainly stops an IMAP client from including a menu that would allow the user to more easily rename and delete keywords. A natural extension to this is a LISTKEYWORDS command, but that isn't as high a priority for me to see happen.
Another use case for keywords like DELETEKEYWORD is not just to remove keywords that created accidentally or malformed but to, perhaps over time, allow users to manually do "housekeeping" by deleting keywords from the keyword mapping that are no longer being used. But this is a slightly different use case that may be better suited by a dedicated command to purge keywords that are no longer being used from the keyword mapping, or perhaps DELETEKEYWORD should not normally succeed if the keyword in question is being used by any message in the mailbox, which may be the better solution since it would not be difficult to do a STORE 1:* first to remove the keyword from all messages and THEN delete it. Thus, refusing to delete keywords in use serves as an additional safety mechanism.
While I can implement this independently in the LBBS IMAP server relatively easily, I think the problem is broad enough that it makes sense to submit this to an IETF working group for possible standardization. See https://datatracker.ietf.org/wg/extra/about/
You must be