Hm. Eu tenho a mesma configuração Vultr que @MathiasFoster e @jryans aqui, e encontrei o mesmo problema (Net::OpenTimeout). ufw allow https fez meu e-mail de entrada funcionar.
Mas agora o site não envia nenhum e-mail. Antes de configurar o e-mail de entrada, o e-mail de saída estava funcionando bem.
Não tenho nada complicado acontecendo:
notification_email é admin@tasat.org.
O e-mail de saída usa smtp.titan.email na Hostinger.
Em e-mails pulados, estou vendo \u003creplies+verp-14c9cc6eb915b08d4983c90c744ba4b4@forum.tasat.org\u003e: Endereço do remetente rejeitado: não pertence ao usuário admin@tasat.org
Sou novo em fazer e-mails. Devo remover forum. das strings do mail_receiver.yml e tornar "replies@tasat.org" um alias de envio de "admin@tasat.org"..?
O receptor de e-mail é independente do Discourse e do envio de e-mails, ele atua apenas como um servidor de e-mail simples configurado apenas para receber e-mails, usando a API do Discourse para enviar esses e-mails para o Discourse.
A única coisa que consigo pensar na configuração que pode afetar o envio é definir reply by email address, embora isso deva apenas definir Reply-To nos e-mails de saída e não afetar o endereço do remetente.
Apenas para confirmar, parece que você tem estes (entre outros) em app.yml:
Se sim, os e-mails de notificação que não aceitam respostas ainda funcionam? Acredito que a verificação de e-mail é um exemplo disso, então você poderia tentar criar uma conta e ver se esse e-mail é enviado com sucesso.
Com essa configuração, o que deveria acontecer para e-mails que podem aceitar respostas é que o e-mail enviado usa: From: admin@tasat.org (também endereço do remetente) Reply-To: replies+abc123@forum.tasat.org
Normalmente, o Reply-To não é tratado como parte das informações do remetente, ele apenas fornece um endereço padrão To a ser usado quando as pessoas respondem, mas talvez a Hostinger o trate como tal. Você pode adicionar um alias de envio para replies@forum.tasat.org.
Acredito que o Vultr (ou talvez apenas a instalação do Docker quando o ufw está presente) tenha algumas regras que impedem os contêineres de se comunicarem entre si, o que significa que o receptor de e-mail não consegue se conectar ao Discourse. ufw allow https contorna isso.
Na rede padrão, somente se um contêiner se conectar diretamente a outro contêiner por endereço IP local, esse é o endereço IP local do próprio contêiner.
Quando o receptor de e-mail consulta o nome de domínio do seu Discourse, ele não obterá esse IP local, portanto, ele terá que sair de sua rede Docker e passará pelo ufw pelo menos uma vez para alcançar o Discourse.
Essa é uma situação separada, embora relacionada. São conexões vindas de fora e o Docker adiciona regras para permitir a passagem de portas expostas.
Não sou muito familiarizado com as regras de cadeia netfilter/iptables, mas acredito que o acima mostra:
Se a conexão estiver vindo de docker0, ou seja, da rede docker padrão, retorne para a cadeia anterior (pare de processar as regras nessa cadeia).
Caso contrário, se a conexão estiver vindo de qualquer coisa que não seja docker0, se for também https ou http, especifique DNAT fazendo com que ela avance para a cadeia FORWARD.
Portanto, com o arranjo mostrado no outro tópico, o que acontece é que se o tráfego https ou http vier de fora, ele será direcionado para o docker. Se o tráfego vier da rede docker, no entanto, ele será retornado e rejeitado ou descartado pela cadeia INPUT.
O que ufw allow https faz é adicionar uma regra à cadeia INPUT aceitando-a. Dessa forma, quando a conexão for retornada para a cadeia INPUT como acima, ela será aceita e encontrará o docker escutando, sendo finalmente roteada para o contêiner.
Obrigado pelas respostas! Tive que me ausentar por um tempo, mas estou voltando a isso…
Sim, é o que tenho no momento.
Quando tento criar uma conta agora, o botão de envio não faz nada. Como se soubesse que não vai funcionar. (E nada aparece em Skipped ou em outro lugar.)
Editar: Configurei “replies@tasat.org” como um alias de envio para admin@tasat.org e confirmei que funciona para enviar e receber. Também confirmei a entrega de um e-mail enviado de um cliente externo endereçado para replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org
No interesse de tentar algo, mudei reply by email address:
de replies+%{reply_key}@forum.tasat.org
para replies+%{reply_key}@tasat.org
Mas isso não muda os resultados.
Ele não chega ao mail-tester. Todas as tentativas de saída acabam em “skipped” com uma variedade desta mensagem:
553 5.7.1 <replies+verp-8c79cd4e83023bda6df0624c2cacd36e@tasat.org>:
Endereço do remetente rejeitado: não é propriedade do usuário admin@tasat.org
Talvez isso seja interessante..? Quando executo discourse-doctor, o e-mail de saída falha da seguinte forma:
==================== TESTE DE E-MAIL ====================
Para um teste robusto, obtenha um endereço em http://www.mail-tester.com/
Enviando e-mail para REDACTED . .
Testando o envio para admin@tasat.org usando smtp.titan.email:587,
usuário:admin@tasat.org com autenticação simples.
Conexão com o servidor SMTP bem-sucedida.
Enviando para admin@tasat.org. . .
E-mail não foi enviado.
Motivo: 553 5.7.1 <replies+verp-3cc19f7b135e6f56219e030999db9e29@tasat.org>:
Endereço do remetente rejeitado: não é propriedade do usuário admin@tasat.org
Enviar diretamente para o endereço replies+ (ou um endereço forum.tasat.org) de um cliente de e-mail funciona – ele segue o alias “replies” e chega à caixa de entrada do administrador. De onde vem a rejeição?
Dei uma olhada na seção do artigo “Impedir que o e-mail do host de saída interfira”. Não tenho o caminho /etc/postfix – mas aqui está a saída do meu netstat:
EDIT PRINCIPAL – Recebi uma resposta do suporte da Titan hoje à noite: “O endereço reply-to e o endereço do remetente devem ser os mesmos, caso contrário, o e-mail não será enviado.” Então, acho que todo o troubleshooting foi em vão e tenho que procurar um novo host de e-mail que não imponha esse requisito.
O tópico a seguir (linkado na parte inferior desse documento) também tem informações sobre o tratamento de devoluções para esses e outros:
Eu uso o plano flexível da Mailgun (inteiramente dentro da franquia gratuita) pessoalmente, mas sei que houve confusão em torno de seus preços e potencialmente as coisas mudaram para novos usuários desde que entrei. A última vez que vi (não faço ideia se ainda é verdade), era possível mudar para o flexível após o término do teste, era apenas incrivelmente confuso.
Certo.
Você pode mudar para o mailgun flex, embora eles dificultem a compreensão. Cerca de uma vez por mês, eu os envio um e-mail perguntando por que é tão difícil de encontrar.
@Simon_Manning e @pfaffman – obrigado novamente pelas contribuições e dicas, me colocaram no caminho certo.
Decidi experimentar o MailerSend, já que o plano gratuito atual deles é bem generoso. Deve atender ao nosso esforço sem fins lucrativos por um tempo. As coisas estão funcionando bem até agora
