Houve muitas atualizações recentemente. Uma delas quebrou a linha de assunto (não inclui mais a categoria) e agora nenhum e-mail está sendo enviado. Os usuários estão muito insatisfeitos. Não sei como começar a depurar este problema. Onde posso encontrar os logs de erro e eu me lembro que existe alguma página sobre as filas do Sidekiq e assim por diante, mas não consigo encontrá-la. Qualquer ajuda seria muito apreciada.
Sim, notei que as notificações por e-mail não parecem estar sendo enviadas no momento após uma atualização ontem, embora os resumos/digest ainda estejam funcionando. Estamos sozinhos nisso?
2 curtidas
A causa disso pode ser o sidekiq falhando ao processar trabalhos agendados quando deveria.
Identificamos o mesmo problema hoje mais cedo em nossos sites de CD. Certifique-se de estar pelo menos no commit:
(Acho que este é o commit, não tenho 100% de certeza)
Para ver se o problema é o mesmo, verifique os trabalhos agendados em /sidekiq e veja se há algum no passado.
3 curtidas
Sim, fomos afetados por isso. Uma atualização resolveu.
2 curtidas
4 publicações foram movidas para um novo tópico: Email From: cabeçalhos perderam o texto “via NOME_DO_SITE”
Confirmo centenas de tarefas do sidekiq com falha no latest-release +103
corrigido no latest-release +153
Estou atualizado para a versão mais recente e ainda estou com um problema de envio de e-mail em um dos meus sites. Eu simplesmente recebo uma mensagem de erro ao enviar um e-mail de teste.
ERRO - fim do arquivo alcançado
Estou no celular agora, verificarei o sidekiq e os logs quando estiver no meu computador. Alguma outra sugestão de onde procurar?
Olá Tobias!
Seu problema é diferente - a conexão está sendo interrompida esperando por uma resposta logo após a conexão inicial bem-sucedida.
Eu arriscaria um palpite de que você está tentando usar o protocolo errado na porta errada… quais configurações você está usando?
A tarefa rake emails:test (com a lógica e mensagens de erro atualizadas recentemente) mostra algum erro diferente?
Olá Michael! Obrigado pela resposta. Sinto muita falta de vocês! 
Hmm… Eu acabei de migrar meu site do DO para a Hetzner e funcionou bem por algumas semanas. Meu outro site também está funcionando bem. É um quebra-cabeça. Só que, em algum momento, cerca de uma semana atrás, parou de funcionar e, quando verifiquei, vi os erros. Entrei em contato com a Hetzner (recusaram-se a ajudar) e com o Mailgun. De acordo com o Mailgun:
Obrigado pela sua resposta, o último evento autenticado aceito que estamos vendo foi em 11 de janeiro e foi enviado via SMTP.
Você pode confirmar se alguma alteração foi feita? Por favor, forneça uma captura de tela da configuração do seu aplicativo de envio para nossa análise, bem como quaisquer erros relevantes nos logs do seu aplicativo de envio/envio SMTP.
Eu acabei de mudar minha senha do Mailgun caso fosse isso e tentei novamente, mas sem sucesso.
Saída de rake emails:test:
root@ubuntu-4gb-nbg1-1-app:/var/www/discourse# rake emails:test
Testando o envio para usando smtp.mailgun.org:587, nome de usuário: postmaster@domain com autenticação simples.
====================================================================================== ERRO =======================================================================================
ERRO DESCONHECIDO!
EOFError: fim de arquivo alcançado
===================================================================================== SOLUÇÃO =====================================================================================
Este não é um erro comum. Nenhuma solução recomendada existe!
Por favor, relate a mensagem de erro exata acima para https://meta.discourse.org/
(E uma solução, se você encontrar uma!)
====================================================================================================================================================================================
1 curtida
Acho que está falhando antes mesmo de tentar o login.
Para eliminar o Discourse como fator, tente a partir do host E de dentro do contêiner:
$ openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Você deve obter um monte de saída e então conseguir tentar a autenticação:
○ → openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Connecting to 34.160.63.108
CONNECTED(00000003)
…
SSL-Session:
…
---
read R BLOCK
EHLO localhost
250-2ed1d46f4d7dec773e2a97b59f3a3bf8a2d6db54f94eead5dcf49e3ea1caac18
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250-8BITMIME
250-SMTPUTF8
250 PIPELINING
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
501 Username used for auth is not valid email address
535 Authentication failed
closed
As strings que você digitaria são:
EHLO localhost
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
(essa string são as credenciais michael/password, então obviamente não funcionará, mas você pode ver este post para aprender como construir a string para suas credenciais reais se quiser tentar manualmente)
Espero que ver em primeira mão o que funciona e o que falha ajude.
Você também pode querer tentar usar o swaks se estiver disponível - provavelmente é um pacote do sistema operacional que você pode instalar.
É um pouco mais fácil e você pode, por exemplo:
swaks --to frodo@shire.net --from bilbo@shire.net --auth PLAIN --auth-user bilbo --auth-password ring --server smtp.mailgun.org:587 --tls
exceto que você pode usar suas credenciais reais.
A saída disso também pode ajudar a revelar o problema.
Eu tentei usar o swaks e obtive isto:
=== Tentando smtp.mailgun.org:587...
=== Conectado a smtp.mailgun.org.
*** O host remoto fechou a conexão inesperadamente.
Isso me inspirou a verificar a partir do meu outro servidor, onde o swaks retornou “Great success” - a mensagem é bem adorável!
<~ 250 Great success
~> QUIT
<~ 221 See you later. Yours truly, Mailgun
=== Conexão encerrada com o host remoto.
Então, o problema é ou o mailgun bloqueando meu servidor, ou meu servidor de alguma forma estando mal configurado. Vou verificar com o mailgun e, se não for isso, então irei destruir e reconstruir meu servidor.
1 curtida
Faz sentido; isto é essencialmente o mesmo erro que
Como você suspeita, a causa mais provável é algo externo interferindo na conexão.
1 curtida
Eu suspeito que você precise usar a porta 2525 em vez da 587
A Hetzner afirma explicitamente que não bloqueia a porta 587.
Além disso, se bloqueassem, provavelmente apareceria como uma falha ao estabelecer uma conexão.
Isso quase elimina a configuração do Discourse e do Mailgun.
Neste ponto, o diagnóstico mais útil é tentar uma porta de envio alternativa do Mailgun a partir do servidor afetado:
openssl s_client -connect smtp.mailgun.org:2525 -starttls smtp
(ou o mesmo teste com swaks).
O Mailgun suporta 2525 especificamente para ambientes onde 587 é interferido por firewalls, filtragem de saída ou regras de rede no nível do provedor.
Se:
- 2525 funcionar e 587 não → muito provavelmente interferência de rede / IP / roteamento
- ambos falharem → caso ainda mais forte de que algo externo está bloqueando ou encerrando a conexão
De qualquer forma, o comportamento corresponde muito mais a uma “interferência de conexão externa” do que a uma regressão do Discourse ou do Sidekiq.
Ainda não tive retorno do Mailgun… meu plano, se eles não puderem ajudar, é simplesmente recomeçar com um novo servidor Hetzner.
Eu tentei o swaks com outras portas e, curiosamente, obtive o mesmo erro com a 2525, e imediatamente, sem qualquer atraso.
=== Tentando smtp.mailgun.org:2525...
=== Conectado a smtp.mailgun.org.
*** Host remoto fechou a conexão inesperadamente.
Mas obtive um erro diferente com as portas 25 e 465, e demorou alguns segundos para a resposta vir.
=== Tentando smtp.mailgun.org:25...
*** Erro ao conectar a smtp.mailgun.org:25:
*** Tempo limite de conexão esgotado
=== Tentando smtp.mailgun.org:465...
*** Erro ao conectar a smtp.mailgun.org:465:
*** Tempo limite de conexão esgotado
Não tenho certeza do que pensar sobre isso. Talvez haja um firewall mal configurado no servidor bloqueando algumas portas.
isso é intencional e esperado.
A Hetzner bloqueia essas portas por padrão.
1 curtida
Faz sentido… mas é interessante que as portas 25 e 465 demoraram mais para falhar do que as outras. De qualquer forma, isso não é urgente e vou esperar o retorno do Mailgun. É para o meu site familiar, então estou apenas incentivando todos a fazerem login e verificarem as notificações por uma mudança, e não apenas esperar por e-mail!
Vou para a Alemanha para visitar a família e um funeral amanhã… na próxima semana eu analisarei isso novamente e provavelmente começarei do zero com um novo servidor.
Obrigado por toda a orientação! Aprendi muito com este processo. Gostei muito daquela ferramenta swaks.
O tempo pode ser uma informação útil, de fato.
Quando uma porta (mais geralmente, o tráfego) é bloqueada, ela pode ser bloqueada por dropping (rejeição silenciosa) ou rejeitada (uma mensagem de “inalcançável”, por exemplo, “porta inalcançável”, é enviada de volta ao originador).
Uma rejeição silenciosa é o que você vê com 25/465 - uma tentativa de conexão é feita e nada acontece até que o tempo limite seja atingido.
Uma rejeição causa uma mensagem como “Conexão recusada” ou “Porta inalcançável”.
Isso é indicativo de comportamento intencional - você está obtendo uma conexão e então a conexão é imediatamente fechada.
Você variou a origem, então algo mais que você pode tentar é variar o destino. Tente o mesmo comando contra, por exemplo, smtp.gmail.com ou smtp.office365.com. Você deve obter uma falha de autenticação, e isso é uma forte indicação de que é o mailgun que está rejeitando você especificamente.
1 curtida
Essa explicação do @supermathie está perfeita 
A diferença de tempo é, na verdade, um sinal útil, não ruído.
Para resumir o que você está vendo:
- 25 / 465 com tempo limite (timeout) → queda silenciosa (bloqueio no nível de política da Hetzner, esperado)
- 2525 conectando e fechando imediatamente → o caminho TCP está bom, mas o lado remoto está encerrando a sessão
Esse último é o detalhe chave.
Porque:
- o handshake TCP é bem-sucedido
- a negociação TLS nunca chega a começar
- e acontece instantaneamente
…isso sugere fortemente que o Mailgun está rejeitando a conexão precocemente, e não o Discourse, Sidekiq ou Ruby.
Isso se alinha com algumas coisas que vimos recentemente:
- reputação de IP / filtragem baseada em região
- novos intervalos de IP da Hetzner ainda não confiáveis
- ou verificações de política do lado do Mailgun antes da troca do banner SMTP
Nada no Discourse causaria um fechamento imediato do socket remoto como esse - o Sidekiq apenas entrega a mensagem ao Net::SMTP e espera.
Se você quiser mais uma confirmação muito forte mais tarde (sem urgência alguma):
openssl s_client -connect smtp.gmail.com:587 -starttls smtp
Você deve obter um banner SMTP adequado e, em seguida, uma falha de autenticação - o que basicamente provaria que o SMTP de saída em si está bom e que o Mailgun é o único endpoint se comportando de forma diferente.
E entendo completamente pausar isso - especialmente dadas as circunstâncias.
Sinto muito que você esteja lidando com isso em cima de todo o resto 
Se o Mailgun retornar algo útil, ótimo - mas, honestamente, começar do zero ou mudar de provedor (Brevo, Postmark, etc.) costuma ser mais rápido do que esperar por correções de reputação de SMTP.
Você já depurou isso exatamente da maneira certa - nada aqui sugere que você perdeu algo ou configurou mal o Discourse.
Boa viagem para a Alemanha e se cuide.
1 curtida