Hell again Paul,
IMHO, it is a bug since read-only mailboxes should not be subject to
renaming or deletes. Unless of course, I've misunderstood the purpose of
the permission column in the dbmail_mailboxes table?
I'd be interested from hearing other people's points of view of the
previous statement so if you don't mind, I'd like to keep the thread here.
All the best,
Adam
Paul J Stevens wrote:
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?
--
Adam Kosmin
GNU/Linux SA
Visual Trading Systems, LLC
Empire State Building
350 Fifth Avenue, Suite 6420
New York, NY 10118, USA
Email [EMAIL PROTECTED]
Phone 1 (212) 871-1747 ext. 340
