Re: AD review of draft-ietf-imapapnd-appendlimit-extension-06

> Please find the latest version of the draft (version 07) attached. As
> per the review discussion, we have updated the draft.
...
> We will upload the draft once if all the review comments has been addressed.

This looks mostly good, and thanks very much for all the work on this.
The ABNF and the Security Considerations still need a bit (see below).
Some editorial nits to fix, as well, before it's ready to post.
Below, "OLD" refers to text in the proposed -07 version.  Except for
the ABNF and Security considerations, these are all very minor
editorial things.

In the abstract, make it "APPEND commands" (plural).

In the Introduction:

OLD
   Several IMAP servers have limitation for mail upload size which is
   not published to the email client.  When email client APPEND a mail
   with huge attachments, using non-synchronizing literals it fails due
   to size restriction set by the IMAP server.
NEW
   Some IMAP servers have limits for mail upload size, and those limits
   are not published to the email client.  When the email client APPENDs
   a message with huge attachments, using non-synchronizing literals,
   the APPEND fails because of the upload limit, but the client has
   already sent the message data anyway.
END

In Section 3:

OLD
   IMAP server can have mailbox specific APPENDLIMIT value, which will
   not be advertised as part of CAPABILITY response.  The IMAP server
   can publish NIL for a mailbox to convey that there is no APPENDLIMIT
   to that mailbox [RFC4466].
NEW
   An IMAP server can have mailbox-specific APPENDLIMIT values, which
   will not be advertised as part of CAPABILITY response.  The IMAP
   server can publish specific values for each mailbox, and can publish
   "NIL" for a mailbox to convey that there is no APPENDLIMIT for that
   mailbox.
END

(I don't think there's any need for a citation to 4466 here; we'll
have it below, by the ABNF.)

In the section titles of 3.1 and 3.2, make it "STATUS response to the"
(not "in the").  This was my error when I suggested the change; sorry.

Similarly, in Section 3.2 take out the word "emit", which was there in error.

In Section 5, I think you misunderstood Alexey's suggestion for using
the 4466 changes.  Let's try this; Alexey, please check that I got
this right:

Replace all the ABNF in Section 5 with this:

NEW
   capability /= "APPENDLIMIT" ["=" number]
               ;; capability is defined in RFC 3501

   status-att /= "APPENDLIMIT"
               ;; status-att is defined in RFC 3501

   status-att-val /= "APPENDLIMIT" SP (number / nil)
               ;; status-att-val is defined in RFC 4466
END

...and also make this change:

OLD
   [RFC3501] defines the non-terminals
   "capability", "resp-text-code" and "status-att".
NEW
   [RFC3501] defines the non-terminals
   "capability" and "status-att", and [RFC4466] defines
   "status-att-val".
END

Reasoning:
First, I think the extra level of indirection, making two lines per
item, was only confusing.

Second, there seem to be three things you need to do: (1) add the
capability string, (2) add the APPENDLIMIT status option, and (3) add
the APPENDLIMIT status response.  Those three items do it.  I don't
know why you had the addition to resp-text-code -- it was always the
wrong thing to have, and we missed it before.

In the paragraph after the ABNF, change "A number indicating the fixed
maximum" to "The number indicates the fixed maximum".

In Section 6, my comment about the security considerations still needs
to be addressed.  You say this:

   The IMAP APPENDLIMIT extension described in this document can
   conceivably be used to facilitate Denial-of-Service attacks.
   Specifically, the information contained in the APPENDLIMIT capability
   and use of the APPEND command make it somewhat quicker and easier to
   devise an efficacious Denial-of-Service attack.  However, unless
   implementations are very weak, these extensions do not create any
   vulnerability that has not always existed with IMAP.

I still ask: Why does this information make it quicker and easier to
do a DoS attack?  I don't see it, and the document needs to explain it
clearly.  I can always, with or without this option, try to append a
very large message using a non-synchronizing literal for the message
data.  What is it about this extension that makes it quicker, easier,
or more effective (I'd avoid the more obscure word "efficacious")?

Barry

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