DELAYED DELETE and very long mailboxes => segfault
bawood at umich.edu
Fri Feb 6 12:27:48 EST 2009
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
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
> 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.
More information about the Cyrus-devel