On 3/28/13 1:17 PM, SM wrote:
Hi Eric,
At 05:13 28-03-2013, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would
offer it would be better to say what we mean, like:
The IMAP interface MUST NOT provide any IMAP facilities that
modify the underlying message and message metadata, such as mailbox,
flags, marking for deletion, etc. If the client is authenticated and
authorized, the IMAP interface MUST provide per-user marking of the
underlying message as read or flagged.
The IMAP interface is a front-end to the read-only mailboxes
(archive). It's easier to do what is mentioned above.
I'm taking more or less that approach in my working copy (I'll be
posting -06 soon).
Something to ponder:
I use the IMAP interface once, mark a bunch of things as read, and
then decide never to use the IMAP interface ever again. How long does
the server need to keep my (per-user) marking metadata? E.g., besides
CPU and I/O issues, there is a potentially unbounded storage problem
as well. It is unbounded because in IMAP I can assign any kind of
label (marking) to a message, even ones I make up.
One thought for an approach to a solution:
1. per-user markings expire after X time units (six months?)
2. per-user markings may take up at most X storage units (512KB?)
I would go for both.
Instead, I propose that we make it possible to notice an abuser and turn
off access (this is what -06 will contain).
I don't believe we could come to a consensus on an automatic expiry of
state - there are use cases I can think of where any short
expiration (like 6-months) would be infuriating.
If keeping this state for normal use turns out to be too expensive for
us, then we will have learned something, and can start talking about
future IMAP work in general to help systems mitigate that expense.
Per-user metadata can be incredibly useful - I might label things by
project, work group, draft, mumble, or foo. I would not want to limit
the labels to red or green. However, we need some predictable limit
as well.
Yes.
Regards,
-sm