Problema de e-mail SMTP Net::Timeout

Olá, tenho tentado resolver meu problema com SMTP e os e-mails não estão sendo enviados. Quando executo o comando ./discourse-doctor, recebo um erro Net::Timeout.

Agradeço antecipadamente pela ajuda.

Seção SMTP do app.yml

DISCOURSE_SMTP_ADDRESS: plesk.oxide.host
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: no-reply@kyekillerbot.xyz
DISCOURSE_SMTP_PASSWORD: password
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opcional, padrão true)
DISCOURSE_SMTP_AUTHENTICATION: login

Já tentei usar telnet, e ele se conecta com sucesso ao domínio SMTP.

Você já tentou comentar essa linha? Acredito que a porta 465 não suporte STARTTLS.

Quanto à porta 465, consulte o RFC 8314:

Com base neste RFC, tanto a porta 465 quanto a 587 são portas válidas para um agente de envio de e-mail SMTP (MSA).

A porta 465 exige a negociação de TLS/SSL durante a configuração da conexão, enquanto a porta 587 usa STARTTLS caso se opte por negociar TLS.

O registro IANA foi atualizado para permitir o uso legítimo da porta 465 para esse fim.

Para um retransmissor de e-mail SMTP, apenas a porta 25 é utilizada, portanto, o STARTTLS é a única maneira de implementar TLS com retransmissão de e-mail.

@kyekiller, você deve considerar tentar esta configuração (definir como false) se for usar a porta 465:

DISCOURSE_SMTP_ENABLE_START_TLS: false

Comentar essa linha provavelmente não ajudará muito, pois, diretamente nos arquivos de configuração do contêiner Discourse, o padrão para essa configuração é true; assim, mesmo comentando essa linha, ela continuará definida como true:

#DISCOURSE_SMTP_ENABLE_START_TLS: true    # (opcional, padrão true)

Espero que ajude.

Veja também (do RFC):

Quando uma conexão TCP é estabelecida para o serviço “submissions” (porta padrão 465), um handshake TLS começa imediatamente. Os clientes DEVEM implementar o mecanismo de validação de certificados descrito em [RFC7817]. Uma vez estabelecida a sessão TLS, os dados do protocolo de Envio de Mensagens [RFC6409] são trocados como dados de aplicação TLS pelo restante da conexão TCP. (Nota: O nome do serviço “submissions” é definido na Seção 7.3 deste documento e segue a convenção usual de que o nome de um serviço sobreposto ao TLS Implícito consiste no nome do serviço usado sem TLS, com um “s” adicionado ao final.) O mecanismo STARTTLS na porta 587 é relativamente amplamente implantado devido à situação com a porta 465 (discutida na Seção 7.3). Isso difere dos serviços IMAP e POP, onde o TLS Implícito é mais amplamente implantado nos servidores do que o STARTTLS. É desejável migrar, ao longo do tempo, os protocolos principais usados por softwares MUA para o TLS Implícito, tanto para consistência quanto pelas razões adicionais discutidas no Apêndice A. No entanto, para maximizar o uso de criptografia para envio, é desejável suportar ambos os mecanismos para Envio de Mensagens sobre TLS durante um período de transição de vários anos. Como resultado, clientes e servidores DEVEM implementar tanto o STARTTLS na porta 587 quanto o TLS Implícito na porta 465 durante esse período de transição. Note que não há diferença significativa nas propriedades de segurança entre o STARTTLS na porta 587 e o TLS Implícito na porta 465, desde que as implementações estejam corretas e tanto o cliente quanto o servidor estejam configurados para exigir a negociação bem-sucedida de TLS antes do Envio de Mensagens.

Nota: Existem duas configurações padrão relacionadas ao TLS no Discourse:

# mecanismo de autenticação smtp
smtp_authentication = plain

# habilitar criptografia TLS para conexões smtp
smtp_enable_start_tls = true

# modo para verificar certificados do servidor smtp
# para desabilitar, defina como 'none'
smtp_openssl_verify_mode =

# forçar TLS implícito conforme RFC 8314 3.3
smtp_force_tls = false

Veja também: