IMAP server can't read (open) mails using fetchmail, procmail & dovecot

Question

I'm trying to setup a mail server ! Everything seems to be ok (after some loooong days) but when I tried to read mail with IMAP server :

Apr 18 17:38:48 sd-84941 dovecot: imap(dlp): Error: open(/data/maildir/dlp/cur/1460993401.13028_0.sd-84941:2,) failed: Permission denied (euid=1000(michael) egid=1000(michael) missing +r perm: /data/maildir/dlp/cur/1460993401.13028_0.sd-84941:2,, we're not in group 8(mail), dir owned by 0:8 mode=0777)

Mails are in the maildir folder but I can't read them because of permissions...

-rw-rw---- 1 root root 2363 Apr 18 17:55 1460994924.16416_0.sd-84941

But if chmod 777 It work (but I can't do this by hand everytimes..) :

-rwxrwxrwx 1 root root 2363 Apr 18 17:55 1460994924.16416_0.sd-84941:2,

What's happen ? Who give file permission ? fetchmail, procmail or dovecot ?

----- Edit ------

Thanks for your answers, @tripleee. I 'll try to give details :

I've installed sendmail, procmail, fetchmail, dovecot & roundcube :

• Sendmail & Roundcube : default install.

• Procmail :

In /etc/procmailrc (I prefer a global conf vs the user way), we have :

MAILDIR=/data/mails/ DEFAULT=$MAILDIR/ LOGFILE=/var/log/procmail VERBOSE=on 

• Fetchmail

In /etc/fetchmailrc :

set syslog set daemon 120 poll mail.interpc.fr with nodns, with protocol POP3, user "dlp", with password mypass option keep 

• dovecot

I've created a vmail user :

sudo addgroup --gid 5000 vmail sudo adduser --home /data/mails/ --uid 5000 --gid 5000 --shell /bin/false vmail 

In /etc/dovecot/users (with vmail's uid & gid) :

dlp:{PLAIN}mypass:5000:5000:: 

In /etc/dovecot/conf.d/10-auth.conf, I've changed to :

disable_plaintext_auth = no #!include auth-system.conf.ext !include auth-passwdfile.conf.ext 

In /etc/dovecot/conf.d/10-mail.conf : mail_location = maildir:/data/mails/

• Problem description : mails are copied to my mail folder but with root permissions so Roundcube can't open mails

 root@sd-84941:/home/michael# ls -al /data/mails/cur/ total 48 drwxr--r-- 2 vmail vmail 4096 Apr 21 15:08 . drwxr--r-- 5 vmail vmail 4096 Apr 21 15:08 .. -rwxr--r-- 1 root root 29635 Apr 21 13:31 1461238276.4519_0.sd-84941:2, -rwxr--r-- 1 root root 3740 Apr 21 13:45 1461239150.5706_0.sd-84941:2, -rw-r--r-- 1 root root 2953 Apr 21 15:04 1461243887.17704_0.sd-84941:2, 

Thanks for helping me...

Answer 1

Your combination of software is a bit unusual these days (i.e. pretty standard 10-20 years ago). I'm guessing what you are doing is using fetchmail to connect to a POP server, and then it passes the mail to procmail to deliver the mail into local directories. This approach has become unusual in part because there's not many servers now that support POP only, and IMAP allows better options for moving mail between servers after delivery. If there's an option to use IMAP on the upstream server, then take a look at imapfilter. It's also unusual these days to want to run a mail server that can't accept direct delivery, which would allow you to just set up a mail forwarding rule on the upstream server.

You are presumably running into problems because you are using procmail to deliver directly into local directories, and doing so with the procmail process running as root, which is not what dovecot runs as, so dovecot can't read the files.

You could figure out how to run procmail as the correct user, or (if run as root) how to tell it to store files with the correct ownership. You might get a degree of compatibility, but for instance dovecot won't get to index the emails properly as they arrive, so search will be impaired.

I suggest that you use dovecot's deliver as a local delivery agent. It might replace procmail, or it might be called by procmail 1,2 . In either case you'll need to call it with appropriate an argument (-d), identifying the user you are delivering to. If you are using procmail to make decisions about which mail folder to deliver to, you might want to use the -p argument for that, or you might be better off using dovecot's sieve filtering engine to make those decisions. procmail is really at its best when dealing with system users rather than virtual users.

Sieve is a better designed solution than procmail for virtual users, though it's an open question which has a less pleasant filter syntax. I had many years of good service from procmail, and I currently use a bit of sieve because it acts before delivery, but for transferring mail between servers after delivery, and where circumstances allow, I'd much prefer writing filters with imapfilter.