Erklärungen & Bewertungsmethodik

Jeder Check erzeugt ein Finding mit einem Status und einem Gewicht. Die gewichteten Findings eines Moduls ergeben eine Prozentzahl, die in eine Buchstabennote (A+ … F) umgerechnet wird. Die Startseite fasst alle Module zu einer Gesamtnote zusammen.

• pass – bestanden (volle Punktzahl)
• good – erfüllt, zählt aber nicht in die Note (optionale Härtung)
• warn – Verbesserungspotenzial (halbe Punktzahl)
• fail – Problem/Risiko (0 Punkte)
• info / skip – rein informativ oder nicht prüfbar (zählt nicht in die Note)

Was „nicht prüfbar“ mit der Note macht. Ein Check, den wir nicht durchführen konnten, verlässt Zähler und Nenner und zählt damit nie gegen die Domain. Genau das allein hieße aber: je weniger gemessen wurde, desto besser die Note — ein Scan, in dem drei von sechs Prüfungen nicht liefen, könnte tadellose 100 % melden. Module melden deshalb das verlorene Gewicht, und der Bericht sagt es: Die Modul-Kopfzeile nennt, wie viele ihrer Gewichtspunkte die Note abdeckt, und die Gesamtnote wird als vorläufig gekennzeichnet. Ein Modul, das gar nicht bewertet werden konnte, ist derselbe Fall in stärkerer Form: Es verlässt den Durchschnitt vollständig, die Gesamtzahl deckt also weniger ab und kann höher ausfallen als bei einem vollständigen Lauf — der Bericht nennt deshalb, welches Modul fehlt, und sagt es. Das ist eine Grenze des Scans und kein Befund über die Domain — ein erneuter Lauf kann sie durchaus messen. Prüfungen, die schlicht nicht anwendbar sind (MTA-STS bei einer Domain, die keine Mail empfängt), gelten nicht als Lücke: Dort wurde nichts versäumt.

Die Gesamtnote ist eine gewichtete Punktsumme über die Findings aller Module, kein Mittel ihrer Noten, und trägt deren Notendeckel nicht. Ein Modul, das mehr benotungsrelevantes Gewicht aufwirft, zählt damit mehr als eines, das weniger aufwirft. Ein Modul, das wegen eines abgelaufenen Zertifikats auf F gedeckelt ist, geht mit seinem ungedeckelten Prozentwert in die Gesamtzahl ein. Wo das vorkommt, benennt die Gesamtnote das gedeckelte Modul und seinen Grund — maßgeblich ist die Modulnote.

Es gibt einen zweiten Weg aus der Bewertung: Ein Finding kann das Gewicht 0 tragen. Es wird dann mit Status und vollständigem Text angezeigt, bleibt aber aus Zähler und Nenner gleichermaßen heraus — unabhängig von seinem Status. So wird derselbe Mangel nicht doppelt berechnet, wenn zwei Findings ihn beschreiben (etwa DANE / TLSA und DANE-Konfiguration).

Bewertungs-Caps (nach dem Vorbild von SSL Labs)

Ein einzelnes schweres Finding darf nicht durch viele „pass“-Ergebnisse weggemittelt werden. Deshalb deckeln bestimmte Findings die Modulnote unabhängig vom Durchschnitt (Minimum-Logik). Die Listen unten nennen die häufigsten Ursachen und sind bewusst nicht abschließend – der Live-Versand- und Empfangs-Test bringen eigene Fälle mit, und jedes deckelnde Finding nennt seinen Grund im Bericht selbst. Ein Deckel greift nur, solange sein Finding auf fail oder warn steht. Ein Deckel kann greifen, ohne etwas zu ändern: Liegt der Modul-Durchschnitt ohnehin auf oder unter dem Deckel, bleibt die Note, wo sie ist. Die Modul-Kopfzeile benennt einen solchen Befund trotzdem — er ist schwer genug, den Durchschnitt zu überstimmen, er bindet hier nur nicht. Die Listen gelten außerdem je Modul: Eine hier genannte Ursache deckelt dort, wo das Modul, das sie erhebt, einen Deckel vergibt. Der Mailtransport auf Port 25 ist die systematische Ausnahme — STARTTLS ist dort opportunistische Sicherheit, und RFC 9325 §5.2 sagt zu genau dieser Lage, strengere Regeln „might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite“. Die MX-Checks fällen deshalb ein Urteil, vergeben aber keinen Deckel für fehlende Forward Secrecy, eine veraltete TLS-Version, eine unvollständige oder nicht vertrauenswürdige Kette und ein abgelaufenes Zertifikat; der einzige Deckel, den sie vergeben, ist Cap C.

• Cap A-: kein TLS 1.3.
• Cap B: veraltetes TLS 1.0/1.1, keine Forward Secrecy, keine AEAD-Cipher, unvollständige Zertifikatskette, DH-Parameter unter 2048 Bit (unter 1024 Bit deckelt auf F), RSA-Zertifikatsschlüssel unter 2048 Bit, RC4.
• Cap C, unter anderem: einfaches DES/RC4/3DES mit TLS 1.1+, schwacher Cipher an einem MX, MX nur im Klartext (kein STARTTLS), eine Weiterleitung, die auf unverschlüsseltem HTTP endet, DMARC p=none, ein unwirksamer oder doppelter DMARC-Record, SPF, das jeden Absender erlaubt (+all oder ein /0-Bereich) oder durch mehrere Records unwirksam ist, DANE-TLSA ohne DNSSEC oder ohne Übereinstimmung mit dem präsentierten Zertifikat, ein DANE-TA-Record, der zwar passt, dessen Zertifikat aber nicht den Namen des Mailservers trägt oder abgelaufen ist, ein MX, der STARTTLS ankündigt, während keine seiner geprüften Verbindungen eine TLS-Sitzung zustande bringt. Die Live-Mail-Tests bringen eigene Fälle mit: Klartext-Zustellung, eine Nachricht ohne DMARC-Ausrichtung, eine fehlende oder nicht verifizierende DKIM-Signatur, ein fälschbarer DKIM- oder MX-Schlüssel, STARTTLS-Command-Injection, MTA-STS enforce, das Mail verwerfen würde.
• Cap F, unter anderem: ein abgelaufenes Zertifikat, ein RSA-Schlüssel unter 1024 Bit, ein Zertifikatsschlüssel, dessen privater Teil sich aus dem öffentlichen berechnen lässt (ROCA, Fermat-faktorisierbare Primzahlen), DH-Parameter unter 1024 Bit, NULL-/Export-/anonyme Cipher, eine DNSSEC-Zone, die validierende Resolver ablehnen – ungültige Signaturen, ein DS beim Parent ohne DNSKEY in der Zone oder ein veralteter DS ohne passenden veröffentlichten Schlüssel – sowie abgelaufene oder noch nicht gültige Signaturen einer per DS verankerten Zone, solange kein validierender Resolver sie zugleich als authentifiziert meldet. Der Empfangs-Test ergänzt eine Domain ohne auflösbaren oder erreichbaren Mailserver.
• T (Trust) bzw. M (Mismatch): T bei einem Zertifikat, dem nicht vertraut wird (und dessen Kette sich auch nicht aus den öffentlich bekannten Intermediates reparieren ließ), das mit einem schwachen Hash signiert ist (SHA-1/MD5, im Leaf oder in einem Intermediate der ausgelieferten Kette) oder das ab dem 1. September 2020 für mehr als 398 Tage ausgestellt wurde und deshalb von Chrome und Safari abgelehnt wird; M bei einem Zertifikat, das nicht zum Hostnamen passt. Beide übersteuern die Buchstabennote.

Methodik angelehnt an den SSL Labs Server Rating Guide, Mozilla, OWASP und die einschlägigen RFCs.