Il y a un bon article Wikipedia à ce sujet.
Les premières itérations de NCP utilisées par ARPAnet ressemblaient davantage à des flux binaires qu'à des flux d'octets, ou à des tentatives de négocier une taille d'octet pratique; l'octet 8 bits n'a été normalisé que beaucoup plus tard. Il y a également eu plusieurs tentatives pour créer des protocoles de transfert de fichiers qui fonctionneraient sur différentes machines (le courrier était initialement une fonction du protocole FTP, principalement en tant MAILqueMLFL commandes et , puis divisé en MTP , puis SMTP .) Ces machines avaient souvent des encodages de caractères différents - ASCII vs EBCDIC - ou même des tailles d'octets différentes, des octets 8 bits vs 6 bits vs ...
Par conséquent, les fonctions de transfert de courrier ont été initialement définies pour le transfert de messages relativement courts en texte brut; spécifiquement, "NVT-ASCII". Par exemple, RFC 772 dit:
REPRÉSENTATION ET STOCKAGE DU COURRIER
Le courrier est transféré d'un périphérique de stockage dans l'hôte d'envoi vers un périphérique de stockage dans l'hôte de réception. Il peut être nécessaire d'effectuer certaines transformations sur le courrier car les représentations de stockage de données dans les deux systèmes sont différentes. Par exemple, NVT-ASCII a différentes représentations de stockage de données dans différents systèmes. Les PDP-10 stockent généralement NVT-ASCII sous forme de cinq caractères ASCII 7 bits, justifiés à gauche dans un mot de 36 bits. 360 stocke NVT-ASCII sous forme de quatre codes EBCDIC 8 bits dans un mot 32 bits. Multics stocke NVT-ASCII sous la forme de quatre caractères 9 bits dans un mot de 36 bits.
Par souci de simplicité, toutes les données doivent être représentées dans MTP en tant que NVT-ASCII. Cela signifie que les caractères doivent être convertis en représentation NVT-ASCII standard lors de la transmission de texte, que les hôtes d'envoi et de réception soient différents. L'expéditeur convertit les données de sa représentation de caractères interne en la représentation NVT-ASCII 8 bits standard (voir la spécification TELNET). Le récepteur convertit les données du formulaire standard en son propre formulaire interne. Conformément à cette norme, la séquence doit être utilisée pour indiquer la fin d'une ligne de texte.
Même si huit bits étaient transmis sur le fil, le 8e bit était souvent supprimé ou altéré, car il n'était pas nécessaire de le conserver; en fait, certains protocoles exigeaient que le 8e bit soit mis à zéro, comme le RFC SMTP initial cité ci-dessous. En d'autres termes, le logiciel n'était pas propre en 8 bits .
Transfert de données
La connexion TCP prend en charge la transmission d'octets 8 bits. Les données SMTP sont des caractères ASCII 7 bits. Chaque caractère est transmis sous la forme d'un octet de 8 bits avec le bit de poids fort remis à zéro.
Cela a persisté pendant longtemps, même après que les encodages de caractères 8 bits ISO-8859- # se soient répandus. Même si certains serveurs étaient déjà propres en 8 bits, beaucoup d'autres ne l'étaient pas, et l'envoi aveugle de données 8 bits aurait entraîné des messages déformés.
Plus tard, "Extended SMTP" a été publié, permettant aux serveurs de messagerie de déclarer les extensions SMTP qu'ils prenaient en charge; l'un d'eux était 8BITMIME, indiquant que le serveur de réception pouvait accepter en toute sécurité des données 8 bits. Les parties de message MIME peuvent avoir " Content-Transfer-Encoding : 8bit", indiquant qu'elles ne sont en aucun cas codées.
Cependant, le protocole SMTP est resté basé sur la ligne et a la limite de ligne de 998 octets, ainsi que l'utilisation d'une .ligne (0D 0A 2E 0D 0A) comme indicateur de "fin de message". Cela signifie que même si la plupart des fichiers binaires peuvent être envoyés sans modification, il est toujours possible que les fichiers contenant cette séquence d'octets soient interprétés comme la fin du message transféré, et le reste du fichier comme une commande SMTP, ce qui pourrait causer des dommages. De même, une "ligne" de plus de 998 octets peut être coupée par le serveur récepteur.
En 2000, l' extension ESMTP "BINARYMIME" a été publiée sous le nom de RFC 3030 , permettant les transferts de données binaires brutes via SMTP. Le message est maintenant transféré en morceaux de longueur pré-indiquée, avec un morceau de longueur nulle utilisé comme terminateur, et les encodages Base64 et similaires ne sont plus nécessaires. Malheureusement, peu de serveurs SMTP prennent en charge cette extension; par exemple, ni Postfix ni Exim4 ne font de publicité CHUNKINGen réponse à EHLO. Pour tirer parti de BINARYMIME, il devrait être pris en charge par tous les serveurs dans le chemin du message, qui peut être plus qu'un ou deux.
Voir également: