What is the correct way to configure the mail_location option for Mailidr format?

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Oct 2014, deoren wrote:

> On 10/22/2014 2:29 AM, Steffen Kaiser wrote:
>> On Tue, 21 Oct 2014, deoren wrote:
>> 
>>> What is the correct way to configure the mail_location option for
>>> Mailidr format?
>> 
>> mail_location = maildir:<path>
>> 
>>> I've long had it setup this way:
>>>
>>>    mail_location = maildir:/var/vmail/%d/%n
>>> 
>>> Is that correct?
>> 
>> any path is OK, as long:
>> 
>> 1) it identifies the mail storage uniquely for the user,
>> 2) does not store any other information in it.
>> 
>>> Here is an example error message I ran into:
>>>
>>>    stat(/var/vmail/example.com/username/.dovecot.lda-dupes/tmp)
>>> failed: Not a directory
>> 
>> That's because you use $HOME == Maildir root.
>> 
>>> Looking at some other guides/tutorials shows something more like:
>>>
>>>    mail_location = maildir:/var/vmail/%d/%n/Maildir
>> 
>> "Maildir" is the default name for "Maildir"-type mail storeage root. No
>> more, no less. If Dovecot is automatically detecting the type of
>> storage, it probes for this directory name in $HOME.
>> 
>>> I assume the latter is how it's supposed to be done? If so, that would
>> 
>> No, you are not "supposed" to do so.
>> 
>>> I did review the official docs here:
>>>
>>>    http://wiki2.dovecot.org/MailLocation/Maildir
>>> 
>>> but I didn't find where it explicitly warns against setting home ==
>>> maildir root. It should probably be apparent, but it wasn't to me when
>>> I first
>> 
>> it applies to all mail storages.
> Thanks for the reply and for answering my questions.
>
> Just to make sure I understand properly, I have a few additional questions 
> that I am hoping will cement really drive the point home so to speak. 
> Regarding the guide that I followed, it suggests the following userdb and 
> mail_location configuration:
>
> userdb {
>  driver = static
>  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
> }
>
> mail_location = maildir:/var/mail/vhosts/%d/%n
>
> This results in the $HOME == Maildir root situation which you mentioned 
> shouldn't be done, correct? Instead mail_location should point to some other 
> directory,

Yes!

>            perhaps one of:
>
> * mail_location = /var/mail/vhosts/%d/%n/Maildir
> * mail_location =  ~/Maildir

for instance, yes.

> If I understand properly the mail_location doesn't have to be a subdirectory 
> within the home directory, it just typically is in common examples? If so,

Yes again. And "Maildir" is just common and the default, but you could 
name the last path component anyway you like, even "mbox", "sdbox", or
"mdbox", but such name probably would confuse any admin, that take the 
server over, because the dir name does imply something different than 
Maildir.

> that guide should probably be updated to use one of the above mail_location 
> settings. If you will confirm that is the case I'll submit a GitHub pull 
> request as previously mentioned so it can be corrected.
>
> Apologies if this is rehashing what you've already said, I'm just looking to 
> make sure I understand this 100%.
>
> So for cases where I have made the mistake like I mentioned above, how would 
> I (properly) fix the problem?
>
> After stopping Dovecot, I ended up doing this:
>
> #1) service dovecot stop
> #2) cd /var/vmail/example.com/username/
> #3) mkdir Maildir
> #4) mv -i * Maildir/
> #5) mv -i .* Maildir/
> #6) chown -R vmail:vmail /var/vmail/example.com/username/
> #7) service dovecot start


#5 will match "..", too.
Better: mv -i * .??* Maildir

That will move the Sieve and LDA files, too, as you found out yourself, 
so:

mkdir Maildir ; mv -i * .??* Maildir && for file in Maildir/.dovecot.*; do
  test -f "$file" && mv "$file" .
done; mv Maildir/sieve_dir .

The 1st "mv" moves all files into Maildir, the for loop is to move the 
sieve files back, and the 3rd mv moves the sieve folder back - you have to 
adjust your name there.

>
> which moved the content into the Maildir subfolder and fixed permissions back 
> to what is specified in the conf files. I also adjusted mail_location like 
> so:
>
> mail_location = maildir:~/Maildir
>
> and I made sure that the home setting is configured as /var/vmail/%d/%n
>
> That seems to work fine, but I still got error messages like this when using 
> doveadm search
>
> "Error: Syncing mailbox dovecot.lda-dupes failed: Internal error occurred."
>
> In my testing I found that I could move the file from this location:
>
>    /var/vmail/example.com/username/Maildir/.dovecot.ldap-dupes
>
> to this one:
>
>    /var/vmail/example.com/username/.dovecot.ldap-dupes
>
> choosing to overwrite the file if it should be there and the error message 
> would not be generated anymore. This suggests that I shouldn't have moved it 
> in the first place.
>
> Looking through the mailing list archives I found a message thread titled 
> "Lifetime of redirect info stored by Sieve in .dovecot.lda-dupes" which 
> indicates that the Message-ID and recipient of forwarded messages are stored 
> in .dovecot.ldap-dupes files. I do forward mail daily from the two accounts 
> where doveadm search generates the errors, so it sounds like I would probably 
> be OK to just nuke the file in this location:
>
>     /var/vmail/example.com/username/Maildir/.dovecot.ldap-dupes
>
> and let it be auto-generated in the proper location the next time mail is 
> forwarded. Can you confirm whether that is the case?

.dovecot.lda-dupes is not essential, but you might get (seldomly) some 
dupes or some users might get duplicate vacation responses from Sieve.

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBVEi+3Xz1H7kL/d9rAQL4+ggAmElvOUFvfcYJOjxByQBA6JDYrSU7uk/1
C21L6QyOl+gS8HGXKQBAEKNywe5/a8QyWYa9z46n/mVGxwU/BgEntqiawyrsYT1q
/Rjz+9AjNVYNhmRlegb/dXemMinN0+GHRINYWJSz7Uu9CRvGrstQLD7zMl3BA2+A
faLDoCnDKc2gDr+qLcgrfCjSDgl2btMho5ApBc4ecFpBnEMIIGA/n7M7xGBaDJqT
65GLUoXAoW5DmriW/w4g3wCaUyAdvYO8+EfYSx5mwIxYSxhzDBb0kbRLEHGdRDOR
q4xEZMMDc42PW1xHSCKuzNkZeQf6G1mRFzVL+no3pvSev6gmLWCl9g==
=TvfG
-----END PGP SIGNATURE-----