MBOX-Line: From tss at iki.fi  Tue Mar 26 14:52:27 2013
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
Message-ID: <DA4AB101-1D7E-466C-8DA1-6234EB098FF8@iki.fi>

On 26.3.2013, at 23.26, Brandon Long <blong@google.com> wrote:

> This was because of some unfortunate combination of factors.  For one, we have a maximum message size on our server, with no real way to make that available to IMAP (maybe via GETQUOTA, but if no clients check it, that's not that useful).  For two, we have an inbound bandwidth quota to protect against both broken clients and attempts to use Gmail IMAP as a storage system.
> 
> So, if a user attempted to draft a message larger than our limit (35MB),

Seems a bit small limit to me.

> 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.


