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