32 lines
2.1 KiB
Plaintext
32 lines
2.1 KiB
Plaintext
MBOX-Line: From alexey.melnikov at isode.com Wed Mar 27 03:03:57 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Alexey Melnikov <alexey.melnikov@isode.com>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] Working around the evils of LITERAL+
|
|
In-Reply-To: <CABa8R6v5dApFF6Quwzrb0=XethrwCU0EQT6t3XtLVK6VRoYhmA@mail.gmail.com>
|
|
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
|
|
<DA4AB101-1D7E-466C-8DA1-6234EB098FF8@iki.fi>
|
|
<CABa8R6v5dApFF6Quwzrb0=XethrwCU0EQT6t3XtLVK6VRoYhmA@mail.gmail.com>
|
|
Message-ID: <B2E07E1B-80E9-4FFB-8518-B4CDC344639E@isode.com>
|
|
|
|
On 26 Mar 2013, at 23:03, Brandon Long <blong@google.com> wrote:
|
|
|
|
> On Tue, Mar 26, 2013 at 2:52 PM, Timo Sirainen <tss@iki.fi> wrote:
|
|
> 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.
|
|
>
|
|
> Heh, sure, we get that from some users from time to time, but almost every part of our system requires loading the whole message into memory at some point (or two copies), and that adds up quick. And its fairly typical from the major webmail providers. And frankly, SMTP is a pretty poor file transfer protocol, what with the base64 encoding and the lack of checksumming or restartability and the duplicate delivery vagueness.
|
|
>
|
|
> And that limit is advertised via EHLO at SMTP time, but there's no mechanism for doing that with IMAP.
|
|
|
|
Let's standardize a way to advertise such limit. I might have use for it as well.
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130327/400a0fad/attachment.html>
|