Pregunta

Nuestra aplicación web envía correos electrónicos. Tenemos muchos usuarios y recibimos muchos rebotes. Por ejemplo, el usuario cambia de compañía y el correo electrónico de su compañía ya no es válido.

Para encontrar rebotes, analizo el archivo de registro SMTP con el analizador de registros. Los registros provienen del servidor SMTP de Microsoft.

Algunos rebotes son excelentes, como 550+#5.1.0+Address+rejected+user@domain.com . Hay user@domain.com en el rebote.

Pero algunos no tienen un mensaje de error en el correo electrónico, como 550 + No + tal + destinatario .

He creado un script Ruby simple que analiza los registros (usa el analizador de registros) para encontrar qué correo causó algo como 550 + No + such + destinatario .

Me sorprende que no haya podido encontrar una herramienta que lo haga. He encontrado herramientas como Zabbix y Splunk para el análisis de registros, pero parecen excesivas para una tarea tan simple.

¿Alguien conoce una herramienta que pueda analizar los registros SMTP, encontrar rebotes y correos electrónicos que los causan?

¿Fue útil?

Solución

Este artículo es exactamente lo que está buscando. Se basa en la gran herramienta analizador de registros .

  

Log parser es un potente y versátil   Herramienta que proporciona consulta universal.   acceso a datos basados ??en texto, como el registro   archivos, archivos XML y archivos CSV, como   así como fuentes de datos clave en el   Windows & # 174; sistema operativo como el   Registro de eventos, el registro, el archivo   sistema y Active Directory & # 174 ;. Tú   dile a Log Parser qué información   necesita y cómo desea que se procese.   Los resultados de su consulta pueden ser   formato personalizado en salida basada en texto,   o pueden persistir a más   objetivos especiales como SQL, SYSLOG, o   una tabla. La mayoría del software está diseñado para   lograr un número limitado de   Tareas específicas. Log Parser es   diferente ... la cantidad de formas en que puede   ser utilizado está limitado solo por las necesidades   e imaginación del usuario. los   mundo es tu base de datos con Log   Analizador.

Otros consejos

Hasta donde puedo ver, el análisis del archivo de registro solo es útil para detectar correos rechazados en el nivel de sesión SMTP. ¿Qué pasa con los rebotes que ocurren después de que el MTA remoto ha aceptado un mensaje para la entrega pero luego no puede entregarlo?

Utilizamos la siguiente configuración para detectar y clasificar todos los rebotes después de la entrega al MTA remoto.

  1. Todos los correos salientes reciben un encabezado de ruta de retorno único que, cuando se decodifica , identifica la dirección de correo electrónico del destinatario y el correo en particular.

  2. Un servidor Apache James que recibe el correo devuelto a la dirección de la ruta devuelta.

  3. Un mailet personalizado, desarrollado en Java y que se ejecuta dentro de Apache James que decodifica la dirección, envía el texto del correo electrónico a boogietools bounce studio para la clasificación del tipo de rebote y luego conserva los resultados en nuestra base de datos.

Funciona muy, muy bien. Podemos detectar rebotes duros permanentes y rebotes blandos transitorios que se clasifican en tipos de rebote muy granulares, como rechazos de correo no deseado, respuestas fuera de la oficina, etc.

No desea analizar los registros para intentar identificar los rebotes. Tendrás falsos negativos y falsos positivos si solo miras los registros.

Los rebotes pueden generarse en sentido descendente desde el servidor al que entregas. Se verán como entregas exitosas en sus registros de servidor salientes.

La coincidencia de patrones ingenua para los rebotes en los registros entrantes (desde el remitente nulo a una de sus direcciones VERP-ed) será inexacta. Hay algunas razones por las cuales:

  • Habrá advertencias de demora combinadas con rebotes de fallas reales.
  • La mayoría de los autorespondedores fuera de la oficina y similares utilizan el remitente nulo para prevenir el síndrome de battlin-bots.
  • Del mismo modo, los sistemas de desafío-respuesta (como * spit * boxbe.com) tienden a usar el remitente nulo.
  • Sus direcciones de remitente VERP-ed, si son persistentes por destinatario, serán recopiladas por los spammers y volverán como destinos de spam o de dispersión inversa.

Lamentablemente, la única forma confiable de hacerlo es examinar los mensajes de rebote. La mayoría de ellos tendrá un " informe / estado de entrega " Parte MIME según RFC1894, y dependiendo del idioma que elija, probablemente haya bibliotecas o módulos para ayudar con otros formatos de rebote. El único con el que tengo experiencia directa es el módulo Perl Mail :: DeliveryStatus :: BounceParser, que funciona lo suficientemente bien.

Me gusta logParser. Cuando necesito analizar algo muy específico o personalizado o usar expresiones regulares, uso biterScripting. De hecho, tienen algunos scripts de muestra que solía comenzar. Uno está en http://www.biterscripting.com/Download/SS_WebLogParser.txt .

Basé un programa de contador de rebote en esta publicación, solo para descubrir más tarde que este método no funciona realmente para los remitentes de alto volumen porque los registros SMTP no están en orden secuencial. Hay más información al respecto en mi blog: Detección de rebote de correo electrónico en registros SMTP y por qué es imposible .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top