[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:
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.
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:
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.
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:
On 5/20/2008 9:53 PM, Kenneth Porter wrote:
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.
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.
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:
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.
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.
Timo Sirainen wrote:
On May 20, 2008, at 2:07 AM, Kenneth Porter wrote:
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.
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. :) This actually may have a real benefit to some specialty folders - such as junk/nojunk folders that are looked for by a scanning re-classifier.
Can you give an example of how to make...Inbox/Junk non-deletable (or even better, update the wiki)?
-- Daniel
On Friday, May 23, 2008 10:38 AM -0700 "Daniel L. Miller" dmiller@amfes.com wrote:
This actually may have a real benefit to some specialty folders - such as junk/nojunk folders that are looked for by a scanning re-classifier. Can you give an example of how to make...Inbox/Junk non-deletable (or even better, update the wiki)?
INBOX is special-cased in cmd-delete.c.
I don't yet see where plugins get invoked so I haven't yet found where the ACL plugin can veto the delete command.
On 5/19/2008 Kenneth Porter wrote:
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.
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.)
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...
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.
Kenneth Porter wrote:
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.)
a probably better approach is to backup the mailstore and let users do what they want in their mailer.
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...
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 Tue, 20 May 2008, mouss wrote:
On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus
Thats pretty drastic - I'd have a rebellion on my hands if I tried that 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 a probably better approach is to backup the mailstore and let users do what
Kenneth Porter wrote: they want in their mailer.
Look how the thread began - it's not about losing folders, it's about lusers deleting their folders and admin losing time on recovering folders from backups :)
Greetings,
Jacek Osiecki joshua@ceti.pl
On Tue, 20 May 2008, mouss wrote:
Kenneth Porter wrote:
On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus > Thats pretty drastic - I'd have a rebellion on my hands if I tried that 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 a probably better approach is to backup the mailstore and let users do what they want in their mailer.
Look how the thread began - it's not about losing folders, it's about lusers deleting their folders and admin losing time on recovering folders from backups :)
Greetings, You can only do so much to protect people from their own stupidity. I usually make users wait a while before restoring their mistakes. A few hours of
on 5-20-2008 6:43 AM Jacek Osiecki spake the following: thinking about it might make them think about it. But then I can be a BOFH sometimes! ;-P
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
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:
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? ;)
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!!!!
on 5-19-2008 4:07 PM Kenneth Porter spake the following:
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.
You mean thunderbird LET a user do something stupid? Even after asking" Are you sure"?
Go figure!
-- 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