Adam,
I don't get it. This patch only affects RENAME commands, not DELETE
commands. Ah, now I get it. Your clients moves the box to Trash....
Still, I'm very relunctant to implement this in the 2.0 branch. It's not
a bug perse. Things have been like this forever, afaik. So it's not a
regression, and it's does not impact any normal use-case, just your
expectations from a sysadmin pov.
I suggest we move over to the devel list.
Adam Kosmin wrote:
> Hello Paul,
>
> I just wanted to share this tiny "patch" that I've tested on 2.0.8. You
> should know that I'm not a developer and really don't know if my small
> change is going to break anything. It does seem to do the trick though :)
>
>
> --- db.c 2006-02-06 13:39:50.000000000 -0500
> +++ db.c.org 2006-02-06 13:37:25.000000000 -0500
> @@ -3454,7 +3454,7 @@
> }
> snprintf(query, DEF_QUERYSIZE,
> "UPDATE dbmail_mailboxes SET name = '%s' "
> - "WHERE mailbox_idnr = '%llu' AND permission != 1",
> escaped_name, mailbox_idnr);
> + "WHERE mailbox_idnr = '%llu'", escaped_name,
> mailbox_idnr);
> dm_free(escaped_name);
>
> if (db_query(query) == -1) {
>
> Also, I did create a bug report of this issue over at
> http://www.dbmail.org/mantis/view.php?id=298
>
> Best,
>
> Adam
>
>
> Paul J Stevens wrote:
>
>> Don't count on it. The fact that level3 mailboxes respect the
>> permission flag
>> does not make sense at all. Like I said, that flag is not checked at
>> all at the
>> moment for delete actions. Could you please include trace_level 5 logs
>> for a
>> level3 mailbox delete and level4 mailbox delete?
>>
>> I havent touched that part of the code yet, other than during general
>> refactoring, so I could be missing something here.
>>
>>
>>
>> Adam Kosmin wrote:
>>
>>> Paul,
>>>
>>> Thank you for the response. I will submit a bug report today. Can you
>>> suggest any workarounds in the mean time? I tried getting around the
>>> issue by changing my mailbox structure like so:
>>>
>>> Problem:
>>> INBOX/Outgoing/2006/01
>>>
>>> Attempted Solution
>>> Outbox/2006/01
>>>
>>> I tried this approach since according to my testing, mailboxes 3 levels
>>> deep are not affected by this issue. However, I can't seem to work with
>>> the newly created 'Outbox' the way I'd expect. Perhaps I'm opening a can
>>> of worms with this workaround :)
>>>
>>> Best,
>>>
>>> Adam
>>>
>>> Paul J Stevens wrote:
>>>
>>>
>>>> Adam,
>>>>
>>>> The DELETE command handling in imap does not check the mailbox
>>>> permissions at all atm, other than determining whether the user issuing
>>>> the command is the owner.
>>>>
>>>> I'll look into this. Please file a bug report so I won't forget.
>>>>
>>>> Adam Kosmin wrote:
>>>>
>>>>
>>>>> Hello again,
>>>>>
>>>>> I haven't heard anything back about this so I thought I'd attempt to
>>>>> explain the problem one more time.
>>>>>
>>>>> I've noticed that I can delete mailboxes that have been marked as
>>>>> read-only (e.g. permissions=1 in dbmail.dbmail_mailboxes).
>>>>>
>>>>> This seems to only affect mailboxes 4 levels deep. For example,
>>>>> INBOX/foo/bar is fine but INBOX/foo/bar/foobar suffers from this
>>>>> problem.
>>>>>
>>>>> It's probably worth mentioning that I can not delete mail residing in
>>>>> that mailbox. However, If I select the mailbox itself and attempt to
>>>>> delete it, the mailbox and all of its messages are blown away.
>>>>>
>>>>> Does anyone have any insight on this?
>>>>
>>>>
>>>>
>>>>
>>
>>
>
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
