Configurar email de entrada para entrega direta em sites hospedados por você com Mail-Receiver

Como isso é feito para criar uma nova definição de contêiner nesse diretório!?

Ao executar os comandos mostrados imediatamente após esse texto. Estritamente falando, você não está criando o arquivo nesse diretório, mas dentro do subdiretório containers, o mesmo que app.yml.

3 curtidas

Obrigado, a princípio eles não pareciam estar funcionando, mas agora cheguei ao editor de texto com:

Parece haver um problema com isso, ao executar
./launcher logs mail-receiver
relata discourse_base_url=https://discourse.example.com, em vez do domínio especificado no editor de texto.

Tentei reconstruir/reiniciar o bootstrap do mail-receiver, mas o domínio correto não foi alterado.

1 curtida

Causa do erro

1 curtida

Estou com um pequeno problema, poderia me dar um conselho!

root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.

starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver

então…

root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
master  4400 root   13u  IPv4  24419      0t0  TCP *:smtp (LISTEN)
master  4400 root   14u  IPv6  24420      0t0  TCP *:smtp (LISTEN)

Eu também tentei…

root@JEN /var/discourse # netstat -nlp | grep 25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      4400/master
tcp6       0      0 :::25                   :::*                    LISTEN      4400/master

e…

root@JEN /var/discourse # ps j 4400
   PPID     PID    PGID     SID TTY        TPGID STAT   UID   TIME COMMAND
      1    4400    4400    4400 ?             -1 Ss       0   0:02 /usr/lib/postfix/sbin/master -w

Estou encontrando instruções online para parar o container e matar o processo (processo 4400?)

Isso é seguro e corrigirá o problema?

Preciso (ou devo, ou não devo) mudar a porta 25 para uma porta diferente no arquivo mail-receiver.yml?

1 curtida

Talvez você tenha instalado o postfix e precise removê-lo?

Você não pode alterar a porta. Você precisa parar o que quer que a esteja usando. Apenas matá-lo não funcionará porque, quando você reiniciar, será uma corrida para ver qual processo inicia primeiro.

3 curtidas

Era o que eu estava pensando também. Não consigo imaginar como foi parar lá, mas vou tentar removê-lo. Caso contrário, posso simplesmente usar o Gmail, que parece estar funcionando perfeitamente.

2 curtidas

Acabei de mover meu fórum para um novo ambiente e, como resultado, reinstalei o mail-receiver. Parece que é uma versão mais recente do que eu tinha instalado anteriormente. A configuração YML mudou um pouco, com DISCOURSE_BASE_URL substituindo DISCOURSE_MAIL_ENDPOINT. O conteúdo do arquivo YML reflete a mudança, mas as instruções no topo deste tópico precisam ser atualizadas.

Além disso, ao receber um e-mail que é devolvido/rejeitado, estou recebendo os seguintes erros…

Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description

Mensagens válidas parecem ser tratadas corretamente. A versão anterior do mail-receiver não apresentou esses erros, pelo que pude ver nos arquivos de log recentes. Pesquisei um pouco e encontrei - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/

Adicionar o seguinte ao arquivo mail-receiver.yml parece resolver o problema para mim:

  ## Fix smtp errors
  POSTCONF_smtp_tls_fingerprint_digest: sha256
  POSTCONF_smtpd_tls_fingerprint_digest: sha256
4 curtidas

Postando aqui para informar que adicionamos suporte DMARC ao mail-receiver através de uma imagem discourse/mail-receiver:with-dmarc. Consulte Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver no OP para mais detalhes.

3 curtidas

2 posts foram mesclados em um tópico existente: Mail-receiver relay access denied

Gostaria de adicionar algo à seção de Solução de Problemas.

O Mail-Receiver (entrega direta) estava funcionando para vários domínios, mas não recebia mensagens de usuários do Gmail. Não consegui descobrir o motivo. Não havia nada nos logs, exceto uma conexão/desconexão do Google. Tudo parecia bom e as ferramentas online confirmaram que o DNS estava bom.

Eventualmente, criei um registro de relatório SMTP TLS no DNS, por exemplo:

_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com

Algumas horas depois, o Google (Gmail) enviou um relatório mostrando que havia armazenado em cache uma política mta-sts que não refletia os registros MX atuais. Fiquei preocupado que o Google fosse manter essa política em cache por uma semana, pois parecia ter ignorado meu registro DNS _mta-sts atualizado, que deveria ter causado uma atualização.

E logo depois disso, todo o meu Gmail em backup começou a fluir para o Discourse sem que eu fizesse nada. O relatório me ajudou a entender a perspectiva do Google sobre o problema e me poupou de ficar quebrando a cabeça quando as mensagens começaram a fluir.

Relatórios SMTP TLS são emitidos com pouca frequência, então seja paciente.

3 curtidas

Dado que o guia não diz nada sobre a configuração do MTA STS, adicionar etapas de diagnóstico para isso não confundiria os 99,999%+ de usuários que não o configuram?

2 curtidas

No meu caso, a adição de um único registro DNS foi suficiente para lançar luz sobre o meu problema. Dado que o guia já instrui a criação de registros DNS para a instalação do Mail-Receiver, sugerir um registro adicional na seção de Solução de Problemas como último recurso não parece um exagero. No entanto, vejo que sua postagem tem dois “likes” e a minha não tem nenhum, então esse pode ser o fim da história.

1 curtida

Essa é uma boa notícia, isso parece ser uma boa informação para adicionar ao guia, especialmente porque o Gmail é um remetente comum.

O guia instrui sobre a criação de registros DNS para fazer o mail-receiver funcionar, não para configurar o MTA STS. Portanto, um usuário que seguir o guia nunca terá o problema que você teve. Daí não haver necessidade de complicar o guia com etapas adicionais e desnecessárias.

1 curtida

Em geral, o mail-receiver é capaz de processar e-mails enviados pelo Gmail para novos tópicos?

Isso parece ser um grande problema, mas não se a causa for um incidente isolado.

Cheguei à conclusão de que Matt está certo. Minha instalação especificamente teve que lidar com MTA-STS porque o e-mail regular de seu domínio é tratado pelo Mail In a Box https://mailinabox.email/, que insiste em uma política MTA-STS rigorosa e o Gmail impõe essa política. Por padrão, a política pode entrar em conflito com a configuração do Mail-Receiver. A maioria dos domínios não terá uma política. Se um domínio tiver uma política, ela será visível em

https://mydomain.com/.well-known/mta-sts.txt

Minha política de trabalho se parece com isto…

version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400

Espero atualizar “mode: none” para “mode: enforce” após um pouco mais de trabalho.

2 curtidas

Alguém poderia me lembrar – quando reconstruímos o Discourse na linha de comando, ele reconstrói automaticamente o contêiner mail-receiver, ou precisamos fazer isso separadamente? Obrigado.

Ele não reconstrói; ele reconstrói apenas quando você o instrui a fazê-lo. Você não precisa reconstruir o receptor de e-mail com frequência.

2 curtidas

Definitivamente me ajudou:)

1 curtida