Про це є гарна стаття у Вікіпедії .
Ранні ітерації NCP, використовувані ARPAnet, більше нагадували потоки бітів, ніж потоки байтів, або спроби узгодити зручний розмір байтів; 8-бітний байт був стандартизований лише набагато пізніше. Було також кілька спроб створити протоколи передачі файлів, які працювали б на різних машинах (пошта спочатку була функцією протоколу FTP, насамперед як команди MAILтаMLFL команди, потім розділилася на MTP , пізніше SMTP .). Ці машини часто мали різні кодування символів - ASCII проти EBCDIC - або навіть різні розміри байтів , 8-бітні байти проти 6-бітних проти ...
Тому функції передачі пошти спочатку були визначені для передачі відносно коротких повідомлень простим текстом; конкретно, "NVT-ASCII". Наприклад, RFC 772 говорить:
ПІДПРИЄМСТВО ТА ЗБЕРІГАННЯ
Пошта передається із пристрою зберігання в хості, що надсилає, до пристрою зберігання в приймаючому хості. Можливо, буде потрібно виконати певні перетворення на пошті, оскільки представлення даних про зберігання даних у двох системах різні. Наприклад, NVT-ASCII має різні уявлення про зберігання даних у різних системах. PDP-10, як правило, зберігає NVT-ASCII у вигляді п'яти 7-бітних символів ASCII, виправданих ліворуч у 36-бітному слові. Компанія 360 зберігає NVT-ASCII як чотири 8-бітні коди EBCDIC в 32-бітному слові. Мультимедіа зберігає NVT-ASCII як чотири 9-бітні символи в 36-бітному слові.
Для простоти всі дані повинні бути представлені в MTP як NVT-ASCII. Це означає, що символи повинні бути перетворені в стандартне представлення NVT-ASCII під час передачі тексту, незалежно від того, чи хости, що надсилають і приймають, не відрізняються. Відправник перетворює дані зі свого внутрішнього представлення символів у стандартне 8-бітове представлення NVT-ASCII (див. Специфікацію TELNET). Одержувач перетворює дані зі стандартної форми у власну внутрішню форму. Відповідно до цього стандарту послідовність повинна використовуватися для позначення кінця рядка тексту.
Незважаючи на те, що вісім біт передається по дроту, 8-й біт часто буде відкинутий або пошкоджений, оскільки не потрібно було його зберігати; насправді, деякі протоколи вимагають, щоб 8-й біт був встановлений на нуль, наприклад, початковий 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, його мали б підтримувати всі сервери на шляху повідомлень, яких може бути більше одного або двох.
Дивись також: