[Dovecot] 2.0.12 (fa2e92526716): Deleting mails and folders from public namespaces

[Binarus]

On 26.05.2011 08:38, Willie Gillespie wrote:
> On 5/25/2011 5:12 AM, Binarus wrote:
>> It seems that the problems come from the fact that deletion is done by
>> renaming. I am not in IMAP but suppose that there is some rename command
>> which is used by email clients in such cases. Maybe there is also a
>> delete command which dovecot is "emulating" by doing a rename - I really
>> don't know...
> 
> Just a little correction here:  Deletion is NOT done by renaming.
> Deletion of folders is done with a DELETE command which gets rid of it
> entirely.  What your mail clients are doing is renaming the folder,
> which is done with a RENAME command.
> 
> For example, if "SomeFolder" is deleted then your mail client is doing:
> RENAME "SomeFolder" "Trash.SomeFolder"
> which effectively just moves the folder as a subfolder of Trash.
> 

I suspected something like that, and you can see it from the fact that
some IMAP clients indeed are able to do the moving (obviously by
internally emulating it by the copy-move-delete method).

That was the reason why I was proposing the server-side copy-move-delete
implementation for such cases. I think it is the correct behaviour for
clients to use renaming instead of more inefficient operations, but I
also think that the server should try to obey the user and should
emulate renaming by the copy-move-delete method if a "pure" renaming is
not possible for some reason.

Obviously, Dovecot incorporates code for creating new folders in any
namespace, for moving messages regardless of namespaces and for deleting
(empty?) folders in any namespace (we can do all these actions manually
provided the ACLs allow). Therefore, emulating renaming by
copy-move-delete in problematic cases might be possible without pain.

I know that it is not a completely "clean" solution; on the other hand,
it would be reasonable and immediately understandable by users. The
purists among us might be happy if there was a configuration directive
to enable or disable such behaviour.

What do you think about that?

> 
> Timo, you said
>> Talking only about ACLs I guess it would be ok to allow renaming from
>> public namespace to a private namespace. Renaming one of your own
>> private mailboxes to public namespace is a bit trickier, because the
>> default ACL is "no permissions". So when renaming, a new explicit ACL
>> should be added to the user who did the renaming, because otherwise
>> user could no longer access that mailbox at all. Still doable I guess.
> 
> I don't think any ACL should be added automatically in this case.  If
> they set their trash folder to be in a public/shared namespace for which
> they have only CREATE permissions, then I think that's their fault and
> the admins problem... not Dovecot's.
> 

I agree with Willie. Once again, look at the analogy: what does a user
expect to happen when he tries to move a folder from his private space
to public space? He expects

- a new folder (with subfolder structure) to be created in public, every
folder having the same name as it's counterpart in private
- all messages to be moved from the folder structure in private to the
folder structure in public
- the folder structure in private to be deleted

These steps could be done by hand, and thus, the behaviour, ACL handling
and error messages should exactly be the same as when doing the steps by
hand. For example, when a user creates a folder in public by hand, he
eventually will not be able to access that folder, depending of the ACLs
of the parent folder. This is normal and expected, so there is no reason
to handle it in special way when moving (renaming?) folders.

By the way, if I got it right, the same problem might appear if the user
was copying folders within the same public namespace. What if a user
copies a folder (in public) to another parent folder (also in public)
where the user only has create rights? I don't know for sure, but I
think the ACL won't be copied in this case, so the user might not have
access to the new folder. But I may be wrong here, and I am unsure what
would happen if the folder would be moved instead of copied; I think if
moving is done by renaming, the ACL would be moved as well, so there
should not be any problem.

We also could look at it the other way: Logically, from my (naive) point
of view, any folder in a user's private namespace is connected with a
standard ACL; however, this ACL can't be altered by users (or the
admin), has only one entry (respective user has full access) and is
created / kept automatically by the server. In this model, renaming from
private to public would be the same as renaming from public to public
and thus would solve the problems.

I don't know how difficult it would be to make Dovecot look at things
that way. Maybe my point of view is completely wrong, but then I hope
somebody will tell me about it...

Personally, I could live very well with both solutions (emulating moving
by copy-move-delete in problematic cases or handling private namespace
just as public namespace with special ACLs that can't be altered). I
don't know which is easier, more logic, and if any of them completely
respects RFCs.

But I know for sure that being unable to move folders between any
namespaces is a big problem for users and even a bigger one for admins
(guess what a user does if he can't move this one, super-important
folder with hundreds of subfolders - this usually ends with the admin
trying to move the whole thing on file-system level, of course during
work time where Dovecot can't be shut down, or the admin desperately
trying to find and configure an IMAP client which emulates moving
internally by copy-move-delete).

Regards,

Peter