slow postfix

Por defecto la configuración de Postfix estándar no debería dar cuellos de botellas ni retardos en los correo.
Aun así un gran tráfico de spam, una secuencia de correos grandes que no deberían estar en la cola, un hardware lento o una mala configuración de nuestra red puede provocarnos muchos problemas.

Si este es el caso, tendremos que repasar estos puntos:

DNS
Una mala configuración de Postfix puede afectar de forma negativa a la velocidad del correo. Durante la entrada y salida del correo el DNS es un servicio muy usado y por tanto mientras el DNS no produzca una respuesta el correo no saldrá ni entrará.
Conviene revisar nuestros DNS dentro de /etc/resvolv.conf y verificar la velocidad de estos.

[root@mta ~]# dig -tmx google.com

; <<>> DiG 9.3.4-P1 <<>> -tmx google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29611
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      MX

;; ANSWER SECTION:
google.com.             10731   IN      MX      10 smtp1.google.com.
google.com.             10731   IN      MX      10 smtp2.google.com.
google.com.             10731   IN      MX      10 smtp3.google.com.
google.com.             10731   IN      MX      10 smtp4.google.com.

;; ADDITIONAL SECTION:
smtp1.google.com.       3531    IN      A       209.85.237.25
smtp2.google.com.       3531    IN      A       64.233.165.25
smtp3.google.com.       3531    IN      A       209.85.137.25
smtp4.google.com.       3531    IN      A       72.14.221.25

;; Query time: 78 msec
;; SERVER: 10.1.2.13#53(10.1.2.13)
;; WHEN: Tue May  5 22:46:28 2009
;; MSG SIZE  rcvd: 180

Una respuesta adecuada no tendría que sobrepasar los 100 o 150ms. Para segundas consultas sobre el dominio el tiempo tendría que ser de 0ms ya que la respuesta queda cacheada por un periodo de tiempo.

Si aun así persisten los retardos en el DNS seria aconsejable pensar de colocar servidor DNS local a nuestra red (o en el propio servidor) que permita cachear todas las peticiones de DNS.

También es aconsejable comprobar si estamos utilizando los DNS proporcionados por nuestro propio ISP u otros ajenos a ellos.

Cortafuegos y uso de red
Otro aspecto a verificar son los firewalls, tanto de la propia maquina de correo como los que puedan haber durante salida hacia Internet. Debemos tener el máximo caudal posible hacia afuera para asegurarnos que los correos permanecen el mínimo de tiempo en la cola de salida.

Podrías hacer alguna vez un test de velocidad (http://www.adsl4ever.com/test/) y comprobar la velocidad de upload de tú servidor.

Open relay
Un open relay es una configuración especial de un MTA por la cual cualquiera que se conecte podrá utilizar nuestro servidor para enviar correo. Esta opción debería estar restringida solo para las maquinas de nuestra red. De lo contrario podría ser utilizada para el envió masivo de spam. Con el tiempo esto provocaría que fuéramos a parar a una lista de negra como Spamhaus, Sorbs, etc.

Para ello revisa el parametro "mynetworks" de Postfix (http://www.postfix.org/postconf.5.html#mynetworks).

# postconf | grep mynetworks
mynetworks = 127.0.0.0/8 192.168.2.0/24 10.5.0.0/16 10.6.0.0/16

En este caso solo las redes 192.168.2.0, 10.5.0.0 y 10.6.0.0 tienes derecho a enviar correo por este MTA.

Tambien puede revisar el parámetro "relay_domains":

myhostname = mxta.domain.com
mydomain = domain.com
mydestination = $myhostname, $mydomain
relay_domains = $mydestination
mynetworks = 127.0.0.0/8 192.168.1.0/24

Listas negras
Otra manera de reducir drásticamente el correo que entra (posible spam), el correo que rebota y tambien el correo que sale, es utilizar listas negras para filtrar el correo. Esto consiste en utilizar bases de datos de IPs de maquinas consideradas spammers.

Para configurar la utilizacion de listas negras se utiliza "smtpd_recipient_restrictions" y "reject_rbl_client".
En este caso utilizados tres bases de datos que contienen listas negras (Spamhaus, Sorbs y Spamcop).

Esto es una ejemplo de cómo utilizar el parámetro de configuración de Postfix dentro de main.cf:

smtpd_recipient_restrictions =
 reject_non_fqdn_recipient,
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination,
 reject_unlisted_recipient,
 reject_invalid_hostname,  
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 reject_rbl_client sbl-xbl.spamhaus.org,
 reject_rbl_client dnsbl.sorbs.net,
 reject_rbl_client bl.spamcop.net,
 permit

Teniendo en cuenta que actualmente el 80% del correo de Internet es spam, esto puede evitar la entrada de mucho correo en la cola. Yo, para unos 100 usuarios bloqueo unos 15.000 correos al día.

Otra buena opción es utilizar tambien un "reject_unknown_sender_domain" que rechaza el correo si el dominio del remitente no existe.

Cola deferred
En esta cola van a parar los mensajes que no se han podido enviar a alguno de los destinatarios y por tanto Postfix tiene que volver a reintentar el envío. Tanto las colas de incoming y deferred se miran periódicamente para ver si hay algún mensaje para enviar. Hay tres parámetros básicos en Postfix para controlar cada cuanto se miran estas colas y que afectan al rendimiento de postfix:
queue_run_delay, minimal_backoff_time y maximal_backoff_time.

El funcionamiento es el siguiente: cuando un mensaje llega este es procesado por el mta y enviado a la cola incoming. Por otro lado cuando se decide enviar un mensaje y Postfix se tiene que poner en contacto con otros mta, estos mensajes son enviados a la cola active. Si por cualquier motivo el mensaje no puede ser enviado a otro mta este pasará a la cola deferred hasta que pueda ser entregado más tarde o expire el tiempo de vida. El tiempo de vida de un mensaje en la cola deferred viene marcado por la variable $maximal_queue_lifetime. Si transcurrido este tiempo el mensaje no se pudo enviar este mensaje se devuelve al remitente pero solo en un tamaño concreto marcado por la variable bounce_size_limit. Si el remitente ha enviado un mail del 50Mb no tiene sentido devolverle otra vez el mail de 50Mb.

El escaneo de la cola de deferred para los reintentos sigue un algoritmo un poco complicado pero que básicamente es algo así: la cola deferred se escanea cada $queue_run_delay en busca de mensajes para enviar. Cuando un mensaje está en esta cola se le pone una marca de tiempo T. Si a los T segundos se hace el envío y este no tiene éxito, el siguiente envío se hace a los 2T y así sucesivamente.

Si quieres vaciar la cola de deferred más rápidamente, puedes modificar $maxima_queue_lifetime, que por defecto son 5 dias, para que los correos no permanezcan mucho tiempo en la cola.

Qshape
Una utilidad para controlar el estado de tú cola es qshape. Qshape te muestra la vejez de un correo dentro de la cola.

Si quieres saber más sobre qshape leete esto.
http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-1.html< http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-2.html

Denegando archivos
El denegar cierto tipo de archivos se puede considerar una manera de reducir ancho de banda para nuestro servidor y también tiempo de procesado de CPU en el caso que el correo se filtrara por un antivirus.

Es costumbre en los MTA finales restringir cierto tipo de archivos como: .exe, .pif, .reg, etc.
No estaría mal tampoco restringir archivos como mpge, mp3, avi, etc, siempre que podamos.
Hace como restringí los archivos wav de audio y no nos dimos cuenta de que la centralita telefónica necesitaba enviar mails con estos adjuntos para los mensajes de voz de los empleados.

Para denegar ciertas extensiones en un Postfix hay que utilizar el parámetro "$mime_header_checks". Aquí tines un ejemplo de como implementarlo: http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html Para finalizar
Lo recomendable siempre es hecharle un vistazo a la documentacion de tuning del producto. Aquí está la documentacion ofical sobre tuning para Postfix: http://www.postfix.org/TUNING_README.html

¿sabes de algo más para repasar?