Acesso ao relé de recebedor de e-mail negado

Estou tentando ativar as respostas por e-mail usando o contêiner mail-receiver. Consistentemente obtenho erros:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Acesso de retransmissão negado

Por que isso acontece? Como posso acessar o contêiner mail-receiver, examinar a configuração do Postfix e depurá-la? Desativei o servidor Postfix no sistema onde isso está sendo executado devido a um conflito na porta 25. Isso está errado?

Tenho razoável certeza de que os registros DNS MX estão corretos, e isso ocorre a partir de qualquer servidor enviando e-mails de entrada. Estou usando o Amazon SES para e-mails de saída no contêiner do aplicativo, e isso funciona bem.

Sou iniciante no Discourse e não sei como depurar o ecossistema. Sou especialista em Postfix, mas não sei como configurá-lo neste universo containerizado.

First thing first, if You already have a postfix instance running, You don’t really need the mail receiver container.

You can configure postfix as an email receiver for the replies email and configure discourse to poll that email.

This howto from 2014 shall give you enough idea to get started and I assume you can figure postfix on your own.

I don’t agree with this at all, the benefit of the mail-receiver is that emails are pushed via the API, rather than polled. There’s a significant difference in the time taken for email to arrive in Discourse using the mail-receiver (minutes versus seconds).

There’s also a huge difference in simplicity in configuration, mail-receiver requires three lines of a yml file be updated, the postfix OOBE requires… more.

That error implies the mail domains don’t match.

As you’re obfuscating parts of the message we can’t easily troubleshoot this for you.

3 curtidas

If you’re getting any mail delivered as you expect, then this implies that someone is trying to use your mail server to deliver mail to some other domain. If, for example, someone pointed their MX record to your IP address. Or, and I’ve never heard of this :wink: , someone was trying to nefariously have your mail server deliver unwanted mail.

Are all of these errors from the same IP? Can you see in the logs what domain they the errant messages are intended for?

The easiest thing to do is to ignore it.

3 curtidas

Tive esse problema em um mail-receiver que já funcionava antes, mas no qual fiz algumas alterações. Achei que bastaria reconstruir o container, mas claramente algo não saiu como esperado, pois recebi múltiplos erros de ‘Relay access denied’ para todos os destinatários. O DNS estava configurado corretamente.

No final, um bom e velho git pull seguido de launcher rebuild mail-receiver resolveu o problema. Estou compartilhando isso caso funcione para mais alguém.

2 curtidas

Tenho o mesmo erro com relatórios do mail-receiver: Relay access denied (in reply to RCPT TO command).

O recebimento de e-mails não está funcionando para a nova instalação, mas já consegui fazer isso funcionar antes. Acredito que todas as configurações estão corretas, mas posso ter perdido algo.

Isso geralmente significa que o e-mail está sendo entregue a um domínio que não é o que o destinatário está configurado para aceitar.

Eu o configurei para o mesmo subdomínio do site do Discourse.

Para o valor do registro MX, é “subdominio.dominio”, e o host deve ser apenas “subdominio” ou @?

Alguém sabe o que causa o erro “Relay access denied”?

Ocorre quando o domínio do destinatário não corresponde ao domínio configurado em mail-receiver.yml.

1 curtida

É esse o endereço para o qual você está enviando o e-mail?

O mesmo endereço, está funcionando agora após a reconstrução do receptor de e-mail.

Acredito que já tinha reconstruído isso antes, mas não estava funcionando, que bom que funciona agora.

Preciso permitir adicionalmente a porta 25 para que o mail-receiver funcione corretamente?

Neste caso, funcionar corretamente significaria que os e-mails de entrada que aparecem em .\launcher logs mail-receiver chegam à interface de administração do Discourse.

Sim, você precisa abrir a porta 25. Isso pode ser adicionado a este guia como uma regra opcional.

1 curtida

Bem, eu não tenho 25 abertas. Então, não.

Mas ufw status não é tão interessante. Em vez disso, nft list ruleset é.

1 curtida

Atualização: ufw deny 25 foi aplicado e mail-reciver funciona bem (07/02/2025)

Posso confirmar que isso está correto, embora eu tenha cometido outro erro. Isso é sobre meu segundo fórum para implementar mail-receiver, e no primeiro eu tinha o registro MX do domínio que recebe os e-mails como Value para o DISCOURSE_BASE_URL

Agora estou recebendo os e-mails na interface do meu (segundo) fórum, em vez de apenas no meu primeiro :tada:

Observação: essa crença de correção pode ter sido devido a não executar ./launcher rebuild mail-receiver após alterar o yml (06/02/2015)

Imagino que você não precise permitir a porta 25 em um firewall de painel Azure ou VPS, por exemplo - então, pré-Ubuntu

porque o valor do registro MX deve apontar para o site, não para o domínio de e-mail, interessante

O guia oficial menciona que a porta 25 deve estar aberta:

Eu mesmo tive um problema com o receptor de e-mail porque esqueci de abrir a porta 25 no meu firewall. Adicionar a regra resolveu o problema.

uma solução melhor seria permitir apenas o endereço IP relevante?

Não vamos contar isso para o meu receptor de e-mail :wink:

A saída está acontecendo usando o Amazon SES. A entrada vem por mx para o domínio do fórum e agora o docker entra em ação.

O motivo para isso é o docker e sua maneira interna de funcionar. Ele simplesmente não se importa com o ufw. Se você quiser uma explicação exata e detalhada, espere um segundo — perguntei uma vez por que o Discourse não se importa com meu firewall, e o motivo foi o tráfego de pacotes. Mas entender profundamente o que está acontecendo não é minha praia. Para mim, é o suficiente que as coisas funcionem. E confie em mim: o ufw está aberto apenas nas portas 22, 80 e 443.

Acho que você citou uma situação em que o receptor de e-mail cuida do envio de e-mails também usando postfix.

1 curtida