Depuis le numéro 59, les Mongueurs de Perl vous proposent tous les mois de découvrir les scripts jetables qu’ils ont pu coder ou découvrir dans leur utilisation quotidienne de Perl. Bref, des choses trop courtes pour en faire un article, mais suffisamment intéressantes pour mériter d’être publiées. Ce sont les perles de Mongueurs.

Inspecter /var/log/mail.log avec Parse::Syslog::Mail

Tout est de la faute du spam

<mavie> Mon fournisseur d’accès à Internet a décidé récemment de mettre en place l’authentification SMTP, afin de réduire le spam et la propagation des virus. L’idée est que les virus ne connaîtront pas l’utilisateur et le mot de passe et que leurs messages seront donc refusés (je pense qu’il suffit d’attendre une ou deux générations de virus pour voir apparaître des virus qui utiliseront l’authentification configurée dans Outlook, et tous ces efforts n’auront servi à rien). Hélas, je n’ai jamais reçu d’email ou d’annonce d’aucune sorte de leur part pour me prévenir des modifications. C’est donc quand j’ai commencé à voir le contenu de ma mail queue se remplir avec des messages comme le suivant que je me suis douté de quelque chose. Après avoir changé temporairement de relais SMTP pour pouvoir communiquer avec le support, j’ai reçu l’explication suivante : "Nous accusons réception de votre demande concernant l’utilisation de votre logiciel de messagerie et vous informons que depuis le 3 janvier, nous avons modifié le numéro de port sortant des mails. Devant les nombreux spams envoyés sur les adresses mails et les virus, nous avons sécurisé l’envoi des e-mails en mettant en place la dépose authentifiée des emails. Dorénavant, le numéro de port sortant est le 587 au lieu du 25. Nous vous invitons à faire cette modification sur votre logiciel Postfix, pour tous les comptes mails utilisés." Après un bref haussement d’épaules (changer le port, c’est une mesure de sécurité ?), j’ai reconfiguré Postfix. Le mail partait enfin. Je croyais mon problème résolu. Au bout de quelques jours, j’ai constaté que si les mails partaient bien, ils ne semblaient pas atteindre leur destination... Un bref coup d’œil au fichier /var/log/mail.log a confirmé mes soupçons : Le message 530 philippe.bruhat@free.fr There is an error in your configuration. More info at www.tele2mail.com (in reply to MAIL FROM command) est assez inquiétant. En me connectant à la page web en question, j’ai donc découvert qu’il me fallait, en plus du changement de port, utiliser le nom d’utilisateur et le mot de passe de mon webmail chez eux (que je n’utilise jamais). Avec l’aide de http://www.postfix.org/SASL_README.html#client_sasl, j’ai pu reconfigurer mon Postfix pour l’envoi de mails. Normalement, tout remarche correctement. </mavie>

Et /var/log/mail.log, c’est le foutoir!

Le plus étonnant dans cette affaire, c’est que je n’ai reçu aucun bounce... Jusqu’à ce que je regarde plus attentivement les lignes de log qui suivent le rejet d’un message : Les bounces étaient renvoyés à mon adresse d’expéditeur, en utilisant le même relais qui a refusé le message original. Les mêmes causes produisant les mêmes effets, les bounces ont donc fini avec mes autres envois, au fin fond de /dev/null. Tous les mails que j’ai envoyés avec la mauvaise configuration de Postfix ont donc été perdus. Heureusement, comme je garde toujours une copie en Fcc: (Folder Carbon-copy) des messages envoyés, je peux les retrouver pour les renvoyer. Il suffit de retrouver les Message-Id des messages perdus dans le /var/log/mail.log. Et c’est maintenant que nous allons enfin utiliser Perl... :-) Comme nous l’avons vu ci-dessus, les logs de Postfix sont éclatés sur plusieurs lignes, en fonction du sous-système qui manipule le message. Pour faire mes recherches, j’aimerais plutôt disposer d’une structure de données simple qui contient toute l’information concernant un message. C’est ce que permet de faire le module Parse::Syslog::Mail, créé par un de mes camarades mongueurs, Sébastien Aperghis-Tramoni. Ce module lit les logs syslog et en extrait les informations produites par les différents serveurs de messagerie. Pour des raisons de performance, Parse::Syslog::Mail ne fait aucune agrégation des logs qui correspondent au même message. Il se contente juste d’éclater chaque ligne de log dans un HASHREF en mettant à jour le plus d’informations possible. Le script suivant réalise l’agrégation des informations correspondant au même message, à l’aide du champ id (qui est différent du champ Message-ID de SMTP). Ceci va permettre d’agréger toutes les informations (on a vu dans les extraits de log ci-dessus que des informations comme le to et le from ne sont pas sur les mêmes lignes de log). Attention cependant, des champs comme text ou status existent et sont différents pour chaque sous-système de Postfix ; pour un même message, les plus récents écraseront donc les plus anciens. Cette opération d’agrégation est coûteuse en mémoire, car on ne peut pas savoir avec certitude quand on a vu tous les logs concernant un message en particulier, et on ne peut donc définir de critère pour le supprimer de la structure d’agrégation. Ma semaine de logs contenant un peu moins de 8000 messages, c’est tout à fait acceptable. Les messages perdus sont détectés grâce au statut bounced. Les messages du mailer-daemon étaient envoyés avec un from à <>, et sont donc ignorés. Une agrégation supplémentaire est réalisée cette fois sur le champ Message-ID (ou msgid pour Parse::Syslog::Mail) afin de n’avoir qu’un bloc d’information par message effectivement envoyé. En tant que root, on crée un flux avec tous les logs et on l’envoie sur notre script : J’ai pu ainsi retrouver les 15 messages perdus pendant ces deux jours, et les renvoyer à leurs destinataires. Ouf !

À vous !

Envoyez vos perles à perles@mongueurs.net. Elles seront peut-être publiées dans un prochain numéro de Linux Magazine.