Estou lidando com procmail
a primeira vez, então peço desculpas se a pergunta a seguir é estúpida. Antes de colocar procmail
em produção, estou fazendo alguns testes básicos. Um deles produziu um resultado totalmente inesperado que o torna quase inútil no meu cenário:
Quando procmail
não consegue ler seu arquivo de configuração, ele define seu código de saída como 0
(true) quando termina. Isso é catastrófico, porque no meu cenário, estou usando procmail
como um MDA que é executado de dentro do fetchmail
. Se procmail
não puder ler seu arquivo de configuração, ele não poderá processar (entregar) mensagens conforme necessário, mas definirá o código de saída 0
quando terminar; fetchmail
interpreta isso como uma entrega bem-sucedida e exclui as respectivas mensagens upstream. Em resumo, isso leva à perda dessas mensagens.
As permissões neste cenário são bastante complexas ( fetchmail
+ procmail
+ cyrdeliver
over lmtp
, fetchmail
rodando sob sua própria conta de usuário, procmail
sendo suid
e setgid
, e assim por diante), então pode muito bem acontecer que alguém cometa um erro com as permissões quando algo precisa ser alterado. Devido ao problema descrito acima, tais erros provavelmente levam à perda de mensagens.
Portanto, gostaria de saber como fazer procmail
para sair com falha (código de saída diferente de 0
) caso não consiga ler seu arquivo de configuração.
Para dar uma ideia do que se trata, considere a seguinte sessão de terminal (linhas irrelevantes removidas). Observe que a propriedade / permissões no diretório de configuração estão erradas intencionalmente, porque este é meu caso de teste.
root@morn /etc/fetchmail # whoami
root
root@morn /etc/fetchmail # dir
total 52K
drwx------ 2 fetchmail root 4.0K 2022-01-23 10:09 .
drwxr-xr-x 123 root root 12K 2022-01-22 17:17 ..
-rw------- 1 fetchmail root 2.4K 2022-01-23 10:09 fetchmailrc
-rw------- 1 root mail 282 2022-01-23 02:49 procmailrc
-rw-r--r-- 1 root root 110 2022-01-23 00:36 testmessage
root@morn /etc/fetchmail # dir `which procmail`
-rwsr-sr-x 1 root mail 92K 2017-11-16 23:42 /usr/bin/procmail
root@morn /etc/fetchmail # cat /etc/systemd/system/pp-fetchmail.service
User=fetchmail
Group=mail
ExecStart=/usr/bin/fetchmail -f /etc/fetchmail/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid --syslog
root@morn /etc/fetchmail # cat fetchmailrc
poll
pop3.example.com
proto pop3
bad-header accept
user "[email protected]"
ssl
pass "supersecret"
is "user1" here
no rewrite
mda "/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc"
root@morn /etc/fetchmail # cat testmessage
From: [email protected]
To: [email protected]
Subject: Test message
This is a test message.
root@morn /etc/fetchmail # sudo -u fetchmail -g mail /usr/bin/procmail /etc/fetchmail/procmailrc < testmessage && echo "procmail exited 0"
procmail: Couldn't read "/etc/fetchmail/procmailrc"
procmail exited 0
Claro, as duas últimas linhas são o problema. Alguém sabe como contornar? É claro que corrigir as permissões faria com que funcionasse corretamente, mas é isso que não estou pedindo explicitamente. Eu gostaria de ter uma solução mais robusta em caso de erros (meus ou outros).
Se o Procmail retornar com sucesso, ele entregou as mensagens com sucesso em algum lugar, embora aparentemente não onde você queria. Uma falha ocorreria quando ele ficasse sem fallbacks e não pudesse entregar em qualquer lugar. Para descobrir para onde vão as mensagens, examine o arquivo de log (que é emitido com erro padrão se você não configurou explicitamente um arquivo de log). No entanto, na ausência de qualquer configuração de log explícita, você verá principalmente apenas os logs de entrega reais, como
O procmail pronto para uso simplesmente será entregue
DEFAULT
na ausência de outras instruções. A-m
opção requer um arquivo de configuração e falhará com um erro (código de saída 73) se não puder ser lido, mas desativará algumas das funcionalidades de entrega regular, que podem não ser o que você deseja.Sua configuração parece bastante frágil no geral.
TARGET=user
por si só não significa nada para o Procmail, então você realmente tem que ter umprocmailrc
arquivo que faça algo com essa informação. O mecanismo de entrega regular usaria-d user
para entregar explicitamente ao usuário em questão e lidar com fallbacks etc. de forma robusta. (Não estou familiarizado o suficiente com Fetchmail para ter uma opinião informada sobre o que seria correto usar aqui.)Nesse caso, eu escreveria um script de shell wrapper que envolve a
"/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc"
chamada, mas executa a verificação de permissões do arquivo de configuração antecipadamente. Se o arquivo de configuração não puder ser lido, retorne 1, se puder ser lido, execute a"/usr/bin/procmail TARGET=user1 /etc/fetchmail/procmailrc"
chamada e retorne.Então, no
fetchmailrc
arquivo, faça isso: