1. Introduction (Einführung)

Die aktuelle E-Mail-Infrastruktur hat die Eigenschaft, dass jeder Host, der E-Mails in das System einschleust, jeden beliebigen DNS-Domainnamen in den verschiedenen Identifikatoren verwenden kann, die in [RFC5321] und [RFC5322] spezifiziert sind. Während diese Eigenschaft in einigen Fällen vorteilhaft ist, stellt sie ein Haupthindernis bei der Reduzierung unerwünschter Massen-E-Mails (UBE, Unsolicited Bulk Email, auch als Spam bekannt) dar. Darüber hinaus sind ADMDs (wie in [RFC5598] beschrieben) verständlicherweise besorgt darüber, dass andere Entitäten ihre Domainnamen leicht verwenden können, oft mit böswilliger Absicht.

Dieses Dokument definiert ein Protokoll, durch das ein ADMD Hosts autorisieren kann, seinen Domainnamen in den Identitäten "MAIL FROM" oder "HELO" zu verwenden. Konforme ADMDs veröffentlichen Sender Policy Framework (SPF)-Einträge im DNS, die angeben, welche Hosts berechtigt sind, ihre Namen zu verwenden, und konforme E-Mail-Empfänger verwenden die veröffentlichten SPF-Einträge, um die Autorisierung eines sendenden Mail Transfer Agents (MTA) zu testen, der während einer E-Mail-Transaktion eine bestimmte "HELO"- oder "MAIL FROM"-Identität verwendet.

Ein weiterer Vorteil für E-Mail-Empfänger besteht darin, dass nach der Validierung der Verwendung einer Identität lokale Richtlinienentscheidungen über E-Mails auf Basis der Domäne des Absenders und nicht auf Basis der IP-Adresse des Hosts getroffen werden können. Dies ist vorteilhaft, da die Reputation eines Domainnamens möglicherweise genauer ist als die Reputation einer Host-IP-Adresse, weil der Domainname über einen längeren Zeitraum stabiler sein könnte. Wenn die behauptete Identität nicht validiert werden kann, können lokale Richtlinien außerdem strengere Maßnahmen gegen solche E-Mails ergreifen, wie z.B. deren Ablehnung.

1.1 Terminology (Terminologie)

1.1.1 Key Words (Schlüsselwörter)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

1.1.2 Imported Definitions (Importierte Definitionen)

ABNF (Augmented Backus-Naur Form) ist in [RFC5234] definiert, die Tokens "ALPHA", "DIGIT" und "SP" (Leerzeichen) sind ebenfalls dort definiert.

Die Tokens "Local-part", "Domain" und "Mailbox" sind in [RFC5321] definiert.

"dot-atom", "quoted-string", "comment", "CFWS" (Comment Folded White Space), "FWS" (Folded White Space) und "CRLF" (Carriage-Return/Line-Feed) sind in [RFC5322] definiert.

1.1.3 MAIL FROM Definition (MAIL FROM Definition)

Dieses Dokument befasst sich mit der Identität des E-Mail-Absenders, wie in [RFC5321] beschrieben:

Die Transaktion beginnt mit dem MAIL-Befehl, der die Absenderidentität angibt.

Da diese Identität viele andere Namen hat, ist es wichtig, einen Namen zu wählen, der:

Allgemein gebräuchlich ist
Klar definiert ist

Daher wird in diesem Dokument der Begriff "MAIL FROM" verwendet, der als die in [RFC5598] beschriebene RFC5321.MailFrom (Reverse-Path)-Identität definiert ist.

1.1.4 HELO Definition (HELO Definition)

Dieses Dokument verwendet auch die HELO/EHLO-Identität. Die "HELO"-Identität stammt vom SMTP HELO- oder EHLO-Befehl (siehe [RFC5321]). Da HELO und EHLO in vielen Fällen austauschbar verwendet werden können, werden sie in diesem Dokument üblicherweise als "HELO" bezeichnet. Dies bedeutet RFC5321.HELO/.EHLO wie in [RFC5598] definiert. Diese Befehle liefern die Identität des SMTP-Clients (sendender Host) für die SMTP-Sitzung.

1.2 check_host()

Abschnitt 4 stellt einen Algorithmus vor, der zur Bewertung der SPF-Richtlinie gegenüber einer eingehenden E-Mail-Transaktion verwendet wird. In frühen Implementierungen wurde dieser Algorithmus in einer Funktion namens check_host() kodiert. Dieser Name wird in diesem Dokument als Symbol für den SPF-Bewertungsalgorithmus verwendet, aber Implementierer müssen diesen Namen natürlich nicht verwenden.