Acesso ao relé de recebedor de e-mail negado

Trying hard to enable replies by email using the mail-receiver container. I consistently get errors:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied

Why is this? How can I get into the mail-receiver container and examine the postfix config and debug it? I have disabled the postfix server on the system on which this is running, because of clash with port 25. Is that wrong?

I am reasonably sure DNS MX records are right, and this happens from any server sending mail inbound, I am using Amazon SES for outbound in the app container and that works fine.

I am a Discourse newbie and I dont know how to debug the ecosystem. I am an expert in postfix, but I don’t know how to configure it in this containerized universe.

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

I had this issue on a previously working mail-receiver which I’d made some changes to. I had thought I’d rebuild the container but clearly something hadn’t gone right as I got multiple ’ Relay access denied’ errors for all recipients. DNS was correctly configured.

In the end a good old git pull and launcher rebuild mail-receiver fixed it. Just posting this in case it works for anyone else.

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