Erro SMTP: deve emitir um comando STARTTLS primeiro

Suporte Instalação
1

Estou tentando configurar o Discourse 2.7.0.beta4 com o serviço SMTP do Mailersend.

Após executar ./discourse-doctor, obtive o erro abaixo.

Erro SMTP: É necessário emitir um comando STARTTLS primeiro

Esta é minha configuração atual no app.yml referente ao SMTP.

  DISCOURSE_SMTP_ADDRESS: 'smtp.mailersend.net'
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: username@subdomain.domain.org
  DISCOURSE_SMTP_PASSWORD: mypasswordhere
 #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (opcional, padrão true)
 #DISCOURSE_SMTP_AUTHENTICATION: login
 #DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Já tentei descomentar e definir DISCOURSE_SMTP_ENABLE_START_TLS explicitamente como true, mas o erro persiste. O mesmo ocorreu com DISCOURSE_SMTP_AUTHENTICATION: login.

Após qualquer alteração no arquivo YML, estou reiniciando o sistema com este comando:

./launcher destroy app; ./launcher start app

Alguma dica sobre o que está acontecendo?

Obrigado desde já!

2

Fiz algumas alterações no discourse-setup recentemente e também uma alteração na tarefa rake que você está usando (que acredito que ainda não foi mesclada).

Se quiser me dar acesso ao seu servidor, darei uma olhada.

2 curtidas
3

Como mencionei via MP, não posso conceder acesso ao servidor devido a preocupações de segurança. Mas muito obrigado a @pfaffman pela ajuda e por tentar resolver esse problema.

Deixe-me adicionar mais contexto a esse problema: um administrador anterior instalou o Discourse com o serviço SMTP do Mailgun, mas ele parou de funcionar e eu não tenho acesso a essa conta.

Como disse, estou tentando configurá-lo agora com Mailersend. Li este tópico [1] e outros sobre STARTTLS aqui no fórum, mas não tenho certeza de como implementar as alterações necessárias.

Também tentei a configuração abaixo, mas o erro persiste:

DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Se estiver relacionado a alguma atualização recente, talvez seja melhor considerar um downgrade?

[1] Can't send email with certificate issue - #3 by supermathie

1 curtida
4

Conseguiu fazer isso funcionar?

5

Não, decidi mudar para outro serviço de e-mail. Agora está funcionando bem com Mailjet.

1 curtida
6

Estou enfrentando um problema semelhante. Ontem depurei o envio de e-mails em uma nova instância do Discourse por cerca de três horas, sem sucesso. Estou tentando enviar e-mails via Fastmail com STARTTLS na porta 587. Outros serviços estão funcionando com as mesmas credenciais.

Não recebo o erro “Must issue a STARTTLS command first” com estas configurações:

DISCOURSE_SMTP_ADDRESS: 'smtp.fastmail.com'
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: 'myuser@fastmail.fm'
DISCOURSE_SMTP_PASSWORD: 'mypass'
DISCOURSE_SMTP_ENABLE_START_TLS: true

…seguido por um ./launcher rebuild app, quando executo ./discourse-doctor e envio um e-mail, recebo um erro 500 5.5.1 Invalid command em resposta.

Hoje comecei a rastrear a comunicação com tcpdump, e notei que o Discourse não parece usar STARTTLS. Veja o que acontece quando envio um e-mail de recuperação do Grafana:

< 220 smtp.fastmail.com ESMTP ready
> EHLO 9b5ba1569f77
< 250-smtp.fastmail.com
< 250-PIPELINING
< 250-SIZE 71000000
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 STARTTLS
> STARTTLS
< ...[encrypted]

Mas com o Discourse, isso acontece:

< 220 smtp.fastmail.com ESMTP ready
> EHLO localhost
< 250-smtp.fastmail.com
< 250-PIPELINING
< 250-SIZE 71000000
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 STARTTLS
> AUTH PLAIN [redacted]
< 500 5.5.1 Invalid command

Então, parece que o Discourse está enviando minhas credenciais pela internet em texto puro, mesmo com STARTTLS habilitado nas configurações? Isso é um bug?

Também notei que quando executo ./discourse-doctor, o resumo “YML SETTINGS” no topo lista os seguintes itens:

==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=forum.[redacted]
SMTP_ADDRESS=smtp.fastmail.com
DEVELOPER_EMAILS=sysadmin@[redacted]
SMTP_PASSWORD=[redacted]
SMTP_PORT=587
SMTP_USER_NAME=[redacted]@fastmail.fm
LETSENCRYPT_ACCOUNT_EMAIL=

No entanto, não há menção de DISCOURSE_SMTP_ENABLE_START_TLS, mesmo que esteja definido em app.yml. Não tenho certeza se este problema está relacionado.

2 curtidas
7

Ah, isso é estranho. Criei uma conta de usuário manualmente (através de rake admin:create) e depois fiz o login, e de repente as notificações por e-mail funcionaram. No entanto, o envio através de discourse-doctor ainda falha.

Talvez o discourse-doctor esteja quebrado?

1 curtida
8

Desculpe. Sei como isso pode ser frustrante.

É possível. Ele faz algumas coisas para tentar depurar qual é o problema, então pode ser que a lógica que ele está usando esteja quebrada para o seu caso.

Há também uma tarefa rake que provavelmente teria sido uma aposta melhor para você.

    rake emails:test[x@y.com]

Você estava seguindo Solução de problemas de e-mail em uma nova instalação do Discourse?

2 curtidas
9

Eu não estava ciente desse comando, ele parece útil mesmo! O resultado é o mesmo, no entanto:

root@app:/var/www/discourse# rake emails:test redacted@example.com
Testing sending to  using smtp.fastmail.com:587, username:myuser@fastmail.fm with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR
500 5.5.1 Invalid command

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!
Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
=======================================================================================

Quando olho o tcpdump, novamente vejo que ele está enviando as credenciais AUTH PLAIN em texto puro, sem criptografia STARTTLS.

Eu olhei essa página, sim.

No entanto, com base no tcpdump, isso parece um bug nas ferramentas de diagnóstico para mim, porque o STARTTLS não está sendo usado, embora a configuração esteja habilitada em app.yml. (O próprio aplicativo Discourse usa STARTTLS. Presumo que muitos provedores de e-mail também permitirão o envio de e-mails não criptografados, então esse problema só surgirá se alguém usar as ferramentas de diagnóstico e usar um provedor que não aceita envio não criptografado via SMTP.)

1 curtida
10

Ah. Parece que essa tarefa do rake é a mesma que o discourse-doctor chama. Desculpe por isso.

Talvez alguém possa dar uma olhada em como tornar essa tarefa do rake mais parecida com o processo real, ou pelo menos não desistir se suas tentativas de descobrir o que está acontecendo forem desajeitadas. Um bom primeiro passo seria dizer “Bem, XXX parece quebrado, mas vamos tentar mesmo assim…”

1 curtida