[Dovecot] Shared Mailboxes (symlink) and kmail: known issues?
Hi,
are there any known issues with symlinked-shared-mailboxes and kmail?
I use virtual users (LDAP), so there are no unix-permissions related problems here: all mailboxes are owned by the local user vmail.
Each user maildir has some symlinks to shared mailboxes. This works fine if I use squirrelmail as a MUA.
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
-- Wilhelm
On Mon, 2009-01-19 at 18:32 +0100, Wilhelm Meier wrote:
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
My guess is that kmail assumes it's the only client accessing the mailbox and doesn't bother handling IMAP notifications about expunged messages.
Hi,
Am Montag 19 Januar 2009 schrieb Timo Sirainen:
On Mon, 2009-01-19 at 18:32 +0100, Wilhelm Meier wrote:
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
My guess is that kmail assumes it's the only client accessing the mailbox and doesn't bother handling IMAP notifications about expunged messages.
If I delete the mail via kmail, the mail gets the "T" flag, but the mail-file remains there and the other kmail shows the mail (strange?). If I afterwards open the mailfolder via e.g. squirrelmail, the mail-file gets deleted, and it vanishes from the kmail list, if I refresh the view in kmail.
The difference is, that squirrelmail does a login/logout every time it looks for mails. kmail stays logged in.
Is this a bug in kmail not to expunge the mail-file? If I manually remove the mail-file, kmail is fine!
-- Wilhelm
Am Dienstag 20 Januar 2009 schrieb Wilhelm Meier:
Hi,
Am Montag 19 Januar 2009 schrieb Timo Sirainen:
On Mon, 2009-01-19 at 18:32 +0100, Wilhelm Meier wrote:
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
My guess is that kmail assumes it's the only client accessing the mailbox and doesn't bother handling IMAP notifications about expunged messages.
If I delete the mail via kmail, the mail gets the "T" flag, but the mail-file remains there and the other kmail shows the mail (strange?). If I afterwards open the mailfolder via e.g. squirrelmail, the mail-file gets deleted, and it vanishes from the kmail list, if I refresh the view in kmail.
The difference is, that squirrelmail does a login/logout every time it looks for mails. kmail stays logged in.
Is this a bug in kmail not to expunge the mail-file? If I manually remove the mail-file, kmail is fine!
A "strange" workaround comes into mind, since our shared mail-folders are usually small in message-numbers:
setup inotify to delete all "T"-flagged files.
Would this be ok with dovecot?
Or can I trigger dovecot (sending a signal or so) to do this?
-- Wilhelm
On Tue, 2009-01-20 at 07:21 +0100, Wilhelm Meier wrote:
Hi,
Am Montag 19 Januar 2009 schrieb Timo Sirainen:
On Mon, 2009-01-19 at 18:32 +0100, Wilhelm Meier wrote:
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
My guess is that kmail assumes it's the only client accessing the mailbox and doesn't bother handling IMAP notifications about expunged messages.
If I delete the mail via kmail, the mail gets the "T" flag, but the mail-file remains there and the other kmail shows the mail (strange?). If I afterwards open the mailfolder via e.g. squirrelmail, the mail-file gets deleted, and it vanishes from the kmail list, if I refresh the view in kmail.
OK, so what you're saying is that you're only marking messages with \Deleted flag, you're not really expunging them from disk. And kmail ignores flag changes done by other clients (or does it see if another client changes e.g. \Seen flag?) kmail notices the EXPUNGEs anyway.
So what the kmail users would need to do is to trigger the EXPUNGE using kmail somehow, there's probably a "expunge", "compact" or something like that somewhere.
The difference is, that squirrelmail does a login/logout every time it looks for mails. kmail stays logged in.
What squirrelmail probably does is a real EXPUNGE instead of only marking the messages as \Deleted.
Am Dienstag 20 Januar 2009 schrieb Timo Sirainen:
On Tue, 2009-01-20 at 07:21 +0100, Wilhelm Meier wrote:
Hi,
Am Montag 19 Januar 2009 schrieb Timo Sirainen:
On Mon, 2009-01-19 at 18:32 +0100, Wilhelm Meier wrote:
kmail instead seems to have some problems: if I save a mail into the shared-folder, the other users are seeing this new mail almost immediately. But if I delete(!) a mail from the shared-folder, the list of the other kmails remains untouch. Refreshing does nothing. I have to close kmail and restart.
Is this related to some sort of wrong config of the shared mailboxes or is this a (known) dovecot <-> kmail problem?
My guess is that kmail assumes it's the only client accessing the mailbox and doesn't bother handling IMAP notifications about expunged messages.
If I delete the mail via kmail, the mail gets the "T" flag, but the mail-file remains there and the other kmail shows the mail (strange?). If I afterwards open the mailfolder via e.g. squirrelmail, the mail-file gets deleted, and it vanishes from the kmail list, if I refresh the view in kmail.
OK, so what you're saying is that you're only marking messages with \Deleted flag, you're not really expunging them from disk. And kmail ignores flag changes done by other clients (or does it see if another client changes e.g. \Seen flag?) kmail notices the EXPUNGEs anyway.
So what the kmail users would need to do is to trigger the EXPUNGE using kmail somehow, there's probably a "expunge", "compact" or something like that somewhere.
Thanks for this hint: the problem is partly solved: kmail has a flag "auto-expunge". I set this to true and then kmail asynchronously does the expunge. It seems that selecting INBOX in kmail triggers this event. Refreshing the folder or retrieving new messages doesn't!
Other question: is it save with respect to dovecot to remove the "T"-flagged messages in the maildir, e.g. per inotify? Yes, this is a hack, I know.
The difference is, that squirrelmail does a login/logout every time it looks for mails. kmail stays logged in.
What squirrelmail probably does is a real EXPUNGE instead of only marking the messages as \Deleted.
-- Wilhelm
On Tue, 2009-01-20 at 19:07 +0100, Wilhelm Meier wrote:
Other question: is it save with respect to dovecot to remove the "T"-flagged messages in the maildir, e.g. per inotify? Yes, this is a hack, I know.
Yes, it's safe. Although if you're using quota it's not updated then.
participants (2)
-
Timo Sirainen
-
Wilhelm Meier