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.