Existe uma maneira de apenas sondar o IMAP para e-mails recebidos

Suporte
2

Ok, outro membro da equipe mencionou que a verificação IMAP nunca funcionou corretamente, foi parcialmente removida e essas poucas configurações parecem ser resquícios de quando se pretendia implementá-la.
*EDIT: Encontrei uma declaração sobre isso: IMAP support for group inboxes - #39 by martin
Parece um passo atrás, já que para mim o POP3 é obsoleto e impraticável hoje em dia, onde as pessoas geralmente usam vários clientes de e-mail (mínimo de telefone + PC). Portanto, não vejo sentido em habilitar ouvintes POP3 em uma instância Dovecot.

No entanto, consegui implementar a API direta do receptor de e-mail do Discourse em nosso Postfix existente sem o contêiner do receptor de e-mail e até mesmo sem seus scripts Ruby, mas seguindo principalmente a integração do Postfix usada no contêiner do receptor de e-mail do Discourse: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub

/etc/postfix/main.cf:

# Para o endereço de e-mail de resposta do Discourse, substituímos o transporte padrão por meio do mapeamento de transporte
transport_maps=hash:/etc/postfix/transport

/etc/postfix/transport

# Um serviço chamado "discourse" é usado como ponto de extremidade de transporte para e-mails para o endereço de resposta do Discourse definido
forum.reply@dietpi.com discourse:

/etc/postfix/master.cf

# Definimos o serviço de transporte "discourse" como um daemon pipe para o curl ouvindo em um soquete UNIX (privado)
# Não pode ser sem privilégios ou chrooted para o pipe para o curl funcionar
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=\u003c- -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
  • Assim, o mapeamento de transporte passa e-mails para o endereço de resposta para nosso serviço personalizado discourse.
  • O melhor desempenho deve ser um soquete UNIX, e ele pode ser privado (o primeiro -), já que nada mais precisa usá-lo de qualquer maneira. “Privado” significa que o soquete está localizado em /var/spool/postfix/private/discourse, em um diretório onde apenas o usuário postfix tem acesso, dentro do diretório chroot do Postfix /var/spool/postfix.
  • Mas não pode ser sem privilégios ou chrooted para pipe funcionar com curl (n n).
  • Em seguida, minimizamos as permissões usando o usuário/grupo nobody:nogroup.
  • Seguindo a API do receptor, o e-mail precisa ser anexado a um campo de formulário email, o que pode ser feito por meio da chamada STDIN <- do curl. Os cabeçalhos Api-Username e Api-Key precisam ser adicionados, o primeiro sendo geralmente system, o segundo pode ser gerado no Discourse, como uma chave de API granular com apenas permissões receive_emails. Em seguida, usando o endpoint HTTP respectivo.

Intencionalmente pulamos as verificações rápidas da política de rejeição feitas pelo contêiner do receptor:

  • Ele verifica a existência dos cabeçalhos From e To, se o remetente é um endereço completo com domínio e se está em uma lista negra que pode ser opcionalmente definida por meio da variável de contêiner BLACKLISTED_SENDER_DOMAINS. E envia os endereços do remetente e do destinatário para outro endpoint de API HTTP do Discourse, que verifica se o destinatário corresponde ao modelo de endereço de e-mail de resposta configurado e se o endereço do remetente pertence a um usuário registrado, a menos que o fórum esteja configurado para criar novos usuários inativos em e-mails recebidos, o que estranhamente estava habilitado por padrão em nosso caso?
  • A maior parte disso, e mais, é verificada por nosso serviço de receptor de SMTP público do Postfix de qualquer maneira, e tudo passa pelo rspamd, o que implica verificações DKIM, SPF e DMARC.
  • Mas, o mais importante, as mesmas verificações são realizadas pelo backend final do receptor de e-mail do Discourse de qualquer maneira. A única desvantagem: remetentes não recebem um e-mail de rejeição/bounce do daemon de e-mail, mas erros em caso de remetente/destinatário inválido são registrados em nosso Discourse. Mas se o remetente e o destinatário estavam corretos, apenas o conteúdo do e-mail não é o esperado (especialmente o cabeçalho Message-ID ausente), os remetentes recebem um e-mail adequado do Discourse. Os e-mails de rejeição/bounce SMTP ausentes estão totalmente bem, na minha opinião, dado que, de outra forma, a implementação tem sobrecarga mínima, tem uma solicitação de rede e processamento de backend a menos por e-mail, etc.
  • Geralmente: tenha cuidado com espaços em argumentos de comando master.cf. A citação para manter os espaços literais não funciona. Em vez disso, tal argumento precisaria ser envolvido em chaves: {algum argumento com espaços}. Mas neste caso, nenhum argumento contém espaços, aqueles entre a chave do cabeçalho e o valor também são opcionais.

Funciona muito bem até agora e se integra perfeitamente à nossa configuração existente com transporte virtual padrão para Dovecot, e o mapeamento de transporte também é usado para encaminhar alguns e-mails para endereços externos, já que nem todos da equipe querem/precisam de uma caixa de correio adicional em nosso servidor. Se um endereço catch-all estiver definido no mapeamento de alias virtual, o endereço de resposta do Discourse precisa ser adicionado a essa tabela, mapeando para si mesmo (como outros usuários/endereços virtuais locais).