Re: Deleting top-level mailbox with 'delete_mode: delayed'

From: Bron Gondwana (no email)
Date: Mon Nov 05 2007 - 05:15:06 EST

  • Next message: Bron Gondwana: "Re: Cyrus IMAPd 2.3.10 Released"

    On Fri, Nov 02, 2007 at 01:15:37PM -0400, Brian Wong wrote:
    > On Nov 2, 2007 12:39 PM, Rudy Gevaert <> wrote:
    > >
    > > Brian Wong wrote:
    > > > I was testing out Cyrus 2.3.10 and realized that when I set the option
    > > >
    > > > delete_mode: delayed
    > > >
    > > > I can not delete top-level mailboxes.
    > > >
    > > > localhost.localdomain> lm
    > > > localhost.localdomain> cm user.bwong
    > > > localhost.localdomain> sam user.bwong <admin_account> c
    > > > localhost.localdomain> dm user.bwong
    > > > deletemailbox: Operation is not supported on mailbox
    > > > localhost.localdomain> lm
    > > > user.bwong (\HasNoChildren)
    > > >
    > > > Disabling the delayed delete gives expected results. The mailbox is
    > > > deleted as normal. Anyone else confirm this?
    > >
    > > I'm just back from holiday (and only catching up on mail). I always set
    > > the 'x' permission. Could you try that? If that doesn't work, I'll try
    > > to delete a top level mailbox on Monday (I'm running 2.3.10 in test).
    > >
    > > Rudy
    > >
    >
    > localhost.localdomain> lam user.bwong
    > bwong lrswipkxtecda
    > admin kxc
    > localhost.localdomain> dm user.bwong
    > deletemailbox: Operation is not supported on mailbox
    >
    > I think if I did not have the right to delete the mailbox, I would get
    > a "Permission Denied" instead of the error I am receiving. Let me know
    > what you find when you try it. I feel that if this is really a bug it
    > would have been caught before release, but then again I can't think of
    > anything atypical with my setup that would cause this problem.

    It's almost certainly caused by the code that checks if you're renaming
    a "top level mailbox" for a user and special cases it in all sorts of
    ways. I never liked that code much!

    My solution was to make DELETED.user.bwong.46A12345 (or similar) also
    be considered to be an "INBOX" so it was treated as a user rename.
    This seems not to be working in your environment, and I'm really not
    sure why.

    I don't see anything specially different in our config.
    fast_rename: yes, but that won't work for you anyway because it's
    using a not-yet-perfect patch at our end.

    All our mailbox deletes are done as the admin user. It won't work
    if you're not a bona-fide admin (not just a user called admin who
    happens to have an ACL). Check the 'admins:' parameter in your
    imapd.conf.

    Regards,
     
    Bron.

    (P.S. your username is scarily similar to mine!)

    ----
    Cyrus Home Page: http://cyrusimap.web.cmu.edu/
    Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
    List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
    

  • Next message: Bron Gondwana: "Re: Cyrus IMAPd 2.3.10 Released"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD