[Dovecot] Disallow folder delete
Is there a straightforward way to disallow the deletion of all IMAP mailboxes?
I have a user who's deleted an important IMAP mailbox and I'm now recovering a recent copy from the backup. But I'd rather just blanket disallow all folder deletions.
The user is using Thunderbird and this has happened more than once so I suspect Tbird is willing to let a folder get deleted too easily. Perhaps there was a delay in the confirmation dialog and the user clicked ahead and confirmed something he shouldn't have.
I'm looking at <http://wiki.dovecot.org/ACL> and it looks like I should be able to use a group override to disallow "x" (mailbox delete) but the page says that groups aren't implemented, so I don't know how one says that nobody can do this for any mailbox.
I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).
On Monday, May 19, 2008 4:07 PM -0700 Kenneth Porter <shiva@sewingwitch.com> wrote:
I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).
I think I'm misinterpreting the CentOS package's version number. The package is listed as:
dovecot-1.0-1.2.rc15.el5.src.rpm
I think that means 1.0 rc15 and RPM packaging version 1.2.
From the package changelog:
- Fri Dec 22 2006 Tomas Janousek <tjanouse@redhat.com> - 1.0-1.2.rc15
- reenabled GSSAPI (#220582)
- Tue Nov 21 2006 Petr Rockai <prockai@redhat.com> - 1.0-1.rc15
- update to latest upstream, fixes a few bugs, plus a security vulnerability (#216510, CVE-2006-5973)
On May 20, 2008, at 2:07 AM, Kenneth Porter wrote:
Using global ACLs gets you closer at least. You can define:
acl = vfile:/etc/dovecot/acls
Then having /etc/dovecot/acls/.DEFAULT probably does something.. But I
don't remember if it applies to all mailboxes or just those on the
root level or what. I should look into this some day and make all of
them possible. :)
It might be nice to have a mode that disallows deletion of *non-empty* folders. In order for a user to delete the folder, the folder must first be emptied and purged.
Alas, deleting messages can be undone, but folders can't be, and the UI of a client doesn't necessarily make this obvious.
On 5/20/2008 9:53 PM, Kenneth Porter wrote:
Actually, a properly configured client will simply move the folder to the Trash - where the user can recover it if it was a mistake, unless/until the trash is empty.
I always configure TBird to only delete messages from the Trash that are older than 30 days. This has saved more than one of our Reps on more than one occasion.
But again - there is only so much that you can do to protect people from themselves.
--
Best regards,
Charles
On Wednesday, May 21, 2008 7:00 AM -0400 Charles Marcus <CMarcus@Media-Brokers.com> wrote:
This depends on the storage type. mbox can't hold a folder in a folder, so where do you put a deleted folder if Trash is an mbox?
I looked at the 1.0.13 source and found that deleting a non-empty mbox folder-to-hold-folders will fail (see mbox_mailbox_delete() in mbox-storage.c), but a non-empty folder-to-hold-messages will succeed.
I think adding this to cmd-delete.c after the client workaround part should prevent this. The message is taken from mbox_mailbox_delete but without the folder name.
struct mailbox_status status; if (mailbox_get_status(mailbox, 0, &status) < 0) { return FALSE; } if (status.messages > 0) { client_send_tagline(cmd, "NO Folder isn't empty, can't delete it."); return TRUE; }
On Tue, 2008-05-20 at 18:53 -0700, Kenneth Porter wrote:
Yes, this sounds like a possibly good idea. Only problem is that it should probably be per-user configurable but there's really no per-user configuration currently.. METADATA extension will probably help there in future.
On 5/19/2008 Kenneth Porter wrote:
Thats pretty drastic - I'd have a rebellion on my hands if I tried that here.
There's only so much you can do to protect people from their own stupidity. I'd say this is one thing you do NOT want to do - otherwise, you're gonna have people bugging you all the time to delete folders for them.
I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).
Actually, that would be 1.0rc15 - and it is way old, time to upgrade... atrpms.net has current versions...
On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus <CMarcus@Media-Brokers.com> wrote:
Thats pretty drastic - I'd have a rebellion on my hands if I tried that here.
The userbase is small, and I'd even be willing to set this up for one user were that to happen. Most users aren't that sophisticated and aren't creating folders in the first place. (Their inboxes tend to be horribly huge because of it.)
How hard is the upgrade? Just install the new RPM, or is there any configuration to update? (I'm currently using a pretty stock installation that uses mbox in /var/spool/mail (for inbox) and /home/user/mail.
I did see 1.0.13 in Rawhide, so I figure I'd just grab the SRPM and build/package against the RHEL libraries.
On Tuesday, May 20, 2008 8:39 AM -0700 Scott Silva <ssilva@sgvwater.com> wrote:
I usually make users wait a while before restoring their mistakes. A few hours of thinking about it might make them think about it
Assuming it was a mistake. How long do you then wait in turn before he gives you your paycheck? ;)
on 5-20-2008 6:50 PM Kenneth Porter spake the following:
You know that the people that sign your paychecks are under an "entirety different" set of rules. They usually also get;
- Higher mail limits.
- Exemptions from the filters on the web proxy.
- Immediate service.
- Any other butt kissing you think necessary to keep them happy.
Sometimes it can legitimately take a while, especially for older archived stuff.
Once a VP couldn't understand why his search for a "titanium driver for his golf clubs triggered the content filters. At least not until I showed him the part of "TIT"anium that triggered it. Then he was totally on board, and usually just e-mailed me on any sites that gave him trouble. My bosses usually embrace technology, they just don't have a lot of experience with it. They are all lawyers and accountants, except for the VP of engineering and operations, who of course is an engineer.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
participants (7)
-
Charles Marcus
-
Daniel L. Miller
-
Jacek Osiecki
-
Kenneth Porter
-
mouss
-
Scott Silva
-
Timo Sirainen