Subject: Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

From: Robert Sparks <[email-masked]>
Date: Mon, 01 Apr 2013 16:41:34 -0500

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Apr 2013 19:49:37 -0400

May I suggest that the specific details of this be left to the
implementation effort.  What is easy to implement in this area depends
significantly on what platform (and here I mean more imap libraries and
imap server technology than say python vs ruby vs .net vs C) A simple
requirement like the implementation should consider how to handle abuse
of message marking.

---

From: Burger Eric <[email-masked]>
Date: Mon, 1 Apr 2013 17:58:16 -0400

Fine with me.

On Apr 1, 2013, at 5:41 PM, Robert Sparks <[email-masked]> 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.
>>> 
> 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
> 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
>

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Apr 2013 06:47:18 -0400

Works for me.

--
Sent from my mobile device. Thanks be to lemonade!  
http://www.standardstrack.com/ietf/lemonade/

-----Original message-----
From: Alexey Melnikov <[email-masked]>
To: Burger Eric <[email-masked]>
Cc: Robert Sparks <[email-masked]>, [email-masked]
Sent: Tue, Apr 2, 2013 09:53:39 GMT+00:00
Subject: Re: Missing requirement in draft-sparks-genarea-imaparch?           
(was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

Hi Eric,
I am sorry if I sound pedantic below, but I think your suggestion can be 
misinterpreted and thus needs improving:

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.
One way to implement this is in an IMAP server is to always fail 
commands for modifying message metadata. Another way of implementing 
this is to allow them, but ignore (don't persist) results. Both ways 
were used in the past and they have different effect on IMAP clients. I 
hope the requirement is intended to allow for either.

Another thing to consider is that for IMAP servers that implement IMAP 
ACL, the easiest way to meet the intended requirement is by not allowing 
unauthorized users to access some commands on a mailbox. Again, a 
possible reading of your suggested text is that that is not allowed.

So, my suggestion is to change "MUST NOT provide any IMAP facilities 
..." to "MUST disallow any IMAP facilities ...".

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Apr 2013 10:54:21 +0100

Hi Eric,

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 1 Apr 2013 18:41:12 +0100

On 27 Mar 2013, at 20:31, Robert Sparks <[email-masked]> wrote:

> While looking at it, I noticed we don't explicitly say that this IMAP interface MUST NOT
> allow messages in the archive to be deleted

I would actually allow administrative users to delete messages (e.g. spam), but such actions should be recorded in logs. Other users shouldn't be allowed to do that.

> or moved to other mailboxes, and MUST NOT
> allow messages to be inserted. I plan to add those as requirements in the next version.

This is fine with me.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Apr 2013 09:46:32 -0500

> requirement like the implementation should consider how to handle abuse
Sam - I agree, and was taking a very similar approach in my working copy 
already.
Let me know if you think -06 has it right.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Apr 2013 09:46:36 -0500

On 4/2/13 4:54 AM, Alexey Melnikov wrote:
> Hi Eric,
> I am sorry if I sound pedantic below, but I think your suggestion can 
> be misinterpreted and thus needs improving:
>
> were used in the past and they have different effect on IMAP clients. 
> I hope the requirement is intended to allow for either.
>
> ACL, the easiest way to meet the intended requirement is by not 
> allowing unauthorized users to access some commands on a mailbox. 
> Again, a possible reading of your suggested text is that that is not 
> allowed.
>
I think I found a way to say this that strikes a good balance in -06. 
Let me know what you think.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 Apr 2013 10:53:40 -0500

> Let me know what you think.

Excellent. Ship it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Apr 2013 12:10:24 -0400

Alexey:

Of course we want to be able to delete spam, but this is being used to access an archive, so only the administrator should be able to delete the spam.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Apr 2013 09:22:18 -0700

On 4/3/2013 9:10 AM, Russ Housley wrote:
> Alexey:
>
> Of course we want to be able to delete spam, but this is being used
> to access an archive, so only the administrator should be able to
> delete the spam.
>
> Russ
>
>
>>> While looking at it, I noticed we don't explicitly say that this
>>> IMAP interface MUST NOT allow messages in the archive to be
>>> deleted
>>
>> I would actually allow administrative users to delete messages
>> (e.g. spam), but such actions should be recorded in logs. Other
>> users shouldn't be allowed to do that.

I'm  confused Russ.  Isn't that exactly what Alexey recommends, here?

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Apr 2013 12:23:56 -0400

> I'm  confused Russ.  Isn't that exactly what Alexey recommends, here?

The administrator does not have to use the IMAP interface.  They could use a different interface.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Apr 2013 09:44:41 -0700

>>> to access an archive, so only the administrator should be able to
...
> The administrator does not have to use the IMAP interface.  They could use a different interface.

Your previous note specified /who/ should have the capability; this 
matches what Alexey said.

Your note now refers to /how/ and appears to mean that you believe they 
should not be allowed to exercise that capability via IMAP.

d/