wasm-demo/demo/ermis-f/imap-protocol/cur/1600095027.22679.mbox:2,S

44 lines
1.8 KiB
Plaintext

MBOX-Line: From lists at hireahit.com Mon Apr 1 15:16:25 2013
To: imap-protocol@u.washington.edu
From: Dave Warren <lists@hireahit.com>
Date: Fri Jun 8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <5159AF25.9060707@psaux.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
<465A2A40-E7B0-421E-9140-D2672F0F682D@iki.fi>
<5159AF25.9060707@psaux.com>
Message-ID: <515A0739.2090700@hireahit.com>
On 2013-04-01 09:00, Tim Showalter wrote:
> On 3/30/13 2:01 PM, Timo Sirainen 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 the client is a mobile phone, they are coming from some NAT address
> and you stand a good chance of blocking a large number of users.
You wouldn't necessarily block the entire IP, but rather, the IP in
question from accessing that particular account. Or possibly all IMAP
access to the account in question since some mobile devices regularly
flip between IPs.
For two-factor-auth enabled users, you could just block that IP and a
specific two-factor password so as to impact the user as little as possible.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren