Patches not taken up by upstream

[Bron Gondwana]

On Wed, Jun 16, 2010 at 11:49:22AM -0500, Patrick Goetz wrote:
> On 06/15/2010 06:36 PM, Bron Gondwana wrote:
> >>
> >>~/imap/imapparse.c
> >>line 53:
> >>-    MAXLITERAL = INT_MAX / 20
> >>+    MAXLITERAL = INT_MAX / 10
> >
> >Hmm - and still untouched in my latest codebase too.  We've got a
> >configurable maximum line length now.
> >
> >That's basically what - 100M, changed up to 200M?  Or am I out by an order
> >of magnitude or so?  Maximum size for a single email.
> >
> >I'd be happy to apply it (and also to replication...) - I don't see the
> >danger with either option, but it will block super-large emails.
> >
> 
> Wouldn't the len*10 here:
>        len = len*10 + c - '0';
>             if (len > MAXLITERAL || len < 0) {
>
> imply that it's actually changing a 10.7MB max size to 21.4MB?

No.  That's a skanky integer parser.  "len" is the integer value of
the number that's been read so far, the *10 was the previously read
character.  I guess that to avoid overflow, you need to limit what
you can read here... hmm.  I think that function could do with a
rewrite actually.
 
> In any case, since most people use email as a defacto file sharing
> system, this should be a run-time option, if possible.  On my
> postfix server at work we had message_size_limit set to 50MB (or
> something like this) and my own spouse got burned by this when some
> consultant tried to email her a large attachment containing some
> work-related videos.  I got the "so and so says he's trying to send
> me some files and the message keeps bouncing" call, which is how I
> discovered the message_size_limit setting in main.cf in the first
> place.
> 
> So, eventually MAXLITERAL should also be configurable, if possible,
> but for now we can probably let the debian *2 size limit patch
> stand?

I've attached the patch I just put into future branch.  It makes it
configurable.  But the more I think about it, the more I think the
whole concept is actually broken.  I'm probably going to just remove
the limit and change how we read the number!

Bron.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maxliteral.patch
Type: text/x-diff
Size: 3164 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20100617/e491a54f/attachment-0001.bin