37 lines
1.5 KiB
Plaintext
37 lines
1.5 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Wed Mar 27 13:04:05 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] Working around the evils of LITERAL+
|
|
In-Reply-To: <B2E07E1B-80E9-4FFB-8518-B4CDC344639E@isode.com>
|
|
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
|
|
<DA4AB101-1D7E-466C-8DA1-6234EB098FF8@iki.fi>
|
|
<CABa8R6v5dApFF6Quwzrb0=XethrwCU0EQT6t3XtLVK6VRoYhmA@mail.gmail.com>
|
|
<B2E07E1B-80E9-4FFB-8518-B4CDC344639E@isode.com>
|
|
Message-ID: <20130327140405.Horde.xVBCOb0icPn4imuUgPQweQ2@bigworm.curecanti.org>
|
|
|
|
Quoting Alexey Melnikov <alexey.melnikov@isode.com>:
|
|
|
|
> On 26 Mar 2013, at 23:03, Brandon Long <blong@google.com> wrote:
|
|
>
|
|
>> 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.
|
|
|
|
Throwing out another idea: What about updating LITERAL+ and explicitly
|
|
excluding its usage with APPEND. IMAP already has a mechanism for
|
|
rejecting overly large appends - NO response to APPEND command
|
|
continuation request - so would be nice to leverage this feature
|
|
instead of adding a new one.
|
|
|
|
Regardless... it probably makes sense for any server to return the
|
|
LIMIT response code in this situation since this is a textbook example
|
|
of an "operation [that] ran up against an implementation limit of some
|
|
kind".
|
|
|
|
michael
|
|
|
|
|