Messagerie et cache

Présentation

Trois types de monitor qui parlent le protocole au lieu de se contenter d’ouvrir un socket. Un check TCP sur le port 587 prouve que quelque chose écoute ; un check SMTP prouve que le serveur vous salue, accepte EHLO, négocie TLS et — si vous lui donnez des identifiants — vous laisse vous authentifier.

Type	Schémas	Port par défaut	Ce que fait le check
SMTP	smtp://, smtps://	587 (465 pour smtps)	Bannière, EHLO, STARTTLS, AUTH facultatif
IMAP	imap://, imaps://	143 (993 pour imaps)	Salutation, CAPABILITY, STARTTLS, LOGIN facultatif
Redis	redis://, rediss://	6379	AUTH facultatif, puis PING → +PONG

La cible peut aussi être un hôte nu : mail.example.com, mail.example.com:993.

TLS

Le TLS prend trois formes ici, et les confondre est la première cause de « mon serveur va bien mais le monitor est rouge » :

Forme	Quand	Comportement
Implicite	smtps://, imaps://, rediss://, ou port 465 / 993	TLS dès le premier octet
STARTTLS	SMTP et IMAP sur tout autre port (587, 143…)	Connexion en clair, puis passage en TLS
Aucun	Redis sans rediss://, ou ?starttls=false	Tout en clair

Un port « sécurisé » implique du TLS implicite même sans schéma : mail.example.com:993, c’est de l’IMAPS, pas de l’IMAP en clair.

Quand STARTTLS s’applique et que le serveur ne l’annonce pas, le check échoue et le dit — plutôt que de continuer discrètement en clair. Un MTA interne qui parle réellement en clair se déclare avec smtp://mta.internal:25?starttls=false.

Identifiants

L’utilisateur et le mot de passe sont facultatifs. Sans eux, le check vérifie que le service répond à son protocole. Avec eux, il vérifie aussi que l’authentification aboutit — ce qui attrape un mot de passe de boîte expiré ou un requirepass Redis tourné avant que votre application ne s’en aperçoive.

Ils vivent dans les mêmes colonnes chiffrées que pour les monitors base de données : jamais dans l’URL, masqués en *** dans l’API et dans tous les exports, retirés des messages d’erreur. Des identifiants collés dans l’URL (smtps://utilisateur:motdepasse@mail.example.com) en sont sortis à l’enregistrement.

• SMTP — AUTH PLAIN quand il est annoncé, sinon AUTH LOGIN.
• IMAP — LOGIN. Un serveur qui annonce LOGINDISABLED est signalé comme tel.
• Redis — AUTH <utilisateur> <mot de passe> (ACL Redis 6+) si un utilisateur est renseigné, sinon AUTH <mot de passe> (le requirepass historique).

Ce qui compte comme « up »

Type	Up	Down
SMTP	Bannière 220, EHLO accepté (250), et authentification acceptée (235) si des identifiants sont renseignés	Connexion refusée, délai dépassé, bannière refusée, STARTTLS absent ou refusé, authentification refusée
IMAP	Salutation * OK, CAPABILITY accepté, et LOGIN accepté si des identifiants sont renseignés	Idem, plus LOGINDISABLED si des identifiants sont renseignés
Redis	PING répond +PONG	Connexion refusée, délai dépassé, AUTH refusé, -NOAUTH sur PING

Un serveur qui coupe la connexion sans un mot après l’authentification est signalé comme un refus, pas comme une réponse vide — le message dit quelle étape a échoué.

La latence couvre tout le dialogue : connexion, TLS et échange protocolaire.

Réglages

Réglage	Description	Défaut
Cible	smtp.example.com:587, imaps://mail.example.com, redis://cache.example.com:6379	—
Utilisateur / Mot de passe	Facultatifs, stockés chiffrés	—
Port	Utilisé seulement si l’URL n’en porte pas	Défaut du type
Ignorer la validation TLS	Accepter un certificat auto-signé	désactivé
Intervalle	Fréquence des checks	selon le plan
Délai d’attente	Budget pour tout le dialogue	10 s

Remarques

• Un serveur SMTP ou IMAP public qui limite les connexions peut refuser un check trop fréquent depuis plusieurs régions à la fois. Commencez à 5 minutes et une ou deux régions.
• Un Redis exposé sur Internet devrait exiger un mot de passe ; un check sans mot de passe qui réussit quand même mérite une investigation à lui seul.
• Le check n’envoie jamais de courriel et n’écrit jamais de clé — le dialogue s’arrête à QUIT / LOGOUT.