Quizás, como buen administrador que revisa los logs de vez en cuando (¿verdad?), hayas visto en los de tu servidor de correo que hay bastantes errores de «Relay access denied«. O quizás en las gráficas que los muestran.
Este error se produce, resumiendo mucho, cuando se intenta enviar un mensaje a un servidor que no acepta correos para el dominio destino (por ejemplo, si intentas enviar correo con destino @gmail.com a los servidores de @outlook.com) o cuando no hay autenticación cuando se intenta enviar correo saliente. Centrándonos en el primer caso, no debería darse con una configuración de DNS correcta (el registro MX) y teniendo el dominio configurado en Postfix como destino, pero suele verse (dominios dados ya de baja de la plataforma, registros MX cacheados…etc), sobre todo si hay altas y bajas de dominios a lo largo del tiempo.

Hasta la versión 2.10 de Postfix, la política por defecto era rechazar este tipo de mensajes con un error permanente (errores de tipo 5XX), por lo que los servidores no reintentaban su envío durante varios días hasta que expirasen.
A partir de dicha versión, se añade la directiva smtpd_relay_restrictions que controla las restricciones de relay. Esto se hace, como bien se indica en la página de ayuda de Postfix, debido a que algunas configuraciones permitían el open relay sin saberlo, es decir, haciendo un PERMIT bajo smtpd_recipient_restrictions a una condición muy amplia (por ejemplo, que el FROM o el parámetro del comando HELO fuesen uno determinado). Para evitarlo, se añade la restricción para relay, de tal forma que aparte de las restricciones anteriores y para evitar esos fallos, quién envía hacia o a través de nuestro servidor se controla con:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Por defecto, podrán enviar a cualquier destino las redes indicadas en la directiva mynetworks y los usuarios autenticados; el resto de destinos no autorizados (dominios no configurados en mydestination, dominios no incluidos en relay_domains…etc), serán rechazados temporalmente. Es ahí donde se provoca que esos correos rechazados por «Relay access denied» lo sean de forma temporal y no permanente. Cambiando el «defer_unauth_destination» por «reject_unauth_destination«, haría que ese comportamiento cambiase y los rechazos fueran definitivos.

Esto evitará reintentos innecesarios (lo ideal es cambiar los MX de los dominios una vez que estemos seguros que el servicio de correo está bien configurado para aceptar sus correos, y no al revés) por parte de los servidores origen, que en caso de ser plataformas grandes, puede ser bastante tráfico.

He tenido dudas a la hora de poner un título a este post. El concepto «desaparición» puede que sea algo amarillista, quizás «pérdida de rastro de mensajes» pudiese hacer más justicia a lo que voy a comentar, pero bueno, queda más «Expediente X» el actual ;-)

Todo esto viene debido a que buscando en los logs un determinado mensaje enviado, no se sabía (a priori) qué había pasado con él. Esto es lo que creo (y supongo que todo el mundo cree) que no debe hacer un log, no dejar evidencias de lo que pasa.

Juntar MailScanner con Postfix siempre ha sido muy criticado, sobre todo en la lista de usuarios de Postfix. No hay una interfaz que pase los mensajes recibidos en el demonio smtpd de Postfix a MailScanner, como sucede con otras pasarelas de correo como amavids-new, sino que cuando llegan los mensajes vía SMTP, pasan a la cola hold donde quedan retenidos y MailScanner, con un proceso batch, procede a recogerlos de ahí regularmente para analizarlos.

Sigue leyendo →