Appendix B. Changes from RFC 4408 (Änderungen gegenüber RFC 4408)
Appendix B. Changes in Implementation Requirements from RFC 4408 (Änderungen der Implementierungsanforderungen gegenüber RFC 4408)
Dieser Anhang fasst die wichtigsten Änderungen von RFC 7208 gegenüber seinem Vorgänger RFC 4408 zusammen.
B.1 Hauptänderungen
B.1.1 SPF RR-Typ veraltet
RFC 4408-Anforderung:
- Gleichzeitige Veröffentlichung von TXT- und SPF-Einträgen (Typ 99)
- Implementierungen müssen beide Eintragstypen prüfen
RFC 7208-Änderung:
- Nur TXT-Einträge verwenden (Typ 16)
- SPF RR-Typ wird nicht mehr unterstützt
- Vereinfachte Implementierung und Bereitstellung
Grund: Sehr geringe Adoptionsrate des SPF RR-Typs, Dual-Typ-System verursachte Interoperabilitätsprobleme.
B.1.2 Klarstellung der DNS-Abfragelimits
RFC 4408:
- DNS-Abfragelimit nicht ausreichend klar beschrieben
- "Void lookup"-Limit nicht definiert
RFC 7208:
- Eindeutige Definition des 10-DNS-Abfragelimits
- Hinzugefügtes "void lookup"-Limit (empfohlen 2)
- Detaillierte Beschreibung zusätzlicher Limits für MX- und PTR-Mechanismen
Spezifische Limits:
- Gesamt-DNS-Abfragen: ≤ 10 (include, a, mx, ptr, exists, redirect)
- Pro mx-Mechanismus: ≤ 10 Adressabfragen
- Pro ptr-Mechanismus: ≤ 10 Adressabfragen
- Void lookups: ≤ 2 (empfohlen)
- Evaluierungszeit: ≥ 20 Sekunden (empfohlen)
B.1.3 Behandlung von "local-part"
RFC 4408:
- local-part-Behandlung nicht ausreichend klar
- Behandlung leerer local-part nicht definiert
RFC 7208:
- Eindeutige Festlegung: Wenn
<sender>keinen local-part hat, verwende "postmaster" - Verbesserte Behandlung leerer Reverse-Path (
<>)
Beispiel:
MAIL FROM:<>
→ SPF verwendet HELO-Identität, local-part ist "postmaster"
B.1.4 Starke Ablehnung des "ptr"-Mechanismus
RFC 4408:
- "ptr"-Mechanismus erlaubt, aber nicht empfohlen
RFC 7208:
- Eindeutig als "do not use" (nicht verwenden) markiert
- Warnung im Mechanismusnamen hinzugefügt
- Betonung von Leistungs- und Zuverlässigkeitsproblemen
Gründe:
- Reverse-DNS-Abfragen langsam
- Abhängig von Konfiguration Dritter (IP-Adresseigentümer)
- Belastung für .arpa-Nameserver
B.1.5 Korrektur der Makrosyntax
RFC 4408:
- Mehrdeutige Makrosyntaxdefinition
RFC 7208:
- Verbesserte ABNF-Definition
- Klarstellung der Makroerweiterungsregeln
- Behobene Grenzfälle
B.1.6 Sicherheitsüberlegungen zum "exp"-Modifikator
RFC 4408:
- Sicherheitsüberlegungen nicht ausreichend detailliert
RFC 7208:
- Sicherheitswarnungen zu externen Erklärungsstrings hinzugefügt
- Empfehlung zur Begrenzung der Länge von Erklärungsstrings
- Betonung der Notwendigkeit, Erklärungen als von Dritten stammend zu kennzeichnen
B.2 Änderungen der Implementierungsanforderungen
B.2.1 MUST-Änderungen (Muss implementiert werden)
Neue Anforderungen:
- Implementierungen müssen nur TXT-Einträge abfragen (keine SPF RR mehr)
- Implementierungen müssen die Gesamtzahl der DNS-Abfragen auf 10 begrenzen
- Implementierungen müssen "void lookup"-Limit handhaben
- Implementierungen müssen bei Überschreitung der Limits "permerror" zurückgeben
Entfernte Anforderungen:
- Keine Unterstützung für SPF RR-Typ mehr erforderlich
- Keine Konvertierungslogik für Dual-Typ-Einträge mehr erforderlich
B.2.2 SHOULD-Änderungen (Sollte implementiert werden)
Neue Empfehlungen:
- Sollte Evaluierungs-Timeout implementieren (mindestens 20 Sekunden)
- Sollte "void lookup" auf 2 begrenzen
- Sollte sowohl HELO- als auch MAIL FROM-Identität prüfen
- Sollte Prüfung während SMTP-Transaktion durchführen
B.2.3 MAY-Änderungen (Kann implementiert werden)
Neue Optionen:
- Kann nicht-kanonische Algorithmen verwenden (solange Ergebnisse gleich sind)
- Kann "void lookup"-Limit konfigurieren
- Kann Länge der Erklärungsstrings begrenzen
B.3 Terminologieänderungen
B.3.1 Standardisierung von Identitätsnamen
RFC 4408:
- Verwendete mehrere Namen: "MAIL FROM", "SMTP MAIL FROM", "reverse-path"
- Inkonsistente Terminologie
RFC 7208:
- Einheitliche Verwendung von "MAIL FROM"-Identität
- Klare Definition als RFC5321.MailFrom
- Verweis auf RFC 5598-Standardterminologie
B.3.2 Übernahme der "ADMD"-Terminologie
RFC 4408:
- Verwendete "domain owner", "sending domain"
RFC 7208:
- Übernahme von "ADMD" (Administrative Management Domain)
- Präzisere Beschreibung der verantwortlichen Partei
B.4 Verbesserung der Sicherheitsüberlegungen
B.4.1 Neue Sicherheitsthemen
-
Cross-User-Fälschung (Abschnitt 11.4):
- In RFC 4408 nicht behandelt
- RFC 7208 diskutiert explizit domäneninterne Benutzerfälschungsprobleme
-
Datenschutzgefährdung (Abschnitt 11.6):
- Makros in DNS-Abfragen können sensible Informationen preisgeben
- Empfehlung zur vorsichtigen Verwendung von Makros mit Absenderinformationen
-
Nicht vertrauenswürdige Informationsquellen (Abschnitt 11.5):
- Detaillierte Diskussion der Risiken externer Header und Erklärungen
- Betonung der Wichtigkeit von Validierung und Filterung
B.4.2 Stärkung des DoS-Schutzes
RFC 4408:
- Grundlegende Abfragelimits
RFC 7208:
- Mehrschichtige Schutzmechanismen
- Klare Grenzwerte
- Timeout-Empfehlungen
- "Void lookup"-Limit
B.5 Änderungen bei IANA-Registrierungen
B.5.1 SPF RR-Typ
RFC 4408:
- Registrierung des SPF RR-Typs (Typ 99)
RFC 7208:
- SPF RR-Typ als veraltet markiert
- Empfehlung, nur TXT-Einträge zu verwenden
B.5.2 Modifikator-Registrierung
RFC 7208 neu:
- Erstellung der SPF-Modifikator-Registrierung
- Standardisierter Registrierungsprozess für neue Modifikatoren
- Anforderung, dass unbekannte Modifikatoren ignoriert werden müssen
B.6 Interoperabilitätsverbesserungen
B.6.1 Klarstellung der Eintragsauswahl
RFC 4408:
- Behandlung mehrerer Einträge unklar
RFC 7208:
- Eindeutige Festlegung: Mehrere SPF-Einträge führen zu "permerror"
- Verbesserte Regeln zum Abgleich von Versionsstrings
- Klarstellung der Eintragsverkettungsregeln (mehrere Strings)
B.6.2 Standardisierung der Fehlerbehandlung
RFC 7208-Verbesserungen:
- Alle Fehlersituationen haben eindeutige Ergebnisse
- Standardisierte Behandlung von DNS-Fehlern
- Verbesserte Timeout-Behandlung
B.7 Rückwärtskompatibilität
B.7.1 Kompatible Änderungen
Die meisten Änderungen sind rückwärtskompatibel:
- TXT-Eintragsformat unverändert
- Mechanismen- und Modifikator-Syntax im Wesentlichen gleich
- Kernalgorithmus bleibt konsistent
B.7.2 Möglicherweise kompatibilitätsbeeinflussende Änderungen
-
Entfernung des SPF RR-Typs:
- Alte Implementierungen könnten weiterhin SPF RR abfragen
- Empfehlung: SPF RR-Einträge entfernen, nur TXT behalten
-
Strengere Limits:
- "Void lookup"-Limit ist neu hinzugefügt
- Einige alte Einträge könnten neue Limits überschreiten
- Empfehlung: SPF-Einträge optimieren, um Limits einzuhalten
-
Ablehnung des "ptr"-Mechanismus:
- Muss weiterhin unterstützt werden, wird aber stark abgelehnt
- Empfehlung: Zu anderen Mechanismen migrieren
B.8 Änderungen der Dokumentenstruktur
RFC 7208-Verbesserungen:
- Klarere Kapitelorganisation
- Erweiterte Beispiele hinzugefügt (Anhang A)
- Implementierungsempfehlungen hinzugefügt (Anhang C-G)
- Verbesserte Darstellung von ABNF-Definitionen
B.9 Migrationsanleitung
Migration von RFC 4408 zu RFC 7208:
Herausgeber:
- SPF RR-Einträge entfernen, nur TXT-Einträge behalten
- DNS-Abfrageanzahl prüfen und optimieren (≤ 10)
- "ptr"-Mechanismus durch "ip4" oder "ip6" ersetzen
- "Void lookup"-Anzahl validieren (≤ 2)
- Testen, ob Einträge 512 Oktetts überschreiten
Empfänger:
- Abfragen von SPF RR-Typ stoppen
- Neue DNS-Abfragelimits implementieren
- "Void lookup"-Limit implementieren
- Fehlerbehandlungslogik aktualisieren
- Erwägung der Implementierung von Evaluierungs-Timeout
Testen:
# SPF-Validierungstool zum Testen von Einträgen verwenden
# Zum Beispiel: https://www.kitterman.com/spf/validate.html
# DNS-Abfrageanzahl prüfen
dig +short example.com TXT | grep "v=spf1"
# Eintragsgröße validieren
dig example.com TXT | grep -A1 "ANSWER SECTION"
B.10 Aktualisierung der Referenzdokumente
RFC 7208 verweist auf aktualisierte Standards:
- RFC 5321 (ersetzt RFC 2821)
- RFC 5322 (ersetzt RFC 2822)
- RFC 5234 (ABNF-Aktualisierung)
- RFC 5598 (Mail-Architektur-Terminologie)
- RFC 5890 (Internationalisierte Domainnamen)