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

PARTE II. Interpretación de Indicadores del archivo Maillog

En la PARTE I. Indicadores de Performance de Postfix usando el Maillog, vimos cómo a través de filtrar el archivo maillog de Postfix pudimos encontrar diversos valores que nos ayudan a saber cómo se comporta nuestro equipo Postfix ó IMSVA en cuanto al performance de entrega, recepción y encolamiento  de correo. Ahora veremos cómo poner un contexto a estos números para transformarlos de números a acciones / configuraciones que mejoren el desempeño del equipo.

No existe una única forma de interpretar los datos porque cada servidor e infraestructura es distinto. Partiendo de este punto, lo que mostraremos a continuación se debe interpretar como una metodología, más que una guía exacta a seguir.

Esta metodología de Interpretación se base en los siguientes puntos:

  • Evaluar la tasa entre correo recibido y correo entregado.
  • Evaluar la tasa entre correo entregado y correo rechazado permanente para ver si hay un impacto significativo.
  • Identificar si en las causas de rechazo permanente hay algo que se pueda hacer en el equipo para bajar el número.
  • Evaluar la tasa entre correo entregado y correo rechazado temporalmente para ver si hay un impacto significativo.
  • Identificar si en las causas de rechazo temporal hay algo que se pueda hacer en el equipo para bajar el número.
  • Evaluar la tasa entre correo entregado y correo eliminado / enviado a cuarentena por la aplicación de políticas.
    Identificar si hay un retraso significativo en la entrega de correo.
  • Resumen

Ahora veremos en mayor detalle, cómo interpretar cada uno de los puntos:

 

1.       Evaluar la tasa entre correo recibido y correo entregado.

Para obtener esta tasa utilizamos los siguientes indicadores obtenidos previamente con la siguiente fórmula:

 

EFICIENCIA DE ENTREGA = CORREO ENTREGADO HACIA INTERNET / NUMERO DE CONEXIONES ENTRANTES

 

Idealmente, uno pensaría que el valor obtenido en esta tasa debe ser “1”, pensando en que todo el correo recibido debe ser entregado. Si su equipo no aplica ninguna política de contenido, verificación de SPAM, etc., entonces estaría en lo correcto. Sin embargo, si utiliza Postfix como filtro, como en el caso de IMSVA, esto no es necesariamente cierto, ya que de ser así, significaría que su Postfix no está aplicando ninguna política y está dejando pasar todo el correo.

 

Veamos el siguiente ejemplo:

CORREO ENTREGADO HACIA INTERNET = 100 correos

CONEXIONES ENTRANTES = 100 conexiones

EFICIENCIA DE ENTREGA = 1

 

NOTA: En una conexión se puede mandar más de un correo, así que aquí asumimos que al menos por cada conexión se recibió un solo correo para hacer los cálculos más sencillos.

 

En este ejemplo, es claro que todo lo que entra sale, lo que indica que de haber políticas de filtrado, no están siendo efectivas, por lo que es probable que exista un problema en la configuración del equipo que impide que el filtrado funcione correctamente.

 

Veamos otro ejemplo:

CORREO ENTREGADO HACIA INTERNET = 80 correos

CONEXIONES ENTRANTES = 100 conexiones

EFICIENCIA DE ENTREGA = 0.8

 

Una eficiencia de 0.8 (80%) indica un ejemplo más apegado a la realidad. Aquí vemos que de cada 100 correos recibidos, 20 se quedan dentro del equipo, sin embargo el número no nos indica todavía, si los 20 correos están encolados o si fueron detenidos por alguna política de filtrado.

 

En este caso el siguiente paso a seguir es investigar bajo cuál de las siguientes 3 categorías caen estos 20 correos: rechazo permanente, rechazo temporal ó aplicación de políticas. Este paso lo desarrollaremos en las siguientes secciones que corresponden a cada categoría.

 

Cuando obtenemos el valor de la tasa, sin importar de qué valor se trate, la pregunta inmediata es ¿cómo puedo saber si la tasa es adecuada para mi Organización? Regresaremos a esta pregunta al final, ya que contemos con los valores de las tasas restantes, pero sin importar cuál sea la razón, un sistema de correo debe ser capaz de entregar siempre más del 80% del correo en tiempo y forma tomando en cuenta que el 100% al que corresponde, se trata de correo que debe ser entregado. Un valor inferior al 80% puede significar retrasos que impacten en la operación / reputación de la empresa.

 

 

2.       Evaluar la tasa entre correo entregado y correo rechazado permanente para ver si hay un impacto significativo.

Esta tasa nos indica cuántas conexiones / almacenamiento / CPU estamos gastando en correo que NO PODRA SER ENTREGADO. La forma de obtenerla es con la siguiente fórmula:

 

RECURSOS PARA CORREO CON RECHAZO PERMANENTE = CORREO CON RECHAZO PERMANENTE / NUMERO DE CONEXIONES SALIENTES

Idealmente el valor de esta tasa debería ser “0”, lo que indicaría que las conexiones salientes de Postfix no se están gastando en procesar correo que no puede ser entregado, sin embargo este tampoco es siempre el caso.

 

Retomando nuestro primer ejemplo, tenemos los siguientes indicadores:

 

CORREO ENTREGADO HACIA INTERNET = 100 correos

CONEXIONES ENTRANTES = 100 conexiones

CORREO CON RECHAZO PERMANENTE = 0 correos

CONEXIONES SALIENTES = 100 conexiones

RECURSOS PARA CORREO CON RECHAZO PERMANENTE = 0%

EFICIENCIA DE ENTREGA = 100%

 

En este caso ideal, vemos que todo el correo recibido por Postfix es entregado hacia su destino. Al haber 0 correos con rechazo permanente, podemos concluir que las conexiones de salida se están utilizando y explotando de la forma más eficiente ya que cada conexión resulta en una entrega exitosa.

 

Veamos el siguiente ejemplo:

CONEXIONES ENTRANTES = 100 conexiones

CONEXIONES SALIENTES = 90 conexiones

CORREO ENTREGADO HACIA INTERNET = 80 correos

CORREO CON RECHAZO PERMANENTE = 10 correos

RECURSOS PARA CORREO CON RECHAZO PERMANENTE = 11%

EFICIENCIA DE ENTREGA = 80%

 

En este caso un poco más real observamos que de los 100 correos recibidos sólo estamos entregando 80. De los 20 restantes, 10 correos no podrán ser entregados, lo que representa el 11% del total de conexiones gastadas innecesariamente. A pesar de que esta tasa pudiera parecer pequeña, tome en cuenta que esos 10 correos corresponden al 50% de los 20 correos que no fueron entregados a Internet, por lo que si se pudiera hacer algo para disminuir este número, la EFICIENCIA DE ENTREGA podría subir hasta un 90%, lo que ya representaría una mejora considerable.

 

En el siguiente punto desarrollamos el método para determinar si es posible disminuir este valor ó si se trata de algo imputable a la operación de la Organización.

 

 

2.1. Identificar si en las causas de rechazo permanente hay algo que se pueda hacer en el equipo para bajar el número.

En este punto es donde los números y las interpretaciones comienzan a complicarse un poco más. Para explicarlo mejor, utilizaremos los indicadores obtenidos previamente con valores más cercanos a la realidad:

NUMERO DE CONEXIONES ENTRANTES = 800,000

NUMERO DE CONEXIONES SALIENTES = 1,000,000

NUMERO DE CORREO ENTREGADO HACIA INTERNET = 180,000

CORREO CON RECHAZO PERMANENTE = 48,000

Correo rechazado porque el buzón no existe = 42,000

Correo rechazado porque el dominio no existe = 6,000

RECURSOS PARA CORREO CON RECHAZO PERMANENTE = 4.8%

EFICIENCIA DE ENTREGA = 22.5 %

Puntos importantes para interpretar estos resultados:

a)      Antes que nada se observa que la EFICIENCIA DE ENTREGA es extremadamente baja, sólo el 22.5% de todo el correo entrante es entregado. Sin embargo aún no se puede concluir que este número es malo hasta no saber el valor de las tasas restantes, pero es algo que debemos tomar en mente para interpretar los demás resultados.

b)      Se observa que hay más conexiones salientes que entrantes, ¿cómo es esto posible? ¿Cómo es que Postfix entrega más correo del que recibe? Aunque puede parecer ilógico, estos números indican claramente un problema de encolamiento excesivo. El que haya más conexiones salientes que entrantes, significa que para cuando llegaron los 800,000 correos nuevos, ya había cierto número de correos encolados gastando conexiones salientes para poder ser entregados, e incluso aunque no hubiera correos previos, recuerde que un correo con rechazo temporal genera al menos dos conexiones, por lo que el número de conexiones salientes generalmente puede ser superior al número de conexiones entrantes.

c)       La tasa de RECURSOS PARA CORREO CON RECHAZO PERMANENTE es baja, sólo el 4.8% de las conexiones se están utilizando para tratar de entregar correo que no será aceptado por el destinatario, por lo que no representa un valor significativo para afectar la entrega de correo.

d)      Existen al menos dos motivos por lo que estos 48,000 correos no pueden ser entregados y es que el dominio ó el buzón no existen. Ambos problemas se pueden atacar evitando que dichos correos entren a Postfix, ya que en estos casos es seguro que el correo nunca será entregado.

¿Cómo sabemos que el dominio no existe? Si se saca el Top Ten de los dominios inexistentes usando el DSN 5.4.4 podrá ver diversas descripciones, todas ellas indicando que no se puede entregar correo a ese dominio porque no hay ningún registro ni MX ni A en ningún DNS público que nos diga cuál es la dirección IP a la que se entregan los correos cuyos destinatarios viven en ese dominio. Tome como ejemplo la siguiente lista:

dsn=5.4.4, name not found. Name service error for name=webhostdb.webtelmex.net.mx type=A: Host not found)

dsn=5.4.4, name not found. Name service error for name=mx1.starmedia.com type=A: Host not found)

dsn=5.4.4, name not found. Name service error for name=mx.terra.es type=A: Host found but no data record of requested

dsn=5.4.4, name not found. Name service error for name=prodigy.mx type=A: Host not found)

dsn=5.4.4, name not found. Name service error for name=multi-net.com.mxtype=A: Host not found)

 

Si se realiza un query por el registro MX y el  registro A de estos dominios verá que ambas respuestas indican que no existen dichos registros por lo que se puede asumir que los correos que van a estos dominios no podrán ser entregados.

¿Cómo saber si los buzones no existen? Aplicando los mismos filtros vistos en la Parte I sobre la obtención de indicadores, podrá ver líneas del maillog similares a la siguientes:

dsn=5.0.0, 550 Requested action not taken: mailbox unavailable (in reply  to RCPT TO command))

dsn=5.0.0, 550 #5.1.0 Address rejected. (in reply to RCPT TO command))

dsn=5.0.0, 550 User unknown (in reply to RCPT TO command))

dsn=5.0.0, 550 Unrouteable address (in reply to RCPT TO command))

dsn=5.0.0, 550 No Such User Here (in reply to RCPT TO command))

dsn=5.0.0, 550 Relay not permitted / No such user (in reply to RCPT TO command))

dsn=5.0.0, 554 Sorry, no mailbox here by that name. (#5.1.1) (in reply to RCPT TO command))

dsn=5.0.0, 550 no mailbox by that name is currently available (in reply to RCPT TO command))

 

Además de estas dos razones, puede haber otras como lo muestra la siguiente lista de DSN con respuestas de rechazo permanente:

dsn=5.0.0, EL BUZON NO EXISTE

dsn=5.4.4, EL DOMINIO NO EXISTE

dsn=5.1.1, EL BUZON O EL ALIAS INDICADO NO EXISTEN

dsn=5.2.1, EL BUZON EXISTE PERO ESTA DESHABILITADO

dsn=5.7.1, EL BUZON NO PUEDE RECIBIR CORREO YA SEA POR RELAY NO AUTORIZADO O POR QUE EL CORREO O LA IP HAN VIOLADO UNA POLITICA DE SEGURIDAD

dsn=5.3.0, EL BUZON NO EXISTE O EL SERVIDOR DE CORREO NO PUEDE ACEPTAR CORREO PARA ESE USUARIO POR VIOLACION DE POLITICAS

dsn=5.7.0, EL CORREO O LA IP HAN VIOLADO UNA POLITICA DE SEGURIDAD

dsn=5.4.1, EL SERVIDOR NO ACEPTA LA CONEXION POSIBLEMENTE POR UNA VIOLACION DE RELAY

 

En todos los casos, el correo no será aceptado, sin embargo, se puede observar que algunos de ellos hacen referencia a errores del servidor o aplicación de políticas donde no necesariamente todos los correos serían rechazados. Por ejemplo, en el DSN 5.7.0, no se puede tener certeza de si sólo el buzón del sender de ese correo en particular es el que ha violado la política o si todos los senders de Postfix están bloqueados. Debido a esto, cuando se realizan acciones para mitigar estos bloqueos es conveniente tomar en cuenta sólo aquellos códigos que nos aseguran una condición donde el rechazo del correo siempre se hará, independientemente de nuestra IP, del contenido del correo o del usuario que lo envía. Suponga por ejemplo, que el servidor de hotmail.com lo tiene bloqueado y envía miles de códigos 5XX, la solución no puede ser bloquear los correos que vayan hacia hotmail.com sino corregir la condición por la cual el dominio ha bloqueado la IP de Postfix.

 

3.       Evaluar la tasa entre correo entregado y correo rechazado temporalmente para ver si hay un impacto significativo.

Este valor es uno de los más importantes porque nos ayuda a determinar si existe un problema de encolamiento, su magnitud y si hay algo que podamos hacer para mitigarlo. En sistemas de correo, la mayor degradación de desempeño, se da cuando el servidor acumula una cantidad de correo excesiva que gasta conexiones y no permiten la entrega de correo legítimo.

La siguiente fórmula nos muestra cómo obtener esta tasa:

RECURSOS PARA CORREO CON RECHAZO TEMPORAL = CORREO CON RECHAZO TEMPORAL /  NUMERO DE CONEXIONES SALIENTES

Ahora agregaremos más valores al ejemplo mostrado anteriormente:

NUMERO DE CONEXIONES ENTRANTES = 800,000

NUMERO DE CONEXIONES SALIENTES = 1,000,000

NUMERO DE CORREO ENTREGADO HACIA INTERNET = 180,000

CORREO CON RECHAZO PERMANENTE = 48,000

Correo rechazado porque el buzón no existe = 42,000

Correo rechazado porque el dominio no existe = 6,000

RECURSOS PARA CORREO CON RECHAZO PERMANENTE = 4.8%

CORREO CON RECHAZO TEMPORAL = 850,000

Correo rechazado por time out o rechazo de conexión = 750,000

Correo rechazado por otras razones = 100,000

RECURSOS PARA CORREO CON RECHAZO TEMPORAL =  85%

EFICIENCIA DE ENTREGA = 22.5 %

Ahora que tenemos más datos, es evidente que el bajo desempeño de este equipo se debe a que está ocupando el 85% de las conexiones salientes en entregas que no han sido satisfactorias pero cuyo reintento podría provocar una entrega exitosa. A diferencia del 4.8% de los RECURSOS PARA CORREO CON RECHAZO PERMANENTE, aquí es claro, que si se ataca el problema de encolamiento, el equipo logrará una mejora significativa.

En este punto es necesario entonces, determinar cuál es la causa del encolamiento y si existe alguna modificación que se pueda hacer en Postfix para mejorar el desempeño. Para esto utilizaremos los indicadores obtenidos en la Parte I Obtención de Indicadores, utilizando las razones por las cuáles se encola el correo.

La primer causa, como se muestra en los números del ejemplo es que casi el 90% de los correos encolados se debe a errores de conexión, ya sea porque la conexión dio timeout o porque la conexión fue rechazada. Ambos casos se observan cuando se obtienen líneas como las siguientes en el maillog filtrando por el DSN 4.4.1:

dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hayoo.com[208.91.197.26]: Connection timed out)

dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hootmail.com[64.4.6.100]: Connection timed out)

dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to msn.com.mx[65.55.206.229]: Connection timed out)

dsn=4.4.1, status=deferred (connect to yahoo.com.mx.com.mx[208.87.35.103]: Connection refused)

 

Lo que indica este DSN, es que a diferencia de la condición para el rechazo permanente donde no existe ningún registro para el dominio, aquí el dominio sí tiene al menos un registro A público y por regla de correo, si la IP que corresponde a este registro no responde en el puerto 25, se debe encolar el correo hasta que la IP responda o hasta que la vida del correo llegue a su límite.

Observe detenidamente los nombres de los dominios y trate de encontrar tanto el registro MX como el registro A de cada uno de ellos:

hayoo.com. No hay registro MX, el registro A es 208.91.197.26

hootmail.com. No  hay registro MX, el registro A es 65.55.39.10/ 64.4.6.100

msn.com.mx. No hay registro MX, el registro A es 65.55.206.229

yahoo.com.mx.com.mx. No hay registro MX, el registro A es 176.74.176.178

 

Se observa claramente que cuando el usuario tecleó el dominio destino se equivocó en las letras pero sin darse cuenta escribió un dominio que SI existe en Internet! Esta condición es la que provoca el encolamiento y por el indicador obtenido, esta condición está generando casi el 90% del problema de los correos encolados, por lo que atacando únicamente este problema el desempeño del equipo puede elevarse drásticamente.

Ahora bien, es cierto que a pesar de que aquí mostramos ejemplos donde claramente el dominio no recibe correo, hay algunos casos donde el dominio sí existe, pero no puede recibir correo ya sea porque temporalmente no puede procesar más conexiones o porque ha bloqueado temporalmente la IP de Postfix, lo que evita la entrega. Para estar seguros. Es necesario analizar el Top Ten de los dominios que presentan esta condición y confirmar que en efecto el registro MX no existe. En aquellos casos donde el registro MX existe pero no responde al puerto 25 o nos rechaza la conexión una vez establecida, estamos hablando de condiciones legítimas de encolamiento.

Para el primer caso donde el dominio no tiene registro MX, se puede configurar Postfix para que no reciba correos cuyo destinatario esté hospedado en estos dominios. Para el segundo caso hay que investigar cuál es la causa de que nuestra IP esté bloqueada y proceder a corregir esa condición.

 

3.1. Identificar si en las causas de rechazo temporal hay algo que se pueda hacer en el equipo para bajar el número.

No en todos los casos, esta será la condición principal del encolamiento. A continuación presentamos otros errores comunes y la forma de interpretarlos adecuadamente:

DSN=4.4.1. No existe registro MX, pero hay al menos un registro A que provoca el encolamiento

dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hootmail.com[64.4.6.100]: Connection timed out)

Este es el caso previamente estudiado donde el usuario escribió mal el nombre del dominio pero el nuevo nombre SI tiene registrado al menos un registro A en Internet, por lo que el correo debe encolarse a pesar de que nunca podrá ser  entregado. Esta situación se puede corregir sacando el Top Ten de los dominios que están generando este tipo de conexiones para bloquear su entrada y evitar que sean procesados por Postfix.

 

DSN=4.4.3. La petición al DNS marca un timeout, no hay certeza de si el dominio existe o no.

dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=organik.com.mx type=MX: Host not found, try again)

A diferencia de los casos ya vistos, el DSN 4.4.3 indica que hay un problema con la respuesta del DNS, no pudiéndose confirmar con certeza si el dominio existe o no. Este error no genera un código de error permanente porque la respuesta del DNS es distinta. Observe los siguientes ejemplos.

Dominio: ksiflkasdf.com
Respuesta del DNS: *** b.resolvers.Level3.net can’t find ksiflkasdf.com: Non-existent domain
Response Code: 3 (valor binario 11)

maillog1

Dominio: organik.com.mx
Respuesta del DNS: *** b.resolvers.Level3.net can’t find organik.com.mx: Server failed
Response Code: 2 (valor binario 10)

maillog2

Observe que cuando el dominio realmente no existe, el DNS nos arroja una respuesta de “Non-existent domain” con un RCODE 3 (Response Code 3), en este caso, dicha respuesta se interpreta como un error permanente.

Para el segundo caso, la respuesta del DNS es “Server failed” con un RCODE 2. Esto indica que el DNS no fue capaz de completar la búsqueda del dominio. Debido a que este error implica un problema de red, esta condición no puede ser imputable al dominio y es por esto que se genera el encolamiento, pensando que si se reintenta más tarde, la consulta al DNS puede ser exitosa.

Tomando en cuenta que los flags que envía el servicio de DNS pueden ser los valores numéricos 3 y 2 para cada situación, es muy fácil para Postfix interpretar si esa conexión debe provocar un encolamiento o un NDR.

Debido a la falta de certeza se recomienda sacar el Top Ten de los dominios que generan esta situación y hacer un muestreo histórico de al menos una semana ó más tiempo de ser posible. Si durante todo ese tiempo no se observa un sólo correo dirigido a ese dominio que contenga un código DSN distinto al 4.4.3, significa que el servidor Postfix nunca ha podido enviar correo a dicho dominio por lo que podemos hacer un bloqueo de correos hacia ese dominio para evitar que estas conexiones gasten recursos innecesarios. De lo contrario, si se llegara a encontrar que en algún momento logró entregarse algún correo a dicho dominio o generó un código de error distinto significa que en al menos esa ocasión no hubo un error de red imputable al DNS, en este caso estamos ante una situación de encolamiento legítimo y no deberían tomarse acciones dentro de Postfix; si el problema realmente fuera de conexión, se deberá revisar el servicio de DNS que utiliza Postfix para asegurarse de que está trabajando adecuadamente.

En la práctica, más del 95% de las conexiones que generan este error corresponden a dominios que no existen, pero como en todo, estos valores pueden variar de Organización en Organización.

 

DSN=4.7.7. Hay una falla en la integridad del correo ó la IP ha sido bloqueada temporalmente por violar políticas de seguridad.

dsn=4.7.7, status=deferred (host ff-mx-vip1.prodigy.net[207.115.20.20] said: 451 4.7.7 Excessive userid unknowns from 65.82.31.32 flld103 (in reply to MAIL FROM command)))

Esta situación indica claramente que nuestro servidor Postfix ha violado una política de seguridad en el servidor de correo destino, por lo que al menos temporalmente, bloqueará la entrada de nuestro correo a su dominio. La razón por la que el correo está siendo bloqueado es porque nuestro Postfix (IMSVA) está enviando correo con muchos destinatarios que no existen en el servidor destino, por lo que este siente que podemos estar generándole un servicio de DoS y se defiende bloqueándonos el acceso.

Si existe algún sistema automático que envía correos a buzones que no existen en ciertos dominios, la primer acción a tomar es depurar la lista de correos de dichos sistemas para reducir la cantidad de ataques que genera Postfix en esta situación. Otra forma de solucionar el problema es lanzar una campaña en que los usuarios depuren sus listas de correo. Desgraciadamente estas dos acciones recaen sobre un tercero, por lo que el administrador de Postfix tiene un poder limitado en estas medidas. Cuando el problema es muy grave y no contamos con el apoyo de las personas adecuadas se puede lanzar un bloqueo para evitar que estos correos salgan de Postfix. En la Parte 3 Emisión de Recomendaciones veremos los filtros adicionales que necesitamos ejecutar para estas situaciones.

 

DSN=4.7.1. El remitente no está autorizado a enviar correo a ese destino.

dsn=4.7.1, status=deferred (host mx2.terra.com[208.70.188.176] said: 450 4.7.1 You’ve exceeded your sending limit to this domain. (in reply to end of DATA command))

 dsn=4.7.1, status=deferred (host mail.itc.mx[200.23.53.200] said: 450 4.7.1 <postfix.localdomain>: Helo command rejected: Host not found (in reply to RCPT TO command))

 dsn=4.7.1, status=deferred (host shio.sublimeip.com[85.255.209.100] said: 454 4.7.1 <user@dc-os.com>: Relay access denied (in reply to RCPT TO command))

 dsn=4.7.1, status=deferred (host in1-mtp.messagingengine.com[66.111.4.71] said: 451 4.7.1 <user@ml1.net>: Recipient address rejected: User is over quota, try again later (in reply to RCPT TO command))

 dsn=4.7.1, status=deferred (host msgin.t.facebook.com[66.220.155.13] said: 421 4.7.1 RCP-T4  http://postmaster.facebook.com/response_codes?ip=200.33.74.70#unavailable Recipient account is unavailable (in reply to RCPT TO command))

 

Todos estos errores son ejemplos del DSN 4.7.1 que puede tomar varias formas. En general, este código numérico indica una situación donde el emisor (ya sea el usuario o la IP de Postfix) no están autorizados a mandar correo ya sea al buzón destino o al dominio completo.

En el primero ejemplo observamos que el rechazo se da porque nuestro Postfix ha superado el número máximo de correos que puede enviar a ese dominio ya sea en una misma sesión o en una ventana de tiempo determinada. Estos errores implican una situación de encolamiento legítimo donde no es necesario aplicar acciones adicionales en Postfix para corregirla, una vez que pase la ventana de bloqueo Postfix intentará nuevamente la entrega hasta que termine de mandar la totalidad de los correos. Obviamente esta situación puede implicar un retraso en la entrega que puede superar los 30 minutos, sin embargo, a menos de que se pueda controlar el envío por bloques de los usuarios a estos dominios, no hay configuraciones adicionales que puedan ayudar a mitigar esta situación.

El segundo ejemplo muestra un caso donde nuestro servidor Postfix inicia la conversación SMTP enviando el comando HELO con su FQDN como argumento, es decir, Postfix inicia la conversación con una línea similar a esta:

EHLO postfix.localdomain

Hay algunos servidores de correo que antes de responder al saludo, validan si el FQDN que viene en el comando HELO tiene un registro PTR asociado para lo que hace una petición reversa a su DNS. Si la petición reversa no es exitosa, entonces el servidor destino rechaza la recepción del correo. Esta situación se puede remediar agregando una zona reversa en nuestro DNS para el FQDN de Postfix, de tal forma que cuando un dominio haga una petición reversa, esté seguro de que el FQDN realmente existe. Esta validación se hace con el fin de aumentar la probabilidad de que estamos recibiendo correo de un servidor que SI existe, esto puede evitar que cualquier usuario nos mande correo desde su casa por ejemplo haciéndose pasar por facebook.com ó cualquier otro dominio, ya que la petición se hace al DNS que es dueño del dominio al que dice pertenecer el nombre.

El tercer ejemplo muestra una situación donde el servidor destino no tiene abierto el relay para recibir correo del dominio remitente. Esta situación se puede dar cuando una empresa hospeda su  dominio de correo con algún proveedor. Dicho proveedor apunta todos los registros MX de todos sus clientes a su propio servidor de correo y para permitir la recepción de correo de múltiples dominios, configura en su relay a todos esos dominios como permitidos. Por ejemplo, suponga que la empresa host.com tiene 5 clientes. Para proveerles el servicio de correo electrónico apunta el registro MX de los 5 dominios a su propio servidor de correo permitiéndoles el acceso en el relay.

Host.com – Registro MX = 10.98.3.4
   Cliente1.com – Registro MX = 10.98.3.4
   Cliente2.com – Registro MX = 10.98.3.4
   Cliente3.com – Registro MX = 10.98.3.4
   Cliente4.com – Registro MX = 10.98.3.4
   Cliente5.com – Registro MX = 10.98.3.4

 

Ahora suponga que el cliente5.com deja de pagar el servicio. En este caso el proveedor cierra el relay para este dominio, pero si olvida eliminar el registro MX, todos los correos que vayan hacia este dominio seguirán llegando a la IP 10.98.3.4, cuando el servidor de correo valida el dominio del destinatario, se observa que ese dominio ya no tiene permitido el relay, lo que provoca el  rechazo. Otra situación es donde tanto el relay como el registro MX se eliminan de los datos del proveedor, sin embargo, también puede pasar que el caché de los servidores DNS, o de los servidores de correo sigan resolviendo la misma IP sin necesidad de hacer la consulta al DNS público por lo que no tienen forma de saber que el dominio ya no está hospedado en dicha IP. Finalmente también  puede ocurrir que el servidor de correo tenga configurado un Smart Host para entregar siempre el correo de ese dominio a esa IP sin realizar nunca una consulta de DNS, por lo que tampoco tiene forma de saber que el dominio ya no vive en esa IP. Para corregir esta situación se puede configurar a Postfix para rechazar los correos que van dirigidos a estos dominios, sin embargo se debe tener mucho cuidado de mantener un monitoreo de dichos dominios ya que aunque por el momento el dominio no recibe correo en esa IP, en un futuro podría contratar un servicio similar con otro proveedor y una IP distinta. Si mantenemos el bloqueo y no verificamos esta parte, en un futuro, cuando el dominio vuelva a ser capaz de recibir correo, nuestros usuarios comenzarán a quejarse de que los correos no llegan.

El cuarto ejemplo muestra un caso donde el buzón destinatario existe pero no es capaz de recibir correo porque ha superado el máximo de almacenamiento que tiene configurado. Suponga un caso donde los usuarios de la Organización tengan un límite de 100MB, una vez que lleguen a este límite, el buzón no podrá recibir ningún correo adicional. En estos casos el rechazo es temporal porque el destinatario puede liberar correo en cualquier momento lo que provocaría que un intento futuro termine en una entrega exitosa. Esta situación refleja una situación de encolamiento legítimo por lo que no hay acciones que se puedan tomar en el servidor Postfix para corregirla. Si esta situación genera un problema de encolamiento crítico, se podría disminuir el tiempo de vida de los correos de Postfix aunque esta configuración no resuelve el problema raíz.

El quinto y último ejemplo muestra una situación donde  el buzón destinatario no está disponible para recibir correo en ese momento. Puede haber varias situaciones para generar este error, entre ellas el que haya un mantenimiento  en el servidor de correo, la cuenta está deshabilitada porque el usuario ya no trabaja en la empresa, se está realizando una auditoría sobre el buzón, se está haciendo alguna investigación legal sobre el dueño de la cuenta, tareas de mantenimiento en el servicio de LDAP, etc. En esta situación no se recomienda realizar acciones de Postfix porque aunque no hay certeza de si el buzón existe o no, es preferible mantener dicho correo encolado y mantener un monitoreo constante para ver si en cierto período de tiempo el correo sigue siendo rechazado.

Si necesita interpretar otros códigos de estado distintos a los aquí mostrados puede revisar nuestro post sobre Códigos de status extendidos (SMTP).

 

4.       Evaluar la tasa entre correo entregado y correo eliminado / enviado a cuarentena por la aplicación de políticas.

Este valor nos da la eficiencia de la configuración de nuestras políticas de seguridad. Su valor corresponde a la siguiente fórmula:

EFICIENCIA DE FILTRADO = (CONEXIONES ENTRANTES – CORREO CON RECHAZO PERMANENTE – CORREO CON RECHAZO TEMPORAL – CORREO ENTREGADO HACIA INTERNET) / CONEXIONES ENTRANTES

En el ejemplo que hemos venido manejando, la tasa sería la siguiente:

CONEXIONES ENTRANTES = 800,000

CORREO CON RECHAZO PERMANENTE = 48,000

CORREO CON RECHAZO TEMPORAL = 450,000

CORREO ENTREGADO HACIA INTERNET = 180,000

EFICIENCIA DE FILTRADO = (800,000 – 48,000 – 850,000 – 180,000) / 800,000 = 15 %

Observe que en este caso, para el indicador de CORREO CON RECHAZO TEMPORAL no tomamos en cuenta el número de conexiones, ya que como se explicó en la Parte I, cuando hay rechazo temporal el número de conexiones siempre es mayor al número total de correo, si evaluamos el número de conexiones, entonces los números no nos dirían exactamente cuántos correos han sido filtrados, e incluso podría darnos una tasa negativa.

El valor que obtuvimos indica que estamos deteniendo un 15% de todos los correos que entran a Postfix (IMSVA) al aplicarse las políticas que tenemos configuradas. Este es un buen valor, pero también debe tomarse en cuenta que el número puede estar alterado, ya que en nuestro caso, el número de correos con rechazo temporal no es exacto. Observe lo siguiente:

Supongamos que nuestro Postfix no tiene ningún correo encolado y en cierto momento recibe los 800,000 correos nuevos. De estos, 48,000 se eliminan por rechazo permanente y 450,000 por rechazo temporal, además de entregar 180,000 directo a Internet. Esto significa que del total de correos que entró, 122,000 no lograron salir y no aparecen registrados en las conexiones de salida. Esto es, porque al ser eliminados o enviados a cuarentena, esos correos salen del flujo normal de Postfix y es como si desaparecieran.

Ahora supongamos que para el momento en que llegan nuestros 800,000 correos nuevos, Postfix ya tiene 300,000 correos encolados tratando de salir. En este punto no podemos estar seguros de cuántos de los 122,000 correos filtrados corresponden a los correos nuevos y cuántos a los correos que ya estaban dentro de Postfix.

Si quisiéramos ser muy estrictos y necesitáramos encontrar el valor exacto de la EFICIENCIA DE FILTRADO, entonces podríamos sacar la lista de los 800,000 Internal ID’s que corresponden a los correos nuevos, después sacamos la lista de todos los Internal ID’s de todos los correos con rechazos y los entregados a Internet. Si sacamos la diferencia de ambos listados, sabremos exactamente cuántos, de los correos nuevos, fueron filtrados por nuestras políticas.

Retomando lo que mencionamos al inicio sobre la tasa de Eficiencia, recuerde que no existe una regla para saber cuál es el valor adecuado, sin embargo mencionábamos que un valor de referencia adecuado puede ser el 80%. Aquí hay que aclarar que este número debe obtenerse como lo hicimos aquí, es decir, el número de correos con rechazo temporal debe ser exactamente el número de correos y no el número de conexiones ya que de otra forma se estaría alterando el valor de la tasa y la interpretación del desempeño podría ser errónea.

Para que este valor sea considerado bueno o malo, es recomendable que obtenga la tasa en diferentes puntos, al menos una vez por mes. De esta forma, se puede evaluar cuál es el comportamiento normal del equipo y se puede evaluar de forma más objetiva si las recomendaciones aplicadas han surtido un efecto positivo y en qué medida han ayudado a mejorar el desempeño del equipo.

 

5.       Identificar si hay un retraso significativo en la entrega de correo.

El último valor para poder generar un contexto general de todos nuestros datos es el tiempo que tardan los correos en ser liberados cuando se presenta una situación tanto de rechazo permanente o temporal. También se puede obtener el indicador para la velocidad de entrega de correo entregado hacia Internet, pero si las velocidades de entrega de los dos indicadores que tenemos son adecuadas, de forma implícita, el correo entregado a Internet exitosamente debe tener una velocidad adecuada también.

Para saber si hay un retraso significativo tomaremos en cuenta los indicadores para ambos casos. A continuación presentamos los indicadores del ejemplo que hemos manejado:

CORREO CON RECHAZO PERMANENTE

Tiempo promedio de vida antes del rechazo = 8 horas

Tiempo máximo de vida antes del rechazo = 10 días

Tiempo mínimo de vida antes del rechazo =60 segundos

CORREO CON RECHAZO TEMPORAL

Tiempo promedio de vida antes del rechazo = 6 días

Tiempo máximo de encolamiento = 14 días

Tiempo mínimo de encolamiento = 25 segundos

Observamos claramente que en ambos casos el tiempo que el correo pasa dentro de Postfix antes de ser rechazado es muy alto, siendo el de correo rechazado de 8 horas en promedio y el temporal de 6 días. Esto representa un grave problema y confirma además el bajo desempeño que tiene el equipo para liberar correo. Los tiempos de mínimo y máximo nos ayudan a ubicar en qué banda de tiempo se encuentra la mayor cantidad de correo.

Para el rechazo permanente observamos la mayor cantidad de correo debe estar esperando entre 2 y 16 horas antes de ser rechazado y generar el NDR. Para el rechazo temporal observamos que la mayor cantidad de correo debe estar entre 5 y 7 días lo que seguramente está generando un gasto excesivo tanto de almacenamiento como de conexiones. Este último número está provocando un cuello de botella que no permite que el correo legítimo pueda ser entregado.

Para tener una referencia. Un buen valor promedio para estos indicadores debe estar por debajo de los 60 segundos, pudiendo alcanzar incluso unos cuantos milisegundos. Dependiendo de la Organización, se puede tener una tolerancia de hasta 10 minutos cuando los equipos no están bien dimensionados y la carga de correo supera los recursos físicos del servidor, pero incluso en esos casos es necesario proponer ajustes ya que tarde o temprano presentarán algún problema crítico de encolamiento.

Con esta información queda claro que el mayor problema de este equipo es el encolamiento excesivo de correos con rechazo temporal y que la velocidad de entrega es extremadamente baja. Tome en cuenta que un correo encolado puede tardar hasta 14 días en ser entregado! A la tasa de entrega actual, el servidor tardaría meses tan sólo en liberar el correo actualmente encolado y esto si el equipo no recibiera correo nuevo.

 

6.       Resumen

A lo largo de este Post hemos evaluado cada uno de los indicadores obtenidos en la Parte I de esta serie. Como resultado, contamos ahora con un diagnóstico que nos indica en primer lugar si nuestro equipo Postfix / IMSVA se está comportando adecuadamente, si está siendo eficiente en la aplicación de políticas y sobre todo si  está entregando correo dentro de límites aceptables.

Vimos también cómo investigar e interpretar los diferentes códigos de estado SMTP que nos ayudarán en la siguiente parte para emitir recomendaciones que ayuden a mitigar dichos problemas, explotando al máximo el equipo realizando una configuración óptima.

Como conclusión del ejemplo analizado aquí podemos rescatar los siguientes puntos:

  1. La tasa de eficiencia de entrega es muy baja.
  2. La mayor problemática es un encolamiento excesivo de correos principalmente porque se está procesando correo dirigido a dominios que no existen y en su caso, es posible realizar configuraciones dentro de Postfix para remediarlos y mejorar el desempeño.
  3. El tiempo de encolamiento está dentro de rangos no aceptables, ya que un correo puede tardar hasta 14 días en ser entregado y esto genera a su vez que el correo nuevo no pueda ser procesado en tiempo.

 

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!

 

One thought on “Análisis del archivo Maillog para Postfix e IMSVA (Parte II)

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

Comments are closed.