Hay un buen artículo de Wikipedia sobre esto.
Las primeras iteraciones de NCP utilizadas por ARPAnet se parecían más a las secuencias de bits que a las de bytes, o los intentos de negociar un tamaño de bytes conveniente; el byte de 8 bits solo se estandarizó mucho más tarde. También hubo varios intentos de crear protocolos de transferencia de archivos que funcionarían en diferentes máquinas (el correo era inicialmente una función del protocolo FTP, principalmente como los comandos MAILyMLFL , luego se dividió en MTP , luego SMTP ). Esas máquinas a menudo tenían diferentes codificaciones de caracteres (ASCII vs EBCDIC) o incluso diferentes tamaños de bytes , bytes de 8 bits frente a 6 bits frente a ...
Por lo tanto, las funciones de transferencia de correo se definieron inicialmente para transferir mensajes relativamente cortos en texto sin formato; específicamente, "NVT-ASCII". Por ejemplo, RFC 772 dice:
REPRESENTACIÓN Y ALMACENAMIENTO POR CORREO
El correo se transfiere desde un dispositivo de almacenamiento en el host emisor a un dispositivo de almacenamiento en el host receptor. Puede ser necesario realizar ciertas transformaciones en el correo porque las representaciones de almacenamiento de datos en los dos sistemas son diferentes. Por ejemplo, NVT-ASCII tiene diferentes representaciones de almacenamiento de datos en diferentes sistemas. Los PDP-10 generalmente almacenan NVT-ASCII como cinco caracteres ASCII de 7 bits, justificados a la izquierda en una palabra de 36 bits. 360's almacena NVT-ASCII como cuatro códigos EBCDIC de 8 bits en una palabra de 32 bits. Multics almacena NVT-ASCII como cuatro caracteres de 9 bits en una palabra de 36 bits.
En aras de la simplicidad, todos los datos deben estar representados en MTP como NVT-ASCII. Esto significa que los caracteres deben convertirse en la representación NVT-ASCII estándar al transmitir texto, independientemente de si los hosts de envío y recepción son diferentes. El remitente convierte los datos de su representación de caracteres internos a la representación NVT-ASCII estándar de 8 bits (consulte la especificación TELNET). El receptor convierte los datos del formulario estándar a su propio formulario interno. De acuerdo con este estándar, la secuencia debe usarse para denotar el final de una línea de texto.
Aunque se transmitían ocho bits a través del cable, el octavo bit a menudo se descartaba o se destrozaba, ya que no era necesario preservarlo; de hecho, algunos protocolos requieren que el octavo bit se establezca en cero, como el RFC SMTP inicial como se cita a continuación. En otras palabras, el software no estaba limpio de 8 bits .
Transferencia de datos
La conexión TCP admite la transmisión de bytes de 8 bits. Los datos SMTP son caracteres ASCII de 7 bits. Cada carácter se transmite como un byte de 8 bits con el bit de orden superior borrado a cero.
Esto persistió durante mucho tiempo incluso después de que las codificaciones de caracteres ISO-8859- # de 8 bits se generalizaran. Aunque algunos servidores ya estaban limpios en 8 bits, muchos otros no lo estaban, y el envío a ciegas de datos de 8 bits habría resultado en mensajes destrozados.
Más tarde, se publicó "SMTP extendido" , permitiendo a los servidores de correo declarar extensiones SMTP que admitían; uno de ellos fue 8BITMIME, lo que indica que el servidor receptor podría aceptar con seguridad los datos de 8 bits. Las partes del mensaje MIME pueden tener " Codificación de transferencia de contenido : 8 bits", lo que indica que no están codificadas de ninguna manera.
Sin embargo, el protocolo SMTP permaneció basado en la línea y tiene el límite de línea de 998 octetos, además de usar una .línea (0D 0A 2E 0D 0A) como el indicador de "fin de mensaje". Esto significa que, aunque la mayoría de los archivos binarios podrían enviarse sin modificaciones, aún es posible que los archivos que contienen esta secuencia de octetos se interpreten como el final del mensaje transferido, y el resto del archivo como un comando SMTP, posiblemente causando daños. Del mismo modo, el servidor receptor puede cortar una "línea" de más de 998 octetos.
En 2000, la extensión ESMTP "BINARYMIME" se publicó como RFC 3030 , lo que permite la transferencia de datos binarios en bruto a través de SMTP. El mensaje ahora se transfiere en fragmentos de longitud previamente indicada, con un fragmento de longitud cero utilizado como terminador, y ya no se necesitan codificaciones Base64 y similares. Desafortunadamente, pocos servidores SMTP admiten esta extensión; por ejemplo, ni Postfix ni Exim4 anuncian CHUNKINGen respuesta a EHLO. Para aprovechar BINARYMIME, todos los servidores de la ruta del mensaje tendrían que admitirlo, que puede ser más que uno o dos.
Ver también: