Acesso ao relé de recebedor de e-mail negado

Suporte Instalação
1

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.

2

Primeiro, se você já tiver uma instância do Postfix em execução, não precisará realmente do contêiner de recebimento de e-mail.

Você pode configurar o Postfix como um receptor de e-mail para as respostas e configurar o Discourse para consultar esse e-mail.

Este howto de 2014 deve dar a você uma ideia suficiente para começar, e assumo que você consiga configurar o Postfix por conta própria.

3

Não concordo com isso de forma alguma. A vantagem do mail-receiver é que os e-mails são enviados via API, em vez de serem consultados. Há uma diferença significativa no tempo que leva para o e-mail chegar no Discourse usando o mail-receiver (minutos versus segundos).

Também há uma enorme diferença na simplicidade da configuração: o mail-receiver exige que apenas três linhas de um arquivo yml sejam atualizadas, enquanto o OOBE do postfix exige… mais.

Esse erro indica que os domínios de e-mail não correspondem.

Como você está ofuscando partes da mensagem, não podemos diagnosticar isso facilmente para você.

4

Se você está recebendo qualquer entrega de e-mail como esperado, isso implica que alguém está tentando usar seu servidor de e-mail para entregar mensagens a outro domínio. Por exemplo, se alguém apontou seu registro MX para o seu endereço IP. Ou, e nunca ouvi falar disso :wink: , alguém estava tentando maliciosamente fazer com que seu servidor de e-mail entregasse mensagens indesejadas.

Todos esses erros vêm do mesmo IP? Você consegue ver nos logs para qual domínio as mensagens errôneas são destinadas?

A coisa mais fácil a fazer é ignorá-los.

5

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.

6

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.

7

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.

8

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 @?

9

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

10

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

11

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

12

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.

13

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.

14

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

15

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 é.

16

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)

17

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

18

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.

19

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

20

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.