Eine Maildomain kann SPF, DKIM und DMARC veröffentlichen und trotzdem Fragen offenlassen. Welcher Server nimmt Nachrichten tatsächlich an? Wie verhält er sich über IPv6? Passt eine veröffentlichte Transportrichtlinie zu dem Dienst, der am Ende erreichbar ist?
Mit Mailcheck möchte ich solche Fragen systematisch beantworten. Nicht durch eine möglichst auffällige Gesamtpunktzahl, sondern durch Befunde, deren Herkunft und Bedeutung nachvollziehbar bleiben.
Messen und bewerten sind zwei unterschiedliche Aufgaben
Die erste Frage lautet: Was lässt sich beobachten? Beispielsweise welche MX-Einträge vorhanden sind, welche Adressen ein Mailserver verwendet oder welches Zertifikat er bei einer TLS-Verbindung präsentiert.
Die zweite Frage lautet: Wie ist diese Beobachtung unter einer bestimmten Prüfregel zu bewerten? Dafür brauche ich den fachlichen Zusammenhang. Ein vorhandener Record ist noch kein Beweis, dass die damit beschriebene Sicherheitsfunktion korrekt arbeitet.
Mailcheck soll beide Ebenen trennen. Ein Bericht muss erkennen lassen, was tatsächlich gemessen wurde, welche Regel darauf angewendet wurde und wo keine belastbare Aussage möglich war.
Eine Domain ist der Anfang, nicht die ganze Prüfeinheit
Hinter einer Domain können mehrere MX-Server stehen, jeder mit mehreren Adressen und unterschiedlichen Verbindungswegen. Eine erfolgreiche Verbindung zu einem einzelnen Ziel ersetzt deshalb keine Prüfung der übrigen erreichbaren Ziele.
Auch die veröffentlichten Richtlinien müssen im Zusammenhang betrachtet werden. DANE bindet die Absicherung des SMTP-Transports an DNSSEC-validierte TLSA-Daten; MTA-STS beschreibt einen anderen Mechanismus für eine veröffentlichte Transportpolitik. Die jeweiligen Grundlagen stehen in RFC 7672 und RFC 8461.
Für Mailcheck folgt daraus keine pauschale Vorgabe, jede Domain müsse jede Technik gleichzeitig einsetzen. Entscheidend ist, welche Eigenschaft geprüft werden soll, welcher Mechanismus sie bereitstellt und ob die beobachtete Konfiguration dazu passt.
Vom Auftrag zum Bericht
Die Architekturplanung zerlegt die Arbeit in nachvollziehbare Schritte:
- Weboberfläche / APIAuftrag annehmen und Ergebnisse zugänglich machen.
- Prüfauftrag und KatalogstandZiele, Umfang und Bewertungsgrundlage festhalten.
- Begrenzter Scan-JobTechnische Beobachtungen unter definierten Grenzen erheben.
- Befunde und BewertungMesswerte und fachliche Einordnung getrennt halten.
- BerichtErgebnisse, Herkunft, Versionen und Lücken nachvollziehbar darstellen.
Weboberfläche und API nehmen Aufträge an und stellen Ergebnisse bereit. Ein Worker koordiniert die Arbeit. Die eigentlichen Netzprüfungen sollen als begrenzte Jobs laufen. Aufträge, Zustände und Befunde werden vom Bericht getrennt gespeichert.
Diese Aufteilung hilft auch bei einer schlichten Betriebsfrage: Ist eine Prüfung noch nicht gestartet, läuft sie gerade, ist sie fehlgeschlagen oder ist nur eine einzelne Teilmessung unvollständig? All diese Zustände in einem roten Gesamtergebnis zusammenzufassen wäre zwar einfach, aber wenig hilfreich.
Der genaue Zuschnitt von API, Worker, Speicher und Berichterzeugung ist in den vorliegenden Architekturunterlagen noch als Vorschlag beschrieben.
Versionen gehören zum Ergebnis
Eine Auswertung lässt sich nur vergleichen, wenn ihre Grundlage bekannt ist. Deshalb sieht das Konzept eine Verbindung zwischen Anforderungsregister, Prüfkatalog und Scan-Engine vor.
Ein Bericht soll festhalten, wann geprüft wurde, welche Ziele untersucht wurden und welche Versionen der Prüfdefinitionen und Werkzeuge beteiligt waren. So lässt sich später unterscheiden, ob sich die Mailkonfiguration geändert hat oder die Bewertungsgrundlage.
Für mich ist das der Unterschied zwischen einem kurzlebigen Testergebnis und einer nachvollziehbaren Dokumentation. Signierte Berichte und zusätzliche Zeitnachweise sind mögliche Ausbauschritte; aus den vorhandenen Unterlagen ergibt sich noch kein vollständig abgenommener Nachweisdienst.
Öffentliche Informationen und weitergehende Prüfungen
Nicht jede Untersuchung hat denselben Umfang. Ein öffentlich sichtbarer DNS-Eintrag ist etwas anderes als eine weitergehende aktive Prüfung einer fremden Infrastruktur.
Im Konzept ist dafür eine Domainfreigabe vorgesehen: Der Verantwortliche hinterlegt einen bereitgestellten Token unter _mailcheck in seiner DNS-Zone. Welche erweiterten Prüfungen damit freigegeben werden und wie die Freigabe geprüft wird, muss für den jeweiligen Auftrag klar feststehen.
Das ist kein Ersatz für die Definition eines Prüfprofils. Eine Freigabe beantwortet die Frage nach dem erlaubten Umfang; der Katalog beantwortet, was in diesem Umfang untersucht und wie es bewertet wird.
Mailcheck und seine Mailinfrastruktur
Die Prüfplattform ist von ihrer eigenen Mailinfrastruktur zu unterscheiden. Die Plattform soll vorhandene Maildienste etwa für Versand und Berichte nutzen, statt einen zweiten Mailserver innerhalb der Scan-Anwendung zu betreiben.
Für mail.mailcheck.tools gilt in meinem Aufbau eine bewusste Ausnahme: Dieser Dienst bleibt dauerhaft direkt angebunden und wird nicht hinter ein Proxmox Mail Gateway gestellt. Ein fehlendes PMG ist dort also kein noch offener Umbaupunkt.
Auch die Webdienste der Fachanwendung haben ihr eigenes Infrastrukturziel. Sie gehören nicht automatisch in den allgemeinen Hosting-Cluster, nur weil sie über HTTP erreichbar sind.
Was ein Befund sagen darf
Eine externe technische Prüfung kann die beobachtbaren Eigenschaften einer Konfiguration dokumentieren. Sie kann nicht allein feststellen, ob sämtliche internen Prozesse funktionieren, ob jede Nachricht zugestellt wird oder ob eine Organisation alle für sie geltenden Verpflichtungen erfüllt.
Darum soll ein Bericht seinen Umfang nennen und Lücken sichtbar lassen. „Nicht erhoben“ ist eine brauchbare Aussage. Eine positive Bewertung ohne ausreichende Grundlage ist es nicht.
Mailcheck ist für mich der Versuch, Mailkonfigurationen so zu beschreiben, dass Betreiber daraus konkrete nächste Schritte ableiten können. Der Ausbau soll dieser Nachvollziehbarkeit folgen: erst eine belastbare Messung, dann eine begründete Bewertung und schließlich eine Darstellung, die beides auseinanderhalten kann.