Então, se o teste do openssl funciona, mas o teste de conexão executado pelo discourse-doctor ainda falha ao usar essas configurações, qual é o próximo passo? Mesmo com o teste do openssl funcionando, minha conexão do Discourse ainda falha com 504 5.7.4 Tipo de autenticação não reconhecido… Presume-se que o método de autenticação LOGIN não esteja sendo reconhecido. Tentei adicionar DISCOURSE_SMTP_AUTHENTICATION: login ao arquivo app.yml, mas isso não ajudou.
Só para constar, eis o que descobri. Entrei na imagem do Docker e comecei a mexer no script lib/tasks/emails.rake e no arquivo config/discourse.conf. Algumas horas depois, após tentar todas as combinações possíveis de smtp.office365.com e .mail.protection.outlook.com com AUTH login e AUTH plain, descomentei o bloco acima do início do SMTP.
# Gostaríamos de fazer isso, mas o Net::SMTP falha ao usar starttls
#Net::SMTP.start(smtp[:address], smtp[:port]) do |s|
# s.starttls if !!smtp[:enable_starttls_auto] && s.capable_starttls?
# s.auth_login(smtp[:user_name], smtp[:password])
#end
Executar isso como estava resultou em um timeout de leitura.
Modificar dessa forma — chamando new em vez de start — resultou em um envio bem-sucedido.
Net::SMTP.new(smtp[:address], smtp[:port]) do |s|
s.enable_starttls
s.auth_login(smtp[:user_name], smtp[:password])
end
Essa é minha primeira experiência com Ruby, rake e afins. Não consigo explicar por que funciona ou se é algo “bom” para casos gerais.
J.
Ah, também nunca consegui fazer funcionar com o my_domain.mail.protection.outlook.com nas portas 25 ou 587; o que funcionou foi smtp.office365.com:587.
Eu utilizo o socketlabs.com como meu serviço de entrega de e-mail e tive um problema semelhante. No meu caso, a solução foi editar o arquivo lib/tasks/emails.rake da seguinte forma:
Alterar a linha: Net::SMTP.start(smtp[:address], smtp[:port], 'localhost', smtp[:user_name], smtp[:password])
para Net::SMTP.start(smtp[:address], smtp[:port], 'localhost', smtp[:user_name], smtp[:password], smtp[:authentication])
Sem essa alteração, o DISCOURSE_SMTP_AUTHENTICATION: login não é passado para o código SMTP de nível inferior.
Eu não testei se o código modificado ainda funciona para outros métodos de autenticação, mas isso resolve o problema para autenticação login.
Posso confirmar que adicionar smtp[:authentication]
à chamada Net::SMTP.start e definir DISCOURSE_SMTP_AUTHENTICATION: login
no app.yml resolve o problema na página de teste de e-mail.
Acredito que os e-mails regulares são enviados pela biblioteca mail, e definir DISCOURSE_SMTP_AUTHENTICATION: login
no app.yml é suficiente para que a biblioteca funcione corretamente.
Ainda assim, acredito que lib/tasks/emails.rake deveria ser corrigido para usar a configuração DISCOURSE_SMTP_AUTHENTICATION. Isso economizaria alguma depuração desnecessária.
Como uma atualização geral sobre este problema, a Microsoft está no processo de desativar a autenticação legada para SMTP e POP3, o que vai complicar as coisas se você estiver usando o O365 como provedor de e-mail. A política padrão aplicada agora é proibir a autenticação SMTP, e você precisa habilitá-la por caixa de correio. Espero que isso seja útil — passei a manhã de ontem batendo a cabeça contra a parede com isso.
É realmente uma pena, especialmente em relação ao POP, pois configurar o recebimento de e-mails vai ficar muito mais difícil, a menos que o Discourse adicione suporte a IMAP para caixas de correio de entrada.
Há uma solução simples para o recebimento de e-mails que inclui um container para recebê-los. Antigamente, era chamada de “straightforward”, mas alguém se opôs ao nome e ela foi alterada, e não consigo encontrá-la mais.
Bem, executar seu próprio servidor de e-mail deve ser considerado um recurso de último caso em qualquer situação. Acredito que era “entrega direta”, tente pesquisar por isso.