Análisis del archivo Maillog para Postfix e IMSVA (Parte I)

[Read this post in English]

 

PARTE I. Indicadores de Performance de Postfix usando el Maillog

El procedimiento que se muestra a continuación funciona en teoría para cualquier servidor de correo ó Appliance de Anti-Spam. Este análisis en particular se hizo sobre el Postfix de un IMSVA 8.5 pero la información puede fácilmente trasladarse a cualquier plataforma.

El primer punto para identificar cuál es el performance actual del equipo es definir ciertos indicadores que nos ayuden a medir patrones. La siguiente lista muestra algunos de los más importantes a tomar en cuenta:

  • Número de conexiones entrantes.
  • Número de conexiones salientes.
  • Número de conexiones al Scanner (sólo para IMSVA)
  • Correo entregado hacia Internet
  • Correo con rechazo permanente
    • Correo rechazado porque el dominio no existe
    • Correo rechazado porque el buzón no existe
  • Tiempo promedio de vida antes del rechazo
  • Tiempo máximo de vida antes del rechazo
  • Tiempo mínimo de vida antes del rechazo
  • Correo con rechazo temporal
    • Correo rechazado por timeout ó rechazo de conexión
      • Top ten de estos dominios
    • Correo rechazado por otra razón
      • Top ten de esta razones
  • Tiempo promedio de encolamiento
  • Tiempo máximo de encolamiento
  • Tiempo mínimo de encolamiento
  • Cantidad de buzones

El siguiente paso es obtener la información para cada uno de los indicadores. Nosotros mostramos la forma manual de hacerlo que sin duda podrá ayudar a generar scripts que realicen las mismas acciones de forma automática, nuestro objetivo es sólo mostrar cómo filtrar el maillog para aprovechar su información.

 

DETERMINAR EL NUMERO DE CONEXIONES ENTRANTES EN EL MAILLOG

Lo primero a notar es que Postfix no distingue entre conexiones desde nuestra red interna y las que provienen de Internet, por lo que buscar el número de conexiones nos dará un número mezclado entre estos dos valores. En nuestro análisis nos centraremos en las conexiones recibidas únicamente desde la red interna, pero el mismo proceso se puede aplicar para sacar el número de conexiones desde Internet. Para sacar este valor hay algunos casos a considerar de acuerdo a la configuración de Postfix.

  • La primera opción es que tengamos un Postfix que es sólo de salida, por lo que el total de sus conexiones se asumen como de la red interna. En este caso filtraremos el maillog para buscar todas las líneas que contengan el siguiente texto: “ connect from unknown”. En el caso de IMSVA, este filtro también incluye las conexiones que realiza Postfix hacia el Scanner en la IP 127.0.0.1 por lo que el filtro debe excluir las líneas que incluyen esta IP.
  • La segunda opción es cuando nuestro Postfix recibe y envía correo desde y hacia Internet y además la configuración del relay está configurada para aceptar conexiones desde ciertas direcciones IP en particular. En este caso debemos filtrar el maillog para buscar líneas del tipo “ connect from unknown[192.168.75.5]”. Si Postfix recibe correo de más de un servidor interno pero todos pertenecen al mismo segmento, entonces el filtro se puede abrir para quedar así “ connect from unknown[192.168.75.”. Si las direcciones IP son de diferentes segmentos entonces se puede hacer más de un filtro, uno para buscar las líneas de cada dirección IP. En este último caso se pueden juntar todos los logs al final o se pueden analizar por separado para detectar diferencias en comportamientos de cada servidor interno hacia nuestro Postfix.
  • La tercera y última opción es cuando sólamente es de entrada, es decir que sólo recibe conexiones desde Internet, en este caso se puede aplicar el mismo filtro de ” connect from unknown” excluyendo la IP 127.0.0.1 que es el Scanner de IMSVA y todas aquellas direcciones IP de la red interna que pertenezcan a los servidores de correo a los que IMSVA entrega el correo filtrado.

Estos filtros se pueden realizar directamente en el equipo con el comando “cat” ó se puede extraer el log y procesarlo con aplicaciones como “Notepad++” que sirven mucho para este tipo de análisis. Como mencionamos al inicio, existen otras herramientas que realizan estos procesos de forma autómatica pero no en todas se puede distinguir entre el tipo de tráfico que queremos, por eso esperamos que mostrar el proceso manual pueda ayudar a dar una mejor interpretación de la información y de dónde se sacan dichos valores.

Si se opta por filtrar el log utilizando el comando “cat”, estos son los comandos a utilizar:

Para el caso 1 en un Postfix (IMSVA) de sólo salida

cat /var/log/maillog | grep " connect from unknown" | grep -v 127.0.0.1 |wc -l

Para el caso 2 en un Postfix (IMSVA) de entrada y salida para un sólo servidor interno

cat /var/log/maillog | grep " connect from unknown[IP_Correo_Interno]" |wc -l

Para el caso 2 en un Postfix (IMSVA) de entrada y salida con varios servidores internos del mismo segmento

cat /var/log/maillog | grep " connect from unknown\[192.168.75." |wc -l

Para el caso 2 en un Postfix (IMSVA) de entrada y salida con varios servidores internos de diferentes segmentos

cat /var/log/maillog | grep " connect from unknown\[IP_Correo_Interno1\]" |wc -l
[...]
cat /var/log/maillog | grep " connect from unknown\[IP_Correo_InternoN\]" |wc -l

Y al final sumar todos los resultados para tener el total de conexiones desde la red interna.

Para el caso 3 en un Postfix (IMSVA) sólo de entrada

cat /var/log/maillog | grep " connect from unknown"| grep -v \[IP_Correo_Interno\]|grep -v 127.0.0.1 |wc -l

El número resultante de estos filtro nos dará el total de conexiones entrantes.

 

DETERMINAR EL NUMERO DE CONEXIONES SALIENTES

Este número se puede determinar con la siguiente fórmula:

CONEXIONES SALIENTES = CORREO ENTREGADO A INTERNET + CORREO CON RECHAZO PERMANENTE + CORREO CON RECHAZO TEMPORAL

Tome en cuenta que este número no incluye el número de correos / conexiones hacia el Scanner (en la IP 127.0.0.1) con el fin de distinguir entre entrega de correo procesado y correo que debe ser procesado.

 

DETERMINAR EL NUMERO DE CONEXIONES AL SCANNER DE IMSVA

En IMSVA, el Scanner es el módulo que se encarga de procesar el correo antes de ser entregado. Existen dos instancias de Postfix: la primera en el puerto 25 ó 2500 cuando está habilitado IP Profiler y el puerto 10026 para recibir el correo procesado por el Scanner. Debido a esta configuración, el Scanner produce líneas adicionales en el maillog que reflejan el paso del correo entre las dos instancias de Postfix. Conocer el número de conexiones recibidas por el Scanner ayuda a saber la capacidad de procesamiento de correo que tiene IMSVA.

El comando para obtener este número es muy similar a los ya presentados:

cat /var/log/maillog | grep " connect from unknown[127.0.0.1]" |wc -l

En este escenario no es posible, al menos de forma simple, distinguir entre las conexiones al Scanner por correo entrante y saliente cuando IMSVA procesa correo para ambas direcciones. A pesar de esto, el número resultante del filtro ayudará a conocer si al Scanner le faltan o le sobran conexiones para aumentar su capacidad / velocidad de procesamiento.

 

DETERMINAR LA CANTIDAD DE CORREO ENTREGADO HACIA INTERNET

Para determinar este número podemos ejecutar el siguiente filtro:

cat /var/log/maillog | grep "status=sent"|grep -v 127.0.0.1 |wc -l

Observe que el filtro excluye los correos entregados exitosamente hacia el Scanner al excluir la IP 127.0.0.1 del número resultante. Si el servidor Postfix (IMSVA) es sólo de salida entonces este filtro es más que suficiente para determinar el número correcto.

En casos donde el Postfix (IMSVA) es tanto de entrada como de salida, este número refleja el correo entregado tanto a Internet como a la red Interna por lo que además de excluir la IP 127.0.0.1 también deberán excluirse la IP ó IP’s de los servidores de correo internos como en el siguiente ejemplo:

cat /var/log/maillog | grep "status=sent"|grep -v 127.0.0.1|grep -v 192.168.75.5| wc -l

Si son varios servidores de correo interno pero pertenecen al mismo segmento omita el cuarto octeto de la IP, por ejemplo “192.168.75.”. En el caso de que sean varios servidores de correo interno en diferentes segmentos tendría que agregar un “grep –v [IP]” por cada IP a excluir.

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO PERMANENTE

Para obtener este número se puede utilizar el siguiente filtro:

cat /var/log/maillog | grep "status=bounced"| wc -l

Observe que en este caso no excluimos la dirección de localhost (127.0.0.1) y en casos donde Postfix es de entrada y salida tampoco excluimos los servidores de correo interno. En este caso es conveniente contar con el número total de correos rechazados y después obtener el número individual de correos rechazados de forma permanente tanto por el Scanner como por los diferentes servidores de correo Interno. Para obtener estos últimos números simplemente agregamos el parámetro “grep” con el valor de la IP que queremos filtrar como en el siguiente ejemplo para obtener los correos con rechazo permanente por parte del Scanner de IMSVA:

cat /var/log/maillog | grep "status=bounced"|grep 127.0.0.1| wc -l

Idealmente el valor de estos sub-filtros debería de ser “0” ya que en caso contrario podría indicar un problema de desempeño de los motores de IMSVA.

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO PERMANENTE PORQUE EL DOMINIO NO EXISTE

Para obtener este número se puede utilizar el siguiente filtro:

cat /var/log/maillog | grep "status=bounced"| grep "dsn=5.4.4" |wc -l

Observe que en vez de identificar el error en base a la descripción, lo hacemos en base al código de estado 5.4.4 que engloba a todos los errores que caen bajo esta categoría. De esta forma se evita el problema de identificar múltiples descripciones ya que cada servidor de correo establece su propia descripción, incluso cada administrador podría cambiar este texto a su idioma o requerimiento de políticas de la Organización.

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO PERMANENTE POR PROBLEMAS CON EL BUZON

Bajo esta categoría caen diversos códigos de estado que en general apuntan hacia el mismo problema: existe una situación con el buzón destinatario que impide que la entrega del correo sea exitosa. En la práctica y de acuerdo al flujo de correo de la Organización se puede asumir en términos generales que esta cantidad corresponde a la diferencia entre el correo total rechazado permanentemente y el correo rechazado porque el dominio no existe es decir:

BUZON INEXISTENTE = TOTAL RECHAZADO PERMANENTE – RECHAZO POR DOMINIO INEXISTENTE

Si se quiere estar seguro de que todo el correo con rechazo permanente cae al menos en un 90 ó 95 % en estas dos categorías se puede ir filtrando uno a uno los diferentes códigos de estado encontrados con estado “bounced”. Como resultado de ese análisis podrá asegurar que estos dos indicadores son suficientes para abarcar la totalidad de estos correos o si debe agregar una tercera o más categorías a su análisis. La forma de obtener las demás razones se muestra en la sección DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO TEMPORAL POR OTRAS RAZONES que se expone más adelante.

 

DETERMINAR EL TIEMPO DE VIDA PROMEDIO, MINIMO Y MAXIMO DEL CORREO ANTES DEL RECHAZO PERMANENTE

Este valor representa el tiempo que tarda el correo desde que es exitosamente recibido por Postfix y el tiempo en que finalmente es entregado a su dominio destino encontrándose con un código 5XX que indica que el correo no puede ser entregado.

Por la naturaleza misma del error, este tipo de correos no serán encolados dentro del Postfix, sino que serán eliminados de inmediato y se generará un NDR (Non-Delivery-Response) para indicar al remitente que su correo no pudo ser entregado.

En este caso, todas las conexiones de este tipo corresponden a un correo en particular, por lo que si vemos 100 conexiones rechazadas permanentemente, se puede asumir que dichas conexiones fueron generadas por 100 correos exactamente. Es importante tomar esto en cuenta ya que en el caso de conexiones con rechazo temporal esto no es necesariamente cierto como veremos más adelante.

Por lo anterior, el tiempo obtenido por este indicador nos puede decir si el correo está teniendo algún tipo de retraso dentro del Scanner o dentro de Postfix antes de tener su primer oportunidad de ser entregado. Todo esto, tomando en cuenta que estos correos sólo tienen un intento de entrega y en dicho intento es rechazado de forma permanente.

El comando para obtener este número es el siguiente:

cat maillog|grep status=bounced|awk '{print $9}'|grep delay=|sed 's/delay=//g'|sed 's/,//g' > delayBounced.txt; cat maillog|grep status=bounced|awk '{print $10}'|grep delay=|sed 's/delay=//g'|sed 's/,//g' >> delayBounced.txt; cat delayBounced.txt |awk 'NR == 1 { max=$1; min=$1; sum=0 }{ if ($1>max) max=$1; if ($1<min) min=$1; sum+=$1;} END {printf "Min: %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'

El comando hace lo siguiente:

  • cat maillog|grep status=bounced|. Esta sección del comando filtra primero todas las líneas que contienen la frase “status=bounced” que corresponde a todos los correos con rechazo permanente.
  • awk ‘{print $9}’. Esta sección presenta únicamente la novena columna de las líneas obtenidas, esto es porque en dicha columna se encuentra el parámetro “delay” que contiene el valor del tiempo total que el correo pasó desde su llegada hasta su entrega final.
  • grep delay=. En algunas líneas, la novena columna contiene un parámetro diferente a “delay” que se llama “conn_use”, este parámetro indica el número de veces que una conexión se ha reutilizado por falta de conexiones disponibles. Debido a que la columna puede tener dos valores distintos, con este parámetro filtramos únicamente aquellos valores que contengan el valor “delay”.
  • sed ‘s/delay=//g’. Hasta este momento contamos con un listado de una columna que tiene un formato similar a este “delay=342,”. Esta sección del comando se encarga de eliminar la palabra “delay=” para que la columna quede solamente como “342,”.
  • sed ‘s/,//g’. Al igual que en el punto anterior, este parámetro elimina la coma al final del número para que quede una sola columna con números.
  • > delayBounced.txt. Este parámetro guarda la columna de números en un archivo llamado delayBounced.txt.
  • Después del último parámetro se observa que se vuelve a repetir el comando. En esta ocasión se toma la columna 10 en vez de la 9, esto es para obtener los valores de “delay” en aquellas líneas cuya línea 9 contiene el parámetro “conn_use”, ya que en este caso la columna “delay” se mueve a la 10. Al final del comando observará que en vez de sobreescribir el archivo “delayBounced.txt” se le agregan las nuevas líneas mediante el uso del mecanismo “>>” que agrega las líneas al final del archivo. Al final de este comando, el archivo contiene todos los valores de tiempo de todos los correos rechazados.
  • El último comando se encarga de sacar los valores mínimo, máximo y el promedio del tiempo que pasó antes del rechazo. Los valores mínimo y máximo son importantes para agregar un contexto al valor promedio. Esto es, supongamos por ejemplo que el promedio de tiempo da 30 minutos, mientras que el mínimo son 2 segundos y el máximo 8 días. En este caso, para que el promedio pueda ser 30 minutos, la mayor cantidad de los valores está muy cercano a una banda entre los 2 segundos y 1 hora, por lo que deben ser pocos los correos que duraron más de 4 horas en entregarse. En cambio, si con los mismos mínimos y máximos obtenemos un promedio de 7 días, significa que la mayoría de los correos presentan un retraso en su entrega de más de 5 días mientras que son pocos los que se pueden entregar en pocos segundos ó incluso en pocas horas.

Estos tres valores nos darán una idea de qué tanto tiempo están tardando este tipo de correos en ser entregados y sobre todo, nos da un estimado de los recursos que ocupa IMSVA en procesarlos.

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO TEMPORAL

Un rechazo temporal se identifica por un código de estado 4XX y significa que en el momento de la transferencia del correo, el SMTP Server no es capaz de recibir ese correo, lo  que implica, por reglas de SMTP, que el correo debe ser encolado y se debe intentar su entrega posteriormente hasta que el tiempo de vida del correo llegue a su fin, en cuyo caso se deberá eliminar de la cola y se deberá generar un NDR para indicar al remitente que su correo no pudo ser entregado.

Para determinar este número se puede utilizar el siguiente filtro que busca todas las líneas de Postfix que contienen el valor “status=deferred”.

cat maillog|grep status=deferred|wc -l

El valor obtenido indica el total de conexiones que han sido rechazadas temporalmente. Debido a que son conexiones, un buen dato adicional, es el identificar la cantidad de correo que provocó este número. Esto se debe a que cuando un correo es encolado su entrega deberá intentarse tantas veces, hasta que sea finalmente aceptado o que llegue a su tiempo de vida límite. Debido a esto un solo correo podría generar más de 2 conexiones (el primer intento cuando fue encolado por primera vez y al menos el segundo intento cuando fue satisfactoriamente entregado). Para determinar la cantidad de correo se puede utilizar el siguiente comando:

cat maillog|grep status=deferred|awk '{print $6}'|sort -u|wc -l

Lo que hace el filtro es tomar primero todas las líneas del log que contienen la frase “status=deferred” que incluye todos los correos que han sido rechazados temporalmente. Después imprimimos únicamente la columna 6 que contiene el Internal ID que Postfix asigna de forma única a cada correo. Si un correo se trata de entregar 10 veces por ejemplo, el Internal ID aparecerá 10 veces también indicando que ese correo ha generado 10 conexiones con rechazo temporal. Finalmente ordenamos todas las líneas y eliminamos todos los ID repetidos, lo que finalmente nos entrega el total de correos únicos que han generado el total de conexiones.

Si además de esto se quiere saber cuántas conexiones ha generado cada correo se puede aplicar el siguiente comando:

cat maillog|grep status=deferred|awk '{print $6}'|sort|uniq -c|sort -nr > countDeferredMail.txt

Este filtro hace exactamente lo mismo que el anterior con la diferencia de que usamos el comando uniq para hacer el conteo de las veces que un Internal ID se ha repetido y al final ordenamos los registros del mayor al menor conteo de repeticiones con “sort –nr”. Como salida, podemos mandar el resultado a un archivo como “countDeferredMail.txt” ó simplemente podemos poner al final un “more” para visualizar la lista directamente sin necesidad de guardarlo a un archivo. Este último caso sería con el siguiente comando:

cat maillog|grep status=deferred|awk '{print $6}'|sort|uniq -c|sort -nr |more

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO TEMPORAL POR TIMEOUT O RECHAZO DE CONEXION

Al igual que como explicamos en los correos rechazados por que el dominio no existe, es preferible determinar este número por el código de estado porque las descripciones de cada sistema pueden variar. En este caso el código que indica esta situación es el DSN 4.4.1. Y la forma de determinar este número se puede hacer con el siguiente comando:

cat maillog|grep status=deferred|grep dsn=4.4.1|wc -l

Este número nos dará la cantidad de conexiones que se han utilizado para entregar correo hacia dominios que presentan alguno de los siguientes problemas:

  • El dominio tiene un registro MX, CNAME ó A vigente en algún DNS público por lo que por regla de correo, Postfix deberá encolar el correo e intentar su entrega hasta que la entrega sea exitosa o se cumpla el límite de vida del correo.
  • El dominio tiene listada a la IP de IMSVA en una lista de bloqueo temporal y está rechazando la conexión.
  • El dominio aceptó la conexión por el puerto 25 pero no responde con el banner de saludo que debe incluir el código 220.
  • Existe algún equipo intermedio: balanceador, firewall, switch, etc., que impide que la transferencia del correo se complete.

Para determinar el número de correo que está generando esta cantidad de conexiones se puede usar el siguiente comando:

cat maillog|grep status=deferred|grep dsn=4.4.1|awk '{print $6}'|sort|uniq -c|sort -nr|wc -l

Para sacar el  Top Ten de los dominios que generan esta situación se puede utilizar el siguiente comando:

cat maillog|grep status=deferred|grep dsn=4.4.1|awk '{print $15}'|grep "\[" > dsn441.txt;cat maillog|grep status=deferred|grep dsn=4.4.1|awk '{print $18}'|grep "\[" >> dsn441.txt; cat dsn441.txt | sort|uniq -c|sort -nr|more

Como resultado se obtendrá una lista ordenada con los dominios que mayor número de conexiones están generando y su dirección IP. Si se quiere guardar la lista completa se puede sustituir el último “more” por un “ > listaDSN441.txt”.

 

DETERMINAR LA CANTIDAD DE CORREO CON RECHAZO TEMPORAL POR OTRAS RAZONES

Este número se puede calcular al restar la cantidad total de correo con rechazo temporal menos el correo rechazado por problemas de conexión obtenido anteriormente, es decir:

CORREO RECHAZADO POR OTRAS RAZONES = TOTAL CON RECHAZO TEMPORAL – TOTAL CON RECHAZO POR PROBLEMAS DE CONEXION

Sin embargo este número por sí mismo no nos ayuda a identificar qué otro tipo de razones existen para que suceda el rechazo. Con el fin de tener un indicador más certero, se recomienda sacar el Top Ten de las razones del rechazo. Este número se puede calcular con el siguiente comando:

cat maillog|grep status=deferred|grep -v dsn=4.4.1|awk '{print $11" "$16" "$17" "$18" "$19" "$20" "$21" "$22" "$23" "$24" "$25" "$26" "$27" "$28" "$29" "$30" "$31" "$32}'|grep dsn= > dsn4XX.txt;cat maillog|grep status=deferred|grep -v dsn=4.4.1|awk '{print $12" "$17" "$18" "$19" "$20" "$21" "$22" "$23" "$24" "$25" "$26" "$27" "$28" "$29" "$30" "$31" "$32" "$33}'|grep dsn= >> dsn4XX.txt;cat dsn4XX.txt | sort|uniq -c|sort -nr|more

Al igual que en otros ejemplos si se quiere guardar la lista para un análisis posterior sólo hay que sustituir el último “more” por “ > listaDSN4XX.txt”.

Tome en cuenta que la salida de este comando puede contener entradas como la siguiente:

25 dsn=4.2.2, 451 4.2.2 user over quota; cannot receive new mail: 
user1@domain.com (in reply to RCPT TO command))
24 dsn=4.2.2, 451 4.2.2 user over quota; cannot receive new mail: 
user2@domain.com (in reply to RCPT TO command))
23 dsn=4.2.2, 451 4.2.2 user over quota; cannot receive new mail:
 user3@domain.com (in reply to RCPT TO command))

Donde se observa que se trata del mismo error pero para diferentes usuarios. Si se desea eliminar este error de la lista para ver qué otras situaciones se están generando se puede excluir el DSN en común para ver los otros motivos, por ejemplo, al final del comando se puede agregar la línea “|grep –v dsn=4.2.2|more” para excluir el DSN 4.2.2 que significa “user over quota”. Con esta modificación se obtendrán ahora los rechazos temporales diferentes a aquellas situaciones donde el correo es rechazado porque el usuario ha superado su cuota.

Otra forma de ver estas situaciones es filtrando exclusivamente por el código DSN, ya que dicho código siempre se refiere al mismo motivo sólo que las descripciones pueden estar expresadas de forma distinta dependiendo del servidor de correo que genera el rechazo. Para tener una lista ordenada de DSN sin incluir las descripciones se puede usar el siguiente comando:

cat maillog|grep status=deferred|awk '{print $11}'|grep dsn= > dsn4XX.txt;cat maillog|grep status=deferred|awk '{print $12}'|grep dsn= >> dsn4XX.txt;cat dsn4XX.txt | sort|uniq -c|sort -nr|more

La salida de este comando nos da ahora la lista de todos los errores con rechazo temporal así como su conteo como se muestra en la siguiente salida:

76661 dsn=4.4.1,
4590 dsn=4.4.3,
3299 dsn=4.7.7,
2989 dsn=4.7.1,
1066 dsn=4.3.2,
572 dsn=4.0.0,

Cuál de estos comandos utilizar depende de la información que se necesita recabar.

 

DETERMINAR EL TIEMPO DE VIDA PROMEDIO, MINIMO Y MAXIMO DEL CORREO ANTES DEL RECHAZO TEMPORAL

Este valor nos indica cuánto tiempo estamos almacenando correo dentro del equipo que no puede ser entregado por alguna de las razones determinadas en los puntos anteriores. Así mismo, nos indica qué tan grave es la afectación al performance del equipo por motivos de encolamiento, por ejemplo, no es lo mismo un valor promedio de 30 minutos a uno de 12 horas por ejemplo. Valores muy elevados nos pueden indicar una posible situación en que nuestra IP está en la lista negra de alguno de estos dominios, que los dominios existen pero ya no hay servidores de correo escuchando entre otras razones que probablemente provocarán que ese correo jamás podrá ser entregado al destino y sólo se están gastando recursos en su almacenamiento y re-envío.

El comando para obtener este valor es el mismo que utilizamos para determinar el mismo valor para los correos con rechazo permanente:

cat maillog|grep status=bounced|awk '{print $9}'|grep delay=|sed 's/delay=//g'|sed 's/,//g' > delayBounced.txt; cat maillog|grep status=bounced|awk '{print $10}'|grep delay=|sed 's/delay=//g'|sed 's/,//g' >> delayBounced.txt; cat delayBounced.txt |awk 'NR == 1 { max=$1; min=$1; sum=0 }{ if ($1>max) max=$1; if ($1<min) min=$1; sum+=$1;} END {printf "Min: %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'

 

DETERMINAR LA CANTIDAD DE BUZONES

Debido a que IMSVA utiliza a Postfix como MTA en modo SMTP proxy, el equipo en sí no contiene ningún buzón local para entrega o envío, los buzones residen por tanto en el servidor de correo interno al cuál se protege. El número de buzones protegidos es importante porque nos da el contexto de los indicadores que obtuvimos, ya que se pueden comparar las estadísticas de tráfico contra la cantidad de buzones observados en el mismo período de tiempo.

Para obtener este número se puede utilizar el siguiente comando:

cat maillog|grep from=|awk '{print $7}'|uniq | wc -l

Si se tiene más de un archivo maillog entonces se puede ejecutar el comando anterior para cada maillog ejecutando el siguiente número para remover los buzones duplicados:

cat maillog maillog.1 maillog.2 maillog.3 maillog.4|grep from=|awk '{print $7}'|sort|uniq -c|sort -nr|wc -l

Tome en cuenta que el número sólo representa la cantidad de buzones que Postfix ha visto que usan el servicio durante el período de tiempo que dura el maillog utilizado en el comando. Si se quiere sacar un total de usuarios más cercano a la realidad se deberá ejecutar el comando sobre la mayor cantidad de archivos maillog posible para evaluar distintos horarios y días.

 

Conclusión

Los comandos presentados aquí junto con la explicación de lo que significa cada indicador nos arrojará como resultado una tabla que concentra la información necesaria para saber cuál es el performance actual de nuestro equipo IMSVA ó Postfix. En la siguiente parte (Parte 2. Interpretación de los Indicadores), mostraremos varios ejemplos con datos reales para poder dar un significado más certero a estos números.

 

 

PARTE I. Indicadores de Performance de Postfix usando el Maillog

PARTE II. Interpretación de Indicadores del archivo Maillog

 

Si requieres de mayor información sobre las reglas de correo electrónico te recomendamos nuestra publicación Fundamentos de Correo Electrónico. Si quieres saber más sobre el funcionamiento de Postfix / IMSVA te recomendamos nuestra publicación Manual Avanzado de Implementación y Configuración de IMSVA. También te recomendamos visitar nuestra sección sobre Postfix.

Recuerda que puedes enviarnos tus preguntas y comentarios a nuestra cuenta de Twitter: @redinskala donde podrás encontrar más información y tips de seguridad.

Gracias por tu visita! Te esperamos pronto!

 

 

3 thoughts on “Análisis del archivo Maillog para Postfix e IMSVA (Parte I)

  1. Pingback: Interpretación de maillog en Postfix | RedinSkala

  2. Pingback: Maillog Analysis for Postfix and IMSVA (Part I) | RedinSkala

  3. Pingback: Análisis del archivo Maillog para Postfix e IMSVA (Parte II) | RedinSkala

Comments are closed.