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


