Re: Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Barry Leiba <[email protected]> Thu, 7 Jan 2016 06:39:18 +0800
Newsgroups gmane.ietf.imapext
Message-ID <CALaySJ+cH_v0fdO9dFwxgNZt71AcoBdQssJhb0NbOZvWB4EVJA@mail.gmail.com>
>>> "But with this extension, the attacker can immediately choose a value
>>> that's a little too large,"
>>>
>>> It doesn't read well to me.  Why would they chose a value that's a
>>> little too large?  Too large for what?  They already have the size
>>> limit per server or per mailbox.  Does this mean they will send a
>>> bunch of messages with the append size maxed out for the mailbox or
>>> the server to fill the quota?
>>
>> The point of the attack isn't filling a mailbox; it's sending
>> boatloads of data to the server.  Suppose there's a limit of 2 MB.  If
>> the client sends 2 MB messages repeatedly, those messages will
>> eventually cause the mailbox to hit the quota, and further attempts to
>> bombard the server will be rejected.  But messages that are, say,
>> 2.1MB will fail to append (the server will respond "NO" to them), and
>> the client can keep bombarding the server with such messages.  The
>> text is trying to warn about that, suggesting that the server might
>> "take a hard line" -- that is, take more serious action than just
>> saying "NO" to the append attempts, but perhaps actually lock out the
>> account until someone checks out the situation.
>
> This point wasn't clear to me from the current text.  I'd suggest updating it to make it more clear.

I think it is, so please suggest specific text that you think will
help clarify it for you.

>>> Why isn't it explicit in that such messages should/MUST be rejected?
>>
>> The messages themselves will be rejected (they APPEND command will get
>> "NO" for a response), but the damage -- the sending of a lot of data
>> unnecessarily -- will have already been done.
>
> Can this be made more clear as well?  It's not in the current text.

No, it's not, because it's how IMAP works.  This really isn't
something we need to make clear here: anyone implementing this already
knows this and will already be doing it.  This is only about
advertising an APPEND limit, not about how APPEND works and how you
say "NO" to an APPEND command.

Barry

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