MBOX-Line: From blong at google.com  Tue Mar 26 14:26:37 2013
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
Message-ID: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>

More than a year ago, we (Gmail) disabled LITERAL+ on our servers.

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

So, we disabled LITERAL+... but now I watch some UTF-8 SEARCH commands that
have N literals in them, each requiring a server response, its just kind of
evil.

I guess we could have the server learn that a user is using a bad client
and disable LITERAL+ automatically, anyone have any other ideas?

Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130326/5cb610fb/attachment.html>
