woro

I found the workaround for me with the configuration option which is not optimal. What I understood from Dovecot developers is that this is just one example where it causes issues. To cite the statement I got: "this is why you should never use maildir:~/ maildir++ treats all .files as potential maildir directories. or to be more verbose, mail_home should not equal mail_location" I would assume to change this would basically break compatibility and therefore is a problem to do. I just wanted to have it written somewhere together with the workaround so others could potentially find it and decide how they want to modify their setup.

Yes, you are right. That part is expected. But as explained in the maildir++ format Dovecot interprets everything starting with a dot to be a folder leading to that error. The maildir_stat_dirs apparently makes sure that Dovecot is actually checking first if it's a directory at all. I have sieve = file:~/sieve;active=~/.dovecot.sieve as proposed. ~ is the Dovecot homedir

Hi, I'm using Froxlor with Dovecot under the hood. I observed regular error messages in the Dovecot logs ages ago but w/o seeing any misbehavior. But finally decided to look deeper into it and also reached out to the Dovecot community. The error looks like this: imap(USERNAME)<6637><fB95wfXo7tFbEJQa>: Error: stat(/srv/customers/mail/$CUSTOMER/$DOMAIN/$USER/Maildir/.dovecot.sieve/tmp) failed: Not a directory That message is because Dovecot thinks that .dovecot.sieve is a mailbox/folder (as maildir++ format is used). I've been told by the Dovecot community that it is a very bad idea and not at all recommended to use the same directory as home AND mail_location but apparently that is currently the default for Froxlor? I think my settings are pretty default: homedir: /srv/customers/mail maildirname: Maildir So in the mail_users table there is always /srv/customers/mail/ in homedir and $CUSTOMER/$DOMAIN/$USER/Maildir/ in maildir. The userdb lookup in Dovecot as documented by Froxlor is: user_query = SELECT CONCAT(homedir, maildir) AS home, CONCAT('maildir:', homedir, maildir) AS mail, uid, gid, CONCAT('*:storage=', quota, 'M') as quota_rule FROM mail_users WHERE (username = '%u' OR email = '%u') So this returns the same directory for home and mail indeed. Apparently there is a workaround to avoid that error but is also in general performance degrading which is to set maildir_stat_dirs = yes So overall this leaves some questions: Is that a known issue or does it qualify to handle it as a bugreport (or improvement request) to use different home and mail dirs for Dovecot? Should the maildir_stat_dirs = yes workaround be reflected in the configuration documentation? Or is there anything wrong in my own Froxlor setup? Thanks Wolfgang

Hi, I'm wondering what the idea is behind the functionality to move domains to another customer. I found it needs to be enabled in the settings and there is also some sort of warning. I tried that now for testing purposes and the process is not clear to me. I moved the domain and within froxlor everything looks quite OK. The data on disk has not been moved (as mentioned in the comment). So far so good. But next I wanted to get rid of the original customer and removed it from the panel. I also have chosen (with the possible risk in mind) to remove the customer data. Now really the testmailbox was completely wiped from disk although it belonged to another customer now. So is there anything else which could be done to sanitize such a move or is this really how it's supposed to behave? Given that it's not visible in the panel that there still is a mailbox in the data set one might just forget that such a thing exists and remove a customer which wipes production data in that case. Thanks, Wolfgang