O servidor IMAP não pode ler (abrir) e-mails usando fetchmail, procmail e dovecot

Question

Estou tentando configurar um servidor de e-mail! Tudo parece estar ok (depois de alguns dias loooong), mas quando eu tentei ler e-mail com o servidor IMAP:

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)

Os e-mails estão na pasta maildir, mas não consigo lê-los devido a permissões ...

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

Mas se chmod 777 Funciona (mas eu não posso fazer isso manualmente a cada vez ..):

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

O que acontece? Quem dá permissão de arquivo? fetchmail, procmail ou dovecot?

----- Editar ------

Obrigado pelas suas respostas, @tripleee. Vou tentar dar detalhes:

Eu instalei o sendmail, o procmail, o fetchmail, o dovecot & roundcube:

• Sendmail & Roundcube: instalação padrão.

• Procmail:

Em / etc / procmailrc (eu prefiro um conf global vs o jeito do usuário), nós temos:

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

• Fetchmail

Em / etc / fetchmailrc:

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

• dovecot

Eu criei um usuário de vmail:

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

Em / etc / dovecot / users (com o uid & gid do vmail):

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

No /etc/dovecot/conf.d/10-auth.conf, mudei para:

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

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

• Descrição do problema: os e-mails são copiados para minha pasta de e-mail, mas com permissões de root, para que o Roundcube não possa abrir e-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,

Obrigado por me ajudar ...

    

Answer 1

Sua combinação de software é um pouco incomum nos dias de hoje (ou seja, bastante padrão 10-20 anos atrás). Eu estou supondo que o que você está fazendo é usando o fetchmail para se conectar a um servidor POP e, em seguida, ele passa o email para o procmail para entregar o email em diretórios locais. Essa abordagem tornou-se incomum em parte porque não há muitos servidores agora que suportam somente POP, e o IMAP permite melhores opções para mover e-mails entre servidores após a entrega. Se houver uma opção para usar o IMAP no servidor upstream, dê uma olhada no imapfilter . Também é incomum hoje em dia querer executar um servidor de email que não pode aceitar a entrega direta, o que permitiria que você configurasse apenas uma regra de encaminhamento de email no servidor upstream.

Você está provavelmente com problemas porque está usando o procmail para entregar diretamente em diretórios locais, e fazendo isso com o processo do procmail rodando como root, que não é o que o dovecot executa, então o dovecot não pode ler os arquivos. / p>

Você pode descobrir como executar o procmail como o usuário correto ou (se executado como root) como informá-lo para armazenar arquivos com a propriedade correta. Você pode obter um grau de compatibilidade, mas, por exemplo, o DoVecot não conseguirá indexar os e-mails corretamente conforme eles chegam, por isso, a pesquisa será prejudicada.

Sugiro que você use deliver do dovecot como agente de entrega local. Pode substituir o procmail, ou pode ser chamado pelo procmail 1 , 2 . Em ambos os casos, você precisará chamá-lo com um argumento apropriado ( -d ), identificando o usuário para o qual você está entregando. Se você estiver usando o procmail para tomar decisões sobre qual pasta de correio entregar, talvez queira usar o argumento -p para isso, ou talvez seja melhor usar o mecanismo de filtragem de peneira da dovecot para tomar essas decisões. O procmail é realmente melhor quando se trata de usuários do sistema, em vez de usuários virtuais.

O Sieve é uma solução melhor projetada do que o procmail para usuários virtuais, embora seja uma questão em aberto que tenha uma sintaxe de filtro menos agradável. Eu tive muitos anos de bom serviço do procmail, e atualmente uso um pouco de peneira porque ela atua antes da entrega, mas para transferir e-mails entre servidores após a entrega, e onde as circunstâncias permitirem, prefiro escrever filtros com imapfilter .