Re: Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt

Quoting Arnt Gulbrandsen <[email protected]>:

> On Thursday, December 18, 2014 1:14:12 PM CEST, Alexey Melnikov wrote:
>> Allowing smaller non synchronizing literal sizes in APPEND might  
>> work, but the problem is that this still allows for abuse if the  
>> limit is exceeded.
>
> Not really, not if the limit is comparable to typical TCP send  
> windows. A badly behaving client can send one TCP window's worth of  
> stuff to the server anyway.
>
> Specifically, the client can send
>    a append inbox () "01-01-2000" {9999999999999999999999999999+}
> no matter whether which part of that line is forbidden, and the  
> server has to eat one whole TCP window before it can throw the  
> client out.

I do like having the option of allowing small messages to be directly  
appended with LITERAL+.  That's the way I've coded APPENDs currently.

Arnt's selection of 16k seems reasonable when viewed through the  
network lens.  Although with multipart/alternative and/or HTML  
messages being more prevalent these days, this probably means that the  
majority of sent-mail like APPENDs won't fall under this 16k  
exception.  So wondering if that means a large limit is needed (64k?)  
or whether we are adding complexity for optimizing only a limited  
number of APPEND transactions and this would be overkill.

michael

___________________________________
Michael Slusarz [[email protected]]

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