|
DMARC |
Scrollen Zurück Oberste Ebene Weiter Mehr |
DMARC steht für "Domain-based Message Authentication, Reporting & Conformance" (domänengestützte Echtheitsbestätigung von Nachrichten, Berichte und Überwachung der Richtlinienkonformität). DMARC ist eine Spezifikation, die missbräuchliche Nutzung von E-Mail-Nachrichten, etwa durch Spam und Phishing, eindämmen soll. DMARC soll insbesondere gefälschten Absenderangaben in der Absenderkopfzeile From: (Von:) der Nachrichten entgegenwirken, die Empfänger von Nachrichten über deren Absender täuschen. DMARC gestattet es den Inhabern von Domänen, das Domain Name System (DNS) zu nutzen, um Empfänger über ihre DMARC-Richtlinien zu informieren. Diese Richtlinien bestimmen die Behandlung solcher Nachrichten durch die Server der Nachrichtenempfänger, die angeblich von einem bestimmten Absender stammen, deren Absender aber nicht echtheitsbestätigt werden kann und daher möglicherweise falsch angegeben ist. Die Server der Nachrichtenempfänger rufen die Richtlinien über eine DNS-Abfrage während der Verarbeitung eingehender Nachrichten ab. Die Richtlinien können bestimmen, dass der Server des Nachrichtenempfängers Nachrichten in Quarantäne geben oder abweisen soll, falls sie nicht richtlinienkonform sind, oder dass der Server keine Maßnahmen ergreifen soll (die Nachricht wird dann normal verarbeitet). Die DNS-Einträge für DMARC können auch Anforderungen enthalten, die Server von Nachrichtenempfängern zum Versand bestimmter Berichte veranlassen. Solche Berichte können die Anzahl der eingehenden Nachrichten angeben, die angeblich aus einer Domäne stammen, die Anteile der erfolgreich und nicht erfolgreich echtheitsbestätigten Nachrichten und Einzelheiten über fehlgeschlagene Echtheitsbestätigungsversuche. Die Leistungsmerkmale für die DMARC-Berichte können insbesondere helfen, die Effizienz der eigenen Echtheitsbestätigungsmaßnahmen für E-Mail-Nachrichten zu beurteilen, und sie geben Auskunft darüber, wie oft die eigene Domäne durch Dritte für gefälschte Absenderangaben missbraucht wird.
Der Abschnitt Echtheitsbestätigung für Absender im Menü Sicherheitseinstellungen ist in drei Konfigurationsdialoge zur Steuerung der DMARC-Prüfung und der Berichte in MDaemon untergliedert: DMARC-Prüfung, DMARC-Berichte und DMARC-Optionen.
DMARC-Prüfung
Während der DMARC-Prüfung fragt MDaemon die DMARC-Richtlinien durch eine DNS-Abfrage ab; diese Abfrage bezieht sich auf die Domäne in der Absenderkopfzeile From: (Von:) jeder eingehenden Nachricht. Die Abfrage prüft zunächst, ob die Domäne DMARC nutzt und ruft bejahendenfalls den DNS-Eintrag für DMARC ab. Diese DNS-Eintrag enthält die DMARC-Richtlinie und verwandte Informationen. DMARC nutzt außerdem das SPF und DKIM, um jede eingehende Nachricht zu prüfen, und die Prüfung durch SPF oder DKIM muss erfolgreich verlaufen, damit auch die DMARC-Prüfung erfolgreich sein kann. Besteht eine Nachricht diese Prüfungen, so wird sie durch den üblichen Filter- und Zustellvorgang in MDaemon normal weiterbearbeitet. Besteht eine Nachricht die Prüfung nicht, dann richtet sich ihre weitere Behandlung nach den DMARC-Richtlinien der angeblichen Absenderdomäne und danach, wie MDaemon für die Behandlung solcher Nachrichten konfiguriert ist.
Besteht eine Nachricht die DMARC-Prüfung nicht, und ist für die angebliche Absenderdomäne die DMARC-Richtlinie "p=none" veröffentlicht, so ergreift MDaemon keine Abwehrmaßnahmen, und die Nachricht wird normal weiterverarbeitet. Ist für die angebliche Absenderdomäne jedoch eine restriktive DMARC-Richtlinie veröffentlicht, also "p=quarantine" oder "p=reject", dann kann MDaemon die Nachricht automatisch in den Spam-Ordner des Empfängers (z.B. Junk-E-Mail) leiten. Sie können auch bestimmen, dass MDaemon die Nachricht dann abweist, wenn für die angebliche Absenderdomäne die Richtlinie "p=reject" veröffentlicht ist. In Nachrichten, für deren angebliche Absenderdomänen restriktive Richtlinien veröffentlicht sind, fügt MDaemon je nach veröffentlichter Richtlinie die Kopfzeilen "X-MDDMARC-Fail-policy: quarantine" oder "X-MDDMARC-Fail-policy: reject" ein. Hiermit können Sie durch den Inhaltsfilter weitere Maßnahmen auslösen, die diese Kopfzeilen auswerten und Nachrichten beispielsweise in einen besonderen Ordner zur genaueren Untersuchung leiten.
Die DMARC-Prüfung ist per Voreinstellung aktiv und wird für die meisten Einsatzgebiete von MDaemon empfohlen.
DMARC-Berichte
Die DMARC-Einträge, die MDaemon aus dem DNS abfragt, können Tags enthalten, durch die der Domäneninhaber anzeigt, dass er bestimmte zusammengefasste Statistik- und Fehlerberichte über die DMARC-gestützte Behandlung solcher Nachrichten erhalten will, die angeblich aus seiner Domäne stammen. Die Optionen im Konfigurationsdialog DMARC-Berichte bestimmen, ob Ihr System die angeforderten Arten von Berichten versenden soll, und welche Metadaten die Berichte enthalten sollen. Zusammengefasste Berichte werden jeden Tag um Mitternacht (UTC-Zeit) gesendet. Fehlerberichte werden für jede Nachricht dann gesendet, wenn eine fehlgeschlagene Prüfung den Fehlerbericht auslöst. Alle Berichte werden als XML-Dateien in ZIP-Archiven versandt, die als Dateianlage an die Berichtsnachrichten angehängt werden. Es stehen verschiedene Auswertungsprogramme zur Verfügung, mit deren Hilfe die Empfänger die Berichte einsehen und auswerten können.
Per Voreinstellung versendet MDaemon keine zusammengefassten Berichte und keine Fehlerberichte. Falls Sie solche Berichte versenden lassen wollen, aktivieren Sie die entsprechenden Optionen im Konfigurationsdialog DMARC-Berichte.
DMARC-Einstellungen
Der Konfigurationsdialog DMARC-Optionen enthält Optionen zur Aufnahme bestimmter Daten in DKIM-Berichte, zur Protokollierung von DNS-Einträgen für DMARC und zur Aktualisierung der Liste öffentlicher Domänenendungen, die MDaemon für DMARC nutzt.
Wechselwirkung zwischen DMARC-Prüfung und Mailinglisten
DMARC soll sicherstellen, dass die Domäne in der Absenderkopfzeile From: eingehender Nachrichten nicht gefälscht ist sondern dem wirklichen Absender entspricht. DMARC muss daher überprüfen, ob der Server, der die Nachricht übermittelt, zum Versand von Nachrichten für die Absenderdomäne auch wirklich berechtigt ist. Bei Mailinglisten kann dies zu einem besonderen Problem führen. Es ist nämlich bei Mailinglisten üblich, dass diese die Listennachrichten für alle, auch fremde, Listenmitglieder versenden, dass dabei die Absenderkopfzeile From: unverändert bleibt und noch die ursprüngliche Domäne des Absenders enthält. Empfängt ein Server eine solche Listennachricht, und führt er eine DMARC-Prüfung für die Nachricht aus, dann stellt er hierbei fest, dass ein Server die Nachricht versandt hat, der eigentlich gar nicht berechtigt ist, für die Domäne in der Absenderkopfzeile From: Nachrichten zu versenden. Ist für die Domäne in der Absenderkopfzeile From: eine restriktive DMARC-Richtlinie veröffentlicht, so kann dies dazu führen, dass der Server des Empfängers die Listennachricht in Quarantäne gibt oder sogar abweist. Außerdem kann in bestimmten Fällen der Empfänger der Listennachricht automatisch aus der Mailingliste entfernt werden. Um dieses Problem zu umgehen, ersetzt MDaemon den Inhalt der Absenderkopfzeile From: in Listennachrichten dann durch die E-Mail-Adresse der Mailingliste, wenn für die Domäne des Absenders eine restriktive DMARC-Richtlinie veröffentlicht ist. Sie können MDaemon aber auch so konfigurieren, dass Listennachrichten aus Domänen mit restriktiven DMARC-Richtlinien abgewiesen werden. Diese Option macht es Benutzern aus Domänen mit restriktiven DMARC-Richtlinien aber unmöglich, Nachrichten in der Mailingliste zu veröffentlichen. Die Option zum Ersetzen der Absenderkopfzeile From: ist im Abschnitt Kopfzeilen des Editors für Mailinglisten enthalten. Die Option, Nachrichten abzuweisen, ist im Abschnitt Einstellungen enthalten.
Die Nutzung von DMARC für eigene MDaemon-Domänen
Die Nutzung von DMARC für eigene Domänen, die die Server der Nachrichtenempfänger in die Lage versetzt, DMARC zur Prüfung solcher Nachrichten einzusetzen, die angeblich aus den eigenen Domänen stammen, hängt von mehreren Voraussetzungen ab. Sie müssen zunächst sicherstellen, dass Sie für die betroffenen Domänen gültige DNS-Einträge für SPF und DKIM erstellt haben. SPF oder DKIM oder beide Verfahren zugleich müssen funktionsfähig eingerichtet sein, damit DMARC nutzbar ist. Falls Sie DKIM nutzen, müssen Sie auch die Signatur von Nachrichten über DKIM konfigurieren, damit MDaemon die Nachrichten der betroffenen Domänen signiert. Sie müssen außerdem für die betroffenen Domänen DNS-Einträge für DMARC anlegen. Diese Einträge sind TXT-Einträge in einem bestimmten, vorgegebenen Format, die die Server der Nachrichtenempfänger abfragen, um Informationen über die DMARC-Richtlinie und verschiedene weitere Parameter zu erhalten. Solche weiteren Parameter sind insbesondere die Art der Echtheitsbestätigung, die Sie nutzen, die Festlegung, ob Sie zusammengefasste Berichte erhalten wollen, und die E-Mail-Adresse, an die die Berichte gesendet werden sollen.
Ist DMARC richtig eingerichtet, und erhalten Sie XML-Berichte für DMARC, so stehen Ihnen eine Reihe von Online-Werkzeugen zur Verfügung, mit deren Hilfe Sie die Berichte auswerten und mögliche Probleme erkennen können. Zur einfacheren Handhabung steht im Verzeichnis \MDaemon\App\ auch ein Hilfsprogramm namens DMARC Reporter zur Verfügung. Nähere Informationen über seine Nutzung enthält in englischer Sprache die Datei DMARCReporterReadMe.txt.
Erstellen eines DMARC-Ressourceneintrags vom Typ TXT
Nachfolgend finden Sie einen Überblick über grundlegende und häufig genutzte Bestandteile eines DMARC-Eintrags. Nähere Informationen und Hinweise zu fortgeschrittenen Konfigurationsmöglichkeiten erhalten Sie auf der Website www.dmarc.org.
Feld "Owner" (Inhaber)
Das Feld "Owner" (es wird auch als "Name" oder "left-hand" bezeichnet) im DMARC-Ressourceneintrag muss immer den Inhalt _dmarchaben. Falls Sie die Domäne oder Subdomäne angeben wollen, auf die sich der Eintrag bezieht, so können Sie das Format _dmarc.domänen.name hierfür nutzen.
Ein Beispiel hierzu:
Ein DMARC-Eintrag für die Domäne example.com
_dmarc IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt für E-Mail-Nachrichten von benutzer@example.com und allen Subdomänen von example.com, also beispielsweise benutzer@support.example.com.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt nur für E-Mail-Nachrichten von benutzer@support.example.com, nicht jedoch beispielsweise für benutzer@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Dieser Eintrag wirkt für E-Mail-Nachrichten von benutzer@support.example.com, benutzer@a.support.example.com, benutzer@a.b.support.example.com und so weiter.
Tags und Parameter für die DMARC-Einträge
Zwingend erforderliche Tags
Tag |
Parameter |
Erläuterung |
v= |
DMARC1 |
Dieser Tag bestimmt die Version. Er muss der erste Tag in dem Textfeld des Ressourceneintrags sein. DMARC-Tags sind üblicherweise unabhängig von Groß- und Kleinschreibung; dies gilt aber nicht für diesen Tag. Er muss immer in Großbuchstaben gesetzt sein: DMARC1. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
none quarantine reject |
Dieser Tag bestimmt die Richtlinie (p steht für policy). Er muss der zweite Tag in dem Textfeld des Ressourceneintrags sein und auf den Tag v= folgen. p=none (keine) bedeutet, dass der Server des Nachrichtenempfängers auf Grundlage der DMARC-Prüfung keine Aktion vornehmen soll. Nachrichten, die die DMARC-Prüfung nicht bestehen, sollen aufgrund der nicht bestandenen DMARC-Prüfung nicht in Quarantäne gegeben oder abgewiesen werden. Sie können aber aus anderen Gründen in Quarantäne gegeben oder abgewiesen werden, etwa wegen einer Spam-Bewertung oder aufgrund anderer Sicherheitsprüfungen als DMARC. Die Nutzung der Richtlinie p=none wird bisweilen als Überwachungs- oder Beobachtungsmodus bezeichnet, da die Richtlinie mit dem Tag rua= gemeinsam verwendet werden kann, um zusammengefasste Berichte über die Nachrichten zu erhalten, gleichzeitig aber Abwehrmaßnahmen nach dem Fehlschlagen von DMARC-Prüfungen zu verhindern. Solange Sie Ihre DMARC-Implementation noch nicht ausführlich und gründlich getestet haben und sicher sind, dass Sie Abwehrmaßnahmen verlangen sollen (wie etwa durch Nutzung der restriktiveren Richtlinie p=quarantine), sollten Sie diese Richtlinie nutzen. p=quarantine (Quarantäne) bedeutet, dass der Server des Nachrichtenempfängers Nachrichten als verdächtig behandeln soll, falls diese laut Absenderkopfzeile From: aus Ihrer Domäne stammen, aber die DMARC-Prüfung nicht bestehen. Je nach der Konfiguration des Servers des Nachrichtenempfängers können solche Nachrichten zusätzlichen Prüfmaßnahmen unterworfen werden, auch können Sie in die Spam-Ordner der Empfänger einsortiert, an einen anderen Server geleitet oder weiteren Maßnahmen unterworfen werden. p=reject (abweisen) bedeutet, dass der Server des Nachrichtenempfängers alle Nachrichten abweisen soll, die die DMARC-Prüfung nicht bestehen. Manche Server sind unter Umständen so konfiguriert, dass sie solche Nachrichten entgegen der Richtlinie annehmen, sie dann aber in Quarantäne geben oder zusätzlichen Prüfmaßnahmen unterwerfen. Diese Richtlinie ist die restriktivste Richtlinie; Sie sollten sie nur dann einsetzen, wenn sie endgültig sicher sind, dass Ihre E-Mail-Richtlinien und ihre Infrastruktur sowie die E-Mail-Dienste, die Sie nutzen wollen, und die Benutzerkonten richtig eingerichtet sind und funktionieren. Wollen Sie Ihren Benutzern beispielsweise gestatten, Mitglieder in Mailinglisten von Drittanbietern zu werden, Weiterleitungsdienste zu nutzen, Funktionen zum "Teilen" oder Weiterleiten von Website-Inhalten oder vergleichbare Leistungsmerkmale zu nutzen, dann führt die Nutzung der Richtlinie p=reject mit hoher Wahrscheinlichkeit dazu, dass auch legitime Nachrichten abgewiesen werden. Es kann auch dazu führen, dass Benutzer automatisch aus Mailinglisten entfernt oder gar nicht erst in sie aufgenommen werden. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-berichte@example.net" |
Optionale Tags
Die nachfolgend aufgeführten Tags sind wahlfrei. Enthält ein Ressourceneintrag diese Tags nicht, dann werden die jeweiligen Vorgaben angenommen und verwendet
Tag |
Parameter |
Erläuterung |
sp= |
none quarantine reject — Vorgabe: Falls sp= nicht verwendet wird, wirkt der Tag p= auf die Domäne und die Subdomänen. |
Dieser Tag bestimmt die Richtlinien, die für Subdomänen der Domäne wirken sollen, auf die sich der DMARC-Ressourceneintrag bezieht. Wird dieser Tag beispielsweise in einem Eintrag verwendet, der sich auf example.com bezieht, dann wirkt die Richtlinie aus dem Tag p= auf E-Mail-Nachrichten aus der Domäne example.com, und die Richtlinie aus dem Tag sp= wirkt auf E-Mail-Nachrichten aus Subdomänen von example.com, etwa mail.example.com. Wird dieser Tag nicht verwendet, so wirkt der Tag p= auf die Domäne und alle ihre Subdomänen. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Kommagetrennte Liste der E-Mail-Adressen, an die zusammengefasste DMARC-Berichte gesendet werden sollen. Die Adressen müssen als URIs im Format — Vorgabe: keine Falls dieser Tag nicht verwendet wird, werden keine zusammengefassten Berichte gesendet. |
Dieser Tag zeigt an, dass Sie zusammengefasste DMARC-Berichte von den Servern der Nachrichtenempfänger erhalten wollen, bei denen Nachrichten mit Adressen aus Ihrer Domäne in der Absenderkopfzeile From: eingehen. Geben Sie mindestens eine E-Mail-Adresse als URI im Format mailto:benutzer@example.com an, und trennen Sie mehrere URIs durch Kommata. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:benutzer01@example.com,mailto:benutzer02@example.com" Die E-Mail-Adressen gehören üblicherweise zu der Domäne, auf die sich der DMARC-Ressourceneintrag bezieht. Falls Sie die Berichte an eine E-Mail-Adresse in einer anderen Domäne senden wollen, dann muss die DNS-Zonendatei dieser anderen Domäne einen besonderen DMARC-Eintrag enthalten, der anzeigt, dass die Domäne die fremden DMARC-Berichte akzeptiert. Ein Beispielseintrag für die Domäne example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:nicht-lokaler-benutzer@example.net" Hierzu der erforderliche Eintrag für die Domäne example.net: example.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Kommagetrennte Liste der E-Mail-Adressen, an die DMARC-Fehlerberichte gesendet werden sollen. Die Adressen müssen als URIs im Format — Vorgabe: keine Falls dieser Tag nicht verwendet wird, werden keine DMARC-Fehlerberichte gesendet. |
Dieser Tag zeigt an, dass Sie DMARC-Fehlerberichte von den Servern der Nachrichtenempfänger erhalten wollen, bei denen Nachrichten mit Adressen aus Ihrer Domäne in der Absenderkopfzeile From: eingehen. Damit die Fehlerberichte versandt werden, müssen die Bedingungen aus dem Tag fo= erfüllt sein. Wird der Tag fo= nicht verwendet, so werden per Voreinstellung die DMARC-Fehlerberichte dann versendet, wenn bei einer Nachricht alle DMARC-Prüfungen (also SPF und DKIM) fehlschlagen. Geben Sie mindestens eine E-Mail-Adresse als URI im Format mailto:benutzer@example.com an, und trennen Sie mehrere URIs durch Kommata. Ein Beispiel hierzu: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" Die E-Mail-Adressen gehören üblicherweise zu der Domäne, auf die sich der DMARC-Ressourceneintrag bezieht. Falls Sie die Berichte an eine E-Mail-Adresse in einer anderen Domäne senden wollen, dann muss die DNS-Zonendatei dieser anderen Domäne einen besonderen DMARC-Eintrag enthalten, der anzeigt, dass die Domäne die fremden DMARC-Berichte akzeptiert. Ein Beispielseintrag für die Domäne example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Hierzu der erforderliche Eintrag für die Domäne example.net: example.com._report._dmarc TXT "v=DMARC1" |
Ausführliche Informationen über die Spezifikation für DMARC erhalten Sie auf der Website www.dmarc.org.
Siehe auch:
