На это есть хорошая статья в Википедии .
Самые ранние итерации NCP, используемые ARPAnet, были больше похожи на битовые потоки, чем на байтовые потоки, или на попытки согласовать удобный размер байта; 8-битный байт был стандартизирован только намного позже. Были также несколько попыток создать протоколы передачи файлов, которые будут работать в разных машинах (почта была первоначально функцией протокола FTP, в первую очередь, как MAILиMLFL команды, а затем разделить на МТР, позже SMTP .). Эти машины часто имели различную кодировку символов - ASCII и EBCDIC - или даже разные размеры байтов, 8-битные байты против 6-битных против ...
Поэтому функции передачи почты изначально были определены для передачи относительно коротких сообщений в виде простого текста; в частности, "NVT-ASCII". Например, RFC 772 говорит:
ПРЕДСТАВИТЕЛЬСТВО И ХРАНЕНИЕ ПОЧТЫ
Почта передается с устройства хранения на отправляющем хосте на устройство хранения на принимающем хосте. Может потребоваться выполнить определенные преобразования для почты, поскольку представления хранения данных в двух системах различны. Например, NVT-ASCII имеет разные представления хранения данных в разных системах. PDP-10 обычно хранят NVT-ASCII в виде пяти 7-битных символов ASCII, выровненных по левому краю в 36-битном слове. 360-е годы хранят NVT-ASCII в виде четырех 8-битных кодов EBCDIC в 32-битном слове. Multics хранит NVT-ASCII в виде четырех 9-битных символов в 36-битном слове.
Для простоты все данные должны быть представлены в MTP как NVT-ASCII. Это означает, что символы должны быть преобразованы в стандартное представление NVT-ASCII при передаче текста независимо от того, различаются ли отправляющий и принимающий узлы. Отправитель преобразует данные из своего внутреннего символьного представления в стандартное 8-битное представление NVT-ASCII (см. Спецификацию TELNET). Получатель преобразует данные из стандартной формы в свою собственную внутреннюю форму. В соответствии с этим стандартом последовательность должна использоваться для обозначения конца строки текста.
Даже если по кабелю передавалось восемь битов, восьмой бит часто отбрасывался или искажался, поскольку не было необходимости сохранять его; на самом деле, некоторые протоколы требуют, чтобы восьмой бит был установлен на ноль, например, начальный SMTP RFC, как указано ниже. Другими словами, программное обеспечение не было 8-битным чистым .
Обмен данными
Соединение TCP поддерживает передачу 8-битных байтов. Данные SMTP - это 7-битные символы ASCII. Каждый символ передается в виде 8-битного байта, причем старший бит сбрасывается в ноль.
Это сохранялось долгое время даже после того, как 8-битные кодировки ISO-8859- # стали широко распространенными. Несмотря на то, что некоторые серверы были уже 8-битными, другие - нет, и слепая отправка 8-битных данных привела бы к искаженным сообщениям.
Позже была опубликована «Расширенная SMTP», позволяющая почтовым серверам объявлять расширения SMTP, которые они поддерживали; один из них 8BITMIMEуказывает на то, что принимающий сервер может безопасно принимать 8-битные данные. Части сообщения MIME могут иметь « Content-Transfer-Encoding : 8bit», указывая на то, что они не кодируются каким-либо образом.
Однако протокол SMTP оставался линейным и имеет предел строки в 998 октетов, а также использование .линии (0D 0A 2E 0D 0A) в качестве индикатора «конец сообщения». Это означает, что, хотя большинство двоичных файлов могут быть отправлены без изменений, все же возможно, что файлы, содержащие эту последовательность октетов, будут интерпретированы как конец переданного сообщения, а остальная часть файла - как команда SMTP, что может привести к повреждению. Аналогичным образом, принимающий сервер может обрезать «строку» длиной более 998 октетов.
В 2000 году расширение ESMTP «BINARYMIME» было опубликовано как RFC 3030, что позволяет передавать необработанные двоичные данные по SMTP. Сообщение теперь передается порциями предварительно указанной длины, причем порция нулевой длины используется в качестве терминатора, и Base64 и подобные кодировки больше не нужны. К сожалению, немногие SMTP-серверы поддерживают это расширение; например, ни Postfix, ни Exim4 не размещают рекламу CHUNKINGв ответ на EHLO. Чтобы воспользоваться преимуществами BINARYMIME, он должен поддерживаться всеми серверами в пути сообщения, который может быть больше одного или двух.
Смотрите также: