[Dovecot] Dovecot not handling r/o mailboxes completely, and problem with ACL as a workaround
mcdouga9 at egr.msu.edu
Fri May 11 06:28:04 EEST 2007
I have an update, I realize now that my ACL is working, however applying the
ACL still does nothing to improve the original problem that dovecot doesn't seem
to communicate permission failures to the client, which allows the client to
become out of sync with reality on the server.
I'm really not sure how dovecot might currently determine if a folder is
read only on disk, because there seems to be some handling for that case
in the code. Perhaps if I knew what part of the code (or an explanation)
of why it thinks a folder is not writable, I could use that to my advantage
and try to make folders look more "read only" on disk.
On Sun, May 06, 2007 at 09:34:28PM -0400, Adam McDougall wrote:
First of all, I think dovecot is really fantastic and I have thanks for all
the hard work. I think it will be the best fit for my ~5000 users when I
have it setup completely. We normally have approx 500 concurrent IMAP
connections during the day.
I am trying to convert from courier-imap to dovecot, but I have an issue with
public namespace folders that are not writable by certain users. Please let me
know if I need to provide more information or how I can help solve this issue.
I don't know how courier stores and checks mail directory
permissions, but it was aware when a user would not be able to delete or change
messages and would return a READ-ONLY imap error when an attempt to change a
message occurred (courier returns this in the IMAP response to update mail flags
to reflect that the client wants to move to delete a mail). I understand that
imap clients will usually only set status as read or deleted first and only try
to delete an email for real on expunge, but it seems dovecot does not try to
detect if a message is modifyable before it is too late for the user to find
out. What happens is a user appears to be able to mark messages read, move them
to another folder, or delete them (another way of moving to another folder eg.
Trash). The user is clueless that the changes will not occur, and only finds
out later when they reload the folder to find the messages back, or tries to
expunge and get an unhelpful 'internal error' from dovecot (I can help trace
this situation if it helps, but I think that stage should not be reached if
things were working right). My configuration has the public folder control and
indexes inside a user's home directory, so it will always be possible for
dovecot to record message status changes, however I do not think dovecot should
update the control and indexes to reflect an IMAP operation that is not allowed
to complete due to restricted permissions on the actual email file. I suppose
dovecot would have to check the permissions on mail message files.
<snip portion about ACLs>
# dovecot --version
The reason I have so many public spaces below, is to match the existing
directory structure we setup for courier, and also to help us keep the
directory listing more tidy since otherwise we would end up with many folders
all under one directory. Some of them have monthly rotation and it could get
out of hand if we did not split them up. I understand it makes things more
difficult for the global acl list at present, if I were to use it, but
I may not have any conflicting folder names at this time.
# dovecot -n
imap_client_workarounds: delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep
mechanisms: plain login
More information about the dovecot