Zum Hauptinhalt springen

2. Terminology and Definitions (Terminologie und Definitionen)

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

DKIM ist so konzipiert, dass es innerhalb des Internet-Mail-Dienstes funktioniert, wie in [RFC5598] definiert. Die grundlegende E-Mail-Terminologie stammt aus dieser Spezifikation.

Syntaxbeschreibungen verwenden erweiterte BNF (ABNF) [RFC5234].

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. Diese Wörter haben nur dann ihre normative Bedeutung, wenn sie in GROSSBUCHSTABEN dargestellt werden.

2.1. Signers (Unterzeichner)​

Elemente im Mail-System, die Nachrichten im Namen einer Domain signieren, werden als Unterzeichner bezeichnet. Dies können MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents) oder andere Agenten wie Mailinglisten-Exploders sein. Im Allgemeinen wird jeder Unterzeichner auf irgendeine Weise an der Einspeisung einer Nachricht in das Nachrichtensystem beteiligt sein. Das Hauptproblem ist, dass eine Nachricht signiert werden muss, bevor sie die administrative Domain des Unterzeichners verlässt.

2.2. Verifiers (Verifizierer)​

Elemente im Mail-System, die Signaturen überprüfen, werden als Verifizierer bezeichnet. Dies können MTAs, Mail Delivery Agents (MDAs) oder MUAs sein. In den meisten Fällen wird erwartet, dass Verifizierer nahe an einem Endbenutzer (Leser) der Nachricht oder einem verbrauchenden Agenten wie einem Mailinglisten-Exploder sind.

2.3. Identity (Identität)​

Eine Person, Rolle oder Organisation. Im Kontext von DKIM umfassen Beispiele den Autor, die Organisation des Autors, einen ISP entlang des Verarbeitungspfads, einen unabhängigen Vertrauensbewertungsdienst und einen Mailinglisten-Betreiber.

2.4. Identifier (Identifikator)​

Ein Label, das sich auf eine Identität bezieht.

2.5. Signing Domain Identifier (SDID) (Signierungsdomänen-Identifikator)​

Ein einzelner Domainname, der die obligatorische Payload-Ausgabe von DKIM ist und der sich auf die Identität bezieht, die eine gewisse Verantwortung für die Nachricht beansprucht, indem sie sie signiert. Er wird in Abschnitt 3.5 spezifiziert.

2.6. Agent or User Identifier (AUID) (Agenten- oder Benutzeridentifikator)​

Ein einzelner Identifikator, der sich auf den Agenten oder Benutzer bezieht, für den der Signierungsdomänen-Identifikator (SDID) die Verantwortung übernommen hat. Der AUID besteht aus einem Domainnamen und einem optionalen lokalen Teil. Der Domainname ist derselbe wie der für den SDID verwendete oder ist eine Subdomain davon. Für die DKIM-Verarbeitung hat der Domainnamensteil des AUID nur grundlegende Domainnamen-Semantik; mögliche eigentümerspezifische Semantiken liegen außerhalb des Geltungsbereichs von DKIM. Er wird in Abschnitt 3.5 spezifiziert.

Beachten Sie, dass akzeptable Werte für den AUID über ein Flag im öffentlichen Schlüsselsatz eingeschränkt werden können (siehe Abschnitt 3.6.1).

2.7. Identity Assessor (Identitätsbeurteiler)​

Ein Element im Mail-System, das die Payload von DKIM konsumiert, welche der verantwortliche Signierungsdomänen-Identifikator (SDID) ist. Der Identitätsbeurteiler ist der Bewertung des gelieferten Identifikators gewidmet. Andere DKIM- (und Nicht-DKIM-) Werte können auch vom Identitätsbeurteiler verwendet werden (wenn sie verfügbar sind), um eine allgemeinere Nachrichtenbewertungs-Filtermaschine bereitzustellen. Diese zusätzliche Aktivität liegt jedoch außerhalb des Geltungsbereichs dieser Spezifikation.

2.8. Whitespace (Leerzeichen)​

Es gibt drei Formen von Leerzeichen:

  • WSP repräsentiert einfache Leerzeichen, d.h. ein Leerzeichen (ASCII 0x20) oder ein Tabulatorzeichen (ASCII 0x09).

  • LWSP repräsentiert lineare Leerzeichen, das ist WSP plus CRLF (Carriage Return/Line Feed)-Sequenzen, die Teil der Kopffeld-Faltung sind.

  • FWS repräsentiert "faltendes Leerzeichen", eine komplexere Form von Leerzeichen, die speziell in [RFC5322] definiert ist.

In jedem Fall wird die tatsächliche Definition von [RFC5234] oder [RFC5322] bereitgestellt.

2.9. Imported ABNF Tokens (Importierte ABNF-Token)​

Einige in dieser Spezifikation verwendete Token werden aus [RFC5322] und [RFC5234] importiert. Die Leser sollten mit der ABNF-Syntax [RFC5234] vertraut sein, wie sie in diesen Dokumenten definiert ist.

2.10. Common ABNF Tokens (Gemeinsame ABNF-Token)​

Die folgenden ABNF-Token werden in dieser gesamten Spezifikation verwendet:

hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = ALPHA *([FWS] (ALPHA / DIGIT / "+" / "/"))
               [FWS] ["=" [FWS] ["="]]
qp-section = [FWS] qp-hdr-value

2.11. DKIM-Quoted-Printable (DKIM-Quoted-Printable)​

Die DKIM-Quoted-Printable-Codierungssyntax wird für Werte verwendet, die in einer Form dargestellt werden müssen, die robust gegen Änderungen durch MTAs während des Transits ist. Diese Codierung basiert auf der in [RFC2045] definierten Quoted-Printable-Codierung, jedoch mit mehreren Einschränkungen und Klarstellungen, um Mehrdeutigkeit zu vermeiden.

Das DKIM-Quoted-Printable-Alphabet besteht aus druckbaren US-ASCII-Zeichen (der Bereich 0x21 bis 0x7E, einschließlich), mit Ausnahme des Semikolons (0x3B), das als Tag-Trennzeichen verwendet wird, und des Gleichheitszeichens (0x3D), das als Codierungs-Escape-Zeichen verwendet wird. Die DKIM-Quoted-Printable-Codierung stellt nicht druckbare Zeichen (solche außerhalb des Bereichs 0x21 bis 0x7E, außer wie angegeben) durch ein Gleichheitszeichen gefolgt von zwei hexadezimalen Ziffern (Groß- oder Kleinbuchstaben) dar, die den Wert des Oktetts darstellen.

Zum Beispiel:

  • Ein Leerzeichen (ASCII 0x20) wird als "=20" codiert.
  • Ein Semikolon (ASCII 0x3B) wird als "=3B" codiert.
  • Ein Gleichheitszeichen (ASCII 0x3D) wird als "=3D" codiert.

Die DKIM-Quoted-Printable-Codierung DARF KEINE Zeilenumbrüche oder Leerzeichen innerhalb der codierten Zeichenfolge enthalten.

Letztes Update am