3. Terminology and Definitions (Terminologie und Definitionen)

Dieser Abschnitt definiert Begriffe, die im Rest des Dokuments verwendet werden.

Die Schlüsselwörter „muss (MUST)", „darf nicht (MUST NOT)", „erforderlich (REQUIRED)", „muss (SHALL)", „darf nicht (SHALL NOT)", „sollte (SHOULD)", „sollte nicht (SHOULD NOT)", „empfohlen (RECOMMENDED)", „kann (MAY)" und „optional (OPTIONAL)" in diesem Dokument sind wie in [KEYWORDS] beschrieben zu interpretieren.

Die Leser werden ermutigt, sich mit dem Inhalt von [EMAIL-ARCH] vertraut zu machen. Insbesondere definiert dieses Dokument verschiedene Rollen in der Messaging-Infrastruktur, die in verschiedenen Kontexten gleich oder getrennt erscheinen können. Beispielsweise könnte ein Domain-Inhaber über die Messaging-Sicherheitsmechanismen, auf denen DMARC basiert, die Fähigkeit delegieren, E-Mails als Domain-Inhaber an einen Dritten mit einer anderen Rolle zu senden. Dieses Dokument befasst sich nicht mit den Unterschieden zwischen solchen Rollen; dem Leser wird empfohlen, sich mit diesem Material vertraut zu machen, bevor er fortfährt.

Die folgenden Begriffe werden ebenfalls verwendet:

Authenticated Identifiers (Authentifizierte Identifikatoren): Identifikatoren auf Domain-Ebene, die mithilfe von Authentifizierungstechnologien validiert werden, werden als „authentifizierte Identifikatoren" bezeichnet. Siehe Abschnitt 4.1 für Details zu den unterstützten Mechanismen.

Author Domain (Autor-Domain): Der Domänenname des scheinbaren Autors, wie aus dem RFC5322.From-Feld extrahiert.

Domain Owner (Domain-Inhaber): Eine Entität oder Organisation, die eine DNS-Domain besitzt. Der Begriff „besitzt" bedeutet hier, dass die referenzierte Entität oder Organisation die Registrierung dieser DNS-Domain hält. Domain-Inhaber reichen von komplexen, global verteilten Organisationen über Dienstleister, die im Namen nicht-technischer Kunden arbeiten, bis hin zu Einzelpersonen, die für die Wartung persönlicher Domains verantwortlich sind. Diese Spezifikation verwendet diesen Begriff analog zu einer administrativen Verwaltungsdomäne, wie in [EMAIL-ARCH] definiert. Es kann sich auch auf Delegierte wie Berichtsempfänger beziehen, wenn diese außerhalb ihrer unmittelbaren Verwaltungsdomäne liegen.

Identifier Alignment (Identifikator-Ausrichtung): Wenn die Domain in der RFC5322.From-Adresse mit einer durch SPF oder DKIM (oder beide) validierten Domain übereinstimmt, hat sie Identifikator-Ausrichtung.

Mail Receiver (E-Mail-Empfänger): Die Entität oder Organisation, die E-Mails empfängt und verarbeitet. E-Mail-Empfänger betreiben einen oder mehrere internetfähige Mail Transfer Agents (MTAs).

Organizational Domain (Organisationsdomain): Die Domain, die bei einem Domänennamen-Registrar registriert wurde. In Ermangelung genauerer Methoden werden Heuristiken verwendet, um dies zu bestimmen, da es nicht immer der Fall ist, dass der registrierte Domänenname einfach eine Top-Level-DNS-Domain plus eine Komponente ist (z. B. „example.com", wobei „com" eine Top-Level-Domain ist). Die Organisationsdomain wird durch Anwendung des in Abschnitt 3.2 gefundenen Algorithmus bestimmt.

Report Receiver (Berichtsempfänger): Ein Betreiber, der Berichte von einem anderen Betreiber erhält, der den in diesem Dokument beschriebenen Berichtsmechanismus implementiert. Ein solcher Betreiber könnte Berichte über seine eigenen Nachrichten oder Berichte über Nachrichten im Zusammenhang mit einem anderen Betreiber erhalten. Dieser Begriff gilt kollektiv für die Systemkomponenten, die diese Berichte empfangen und verarbeiten, und die Organisationen, die sie betreiben.

3.1. Identifier Alignment (Identifikator-Ausrichtung)

E-Mail-Authentifizierungstechnologien authentifizieren verschiedene (und unterschiedliche) Aspekte einer einzelnen Nachricht. Beispielsweise authentifiziert [DKIM] die Domain, die eine Signatur an die Nachricht angefügt hat, während [SPF] entweder die Domain authentifizieren kann, die im RFC5321.MailFrom (MAIL FROM) Teil von [SMTP] erscheint, oder die RFC5321.EHLO/HELO-Domain oder beides. Dies können unterschiedliche Domains sein, und sie sind typischerweise für den Endbenutzer nicht sichtbar.

DMARC authentifiziert die Verwendung der RFC5322.From-Domain, indem es erfordert, dass sie mit einem authentifizierten Identifikator übereinstimmt (ausgerichtet ist). Die RFC5322.From-Domain wurde als zentrale Identität des DMARC-Mechanismus ausgewählt, weil es sich um ein erforderliches Nachrichtenkopffeld handelt und daher garantiert in konformen Nachrichten vorhanden ist, und die meisten Mail User Agents (MUAs) das RFC5322.From-Feld als Absender der Nachricht darstellen und einen Teil oder den gesamten Inhalt dieses Kopffelds den Endbenutzern anzeigen.

Daher ist dieses Feld dasjenige, das von Endbenutzern verwendet wird, um die Quelle der Nachricht zu identifizieren, und daher ein Hauptziel für Missbrauch. Viele hochkarätige E-Mail-Quellen, wie E-Mail-Dienstanbieter, erfordern, dass der sendende Agent authentifiziert wurde, bevor E-Mails generiert werden können. Daher bietet der in diesem Dokument beschriebene Mechanismus für diese Postfächer den Endempfängern starke Beweise dafür, dass die Nachricht tatsächlich von dem Agenten stammt, den sie mit diesem Postfach verbinden, wenn der Endbenutzer weiß, dass diese verschiedenen Schutzmaßnahmen bereitgestellt wurden.

Domänennamen sind in diesem Kontext in einer Groß-/Kleinschreibung unabhängigen Weise zu vergleichen, gemäß [DNS-CASE].

Es ist wichtig zu beachten, dass Identifikator-Ausrichtung nicht bei einer Nachricht auftreten kann, die gemäß [MAIL] nicht gültig ist, insbesondere eine mit einem fehlerhaften, fehlenden oder wiederholten RFC5322.From-Feld, da in diesem Fall keine zuverlässige Möglichkeit besteht, eine DMARC-Richtlinie zu bestimmen, die auf die Nachricht anwendbar ist. Dementsprechend setzt die DMARC-Operation voraus, dass die Eingabe ein gültiges RFC5322-Nachrichtenobjekt ist, und die Behandlung solcher nicht konformer Fälle liegt außerhalb des Geltungsbereichs dieser Spezifikation. Eine weitere Diskussion darüber findet sich in Abschnitt 6.6.1.

Jede der zugrunde liegenden Authentifizierungstechnologien, die DMARC als Eingabe nimmt, liefert authentifizierte Domains als ihre Ausgaben, wenn sie erfolgreich sind. Aus Sicht von DMARC kann jede im „strict"-Modus oder im „relaxed"-Modus betrieben werden. Ein Domain-Inhaber würde normalerweise den strict-Modus wählen, wenn er möchte, dass Mail-Empfänger die DMARC-Verarbeitung nur auf Nachrichten anwenden, die eine RFC5322.From-Domain tragen, die genau mit den Domains übereinstimmt, die diese Mechanismen überprüfen werden. Der relaxed-Modus kann verwendet werden, wenn der Betreiber auch Nachrichtenflüsse beeinflussen möchte, die Subdomains der verifizierten Domains tragen.

3.1.1. DKIM-Authenticated Identifiers (DKIM-authentifizierte Identifikatoren)

DMARC erlaubt, dass die Identifikator-Ausrichtung, basierend auf dem Ergebnis einer DKIM-Authentifizierung, streng oder locker ist. (Beachten Sie, dass diese nicht mit den „simple"- und „relaxed"-Kanonisierungsmodi von DKIM zusammenhängen.)

Im relaxed-Modus müssen die Organisationsdomains sowohl der [DKIM]-authentifizierten Signatur-Domain (entnommen aus dem Wert des „d="-Tags in der Signatur) als auch der RFC5322.From-Domain gleich sein, wenn die Identifikatoren als ausgerichtet betrachtet werden sollen. Im strict-Modus wird nur eine exakte Übereinstimmung zwischen beiden vollständig qualifizierten Domänennamen (FQDNs) als Identifikator-Ausrichtung angesehen.

Zur Veranschaulichung: Im relaxed-Modus, wenn eine validierte DKIM-Signatur erfolgreich mit einer „d="-Domain von „example.com" verifiziert wird und die RFC5322.From-Adresse „[email protected]" lautet, werden die DKIM-„d="-Domain und die RFC5322.From-Domain als „ausgerichtet" betrachtet. Im strict-Modus würde dieser Test fehlschlagen, da die „d="-Domain nicht genau mit dem FQDN der Adresse übereinstimmt.

Eine DKIM-Signatur mit einem Wert von „d=com" würde jedoch niemals ein „ausgerichtet"-Ergebnis ermöglichen, da „com" auf allen öffentlichen Suffix-Listen erscheinen sollte (siehe Anhang A.6.1) und daher keine Organisationsdomain sein kann.

Identifikator-Ausrichtung ist erforderlich, da eine Nachricht eine gültige Signatur von jeder Domain tragen kann, einschließlich Domains, die von einer Mailingliste oder sogar von einem böswilligen Akteur verwendet werden. Daher reicht das bloße Tragen einer gültigen Signatur nicht aus, um die Authentizität der Autor-Domain zu folgern.

Beachten Sie, dass eine einzelne E-Mail mehrere DKIM-Signaturen enthalten kann, und sie wird als DMARC-„pass" betrachtet, wenn eine DKIM-Signatur ausgerichtet ist und verifiziert wird.

3.1.2. SPF-Authenticated Identifiers (SPF-authentifizierte Identifikatoren)

DMARC erlaubt, dass die Identifikator-Ausrichtung, basierend auf dem Ergebnis einer SPF-Authentifizierung, streng oder locker ist.

Im relaxed-Modus müssen die [SPF]-authentifizierte Domain und die RFC5322.From-Domain dieselbe Organisationsdomain haben. Im strict-Modus wird nur eine exakte DNS-Domain-Übereinstimmung als Identifikator-Ausrichtung betrachtet.

Beachten Sie, dass die RFC5321.HELO-Identität im Kontext von DMARC typischerweise nicht verwendet wird (außer wenn erforderlich, um einen ansonsten null Rückwärtspfad zu „fälschen"), obwohl eine „reine SPF"-Implementierung gemäß [SPF] diesen Identifikator überprüfen würde.

Wenn beispielsweise eine Nachricht eine SPF-Prüfung mit einer RFC5321.MailFrom-Domain von „cbg.bounces.example.com" besteht und der Adressteil des RFC5322.From-Felds „[email protected]" enthält, werden die authentifizierte RFC5321.MailFrom-Domain-Identifikator und die RFC5322.From-Domain im relaxed-Modus als „ausgerichtet" betrachtet, aber nicht im strict-Modus.

3.1.3. Alignment and Extension Technologies (Ausrichtung und Erweiterungstechnologien)

Wenn DMARC in Zukunft erweitert wird, um die Verwendung anderer Authentifizierungsmechanismen einzuschließen, müssen die Erweiterungen die Extraktion von Domain-Identifikatoren ermöglichen, damit die Ausrichtung mit der RFC5322.From-Domain überprüft werden kann.

3.2. Organizational Domain (Organisationsdomain)

Die Organisationsdomain wird mit dem folgenden Algorithmus bestimmt:

1. Erwerben Sie eine „öffentliche Suffix"-Liste, d. h. eine Liste von DNS-Domänennamen, die für Registrierungen reserviert sind. Einige Länder-Top-Level-Domains (TLDs) haben spezifische Registrierungsanforderungen, z. B. platziert das Vereinigte Königreich Unternehmensregistrierungen unter „.co.uk"; andere TLDs wie „.com" erscheinen im IANA-Register der Top-Level-DNS-Domains. Eine öffentliche Suffix-Liste ist die Vereinigung all dieser. Anhang A.6.1 enthält einige Diskussionen über das Erhalten einer öffentlichen Suffix-Liste.

2. Teilen Sie den Subjekt-DNS-Domänennamen in einen Satz von „n" geordneten Labels auf. Nummerieren Sie diese Labels von rechts nach links; z. B. wäre für „example.com" „com" Label 1 und „example" wäre Label 2.

3. Durchsuchen Sie die öffentliche Suffix-Liste nach dem Namen, der mit der größten Anzahl von Labels übereinstimmt, die im Subjekt-DNS-Domain gefunden wurden. Sei diese Zahl „x".

4. Konstruieren Sie einen neuen DNS-Domänennamen unter Verwendung des Namens, der aus der öffentlichen Suffix-Liste übereinstimmte, und setzen Sie das „x+1"-te Label aus der Subjekt-Domain davor. Dieser neue Name ist die Organisationsdomain.

Da „com" eine bei der IANA registrierte TLD ist, hätte eine Subjekt-Domain von „a.b.c.d.example.com" eine Organisationsdomain von „example.com".

Der Prozess der Bestimmung eines Suffix ist derzeit ein heuristischer. Keine Liste ist garantiert genau oder aktuell.