Análisis de correo electrónico rebotado

Actualmente estoy teniendo un lío con la captura, análisis y clasificación de correos electrónicos devueltos. Tengo los elementos básicos configurados muy bien y hace lo que quiero, lo que es bueno … el problema es que parece que no hay un estándar para los mensajes devueltos en el correo electrónico devuelto.

Por ejemplo, algunos servidores devuelven el código de error según lo especificado por RFC 1893 y puedo nueve veces de cada diez recogerlo a través de una simple expresión regular. Pero a veces los servidores simplemente responden diciendo que el correo electrónico ha rebotado, sin motivo alguno o con un motivo redactado de manera completamente diferente a cualquier estándar.

Así que supongo que mi pregunta es, ¿alguien tiene alguna solución para esto? No quiero buscar mil millones y una cadena posible en el correo electrónico devuelto para ser honesto. Sin embargo, sería bueno no tener que recurrir a “razón desconocida” o algo similar.

¿Alguien más ha tenido suerte con esto o con las ideas? Aclamaciones

Puede configurar el sistema para que un operador pueda revisar mensajes, seleccionar cadenas y luego categorizar desde allí. Eventualmente, puede esperar obtener ese 1 en 10 hasta 1 en 100 o 1 en 1,000. Sin embargo, siempre habrá más casos de esquina aquí.

Además, no es una respuesta definitiva, pero en un espíritu similar a la respuesta de Kyle, puede usar un filtro de spam basado en bayes / token para “aprender” sobre los mensajes de rebote y luego enrutarlos automáticamente a lo que desee para manejar el correo rebotado.

En otras palabras, tienes una cuenta donde entrenas spamassassin o spamprobe o lo que sea que un montón de diferentes mensajes de rebote (y solo mensajes de rebote) son “basura”, entonces deja que ese sistema de spam sea una segunda línea de filtrado después de lo que sea que hayas desarrollado.

Entonces, digamos que su solución, el primer filtro, encuentra el 90% de los mensajes devueltos. Haga que su sistema haga lo que normalmente hace con los rebotes, luego guárdelos en un buzón de mensajes de rebote, que spamassasin / spamprobe escanea periódicamente para aprender esos mensajes como “basura”.

También tiene spamassassin o spamprobe o lo que sea, como segundo filtro (ejecute en cualquier cosa que el suyo no marque como un rebote) haga su propia estimación de rebote, y lo que considere “basura” (porque usted ha entrenado para piense en rebote = basura), también puede enrutar a su progtwig, etc.

Todavía requiere un poco de revisión manual, pero en teoría debería mejorar cada vez más a medida que dependes del aprendizaje del sistema de correo no deseado para dar cuenta de los casos límite.

Nos enfrentamos al mismo problema, pero tampoco encontramos ninguna solución “perfecta”. creo que usted

  • podría utilizar algún proveedor de servicios (con una API de correo adecuada); esto le permitiría “subcontratar” el problema y obtener una alta tasa de detección o
  • use un filtro simple para capturar al menos (digamos) el 80% de los rebotes. En nuestra configuración , esto fue suficiente para mantener nuestra base de datos en un estado razonable.
Intereting Posts