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 podría 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 electrónico que esta entrando en este momento. Una vez el mensaje ha entrado desaparecerá de la cola. Lógicamente si no hay ninguno archivo es que no está entrando correo. Como veis hay un montón de colas en postfix y cada una tiene su función. Lógicamente todo este árbol de carpetas no hay que tocarlo para nada porque para eso están las utilidades de postfix.

Si tenemos una maquina dedicada al correo, es seguro que el 99% de la congestión que pueda tener es debido al procesamiento de los mensajes que entran y salen. Las colas más importantes que tiene postfix son las siguientes:

+ cola incoming: en esta cola están 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 envían los mensajes a sus destinatarios. Esta es una de las colas más importantes ya que internamente hay mucha logica para implementarla. Desde esta cola se crearán 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 análisis 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 automática 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 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_life_time. 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 $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 básicamente 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 envío y este no tiene éxito, el siguiente envío se hace a los 2T y así sucesivamente.

En la siguiente imagen es la más completa que he podido encontrar por Internet (google images) de la relación entre las colas y lo procesos de postfix:

En el próximo 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 también el configurador de parámetros, 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 tamaño de todos ellos (1066Kb). Si por ejemplo veis que tenéis 125 mensajes por procesar y 450Mb de correo pues es para ver que esta pasando. Yo en este caso movería los correos que más pesan a la cola hold para enviarlos más 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 parámetro -f:[root@zimbra sbin]# ./postqueue -f

Esto es útil cuando tienes un problema en tú línea 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 línea los mensajes seguirán 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 parámetro -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 parámetro -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 parámetro -h.[root@zimbra sbin]# ./postsuper -h C18C368288

Si posteriormente queremos poner este mensaje otra vez en circulación haríamos lo mismo pero con el parámetro -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 5 10 20 40 80 160 320 640 1280 1280+ TOTAL 486 0 0 1 0 0 2 4 20 40 419 yahoo.com 14 0 0 1 0 0 0 0 1 0 12 extremepricecuts.net 13 0 0 0 0 0 0 0 2 0 11 ms35.hinet.net 12 0 0 0 0 0 0 0 0 1 11 winnersdaily.net 12 0 0 0 0 0 0 0 2 0 10 hotmail.com 11 0 0 0 0 0 0 0 0 1 10 worldnet.fr 6 0 0 0 0 0 0 0 0 0 6 ms41.hinet.net 6 0 0 0 0 0 0 0 0 0 6 osn.de 5 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 más de 1280 minutos esperando a salir.

Por ultimo tenemos el comando postconf que nos muestra la configuración activa que hay en postfix. Esta configuración se puede cambiar en /opt/zimbra/conf/main.cf.in. Si queremos ver todos los parámetros relacionados con colas haremos:[root@zimbra sbin]# ./postconf | grep queuebounce_queue_lifetime = 5dhash_queue_depth = 1hash_queue_names = deferred, defermaximal_queue_lifetime = 5dqueue_directory = /opt/zimbra/postfix-2.2.9/spoolqueue_file_attribute_count_limit = 100queue_minfree = 0queue_run_delay = 1000squeue_service_name = qmgr

Tenemos por ejemplo que numero máximo de días 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 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:

DNSUna 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.25smtp2.google.com. 3531 IN A 64.233.165.25smtp3.google.com. 3531 IN A 209.85.137.25smtp4.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 redOtro 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 relayUn 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 mynetworksmynetworks = 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.commydomain = domain.commydestination = $myhostname, $mydomainrelay_domains = $mydestinationmynetworks = 127.0.0.0/8 192.168.1.0/24

Listas negrasOtra 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 deferredEn 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.

QshapeUna 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 archivosEl 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 finalizarLo 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?