SMTP
Monitoring de serveur mail
Le handshake, pas juste le port.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te montrer.
À quoi ça sert
Un serveur mail qui arrête d'accepter les mails est coûteux et silencieux. Personne ne téléphone pour dire que ton MX les refuse ; le mail se met simplement en file d'attente sur la machine de quelqu'un d'autre pendant cinq jours avant de rebondir, et d'ici là, la facture, la réinitialisation de mot de passe et la confirmation de commande sont toutes perdues.
Cela se connecte, complète le handshake SMTP et vérifie STARTTLS. Un test de port passerait sur un serveur qui accepte la connexion puis ne dit rien, ce qui est exactement à quoi ressemble un serveur mail à moitié mort vu de l'extérieur.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- STARTTLS
- Obligatoire, optionnel ou non utilisé. Obligatoire est correct pour un serveur qui reçoit des mails d'internet. Un relais interne qui ne l'a jamais proposé n'est pas cassé, et le dire nous empêche de le signaler comme en panne indéfiniment.
- Salutation attendue
- Une expression régulière que la bannière doit correspondre. Sans ça, c'est un test de port avec un handshake par-dessus.
Questions
Sur quels ports cela fonctionne-t-il ?
Le port 25 par défaut, qui est celui que les autres serveurs mail utilisent pour te livrer, et tout port que tu indiques après un deux-points. Le port 587 est pour la soumission et est vérifié de la même manière, avec STARTTLS. Le port 465 est SMTPS, qui enveloppe la connexion dans TLS dès le premier octet plutôt que de l'améliorer en cours de route, donc il suit l'autre chemin : la session est chiffrée avant que le greeting n'arrive et il n'y a plus de STARTTLS à exiger.
Est-ce que tu vérifies aussi mon enregistrement MX ?
Pas d'ici. Cela se connecte à l'hôte que tu nommes et lui parle, ce qui est une question différente de savoir si le monde est encore informé d'envoyer des mails là-bas. Un monitor DNS sur l'enregistrement MX, avec la réponse que tu attends renseignée, détecte un changement d'enregistrement. Toute personne sérieuse à propos des mails utilise les deux.
Que signifie connexion refusée ici ?
Quelque chose a répondu et dit non : rien n'écoute sur ce port. Un serveur mort, une règle de pare-feu, ou un fournisseur d'hébergement qui bloque le port 25 sortant, ce que beaucoup font. C'est signalé à part d'un handshake qui commence puis échoue, car ce sont des pannes différentes avec des solutions différentes.
Peux-tu voir ma file d'attente de mails ?
Non, et on le dit plutôt que de laisser entendre le contraire. Une file d'attente vit à l'intérieur de ton serveur et rien à l'extérieur ne peut compter les messages en attente. Ce qui est visible de l'extérieur, c'est le serveur qui a arrêté d'accepter les mails, ce qui remplit la file d'attente des autres avec tes mails, et c'est ce que cela détecte.
Est-ce que tu vérifies le certificat quand STARTTLS est utilisé ?
On vérifie que STARTTLS est annoncé et que la mise à niveau se termine, et on s'arrête là. Le mail entre serveurs est opportuniste par conception et beaucoup de relais fonctionnels présentent un certificat qu'aucun trust store n'accepterait, donc les signaler comme en panne serait signaler une panne qui n'en est pas une. Surveille l'expiration avec un monitor de certificat sur le même hôte et port.
Quelle est la différence entre obligatoire, optionnel et non utilisé ?
Obligatoire signifie que STARTTLS doit être annoncé et réussir, ce qui est correct pour un serveur qui reçoit des mails d'internet. Optionnel signifie qu'il est vérifié quand il est proposé et n'est pas retenu contre un serveur qui ne le propose pas. Non utilisé le saute, pour un relais interne qui n'a jamais eu de TLS et n'est pas cassé pour ne pas en avoir.
Pourquoi ne pas simplement m'envoyer un message de test de temps en temps ?
Un message de test prouve plus que ce test : il prouve la livraison, jusqu'à une boîte mail, ce qui est ce qui t'importe vraiment. C'est aussi quelque chose que tu feras deux fois puis oublieras, ça ne te dit rien à trois heures du matin, et un message qui arrive ne dit rien sur les quatre heures qu'il a passées en file d'attente. Celui-ci surveille le handshake en continu à la place, qui est la partie qui échoue soudainement plutôt que progressivement. Envoie aussi le message de test.