Aller au contenu principal

Annexe F. Fonctionnalités dépréciées de RFC 821 (Deprecated Features of RFC 821)

Cette annexe répertorie les fonctionnalités de RFC 821 qui sont dépréciées et ne devraient pas être utilisées dans les nouvelles implémentations.

F.1. TURN​

Commande : TURN

But : Inversait les rôles client et serveur, permettant l'échange de courrier bidirectionnel sur une seule connexion TCP.

Raisons de dépréciation :

  • Risques de sécurité : Permettait le relais non autorisé
  • Complexité : Difficile à implémenter correctement
  • Inutile : Les systèmes modernes maintiennent des connexions séparées

Statut : Obsolète - Ne pas implémenter

Réponse : Les serveurs DEVRAIENT (SHOULD) retourner 502 Command not implemented

C: TURN
S: 502 5.5.1 Command not implemented

F.2. Routage par source (Source Routing)​

Fonctionnalité : Routage explicite via des hôtes intermédiaires

Syntaxe : @host1,@host2:user@host3

Raisons de dépréciation :

  • Sécurité : Permis le spam et les abus
  • Complexité : Logique de routage sujette aux erreurs
  • Obsolescence : Les MX DNS fournissent un meilleur routage
  • Voir l'Annexe C pour plus de détails

Statut : Déprécié - Ne devrait pas être utilisé

Réponse : Les serveurs DEVRAIENT (SHOULD) rejeter les adresses routées par source

C: MAIL FROM:<@relay.example:[email protected]>
S: 550 5.5.0 Source routing not supported

F.3. HELO​

Commande : HELO domain

Alternative moderne : EHLO domain

Statut : Pris en charge mais non préféré

HELO est conservé pour la compatibilité ascendante, mais :

  • EHLO est fortement recommandé
  • Les nouvelles implémentations DEVRAIENT (SHOULD) prendre en charge les deux
  • Les clients DEVRAIENT (SHOULD) essayer EHLO d'abord et revenir à HELO si nécessaire

Recommandation : Toujours essayer EHLO d'abord

# Recommandé
C: EHLO client.example
S: 250 server.example

# Repli uniquement
C: HELO client.example  
S: 250 server.example

F.4. Littéraux # (#-literals)​

Fonctionnalité : Format de littéral d'adresse alternatif utilisant # au lieu de []

Ancienne syntaxe : user@[#192.0.2.1] (décimal), user@[#xC0000201] (hexadécimal)

Raisons de dépréciation :

  • Syntaxe confuse
  • Rarement utilisé
  • Les crochets standard sont suffisants

Statut : Obsolète - Ne pas implémenter

Syntaxe moderne : Utiliser les littéraux IP standards

✅ IPv4 : user@[192.0.2.1]
✅ IPv6 : user@[IPv6:2001:db8::1]
❌ Ancien : user@[#192.0.2.1]

F.5. Dates et années (Dates and Years)​

Problème : RFC 821 permettait les années à 2 chiffres

Problème : Ambiguïté Y2K

Statut : Corrigé - Toujours utiliser des années à 4 chiffres

Exigence RFC 5322 : Les dates DOIVENT (MUST) utiliser des années à 4 chiffres

❌ Ancien : Date: 24 Dec 99 10:00:00 +0000
✅ Nouveau : Date: 24 Dec 2024 10:00:00 +0000

F.6. Envoi vs courrier (Sending versus Mailing)​

Commandes : SEND, SOML, SAML

Commande SEND (SEND Command)​

  • But : Envoyer au terminal de l'utilisateur plutôt qu'à la boîte aux lettres
  • Raison de dépréciation : Accès au terminal obsolète

Commande SOML (SOML Command)​

  • But : Envoyer ou courrier - livrer au terminal si connecté, sinon à la boîte aux lettres
  • Raison de dépréciation : Complexe et rarement implémenté

Commande SAML (SAML Command)​

  • But : Envoyer et courrier - livrer au terminal et à la boîte aux lettres
  • Raison de dépréciation : Livraison au terminal obsolète

Statut : Obsolète - Ne pas implémenter

Réponse : Retourner 502 Command not implemented

C: SEND FROM:<[email protected]>
S: 502 5.5.1 Command not implemented

C: SOML FROM:<[email protected]>
S: 502 5.5.1 Command not implemented

C: SAML FROM:<[email protected]>
S: 502 5.5.1 Command not implemented

Tableau récapitulatif (Summary Table)​

FonctionnalitéStatutAction
TURNObsolèteNe pas implémenter
Routage par sourceDépréciéRejeter si tenté
HELOPris en chargeConserver pour compatibilité, recommander EHLO
Littéraux #ObsolèteNe pas implémenter
Années à 2 chiffresCorrigéToujours utiliser 4 chiffres
SEND/SOML/SAMLObsolèteNe pas implémenter

Directives de migration (Migration Guidelines)​

Pour les serveurs prenant toujours en charge les fonctionnalités dépréciées :

  1. Journaliser l'utilisation : Suivre si quelqu'un utilise les fonctionnalités dépréciées
  2. Retourner des erreurs : Rejeter les commandes obsolètes avec des messages clairs
  3. Documenter : Informer les utilisateurs de la dépréciation
  4. Retirer : Supprimer complètement le support après une période de transition
  5. Tester : Assurer que la suppression n'affecte pas l'utilisation légitime

Pour les clients utilisant des fonctionnalités dépréciées :

  1. Mettre à jour le code : Supprimer l'utilisation de fonctionnalités obsolètes
  2. Utiliser EHLO : Passer de HELO à EHLO
  3. Supprimer le routage par source : Utiliser des adresses simples
  4. Formats standards : Utiliser des formats d'adresse et de date modernes
Dernière mise à jour le