ข้อคิดแบบเปิดเผยเกี่ยวกับอีเมลยุคที่ 2
(gabrielsieben.tech)Note: บทความนี้เป็นเพียงการเรียบเรียงความคิดของผมเท่านั้น ไม่ได้ผ่านการไตร่ตรองอย่างลึกซึ้ง และไม่จำเป็นต้องมองว่าเป็นไอเดียที่ดี โปรดลดความคาดหวังให้ต่ำที่สุดก่อนอ่าน
ปัญหาของอีเมล
- แม้เทคโนโลยีเก่าแก่หลายอย่างยังคงถูกใช้งานอยู่ แต่อีเมลกลับทำให้ผมหงุดหงิดทุกครั้งที่ใช้
- ในมุมของผู้ใช้ อีเมลทำงานได้ค่อนข้างดี บางครั้งอาจมีอีเมลมากเกินไปเพราะสแปม แต่อีเมลเป็นเทคโนโลยีเก่าแก่ที่เชื่อถือได้ เข้าใจง่าย และค้นหาได้ค่อนข้างง่าย
- แต่แบ็กเอนด์ของอีเมลนั้นยุ่งเหยิงมาก
ปัญหาของแบ็กเอนด์อีเมล
- ฟีเจอร์หลายอย่างของอีเมลไม่มีสเปกที่ชัดเจน ตัวอย่างเช่น เวลาเราส่งตอบกลับ ก็ไม่ชัดเจนว่าควรพิมพ์คำตอบไว้ด้านบนหรือด้านล่างของข้อความเดิม
- ไม่ชัดเจนว่าใส่ HTML แบบใดลงในอีเมลได้บ้าง บางครั้ง Microsoft Outlook ก็ใช้งานตัวเรนเดอร์ HTML ของ Microsoft Word แบบเกินเลย
- วิธีเข้ารหัสอีเมลก็ไม่ชัดเจนเช่นกัน มีการคิด OpenPGP ขึ้นมา แต่แทบไม่มีคนใช้ และมันก็มีข้อบกพร่องใหญ่
- เราไม่เคยตรวจสอบความแท้จริงของอีเมลได้เสมอไป จึงมีการคิด SPF ขึ้นมา แต่ SPF ก็ไม่ได้แก้ทุกปัญหา จากนั้นจึงมี DKIM แต่ DKIM ก็ยังแก้ไม่ได้ทั้งหมด แล้วจึงมี DMARC แต่ DMARC ก็ยังถูกเลี่ยงได้ เพราะตัว DKIM เองมีข้อบกพร่องสำคัญ
- ยังมีการเพิ่มอีกชั้นหนึ่งชื่อ BIMI ซึ่งก็พึ่งพา DMARC, DMARC พึ่งพา DKIM และ DKIM เองก็มีข้อบกพร่อง
- แม้จะมี DMARC อยู่แล้ว แต่ระเบียน 68.2% ก็ยังตั้งค่าเป็น
p=noneซึ่งหมายความว่าโดยพื้นฐานแล้ว DMARC ไม่ได้ทำอะไรเลย - ทั้งหมดที่กล่าวมาข้างต้น รวมถึงนโยบายป้องกันสแปมที่เข้มงวด ทำให้การโฮสต์อีเมลเองเป็นเรื่องยากมาก
- สุดท้ายยังมีเรื่องการจัดการชื่อเสียงของ IP ด้วย IP บางช่วง “สะอาด” กว่าช่วงอื่น โดยเฉพาะในระบบที่ใช้ร่วมกันอย่าง SendGrid หรือ AWS SES เรื่องนี้ทำให้การสมัครใช้บัญชีสำหรับส่งอีเมลจำนวนมากซับซ้อนขึ้น และอีเมลที่ถูกต้องก็มักถูกจัดเป็นสแปม
สมมติฐานเกี่ยวกับอีเมลยุคที่ 2
- สร้าง DNS record ใหม่ชื่อ
MX2บริการอีเมลส่วนใหญ่จะมีทั้งMX2และMXส่วนบริการเก่าจะมีแค่MX - หากไคลเอนต์อีเมลรุ่นเก่าอายุ 20 ปีพยายามส่งข้อความ มันจะค้นหา
MXrecord แล้วส่งข้อความ ขณะที่ไคลเอนต์สมัยใหม่จะดูMX2แล้วส่งข้อความ - บริการอีเมลที่รองรับ
MX2จะประกาศวันที่เผยแพร่ และหลังจากวันนั้น ข้อความทั้งหมดที่ส่งผ่านMXrecord จะถูกจัดเป็นสแปมโดยอัตโนมัติ
ลำดับความสำคัญของอีเมลยุคที่ 2
- จัดทำสเปก HTML แบบมาตรฐานสำหรับอีเมล พร้อม test suite สำหรับตรวจสอบความสอดคล้อง
- จัดเตรียม header สำหรับการตั้งค่าความชอบเกี่ยวกับเธรดอีเมล หรือค่ากำหนดอื่น ๆ ที่เกี่ยวข้องกับอีเมล
- จัดเตรียมสำเนาแบบข้อความล้วนที่ไม่ใช่ HTML ควบคู่ไปกับมุมมอง HTML
- ทุก
MX2record ต้องมี public key รวมอยู่ด้วย - สร้างแฮชเพื่อยืนยันความแท้จริงและความสมบูรณ์ของอีเมล จากนั้นเข้ารหัสแล้วเพิ่มไว้ใน header
- ตัด SPF, DKIM และ DMARC ออก แล้วทำให้เป็นมาตรฐานเดียวผ่าน
MX2record เพื่อทำให้สแตกอีเมลแบบโฮสต์เองง่ายขึ้น - ยืนยันตัวตนอีเมลตามโดเมน ไม่ใช่ตาม IP address
- ไคลเอนต์ที่รองรับ
MX2สามารถเลือกใช้สคีมการเข้ารหัสใหม่เพื่อแทนที่ OpenPGP ได้
ความคิดเพิ่มเติม
- จำเป็นต้องมีวิธีแชร์ไฟล์ขนาดใหญ่
- หาก Google และ Microsoft ไม่เข้าร่วม
MX2ก็คงไม่มีวันเกิดขึ้นจริง - อาจพิจารณาแทนที่ SMTP ด้วย HTTP, REST API แบบมาตรฐาน และ JSON body
- การใช้ HTML เองก็อาจเป็นประเด็นถกเถียงได้ แต่อีเมลเดิมไม่ได้ถูกออกแบบมาสำหรับ HTML
- นี่อาจเป็นโอกาสในการบังคับใช้มาตรฐานใหม่อย่างเข้มงวด
ความเห็นของ GN⁺
- ความพยายามในการแก้ปัญหาความซับซ้อนและปัญหาด้านความปลอดภัยของระบบอีเมลนั้นน่าสนใจมาก โดยเฉพาะการเสนอวิธีใหม่เพื่อรับประกันความแท้จริงและความสมบูรณ์ของอีเมล ซึ่งน่าจะเป็นประโยชน์
- อย่างไรก็ตาม การนำมาตรฐานใหม่มาใช้เป็นเรื่องยากมาก โดยเฉพาะเมื่อจำเป็นต้องได้รับความร่วมมือจากผู้เล่นรายใหญ่อย่าง Google และ Microsoft
- ประเด็นถกเถียงเรื่องการใช้ HTML ยังคงมีอยู่ อาจจำเป็นต้องพิจารณาภาษามาร์กอัปแบบอื่นเพื่อแก้ปัญหาด้านความปลอดภัย
- การบังคับใช้มาตรฐานใหม่อย่างเข้มงวดเป็นเรื่องในอุดมคติ แต่ในความเป็นจริงอาจทำได้ยาก จำเป็นต้องมีกลไกเพิ่มเติมเพื่อป้องกันการเบี่ยงเบนจากมาตรฐานและข้อผิดพลาดในการนำไปใช้
- การรวมศูนย์ของระบบอีเมลอาจช่วยให้การนำมาตรฐานใหม่มาใช้ทำได้ง่ายขึ้น แต่ในขณะเดียวกันก็อาจเพิ่มการพึ่งพาบริษัทบางแห่ง
8 ความคิดเห็น
อย่างน้อยในแง่ของการปรับปรุงการเรนเดอร์ Google และ Microsoft ก็ได้ลงทุนไปแล้ว... เพราะทั้งคู่เข้าร่วมและสนับสนุนโครงการ AMP Email
การสร้างมาตรฐานข้อมูลแบบ
JSONเป็นเรื่องที่ดีครับแต่เพราะต้องมีการหารือเรื่องสเปกการเรนเดอร์ไปพร้อมกันด้วย เลยดูเหมือนว่าจะไม่ง่ายนัก
เหตุผลที่เลือก
HTMLก็คงไม่ใช่เพื่ออาศัยสเปกการเรนเดอร์ของ
HTML+CSSไปด้วยหรอกหรือ?ท่านข้างบนได้ยกกรณีสุดโต่งอย่าง Shop Mail ขึ้นมาพูดกันไปแล้วนะครับ ส่วนตัวแล้วผมค่อนข้างกังขาอย่างมากกับการที่เอาโปรโตคอลซึ่งใช้งานได้ดีอยู่แล้วไปจัดว่าเป็น "deprecated" แบบโจ่งแจ้ง แล้วทำให้รองรับได้เฉพาะมาตรฐานโปรโตคอลใหม่บางอย่างที่ไม่เข้ากันเท่านั้น
ดังนั้นพวกเราจึงสร้าง Sapp Mail... (หือ? ไม่ใช่อันนั้น...)
ระบบอีเมลนั้นสะดวกและดีอยู่หรอก แต่ก็ทำให้รู้สึกว่าจำเป็นต้องมีการปรับปรุงโปรโตคอลแบบค่อยเป็นค่อยไปจริง ๆ
อีกไม่กี่สิบปีข้างหน้า ถ้ายังใช้งานกันด้วยวิธีนี้อยู่ก็คงจะ...
ความคิดเห็นใน Hacker News
สรุปความคิดเห็นจากคอมเมนต์ใน Hacker News
ความซับซ้อนและการทำงานร่วมกันได้ของระบบอีเมล
ความกำกวมและปัญหาของอีเมล
ปัญหาการรวมศูนย์ของอีเมล
ปัญหาของอีเมล HTML
ความจำเป็นในการคงความเป็นอะซิงโครนัสของอีเมล
ความยากในการดูแลเซิร์ฟเวอร์อีเมล
นิยามของอีเมลที่ชอบธรรม
ความจำเป็นในการปรับปรุงระบบอีเมล
เช็กลิสต์ไอเดียป้องกันสแปม
เช็กลิสต์ไอเดียป้องกันสแปม