Disallow folder delete

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Disallow folder delete

Kenneth Porter
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).
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
On Monday, May 19, 2008 4:07 PM -0700 Kenneth Porter
<[hidden email]> 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 <[hidden email]> - 1.0-1.2.rc15
- reenabled GSSAPI (#220582)

* Tue Nov 21 2006 Petr Rockai <[hidden email]> - 1.0-1.rc15
- update to latest upstream, fixes a few bugs, plus a security
  vulnerability (#216510, CVE-2006-5973)

Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Timo Sirainen
In reply to this post by Kenneth Porter
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. :)


PGP.sig (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Charles Marcus
In reply to this post by Kenneth Porter
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...
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

mouss-2
Kenneth Porter wrote:

> On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus
> <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Jacek Osiecki
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,
--
Jacek Osiecki
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Scott Silva
In reply to this post by Kenneth Porter
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!!!!


signature.asc (266 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Scott Silva
In reply to this post by Jacek Osiecki
on 5-20-2008 6:43 AM Jacek Osiecki spake the following:

> 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
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!!!!


signature.asc (266 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
On Tuesday, May 20, 2008 8:39 AM -0700 Scott Silva <[hidden email]>
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? ;)


Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
In reply to this post by Timo Sirainen
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.
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Charles Marcus
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
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Scott Silva
In reply to this post by Kenneth Porter
on 5-20-2008 6:50 PM Kenneth Porter spake the following:

> On Tuesday, May 20, 2008 8:39 AM -0700 Scott Silva <[hidden email]>
> 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;
1) Higher mail limits.
2) Exemptions from the filters on the web proxy.
3) Immediate service.
4) 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!!!!


signature.asc (266 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
In reply to this post by Charles Marcus
On Wednesday, May 21, 2008 7:00 AM -0400 Charles Marcus
<[hidden email]> 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;
}


Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Daniel Miller
In reply to this post by Timo Sirainen
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
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Kenneth Porter
On Friday, May 23, 2008 10:38 AM -0700 "Daniel L. Miller"
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Disallow folder delete

Timo Sirainen
In reply to this post by Kenneth Porter
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.


signature.asc (196 bytes) Download Attachment