Não consigo enviar e-mail - problema com a porta 465

[schungx (Stephen Chung)]

Gostaria de alterar o provedor de SMTP, mas não parece funcionar, embora tenha certeza de que o servidor pode enviar e-mails.

Tenho isto em app.yml:

  DISCOURSE_SMTP_ADDRESS: <<SMTP SERVER>>
  DISCOURSE_SMTP_PORT: 465
  DISCOURSE_SMTP_USER_NAME: <<USER>>
  DISCOURSE_SMTP_PASSWORD: <<PASSWORD>>

Usando telnet <<SMTP SERVER>> 465 conecta OK, mas quando tento enviar e-mails, o Discourse retorna com:

ERROR - Net::ReadTimeout with #<Socket:(closed)>

Alguém tem alguma dica sobre o que preciso configurar?

Verifiquei o servidor com base neste tópico: Troubleshoot email on a new Discourse install

Parece conectar ao servidor e enviar um e-mail de teste corretamente se eu fizer isso manualmente:

> sudo ./launcher enter app
root@support-app:/var/www/discourse# openssl s_client -connect mail.xxxxxxxx.com:465
  :
  :
  quantidade massiva de lixo
  :
  :
220 xxxxxxx.com Anti-spam GT for Coremail System (mispb-6da2110f-64b0-4d67-acf1-2d302bd594f9-xxxxxxx.com[20220915])
EHLO mail.xxxxxxxxx.com
250-mail
250-PIPELINING
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-coremail 1Uxr2xKj7kG0xkI17xGrUDI0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UrpDiNKUCa0xDrUUUUj
250-STARTTLS
250-SMTPUTF8
250 8BITMIME
AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
235 Authentication successful
mail from: <xxx@xxxxxx.com>
250 Mail OK
rcpt to: <xxxx@xxxxxxx.com>
250 Mail OK
data
354 End data with <CR><LF>.
content

.
250 Mail OK queued as AQAAfwBXr9nSGHdj3hEgAA--.7073S2

[RGJ (Richard - Communiteq)]

@schungx

Parece conectar ao servidor e enviar um e-mail de teste corretamente se eu fizer isso manualmente:

Quanto tempo leva para a saída aparecer?

SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow

Hello, since view weeks sending mail from my Discourse instance fails. The SMTP settings are unchanged, curl test is still working but notably slow. The smtp server from our hoster (that we need to send mails with) has a consistent send time of 7 seconds. cat testmail | curl -vvv --url 'smtp://smtp.<HOST>:587' --mail-from mail@<DOMAIN> --mail-rcpt <ME> --user "mail@<DOMAIN>:<PW>" -T - % Total % Received % Xferd Average Speed Time Time Time Current …

[schungx (Stephen Chung)]

@RGJ

Quanto tempo leva para a saída aparecer?

Quase imediatamente depois que eu envio um comando.

EDITAR: Existe uma maneira de obter logs mais detalhados para descobrir qual etapa está causando o erro?

[pfaffman (Jay Pfaffman)]

É provável que a porta de saída esteja sendo bloqueada pelo seu provedor de hospedagem. Se você estiver usando algum serviço como o Mailgun (ou a maioria dos outros), a porta 2525 deverá funcionar. Se for um servidor de e-mail que você gerencia, você pode configurá-lo para escutar em outra porta (como a 2525).

Ou (provavelmente o mais difícil) você pode abrir um ticket com quem hospeda seu servidor e pedir para eles abrirem a porta.

[schungx (Stephen Chung)]

Bem, considerando que posso ./launcher enter app e então openssl conectar ao servidor de e-mail, fazer login via SMTP e enviar um e-mail com sucesso de dentro do contêiner discourse, duvido que seja a porta que não funciona…

[schungx (Stephen Chung)]

Eu rastreeei o código e parece que EHLO nem foi alcançado. O servidor SMTP está conectado, mas o handshake SSL parece estar faltando, então o servidor se desconecta e o Discourse não recebe nenhuma resposta, daí o erro.

Portanto, suspeitei que o suporte da porta 465 parece ter um bug (ele usa SSL por padrão, mas acho que o Discourse não reconhece isso), então provavelmente a conexão SSL nunca é estabelecida.

Mudar para a porta 25 parece pelo menos eliminar o erro, embora eu ainda não esteja recebendo nenhum e-mail enviado…

EDIT: Posso confirmar que a porta 25 funciona corretamente (assim como a 587, mas infelizmente meu servidor smtp não expõe a 587).

Eu não estava recebendo nenhum e-mail antes devido ao fato de que o endereço IP do servidor Discourse foi temporariamente colocado na lista negra pelo servidor smtp por causa de muitas tentativas falhas.

[RGJ (Richard - Communiteq)]

Acho que você está certo.

E, ao que parece, você não é o primeiro… ao pesquisar por DISCOURSE_SMTP_PORT 465, encontrei um monte de problemas semelhantes.

• Not able to send email Net::ReadTimeout - #18 by Stranik
• Email not working but i can access smtp server from container
• DigitalOcean + Siteground Email via port 465 won’t work (2525 will work)
• Problem with SMTP configuration
• Post-install, Curl can send email, but Discourse cannot. Help to fix?
• Mail problem on discourse with reverse proxy
• Can't setup SMTP with SSL/TLS
• SMTP email issue Net::Timeout - #3 by neounix

O último contém um link para a (possível?) solução.

Com este patch, é possível definir
DISCOURSE_SMTP_FORCE_TLS=true para usar TLS implícito na porta 465

[JammyDodger]

Também vi vários tópicos sobre o ‘problema 465’. No entanto, minha depuração de e-mail para qualquer coisa além do óbvio não é ótima, então tenho citado o guia de solução de problemas:

@Discourse

Seleção da porta SMTP de e-mail (Usando 465?)

A capacidade de AUTENTICAR usando ‘telnet’ é extremamente importante em seus primeiros passos de solução de problemas de e-mail.

A porta 465 (SMTP sobre SSL) está em grande parte obsoleta em favor do STARTTLS na porta 25. Pode ser necessário tentar portas alternativas, como porta 2525 ou a porta 587 (Envio de E-mail) quando as coisas não parecem funcionar como esperado.

Há algo que possamos adicionar a isso para ajudar as pessoas?

[RGJ (Richard - Communiteq)]

@JammyDodger

Há algo que possamos adicionar a isso para ajudar as pessoas?

Bem, se o @schungx puder confirmar que DISCOURSE_SMTP_FORCE_TLS=true é de fato uma solução, podemos adicioná-lo.

[schungx (Stephen Chung)]

@RGJ

Bem, se @schungx puder confirmar que DISCOURSE_SMTP_FORCE_TLS=true é realmente uma solução, podemos adicioná-la.

Vou tentar imediatamente!

EDIT: @RGJ Posso confirmar que DISCOURSE_SMTP_FORCE_TLS: true em app.yml resolveu o problema com sucesso!

Sugiro um aviso em negrito dizendo Se você usa a porta 465, defina DISCOURSE_SMTP_FORCE_TLS: true, ou o Discourse não deveria ser inteligente o suficiente para detectar isso?