Se eu não precisar de nenhuma das coisas avançadas, então não preciso usar as variáveis POSTCONF_smtpd_tls..., certo?
O site é, claro, https.
Se eu não precisar de nenhuma das coisas avançadas, então não preciso usar as variáveis POSTCONF_smtpd_tls..., certo?
O site é, claro, https.
Você não precisará das variações acima, mas ainda precisará da configuração TLS encontrada em samples/mail-receiver.yml, modificada para o nome do seu domínio, a fim de suportar a criptografia TLS.
Assumindo que você esteja usando o modelo Let’s Encrypt para https, as linhas da amostra só precisam ser descomentadas com o nome do domínio substituído.
hm, então alguma ideia do porquê parou de funcionar recentemente, mostrando este erro sobre certificados?
<19>Oct 6 19:18:27 receive-mail[94]: Falha ao POST o e-mail para https://www..../admin/email/handle_mail:
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed (OpenSSL::SSL::SSLError)
<19>Oct 6 19:18:27 receive-mail[94]: /usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `connect_nonblock'
/usr/local/lib/ruby/2.3.0/net/protocol.rb:44:in `ssl_socket_connect'
/usr/local/lib/ruby/2.3.0/net/http.rb:928:in `connect'
/usr/local/lib/ruby/2.3.0/net/http.rb:863:in `do_start'
/usr/local/lib/ruby/2.3.0/net/http.rb:852:in `start'
/usr/local/lib/ruby/2.3.0/net/http.rb:1384:in `request'
/usr/local/lib/ruby/site_ruby/mail_receiver/discourse_mail_receiver.rb:42:in `process'
Bem, o erro está mostrando que ele recebeu um e-mail e está falhando ao verificar o certificado ao tentar se conectar à sua instância do Discourse. Isso nos diz que o problema não é com outra coisa se conectando ao seu receptor de e-mail, embora não necessariamente que o TLS esteja funcionando. (O e-mail pode ter sido entregue sem TLS)
É difícil dizer o que pode estar acontecendo apenas com base nisso, mas se você acessar https://www.... (domínio exatamente como aparece na mensagem de erro) em seu navegador, ele se conecta com sucesso?
Se sim, isso provavelmente sugere que seu receptor de e-mail não confia nele por algum motivo.
Se não, isso pode sugerir algo errado com a configuração SSL em app.yml (por exemplo, obter apenas um certificado para example.com e não para www.example.com) ou algo errado com o URL do Discourse em mail-receiver.yml (por exemplo, usar www.example.com quando deveria ser apenas example.com).
Se você incluísse o nome do seu host, poderíamos ajudar mais.
Você alterou o nome de domínio do seu site? O certificado está correto no site?
Algo mais mudou no site nos últimos 90 dias?
https://www.programmersforum.rocks
Nenhuma alteração no domínio ou em qualquer outra coisa, o site funciona bem.
Na verdade, os logs mostram que começou em novembro passado, mas ainda assim não houve alterações.
Ok, esse certificado está perfeito.
Fale-nos mais sobre o servidor de e-mail que se conecta ao seu fórum. É um contêiner docker receptor de e-mail comum?
Eu verifiquei com //email/testTo:; se você quiser ver por si mesmo, essa é uma maneira de testar.
Como Richard sugere, o problema não parece ser com o Discourse receptor de e-mail.
Se começou em novembro passado, é quase certo que seja a expiração do certificado raiz do Let’s Encrypt. Você só precisa baixar a nova imagem e reconstruir.
Não, acho que o problema está entre o receptor de e-mail e o Discourse.
O Discourse é público, então pude verificar o certificado do Discourse e ver que estava tudo bem.
Portanto, minha suspeita é que o problema esteja no lado do receptor de e-mail.
Essa parece uma boa possibilidade!
Concordo, mas a explicação do Simon pode explicar o problema com o que quer que esteja se conectando ao receptor de e-mail.
EDIT: Se for possível que o problema tenha começado em novembro passado, mas só foi notado recentemente.
…
Alex corrigiu quando começou em uma de suas respostas:
ah, sim, a atualização corrigiu o erro SSL.
Mas depois disso, estava recebendo uma resposta 404. Criar uma nova chave de API corrigiu isso.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.