2. Operational Overview (Betriebsübersicht)

2.1 Publishing Authorization (Veröffentlichung der Autorisierung)

SPF-konforme Domänen veröffentlichen gültige SPF-Einträge wie in Abschnitt 3 beschrieben. Diese Einträge autorisieren die darin angegebenen MTAs, den zugehörigen Domainnamen in den Identitäten "HELO" und "MAIL FROM" zu verwenden.

SPF-Ergebnisse können verwendet werden, um sowohl positive (Quelle ist autorisiert) als auch negative (Quelle ist nicht autorisiert) Bestimmungen zu treffen. Wenn ein ADMD sich dafür entscheidet, einen SPF-Eintrag zu veröffentlichen und Empfänger bei negativen Autorisierungsentscheidungen unterstützen möchte, muss es einen Eintrag veröffentlichen, der mit "-all" endet oder auf einen anderen Eintrag umleitet, der dies tut; andernfalls kann keine eindeutige Bestimmung über die Autorisierung getroffen werden. Abschnitt 10 diskutiert potenzielle Probleme und Abhilfemaßnahmen im Zusammenhang mit negativen Entscheidungen.

ADMDs, die erklären möchten, dass keine Hosts autorisiert sind, ihren DNS-Domainnamen während SMTP-Sitzungen in HELO- oder MAIL FROM-Befehlen zu verwenden, können einen solchen SPF-Eintrag für Domainnamen veröffentlichen, die weder im Domänenteil von E-Mail-Adressen verwendet werden noch voraussichtlich E-Mails senden werden.

Bei Änderungen an SPF-Einträgen muss darauf geachtet werden, dass es eine Übergangszeit gibt, während der die alte Richtlinie gültig bleibt, bis alle legitimen E-Mails vernünftigerweise überprüft worden sein können. [RFC5321] Abschnitt 4.5.4.1 diskutiert, wie lange Nachrichten sich im Transit befinden können. Während Offline-Prüfungen möglich sind, ist es wahrscheinlicher, dass ein SPF-Ergebnis erzielt wird, das mit der Absicht des sendenden ADMD zum Zeitpunkt des Sendens der Nachricht übereinstimmt, je näher die Prüfung am ursprünglichen Übertragungszeitpunkt erfolgt.

2.2 Checking Authorization (Prüfung der Autorisierung)

E-Mail-Empfänger können eine Reihe von SPF-Prüfungen für jede empfangene E-Mail durchführen. Eine SPF-Prüfung testet die Autorisierung des Client-Hosts, E-Mails mit einer bestimmten Identität zu senden. Typischerweise werden solche Prüfungen vom empfangenden MTA durchgeführt, können aber auch an anderen Stellen in der E-Mail-Verarbeitungskette durchgeführt werden, solange die erforderlichen Informationen verfügbar und zuverlässig sind. Die Identitäten "MAIL FROM" und "HELO" werden gemäß Abschnitt 2.4 bzw. 2.3 überprüft.

Es wird nicht empfohlen, andere Identitäten gegen SPF-Version-1-Einträge zu prüfen, ohne explizite Genehmigung des veröffentlichenden ADMD, da bekannt ist, dass einige Situationen falsche Ergebnisse liefern. Beispielsweise schreiben fast alle Mailinglisten die Identität "MAIL FROM" um (siehe Abschnitt 10.3), aber einige ändern keine anderen Identitäten in der Nachricht. Dokumente, die andere Identitäten definieren, müssen Methoden zur expliziten Genehmigung definieren.

E-Mail-Empfänger können SPF-Prüfungen als Teil eines größeren Test-Sets für eingehende E-Mails einbeziehen. Die Ergebnisse anderer Tests können beeinflussen, ob eine bestimmte SPF-Prüfung durchgeführt wird. Beispielsweise kann das Finden der IP-Adresse des sendenden Hosts auf einer lokalen Whitelist dazu führen, dass alle anderen Tests übersprungen werden und alle E-Mails von diesem Host akzeptiert werden.

Wenn ein E-Mail-Empfänger sich entscheidet, eine SPF-Prüfung durchzuführen, muss er die korrekt implementierte check_host()-Funktion (Abschnitt 4) verwenden und mit den richtigen Parametern auswerten. Während der gesamte Test optional ist, muss er, sobald die Entscheidung getroffen wurde, ihn durchzuführen, wie vorgeschrieben durchgeführt werden, um die korrekten Semantiken zwischen Veröffentlichern und Empfängern zu bewahren.

Um den Test durchzuführen, muss der E-Mail-Empfänger die check_host()-Funktion mit den in Abschnitt 4.1 beschriebenen Parametern bewerten.

Obwohl ungültige, fehlerhafte oder nicht existierende Domänen dazu führen, dass SPF-Prüfungen "none" zurückgeben (da kein SPF-Eintrag gefunden wird), ist es seit langem die Richtlinie vieler MTAs, E-Mails von solchen Domänen abzulehnen, insbesondere im Fall von ungültigen "MAIL FROM". Das Ablehnen der E-Mail verhindert eine Möglichkeit, SPF-Einträge zu umgehen.

Implementierungen müssen darauf achten, das <domain> korrekt aus den mit dem SMTP MAIL FROM-Befehl angegebenen Daten zu extrahieren, da viele MTAs noch Dinge wie Source Routing (siehe Anhang C von [RFC5321]), %-Hack (siehe [RFC1123]) und Bang-Pfade (siehe [RFC1983]) akzeptieren. Diese veralteten Features wurden böswillig verwendet, um Sicherheitssysteme zu umgehen.

2.3 The "HELO" Identity (Die "HELO"-Identität)

Es wird empfohlen, dass SPF-Verifizierer nicht nur die Identität "MAIL FROM" prüfen, sondern auch die Identität "HELO" separat prüfen, indem sie die check_host()-Funktion (Abschnitt 4) auf die Identität "HELO" als <domain> anwenden. Die Prüfung von "HELO" kann zu konsistenten Ergebnissen beitragen und die Nutzung von DNS-Ressourcen reduzieren. Wenn eine definitive Bestimmung über eine Nachricht auf der Grundlage der Prüfung von "HELO" getroffen werden kann, können DNS-Ressourcen zur Verarbeitung der normalerweise komplexeren "MAIL FROM" vermieden werden. Außerdem, da SPF-Einträge, die für die Identität "HELO" veröffentlicht werden, sich auf einen einzelnen Host beziehen, sind sie, wenn verfügbar, eine sehr zuverlässige Quelle für den Host-Autorisierungsstatus. Wenn beide geprüft werden sollen, wird empfohlen, zuerst "HELO" und dann "MAIL FROM" zu prüfen.

Beachten Sie, dass die Anforderungen an die Domäne, die im EHLO- oder HELO-Befehl für Absender präsentiert wird, nicht immer klar sind, und SPF-Verifizierer müssen darauf vorbereitet sein, dass die Identität ein IP-Adressliteral ist (siehe [RFC5321] Abschnitt 4.1.3) oder einfach nur fehlerhaft. Diese SPF-Prüfung kann nur durchgeführt werden, wenn die "HELO"-Zeichenfolge ein gültiger Multi-Label-Domainname ist.

2.4 The "MAIL FROM" Identity (Die "MAIL FROM"-Identität)

Wenn die "HELO"-Prüfung nicht durchgeführt wurde oder kein definitives Richtlinienergebnis erreicht wurde, muss der SPF-Verifizierer die Identität "MAIL FROM" prüfen, indem er die check_host()-Funktion auf die Identität "MAIL FROM" als <domain> anwendet.

[RFC5321] erlaubt, dass der Reverse-Path leer ist (siehe Abschnitt 4.5.5 in [RFC5321]). In diesem Fall gibt es keine explizite Absender-Mailbox, und solche Nachrichten können als Benachrichtigungsnachrichten vom E-Mail-System selbst angenommen werden. Wenn der Reverse-Path leer ist, definiert dieses Dokument die Identität "MAIL FROM" als die Mailbox, die aus dem lokalen Teil "postmaster" und der Identität "HELO" besteht (die möglicherweise zuvor separat geprüft wurde oder auch nicht).

2.5 Location of Checks (Ort der Prüfungen)

Autorisierungsprüfungen sollten während der Verarbeitung der SMTP-Transaktion durchgeführt werden, die die E-Mail empfängt. Dies reduziert die Komplexität bei der Bestimmung der korrekten IP-Adresse, die als Eingabe für check_host() verwendet wird, und ermöglicht es, Fehler durch SMTP-Antworten direkt an den sendenden MTA zurückzugeben. Anhang D von [RFC7001] bietet eine umfassendere Diskussion zu diesem Thema.

Autorisierungsprüfungen werden während der SMTP-Transaktion zum Zeitpunkt des MAIL-Befehls durchgeführt und verwenden den MAIL FROM-Wert und die Client-IP-Adresse. Die Durchführung von Prüfungen zu einem späteren Zeitpunkt oder mit anderen Eingaben kann zu folgenden Problemen führen:

Es kann schwierig sein, die erforderlichen Informationen aus potenziell gefälschten Headern genau zu extrahieren.
Legitime E-Mails können die Autorisierungsprüfung nicht bestehen, weil sich die Richtlinie des Absenders geändert hat.

Das Generieren von Unzustellbarkeitsmeldungen an gefälschte Identitäten, die die Autorisierungsprüfung nicht bestanden haben, stellt normalerweise Backscatter dar, d.h. unbrauchbare belästigende Ablehnungsbenachrichtigungen. Betreiber werden dringend aufgefordert, solche Praktiken zu vermeiden. Abschnitt 2 von [RFC3834] beschreibt Backscatter und die damit verbundenen Probleme.

2.6 Results of Evaluation (Bewertungsergebnisse)

Abschnitt 4 definiert check_host(), eine Modellfunktionsdefinition, die die oben definierten Eingaben und die im DNS veröffentlichte Absenderrichtlinie verwendet, um zu Schlussfolgerungen über die Client-Autorisierung zu gelangen. SPF-Verifizierer implementieren etwas, das semantisch äquivalent zur hier definierten Funktion ist.

Dieser Abschnitt listet auf und definiert kurz die möglichen Ausgaben dieser Funktion. Beachten Sie jedoch, dass das Protokoll keine normativen Anforderungen für die Behandlung bestimmter Ergebnisse festlegt. Behandlungsoptionen für jedes Ergebnis werden in Abschnitt 8 diskutiert.

2.6.1 None

Ein Ergebnis von "none" bedeutet, dass (a) aus der SMTP-Sitzung kein syntaktisch gültiger DNS-Domainname extrahiert werden konnte, der als <domain> zur Autorisierung verwendet werden könnte, oder (b) kein SPF-Eintrag aus dem DNS abgerufen wurde.

2.6.2 Neutral (Neutral)

Ein "neutral"-Ergebnis bedeutet, dass das ADMD ausdrücklich erklärt hat, dass es keine Aussage darüber macht, ob die IP-Adresse autorisiert ist oder nicht.

2.6.3 Pass (Bestanden)

Ein "pass"-Ergebnis ist eine explizite Aussage, dass der Client autorisiert ist, E-Mails mit der angegebenen Identität einzuschleusen.

2.6.4 Fail (Fehlgeschlagen)

Ein "fail"-Ergebnis ist eine explizite Aussage, dass der Client nicht autorisiert ist, die Domäne in der angegebenen Identität zu verwenden.

2.6.5 Softfail (Soft-Fail)

Ein "softfail"-Ergebnis ist eine schwache Aussage des veröffentlichenden ADMD, dass der Host möglicherweise nicht autorisiert ist. Es hat keine stärkere, explizitere Richtlinie veröffentlicht, die zu einem "fail" führen würde.

2.6.6 Temperror (Temporärer Fehler)

Ein "temperror"-Ergebnis bedeutet, dass der SPF-Verifizierer bei der Durchführung der Prüfung auf einen vorübergehenden (normalerweise DNS-) Fehler gestoßen ist. Ein erneuter Versuch zu einem späteren Zeitpunkt kann erfolgreich sein, ohne dass weitere Maßnahmen des DNS-Betreibers erforderlich sind.

2.6.7 Permerror (Permanenter Fehler)

Ein "permerror"-Ergebnis bedeutet, dass der veröffentlichte Eintrag der Domäne nicht korrekt interpretiert werden konnte. Dies zeigt eine Fehlerbedingung an, die definitiv ein Eingreifen des DNS-Betreibers zur Behebung erfordert.