Có một bài viết Wikipedia tốt về điều này.
Các lần lặp đầu tiên của NCP được ARPAnet sử dụng giống như các luồng bit hơn là các luồng byte hoặc cố gắng đàm phán kích thước byte thuận tiện; byte 8 bit chỉ được chuẩn hóa vào nhiều sau này. Cũng có một số nỗ lực trong việc tạo các giao thức truyền tệp sẽ hoạt động trong các máy khác nhau (thư ban đầu là một chức năng của giao thức FTP, chủ yếu là các lệnh MAILvàMLFL , sau đó được phân tách thành MTP , sau này là SMTP .). Những máy đó thường có mã hóa ký tự khác nhau - ASCII so với EBCDIC - hoặc thậm chí kích thước byte khác nhau, byte 8 bit so với 6 bit so với ...
Do đó, chức năng chuyển thư ban đầu được xác định để chuyển thư tương đối ngắn trong văn bản thuần túy; cụ thể là "NVT-ASCII". Ví dụ: RFC 772 nói:
ĐẠI DIỆN VÀ BẢO QUẢN
Thư được chuyển từ thiết bị lưu trữ trong máy chủ gửi đến thiết bị lưu trữ trong máy chủ nhận. Có thể cần phải thực hiện các chuyển đổi nhất định trên thư vì các biểu diễn lưu trữ dữ liệu trong hai hệ thống là khác nhau. Ví dụ, NVT-ASCII có các biểu diễn lưu trữ dữ liệu khác nhau trong các hệ thống khác nhau. PDP-10 thường lưu trữ NVT-ASCII dưới dạng năm ký tự ASCII 7 bit, được căn trái trong một từ 36 bit. 360 lưu trữ NVT-ASCII dưới dạng bốn mã EBCDIC 8 bit trong một từ 32 bit. Multics lưu trữ NVT-ASCII dưới dạng bốn ký tự 9 bit trong một từ 36 bit.
Để đơn giản, tất cả dữ liệu phải được trình bày trong MTP dưới dạng NVT-ASCII. Điều này có nghĩa là các ký tự phải được chuyển đổi thành biểu diễn NVT-ASCII tiêu chuẩn khi truyền văn bản, bất kể máy chủ gửi và nhận có giống nhau hay không. Người gửi chuyển đổi dữ liệu từ biểu diễn ký tự bên trong của nó sang biểu diễn NVT-ASCII 8 bit tiêu chuẩn (xem thông số kỹ thuật của TELNET). Người nhận chuyển đổi dữ liệu từ dạng chuẩn sang dạng bên trong của chính nó. Theo tiêu chuẩn này, trình tự nên được sử dụng để biểu thị sự kết thúc của một dòng văn bản.
Mặc dù tám bit được truyền qua dây, bit thứ 8 thường sẽ bị loại bỏ hoặc xáo trộn, vì không có yêu cầu bảo quản nó; trong thực tế, một số giao thức yêu cầu bit thứ 8 được đặt thành 0, chẳng hạn như RFC SMTP ban đầu như được trích dẫn dưới đây. Nói cách khác, phần mềm không sạch 8 bit .
Truyền dữ liệu
Kết nối TCP hỗ trợ truyền các byte 8 bit. Dữ liệu SMTP là các ký tự ASCII 7 bit. Mỗi ký tự được truyền dưới dạng một byte 8 bit với bit thứ tự cao bị xóa thành 0.
Điều này tồn tại trong một thời gian dài ngay cả sau khi mã hóa ký tự ISO-8859- # 8 bit trở nên phổ biến. Mặc dù một số máy chủ đã sạch 8 bit, nhưng nhiều máy khác thì không, và việc gửi dữ liệu 8 bit một cách mù quáng sẽ dẫn đến tin nhắn bị sai lệch.
Sau đó, "Extended Extended" đã được xuất bản, cho phép các máy chủ mail khai báo các phần mở rộng SMTP mà họ hỗ trợ; một trong số đó là 8BITMIME, chỉ ra rằng máy chủ nhận có thể chấp nhận dữ liệu 8 bit một cách an toàn. Các phần thông báo MIME có thể có " Mã hóa chuyển nội dung : 8 bit", cho biết rằng chúng không được mã hóa theo bất kỳ cách nào.
Tuy nhiên, giao thức SMTP vẫn dựa trên dòng và có giới hạn dòng octet 998, cũng như sử dụng một .dòng (0D 0A 2E 0D 0A) làm chỉ báo "kết thúc tin nhắn". Điều này có nghĩa là mặc dù hầu hết các tệp nhị phân có thể được gửi không bị thay đổi, nhưng vẫn có khả năng các tệp chứa chuỗi octet này sẽ được hiểu là phần cuối của tin nhắn được chuyển và phần còn lại của tệp là lệnh SMTP, có thể gây ra thiệt hại. Tương tự, một "dòng" dài hơn 998 octet có thể bị cắt bởi máy chủ nhận.
Năm 2000, tiện ích mở rộng ESMTP "BINaryMIME" đã được xuất bản với tên RFC 3030 , cho phép chuyển dữ liệu nhị phân thô qua SMTP. Thông báo hiện được chuyển theo từng đoạn có độ dài được chỉ định trước, với một đoạn có độ dài bằng không được sử dụng làm dấu kết thúc, và mã hóa Base64 & tương tự không còn cần thiết nữa. Thật không may, rất ít máy chủ SMTP hỗ trợ phần mở rộng này; ví dụ, cả Postfix và Exim4 đều không quảng cáo CHUNKINGkhi trả lời EHLO. Để tận dụng lợi thế của BINARYMIME, nó sẽ phải được hỗ trợ bởi tất cả các máy chủ trong đường dẫn tin nhắn, có thể nhiều hơn chỉ một hoặc hai.
Xem thêm: