Skip to main content

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

Yes

(Barry Leiba)

No Objection

(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Stephen Farrell)

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

Barry Leiba Former IESG member
Yes
Yes (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2016-01-05 for -08) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-01-06 for -08) Unknown
- 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 Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-01-07 for -08) Unknown
Sarah Banks performed the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-01-05 for -08) Unknown
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?
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -08) Unknown