MBOX-Line: From slusarz at curecanti.org  Tue Mar 26 15:30:25 2013
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <DA4AB101-1D7E-466C-8DA1-6234EB098FF8@iki.fi>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
	<DA4AB101-1D7E-466C-8DA1-6234EB098FF8@iki.fi>
Message-ID: <20130326163025.Horde.rCiAnaUmvPUaLmL5tkpnSA1@bigworm.curecanti.org>

Quoting Timo Sirainen <tss@iki.fi>:

> On 26.3.2013, at 23.26, Brandon Long <blong@google.com> wrote:
>
>> with LITERAL+, the client would just issue an APPEND with two large  
>> a message.  Our options were to just eat the data and say NO  
>> afterwards (great waste of bandwidth) or drop the connection.  Some  
>> clients would just keep retrying to do the APPEND until they  
>> exhausted the upload bandwidth quota, or just cost the user a lot  
>> of money if they happened to be on a line that charged.
>
> You can answer NO immediately and then eat away the data. I don't  
> know if any clients will handle it though.

Probably not.  Especially if the client is pipelining the data with  
the LITERAL+ argument.

Anyway, this is a known issue:  
http://tools.ietf.org/html/rfc4549#section-4.2.2.3  We explicitly  
disable LITERAL+ for our APPEND actions for precisely this reason - to  
capture NO responses before we send potentially large data payloads  
(although we compromise a bit and only disable LITERAL+ if the literal  
data is greater than 0.5 MB. No magic about that number - just a guess  
at the cost/benefit of wasted bandwidth vs. waiting for literal  
confirmation).

I think you've already laid out the only 2 sane choices: either take  
the bandwidth hit to send the proper response or immediately drop the  
connection, albeit at the expense of making people think your software  
is "broken".  For the former, you can issue a CLIENTBUG response code  
in the hopes that maybe a client author will see it and fix their  
APPEND usage.

michael


