Bonjour,
Prélude
J’ai mis « Supervision » entre guillemets car c’est un peu prétentieux vu l’outil.
Introduction
Il vous est certainement arrivé de constater des indisponibilités ou des lenteurs de votre boite email.
Quand c’est occasionnel on patiente, quand c’est récurrent on contacte le support client de l’hébergeur. Le dialogue avec le support des différents opérateurs/hébergeurs est souvent compliqué sur ce genre de problème de qualité et d’évènements intermittents.
Afin de pouvoir dialoguer avec eux et avoir une vue objective, il faut quantifier et avoir des données fiables. D’où le développement de ce petit outil qui teste les connexions à un ou plusieurs serveurs SMTP/IMAP et génère un historique.
Principe
On interroge le serveur et on journalise le succès et le temps de réponse. Concrètement, cela envoie un e-mail en SMTP à sa propre adresse et ensuite ça l’efface en IMAP. On valide donc le fonctionnement (liaison et authentification) et on mesure les temps pour les deux protocoles.
L’outil se contente de générer les données sous forme d’un historique au format CSV. Chacun pourra ainsi l’exploiter avec un tableur (Libre Office Calc, Excel, OnlyOffice, Calligra Sheets, etc.) pour obtenir ce qui l’intéresse (temps de réponse moyen/max/min) ou taux d’erreur…
Usage
C’est un outil en ligne de commande qui possède un fichier de configuration en JSON.
Selon la configuration, une fois lancé il fonctionne de manière perpétuelle en interrogeant toutes les X minutes. Si on veut que cela fonctionne automatiquement, il faut le déclarer en service sous Linux ou dans une tache planifiée au démarrage de la machine sous Windows.
Les commandes sont les suivantes :
-
-a: ajout d’une boite à lettre à tester -
-l: liste les boites configurées -
-d: suppression d’une boite configurée -
-u: permet de lancer une exécution unique même si la config indique un mode perpétuel.
Configuration
Le fichier JSON est crée automatiquement lors de la première utilisation.
-
AskMin: interrogation toutes les X minutes. Par défaut=0=Interrogation unique -
CSVName: le nom du fichier de sortie. Par défaut="MailServerMonitor.csv".
Pour chaque boite :
-
eMail: l’e-mail à tester en envoi/réception -
TimeOutMs: Time out in millisecondes, par défaut=30000 -
ServerName: le nom du serveur ou son IP -
Login: nom d’utilisateur pour l’authentification -
EncryptedPassword: utiliser la commande-apour le créer -
ImapPort: le port IMAP, par défaut=993 -
ImapSSL: pour utiliser SSL/TLS, par défaut=true -
SmtpPort: le port SMTP, par défaut=465 -
SmtpSSL: pour utiliser SSL/TLS, par défaut=true
Exploitation
L’historique contient une ligne par test pour chaque serveur configuré.
Le fichier dont le nom est paramétrable contient en entête les noms des colonnes.
On y trouve :
- le nom/ip du serveur
ServerName - l'e-mail de la boite
eMail - la date et heure de l’évènement
EventDateTime - si l'envoi et la réception on abouti
SendRecieveOk - si le serveur SMTP fonctionne
StmpConnected - le temps de réponse du serveur SMTP
SmtpResponseTimeMs - le message d’erreur associé au SMTP en cas d’erreur
SmtpError - pareil pour l’IMAP
ImapConnected ImapResponseTimeMs ImapError - le nombre de messages effacés lors de cette session
DeletedCount
MailServeMonitor
C’est son nom et il est OpenSource sur GitHub : MailServerMonitor.
C’est du .Net 6 donc utilisable sous Windows et Linux.
Conclusion
Merci d’avoir lu jusqu’ici.
Si ça peut vous servir le monde de l’Open Source et ma modeste contribution ne seront pas inutiles.
Pour les commentaires, ci-après ou GitHub
Aller plus loin
- Source et Package de l'outil (118 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comptes SMPT / IMAP différents
Posté par Philippe GRAILLE . Évalué à 2.
Pas à ce jour.
J'y ai pensé mais je me suis contenté de répondre à mon besoin pour l'instant :)
Avec plaisir.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comptes SMPT / IMAP différents
Posté par Philippe GRAILLE . Évalué à 1.
Je vais créer une discussion sur le GIT cela sera plus approprié.
Sinon:
Le X minutes c'est l'attente entre les tentatives, effectivement dérive du temps liée à l'exécution des tests. En pleine connaissance de cause, j'ai laissé comme ça n'ayant pas besoin d'une grande précision.
Le timeout est configurable dans le config.json
Pas de réentrance puisque mono thread et séquentiel.
Pour la boite d’envoi, effectivement bonne remarque, cela doit dépendre de ce qu'il y a au bout.
Dans mon cas c'est un Exchange, probable qu'il conserve les messages envoyés.
A vérifier donc.
Pour la séparation, le plus simple est de séparer la partie serveur et Authentification pour IMAP et SMTP. Comme ça cela permet d'utiliser des boites différentes en croisant.
Une option serait aussi en cas de panne d’envoyer par un autre serveur une alerte. A voir si cela intéresse du monde.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Pourquoi Yet Another programme ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Des logiciels libres de supervision, il en existe des millions, et tous peuvent tester IMAP et SMTP (par exemple pour ceux qui ont l'API Nagios, il y a les monitoring plugins https://www.monitoring-plugins.org/doc/man/check_smtp.html et https://www.monitoring-plugins.org/doc/man/check_imap.html).
[^] # Re: Pourquoi Yet Another programme ?
Posté par Frédéric Blanc . Évalué à 7.
check_smtp et check_imap, d'après leur description, ne font que s'assurer qu'un socket répond bien (très probablement en vérifiant les premiers échanges du protocole en question). L'outil de Philippe s'assure qu'un mail partant en SMTP est bien reçu en IMAP : la vérification ça plus loin.
[^] # Re: Pourquoi Yet Another programme ?
Posté par Dring . Évalué à 2.
Tout à fait.
Cela dit, ces plugins permettent de spécifier une chaîne à envoyer, et une chaîne à recevoir.
Il est donc possible (mais plus complexe) en théorie de reproduire le comportement attendu.
I.e. :
- envoyer la commande d'envoi de mail depuis le plugin check_smtp, vérifier que la réponse stipule bien qu'il a été envoyé
- envoyer la commande de réception de mail depuis le plugin check_imap.
Ca va surtout dépendre de l'outil de supervision, qui doit être capable de s'assurer de la cohérence entre l'envoi et la réception ; là il faudrait un gars avec de l'expérience Nagios / Shinken / … pour répondre.
On va dire que si c'est pour un particulier ou une PME, la solution présentée ici a de toute façon l'avantage de ne pas demander à devenir un expert supervision juste pour pouvoir mettre le nez de son FAI dans son propre caca.
[^] # Re: Pourquoi Yet Another programme ?
Posté par Jean Gabes (site web personnel) . Évalué à 5.
C'est jouable de passer des valeurs d'un check à un autre dans nagios/shinken/icinga and co, mais après ça peux te poser des contraintes lors de la scalabilité et c'est pas trivial (pas de magie :p ).
Donc le principe d'avoir un check qui fait la vérification de toute la chaine est valable, car vérifier juste que SMTP et IMAP répondent n'est pas suffisant dans la vraie vie.
J'avais un script mode "a l'arrache" dans le passé qui faisait ça, mais clairement en faire un vrai projet a un intérêt :D
[^] # Re: Pourquoi Yet Another programme ?
Posté par gst . Évalué à 2. Dernière modification le 22 mars 2022 à 17:11.
pfiouu.. y a ~20 ans j’étais responsable (entre autre) du monitoring de l'infra email de "Belgacom".
J'avais donc écrit un "check_smtp" custom qui - en plus de faire un login smtp - envoyait un mail a une adresse de test/custom. email dans lequel je passais quelques metadata custom (en plus d'un body plus ou moins long).. comme le timestamp de création/envoi du email lui même.
ce qui me permettait dans des check_(imap|pop) tout autant custom .. de faire une lecture des mails recus dans la boite custom.. et de faire un diff avec le timestamp d’arrivée/d’écriture du mail dans la boite. (ce qui permettait de mesure l’efficacité de toute la chaîne infra email)
KPI quoi ;)
[^] # Re: Pourquoi Yet Another programme ?
Posté par DerekSagan . Évalué à 2.
J'ai déjà fait le même genre de choses, mais pas avec check_smtp et check_imap justement.
Parce que les indicateurs que je voulais c'était "depuis quand il n'y a pas eu d'échange fructueux ?" et "quelle est la durée du roundtrip ?"
Et c'est beaucoup plus facile à coder from scratch.
[^] # Re: Pourquoi Yet Another programme ?
Posté par DerekSagan . Évalué à 10.
https://fr.wikipedia.org/wiki/Principe_KISS
faire un petit outil simple dédié à la fonction, au besoin
vs.
installer un énorme truc comme Nagios, se taper des pages de doc pour y arriver, et ensuite tordre le fonctionnement des testeur de dispo du serveur (check_cmtp, check_imap) pour leur donner une logique stateful permettant de rendre quand même le service dont on avait besoin
[^] # Re: Pourquoi Yet Another programme ?
Posté par Philippe GRAILLE . Évalué à 8.
Probablement parce que je voulais quelque chose de "simple".
Utilisable ponctuellement mais aussi pour faire des stats.
Du souvenir que j'ai de Nagios la courbe d'apprentissage n'est pas compatible avec mon besoin.
[^] # Re: Pourquoi Yet Another programme ?
Posté par Pol' uX (site web personnel) . Évalué à 5.
check_smtp et check_imap fonctionnent indépendamment de nagios. Ce sont des petits utilitaires auxquels tu passes les arguments qui conviennent et ils retournent un code d'erreur et quelques métriques. Le lien avec Nagios n'est que dans le format du code d'erreur (ou de succès) et des métriques.
Sinon pour du debug smtp il y a swaks qui est sympa.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pourquoi Yet Another programme ?
Posté par DerekSagan . Évalué à 2.
C'est pas évident de trouver dans les docs de swaks, check_smtp et check_imap la façon dont on peut vérifier que le mail envoyé en smtp arrive bien jusqu'à la boîte au lettre et peut être lu en imap et le temps que cela prend.
Ils le font vraiment ?
Ou tu proposes des outils qui en plus d'être plus complexe ne font pas le travail ?
[^] # Re: Pourquoi Yet Another programme ?
Posté par Pol' uX (site web personnel) . Évalué à 2.
Sympa l'accueil. :)
Alors d'une part je ne recommande pas spécialement, je précise des éléments pour expliquer que s'attaquer à la complexité check_smtp ne ressemble en aucune mesure à la complexité de s'attaquer à Nagios.
D'autre part swaks est très bien documenté.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pourquoi Yet Another programme ?
Posté par DerekSagan . Évalué à 3.
je pense que t'as pas compris que l'outil de Philippe permet de corréler le message envoyé et le message reçu, ni l'ironie de mon propos sur la doc de swaks, je vais quand même essayer de te le redire de façon imagée mais c'est pas gagné:
[^] # Re: Pourquoi Yet Another programme ?
Posté par Pol' uX (site web personnel) . Évalué à 0.
Qu'est-ce qui te fait penser ça ?
Adhérer à l'April, ça vous tente ?
# Convention
Posté par barmic 🦦 . Évalué à 3.
Je comprends qu'utiliser
EMailt'a gêné mais je trouve du coup le nommage moins cohérent. Est-ce queTarget,RecipientouMailn'aurait pas était mieux ?Sinon l'IETF n'utilise jamais cette convention, mais bien
email/Email(par exemple dans le RFC5321).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# V1.1
Posté par Philippe GRAILLE . Évalué à 2.
La version 1.1 est publiée :
https://github.com/GPh83/MailServerMonitor/releases
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.