Ver colas de Correo en Zimbra

colas en zimbra (parte 1)

3 de septiembre de 2008

Este post aunque se llama "colas en zimbra" bien se podra llamar "colas en postfix" ya que postfix es el mta que utiliza zimbra. Postfix tiene varias colas donde va guardando todo el correo que procesa y el correo que no ha podido procesar por cualquier motivo. Por regla general a cada concepto de cola en postfix se le asigna una carpeta fisica dentro del sistema de ficheros. En el caso de zimbra las colas se encuentran dentro de la carpeta "/opt/zimbra/postfix/spool". Si entramos por ejemplo dentro de la cola incoming podremos ver archivos los cuales cada uno corresponden a un mensaje de correo electrnico que esta entrando en este momento. Una vez el mensaje ha entrado desaparecer de la cola. Lgicamente si no hay ninguno archivo es que no est entrando correo. Como veis hay un montn de colas en postfix y cada una tiene su funcin. Lgicamente todo este rbol de carpetas no hay que tocarlo para nada porque para eso estn las utilidades de postfix. Si tenemos una maquina dedicada al correo, es seguro que el 99% de la congestin que pueda tener es debido al procesamiento de los mensajes que entran y salen. Las colas ms importantes que tiene postfix son las siguientes: + cola incoming: en esta cola estn todos los nuevos mensajes que entran en postfix. Estos ficheros que se crean por cada mensaje los crea un servicio de postfix llamado cleanup. Este fichero tendr de propietario postfix y permisos 0600 mientras se est recibiendo y 0700 una vez se ha terminado de recibir. + cola active: desde esta cola se envan los mensajes a sus destinatarios. Esta es una de las colas ms importantes ya que internamente hay mucha logica para implementarla. Desde esta cola se crearn todas las conexiones smtp necesarias (consultando los registros MX de los DNS) para los destinatarios. Aunque a esta cola le corresponda una carpeta, internamente en postfix se crean estructuras de memoria para su procesamiento. Las colas de incoming, hold o deferred no ocupan memoria en el sistema. Normalmente el anlisis de los cuellos de botella se centran en esta cola. + cola hold: en esta cola van a parar indefinidamente los mensajes que el administrador quiere que no se procesen. Es posible configurar postfix para que mueva mensajes a esta cola de forma automtica utilizando access. + cola deferred: en esta cola van a parar los mensajes que no se han podido enviar alguno de los destinatarios y por tanto postfix tiene que volver a reitentar el envi. Tanto las colas de incoming y deferred se miran peridicamente para ver si hay algn mensaje para enviar. Hay tres parmetros bsicos 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 ms tarde o expire el tiempo de vida. El tiempo de vida de un mensaje en la cola deferred viene marcado por la variable $maximal_life_time. Si transcurrido este tiempo el mensaje no se pudo enviar este mensaje se devuelve al remitente pero solo en un tamao concreto marcado por la variable $bunce_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 bsicamente es algo as: la cola deferred se escanea cada $queue_run_delay en busca de mensaje 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 envo y este no tiene xito, el siguiente envo se hace a los 2T y as sucesivamente. En la siguiente imagen es la ms completa que he podido encontrar por Internet (google images) de la relacin entre las colas y lo procesos de postfix:

En el prximo post explicar los comandos para el manejo de las colas y unos apuntes de tunnig de postfix.

Las utilidades que postfix proporciona se encuentran dentro de /opt/zimbra/postfix/sbin. No solo encontraremos las utilidades para el manejo de colas sino tambin el configurador de parmetros, el creador de alias, etc. La primera utilidad para ver la cantidad de mensajes en cola es la utilidad postqueue. Si la lanzamos con el comando -p nos mostrar los mensajes que hay en proceso (cola deferred y active):
[root@zimbra sbin]# ./postqueue -p -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------1B6FE682F9 22910 Wed Sep 3 17:09:39 MAILER-DAEMON (connect to mail.member.gocyberlink.com[203.70.119.145]: Connection timed out) Membership@member.gocyberlink.com CE801682F8 488323 Wed Sep 3 17:09:38 xxxx@xxxxx.com (connect to hotamil.com[65.74.135.110]: Connection timed out) yyyy@hotmail.com C18C368288 42744 Wed Sep 3 17:09:51 xxxx@xxxxx.com (connect to hotamil.com[65.74.135.110]: Connection timed out) yyyyy@hotamil.com 58D796836C 536981 Fri Sep 5 14:22:39 rrrrrr@xxxxx.com (host mx.poczta.interia.pl[217.74.64.238] said: 450 4.7.1 : Helo command rejected: Host not found (in reply to RCPT TO command)) hhhhh@fffff.pl -- 1066 Kbytes in 4 Requests.

Con esta utilidad podemos hacernos una idea de cuantos mensajes hay pendientes de procesar (4 mensajes) y el tamao de todos ellos (1066Kb). Si por ejemplo veis que tenis 125 mensajes por procesar y 450Mb de correo pues es para ver que esta pasando. Yo en este caso movera los correos que ms pesan a la cola hold para enviarlos ms tarde. Otra cosa que podemos hacer con postqueue es volver a reintentar enviar todos los correos que se encuentran en deferred. Es decir reintentar el envi o hacer un flush. Esto se hace con el parmetro -f:
[root@zimbra sbin]# ./postqueue -f

Esto es til cuando tienes un problema en t lnea de Internet y por cualquier motivo los correos no pueden salir. Todos estos correos que no pueden salir iran a parar a la cola deferred. Una vez arreglado el problema en la lnea los mensajes seguirn en la cola deferred hasta que el procesador de posfix no vuelva a reintentar el envi. Para no esperar hasta la marca de tiempo se puede utilizar el parmetro -f para forzar el envi. El siguiente comando interesante es postsuper. Con este comando podemos tocar internamente los mensajes que hay en la cola. Con el parmetro -d podemos borrar un mensaje de correo que est identificado por un

"queue ID". Para ello primero tenemos que hacer un "postqueue -p" para ver los mensaje que tenemos y buscar el "queue ID" del mensaje que queremos eliminar. Supongamos que queremos eliminar el mensaje "C18C368288".
[root@zimbra sbin]# ./postsuper -d C18C368288

Si por el contrario no lo queremos eliminar pero nos lo queremos quitar de enmedio, lo podemos enviar a la cola hold con el parmetro -h.
[root@zimbra sbin]# ./postsuper -h C18C368288

Si posteriormente queremos poner este mensaje otra vez en circulacin haramos lo mismo pero con el parmetro -H.
[root@zimbra sbin]# ./postsuper -H C18C368288

Otra utilidad para ver colas es el script qshape.pl. Es un script que no utilizo mucho, pero lo que hace es mostrarte un listado de todos los dominios de mensajes que hay por enviar y cuando tiempo hace que estan en la cola.
$ qshape -s hold | head T TOTAL 486 yahoo.com 14 extremepricecuts.net 13 ms35.hinet.net 12 winnersdaily.net 12 hotmail.com 11 worldnet.fr 6 ms41.hinet.net 6 osn.de 5 5 10 20 40 80 160 320 640 1280 1280+ 0 0 1 0 0 2 4 20 40 419 0 0 1 0 0 0 0 1 0 12 0 0 0 0 0 0 0 2 0 11 0 0 0 0 0 0 0 0 1 11 0 0 0 0 0 0 0 2 0 10 0 0 0 0 0 0 0 0 1 10 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 6 0 0 0 0 0 1 0 0 0 4

En este ejemplo vemos que de mensajes que van para yahoo.com hay 14. De estos 14 mensajes que se tienen que entregar a yahoo.com hay 12 que llevan ms de 1280 minutos esperando a salir. Por ultimo tenemos el comando postconf que nos muestra la configuracin activa que hay en postfix. Esta configuracin se puede cambiar en /opt/zimbra/conf/main.cf.in. Si queremos ver todos los parmetros relacionados con colas haremos:
[root@zimbra sbin]# ./postconf | grep queue bounce_queue_lifetime = 5d hash_queue_depth = 1 hash_queue_names = deferred, defer maximal_queue_lifetime = 5d queue_directory = /opt/zimbra/postfix-2.2.9/spool queue_file_attribute_count_limit = 100 queue_minfree = 0 queue_run_delay = 1000s queue_service_name = qmgr

Tenemos por ejemplo que numero mximo de das que un mensaje puedes estar sin enviar es de 5 dias (bounce_queue_lifetime) y que la cola de deferred se escanea cada 1000 segundos en busca de mensajes que reenviar (queue_run_delay).

PREGUNTAS DNS

Por defecto la configuracin de Postfix estndar no debera dar cuellos de botellas ni retardos en los correo. Aun as un gran trfico de spam, una secuencia de correos grandes que no deberan estar en la cola, un hardware lento o una mala configuracin de nuestra red puede provocarnos muchos problemas. Si este es el caso, tendremos que repasar estos puntos: DNS Una mala configuracin 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. ;; ANSWER SECTION: google.com. google.com. google.com. google.com. ;; ADDITIONAL SECTION: smtp1.google.com. smtp2.google.com. smtp3.google.com. smtp4.google.com. ;; ;; ;; ;; 10731 10731 10731 10731 3531 3531 3531 3531 IN IN IN IN IN IN IN IN IN MX MX MX MX MX A A A A 10 10 10 10 smtp1.google.com. smtp2.google.com. smtp3.google.com. smtp4.google.com.

209.85.237.25 64.233.165.25 209.85.137.25 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 tendra que sobrepasar los 100 o 150ms. Para segundas consultas sobre el dominio el tiempo tendra 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. Tambin 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 mximo caudal posible hacia afuera para asegurarnos que los correos permanecen el mnimo de tiempo en la cola de salida. Podras 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 configuracin especial de un MTA por la cual cualquiera que se conecte podr utilizar nuestro servidor para enviar correo. Esta opcin debera estar restringida solo para las maquinas de nuestra red. De lo contrario podra ser utilizada para el envi masivo de spam. Con el tiempo esto provocara que furamos 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 parmetro "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 drsticamente 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 cmo utilizar el parmetro de configuracin 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 da. Otra buena opcin 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 envo. Tanto las colas de incoming y deferred se miran peridicamente para ver si hay algn mensaje para enviar. Hay tres parmetros bsicos 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 ms 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 tamao 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 bsicamente 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 envo y este no tiene xito, el siguiente envo se hace a los 2T y as sucesivamente. Si quieres vaciar la cola de deferred ms rpidamente, 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 ms 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 tambin 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 estara 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 telefnica 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 parmetro "$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 ms para repasar?