Blog

Archive for Postfix

Cómo rebotar un mensaje en la cola de postfix con Core-Admin

[extoc]

Cómo rebotar un mensaje de la cola de Postfix con Core-Admin

En el caso de que quieran rebotar un mensaje de la cola de postfix, generando un mensaje de rebote, y sin tener que esperar a que llegue el máximo tiempo de cola (queue max life time), entonces puede utilizar el siguiente comando proporcionado por el paquete core-admin-tools.

Prerequisitos

Instale/actualice el paquete core-admin-tools si no dispone del comando crad-bounce.pyc. Use:

>> crad-update.pyc -u
>> crad-update.pyc -g

Comando para rebotar un mensaje de la cola de Postfix con Core-Admin

>> crad-bounce.pyc -b <postfixqueueid>

En tal caso, encuentre el ID del mensaje a rebotar usando mailq como de costumbre. Por ejemplo:

>> mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
6FC2068C00EF    7041 Wed Nov 29 19:11:08  soXXpeXX@josXXeasXXa.cXX
                                         XXlos.AmXXamXX@XXale.XX

Con esta información puede rebotar el mensaje ejecutando:

>> crad-bounce.pyc -b 6FC2068C00EF

Posted in: Postfix

Leave a Comment (0) →

Portfix informa “Connection timed out” pero el telnet funciona

Índice de claves

  • Postfix connection cache
  • Postfix caching connection timeout
  • Postfix insiste en informar “Connection timed out”

Introducción

Si encuentra que está recibiendo informes de “connection timeout” de “Mail deliveries” o directamente desde el log como el que sigue:

Jan 11 07:32:14 server-smtp-01 postfix/error[11965]: 62E6DEBAD: to=, relay=none, delay=17159, delays=17159/0.04/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mailserver.xx.es[194.X.187.X]:25: Connection timed out)

..y al mismo tiempo, está ejecutando operaciones de telnet y funcionan sin problemas::

telnet 194.X.187.X 25
Trying 194.X.187.X...
Connected to 194.X.187.X.
Escape character is '^]'.
220 mailserver.xx.es ESMTP

En este contexto, incluso si reinicia el servicio de Postfix sigue encontrando que los errores persisten y sigue reportando “Connection timed out”.

Al mismo tiempo, ya ha comprobado que ningún firewall está bloqueando la conexión: por ejemplo, root puede tener permitido hacer telnet mientras que el usuario “postfix” no.

¿Porqué Postfix sigue reportando “Connection timed out”?

Todos estos “Connection timed out” informados por Postfix son usualmente causados por el módulo de postfix de cacheo de estado de conexiones (postfix connection cache): http://www.postfix.org/CONNECTION_CACHE_README.html

Este código de cache es usado por Postfix para acelerar las operaciones y para evitar seguir hablando con hosts lentos o que están fallando. Es una mejora para el rendimiento que, en algunos casos, puede causarle problemas.

En algún momento del pasado, el servidor SMTP de destino comenzó a fallar con un timeout. Luego, este estado fue cacheado por Postfix, causando este problema.

¿Cómo resolver el “Connection timed out” cuando telnet funciona?

Primero, intente revisar la configuración “smtp_connect_timeout” para incrementarlo. Por defecto viene configurado a 30 segundos. No lo incremente por encima de 90 porque le causará otros problemas.

Después de eso, ejecute los siguientes comandos para reencolar los correos y luego reiniciar postfix. Recuerde que esto reintentará todo:

postsuper -r ALL
/etc/init.d/postfix restart

Posted in: Postfix

Leave a Comment (0) →

Controlando el “content filter” Amavis con Valvula (protocolo “access policy delegation”)

Índice de claves

Resumen

Controlando los correos comprobados o producidos por el servidor de “Content filter” (Amavis) con el servidor de delegación de políticas de acceso (Valvula)configurado en Postfix.

Introdución

Debido al modo en que funciona Postfix cuando configuras el parámetro “content filter =”, donde configuras Amavis o cualquier otro servidor de “Content Filter”, esto hace que todos los correos que entran en la cola de Postfix sean envaidos a Amavis (o el servidor de “Content filter” que tenga configurado) de manera que el correo sea procesado y a su vez, si todo está correcto, ese correo regresará a Postfix a través de un puerto interno diferente (típicamente 10025/tcp).

Desde aquí, asumiremos que el servidor de “Content Filter” es Amavis y Valvula como servidor de delegación de política. Si este no es el caso, este artículo sigue siendo relevante para su configuración.

Una vez que Amavis ha decidido que todo está correcto, ese correo es enviado de nuevo a Postfix en un puerto dedicado, usualmente declarado como sigue en  /etc/postfix/master.cf:

# amavis connection, messages received from amavis 
127.0.0.1:10025 inet n - y - - smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o smtpd_restriction_classes=
 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject 
 -o mynetworks=127.0.0.0/8
 -o strict_rfc821_envelopes=yes
 -o receive_override_options=no_address_mappings

Como puede ver, cualquier correo será aceptado en el puerto (10025/tcp) mientras que venga de localhost (confianza total).

Sin embargo, el problema que queremos resolver es como enfrentarnos a correos originados desde el servidor internamente (enviados por el comando mail/maildrop) o porque sean enviados por mailman (o alguna configuración del propio servidor de “Content Filter” que también puede producir correos por si mismo) y que estos sean controlados/supervisados por Valvula (access policy server).

En este caso, con la configuración anterior no hará que los correos producidos por Amavis sean controlados por Valvula.

Qué hay que cambiar para que el servidor de políticas sea llamado

Con esta información identificada, en el caso de que sea necesario filtrar los correos enviados de regreso a Postfix por el servicio de “Content Filter”, puede actualizar el siguiente parámetro:

        -o smtpd_recipient_restrictions=permit_mynetworks,reject

..para que sea lo siguiente:

        -o smtpd_recipient_restrictions=check_policy_service,inet:127.0.0.1:3579,permit_mynetworks,reject

Esta esta la configuración recomendada para Core-Admin, donde la parte relevante es “127.0.0.1:3579″ y que tiene que ser actualizada con su configuración local.

De esta manera, cuando Amavis termine, ese correo tendrá que ir también através de Valvula cuando vuelva a Postfix.

Interacciones que puede causar esta configuración

Este cambio hará que Valvula (o el servidor de políticas que tenga configurado) que sea llamado 2 veces por cada correo recibido. Primero cuando el correo es recibido y segundo, cuando es recibido después que Amavis termina de procesar el correo.

Porqué no configurar esto por defecto

Esta configuración aquí descrita puede ser interesante en algunos escenarios.

Para el caso de un servidor de correo dedicado, esta configuración no es útil/necesaria. Nos referimos “servidores de correo dedicados” aquellos que no tienen un software de gestión de listas, páginas webs o cualquier otro software que pueda proucir correos internamente y que sea necesario limitarlos, bloquearlos o descartarlos.

Por otro lado, esta información puede no ser interesante en todos aquellos casos conde esta limitación pueda ser en origen (actualizando la configuración del servicio produciendo estos correos a limitar) o incluso la configuración de Postfix authorized_submit_users.

Resumiendo, esta no es la única configuración disponible para limitar/controlar correos desde dentro del servidor usando el servicio de delegación de política de acceso (http://www.postfix.org/SMTPD_POLICY_README.html).

Posted in: Administrador de Correo, Amavis, Postfix, Seguridad, Valvula

Leave a Comment (0) →