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.
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.
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?
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.
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.
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
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.
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.
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?
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.
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.
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.
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.
Definitivamente me ajudou:)
