Estou executando uma configuração de teste (atualmente 2.4.0.beta4) em casa, em um mini-PC local com Ubuntu 16.04 LTS. A instalação foi feita usando o excelente guia de instalação de 30 minutos. O sistema possui um FQDN. O envio de e-mails por meio de uma caixa de correio do meu provedor de internet, usando SMTP na porta 587 com autenticação simples, funcionou sem problemas por mais de um ano.
Acabei de perceber que não recebi nenhuma notificação por e-mail há algum tempo, como “nova versão disponível”. Verificando Admin > E-mails > Ignorados, vejo que tudo está recebendo o seguinte erro:
550-Bad HELO: localhost.localdomain não existe - Consulte o RFC 2821
Olhando para trás na caixa de correio, isso pode ter começado com a versão 2.4.0.beta2. Mas também pode ter sido alguma mudança de política do meu provedor de internet por volta da mesma época (final de julho de 2019). Não tenho certeza de por onde começar. De onde vem esse localhost.localdomain? Durante a instalação, precisei apenas editar o app.yml, e ele mostra meu FQDN corretamente em DISCOURSE_HOSTNAME:
Eu nunca tinha ouvido falar do Mailgun. Você se refere ao mailgun.com, o “Serviço de API de E-mail Transacional”? Para te dar uma ideia do meu nível de conhecimento: eu sei vagamente o que é uma API, mas não saberia como usá-la. Mas eu poderia tentar usar SMTP para outra caixa de entrada em um provedor de internet diferente. Vou reportar aqui amanhã.
O Mailgun fornecerá credenciais SMTP se você se cadastrar. Tenho certeza de que você conseguirá descobrir apenas seguindo as instruções deles durante o cadastro.
@itsbhanusharma, @jtbayly Obrigado! Consegui enviar uma mensagem de teste pelo Mailgun. Então o problema era uma nova política no servidor SMTP do meu provedor de internet. Talvez eu continue usando o Mailgun.
Fiz mais algumas pesquisas, pois não posso usar o Mailgun para nosso fórum de produção.
No cabeçalho dos e-mails recebidos via Mailgun, ainda vejo:
Received: from localhost.localdomain
O HELO é o primeiro comando no diálogo SMTP (fonte).
Deveria ser algo como:
HELO discourse.mydomain.tld
Alguns servidores SMTP, como o Postfix, têm uma opção para verificar isso contra o endereço IP do cliente. O localhost.localdomain resolve para o endereço IP do servidor SMTP; provavelmente está no arquivo hosts dele. Parece que os provedores de internet (ISPs) estão ativando isso em sua batalha contra spammers.
Funciona com o Mailgun porque o Mailgun não executa essa verificação. Mas ainda assim é um “HELO ruim”.
Para comparar, enviei um e-mail usando um cliente de e-mail (Sylpheed) no mesmo sistema. Isso funciona, mesmo com a caixa de correio do meu ISP, e parece usar:
HELO HL80L
HL80L é o nome da minha rede local. Ainda não é um FQDN, mas pelo menos não aparece como algo obviamente falso para o servidor do meu ISP.
Então, talvez isso seja algo que precise ser melhorado. Mas aviso: não sou especialista em SMTP.
A propósito, consegui fazê-lo funcionar novamente através da caixa de correio do meu provedor de internet, colocando um MTA intermediário como retransmissor. É um aplicativo baseado no Postfix no meu NAS. Ele usa HELO mydomain.tld
Vou verificar se algo foi quebrado durante a migração para o Debian 10 ou a atualização para o Rails 6. Enquanto isso, definir DISCOURSE_SMTP_DOMAIN no app.yml deve funcionar. Acho que devemos usar como padrão o valor de DISCOURSE_HOSTNAME se o domínio SMTP não estiver definido explicitamente.
Obrigado, @gerhard! DISCOURSE_SMTP_DOMAIN não estava presente no meu app.yml, mas respirei fundo, adicionei e, sim, isso resolveu. Posso usar a caixa de correio do meu provedor de internet novamente. No lado receptor, encontro no cabeçalho:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
Entretanto, aprendi que tanto o RFC 2821 quanto seu sucessor RFC 5321, seção 4.1.4 afirmam que:
Um servidor SMTP PODE verificar se o argumento do nome de domínio no comando EHLO corresponde realmente ao endereço IP do cliente. No entanto, se a verificação falhar, o servidor NÃO DEVE recusar a aceitação de uma mensagem com base nisso. As informações capturadas na tentativa de verificação são para fins de registro e rastreamento. Observe que essa proibição aplica-se apenas à correspondência do parâmetro ao seu endereço IP; consulte a Seção 7.9 para uma discussão mais extensa sobre a rejeição de conexões ou mensagens de e-mail recebidas.
Mas muitos MTAs, como Postfix e Exim, ainda parecem ter uma configuração opcional para fazer isso. Possivelmente, os administradores estão ativando isso na batalha contínua contra spam.
