SMTP ist ein Kommunikationsprotokoll für die elektronische Postübertragung, und die SMTP-TLS-Berichterstattung ist ein Mechanismus zur Erkennung potenzieller Fehlkonfigurationen. Gehen wir Schritt für Schritt vor, um den Arbeitsprozess von SMTP (Simple Mail Transfer Protocol) und den TLS-Berichtsmechanismus zu beschreiben.
Ziel des Simple Mail Transfer Protocol (SMTP) ist es, E-Mails zuverlässig und effizient zu übertragen.
Mail Transfer Agent (MTA)
- Empfängt E-Mails von der MUA des Kunden
- Verwendet SMTP zur Weiterleitung von E-Mails zwischen Servern
- Leitet E-Mails zur endgültigen Zustellung an den MDA weiter
[ED:text-important]Damit zwei E-Mail-Server miteinander kommunizieren können, MÜSSEN SMTP und MTA laufen, um E-Mails zwischen den beiden Servern zu übertragen!
SMTP wird für die Weiterleitung von E-Mails verwendet, POP für die Zustellung von E-Mails.
[/ED:text-important]
Mail Delivery Agent (MDA)
MDA empfängt Nachrichten von der MUA oder vom MTA, um die E-Mails zu sortieren und an die Mailbox des Empfängers zuzustellen. Jedes Programm, das eine Nachricht für die Zustellung so bearbeitet, dass sie von einer E-Mail-Client-Anwendung gelesen werden kann, kann als MDA betrachtet werden. Aus diesem Grund können einige MTAs (wie Sendmail und Postfix) die Rolle eines MDAs übernehmen, wenn sie neue E-Mail-Nachrichten an einen lokalen Benutzer anhängen.
SMTP-verschlüsselte Kanäle
Das ursprüngliche SMTP-Protokoll unterstützte nur unauthentifizierte, unverschlüsselte Kommunikation. Es ist anfällig für Man-in-the-Middle-Angriffe, Spoofing und Spamming und erfordert die Verschlüsselung aller Binärdaten vor der Übertragung.
Es gibt eine Reihe von Protokollen zur Einrichtung verschlüsselter Kanäle zwischen SMTP Mail Transfer Agents (MTAs), darunter
- STARTTLS
STARTTLS ist ein Protokollbefehl, der von einem E-Mail-Client ausgegeben wird. Er zeigt an, dass der Client eine bestehende, unsichere Verbindung zu einer sicheren Verbindung unter Verwendung des kryptografischen SSL/TLS-Protokolls aufwerten möchte. Der Befehlsname STARTTLS wird von den Protokollen SMTP und IMAP verwendet, während das POP3-Protokoll STLS als Befehlsname verwendet.
- DNS-Based Authentication of Named Entities (DANE) TLSA
DNS-Based Authentication of Named Entities, kurz „DANE“, ermöglicht es Ihnen, genau festzulegen, welches TLS/SSL-Zertifikat eine Anwendung oder ein Dienst verwenden soll, um sich mit Ihrer Domain zu verbinden.
- MTA Strict Transport Security (MTA-STS)
SMTP MTA Strict Transport Security (MTA-STS) ist ein Mechanismus, der es Mail Service Providern (SPs) ermöglicht, ihre Fähigkeit zu erklären, sichere SMTP-Verbindungen mit Transport Layer Security (TLS) zu empfangen und anzugeben, ob sendende SMTP-Server die Zustellung an MX-Hosts verweigern sollen, die kein TLS mit einem vertrauenswürdigen Serverzertifikat anbieten.
Diese Protokolle können aufgrund von Fehlkonfigurationen oder aktiven Angriffen versagen, was dazu führt, dass Nachrichten nicht zugestellt werden oder über unverschlüsselte oder nicht authentifizierte Kanäle zugestellt werden. Domain-Inhaber können SMTP-TLS-Meldeinformationen nutzen, um sowohl potenzielle Angriffe zu erkennen als auch unbeabsichtigte Fehlkonfigurationen zu diagnostizieren.
SMTP TLS Reporting definiert einen Meldemechanismus, der Fehler beim Routing, der DNS-Auflösung und der STARTTLS-Aushandlung sowie Fehler bei der Richtlinienvalidierung sowohl für DANE als auch für MTA-STS abdeckt. Ein Standard-TXT-Eintrag kann verwendet werden, um anzugeben, wohin Berichte in diesem Format gesendet werden sollen. Der Bericht kann auch als „Heartbeat“ dienen, um anzuzeigen, dass die Systeme TLS während der Sitzungen wie erwartet erfolgreich aushandeln.
Die MTA-STS-Richtlinie ist ein Mechanismus, mit dem Systemadministratoren oder Domain-Inhaber die erwartete TLS-Verfügbarkeit, die präsentierte Identität und die gewünschten Aktionen für eine bestimmte E-Mail-Empfänger-Domain festlegen können.
SMTP TLS Reporting-Richtlinie
Eine Domain veröffentlicht einen Eintrag in ihrem DNS, der angibt, dass sie Berichte erhalten möchte. Diese SMTP-TLSRPT-Richtlinien werden über DNS von der Zone der Richtlinien-Domain als TXT-Einträge wie DMARC-Richtlinien unter dem Namen „_smtp._tls“ verteilt.
Zum Beispiel kann für die Richtlinien-Domain „easydmarc.com“ die TLSRPT-Richtlinie des Empfängers abgerufen werden von
“_smtp._tls.easydmarc.com“.
“v=TLSRPTv1; rua=mailto:[email protected]”
- “v”: Version von TLSRPT, bei der dieser Wert gleich „TLSRPTv1“ sein MUSS.
- “rua”: Ein URI, der den Endpunkt angibt, an den aggregierte Informationen über Richtlinienvalidierungsergebnisse gesendet werden sollen.
Hinweis: Im Falle von „mailto“ sollten die Berichte an die angegebene E-Mail-Adresse gesendet werden. Beim Versand von Fehlerberichten über SMTP MÜSSEN die sendenden MTAs die Berichte trotz TLS-bedingter Fehler zustellen und SOLLTEN diese SMTP-Sitzung NICHT in den nächsten Bericht aufnehmen. Dies kann bedeuten, dass die Berichte unverschlüsselt zugestellt werden. Über SMTP gesendete Berichte MÜSSEN eine gültige DomainKeys Identified Mail (DKIM)-Signatur der meldenden Domain enthalten. Berichte ohne eine solche Signatur MÜSSEN vom Empfänger ignoriert werden. DKIM-Signaturen DÜRFEN NICHT das Attribut „l=“ verwenden, um die Länge des in der Signatur verwendeten Textkörpers zu begrenzen. Dadurch wird sichergestellt, dass Angreifer keine fremden oder irreführenden Daten an einen Bericht anhängen können, ohne die Signatur zu brechen. Der DKIM-TXT-Eintrag MUSS die entsprechende Diensttyp-Deklaration „s=tlsrpt“ enthalten. Ist dies nicht der Fall, KANN das empfangende System Berichte ignorieren, die diesen Diensttyp nicht enthalten.
SMTP TLS Reporting-Schema
Der Bericht besteht aus einer Klartextdatei, die im Internet-JSON-Format (I-JSON) kodiert ist.
Aggregierte Berichte enthalten die folgenden Felder:
Metadaten des Berichts:
- Die für den Bericht verantwortliche Organisation
- Kontaktinformationen für eine oder mehrere Parteien, die für den Inhalt des Berichts verantwortlich sind
- Ein eindeutiger Identifikator für den Bericht
- Der Datumsbereich für den Bericht
Richtlinie, bestehend aus Folgendem:
1 . Eine der folgenden Richtlinienarten:
- die angewandte MTA-STS-Richtlinie (als String)
- der angewandte DANE TLSA-Eintrag (als String, mit jedem RR-Eintrag des RRsets aufgelistet und durch ein Semikolon getrennt)
- die Zeichenkette „no-policy-found“, wenn weder eine DANE- noch eine MTA-STS-Richtlinie gefunden werden konnte
- Die Domain, auf die die Richtlinie angewendet wird
- Der MX-Host
- Aggregierte Zählungen, die den Ergebnistyp, die IP-Adresse des sendenden MTA, den Hostnamen des empfangenden MTA, die Anzahl der Sitzungen und ein optionales zusätzliches Informationsfeld umfassen, das einen URI enthält, über den die Empfänger weitere Informationen zu einem Fehlertyp einsehen können.
Zusammenfassung des Berichts
Erfolgszahl
“total-successful-session-count”: Dieses Feld enthält die Gesamtzahl der erfolgreichen Verbindungen für das Meldesystem.
Fehlerzahl
“total-failure-session-count”: Dieses Feld enthält die Gesamtzahl der fehlgeschlagenen Verbindungen.
Ergebnisarten
Verhandlungsfehler
- “starttls-not-supported”: Dies zeigt an, dass der Empfänger MX nicht STARTTLS unterstützt.
- “certificate-host-mismatch”: Dies zeigt an, dass das vorgelegte Zertifikat nicht den in der MTA-STS- oder DANE-Richtlinie festgelegten Beschränkungen entsprach.
- “certificate-expired”: Dies zeigt an, dass das Zertifikat abgelaufen ist.
- “certificate-not-trusted”: Dies ist ein Etikett, das mehrere Fehler im Zusammenhang mit Zertifikaten abdeckt.
- “validation-failure”: Dies zeigt einen allgemeinen Fehler aus einem Grund an, der nicht einer der oben genannten Kategorien entspricht.
Richtlinienfehler
DANE-spezifische Richtlinienfehler
- “tlsa-invalid”: Dies zeigt einen Validierungsfehler im TLSA-Eintrag an, der mit einer DANE-Richtlinie verbunden ist.
- “dnssec-invalid”: Dies zeigt an, dass keine gültigen Einträge vom rekursiven Resolver zurückgegeben wurden.
- “dane-required”: Dies zeigt an, dass das sendende System so konfiguriert ist, dass DANE TLSA-Einträge für alle MX-Hosts der Zieldomain erforderlich sind, aber keine DNSSEC-validierten TLSA-Einträge für den MX-Host vorhanden sind, der Gegenstand des Berichts ist.
MTA-STS-spezifische Richtlinienfehler
- “sts-policy-fetch-error”: Dies zeigt an, dass der Abruf einer MTA-STS-Richtlinie fehlgeschlagen ist, z. B. weil der Host der Richtlinie nicht erreichbar ist.
- “sts-policy-invalid”: Dies zeigt einen Validierungsfehler für die gesamte MTA-STS Policy an.
- “sts-webpki-invalid”: Dies zeigt an, dass die MTA-STS-Richtlinie nicht mithilfe der PKIX-Validierung authentifiziert werden konnte.
JSON-Bericht-Schema
Hier ist das Beispiel:
{
„organization-name“: organization-name,
„date-range“: {
„start-datetime“: date-time,
„end-datetime“: date-time
},
„contact-info“: email-address,
„report-id“: report-id,
„policies“: [{
„policy“: {
„policy-type“: policy-type,
„policy-string“: policy-string,
„policy-domain“: domain,
„mx-host“: mx-host-pattern
},
„summary“: {
„total-successful-session-count“: total-successful-session-count,
„total-failure-session-count“: total-failure-session-count
},
„failure-details“: [
{
„result-type“: result-type,
„sending-mta-ip“: ip-address,
„receiving-mx-hostname“: receiving-mx-hostname,
„receiving-mx-helo“: receiving-mx-helo,
„receiving-ip“: receiving-ip,
„failed-session-count“: failed-session-count,
„additional-information“: additional-info-uri,
„failure-reason-code“: failure-reason-code
}
]
}
]
}
“organization-name”: Der Name der Organisation, die für den Bericht verantwortlich ist. Er wird als Zeichenkette angegeben.
“date-time”: Die Datumszeit gibt die Anfangs- und Endzeit für den Berichtsbereich an.
“email-address”: Die Kontaktinformationen der für den Bericht verantwortlichen Partei.
“report-id”: Ein eindeutiger Identifikator für den Bericht.
“policy-type”: Die Art der Richtlinie, die von der sendenden Domain angewendet wurde.
“policy-string”: Eine Kodierung der angewandten Richtlinie als JSON-Array von Zeichenketten.
“domain”: Die Richtlinien-Domain, für die die MTA-STS- oder DANE-Richtlinie definiert ist.
“mx-host-pattern”: Wenn „policy-type“ „sts“ ist, handelt es sich um das Muster der MX-Hostnamen aus der angewandten Richtlinie.
“ip-address”: Die IP-Adresse des sendenden MTA, der die STARTTLS-Verbindung versucht hat.
“receiving-mx-hostname”: Der Hostname des MX-Eintrags des empfangenden MTA, mit dem der sendende MTA versucht hat, eine STARTTLS-Verbindung auszuhandeln.
“receiving-mx-helo” (optional): Die Zeichenkette HELLO (HELO) oder Extended HELLO (EHLO) des Banners, das während der gemeldeten Sitzung angekündigt wurde.
“receiving-ip”: Die Ziel-IP-Adresse, die bei der Erstellung der ausgehenden Sitzung verwendet wurde.
“total-successful-session-count”: Die Gesamtzahl der erfolgreich ausgehandelten TLS-fähigen Verbindungen zur empfangenden Website.
“total-failure-session-count”: Die Gesamtzahl der Fehlschläge bei der Aushandlung einer TLS-fähigen Verbindung zur empfangenden Website.
“failed-session-count”: Die Anzahl der (versuchten) Sitzungen, die dem entsprechenden „Ergebnistyp“ für diesen Abschnitt entsprechen.
“additional-info-uri” (optional): Ein URI, der auf zusätzliche Informationen über den betreffenden „Ergebnistyp“ verweist. Dieser URI könnte beispielsweise die vollständige Zertifikatskette hosten, die bei einer versuchten STARTTLS-Sitzung vorgelegt wird.
“failure-reason-code”: Ein Textfeld zur Aufnahme eines TLS-bezogenen Fehlercodes oder einer Fehlermeldung.
Die SMTP-TLS-Berichterstattung bietet Einblick in Fehlkonfigurationen oder Versuche, E-Mails zwischen Hosts, die STARTTLS unterstützen, abzufangen oder zu manipulieren.
Melden Sie sich an, um die Sicherheit Ihrer Domain zu verbessern.
SPF Permerror – SPF zu viele DNS-Abfragen
Was ist ein DKIM-Selektor und wie funktioniert er?