Some of the things that keep being brought up SEEM TO ME to be a form of IMAP crack that can be accomplished in a much more generalized manner with a little bit of thought.
An idea I had a while back was for IMAP views. It accomplishes the four things I keep seeing on this list without being specific to any of them.
Consider new configuration variables:
rewrite Junk { folder = INBOX search = KEYWORD "Junk" post = +FLAGS (Junk) } rewrite Trash { folder = * search = DELETED fetch = -FLAGS (\Deleted) post = +FLAGS (\Deleted) }
Views would not be deletable (unless one wants to invent some nonstandard IMAP extensions today), but they would otherwise look like regular folders. One could post and search and fetch messages as normal (with some alterations to various IMAP fields).
In the examples I gave:
A001 SELECT Junk A002 SEARCH ALL A003 SELECT Trash A004 SEARCH ALL A005 FETCH 1 FLAGS
would be translated into:
A001 SELECT INBOX A002 SEARCH ALL KEYWORD Junk A003 SELECT {for each SUBSCRIBED folder} A004 SEARCH ALL DELETED A005 FETCH 1 FLAGS
Except, A005 would actually yield:
- 1 FETCH (FLAGS ())
Instead of:
- 1 FETCH (FLAGS (\Deleted))
It would probably be ideal if these were configurable per-user, but I'd be happy with system-wide rewriting.
Options for rewrite could include: folder = folders that could be selected using LSUB OR a valid (existing) folder name. If this is system wide, pretty much only INBOX, INBOX.% and INBOX.* and * and % are valid :) search = tags to append to SEARCH operations on the view fetch = IMAP fields that are acceptable to STORE that we will pretend occurred when fetching. recent = IMAP fields that should be STORE'd when the \Recent flag is still set. post = IMAP fields that are acceptable to STORE that we will perform when APPENDing or STOREing. append = argument to be passed to /bin/sh -c which will receive on standard input the APPENDed body, and produce on output a STOREed body. open = argument for /bin/sh -c for when this view is SELECTed or EXAMINEd close = argument to be passed to /bin/sh -c for when the view is closed. index = argument to be passed to /bin/sh -c for when dovecot wants to index a portion of the message. standard input of the argument is the message, whereas standard output is the portion to actually index. path = a regular dovecot mailbox path that would contain the real contents of this folder.
ro path =
like path, but would be decidedly read-only (except for
any side-effects generated by append =)Subprocesses that exit 99 would handle the task internally- thus any normal actions (such as for index = and append =) would not occur. Exit code 0 is for normal completion, and all other exit codes should generate an error.
If one allowed open = and close = to be used on REAL folders, this would allow people to actually have the behavior UW-IMAP does by MOVING mail from /v/s/m into ~/mbox...
One could use append = with a "Outbox" view that could write the queue at the same time as storing a copy into Sent Items. One could also use append for gpg-signing messages as they're being recorded. One could also use append for publishing to a mailing list.
One could use index = to spell-check messages beforehand thus improving my chances of actually finding messages from my PHB.
One could also use append =, recent = and ro path = to emulate shared folders support in a manner that would be useful for using IMAP folders as a kind of work-queue.
Thoughts?