The IMAP APPENDLIMIT Extension
draft-ietf-imapapnd-appendlimit-extension-10

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

(Ben Campbell) No Objection

Comment (2016-01-06 for -08)
No email
send info
- section 2, last paragraph:

It was not obvious to me if "An IMAP client SHOULD be able to parse both formats. " meant both STATUS and LIST, or both global and per-mailbox. I assume the former.

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2016-01-05 for -08)
No email
send info
It's unusual to see author names without first initials in the document header. Not sure if that was intentional but seems like it should be fixed (assuming the authors have both first names and surnames).

= Section 2 =

"In this case the client SHOULD get an APPENDLIMIT value by issuing a
   STATUS or LIST command.

   An IMAP client SHOULD be able to parse both formats.  By looking at
   the upload size advertised by the IMAP server, a client MUST NOT try
   to APPEND mail more than the advertised limit."

The first and last normative requirements here seem too strict considering that this extension basically allows an optimization. That is, if a client decides not to find out the append limit for a particular mailbox using STATUS or LIST, that doesn't seem to create any particular problem. Likewise, it seems better for a client to avoid sending an attachment larger than a known limit, but doing so doesn't seem so problematic as to warrant a MUST NOT.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2016-01-07 for -08)
No email
send info
Sarah Banks performed the opsdir review

(Kathleen Moriarty) No Objection

Comment (2016-01-05 for -08)
No email
send info
Thanks for your work on this extension, it seems useful, I just have a few comments that can be left to the editors and AD to handle if I disappear for maternity leave.  

I think the security considerations section could be a bit more clear on the actual risks with this extension.  I think the flow of the section can be improved to make these risks a bit more clear.

First, this extension lets you find out the limit for either the server or individual mailboxes, so shouldn't the first part of the description focus on a possible DoS filling up those resources?

I'm not sure why there is a focus on "without this extension".

Then, it's a common security programming practice to enforce size limitations in code.  Why is there a focus on an attacker sending append content that exceeds the allowable size rather than just saying that such append content should be rejected?

Alvaro Retana No Objection

(Martin Stiemerling) No Objection