Outil d'analyse de journaux SMTP permettant de rechercher des rebonds

Question

Notre application Web envoie des courriels. Nous avons beaucoup d'utilisateurs et nous obtenons beaucoup de rebonds. Par exemple, l'utilisateur change de société et son courrier électronique n'est plus valide.

Pour rechercher des rebonds, j'analyse le fichier journal SMTP avec l'analyseur de journal. Les journaux proviennent du serveur Microsoft SMTP.

Certains rebonds sont intéressants, comme 550+#5.1.0+Address+rejected+user@domain.com . Il y a utilisateur@domaine.fr dans Bounce.

Mais certains n'ont pas d'e-mail dans les messages d'erreur, comme 550 + Non + tel + destinataire .

J'ai créé un script Ruby simple qui analyse les journaux (utilise l'analyseur de journal) pour rechercher le courrier à l'origine de quelque chose comme 550 + Non + tel + destinataire .

Je suis juste surpris de ne pas pouvoir trouver un outil qui le fasse. J'ai trouvé des outils tels que Zabbix et Splunk pour l'analyse des journaux, mais ils semblent excessifs pour une tâche aussi simple.

Quelqu'un connaît-il un outil permettant d'analyser les journaux SMTP, de rechercher les rebonds et les courriers électroniques qui les provoquent?

Answer 1

Cet article correspond exactement à ce que vous recherchez. Il est basé sur le formidable outil analyseur de journaux .

  

L’analyseur de journaux est un outil puissant et polyvalent.   outil qui fournit une requête universelle   accès aux données textuelles telles que le journal   fichiers, fichiers XML et fichiers CSV, tels que   ainsi que des sources de données clés sur le   Système d'exploitation Windows® tel que le   Journal des événements, le registre, le fichier   système et Active Directory®. Vous   indiquez à Log Parser quelles informations vous avez   besoin et comment vous voulez qu'il soit traité.   Les résultats de votre requête peuvent être   format personnalisé dans une sortie texte,   ou ils peuvent être persistés à plus   cibles spécialisées comme SQL, SYSLOG ou   un graphique. La plupart des logiciels sont conçus pour   accomplir un nombre limité de   tâches spécifiques. Log Parser est   différent ... le nombre de façons qu'il peut   être utilisé est limité que par les besoins   et l'imagination de l'utilisateur. le   World est votre base de données avec Log   Analyseur.

Answer 2

Pour autant que je sache, l’analyse des fichiers journaux n’est utile que pour détecter les courriers rejetés au niveau de la session SMTP. Qu'en est-il des rebonds qui se produisent après que le MTA distant a accepté un message pour la remise mais ne le transmet plus par la suite?

Nous utilisons la configuration suivante pour détecter et classer tous les rebonds après leur remise au MTA distant.

1. Tous les courriers sortants reçoivent un en-tête de chemin de retour unique qui, une fois décodé , identifie l'adresse e-mail du destinataire et le mailing en question.

2. Un serveur Apache James qui reçoit le courrier renvoyé à l'adresse du chemin de retour.

3. Un mailet personnalisé, développé en Java et exécuté dans Apache James qui décode l'adresse de destination, envoie le texte de l'e-mail à boogietools bounce studio pour la classification des types de rebonds, puis conserve les résultats dans notre base de données.

Cela fonctionne très très bien. Nous sommes en mesure de détecter les rebonds durs permanents et transitoires qui sont ensuite classés en types de rebond très granulaires tels que les rejets de spam, les réponses d'absence du bureau, etc.

Answer 3

Vous ne voulez pas analyser les journaux pour essayer d'identifier les rebonds. Vous aurez à la fois des faux négatifs et des faux positifs si vous ne regardez que les journaux.

Les rebonds peuvent être générés en aval du serveur sur lequel vous livrez. Ils ressembleront à des livraisons réussies dans les journaux de votre serveur sortant.

La correspondance de modèle naïf pour les rebonds dans les journaux entrants (de l'expéditeur null à l'une de vos adresses VERP-ed) sera inexacte. Il y a plusieurs raisons pour lesquelles:

• Des avertissements de retard seront mélangés aux rebonds d'échec réels.
• La plupart des répondeurs automatiques absents et similaires utilisent l'expéditeur nul pour prévenir le syndrome de Battlin-Bots.
• De même, les systèmes de challenge-response (comme * spit * boxbe.com) ont tendance à utiliser l'expéditeur nul.
• Vos adresses d'expéditeur VERP-ed, si elles sont persistantes par destinataire, seront récupérées par les spammeurs et reviendront sous forme de cibles de spam ou de rétrodiffusion.

Donc, malheureusement, le seul moyen fiable de le faire est d’examiner les messages de rebond eux-mêmes. La plupart d'entre eux auront un "rapport / statut de livraison". Partie MIME selon RFC1894, et selon la langue de votre choix, il existe probablement des bibliothèques ou des modules pour vous aider avec d’autres formats de rebond. Le seul que je connaisse directement est le module Perl Mail :: DeliveryStatus :: BounceParser, qui fonctionne assez bien.

Answer 4

J'aime logParser. Lorsque j'ai besoin d'analyser quelque chose de très spécifique ou personnalisé ou d'utiliser des expressions régulières, j'utilise biterScripting. Ils ont en fait des exemples de scripts que j'avais l'habitude de commencer. L’une d’elles se trouve à l'adresse http://www.biterscripting.com/Download/SS_WebLogParser.txt . .

Answer 5

J'ai basé un programme de compteurs de rebond sur cette publication, mais je me suis aperçu plus tard que cette méthode ne fonctionnait pas pour les expéditeurs à volume élevé, car les journaux SMTP ne sont pas dans un ordre séquentiel. Il y en a plus dans mon billet de blog: Détection de rebond de courrier électronique dans les journaux SMTP et pourquoi c'est impossible .