Existe um bom artigo da Wikipedia sobre .
As iterações mais antigas do NCP usadas pela ARPAnet eram mais como fluxos de bits do que fluxos de bytes ou tentativas de negociar um tamanho conveniente de bytes; o byte de 8 bits só foi padronizado muito mais tarde. Também houve várias tentativas de criar protocolos de transferência de arquivos que funcionassem em máquinas diferentes (o e-mail era inicialmente uma função do protocolo FTP, principalmente como o título MAIL e MLFL comandos e, em seguida, divididos em MTP , mais tarde SMTP . ). Essas máquinas muitas vezes tinham codificações de caracteres diferentes - ASCII vs EBCDIC - ou até mesmo tamanhos de byte , bytes de 8 bits vs 6 bits versus ...
Portanto, as funções de transferência de email foram inicialmente definidas para transferir mensagens relativamente curtas em texto simples; especificamente, "NVT-ASCII". Por exemplo, RFC 772 diz:
MAIL REPRESENTATION AND STORAGE
Mail is transferred from a storage device in the sending host to a storage device in the receiving host. It may be necessary to perform certain transformations on the mail because data storage representations in the two systems are different. For example, NVT-ASCII has different data storage representations in different systems. PDP-10's generally store NVT-ASCII as five 7-bit ASCII characters, left-justified in a 36-bit word. 360's store NVT-ASCII as four 8-bit EBCDIC codes in a 32-bit word. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit word.
For the sake of simplicity, all data must be represented in MTP as NVT-ASCII. This means that characters must be converted into the standard NVT-ASCII representation when transmitting text, regardless of whether the sending and receiving hosts are dissimilar. The sender converts the data from its internal character representation to the standard 8-bit NVT-ASCII representation (see the TELNET specification). The receiver converts the data from the standard form to its own internal form. In accordance with this standard, the sequence should be used to denote the end of a line of text.
Apesar de oito bits estarem sendo transmitidos através do fio, o 8º bit seria frequentemente descartado ou desconfigurado, já que não havia necessidade de preservá-lo; de fato, alguns protocolos exigiram que o 8º bit fosse definido como zero, como o inicial SMTP RFC como citado abaixo. Em outras palavras, o software não era 8-bit clean .
Data Transfer
The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.
Isso persistiu por muito tempo, mesmo depois que as codificações de caracteres ISO-8859- # de 8 bits se tornaram difundidas. Mesmo que alguns servidores já estivessem limpos de 8 bits, muitos outros não estavam, e enviar cegamente dados de 8 bits resultaria em mensagens desconfiguradas.
Mais tarde, "SMTP estendido" foi publicado, permitindo que servidores de email declarar extensões SMTP que eles suportaram; um deles era 8BITMIME , indicando que o servidor de destino podia aceitar com segurança 8 bits dados. As partes da mensagem MIME podem conter " Content-Transfer-Encoding : 8bit", indicando que elas não são codificado de qualquer forma.
No entanto, o protocolo SMTP permaneceu baseado em linha e possui o limite de linha de 998 octetos, além de usar uma linha . (0D 0A 2E 0D 0A) como o indicador "fim da mensagem". Isso significa que, embora a maioria dos arquivos binários possa ser enviada inalterada, ainda é possível que os arquivos que contêm essa seqüência de octetos sejam interpretados como o final da mensagem transferida e o restante do arquivo como um comando SMTP, possivelmente causando danos. Da mesma forma, uma "linha" com mais de 998 octetos pode ser cortada pelo servidor de recebimento.
Em 2000, as Extensão ESMTP "BINARYMIME" foi publicada como RFC 3030 , permitindo transferências de dados binários brutos através de SMTP. A mensagem agora é transferida em blocos de comprimento pré-indicado, com um pedaço de comprimento zero usado como terminador, e Base64 & codificações semelhantes não são mais necessárias. Infelizmente, poucos servidores SMTP suportam essa extensão; por exemplo, nem Postfix nem Exim4 anunciam CHUNKING em resposta a EHLO. Para aproveitar o BINARYMIME, ele teria que ser suportado por todos os servidores no caminho da mensagem, o que pode ser mais do que apenas um ou dois.
Veja também: