Appendix B. Changes from RFC 4408 (Changements par rapport à RFC 4408)
Appendix B. Changes in Implementation Requirements from RFC 4408 (Changements des exigences de mise en œuvre par rapport à RFC 4408)
Cette annexe résume les principaux changements de RFC 7208 par rapport à son prédécesseur RFC 4408.
B.1 Changements majeurs
B.1.1 Type RR SPF obsolète
Exigence RFC 4408:
- Publication simultanée d'enregistrements TXT et SPF (type 99)
- Les implémentations doivent vérifier les deux types d'enregistrements
Changement RFC 7208:
- Utiliser uniquement les enregistrements TXT (type 16)
- Le type RR SPF n'est plus supporté
- Implémentation et déploiement simplifiés
Raison: Taux d'adoption très faible du type RR SPF, système à double type causant des problèmes d'interopérabilité.
B.1.2 Clarification des limites de requêtes DNS
RFC 4408:
- Limite de requêtes DNS insuffisamment claire
- Limite "void lookup" non définie
RFC 7208:
- Définition claire de la limite de 10 requêtes DNS
- Ajout de la limite "void lookup" (recommandé 2)
- Description détaillée des limites supplémentaires pour les mécanismes MX et PTR
Limites spécifiques:
- Total requêtes DNS: ≤ 10 (include, a, mx, ptr, exists, redirect)
- Par mécanisme mx: ≤ 10 requêtes d'adresse
- Par mécanisme ptr: ≤ 10 requêtes d'adresse
- Void lookups: ≤ 2 (recommandé)
- Temps d'évaluation: ≥ 20 secondes (recommandé)
B.1.3 Traitement du "local-part"
RFC 4408:
- Traitement du local-part insuffisamment clair
- Traitement du local-part vide non défini
RFC 7208:
- Spécification claire: si
<sender>n'a pas de local-part, utiliser "postmaster" - Amélioration du traitement du chemin inverse vide (
<>)
Exemple:
MAIL FROM:<>
→ SPF utilise l'identité HELO, local-part est "postmaster"
B.1.4 Opposition forte au mécanisme "ptr"
RFC 4408:
- Mécanisme "ptr" autorisé mais non recommandé
RFC 7208:
- Marqué clairement comme "do not use" (ne pas utiliser)
- Avertissement ajouté dans le nom du mécanisme
- Accent sur les problèmes de performance et de fiabilité
Raisons:
- Requêtes DNS inverses lentes
- Dépend de la configuration de tiers (propriétaire d'adresse IP)
- Charge sur les serveurs de noms .arpa
B.1.5 Correction de la syntaxe des macros
RFC 4408:
- Définition de syntaxe de macro ambiguë
RFC 7208:
- Définition ABNF améliorée
- Clarification des règles d'expansion des macros
- Correction des cas limites
B.1.6 Considérations de sécurité pour le modificateur "exp"
RFC 4408:
- Considérations de sécurité insuffisamment détaillées
RFC 7208:
- Ajout d'avertissements de sécurité sur les chaînes d'explication externes
- Recommandation de limiter la longueur des chaînes d'explication
- Accent sur la nécessité d'identifier les explications comme provenant de tiers
B.2 Changements des exigences de mise en œuvre
B.2.1 Changements MUST (Doit être implémenté)
Nouvelles exigences:
- Les implémentations doivent interroger uniquement les enregistrements TXT (plus de SPF RR)
- Les implémentations doivent limiter le nombre total de requêtes DNS à 10
- Les implémentations doivent gérer la limite "void lookup"
- Les implémentations doivent retourner "permerror" en cas de dépassement des limites
Exigences supprimées:
- Support du type RR SPF plus nécessaire
- Logique de conversion pour enregistrements à double type plus nécessaire
B.2.2 Changements SHOULD (Devrait être implémenté)
Nouvelles recommandations:
- Devrait implémenter un timeout d'évaluation (au moins 20 secondes)
- Devrait limiter "void lookup" à 2
- Devrait vérifier les identités HELO et MAIL FROM
- Devrait effectuer la vérification pendant la transaction SMTP
B.2.3 Changements MAY (Peut être implémenté)
Nouvelles options:
- Peut utiliser des algorithmes non canoniques (tant que les résultats sont identiques)
- Peut configurer la limite "void lookup"
- Peut limiter la longueur des chaînes d'explication
B.3 Changements de terminologie
B.3.1 Standardisation des noms d'identité
RFC 4408:
- Utilisait plusieurs noms: "MAIL FROM", "SMTP MAIL FROM", "reverse-path"
- Terminologie incohérente
RFC 7208:
- Utilisation uniforme de l'identité "MAIL FROM"
- Définition claire comme RFC5321.MailFrom
- Référence à la terminologie standard RFC 5598
B.3.2 Adoption de la terminologie "ADMD"
RFC 4408:
- Utilisait "domain owner", "sending domain"
RFC 7208:
- Adoption de "ADMD" (Administrative Management Domain)
- Description plus précise de la partie responsable
B.4 Amélioration des considérations de sécurité
B.4.1 Nouveaux sujets de sécurité
-
Usurpation inter-utilisateurs (Section 11.4):
- Non couvert dans RFC 4408
- RFC 7208 discute explicitement des problèmes d'usurpation d'utilisateurs intra-domaine
-
Exposition de la vie privée (Section 11.6):
- Les macros dans les requêtes DNS peuvent divulguer des informations sensibles
- Recommandation d'utiliser prudemment les macros contenant des informations sur l'expéditeur
-
Sources d'informations non fiables (Section 11.5):
- Discussion détaillée des risques des en-têtes et explications externes
- Accent sur l'importance de la validation et du filtrage
B.4.2 Renforcement de la protection DoS
RFC 4408:
- Limites de requête de base
RFC 7208:
- Mécanismes de protection multicouches
- Valeurs limites claires
- Recommandations de timeout
- Limite "void lookup"
B.5 Changements d'enregistrement IANA
B.5.1 Type RR SPF
RFC 4408:
- Enregistrement du type RR SPF (type 99)
RFC 7208:
- Type RR SPF marqué comme obsolète
- Recommandation d'utiliser uniquement les enregistrements TXT
B.5.2 Registre des modificateurs
Nouveau RFC 7208:
- Création du registre des modificateurs SPF
- Processus d'enregistrement standardisé pour les nouveaux modificateurs
- Exigence que les modificateurs inconnus doivent être ignorés
B.6 Améliorations de l'interopérabilité
B.6.1 Clarification de la sélection d'enregistrement
RFC 4408:
- Traitement de plusieurs enregistrements peu clair
RFC 7208:
- Spécification claire: plusieurs enregistrements SPF entraînent "permerror"
- Règles améliorées de correspondance des chaînes de version
- Clarification des règles de concaténation d'enregistrements (plusieurs chaînes)
B.6.2 Standardisation du traitement des erreurs
Améliorations RFC 7208:
- Toutes les situations d'erreur ont des résultats clairs
- Traitement standardisé des erreurs DNS
- Amélioration du traitement des timeouts
B.7 Rétrocompatibilité
B.7.1 Changements compatibles
La plupart des changements sont rétrocompatibles:
- Format d'enregistrement TXT inchangé
- Syntaxe des mécanismes et modificateurs essentiellement identique
- Algorithme de base reste cohérent
B.7.2 Changements pouvant affecter la compatibilité
-
Suppression du type RR SPF:
- Les anciennes implémentations peuvent encore interroger SPF RR
- Recommandation: Supprimer les enregistrements SPF RR, conserver uniquement TXT
-
Limites plus strictes:
- La limite "void lookup" est nouvellement ajoutée
- Certains anciens enregistrements peuvent dépasser les nouvelles limites
- Recommandation: Optimiser les enregistrements SPF pour respecter les limites
-
Opposition au mécanisme "ptr":
- Doit toujours être supporté mais fortement découragé
- Recommandation: Migrer vers d'autres mécanismes
B.8 Changements de structure du document
Améliorations RFC 7208:
- Organisation des chapitres plus claire
- Exemples étendus ajoutés (Annexe A)
- Recommandations de mise en œuvre ajoutées (Annexes C-G)
- Présentation améliorée des définitions ABNF
B.9 Guide de migration
Migration de RFC 4408 vers RFC 7208:
Éditeurs:
- Supprimer les enregistrements SPF RR, conserver uniquement les enregistrements TXT
- Vérifier et optimiser le nombre de requêtes DNS (≤ 10)
- Remplacer le mécanisme "ptr" par "ip4" ou "ip6"
- Valider le nombre de "void lookup" (≤ 2)
- Tester si les enregistrements dépassent 512 octets
Destinataires:
- Arrêter d'interroger le type SPF RR
- Implémenter les nouvelles limites de requêtes DNS
- Implémenter la limite "void lookup"
- Mettre à jour la logique de traitement des erreurs
- Envisager l'implémentation d'un timeout d'évaluation
Tests:
# Utiliser un outil de validation SPF pour tester les enregistrements
# Par exemple: https://www.kitterman.com/spf/validate.html
# Vérifier le nombre de requêtes DNS
dig +short example.com TXT | grep "v=spf1"
# Valider la taille de l'enregistrement
dig example.com TXT | grep -A1 "ANSWER SECTION"
B.10 Mise à jour des documents de référence
RFC 7208 fait référence à des normes mises à jour:
- RFC 5321 (remplace RFC 2821)
- RFC 5322 (remplace RFC 2822)
- RFC 5234 (mise à jour ABNF)
- RFC 5598 (terminologie d'architecture de messagerie)
- RFC 5890 (noms de domaine internationalisés)