สามารถพิมพ์แบบเสนอราคาได้เพียงพอที่จะทำให้เมลเป็นไปตามการจำกัดความยาวบรรทัดที่ถูกวางใน RFC 2822 หรือไม่


9

ใน RFC 2822 (กำหนดอีเมล) มีการกำหนดว่าไม่มีบรรทัดใดที่ควรยาวเกิน 78 ตัวอักษร (ไม่รวม CRLF) และต้องไม่เกิน 998 ตัวอักษร ด้วยบรรทัดที่ยาวกว่าที่พิมพ์ได้และมีเครื่องหมายคำพูดจะถูกแบ่งออกเป็นหลายบรรทัดโดยลงท้ายด้วย '=' จนกว่าจะถึงเส้นจริง สอดคล้องกับเมลมาตรฐานหากมีบรรทัดที่มีความยาวมากกว่า 78 (หรือ 998) อักขระ แต่ถูกเข้ารหัสด้วยเครื่องหมายคำพูดที่พิมพ์ได้?

มีข้อโต้แย้งว่าสิ่งนี้ไม่เข้ากันได้เนื่องจากการรับเมลไคลเอ็นต์มีบรรทัดที่ยาวกว่าหลังจากถอดรหัสข้อความที่พิมพ์ได้

แก้ไข : เพื่อชี้แจงคำถามในแบบที่ถามโดย David Cary: ใช่ฉันหมายถึงจดหมายที่เข้ารหัสที่พิมพ์ได้ที่อ้างได้ควรจะเข้ากันได้กับเครื่องหมายคำพูดที่พิมพ์ได้หมายความว่าบรรทัดไม่เกิน 76 ตัวอักษร แต่ข้อความที่ถอดรหัสอาจมีบรรทัดที่ยาวกว่าขีด จำกัด นี้ ดังนั้นคำถามของฉันคือซอฟต์แวร์ไคลเอนต์ที่ใช้ RFC 1521 ควรจัดการบรรทัดยาว ๆ หลังจากถอดรหัสเนื้อหาข้อความที่พิมพ์ได้หรือไม่? นี่คือคำตอบใช่ทั้งสองคำตอบจนถึงขณะนี้ (ขอบคุณ) ด้วยข้อ จำกัด ที่ Netiquette (RFC 1855) ไม่สนับสนุน แต่ Netiquette ยังจำกัดความยาวของบรรทัดไว้ที่ 65 ตัวอักษรซึ่งเกือบจะไม่มีใคร จำกัด

คำตอบ:


3

ฉันไม่แน่ใจว่าคุณถามอะไร:

ไคลเอนต์ที่รับจดหมายค้นหาบรรทัดที่ยาวก่อนที่จะถอดรหัสสามารถพิมพ์ได้

กล่าวว่าซอฟต์แวร์เข้ารหัสที่พิมพ์ได้ที่ปลายด้านการส่งสัญญาณนั้นอ้างถึงตัวอักษรที่ไม่สามารถพิมพ์ได้ทำให้สายการเข้ารหัสที่ได้มีความยาวมากกว่าบรรทัดเดิมโดยไม่ต้องเพิ่ม "ตัวแบ่งเส้นนุ่ม" ทำให้เส้นเข้ารหัสยาวเกินขีด จำกัด

สิ่งนี้ไม่เข้ากัน

บรรทัดของข้อมูลที่เข้ารหัสที่เสนอราคาต้องมีความยาวไม่เกิน 76 อักขระ เพื่อตอบสนองความต้องการนี้โดยไม่แก้ไขข้อความที่เข้ารหัสอาจเพิ่มตัวแบ่งบรรทัดซอฟต์ ... ตัวแบ่งบรรทัดที่อ่อนนุ่มเหล่านี้ยังอนุญาตให้เข้ารหัสข้อความโดยไม่มีตัวแบ่งบรรทัด (หรือมีบรรทัดที่ยาวมาก) สำหรับสภาพแวดล้อมที่ขนาดบรรทัดมี จำกัด เช่น " ขีด จำกัด 1,000 อักขระต่อบรรทัด "ของซอฟต์แวร์ SMTP บางตัวตามที่อนุญาตโดย RFC 2821

- Wikipedia: ใบเสนอราคาที่พิมพ์ได้ , การถอดความRFC2045หน้า 21

บรรทัดที่เข้ารหัสนั้นสั้น แต่เมลไคลเอ็นต์ที่รับพบบรรทัดยาวหลังจากถอดรหัสที่ยกมาพิมพ์ได้

ที่สอดคล้องกับ RFC2822 และ RFC2045 และควรได้รับการสนับสนุนโดยซอฟต์แวร์ทั้งหมด

อย่างไรก็ตามการสร้างข้อความดังกล่าวนั้นไม่ได้รับการสนับสนุนจากแนวทางของ Netiquette หลายประการรวมถึงหน้า 3 ของRFC 1855 "แนวทางของ Netiquette"


RFC 1855 มีจำนวนของความคิดที่แปลกตาเช่นการ จำกัด ขนาดของสิ่งที่แนบมาที่ 50K หรือความคิดที่ว่าทุกคนบนใบหน้าของโลกยังคงใช้โกเฟอร์เพื่อวัตถุประสงค์ที่ร้ายแรง
เควิน

9

มันเป็นไปตามอย่างแน่นอน จุดทั้งหมดของ Quoted-Printable และส่วนที่เหลือของชุด MIME ของ RFC (RFC 2045 ถึง RFC 2049) คือการอนุญาตให้เข้ารหัสข้อมูลที่มิฉะนั้นจะไม่ถูกต้องในอีเมล RFC 2822 อย่างชัดเจน (และซ้ำ ๆ !) ชี้ผู้อ่านไปที่ RFC เหล่านั้นสำหรับข้อมูลเกี่ยวกับวิธีการทำเช่นนี้


1
+1 ขีด จำกัด บรรทัดไม่ได้กำหนดไว้ในข้อความ แต่เป็นการส่งข้อความ
Chris S

3

หากคุณต้องการทราบว่าการสร้างผู้แต่งอีเมลและ parser ที่ซับซ้อนนั้นซับซ้อนเพียงใดคุณต้องดูวิดีโอนี้ใน Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes ให้มุมมองภายในเกี่ยวกับ RFCs ที่แตกต่างกันและความโง่เขลาที่พวกเขานำมาสู่ชีวิตจริง

ยาว 40 นาทีและมีเพียงรอยขีดข่วนที่พื้นผิวของ "เนื้อหา" อีเมลที่ไม่ดีและดี หลังจากดูคุณจะเปลี่ยนความคิดเห็นของคุณเกี่ยวกับซอฟต์แวร์อีเมลที่คุณคิดว่าสอดคล้องกับมาตรฐานอีเมล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.