Dificuldade em configurar SMTP no Discourse com Azure Communication Service

Olá a todos,

Tenho tido dificuldades em configurar o SMTP na minha instalação do Discourse, e tem sido um desafio considerável. Já explorei vários posts como este sem sucesso.

Aqui está a situação: suspeito que meus problemas estejam ligados ao formato e comprimento do nome de usuário e senha que sou obrigado a usar. Estou utilizando o Azure Communication Service para meu servidor SMTP, que exige uma configuração específica envolvendo um Azure Entra App (anteriormente Azure Active Directory).

Para ir direto ao ponto, o formato do nome de usuário se parece com isto (não são credenciais reais, apenas um exemplo):

<Nome do Recurso do Azure Communication Services>.<ID do Aplicativo Entra>.<ID do Tenant do Aplicativo Entra>

Aqui está um exemplo: my-communication-service.7d8233e0-c230-4468-a2de-1d03aa64bb71.49ba4f9c-3b18-43df-b5fd-5e203ba6e031

Para mais detalhes, confira este link.

Enquanto isso, a senha precisa aderir a um formato de segredo gerado pelo Azure, como:

b_C8Q~WjHH~MtFQptMj8wR1KroOZYigGy3A3Zc5M

Agora, eu consegui configurar isso funcionando perfeitamente em C# com credenciais semelhantes.

private static void SendMail()
{
    string smtpAuthUsername = "my-communication-service.7d8233e0-c230-4468-a2de-1d03aa64bb71.49ba4f9c-3b18-43df-b5fd-5e203ba6e031";
    string smtpAuthPassword = "a~C8Q~WjHH~MtFQptMj8wR1KroOZYigGy3A3Zc5M";

    string sender = "DoNotReply@my-domain.com";
    string recipient = "admin@my-domain";
    string subject = "You a chosen";
    string body = "One gorgeous body";
    string smtpHostUrl = "smtp.azurecomm.net";

    using (var client = new SmtpClient(smtpHostUrl))
    {
        client.Port = 587;
        client.Credentials = new NetworkCredential(smtpAuthUsername, smtpAuthPassword);
        client.EnableSsl = false;

        var message = new MailMessage(sender, recipient, subject, body);

        try
        {
            client.Send(message);
            Console.WriteLine("The email was successfully sent using Smtp.");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Smtp failed with the exception: {ex.Message}.");
        }
    }
}

No entanto, quando tento implementar essas configurações no Discourse, as coisas começam a dar errado. Aqui está o que configurei:

DISCOURSE_SMTP_ADDRESS: smtp.azurecomm.net
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: "my-communication-service.7d8233e0-c230-4468-a2de-1d03aa64bb71.49ba4f9c-3b18-43df-b5fd-5e203ba6e031"
DISCOURSE_SMTP_PASSWORD: "b_C8Q~WjHH~MtFQptMj8wR1KroOZYigGy3A3Zc5M"
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_DOMAIN: my-domain.com
DISCOURSE_NOTIFICATION_EMAIL: DoNotReply@my-domain.com

No entanto, apesar dessa configuração, continuo recebendo um erro de autenticação, conforme o trecho do log:

Job exception: Net::SMTPAuthenticationError

Eu experimentei encapsular o nome de usuário e a senha de várias maneiras — aspas simples, aspas duplas ou até mesmo deixá-los de fora. Mas o resultado permanece o mesmo.

Qualquer dica ou sugestão sobre o que mais eu poderia tentar seria muito apreciada.

1 curtida

Olá, encontrei o mesmo problema com o Azure Communication Service.

De acordo com a Microsoft Docs, acho que pode ser que o Microsoft Entra precise ser suportado pelo aplicativo, mas o Discourse infelizmente não suporta isso.

Enquanto isso, estou ansioso por quaisquer outros métodos disponíveis também.

Encontrei o mesmo problema e descobri este tópico em uma pesquisa na web, e parece que (assim como com os servidores de e-mail do Microsoft 365 antes de eles desativarem a autenticação baseada em senha) apenas AUTH LOGIN é suportado, não AUTH PLAIN que é o padrão no Discourse no momento em que este texto foi escrito.

Definir DISCOURSE_SMTP_AUTHENTICATION: login na configuração do contêiner faz o e-mail funcionar. Vale notar também que, por padrão, o único e-mail ‘de’ permitido é o padrão DoNotReply@domain.example - se você não definir isso, seus e-mails serão rejeitados com “550 5.3.5 Email sender’s username is invalid”.

4 curtidas

Parece que isso foi corrigido agora