MBOX-Line: From tss at iki.fi  Mon Apr  1 01:53:41 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: <CABa8R6uqeEuKJ=O7QG3+5QXJJZmj=ZEz88UuGL8qCSfmWQrYag@mail.gmail.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
	<465A2A40-E7B0-421E-9140-D2672F0F682D@iki.fi>
	<CABa8R6uqeEuKJ=O7QG3+5QXJJZmj=ZEz88UuGL8qCSfmWQrYag@mail.gmail.com>
Message-ID: <16568A67-AB8A-4627-AEC4-243E1B2709E7@iki.fi>

On 1.4.2013, at 8.42, Brandon Long <blong@google.com> wrote:

> On Sat, Mar 30, 2013 at 2:01 PM, Timo Sirainen <tss@iki.fi> wrote:
> On 26.3.2013, at 23.26, Brandon Long <blong@google.com> wrote:
> 
> > 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.
> 
> Did you consider blocking the client's IP for n minutes and sending the user an email explaining the issue and asking to reset the client?
> 
> 
> If we block the IP, they won't get the email either... but there may be something there that could work.

I was more thinking that the user would then login via webmail to find the mail. Maybe not block entirely but show login failure with [ALERT] or something.

> I'm more thinking that implementing the UTF8 rfc (or at least parts of it) would eliminate most of the need to use literals in commands, giving us the near equivalent to "only allow literal+ except for append".

Well, would be nice to implement UTF8 in any case, but somehow I doubt it's going to help anytime soon.


