xfer problem -- Fatal error: literal too big

[Wesley Craig]

maxmessagesize has no bearing on MAXLITERAL.  maxmessagesize is an  
admin limit, whereas MAXLITERAL is a machine/protocol limit.  Setting  
it to INT_MAX / 20 is laudably cautious, but is too small for sites  
that allow 100+ MB messages and 1+ GB mailboxes -- neither large  
messages nor large cyrus metadata can be xfer'd.

The way the code is written, I would suggest defining MAXLITERAL as  
INT_MAX - 1.  This allows the code to function as expected without  
making any further changes.

:wes

On 02 Aug 2005, at 11:30, Paul Turgyan wrote:
> Anyway, it would be good if lmtpd and imapd, and the other
> processes would agree on what the maximum message size is,
> and process it.  And maybe even get the append command to limit
> the size of the message it is accepting.  I'm not sure
> what other commands take a literal.
>
> imapd.conf.5. says that "maxmessagesize" is the size of
> the largest message that lmtpd will process,  and that the default
> value is unlimited or INT_MAX.  We should be able to xfer/undump
> any message that lmtpd and cmd_append stuffs onto the disk.
>
> On Mon, 1 Aug 2005, Rob Siemborski wrote:
>> Note that if you actually use this code with maxmessagesize=0,  
>> then you'll
>> never detect that len is greater than maxliteral(), since, well,  
>> you can't
>> have something bigger than INT_MAX, and you'll reintroduce the  
>> overflow
>> that this limit is preventing.
>>
>> This is because further down you have:
>>
>>          if (len >= buf->alloc) {
>>              buf->alloc = len+1;
>>              buf->s = xrealloc(buf->s, buf->alloc+1);
>>          }
>>
>> Which, with some work, can be turned into an explitable heap overflow
>> (the major cause of the 2.1.10 release).
>>
>> It would be much safer to limit maxmessagesize to something notably
>> smaller than INT_MAX in general.