Definieren Sie Akzeptanz und Verfügbarkeit als separate Maßnahmen
MTA-STS Die Einführung kann sich auf DNS Erkennung, den Abruf einer syntaktisch gültigen Richtlinie, die Veröffentlichung eines Durchsetzungsmodus oder die beobachtete Kompatibilität mit der empfangenden MX Route der Domäne beziehen. Die Verfügbarkeit des Richtlinienhosts ist eine weitere Eigenschaft: Sie betrifft, ob der HTTPS-Endpunkt zum Beobachtungszeitpunkt erreichbar und gültig war. Eine Studie sollte diese Maßnahmen separat definieren, anstatt einen erfolgreichen Abruf als vollständige Einführung der Transportsicherheit zu behandeln.
RFC 8461 definiert MTA-STS Erkennung, Richtlinienabruf, Validierung und Caching. Es unterstützt ein reproduzierbares Messdesign und keine Behauptung, dass ein Datensatz vorhanden ist. Dieser Artikel enthält keine Domain-Scans, Verfügbarkeitsprozentsätze, Verbindungstests oder Längsschnittergebnisse. Alle Beispiele sind ausdrücklich hypothetisch.
Legen Sie die Bevölkerung der Empfangsdomäne fest
MTA-STS betrifft die Mail-Route der empfangenden Domain. Eine Liste von Websites, ausgehenden Absendermarken oder Kundenorganisationen ist nicht automatisch eine geeignete Liste von Empfangsdomänen. Definieren Sie vor der Erfassung die Einheit, die Auswahlmethode und die Ausschlüsse. Zeichnen Sie auf, ob die Stichprobe Domänen ohne nutzbare E-Mail-Route umfasst und wie sich diese Fälle auf jede Metrik auswirken, anstatt sie stillschweigend zu löschen.
Frieren Sie die Eingabeliste ein und behalten Sie ihre Quelle, ihr Datum, ihre Normalisierungsregeln und ihren Hash bei. Wenn sich die Liste zwischen den Läufen ändert, behalten Sie den Mitgliedschaftsverlauf bei. Eine Domain, die in die Stichprobe einsteigt oder sie verlässt, kann die scheinbare Akzeptanz verändern, ohne dass sich ihre Richtlinien ändern. Bezeichnen Sie eine Convenience-Stichprobe nicht als globale Schätzung, es sei denn, das Stichprobendesign unterstützt diese Schlussfolgerung. Dieses Manuskript liefert keine solche Schätzung.
Trennen Sie DNS -Erkennung vom HTTPS-Abruf
RFC 8461 definiert den Erkennungsdatensatz beim _mta-sts Eigentümer und den Speicherort für den Richtlinienabruf unter dem mta-sts-Host im bekannten Pfad. Die Erkennungskennung signalisiert Richtlinienänderungen; Es handelt sich nicht um einen Zertifikatsfingerabdruck oder um einen Beweis dafür, dass der Endpunkt derzeit funktioniert. Zeichnen Sie die DNS Antwort, den Besitzer, den Resolver und die Zeit unabhängig von der nachfolgenden HTTPS-Beobachtung auf.
Der Standard erfordert HTTP 200 OK für den Richtlinienabruf und besagt, dass Absender bei diesem Abrufvorgang keinen HTTP-Weiterleitungen folgen dürfen. Außerdem heißt es, dass Absender im Gegensatz zum MTA-STS -Richtlinien-Caching kein HTTP-Caching für den Richtlinienabruf verwenden dürfen. Die Methode sollte den Antwortstatus und das Umleitungsverhalten beibehalten, anstatt jedes erfolgreich aussehende Browserziel zu akzeptieren. Während dieser Arbeit wurde kein Endpunkt abgerufen oder eine Umleitung durchgeführt.
Validieren Sie die Richtlinie und die Verbindung gemäß den angegebenen Regeln
Die Richtlinie enthält Version, Modus, MX Muster und maximales Alter gemäß der Syntax von RFC 8461 . Behalten Sie die tatsächlichen Bytes und die Parser-Version bei. Eine Richtlinie, die den Testmodus verwendet, ist nicht dieselbe gemessene Kategorie wie der Erzwingungsmodus. Eine „Keine“-Richtlinie ist ein weiterer Zustand, der benannt und nicht in einer allgemeinen Adoptionszählung zusammengefasst werden sollte. Melden Sie den Umgang mit Inhaltstypen mit der Anforderungsstärke des Standards: Absender sollten Text/Plain validieren, anstatt eine universelle strengere Anforderung zu erfinden.
Die Validierung von HTTPS-Zertifikaten ist eine separate Beobachtung. Notieren Sie den angeforderten Hostnamen, den Endpunkt, die Uhrzeit und das tatsächliche Validierungsergebnis. Ein Netzwerkfehler, ein Zertifikatfehler, ein unerwarteter Status und eine fehlerhafte Richtlinie haben unterschiedliche Bedeutungen und sollten im Fehlerprotokoll getrennt bleiben. Schließen Sie nicht daraus, dass eine Richtlinie nicht vorhanden ist, nur weil ein Beobachtungsort sie nicht erreichen konnte, und ignorieren Sie nicht Verbindungsfehler, um einen größeren Adoptionszähler zu erzeugen.
Vergleichen Sie Richtlinienmuster mit der beabsichtigten MX Route
Eine syntaktisch gültige Richtlinie kann immer noch die falschen empfangenden Hosts beschreiben. RFC 8461 definiert den Abgleich exakter MX Hostnamen und Platzhaltermuster. Ein Platzhalter ist kein uneingeschränkter Glob irgendwo in einem Namen; Die Methode muss die im Standard definierte Syntax und Übereinstimmung implementieren. Behalten Sie die MX Beobachtungen und die Übereinstimmungsentscheidung für jeden Host innerhalb des gemessenen Bereichs bei.
Ein HTTPS-Abruf allein stellt nicht sicher, dass jeder MX Endpunkt einen gültigen TLS Dienst anbietet, der der Richtlinie entspricht. Wenn die Studie keine autorisierten SMTP Beobachtungen durchführt, geben Sie an, dass die Routenkompatibilität nicht gemessen wurde. Wenn spätere Tests genehmigt werden, halten Sie den Verbindungsnachweis und die Bevölkerung getrennt von der Verfügbarkeit des Richtlinienhosts. Beanspruchen Sie nicht allein durch DNS und HTTP eine durchgängige Durchsetzung.
Konto für zwischengespeichertes Richtlinienverhalten
Absender können eine MTA-STS Richtlinie für die im Protokoll festgelegte Höchstdauer beibehalten. Ein vorübergehender Ausfall des Richtlinienhosts kann sich daher auf einen Absender mit einer verwendbaren zwischengespeicherten Richtlinie anders auswirken als auf einen Absender, der die Domäne zum ersten Mal erkennt. Eine externe Messsonde kennt im Allgemeinen nicht den Cache-Status jedes Absenders. Die Studie darf die Ausfallzeit des Endpunkts nicht direkt in einen allgemeinen Zeitraum ungeschützter E-Mails umwandeln.
Ebenso benötigen die Erkennungskennung und die beobachtete Richtlinienversion eine zeitliche Aufzeichnung. Wenn sich eine Richtlinie während der Erfassung ändert, behalten Sie die Reihenfolge bei, anstatt die alte DNS Beobachtung ohne Erklärung mit einem neuen Körper zu verbinden. Wiederholte Messungen sollten den Sondenstatus und jede absichtliche Cache-Behandlung aufzeichnen. Das Verfahren muss sich in seinem Messverhalten von einem Vollversand unterscheiden MTA Durchführung.
Entwerfen Sie den Verfügbarkeitsplan vor der Abholung
Definieren Sie Sondenstandorte, Kadenz, Timeout, Wiederholungsrichtlinien und Klassifizierungsregeln im Voraus. Ein Endpunkt, der einmal fehlschlägt und bei einem erneuten Versuch erfolgreich ist, sollte nicht aus dem Fehlerdatensatz verschwinden. Melden Sie Beobachtungsversuche, erfolgreiche Beobachtungen und Fehlerkategorien mit einem klaren Nenner. Wenn Wartungsfenster oder nicht erreichbare Aussichtspunkte ausgeschlossen werden, bewahren Sie die Gründe auf und zeigen Sie, wie Ausschlüsse das Ergebnis verändern.
In diesem Artikel wird kein allgemeingültiges Rhythmus- oder Service-Level-Ziel vorgegeben. Wählen Sie einen Zeitplan, der der Forschungsfrage und der Autorisierung entspricht, und vermeiden Sie eine übermäßige Belastung. Dokumentieren Sie die Toolversion und die Abhängigkeiten, damit ein anderer Analyst die Methode reproduzieren kann. Schlussfolgerungen zur tatsächlichen Verfügbarkeit erfordern gesammelte Daten; Ein vorgeschlagener Zeitplan ist kein Beweis dafür, dass ein Dienst ein Ziel erreicht oder verfehlt hat.
Ein Arbeitsblatt für versionierte Datensätze
Erstellen Sie Felder für Beispielversion, empfangende Domäne, Beobachtungszeit, DNS Erkennungsergebnis, Richtlinien-ID, HTTPS-Endpunkt, Status, Zertifikatergebnis, Inhaltstyp, Körper-Hash, analysierter Modus, MX Muster und maximales Alter. Fügen Sie MX -Beobachtungsreferenzen, übereinstimmende Ergebnisse, Fehlerkategorie, Wiederholungsverlauf und Ausschlussgrund hinzu. Bewahren Sie Rohbeweise getrennt von normalisierten Klassifizierungen auf.
RFC 8460 definiert SMTP TLS Berichterstellung, die bei rechtmäßiger Verfügbarkeit eine andere Perspektive bieten kann. Solche Berichte entsprechen nicht einer externen Verfügbarkeitsprüfung und decken nicht automatisch jeden Absender ab. Falls enthalten, dokumentieren Sie deren Quelle und Umfang separat. Dieser Entwurf sammelte weder Untersuchungen noch Berichte und impliziert keine genaue Korrelation zwischen ihnen.
Fiktive Diagnose: Endpoint-Ausfall wird zum Durchsetzungsanspruch
Eine fiktive Studie beobachtet einen fehlgeschlagenen HTTPS-Abruf und kennzeichnet die empfangende Domäne den ganzen Tag lang als ohne MTA-STS -Schutz. Die vorgeschlagene Überprüfung identifiziert fehlende Beweise: Die Beobachtung deckte einen bestimmten Zeitpunkt und Standpunkt ab, und die Absender haben möglicherweise zwischengespeicherte Richtlinien. Die korrekte Schlussfolgerung ist enger gefasst und beschreibt den fehlgeschlagenen Abruf und seine Fehlerkategorie innerhalb des gemessenen Zeitplans.
Das Team würde nachfolgende Beobachtungen behalten und den Nenner melden, anstatt den Fehler zu löschen oder ihn auf das allgemeine E-Mail-Verhalten zu extrapolieren. Hierbei handelt es sich um ein fiktives methodisches Beispiel, nicht um einen beobachteten Ausfall oder eine Behauptung bezüglich einer benannten Domain. Es wurde keine Netzwerkprüfung oder E-Mail-Zustellungstest durchgeführt.
Geben Sie nur reproduzierbare Ergebnisse frei
Der Katalog erfordert einen versionierten Datensatz, eine Abfragemethode und ein Fehler-/Ausschlussprotokoll, die ein anderer Analyst reproduzieren kann. Diese Originalartefakte bleiben offen. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Dieser Entwurf liefert ein Studiendesign und eine fiktive Diagnose, nicht jedoch Akzeptanzzahlen, Verfügbarkeitsergebnisse oder eine umfassende Bewertung der Transportsicherheit.