Há um bom artigo da Wikipedia sobre isso.
As primeiras iterações do NCP, usadas pelo 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 foi padronizado apenas muito mais tarde. Também houve várias tentativas de criar protocolos de transferência de arquivos que funcionariam em máquinas diferentes (o correio era inicialmente uma função do protocolo FTP, principalmente como os comandos MAILeMLFL , depois dividido em MTP , depois em SMTP ). Essas máquinas geralmente tinham codificações de caracteres diferentes - ASCII vs EBCDIC - ou mesmo tamanhos de bytes diferentes, bytes de 8 bits e 6 bits ...
Portanto, as funções de transferência de email foram definidas inicialmente para transferir mensagens relativamente curtas em texto sem formatação; especificamente, "NVT-ASCII". Por exemplo, o RFC 772 diz:
REPRESENTAÇÃO E ARMAZENAMENTO DE CORREIO
O correio é transferido de um dispositivo de armazenamento no host de envio para um dispositivo de armazenamento no host de recebimento. Pode ser necessário executar determinadas transformações no correio porque as representações de armazenamento de dados nos dois sistemas são diferentes. Por exemplo, o NVT-ASCII possui diferentes representações de armazenamento de dados em diferentes sistemas. Os PDP-10 geralmente armazenam NVT-ASCII como cinco caracteres ASCII de 7 bits, justificados à esquerda em uma palavra de 36 bits. A 360's armazena o NVT-ASCII como quatro códigos EBCDIC de 8 bits em uma palavra de 32 bits. Multics armazena NVT-ASCII como quatro caracteres de 9 bits em uma palavra de 36 bits.
Por uma questão de simplicidade, todos os dados devem ser representados no MTP como NVT-ASCII. Isso significa que os caracteres devem ser convertidos na representação NVT-ASCII padrão ao transmitir texto, independentemente de os hosts de envio e recebimento serem diferentes. O remetente converte os dados de sua representação interna de caracteres na representação NVT-ASCII padrão de 8 bits (consulte a especificação TELNET). O receptor converte os dados do formulário padrão em seu próprio formulário interno. De acordo com este padrão, a sequência deve ser usada para indicar o final de uma linha de texto.
Embora oito bits estivessem sendo transmitidos pelo cabo, o oitavo bit costumava ser descartado ou confundido, pois não havia necessidade de preservá-lo; de fato, alguns protocolos exigiam que o 8º bit fosse definido como zero, como o RFC SMTP inicial, conforme citado abaixo. Em outras palavras, o software não estava limpo em 8 bits .
Transferência de dados
A conexão TCP suporta a transmissão de bytes de 8 bits. Os dados SMTP são caracteres ASCII de 7 bits. Cada caractere é transmitido como um byte de 8 bits com o bit de ordem superior limpo em zero.
Isso persistiu por um longo tempo, mesmo depois que as codificações de caracteres ISO-8859- # de 8 bits se espalharam. Embora alguns servidores já estivessem limpos em 8 bits, muitos outros não estavam, e o envio cego de dados em 8 bits resultaria em mensagens confusas.
Posteriormente, foi publicado o "SMTP estendido" , permitindo que os servidores de correio declarassem extensões SMTP suportadas; uma delas era 8BITMIME, indicando que o servidor de recebimento podia aceitar com segurança dados de 8 bits. As partes da mensagem MIME podem ter " Content-Transfer-Encoding : 8bit", indicando que não são codificadas de forma alguma.
No entanto, o protocolo SMTP permaneceu baseado em linha e possui o limite 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 contenham essa sequê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, a extensão ESMTP "BINARYMIME" foi publicada como RFC 3030 , permitindo transferências de dados binários brutos por SMTP. A mensagem agora é transferida em pedaços de comprimento pré-indicado, com um pedaço de comprimento zero usado como terminador, e Base64 e codificações similares não são mais necessárias. Infelizmente, poucos servidores SMTP suportam essa extensão; por exemplo, nem o Postfix nem o Exim4 anunciam CHUNKINGem resposta ao EHLO. Para tirar proveito do BINARYMIME, ele teria que ser suportado por todos os servidores no caminho da mensagem, que pode ser mais do que apenas um ou dois.
Veja também: