Subject: Re: [imapext] Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 Mar 2015 11:09:42 +0000

On 19/12/2014 09:26, Dave Cridland wrote:
>
> On 17 December 2014 at 18:35, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I revived and updated LITERAL+ extension. I also added LITERAL-
>     extension (same as LITERAL+, but disallowed in APPEND).
>
>
> Given the current discussions, wouldn't LITERAL- be better expressed 
> as a LITERAL+ with a limited size?
I can go along with that. What is a reasonable limit?
Also, this has interactions with APPENDLIMIT.

Any other opinions on what people prefer?

> I accept that the normal case for a large literal is APPEND,  but the 
> issue is a general one with the size of the literal rather than the 
> specific case of APPEND, isn't it?
>
> This could even be an advertised token-sequence limit, but that's 
> probably too hard to express.
Sounds like overkill. Either way, can you suggest how this is going to 
look like?

> Possible, though, to limit the amount of non-synchronized literal data 
> with an entire command, which'd handle the MULTIAPPEND case as well.
>
> To give an specific case, a client can always side-step a simple 
> APPEND LITERAL+ limit by just using CATENATE in a fairly abusive manner.

A client that can append can do all sort of damage. Selecting INBOX and 
doing "COPY 1:* INBOX" in a loop is my favourite.

Best Regards,
Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 5 Mar 2015 12:54:50 +0100

Alexey Melnikov wrote:
> A client that can append can do all sort of damage. Selecting 
> INBOX and doing "COPY 1:* INBOX" in a loop is my favourite.

That was my favourite way of building a large mailbox for testing ;) A few 
appends, then a dozen or two copy commands.

More relevantly, trying to prevent one thing by blocking another is just 
whackamole. Tiresome and ultimately fruitless. Multiappend, copy, catenate 
and SMTP all offer ways to get around the size limit, if that's the game.

I sort of like 2088bis, but I think it should state what it tries to 
achieve and forget the rest. This could be good: "This is intended to limit 
the resource waste by errant clients, not to enforce any kind of quota 
(RAM, disk space, I/O or anything else) or to stop malevolent clients. 
Malevolent clients are considered a task for the system administrator."

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Thu, 5 Mar 2015 16:08:21 +0000

On 5 March 2015 at 11:09, Alexey Melnikov <[email-masked]> wrote:

> On 17 December 2014 at 18:35, Alexey Melnikov <[email-masked]>
> wrote:
>
>  Given the current discussions, wouldn't LITERAL- be better expressed as
> a LITERAL+ with a limited size?
>

Configurable and advertised, but I'd go for around 2048 octets for a single
token.

> Sounds like overkill. Either way, can you suggest how this is going to
Not in any way that'd be useful as a formal description.

It's a matter of saying something along the lines of a command line length,
including any non-synchronizing literals, must not exceed X octets.

>  To give an specific case, a client can always side-step a simple APPEND
> LITERAL+ limit by just using CATENATE in a fairly abusive manner.
>
>

I meant to side-step the limits in an annoying manner by abusing CATENATE,
stringing together hundreds of TEXT sections.

Overall I think a per-literal limit works best, though, since anything else
is clearly abuse. But abandoning literals within an APPEND command entirely
is silly - if a message fits within 2048 (unlikely, though possible for
small notes) or a TEXT item in CATENATE (quite likely), then a non-synch
literal seems the best solution.

Conversely, a non-synch literal size limit also would help with any
(present or future) case where large literals might be used with commands
other than APPEND.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Mar 2015 11:34:00 +0000

On 05/03/2015 16:08, Dave Cridland wrote:
>
> On 5 March 2015 at 11:09, Alexey Melnikov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>         I revived and updated LITERAL+ extension. I also added
>>         LITERAL- extension (same as LITERAL+, but disallowed in APPEND).
>>
>>
>>     Given the current discussions, wouldn't LITERAL- be better
>>     expressed as a LITERAL+ with a limited size?
> Configurable and advertised, but I'd go for around 2048 octets for a 
> single token.
I've seen lots of small messages around 3-4Kb, so how about 4096 
instead? It is still going to be a single TCP packet in most cases.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Mar 2015 11:42:28 +0000

On 9 March 2015 at 11:34, Alexey Melnikov <[email-masked]> wrote:

> I've seen lots of small messages around 3-4Kb, so how about 4096 instead?
> It is still going to be a single TCP packet in most cases.
>

Since my figure was plucked from thin air, I'm happy to go along with
anyone else's, but I'm curious as to whether there's any hard data on
message sizes and TCP packet sizes on various networks.

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Mar 2015 12:48:44 +0100

Alexey Melnikov writes:
> I've seen lots of small messages around 3-4Kb, so how about 
> 4096 instead? It is still going to be a single TCP packet in 
> most cases.

No, not one packet. What you mean is the typical TCP window, ie. the number 
of bytes a TCP sender can send without waiting for Ack from the peer. Which 
is often 4500 until the peers negotiate different values.

I quite agree that 2048 is too low. Any value between 4096 and 32768 is 
okay, I think, and practically equivalent. Most messages are either <4096 
(when leaving the sending MUA) or >32768.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Mar 2015 12:56:11 +0100

Dave Cridland writes:
> Since my figure was plucked from thin air, I'm happy to go 
> along with anyone else's, but I'm curious as to whether there's 
> any hard data on message sizes and TCP packet sizes on various 
> networks.

Vast amounts of network data are available if you ask people who work on 
TCP implementations. I don't, but I keep an eye on it since I have written 
that a long time ago.

The tl;dr: The packet size is 1500 everywhere except on VPNs. 1280 may be 
considered a lower bound these days. Less than that, and you get in trouble 
with IPv6, which was okay in 2005 but generates too many customer 
complaints if you do it in 2015. Sending three packets without asking for 
ack is considered polite and not harmful (Google did a lot of research on 
that in order to speed up their search result page), so 3*1500 minus a bit 
is a safe amount to send.

Arnt