DELAYED DELETE and very long mailboxes => segfault

[Brian Awood]

We have had users that weren't able to delete a mailbox that was close 
to, or already at, the max name length.  Cyrus generates the new name 
with the DELETED prefix and time stamp suffix, which ends up being 
longer than the allowed max and the rename then fails.

No idea where 490 came from, but it seems like most imap clients don't 
even correctly display a mailbox name that long.  Also, the mailboxes 
we've seen like this look like they occurred by accident, whether 
because of user error or software bug, the user then can't delete the 
mailbox themselves.  

Brian

On Friday 06 February 2009 @ 08:41, Bron Gondwana wrote:
> This is a fun one... the delayed delete path has a buffer of
> MAX_MAILBOX_PATH rather than MAX_MAILBOX_NAME size.  Meaning
> it can be longer than a basic mailbox.
>
> Which is actually fine by me.  Does anyone know why the limit
> of 490 was chosen?  I can't see anything obvious with a quick
> google.
>
> Unfortunately, this crashes idle sending, which uses a straight
> strcpy of the passed mailbox name onto a MAX_MAILBOX_NAME
> sized buffer.
>
> Anyway, I've worked up a patch (on github, of course) which
> creates a 1024 character size MAX_MAILBOX_BUFFER, and uses
> that everywhere that a buffer is created.
>
> Plus this little one, which I will apply to CVS immediately,
> since it's a clear bugfix.
>
> Bron.