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

47 lines
1.9 KiB
Plaintext

MBOX-Line: From imap at maclean.com Wed Mar 27 19:56:26 2013
To: imap-protocol@u.washington.edu
From: Pete Maclean <imap@maclean.com>
Date: Fri Jun 8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <5A6676FF-E967-48F1-839C-56149288A402@orthanc.ca>
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>
<78AB33AC-4EFC-42AF-80F8-AD1FB3C26746@iki.fi>
<5A6676FF-E967-48F1-839C-56149288A402@orthanc.ca>
Message-ID: <mailman.16.1528486490.22076.imap-protocol@mailman13.u.washington.edu>
If we have to submit to per-mailbox limits then another idea would be
to add a MAXAPPENDSIZE item to the STATUS command. This could
perhaps be a 64-bit value like HIGHESTMODSEQ. And it could be set to
zero to indicate that the mailbox cannot accept APPENDs at all.
Pete Maclean
At 10:30 PM 3/27/2013, Lyndon Nerenberg wrote:
>On 2013-03-27, at 3:27 AM, Timo Sirainen wrote:
>
> > So .. maybe a per-mailbox limit isn't that useful. I was mainly
> thinking about different users having different limits, causing
> shared mailboxes to have different limits. Or maybe some other
> special mailboxes with special rules.
>
>Why not require the server to issue a [LITERALPLUSSIZE nnn] whenever
>the server's state changes the value it's prepared to deal
>with. That makes it agnostic to any existing and future extensions.
>
>You could then set limits by user, by folder, by user+folder,
>etc. Lots of flexibility, and it never has to be updated for
>follow-on capabilities. (I run in fear of the 64-bit proposal.)
>
>--lyndon
>
>_______________________________________________
>Imap-protocol mailing list
>Imap-protocol@u.washington.edu
>http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol