Tenho lutado por vários dias para resolver um problema com e-mails de saída da minha instância Discourse. Estou executando o Discourse em um contêiner Docker em um VPS Spaceship (Phoenix, EUA). Meu provedor de e-mail é o Spacemail (SMTP).
Problema:
O Discourse não consegue enviar e-mails. Toda tentativa de enviar um e-mail de teste resulta em um erro de tempo limite:
Net::ReadTimeout with #<TCPSocket:(closed)>
Ou: execution expired
O problema persiste, independentemente de eu usar mail.spacemail.com ou smtp.spacemail.com como servidor SMTP.
O que eu tentei:
Verifiquei todas as configurações SMTP (endereço, porta 465 para SSL, e-mail completo como nome de usuário, senha correta) com o suporte da Spaceship/Spacemail.
Redefini e reinseri a senha SMTP várias vezes.
Confirmei com o suporte do Spacemail que não há restrições ou bloqueios do lado deles.
O Telnet do VPS para mail.spacemail.com na porta 465 é bem-sucedido (conexão abre, sem problema de firewall).
Mudei o MTU da rede Docker para 1400, conforme sugerido nos fóruns do Discourse, e reiniciei o Docker e o contêiner do Discourse.
Tentei tanto destroy/start quanto rebuild completo do aplicativo Discourse.
Verifiquei que Redis, PostgreSQL e todos os outros serviços estão rodando corretamente no contêiner.
Verifiquei que todos os registros DNS (MX, SPF, DKIM) estão configurados e propagados.
Testei de vários navegadores e dispositivos para descartar problemas do lado do cliente.
Enviei e recebi e-mails com sucesso usando a mesma conta Spacemail no Gmail (SMTP funciona fora do Discourse).
Ambiente:
Discourse rodando em Docker em um VPS Ubuntu 22.04 (Spaceship, Phoenix, EUA)
Todos os registros DNS estão corretos e propagados
Logs:
Nenhum erro nos logs do Discourse, exceto o tempo limite no envio de e-mail.
Redis e outros serviços estão rodando sem conflito.
Tempos limite do worker Unicorn coincidem com as tentativas de envio de e-mail.
Contexto adicional: Somente hoje, gastei cerca de 7 horas trabalhando com o suporte do Spacemail via chat ao vivo para solucionar este problema. Apesar dos esforços deles e da confirmação de que tudo está configurado corretamente do lado deles, o problema persiste.
O que eu preciso:
Algum conselho sobre o que mais verificar ou tentar?
Existe alguma maneira de obter logs de depuração SMTP mais detalhados do Discourse?
Alguém já encontrou um problema semelhante com Spacemail ou outro provedor?
Sim, segui o guia oficial de instalação do Discourse para Docker. Se precisar, posso fornecer detalhes sobre minha configuração ou quaisquer ajustes que tive que fazer para o meu ambiente de VPS.
Descrição: Este erro ocorre toda vez que o Discourse tenta enviar um e-mail. O Net::ReadTimeout indica que o Discourse está esperando uma resposta do servidor SMTP (Spacemail), mas não a recebe a tempo. Todos os testes de rede e TLS (openssl, telnet) são bem-sucedidos, e o SMTP funciona em clientes externos, portanto, o problema parece ser específico da comunicação ou autenticação SMTP do Discourse.
Se precisar do stacktrace completo ou de mais detalhes, posso fornecê-los.
Não tenho familiaridade alguma com esse vps. Se você está bem no início da sua configuração, pode tentar recomeçar com um novo servidor em vez de continuar batendo a cabeça contra a parede. Talvez tente um provedor diferente se isso ainda não funcionar.
Verificou com o suporte da Spacemail que não há restrições ou bloqueios do lado deles.
Confirmou que todos os registros DNS (MX, SPF, DKIM) estão corretos e propagados.
Enviou e recebeu e-mails com sucesso usando a mesma conta Spacemail no Gmail (SMTP funciona fora do Discourse).
Testou a conexão SMTP do VPS usando telnet e openssl (handshake TLS e banner SMTP recebidos com sucesso).
Alterou o MTU da rede Docker para 1400 e reiniciou o Docker e o contêiner Discourse.
Verificou que Redis, PostgreSQL e todos os outros serviços estão rodando corretamente no contêiner.
Tentou tanto destroy/start quanto rebuild completo do aplicativo Discourse após cada alteração.
Verificou os logs: apenas erros Net::ReadTimeout ao enviar e-mails, nenhum outro erro.
Certificou-se de que “Enable SMTP” está habilitado na interface de administração do Discourse.
Passou vários dias e cerca de 7 horas em chat ao vivo com o suporte da Spaceship/Spacemail para solucionar este problema.
Apesar de todas essas etapas, o Discourse ainda não consegue enviar e-mails e sempre retorna um erro Net::ReadTimeout.
root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet mail.spacemail.com 465
Tentando 198.177.121.32… Conectado a mail.spacemail.com.
Caractere de escape é ‘^\]’.
Obrigado pela sua sugestão. Meu provedor de caixa de correio (Spacemail) suporta oficialmente apenas a porta 465 com SSL para SMTP. No entanto, também testei a porta 587 com STARTTLS como parte da solução de problemas (juntamente com o suporte), mas o problema de tempo limite ainda persiste.
Eu fiz a instalação padrão duas vezes na semana passada com 2 provedores de e-mail diferentes, e sei que funciona. Suspeito que o spacemail não é adequado para e-mails transacionais reais.
Nada está bloqueado por parte do Spaceship ou Spacemail. Passei sete horas discutindo isso com o suporte deles ontem, e eles confirmaram que todas as portas necessárias estão abertas e o SMTP está funcionando do lado deles. Eles me enviaram para cá para mais solução de problemas. Além disso, a porta 2525 não é suportada pelo Spacemail, então não posso usá-la como alternativa.
Não sei se isso ajuda, já que você já verificou o acesso à porta via telnet, mas você poderia tentar enviar um e-mail com Swaks (deve haver um pacote Ubuntu disponível para ele). Acho bastante útil para depurar problemas de e-mail.
Talvez tente um serviço de e-mail transacional como Brevo ou Mailgun? Se funcionar, talvez queira usá-lo em vez disso. Pelo que vejo, como disse Lilly, não vejo nenhuma indicação de que seja um serviço de e-mail transacional.
Acabei de perguntar ao suporte deles e eles disseram:
Embora o Spacemail não suporte diretamente e-mails transacionais, você pode usar o protocolo SMTP para conectar sua caixa de correio Spacemail ao seu formulário de contato ou a qualquer ferramenta que envie e-mails automaticamente.
O problema será no lado da nave espacial. Porque tentei o GOOGLE SMTP, e funcionou e recebi um e-mail de teste.
Hoje, encaminhei isso para os técnicos da nave espacial através do suporte da nave espacial. Avisarei se precisar de mais detalhes diretamente de você.
Essa é (na minha opinião) uma abordagem equivocada por parte deles devido à bagunça absoluta em torno da porta 465.
A porta 465 (SMTPS) é MUITO frequentemente bloqueada em ambientes de VPS como uma medida anti-spam, pois é a porta histórica usada para comunicação TLS MTA-MTA. Atualmente, ela foi reclassificada para SUBMISSIONS (SUBMISSION + TLS implícito), mas não prevejo que os provedores de VPS a desbloqueiem devido ao fato de que sempre haverá MTAs ouvindo tráfego MTA-MTA nesta porta.
A porta 587 (SUBMISSION) é explicitamente a porta de submissão de e-mail MUA-MTA e é o que deve ser usado para submissão de e-mail autenticada em combinação com STARTTLS.
Não obstante meu desabafo sobre isso, vejo que você consegue se conectar a essa porta, então o que acontece se você enviar e-mails manualmente do VPS e do contêiner pela porta 465?