Acceso denegado para reenvío de Mail-receiver

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 Me gusta

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 Me gusta

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 Me gusta

Tengo el mismo error con los informes de mail-receiver: Relay access denied (in reply to RCPT TO command).

La recepción de correo no funciona para la nueva instalación, pero ya he conseguido que esto funcione antes. Creo que todas las configuraciones son correctas, pero podría haberme saltado algo.

Esto generalmente significa que el correo se está entregando a un dominio que no es el que el destinatario está configurado para aceptar.

Lo tengo configurado para el mismo subdominio que el sitio de Discourse.

Para el valor del registro MX es “subdominio.dominio”, y el host debe ser solo “subdominio” o @?

¿Alguien sabe qué causa el error “Relay access denied”?

Ocurre cuando el dominio del destinatario no coincide con el dominio configurado en mail-receiver.yml.

1 me gusta

¿Es esa la dirección a la que estás enviando el correo?

La misma dirección, está funcionando ahora después de reconstruir el receptor de correo.

Creo que lo había reconstruido antes pero no funcionaba, bueno que ahora funciona.

¿Necesito permitir adicionalmente el puerto 25 para que mail-receiver funcione correctamente?

En este caso, funcionar correctamente significaría que los correos electrónicos entrantes que aparecen en .\launcher logs mail-receiver lleguen a la interfaz de administración de Discourse.

Sí, debes abrir el puerto 25. Eso podría añadirse a esta guía como una regla opcional.

1 me gusta

Bueno, no tengo 25 abiertas. Así que no.

Pero ufw status no es tan interesante. En cambio, nft list ruleset sí lo es.

1 me gusta

Actualización: Se aplicó ufw deny 25 y mail-reciver funciona correctamente (07/02/2025)

Puedo confirmar que esto es correcto, aunque cometí otro error. Se trata de mi segundo foro para implementar mail-receiver, y en el primero, el registro MX del dominio que recibe los correos Value era la DISCOURSE_BASE_URL.

Ahora recibo los correos en la interfaz de mi (segundo) foro, en lugar de solo en el primero :tada:

Nota: esta creencia de corrección puede deberse a no haber ejecutado ./launcher rebuild mail-receiver después de cambiar el yml (06/02/2015).

Imagino que no necesites permitir el puerto 25 en, por ejemplo, un firewall de panel de Azure o VPS, así que pre-Ubuntu

porque el valor del registro MX debería apuntar al sitio web, no al dominio de correo, interesante

La guía oficial menciona que el puerto 25 debe estar abierto:

Yo mismo tuve un problema con el receptor de correo porque olvidé abrir el puerto 25 en mi firewall. Añadir la regla resolvió el problema.

¿una mejor solución podría ser permitir solo la dirección IP relevante?

No se lo digamos a mi receptor de correo :wink:

La salida se realiza a través de Amazon SES. La entrada llega por mx al dominio del foro y ahora entra Docker.

La razón de esto es Docker y su forma interna de trabajar. Simplemente no le importa ufw. Si quieres una explicación detallada exacta, espera un segundo; una vez pregunté por qué Discourse no se preocupa por mi firewall, y la razón fue el tráfico de paquetes. Pero entender profundamente lo que está pasando no es lo mío. Para mí es suficiente que las cosas funcionen. Y créeme: ufw solo tiene abiertos los puertos 22, 80 y 443.

Supongo que citaste una situación en la que el receptor de correo también se encarga de enviar correos electrónicos usando postfix.

1 me gusta