Existe alguma forma de fazer “downgrade” do Discourse para uma versão anterior que funcione (por exemplo, 2.8.0 stable ou 2.9.0 beta3) até que isso seja resolvido?
1 curtida
Decidi gastar mais meia hora investigando isso e acho que encontrei a causa.
Isso parece estar relacionado à migração para o Rails 7, que atualizou o net-smtp de 0.1.0 para 0.3.1, o que alterou os padrões.
A maneira como a gem smtp chama net-smtp não desabilita enable_starttls_auto e openssl_verify_mode, ela apenas o habilita quando habilitado.
10 curtidas
Bom trabalho, Richard! Isso teria levado duas horas para mim, senão o dobro disso. Para mim é mais fácil sucumbir a lidar com os novos padrões.
Aha. Então eu estava meio certo, é só que pode não ser muito difícil para um PR consertar isso.
4 curtidas
Bom trabalho, @RGJ!
Enquanto aguardamos uma correção, em uma nota paralela, seria bom se este problema não causasse a cascata de problemas que experimentei, que quase derrubaram meu fórum completamente. Especificamente:
- As falhas de e-mail parecem ser retentadas com extrema rapidez, o que faz com que a fila do sidekiq exploda em tamanho e ~100% de uso de CPU causado por essas tarefas.
- Além disso, algo (quedas ou reinícios) estava fazendo com que o Redis gravasse enormes arquivos temporários, que presumo conter o estado da fila do sidekiq. Embora fossem seguros para remover, eles rapidamente preencheram o disco, o que causou mais quedas, e assim por diante. Eu tinha algum espaço em disco que pude liberar para reiniciar o fórum e descobrir o que estava acontecendo, mas isso pode não ser verdade para todos. (Também é um tanto difícil confirmar que, neste caso, os arquivos temporários do Redis são de fato seguros para excluir.)
Minha suposição é que a solução mais simples aqui é diminuir a velocidade da retentativa em trabalhos de e-mail com falha — ou pelo menos naqueles que não têm restrições de tempo, como redefinições de senha. O que parece apropriado, dado que problemas de e-mail provavelmente não se resolverão rapidamente, e a maioria/todos os remetentes farão suas próprias retentativas assim que receberem uma mensagem.
8 curtidas
No meu caso, quando encontrei a falha após a atualização, estava usando TLS com um servidor de terceiros e o nome no certificado correspondia ao nome do servidor SMTP. Tive apenas uma falha, no entanto. Não reiniciei nem atualizei desde então para evitar mais problemas. Tentarei uma atualização assim que o patch for lançado e verei como funciona.
2 curtidas
Começarei criando um tópico em Bug, mas como tecnicamente é um problema em uma gem upstream, não tenho certeza de quanta prioridade isso receberá.
3 curtidas
+1 :preocupado: bug realmente frustrante
1 curtida
A gem não pode ser revertida? Ficaria surpreso se isso não recebesse atenção, já que se trata de uma funcionalidade “central”, a capacidade de enviar e-mails, e para alguns também está causando uma interrupção devido a arquivos temporários e ao uso excessivo da CPU no servidor. A estabilidade central do fórum está sendo interrompida aqui.
2 curtidas
Por favor, não se esqueça de que isso pode ser facilmente resolvido configurando seu servidor de e-mail adequadamente também.
1 curtida
Pelo que sei, meu servidor está configurado corretamente. O nome do certificado corresponde ao nome do host smtp, STARTTLS na porta 587. Estou me perguntando por que enfrentei o problema?
Obrigado por abrir um novo ticket. Dada a sua compreensão, você poderia esclarecer as combinações das duas variáveis que você apontou no arquivo YML - como elas devem ser usadas para diferentes cenários?
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Por exemplo, tenho apenas STARTTLS na porta 587 e nenhuma outra porta sendo usada por SMTP por motivos de segurança. Ambas as variáveis devem ser especificadas no arquivo YML ou apenas uma?
2 curtidas
Depende.
Se o seu servidor SMTP estiver configurado corretamente, você não precisará de nenhum deles.
Mas o problema agora é que eles não estão fazendo nada.
Envie-me uma mensagem privada com o nome do seu servidor SMTP e eu darei uma olhada para ver se consigo descobrir por que não está funcionando para você.
2 curtidas
Tenho um servidor SMTP local sem suporte a TLS/SSL e, quando uso StartTls=false, não funciona 
1 curtida
[quote=“Richard - Communiteq, post:56, topic:225778, username:RGJ”]seu servidor de e-mail corretamente também.
[/quote]
Ponto justo, mas nem sempre é nosso servidor de e-mail. Estou usando um servidor de e-mail interno que é mantido por outro grupo e, portanto, não tenho controle sobre os problemas de certificado ou a configuração do servidor de e-mail.
Dito isso, para outros que estão com dificuldades nisso, uma opção pode ser configurar seu próprio servidor de e-mail em localhost e apenas encaminhar os e-mails. Então você tem controle sobre o servidor de e-mail com o qual o Discourse se comunica, e seu servidor de e-mail em localhost pode ser configurado para lidar com quaisquer problemas de upstream que você possa encontrar. Eu já fiz isso antes, mas o removi em algum momento, pois era mais simples fazer o Discourse se comunicar diretamente com o servidor de e-mail upstream. (Opa.)
1 curtida
É por isso que a Instalação Padrão recomenda provedores de e-mail de terceiros, em vez de tentar usar uma solução existente ou auto-hospedada.
O e-mail é difícil por uma infinidade de razões, só porque algo está funcionando hoje não significa que está configurado corretamente, apenas que a má configuração não impacta o propósito original.
1 curtida
O motivo pelo qual escolhi o Discourse foi que ele deveria ser fácil de instalar e manter para pequenas implantações auto-hospedadas.
1 curtida
E é possível se você seguir as recomendações.
Se você optar por seguir um caminho diferente, não é realmente possível fazer quaisquer garantias.
1 curtida
Resumindo, você está dizendo que com o Discourse não é mais possível usar um servidor SMTP sem TLS, SSL ou StartTLS?
1 curtida
Não acho que ninguém esteja sugerindo isso. Isso se relaciona apenas com a forma como o problema surgiu e levou tempo para encontrar uma causa raiz.
A razão pela qual estamos vendo apenas um punhado de casos aqui é devido ao número relativamente pequeno de instalações com a gema atualizada que também não estão transmitindo e-mails por alguma forma de transporte seguro.
Richard já iniciou um tópico sobre o bug:
Para quem precisar que isso funcione mais cedo, eles também podem ativar o TLS em seu servidor de e-mail ou mudar temporariamente para um provedor de e-mail que ofereça transporte seguro.
1 curtida
Eu tenho TLS ativado com um certificado válido e nome de host correspondente desde o início e, em seguida, encontrei o problema após a atualização BETA 4 (461936f211) e postei os logs no tópico abaixo. Outro usuário também está tendo problemas e, de acordo com ele, seus certificados também estão em ordem:
1 curtida
É o que parece para mim. Alguns dos comentários nesta thread têm sido francamente irritantes.
Eu faço a auto-hospedagem do Docker-Discourse e uso meu host Docker como servidor de e-mail. Tenho usado o Discourse na porta 25, sem TLS, para entregar e-mails através da interface Docker interna desde o início, há seis anos. Esta é uma configuração perfeitamente razoável e perfeitamente segura. As transações eram 100% internas ao meu próprio host. Veja mais acima na thread para minha antiga configuração.
Para mim, a solução alternativa foi fazer o seguinte:
Adicionar o endereço IP da interface Docker interna do host como um host válido no arquivo de zona DNS para o meu domínio. Ou seja:
discourse-mail.jag-lovers.com A 172.17.0.1
Por favor, note: Eu poderia inventar qualquer nome de host no domínio jag-lovers.com, já que uso um certificado curinga (CN = *.jag-lovers.com). Se você não tiver um certificado curinga, certifique-se de usar um nome de host que seja um CN ou SAN válido em seu certificado.
Por favor, note também: O endereço IP que usei acima é o endereço IP interno que meu host usa na interface Docker, para se comunicar com o contêiner Discourse-Docker. É um endereço IP privado e não roteável.
Em seguida, altere a configuração do app.yml do Discourse para se conectar ao nome de host que acabei de criar, para usar TLS, para se conectar na porta 587 e para usar SASL para fazer login no host para cada transação de e-mail (porque, caso contrário, você receberá uma mensagem de erro de retransmissão negada).
DISCOURSE_SMTP_ADDRESS: discourse-mail.jag-lovers.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: REDACTED
DISCOURSE_SMTP_PASSWORD: "REDACTED"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opcional, padrão true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
Em seguida, reconstrua o Discourse. Isso corrigiu o problema para mim.
2 curtidas