[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Imap-protocol] Re: IMAP capability for maximum APPEND message size?
On Thu Nov 24 00:08:09 2005, Mark Crispin wrote:
Currently, the only message size limit in IMAP is 4294967295 (2^32
- 1) due to IMAP's use of unsigned 32-bit integers. Supporting
that size is troublesome due to +1 overflow problems. Many
implementations have much smaller limits, such as both for
administrative and technical reasons (many filesystems encounter
problems after 2^31 - 1).I have the strange suspicion that if anyone else had suggested this,
you'd have personally shot the proposal down by pointing out that
maximum message size depends on the mailbox driver and/or the
filesystem the data resides on, rather than the server as a whole,
and thus it needs to be a per-mailbox capability. Since you're
proposing this, it befalls me to shoot it down instead. :-)
Rather than have this be a secret, I propose a capability called
MAXAPPENDSIZE=nnn, where nnn is the size.
Currently, there's an ever-growing list of these per-mailbox
capabilities, generally handled by adding gumph (untagged OK with a
response-code) to SELECT, meaning that a client has to SELECT the
mailbox before it knows of certain capabilities - I've never liked
this much. I'd prefer to add these as either a new mechanism within
the protocol (that is, a new command, or LIST-EXTENDED extended data
item), or by extending some other item (such as STATUS, or
ANNOTATEMORE). Other examples are CONDSTORE, ANNOTATE, etc.
I'm not interested in command line length at all, perhaps because I
would hate to add that code to Polymer. (Although Polymer does, of
course, use set-syntax, and UID ranges are extended over non-existent
UIDs in order to reduce the size).
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
Imap-protocol mailing list