Acceso denegado para reenvío de Mail-receiver

Estoy intentando activar las respuestas por correo electrónico utilizando el contenedor mail-receiver. Recibo consistentemente errores:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Acceso de retransmisión denegado

¿Por qué ocurre esto? ¿Cómo puedo acceder al contenedor mail-receiver para examinar la configuración de Postfix y depurar el problema? He desactivado el servidor Postfix en el sistema donde se está ejecutando debido a un conflicto con el puerto 25. ¿Es eso incorrecto?

Estoy bastante seguro de que los registros MX de DNS son correctos, y esto ocurre desde cualquier servidor que envíe correo entrante. Estoy utilizando Amazon SES para el correo saliente en el contenedor de la aplicación y eso funciona bien.

Soy nuevo en Discourse y no sé cómo depurar el ecosistema. Soy experto en Postfix, pero no sé cómo configurarlo en este entorno contenerizado.

Lo primero es lo primero: si ya tienes una instancia de Postfix en ejecución, realmente no necesitas el contenedor de recepción de correo.

Puedes configurar Postfix como receptor de correo para los correos de respuesta y configurar Discourse para consultar ese correo.

Este #cómo-hacerlo de 2014 te dará una idea suficiente para empezar, y asumo que podrás configurar Postfix por tu cuenta.

No estoy de acuerdo con esto en absoluto. La ventaja del receptor de correo es que los correos electrónicos se envían mediante la API en lugar de ser consultados. Hay una diferencia significativa en el tiempo que tarda un correo en llegar a Discourse usando el receptor de correo (minutos frente a segundos).

También hay una gran diferencia en la simplicidad de la configuración: el receptor de correo requiere actualizar solo tres líneas de un archivo yml, mientras que el OOBE de Postfix requiere… más.

Ese error implica que los dominios de correo no coinciden.

Como estás ocultando partes del mensaje, no podemos solucionar esto fácilmente por ti.

3 Me gusta

Si estás recibiendo algún correo tal como esperas, esto implica que alguien está intentando usar tu servidor de correo para enviar mensajes a otro dominio. Por ejemplo, si alguien apuntó su registro MX a tu dirección IP. O, y nunca había oído esto :wink:, alguien estaba intentando que tu servidor de correo entregara correo no deseado de manera malintencionada.

¿Son todos estos errores provenientes de la misma dirección IP? ¿Puedes ver en los registros a qué dominio iban dirigidos los mensajes erróneos?

Lo más sencillo es ignorarlo.

3 Me gusta

Tuve este problema en un mail-receiver que ya funcionaba y al que le había realizado algunos cambios. Pensé en reconstruir el contenedor, pero claramente algo salió mal, ya que obtuve múltiples errores de ‘Relay access denied’ para todos los destinatarios. DNS estaba configurado correctamente.

Al final, un buen y antiguo git pull seguido de launcher rebuild mail-receiver lo solucionó. Lo comparto por si sirve a alguien más.

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