Surveiller un serveur de courriel

Ce que vous saurez

• Chaque service de courriel est en ligne, et c’est bien un serveur de courriel qui répond. Le courriel entrant sur le port 25, les applications de courriel de vos utilisateurs sur les ports 587 et 465, et IMAP et POP3 avec et sans TLS. Chaque port a sa propre vérification, qui attend le message d’accueil qu’envoie un vrai serveur de courriel.
• Les certificats ne sont pas sur le point d’expirer. Gryphon avertit 30 jours avant l’expiration d’un certificat sur un port TLS, et signale un problème à 7 jours.
• L’enregistrement MX de votre domaine pointe toujours vers votre serveur. Le courriel va là où l’enregistrement MX l’indique : une erreur à cet endroit fait perdre du courriel, même quand le serveur fonctionne bien.

Une simple vérification de port dirait que le port est ouvert. Ces vérifications lisent aussi ce qui y répond. Si un répartiteur de charge accepte la connexion alors que le serveur de courriel derrière lui est en panne, ou si autre chose a pris le port, le message d’accueil manque et la vérification passe en problème.

Ce que cette configuration ne peut pas vous dire : si le courriel est réellement livré. Un serveur peut accueillir chaque connexion et tout de même renvoyer des messages, garder une file d’attente pleine ou figurer sur une liste de blocage. Ces vérifications surveillent le serveur, les certificats et le DNS, là où commencent la plupart des pannes de courriel.

Avant de commencer

• Le serveur de courriel ajouté comme hôte dans Gryphon, avec son nom public, comme mail.example.com, dans Nom d’hôte ou IP. Chacune des vérifications ci-dessous se connecte à cette adresse.
• Aucun agent. Toutes ces vérifications partent de Gryphon, comme le font les applications de courriel de vos utilisateurs et les autres serveurs de courriel pour le joindre.

Étapes

1Vérifier le courriel entrant sur le port 25

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service et sélectionnez TCP envoi/attente. Cette vérification se connecte et attend le message d’accueil que donne un vrai serveur de courriel ; si c’est nouveau pour vous, le fonctionnement d’envoi/attente l’explique depuis le début.

Nom

SMTP

Port

25

TLS

none

Envoyer (facultatif)

laisser vide

Attendre

220

Intervalle de vérification

Fréquence 3 Minutes

Un serveur de courriel parle en premier. Il accueille chaque connexion par une ligne qui commence par 220, comme 220 mail.example.com ESMTP Postfix : la vérification n’a donc qu’à écouter. Laissez Envoyer vide. Le postscreen de Postfix, et les défenses antipourriel semblables, traitent un client qui parle avant le message d’accueil comme un robot de pourriel.

2Ajouter les autres ports que vous utilisez

Ajoutez une vérification TCP envoi/attente par port, avec un Nom qui dit de quel port il s’agit. Laissez Envoyer vide pour chacune, car tous ces services parlent en premier.

tls établit une poignée de main TLS avant de lire le message d’accueil, et exige un certificat de confiance émis pour le nom de l’hôte, comme le fait une application de courriel. Pour un serveur qui a un certificat autosigné, choisissez tls-no-verify. Les ports 25 et 587 passent à TLS avec STARTTLS après le message d’accueil : on les vérifie donc avec none. Le message d’accueil arrive avant le passage à TLS.

Choisissez le réglage TLS qui correspond au port. Un port TLS vérifié avec none attend un message d’accueil qui ne vient jamais, et échoue après 10 secondes. Un port non chiffré vérifié avec tls échoue à la poignée de main.

3Surveiller les certificats

Ajoutez Certificat SSL une fois pour chaque port qui a son propre certificat :

Port

993

Vérifier le certificat

true

La vérification de certificat parle TLS dès le premier octet : elle lit donc les ports 465, 993 et 995, mais pas 25 ni 587, où TLS commence plus tard. C’est rarement une lacune, car la plupart des serveurs de courriel utilisent un seul certificat pour tous ces ports. Si ce n’est pas le cas du vôtre, les ports TLS vous préviennent tout de même quand chaque certificat approche de son expiration.

4Surveiller l’enregistrement MX

Ajoutez DNS au même hôte :

Serveur de noms

1.1.1.1 — ou le serveur de noms de votre propre domaine

Port

53

Nom à résoudre

example.com

Type d’enregistrement

MX

Protocole

udp

Réponse attendue (facultatif)

mail.example.com

Remplissez Serveur de noms. Laissé vide, ce champ fait interroger l’hôte auquel appartient la vérification, et un serveur de courriel n’est généralement pas un serveur de noms. La vérification réussit quand un enregistrement MX contient le texte attendu, sans tenir compte de la casse ni du point final : mail.example.com correspond donc à 10 mail.example.com.

Faire un essai

1. Utilisez Vérifier maintenant sur chaque nouvelle vérification. Une vérification en bon état indique ce qu’elle a trouvé, par exemple mail.example.com:993 - answered with "* OK" in 41ms.
2. Remplacez la valeur Attendre d’une vérification par quelque chose que le serveur ne dira pas, comme XYZ, et vérifiez-la de nouveau. Elle passe en problème, et le message cite ce que le serveur a réellement envoyé : c’est le moyen le plus rapide de trouver le bon texte pour un serveur dont vous n’êtes pas certain. Remettez ensuite la valeur d’origine.
3. Pour un vrai essai, arrêtez le service IMAP par une soirée tranquille, par exemple avec sudo systemctl stop dovecot. Gryphon revérifie chaque minute et alerte dès que trois vérifications de suite concordent. Redémarrez-le, et le rétablissement est annoncé lui aussi.

Variantes

Microsoft 365 ou Google Workspace

Quand quelqu’un d’autre exploite les serveurs de courriel, vous n’avez rien à vous à quoi vous connecter. Gardez seulement la vérification DNS, en attendant leur hôte MX, comme mail.protection.outlook.com ou google.com. Ajoutez une deuxième vérification DNS avec Type d’enregistrement TXT et Réponse attendue v=spf1, pour savoir quand votre enregistrement SPF disparaît.

Un serveur de courriel que seul votre réseau peut joindre

Pour un relais interne, ou un serveur IMAP derrière le pare-feu, utilisez TCP envoi/attente (agent) sur un hôte qui a l’agent Gryphon. Elle prend les mêmes champs, plus Hôte : l’adresse privée ou le nom interne du serveur, tel que l’agent le voit.

fail2ban et les journaux de connexion

Chaque vérification se connecte, lit le message d’accueil et raccroche : votre journal de courriel s’enrichit donc d’une courte ligne toutes les quelques minutes. Si fail2ban est réglé pour bannir les clients qui se connectent et repartent sans envoyer de courriel, ajoutez les adresses de Gryphon à sa liste d’exceptions. Elles figurent sur la page des emplacements des vérifications.

Depuis plus d’une région

Avec les forfaits Pro et Teams, TCP envoi/attente peut s’exécuter depuis plusieurs régions, sous Vérifier depuis : un problème d’acheminement qui ne touche qu’une partie du monde apparaît alors comme tel. Les vérifications de certificat et celles de l’agent s’exécutent depuis un seul endroit.