MBOX-Line: From dave at cridland.net  Thu Nov 24 03:25:52 2005
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] Re: IMAP capability for maximum APPEND message size?
In-Reply-To: <43858BAB.7080404@sun.com>
References: <Pine.OSX.4.64.0511231556030.533@pangtzu.panda.com>
	<27488.1132823348.282206@peirce.dave.cridland.net>
	<43858BAB.7080404@sun.com>
Message-ID: <27773.1132831552.908324@peirce.dave.cridland.net>

On Thu Nov 24 09:45:15 2005, Arnaud Taddei wrote:
> It is true that there are more an more meta properties at the 
> folder level and the trend is not decreasing (and we are missing 
> ACAP though ACAP is making it through ANNOTATE and ANNOTATEMORE 
> no?).
> 
> 
You may be missing ACAP, but I'm not, I use it all the time. :-)


> Though here this is a general APPEND config and it is why I don't 
> see it as a per folder mechanism. I think this is the symmetric to 
> SMTP size limits so I would leave it as Mark explained.

But any limitation aside from a policy-based limitation is 
potentially at a finer granularity than the server.

Pete Maclean has already proposed it be a NAMESPACE extension, I'd 
prefer it to be per-mailbox, and try to provide a sensible 
architecture for per-mailbox capabilities at the same time, instead 
of the suck-it-and-see mechanisms we have now. (BINARY APPEND support 
is another per-mailbox capability, currently handled by 
suck-it-and-see.)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

