คำถามติดแท็ก rfc

ผลิตภัณฑ์อีเมลบุคคลที่สามที่แตกต่างกันสองรายการที่เรามีกำลังตอบสนองต่อส่วนหัวของรหัสเนื้อหาในแหล่ง MIME ของอีเมล สิ่งนี้ทำให้เกิดประสบการณ์การใช้งานที่ไม่สอดคล้องซึ่งเรากำลังพยายามแก้ไข นี่คือตัวอย่าง: --boundary-example Content-Location: CID:somethingatelse Content-ID: <foo4atfoo1atbar.net> Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV wbGljYXRpb24gcHJvaGliaXRlZC4A etc.. หนึ่งผลิตภัณฑ์อีเมลตีความว่านี่เป็นภาพฝังตัว การตีความอื่น ๆ นี้เป็นสิ่งที่แนบสามัญ (ไม่ฝัง) หากเราลบบรรทัดContent-IDออกอย่างสมบูรณ์ผลิตภัณฑ์ทั้งสองคิดว่าสิ่งที่แนบมานั้นไม่ได้ถูกฝังไว้ มี RFC เฉพาะที่สรุปว่าพฤติกรรมใดถูกต้องหรือไม่? เพื่อนร่วมงานและฉันตรวจสอบ RFC2392 ซึ่งในนามธรรมเปิดพูดว่า: การใช้ [MIME] ภายในอีเมลเพื่อสื่อเว็บเพจและ รูปภาพที่เกี่ยวข้องต้องใช้รูปแบบ URL เพื่ออนุญาตให้ HTML อ้าง ถึงรูปภาพหรือข้อมูลอื่น ๆ ที่รวมอยู่ในข้อความ Resource -ID Uniform Resource Locator "cid:" ทำหน้าที่จุดประสงค์นั้น […] รูปแบบ …

11 email  mime  rfc 

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

9 email  rfc