44 lines
2.0 KiB
Plaintext
44 lines
2.0 KiB
Plaintext
MBOX-Line: From tss at iki.fi Thu Nov 24 03:19:53 2005
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:36 2018
|
|
Subject: [Imap-protocol] Re: IMAP capability for maximum APPEND message size?
|
|
In-Reply-To: <Pine.OSX.4.64.0511231556030.533@pangtzu.panda.com>
|
|
References: <Pine.OSX.4.64.0511231556030.533@pangtzu.panda.com>
|
|
Message-ID: <1132831193.14231.285.camel@localhost.localdomain>
|
|
|
|
On Wed, 2005-11-23 at 16:08 -0800, Mark Crispin wrote:
|
|
> I am considering the addition of a trivial new capability to IMAP that
|
|
> would advertise the maximum size of a message in APPEND (and probably also
|
|
> CATENATE). This has the same purpose as the SIZE capability in SMTP.
|
|
>
|
|
> 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).
|
|
>
|
|
> Rather than have this be a secret, I propose a capability called
|
|
> MAXAPPENDSIZE=nnn, where nnn is the size.
|
|
|
|
Well, personally I don't see a need for it. If you're sending message
|
|
size in APPEND as a normal literal, the server can reject it
|
|
immediately. So it would be useful for literalplus only.
|
|
|
|
And is it really the message size limit that's a problem? If your
|
|
system/code is able to handle only 2GB files, how does 10MB message size
|
|
limit help if the whole mailbox size is already 1,99GB?
|
|
|
|
Also I think in many (most?) cases you'll reach out-of-quota condition
|
|
before server's maximum allowed message size, and in that case it
|
|
doesn't matter what the message size limit was.
|
|
|
|
Is +1 overflow problem really an issue? If you're using 32bit file
|
|
offsets, the file limit is 2GB. As long as you're using unsigned
|
|
integers to perform your internal calculations, there are no overflow
|
|
problems. If you want larger files, you're using 64bit offsets and again
|
|
there are no overflow problems.
|
|
|
|
|
|
|