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.
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.
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 , 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?
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.
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.
¿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.
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
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).
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.
, someone was trying to nefariously have your mail server deliver unwanted mail.
