Was ist SMTP TLS Reporting?
TLS Reporting ist ein umgekehrter Feedback-Mechanismus, der Domaininhabern hilft, Probleme bei der E-Mail-Zustellung punktgenau zu finden. Er funktioniert in Verbindung mit dem MTA-STS Protokoll und liefert Nachverfolgungsdaten über gebouncte E-Mails, die aufgrund eines fehlgeschlagenen TLS-Handshakes nicht zugestellt werden konnten.
Was bedeutet TLS-Berichterstattung?
TLS Reporting (TLS-RPT) ist ein Standard zur Meldung von Problemen bei der E-Mail-Zustellung, die auftreten, wenn eine E-Mail nicht mit TLS verschlüsselt ist. Er unterstützt das MTA-STS-Protokoll, mit dem sichergestellt wird, dass jede an Ihre Domain gesendete E-Mail mit TLS verschlüsselt wird.
- Die TLS-Verschlüsselung gewährleistet, dass jede an Sie gesendete E-Mail sicher zugestellt wird. Ein Angreifer könnte jedoch ein SMTP-Downgrade versuchen, eine Art Angriff, bei dem die E-Mail unverschlüsselt an Sie gesendet wird, so dass er den Inhalt lesen oder manipulieren kann. MTA-STS bekämpft dies, indem es dafür sorgt, dass alle E-Mails verschlüsselt werden müssen, bevor sie an Sie gesendet werden. Wenn ein Angreifer versucht, ein SMTP-Downgrade durchzuführen, wird die E-Mail überhaupt nicht gesendet.
- TLS-RPT ermöglicht es Ihnen, als Domaininhaber, Berichte über jede E-Mail zu erhalten, die nicht verschlüsselt wird und nicht an Sie zugestellt werden kann. Sie können dann die Quelle des Problems identifizieren und Ihre Zustellungsprobleme beheben.
Wie funktioniert die TLS-Berichterstattung?
TLS-Reporting (TLS-RPT) wird zur Unterstützung des MTA-STS-Protokolls verwendet, das sicherstellt, dass E-Mails vor der Zustellung verschlüsselt werden. Normalerweise handelt Ihr E-Mail-Server oder Mail Transfer Agent (MTA) mit dem Empfangsserver aus, ob er den STARTTLS-Befehl unterstützt. Wenn dies der Fall ist, wird die E-Mail mit TLS verschlüsselt und an den empfangenden MTA zugestellt.
Ein Angreifer könnte an dieser Stelle einen SMTP-Downgrade-Angriff versuchen, bei dem die Aushandlung zwischen dem sendenden und dem empfangenden MTAs blockiert wird. Der sendende Server denkt, dass der Empfänger den STARTTLS-Befehl nicht unterstützt und sendet die E-Mail ohne TLS-Verschlüsselung, was dem Angreifer ermöglicht, den Inhalt der E-Mail einzusehen oder zu manipulieren.
Wenn Sie MTA-STS in Ihrer Domäne implementieren, muss Ihr Versandserver die Nachrichten verschlüsseln, bevor er sie versendet. Wenn ein Angreifer einen SMTP-Downgrade-Angriff versucht, wird die E-Mail einfach nicht gesendet. Dadurch wird die TLS-Verschlüsselung für alle Ihre E-Mails sichergestellt.
TLS-Reporting (TLS-RPT) ist ein Protokoll, das Sie als Domaininhaber benachrichtigt, wenn bei der Zustellung von E-Mails, die über Ihre Domain versendet werden, Probleme auftreten. Wenn eine E-Mail aufgrund eines SMTP-Downgrades oder eines anderen Problems nicht zugestellt werden kann, erhalten Sie einen Bericht in einem JSON-Dateiformat, der die Details der fehlgeschlagenen E-Mail enthält. Dieser Bericht enthält nicht den Inhalt der E-Mail.
Warum brauchen Sie SMTP-TLS-Reporting?
Für Domaininhaber ist es wichtig, über Probleme bei der E-Mail-Zustellung aufgrund von Fehlern bei der TLS-Verschlüsselung von E-Mails, die von einer MTA-STS-aktivierten Domain gesendet werden, informiert zu sein. Das TLS-Reporting macht dies möglich, indem es diese Informationen bereitstellt.
Empfang von Feedback-Berichten
Wenn eine Nachricht nicht gesendet werden kann, werden Sie mit Hilfe der TLS-Berichterstattung darüber informiert.
Vollständige Transparenz der E-Mail-Kanäle erhalten
Erhalten Sie detaillierte Einblicke in Ihren E-Mail-Verkehr durch TLS-Berichte
Beseitigung von Lieferproblemen
TLS-Berichte helfen Ihnen, die Ursache des Problems zu ermitteln und es ohne Verzögerung zu beheben
Schritte zur Aktivierung der TLS-Berichterstattung
Sie können die TLS-Berichterstattung für Ihre Domäne aktivieren, indem Sie einen TXT-Eintrag für TLS-RPT erstellen und ihn in Ihrem DNS veröffentlichen. Dieser Eintrag muss auf der Subdomain veröffentlicht werden _smtp._tls.ihredomain.de
Beispiel eines TLS-RPT-Datensatzes
v=TLSRPTv1; rua=mailto:[email protected];
Schauen wir uns die Bestandteile des bereitgestellten TLS-Berichtsdatensatzes an:
v=TLSRPTv1:
Dieses Tag gibt die Version des verwendeten TLS-RPT-Protokolls an. In diesem Fall "TLSRPTv1" die erste Version des TLS-RPT-Protokolls an.
rua=mailto:[email protected]:
Dieses Tag gibt die Berichts-URI für die aggregierten Berichte (RUAs) an. Es gibt an, wohin der Mailserver des Empfängers aggregierte Berichte über TLS-Fehler senden soll. rua steht für "Reporting URI for Aggregated Reports".
Der Wert "mailto:[email protected]" ist ein URI, der eine E-Mail Adresse angibt ([email protected]) angibt, an die die aggregierten Berichte per E-Mail gesendet werden sollen.
In der Praxis würden Sie Folgendes ersetzen "IhreDomain.de" durch den tatsächlichen Domänennamen, unter dem Sie diese Berichte erhalten möchten.
Die Bedeutung der einzelnen Komponenten:
v=TLSRPTv1:
Hier wird die Version des verwendeten TLS-RPT-Protokolls angegeben. Sie hilft, die Kompatibilität zwischen Sender und Empfänger der Berichte zu gewährleisten.
rua=mailto:[email protected]:
Hier wird angegeben, wohin die gesammelten Berichte über TLS-Zustellungsprobleme gesendet werden sollen. Durch die Angabe einer Berichts-E-Mail-Adresse können Domänenbesitzer Informationen über fehlgeschlagene oder problematische TLS-Verbindungen erhalten. Die Berichte sind wertvoll für die Diagnose potenzieller Sicherheits- oder Konfigurationsprobleme im Zusammenhang mit der E-Mail-Kommunikation.
TLS-Berichtsformat und Berichtsbeispiel
Ein JSON-TLS-Bericht folgt einem bestimmten Format, das in der TLS-RPT-Spezifikation (Transport Layer Security Reporting Policy) festgelegt ist. Dieses Format wird verwendet, um Informationen über E-Mail-Zustellungsprobleme im Zusammenhang mit der TLS-Verschlüsselung zu übermitteln. Nachstehend finden Sie ein Beispiel dafür, wie ein JSON-TLS-Bericht aussehen könnte:
Hier ist die Aufschlüsselung der wichtigsten Felder in diesem JSON-TLS-Bericht:
Organisation: Die Domänenorganisation, die Eigentümer des TLS-RPT-Eintrags ist.
E-Mail: Die E-Mail-Adresse, an die die aggregierten Berichte gesendet werden.
beginn_datum: Das Anfangsdatum des Berichtszeitraums.
end_date: Das Enddatum des Berichtszeitraums.
Politik: Ein Array von Richtlinienobjekten, die die während des Berichtszeitraums angewandten Richtlinien beschreiben.
Politik: Enthält Informationen über die angewandte Richtlinie.
richtlinien_type: Gibt den Typ der Richtlinie an (z. B. "policy" für eine TLS-Richtlinie).
richtlinien_string: Gibt die mit der Richtlinie verbundene Zeichenkette an (z. B. "reject" für eine strenge TLS-Richtlinie).
Zusammenfassung: Enthält zusammenfassende Informationen über die versuchten Sitzungen.
total_successful_session_count: Die Gesamtzahl der erfolgreich aufgebauten TLS-Sitzungen.
total_failure_session_count: Die Gesamtzahl der fehlgeschlagenen TLS-Sitzungen.
fehler_details: Ein Array von Objekten, die Details zu bestimmten Fehlern enthalten.
Grund: Eine Zeichenfolge, die den Grund für den Fehler angibt (z. B. "certificate_expired").
zählen: Die Anzahl der Sitzungen, die aus einem bestimmten Grund fehlgeschlagen sind.
Gründe und Arten von Fehlern bei der TLS-Verschlüsselung
Zertifikatsprobleme:
- zertifikat_abgelaufen: Das vom entfernten Server vorgelegte Zertifikat hat sein Ablaufdatum überschritten, so dass es für die Verschlüsselung nicht mehr vertrauenswürdig ist.
- zertifikat_nicht_gültig_noch: Das vom entfernten Server vorgelegte Zertifikat ist noch nicht gültig, möglicherweise aufgrund einer falschen Serverzeit oder einer verfrühten Verwendung des Zertifikats.
- zertifikat_widerrufen: Das vom Fernserver vorgelegte Zertifikat wurde von der Zertifizierungsstelle aufgrund von Sicherheitsbedenken widerrufen.
- untrusted_certificate: Die vom Remoteserver vorgelegte Zertifikatskette wird vom Mailserver oder -client des Absenders nicht als vertrauenswürdig eingestuft, was auf ein potenzielles Sicherheitsrisiko hinweist.
- keine_gültige_Unterschrift: Das vom Remote-Server vorgelegte Zertifikat ist nicht ordnungsgemäß von einer vertrauenswürdigen Zertifizierungsstelle signiert, was Bedenken hinsichtlich seiner Authentizität aufkommen lässt.
- nicht unterstütztes_Zertifikat: Das vom entfernten Server vorgelegte Zertifikat verwendet Verschlüsselungsalgorithmen oder Schlüssellängen, die vom Mailserver des Absenders nicht unterstützt werden, was eine sichere Verbindung verhindert.
Hostname und Identität stimmen nicht überein
- hostname_mismatch: Der im Zertifikat des Servers angegebene Hostname stimmt nicht mit dem Hostnamen des Servers überein, mit dem sich der Mailserver des Absenders zu verbinden versucht. Dies weist auf einen möglichen Man-in-the-Middle-Angriff oder ein Konfigurationsproblem hin.
Cipher Suite und Verschlüsselungskonfiguration
- insecure_cipher_suite: Die zwischen dem Mailserver des Absenders und des Empfängers ausgehandelte Cipher-Suite wird als schwach oder unsicher angesehen, was die Vertraulichkeit und Integrität der Kommunikation gefährden kann.
- protocol_version_mismatch: Die unterstützten TLS-Protokollversionen der Mailserver des Absenders und des Empfängers stimmen nicht überein, so dass sie keine kompatible verschlüsselte Verbindung aufbauen können.
- no_shared_cipher_suite: Es gibt keine gemeinsame Cipher-Suite, die sowohl der Mailserver des Absenders als auch der des Empfängers für die Verschlüsselung verwenden können, was zu einer fehlgeschlagenen Verbindung führt.
Handshake- und Protokoll-Probleme
- handshake_failure: Während des anfänglichen TLS-Handshake-Prozesses zwischen dem Mailserver des Absenders und dem Mailserver des Empfängers ist ein Problem aufgetreten, das den Aufbau des sicheren Kanals verhindert.
- unerwartete_nachricht: Der Mailserver des Absenders hat während des TLS-Handshake-Prozesses eine unerwartete oder nicht unterstützte Nachricht erhalten, was auf eine mögliche Protokoll- oder Implementierungsfehlanpassung hinweist.
Politische Themen der MTA-STS
- mta_sts_policy_not_found: Dieser Fehler tritt auf, wenn der Mailserver des Absenders keine MTA-STS-Richtlinie für die Domäne des Empfängers finden kann.
- mta_sts_policy_invalid: Dieser Fehler tritt auf, wenn die im DNS gefundene MTA-STS-Richtlinie für die Domäne des Empfängers ungültig ist, Fehler enthält oder nicht der MTA-STS-Spezifikation entspricht.
- mta_sts_policy_fetch_error: Dieser Fehler tritt auf, wenn der Mailserver des Absenders beim Versuch, die MTA-STS-Richtlinie aus den DNS-Einträgen der Empfängerdomäne abzurufen, auf einen Fehler stößt.
- mta_sts_connection_failure: Dieser Fehler tritt auf, wenn der Mailserver des Absenders versucht, eine sichere Verbindung mit MTA-STS aufzubauen, dies aber aus Gründen wie nicht vertrauenswürdigen Zertifikaten, nicht unterstützten Cipher Suites oder anderen TLS-Problemen fehlschlägt.
- mta_sts_ungültiger_hostname: Dieser Fehler tritt auf, wenn der Hostname des Mailservers des Empfängers, wie in der MTA-STS-Richtlinie angegeben, nicht mit dem tatsächlichen Hostnamen des Servers übereinstimmt.
- mta_sts_policy_upgrade: Dieser Fehler tritt auf, wenn der Mailserver des Absenders versucht, die Verbindung mit Hilfe von MTA-STS auf eine sichere Verbindung umzustellen, der Server des Empfängers die Umstellung aber nicht unterstützt.
Vereinfachte SMTP-TLS-Berichterstattung mit PowerDMARC
Die SMTP-TLS-Berichterstattung von PowerDMARC ist darauf ausgerichtet, Ihre Sicherheit zu verbessern und Ihnen das Leben mit einem gehosteten Dienst zu erleichtern.
Übersetzte TLS-Berichte
Komplexe JSON-Berichte für die TLS-Berichterstattung werden in vereinfachte Informationen umgewandelt, die Sie in Sekundenschnelle überfliegen oder im Detail lesen können
Probleme mit der automatischen Erkennung
Die PowerDMARC-Plattform lokalisiert automatisch das Problem, das Sie haben, damit Sie es ohne Zeitverlust lösen können
- DMARC Schwarzer Freitag: Sichern Sie Ihre E-Mails in der Weihnachtszeit - 23. November 2023
- Google und Yahoo aktualisieren E-Mail-Authentifizierungsanforderungen für 2024 - November 15, 2023
- Wie finden Sie den besten DMARC-Lösungsanbieter für Ihr Unternehmen? - November 8, 2023
