Re: The IMAP APPENDLIMIT Extension

Hi Michael,

Thanks for your review comments. 

Please find my response inline. 

Regards,
Jay

-----Original Message-----
From: Michael M Slusarz [mailto:[email protected]] 
Sent: Monday, February 16, 2015 1:08 AM
To: [email protected]
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Quoting Jayantheesh S B <[email protected]>:

> Please find the next version of the draft updated with APPENDLIMIT=0 
> case addressed.

Was working on a test server implementation of this, and ran into several issues that need to be addressed/clarified.

1) The APPENDLIMIT value is defined in ABNF as a "number", which is limited to 32-bits.  Seems like this should be 64-bits instead to better reflect modern resource limitations (or at least an unsigned 63-bit number, such as MODSEQs).

[Jay] Yes,  ABNF can be changed similar to that of MODSEQ to accommodate 64-bits. 

2) I don't believe the APPENDLIMIT response code should be returned for an EXAMINE operation.  The value is irrelevant since you can't append to a read-only mailbox.  It's possible that APPENDLIMIT may be somewhat expensive to generate - i.e. a quota value that needs to be determined/parsed/updated - so there's no need to report it when it is not directly usable.

[Jay] As per IMAP base RFC3501, If a client issues EXAMINE command, only permanent state and flags of the mailbox should not be changed. 

The EXAMINE command is identical to SELECT and returns the same
      output; however, the selected mailbox is identified as read-only.
      No changes to the permanent state of the mailbox, including
      per-user state, are permitted; in particular, EXAMINE MUST NOT
      cause messages to lose the \Recent flag.

Even I have observed that Gmail, AOL, Yahoo and Isode allows Appending the message in READ-ONLY mode.  Please find the transaction snippet below.

02-17 15:30:31.350  4433 12278 D MailTransport: >>> 25 EXAMINE "Drafts"
02-17 15:30:31.510  4433 12278 D Email   : <<< #null# ["OK", ["CLOSED"], "Previous mailbox closed"]
02-17 15:30:31.520  4433 12278 D Email   : <<< #null# ["FLAGS", ["\Answered", "\Flagged", "\Deleted", "\Draft", "\Seen"]]
02-17 15:30:31.520  4433 12278 D Email   : <<< #null# ["OK", ["PERMANENTFLAGS", []], "Flags"]
02-17 15:30:31.530  4433 12278 D Email   : <<< #null# ["0", "EXISTS"]
02-17 15:30:31.530  4433 12278 D Email   : <<< #null# ["0", "RECENT"]
02-17 15:30:31.540  4433 12278 D Email   : <<< #null# ["OK", ["UIDVALIDITY", "1398813396"], "UIDs valid"]
02-17 15:30:31.540  4433 12278 D Email   : <<< #null# ["OK", ["UIDNEXT", "20"], "Predicted next UID"]
02-17 15:30:31.540  4433 12278 D Email   : <<< #null# ["OK", ["URLMECH", "INTERNAL"], "URL mechs"]
02-17 15:30:31.540  4433 12278 D Email   : <<< #null# ["OK", ["HIGHESTMODSEQ", "67"], "Highest"]
02-17 15:30:31.550  4433 12278 D Email   : <<< #25# ["OK", ["READ-ONLY"], "EXAMINE Completed"]

02-17 15:30:31.660  4433 12278 D MailTransport: >>> 26 APPEND "Drafts" (\SEEN \DRAFT) {994}
02-17 15:30:31.820  4433 12278 D Email   : <<< #+# ["go ahead"]
02-17 15:30:32.430  4433 12278 D Email   : <<< #null# ["1", "EXISTS"]
02-17 15:30:32.450  4433 12278 D Email   : <<< #null# ["1", "RECENT"]
02-17 15:30:32.460  4433 12278 D Email   : <<< #26# ["OK", ["APPENDUID", "1398813396", "20"], "APPEND Completed"]

I believe APPENDLIMIT response code as part of EXAMINE command is fine.

3) I believe this was mentioned by at least one other person, but the current handling of the response code in the mailbox is not correct, at least according to the draft specification.

Take this example:

<QUOTA active; user currently has 100 bytes left in account>
a1 SELECT INBOX
<...>
* OK [APPENDLIMIT 100]
a1 OK [READ-WRITE] Done
a2 STORE 1 +flags \deleted
* 1 FETCH (FLAGS (\Deleted))
a2 OK
a3 EXPUNGE
* 1 EXPUNGE
* 0 EXISTS
a3 OK

Assuming that message 1 was 100 bytes, the quota for the user is now up to 200 bytes.  This should be the new APPENDLIMIT value, but according to the spec this does not need to be reported/updated.

This needs to be handled similarly to the way that message counts are updated when in the selected state.  Although, as mentioned above, the appendlimit value may not be a trivial item to calculate so this can start to become a fairly expensive feature add.

It makes me wonder whether adding this response code this is the correct approach.  APPENDs will normally happen in an unselected state (there are at least 2 server implementations that I am aware of that don't allow APPENDs to a selected mailbox), so this information is better obtained by using one of the other two methods anyway.

michael

___________________________________
Michael Slusarz [[email protected]]


_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext