มีบทความ Wikipediaที่ดีเกี่ยวกับเรื่องนี้
การวนซ้ำครั้งแรกของ NCP ที่ใช้โดย ARPAnet นั้นคล้ายกับบิตสตรีมมากกว่าสตรีมไบต์หรือพยายามเจรจาขนาดไบต์ที่สะดวก ไบต์ 8- บิตเป็นมาตรฐานในภายหลัง นอกจากนี้ยังมีความพยายามหลายครั้งในการสร้างโปรโตคอลการถ่ายโอนไฟล์ที่จะทำงานในเครื่องที่แตกต่างกัน (เริ่มแรกเมลเป็นหน้าที่ของโปรโตคอล FTP ส่วนใหญ่เป็นคำสั่งMAILและMLFLคำสั่งจากนั้นแบ่งเป็นMTPภายหลังSMTP ) เครื่องเหล่านั้นมักจะมีการเข้ารหัสอักขระที่แตกต่างกัน - ASCII เทียบกับ EBCDIC - หรือขนาดไบต์ที่ต่างกัน, 8-bit bytes เทียบกับ 6-bit vs ...
ดังนั้นฟังก์ชั่นการถ่ายโอนจดหมายจึงถูกกำหนดไว้สำหรับการถ่ายโอนข้อความที่ค่อนข้างสั้นในข้อความธรรมดา โดยเฉพาะ "NVT-ASCII" ตัวอย่างเช่นRFC 772พูดว่า:
การเป็นตัวแทนและการจัดเก็บจดหมาย
เมลจะถูกถ่ายโอนจากอุปกรณ์เก็บข้อมูลในโฮสต์ที่ส่งไปยังอุปกรณ์เก็บข้อมูลในโฮสต์ที่รับ อาจจำเป็นต้องทำการแปลงบางอย่างบนเมลเนื่องจากการเก็บข้อมูลแทนในระบบทั้งสองนั้นแตกต่างกัน ตัวอย่างเช่น NVT-ASCII มีการจัดเก็บข้อมูลที่แตกต่างกันในระบบที่แตกต่างกัน โดยทั่วไปแล้ว PDP-10 จะจัดเก็บ NVT-ASCII เป็นอักขระ ASCII 7 บิตห้าตัวโดยมีการจัดชิดซ้ายด้วยคำศัพท์ 36 บิต ร้านค้า NVT-ASCII ของ 360 เป็นรหัส EBCDIC 8 บิตสี่ตัวในคำ 32 บิต Multics เก็บ NVT-ASCII เป็นอักขระ 9 บิตสี่ตัวในคำ 36 บิต
เพื่อความเรียบง่ายข้อมูลทั้งหมดจะต้องแสดงใน MTP เป็น NVT-ASCII ซึ่งหมายความว่าอักขระจะต้องถูกแปลงเป็นตัวแทน NVT-ASCII มาตรฐานเมื่อส่งข้อความโดยไม่คำนึงว่าโฮสต์การส่งและรับนั้นแตกต่างกันหรือไม่ ผู้ส่งแปลงข้อมูลจากการแสดงอักขระภายในไปเป็นตัวแทน NVT-ASCII 8 บิตมาตรฐาน (ดูข้อมูลจำเพาะ TELNET) ผู้รับแปลงข้อมูลจากแบบฟอร์มมาตรฐานเป็นแบบฟอร์มภายในของตัวเอง ตามมาตรฐานนี้ควรใช้ลำดับเพื่อแสดงถึงจุดสิ้นสุดของบรรทัดข้อความ
แม้ว่าแปดบิตจะถูกส่งผ่านลวดบิตที่ 8 มักจะถูกละทิ้งหรือ mangled เนื่องจากไม่มีความต้องการที่จะรักษามันไว้; ในความเป็นจริงโปรโตคอลบางตัวจำเป็นต้องตั้งค่าบิตที่ 8 ให้เป็นศูนย์เช่นSMTP RFCเริ่มต้นตามที่ยกมาด้านล่าง ในคำอื่น ๆ ซอฟแวร์ที่ไม่ได้8 บิตที่สะอาด
การถ่ายโอนข้อมูล
การเชื่อมต่อ TCP รองรับการส่งข้อมูล 8 บิต ข้อมูล SMTP เป็นอักขระ ASCII 7 บิต อักขระแต่ละตัวจะถูกส่งเป็นไบต์แบบ 8 บิตโดยบิตที่มีลำดับสูงจะถูกล้างให้เหลือศูนย์
สิ่งนี้ยืนยันเป็นเวลานานแม้หลังจากการเข้ารหัสอักขระ 8 บิต ISO-8859- # กลายเป็นที่แพร่หลาย แม้ว่าเซิร์ฟเวอร์บางตัวจะมีความสะอาด 8 บิตอยู่แล้ว แต่คนอื่น ๆ ก็ไม่ได้และการส่งข้อมูล 8 บิตแบบสุ่มจะส่งผลให้เกิดข้อความที่ยุ่งเหยิง
ต่อมามีการเผยแพร่"Extended SMTP"ซึ่งอนุญาตให้เซิร์ฟเวอร์อีเมลประกาศส่วนขยาย SMTP ที่รองรับ หนึ่งในนั้นคือ8BITMIMEแสดงว่าเซิร์ฟเวอร์ที่รับสามารถรับข้อมูล 8 บิตได้อย่างปลอดภัย ส่วนข้อความ MIME สามารถมี " การถ่ายโอนเนื้อหาการเข้ารหัส : 8 บิต" ซึ่งระบุว่าพวกเขาจะไม่ถูกเข้ารหัส แต่อย่างใด
อย่างไรก็ตามโพรโทคอล SMTP ยังคงยึดตามบรรทัดและมีการ จำกัด บรรทัด octet 998 ตลอดจนใช้.บรรทัด (0D 0A 2E 0D 0A 0) เป็นตัวบ่งชี้ "สิ้นสุดข้อความ" ซึ่งหมายความว่าแม้ว่าไฟล์ไบนารีส่วนใหญ่สามารถส่งแบบไม่เปลี่ยนแปลง แต่ก็ยังเป็นไปได้ที่ไฟล์ที่มีลำดับ octet นี้จะถูกตีความว่าเป็นจุดสิ้นสุดของข้อความที่ถ่ายโอนและส่วนที่เหลือของไฟล์เป็นคำสั่ง SMTP อาจทำให้เกิดความเสียหาย ในทำนองเดียวกัน "บรรทัด" ที่ยาวเกิน 998 อ็อกเท็ตอาจถูกตัดโดยเซิร์ฟเวอร์ที่รับ
ในปี 2000 ส่วนขยาย ESMTP "BINARYMIME"ได้รับการเผยแพร่เป็นRFC 3030ทำให้สามารถถ่ายโอนข้อมูลไบนารีแบบดิบผ่าน SMTP ตอนนี้ข้อความจะถูกถ่ายโอนเป็นส่วนของความยาวที่ระบุไว้ล่วงหน้าโดยไม่มีการใช้ความยาวเป็นศูนย์ที่ใช้เป็นเทอร์มิเนเตอร์และไม่จำเป็นต้องใช้การเข้ารหัส Base64 & ที่คล้ายกันอีกต่อไป น่าเสียดายที่เซิร์ฟเวอร์ SMTP บางตัวสนับสนุนส่วนขยายนี้ ตัวอย่างเช่นไม่ใช่ Postfix หรือ Exim4 โฆษณาCHUNKINGตอบ EHLO หากต้องการใช้ประโยชน์จาก BINARYMIME เซิร์ฟเวอร์ทั้งหมดจะต้องได้รับการสนับสนุนในพา ธ ข้อความซึ่งอาจมากกว่าหนึ่งหรือสอง
ดูสิ่งนี้ด้วย: