IMAP-Check

Was er prüft

Ein IMAP-Monitor verbindet sich aus jeder seiner Regionen mit Host und Port. Der Check besteht, wenn die erste Zeile der Begrüßung mit * OK beginnt. Auf Port 993 schließt der Prüfpunkt zuerst einen TLS-Handshake gegen den öffentlichen Root-Store ab, mit dem Host als SNI. Jeden anderen Port liest er im Klartext. Mit eingeschaltetem Zertifikat-Subcheck bewertet der Monitor außerdem Ablauf, Aussteller und Subject, über den direkten Handshake auf 993 oder über STARTTLS auf den anderen Ports.

Wann Sie ihn einsetzen

• Ein Mailserver hat einen IMAP-Endpunkt, von dem Clients lesen, und eine abgewiesene Verbindung oder eine fehlende Begrüßung soll einen Incident öffnen.
• Das Zertifikat, das der Server vorzeigt, soll zusammen mit dem Dienst bewertet werden, ohne zweiten Monitor. Der Subcheck deckt Ablauf, Aussteller und Subject ab, über implizites TLS oder STARTTLS.
• Der IMAPS-Endpunkt muss öffentlich vertrauenswürdig bleiben. Auf 993 wird die Begrüßung erst nach einem Handshake gegen den öffentlichen Root-Store gelesen, ein Problem mit der Kette zeigt sich also als Ausfall.

Der Check meldet sich nicht an, öffnet kein Postfach und sendet kein CAPABILITY. Für einen SMTP-Endpunkt nutzen Sie den SMTP-Check. Ein Zertifikat auf einem direkten TLS-Port, das einen eigenen Incident verdient, prüft der TLS-Zertifikat-Check. Ein selbstsignierter IMAPS-Server auf 993 fällt bei der Begrüßungsprüfung durch, weil allow_self_signed nur den Zertifikat-Subcheck erreicht.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Konfiguration

Ziel. Ein Hostname oder eine IP-Adresse ohne Schema oder Pfad, dazu ein optionaler Port. Das Formular schlägt 993 vor. Jede aufgelöste Adresse wird geprüft, bevor sich der Prüfpunkt verbindet. Loopback-, private, Link-local- und Cloud-Metadaten-Adressen werden abgewiesen, der Monitor erreicht also kein internes Netz.

TLS-Zertifikat

Auf eine bestandene Begrüßung kann eine Zertifikatsregel folgen, einmal je Check statt je Adresse. Auf 993 nutzt sie einen direkten Handshake, auf jedem anderen Port den IMAP-STARTTLS-Dialog (A1 STARTTLS, dann A1 OK). Das Formular bietet den Schalter mit Port, Warnfenster, Regex für Aussteller und Subject und dem Schalter für selbstsignierte Zertifikate. Ohne den Schalter zeigt die Monitoransicht weiterhin das ausgelieferte Zertifikat, aber Regel und Ablaufhinweis brauchen den Schalter.

So läuft ein Check ab

1. Jede Region, deren Intervall fällig ist, löst den Host über den eigenen Resolver des Knotens auf.
2. Jede aufgelöste Adresse der gewählten Familie wird gegen die gesperrten Bereiche geprüft und dann für sich verbunden.
3. Auf Port 993 schließt der Prüfpunkt zuerst einen TLS-Handshake gegen den öffentlichen Root-Store ab, mit dem Host als SNI. Auf jedem anderen Port bleibt er im Klartext. Dann liest er die erste Zeile, die der Server sendet.
4. Eine Zeile, die mit * OK beginnt, besteht, alles andere schlägt fehl. Verbindung, Handshake und Begrüßung teilen sich das Limit von 10 s. Ein Server, der schweigt, ist ausgefallen und kein Konfigurationsfehler.
5. Nur ein bestandener Check mit tls_cert.enabled führt die Zertifikatsregel aus, einmal je Check. Sie nutzt auf 993 einen direkten Handshake und auf anderen Ports den STARTTLS-Dialog. Die regulären Ausdrücke werden zuerst kompiliert, und ein ungültiger beendet den Check als Fehler.
6. Das Ergebnis der Region geht an die Control Plane. Ein Fehlschlag öffnet einen Incident, sobald das Quorum der Alarmregel übereinstimmt, in der Voreinstellung 2 Regionen über 2 aufeinanderfolgende Checks.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Was ein Ergebnis enthält

Begrüßung

Die erste Zeile, die der Server gesendet hat, bewertet auf * OK.

Antwortzeit

Zeit bis zur Begrüßung, auf 993 einschließlich TLS-Handshake, je Region und je Adresse.

Detailzeile

Eine Zeile, die sagt, was passiert ist: die Begrüßung, IMAP error: mit dem Transport- oder Handshake-Fehler oder Timeout. Mit eingeschaltetem Subcheck wird der Zertifikatsbefund bei Bestehen an die Begrüßung angehängt und ersetzt sie bei einem Fehlschlag.

Ursachenschicht

Ob der Fehler beim DNS des Ziels lag (NXDOMAIN oder NODATA) oder bei seiner Anwendung nach erfolgreicher Auflösung. Alles andere wird als unbekannt gemeldet.

Zertifikat

Das Ergebnis behält Common Name, alternative Namen und Aussteller, dazu Gültigkeitsdaten, das Kennzeichen selbstsigniert und das öffentliche Vertrauen. Jeder Check liest diese Angaben, mit oder ohne Subcheck. Die Restlaufzeit mit ihrer Warnung erscheint nur mit eingeschaltetem Subcheck.

Region, Familie, Adresse

Jedes Ergebnis trägt die Region, die es gemessen hat, und ein Teilergebnis je IP-Familie und je Adresse.

Zustände und Schwere

• okDie Begrüßung beginnt mit * OK, auf 993 nach einem vertrauenswürdigen Handshake. Mit eingeschaltetem Subcheck hält auch die Zertifikatsregel, und ein Zertifikat innerhalb seines Warnfensters behält diesen Zustand.
• eingeschränktEine IP-Familie fällt aus, während die andere antwortet, oder einige von mehreren aufgelösten Adressen einer Familie fallen aus, während die anderen antworten. Das gilt bei voreingestellter family_fail_severity.
• ausgefallenDie Verbindung wird abgewiesen, läuft in den Timeout oder wird blockiert, oder die Begrüßung ist nicht * OK. Der Check ist auch ausgefallen, wenn der Handshake auf 993 abgewiesen wird, weil die Kette nicht vertrauenswürdig ist, der Hostname nicht passt oder das Zertifikat abgelaufen ist. Dasselbe gilt, wenn die Zertifikatsregel am Ablauf, an einem abgewiesenen Handshake oder an Aussteller oder Subject scheitert.
• FehlerDie Konfiguration ist nicht ausführbar, zum Beispiel wegen eines ungültigen regulären Ausdrucks in der Zertifikatsregel. Der Check endet dann als Fehler statt als Fehlschlag und zählt als Ausfall mit Schwere critical.

Per Quorum bestätigt: Standardmäßig müssen 2 Regionen den Fehler melden, bevor Perstat einen Incident öffnet. Die Voreinstellung der Organisation verlangt 2 Regionen und 2 aufeinanderfolgende Checks. Ein Monitor kann eine eigene Regel tragen, mit Anzahl oder Prozent, aufeinanderfolgenden Checks und einer Mindestdauer.

Tarife und Grenzen

Kürzestes Intervall

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command und 10 s in Enterprise. Das Webformular bietet 30 s, 1 min, 5 min, 15 min und 1 h an. Die Untergrenzen von 15 s und 10 s erreichen Sie nur über MCP.

Regionen

2 von 6 in Free, 3 von 6 in Pulse und alle 6 ab Sentinel.

Monitore

10 in Free, 50 in Pulse, 150 in Sentinel, 500 in Command und ein individuelles Kontingent in Enterprise. Die elf regionalen Checktypen teilen sich dieses Kontingent. Host-Agenten und Heartbeats haben eigene Kontingente.

Alle Tarifgrenzen vergleichen

Aus der Pipeline oder von einem Agenten

Dieselbe config gilt im Deploy-Schritt, in einem MCP-Client wie Claude Code und im Formular oben. create_monitor braucht einen API-Schlüssel für die ganze Organisation. Wenn Sie regions weglassen, wählt der Tarif seine Voreinstellung.

{
  "name": "Mailbox IMAPS",
  "type": "imap",
  "interval_seconds": 60,
  "config": {
    "host": "mail.example.com",
    "port": 993,
    "tls_cert": { "enabled": true, "warn_days": 21 }
  }
}

Jede Schnittstelle mit ihrer Grenze

Grenzen

• Keine Anmeldung, kein Postfachzugriff und kein CAPABILITY. Der Prüfpunkt liest eine Zeile.
• Auf 993 verlangt die Begrüßungsprüfung eine öffentlich vertrauenswürdige Kette. Der Schalter allow_self_signed erreicht nur den Zertifikat-Subcheck, ein selbstsignierter IMAPS-Server bleibt also ausgefallen.
• Nur Port 993 bedeutet implizites TLS. Jeder andere Port wird im Klartext gelesen, und der Zertifikat-Subcheck nutzt dort STARTTLS.
• Die Zertifikatsregel läuft einmal je Check, nicht je Adresse, und nur nach einer bestandenen Begrüßung.
• Ziele auf privaten, Loopback-, Link-local- und Cloud-Metadaten-Adressen werden abgewiesen.
• Nicht jede Region prüft IPv6, deshalb schränkt die Auswahl von ipv6 die nutzbaren Regionen ein.
• SPF, DMARC und CAA der Mail-Domain gehören zum DNS-Hygiene-Check.

Verwandte Checktypen

• SMTP-CheckBanner und EHLO eines Mailservers, optional mit Zertifikatsprüfung über STARTTLS oder implizites TLS.
• TLS-Zertifikat-CheckAblauf, Aussteller und Subject eines Zertifikats per direktem TLS-Handshake, mit Hinweis vor dem Ablauf.
• TCP-Port-CheckOb ein Port eine Verbindung annimmt, wahlweise mit dem Zertifikat, das er ausliefert.
• DNS-Hygiene-CheckSPF, DMARC mit Policy und CAA einer Domain, bewertet als Konfigurationsstand und nie als Ausfall.

Alle Checktypen