6. Policy (Richtlinie)
DMARC-Richtlinien werden von Domain-Inhabern (Domain Owner) veröffentlicht und von E-Mail-Empfängern (Mail Receiver) angewendet.
Ein Domain-Inhaber kündigt die DMARC-Teilnahme einer oder mehrerer seiner Domains an, indem er einen DNS-TXT-Eintrag (beschrieben in Abschnitt 6.1) zu diesen Domains hinzufügt. Dabei stellen Domain-Inhaber spezifische Anforderungen an E-Mail-Empfänger bezüglich der Disposition von Nachrichten, die vorgeben, von einer der Domains des Domain-Inhabers zu stammen, und der Bereitstellung von Feedback über diese Nachrichten.
Ein Domain-Inhaber kann wählen, nicht an der DMARC-Bewertung durch E-Mail-Empfänger teilzunehmen. In diesem Fall lehnt der Domain-Inhaber einfach ab, die Teilnahme an diesen Schemata anzukündigen. Wenn beispielsweise die Ergebnisse von Pfadautorisierungsprüfungen nicht als Teil des gesamten DMARC-Ergebnisses für eine gegebene Autor-Domain betrachtet werden sollten, veröffentlicht der Domain-Inhaber keinen SPF-Richtlinieneintrag, der ein SPF-Pass-Ergebnis erzeugen kann.
Ein E-Mail-Empfänger, der den DMARC-Mechanismus implementiert, sollte (SHOULD) einen Best-Effort-Versuch unternehmen, sich an die vom Domain-Inhaber veröffentlichte DMARC-Richtlinie zu halten, wenn eine Nachricht den DMARC-Test nicht besteht. Da E-Mail-Ströme kompliziert sein können (aufgrund von Weiterleitung, bestehenden RFC5322.From-Domain-Spoofing-Diensten usw.), können (MAY) E-Mail-Empfänger während der Nachrichtenverarbeitung von der veröffentlichten Richtlinie eines Domain-Inhabers abweichen und sollten (SHOULD) die Tatsache und den Grund für die Abweichung dem Domain-Inhaber über Feedback-Berichte zur Verfügung stellen, insbesondere unter Verwendung der „PolicyOverride"-Funktion des aggregierten Berichts (siehe Abschnitt 7.2).
6.1. DMARC Policy Record (DMARC-Richtlinieneintrag)
Die DMARC-Präferenzen des Domain-Inhabers werden als DNS-TXT-Einträge in Subdomains mit dem Namen „_dmarc" gespeichert. Beispielsweise würde der Domain-Inhaber von „example.com" DMARC-Präferenzen in einem TXT-Eintrag bei „_dmarc.example.com" veröffentlichen. Ebenso würde ein E-Mail-Empfänger, der DMARC-Präferenzen bezüglich E-Mails mit einer RFC5322.From-Domain von „example.com" abfragen möchte, eine TXT-Abfrage an das DNS für die Subdomain von „_dmarc.example.com" stellen. Die im DNS befindlichen DMARC-Präferenzdaten werden im Folgenden als „DMARC-Eintrag" bezeichnet.
Die Verwendung des Domain Name Service durch DMARC wird durch die Verwendung von Domainnamen durch DMARC und die Art der durchgeführten Abfrage bestimmt. Die Abfrageanforderung passt zum DNS, um einfache parametrische Informationen zu erhalten. Es verwendet eine etablierte Methode zum Speichern der Informationen, die mit dem Ziel-Domainnamen verbunden sind, nämlich einen isolierten TXT-Eintrag, der auf den DMARC-Kontext beschränkt ist. Die Verwendung des DNS als Abfragedienst hat den Vorteil, eine äußerst gut etablierte Betriebs-, Verwaltungs- und Managementinfrastruktur wiederzuverwenden, anstatt eine neue zu erstellen.
Gemäß [DNS] kann ein TXT-Eintrag aus mehreren „character-string"-Objekten bestehen. In diesem Fall muss (MUST) das Modul, das die DMARC-Bewertung durchführt, diese Zeichenfolgen verketten, indem es die Objekte in der Reihenfolge zusammenfügt und das Ergebnis als einzelne Zeichenfolge analysiert.
6.2. DMARC URIs (DMARC-URIs)
[URI] definiert eine generische Syntax zur Identifizierung einer Ressource. Der DMARC-Mechanismus verwendet dies als Format, durch das ein Domain-Inhaber das Ziel für die beiden unterstützten Berichtstypen angibt.
Der Ort, an dem solche URIs angegeben werden (siehe Abschnitt 6.3), ermöglicht die Bereitstellung einer Liste dieser URIs. Ein Bericht wird normalerweise an jeden aufgelisteten URI in der vom Domain-Inhaber bereitgestellten Reihenfolge gesendet. Empfänger können (MAY) eine Begrenzung der Anzahl der URIs auferlegen, an die sie Berichte senden, müssen (MUST) jedoch die Fähigkeit unterstützen, an mindestens zwei zu senden. Die Liste der URIs wird durch Kommas (ASCII 0x2C) getrennt.
Jedem URI kann eine maximale Berichtsgröße zugeordnet werden, die an ihn gesendet werden kann. Dies wird erreicht, indem ein Ausrufezeichen (ASCII 0x21), gefolgt von einer Maximalgrößenangabe, vor einem trennenden Komma oder einem abschließenden Semikolon angehängt wird.
Somit ist ein DMARC-URI ein URI, in dem alle Kommas oder Ausrufezeichen gemäß [URI] prozentcodiert sind, gefolgt von einem OPTIONALEN Ausrufezeichen und einer Maximalgrößenangabe, und, falls zusätzliche Berichts-URIs in der Liste vorhanden sind, einem Komma und dem nächsten URI.
Beispielsweise würde der URI mailto:[email protected]!50m anfordern, dass ein Bericht per E-Mail an „[email protected]" gesendet wird, solange die Berichtsnutzlast 50 Megabyte nicht überschreitet.
Eine formale Definition wird in Abschnitt 6.4 bereitgestellt.
6.3. General Record Format (Allgemeines Eintragsformat)
DMARC-Einträge folgen der erweiterbaren „Tag-Wert"-Syntax für DNS-basierte Schlüsseleinträge, die in DKIM [DKIM] definiert ist.
Abschnitt 11 erstellt ein Register für bekannte DMARC-Tags und registriert den in diesem Dokument definierten Anfangssatz. Nur Tags, die in diesem Dokument oder in späteren Erweiterungen definiert und somit zu diesem Register hinzugefügt wurden, sind zu verarbeiten; unbekannte Tags müssen (MUST) ignoriert werden.
6.4. Formal Definition (Formale Definition)
(Siehe RFC 7489 für die vollständige ABNF-Syntax)
6.5. Domain Owner Actions (Aktionen des Domain-Inhabers)
Domain-Inhaber veröffentlichen DMARC-Richtlinien, um ihre Präferenzen für die Behandlung von Authentifizierungsfehlern anzugeben.
6.6. Mail Receiver Actions (Aktionen des E-Mail-Empfängers)
E-Mail-Empfänger fragen DMARC-Richtlinien ab und wenden sie gemäß der lokalen Richtlinie an.
6.7. Policy Enforcement Considerations (Überlegungen zur Richtliniendurchsetzung)
E-Mail-Empfänger sollten verschiedene Faktoren bei der Durchsetzung von DMARC-Richtlinien berücksichtigen, einschließlich legitimer Weiterleitungsszenarien und Mailinglisten-Operationen.