Mozilla Thunderbird เพิ่มการรองรับ Exchange แบบเนทีฟ

 (blog.thunderbird.net)
1 คะแนน โดย GN⁺ 2024-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Microsoft Exchange ซึ่งถูกใช้อย่างแพร่หลายในองค์กรและสถาบันการศึกษา จะได้รับการรองรับแบบเนทีฟใน Thunderbird ตั้งแต่ ESR เดือนกรกฎาคม 2024 โดยขอบเขตแรกจำกัดเฉพาะอีเมล
  • งานครั้งนี้ไม่ใช่แค่การรองรับ Exchange Web Services(EWS) แต่ยังเป็นจุดเริ่มต้นของการค่อย ๆ สะสางข้อจำกัดของสถาปัตยกรรมโปรโตคอลเมลที่สืบต่อมากว่า 20 ปีและโค้ด C++ รุ่นเก่า
  • ภาษาที่เลือกใช้ในการพัฒนาคือ Rust โดยเหตุผลหลักคือความปลอดภัยด้านหน่วยความจำ ประสิทธิภาพแบบเนทีฟ ความเป็นโมดูล และการใช้ CI ร่วมกับ Firefox รวมถึงการทำงานร่วมกับ XPCOM
  • ระหว่างการผสาน EWS ได้มีการสร้าง crate อย่าง xpcom_async, moz_http, xml_struct, ews เพื่อห่อการเรียก HTTP แบบ XPCOM และการซีเรียลไลซ์ XML ให้ใช้งานได้สะดวกใน Rust
  • แม้ EWS จะ ไม่สามารถใช้งานบน Exchange Online ได้หลังเดือนตุลาคม 2026 แต่ยังคงจำเป็นสำหรับ Thunderbird เพราะยังมีผู้ใช้ Exchange Server แบบ on-premises จำนวนมาก

ขอบเขตการรองรับ Exchange ใน ESR เดือนกรกฎาคม 2024

  • Thunderbird มีแผนจะรองรับ Exchange แบบเนทีฟใน ESR(Extended Support) รุ่นถัดไป เดือนกรกฎาคม 2024
  • ขอบเขตเริ่มต้นจำกัดอยู่ที่ อีเมล
    • การรองรับปฏิทินและสมุดที่อยู่จะถูกเพิ่มตามมาในภายหลัง
    • จนกระทั่งไม่นานมานี้ ความสามารถด้าน Exchange ใช้งานได้ผ่านแอดออนเท่านั้น
  • เป้าหมายของการพัฒนาคือ API Exchange Web Services(EWS) ของ Microsoft
    • EWS ทำงานบน HTTP
    • เนื้อหาของคำขอและคำตอบใช้ XML

ภาระของสถาปัตยกรรมเมลที่มีอายุกว่า 20 ปี

  • สถาปัตยกรรมโปรโตคอลเมลปัจจุบันของ Thunderbird มีรากฐานมาจากโค้ดที่เก่ากว่า Thunderbird เอง
    • พัฒนามาตั้งแต่กว่า 20 ปีก่อนในฐานะส่วนหนึ่งของ Netscape Communicator
    • หลัง Mozilla โอนความเป็นเจ้าของ Thunderbird ให้ชุมชนในปี 2012 ก็ไม่มีผู้ดูแลแบบได้รับค่าจ้าง จนกระทั่งกลับมาอยู่กับ Mozilla Foundation อีกครั้งในปี 2017
  • การเปลี่ยนแปลงชั่วคราวที่สะสมมาโดยไม่มีทิศทางสถาปัตยกรรมใหญ่ ทำให้ยังมี โค้ด C++ จำนวนมากที่ไม่ได้ใช้มาตรฐานสมัยใหม่
  • ตลอด 20 ปีของโครงการ Thunderbird ไม่เคยมีการเพิ่มการรองรับโปรโตคอลเมลใหม่เลย
    • ขณะที่โปรโตคอลเมลเปลี่ยนไปตามรูปแบบการใช้งานยุคใหม่ โครงสร้างที่เกี่ยวข้องกลับไม่ได้รับการอัปเดต
    • ความรู้เชิงสถาบันจำนวนมากก็สูญหายไปแล้ว
  • การรองรับ Exchange คือความพยายามแบบ ขับเคลื่อนโดยองค์กร ครั้งแรกในการทำความเข้าใจข้อจำกัดของสถาปัตยกรรม Thunderbird และแก้ไขอย่างค่อยเป็นค่อยไป

เหตุผลที่เลือก Rust

  • Rust ถูกเลือกเป็นภาษาในการพัฒนาการรองรับโปรโตคอลใหม่ของ Thunderbird
  • เหตุผลของการเลือกมีทั้งข้อดีทั่วไปของ Rust และเงื่อนไขเฉพาะของ Thunderbird
    • ความปลอดภัยด้านหน่วยความจำ: Thunderbird รับอินพุตจากทุกคนที่สามารถส่งอีเมลมาได้ จึงสำคัญมากที่จะลดบั๊กด้านความปลอดภัย
    • ประสิทธิภาพ: Rust รันเป็นโค้ดเนทีฟ
    • ความเป็นโมดูลและอีโคซิสเต็ม: สามารถใช้ประโยชน์จากโครงสร้างแบบโมดูลและอีโคซิสเต็มที่เกี่ยวกับอีเมลของ Rust ได้
  • Thunderbird สร้างอยู่บนโค้ดของ Firefox จึงมีความพร้อมในการใช้ Rust อยู่แล้ว
    • โครงสร้าง CI ที่ใช้ร่วมกับ Firefox รองรับ Rust
    • ผ่านชั้นทำงานร่วมกันของ XPCOM(Cross-Platform Component Object Model) จาก Firefox ทำให้ Rust, C++, JavaScript เรียกข้ามกันได้
  • type และเครื่องมือของ Rust ช่วยให้สร้าง API ที่ใช้งานผิดได้ยาก
    • เช่น ช่วยหลีกเลี่ยง circular reference หรือสร้างฟังก์ชันที่ไม่สามารถถูกเรียกด้วยค่าที่ไม่มีความหมายได้
    • เครื่องมือจัดทำเอกสารถูกรวมมาในภาษาโดยตรง จึงเป็นประโยชน์กับทีมขนาดเล็ก
  • หากสร้างเป็น crate แบบโมดูล ก็สามารถนำกลับไปใช้ซ้ำในโครงการอื่น เช่น Thunderbird for Android/K-9 Mail ได้

ระบบบิลด์และข้อจำกัดของ XPCOM

  • ตอนนำคอมโพเนนต์ Rust ตัวแรกมารันใน Thunderbird นั้น ระบบบิลด์ คืออุปสรรคแรก
  • Thunderbird ไม่ได้มีโครงสร้างแบบพ่วงเข้ากับโค้ด Firefox เหมือน dependency ปกติ
    • ระหว่างบิลด์จะดึงโค้ด Firefox มา
    • นำโค้ด Thunderbird เข้าไปเป็น subtree ของ Firefox
    • แล้วชี้ไปยัง subtree นั้นด้วยไฟล์ตั้งค่าการบิลด์
  • Firefox รวบรวม crate แต่ละตัวเข้าเป็น Cargo workspace เดียว เพื่อสร้างกราฟ dependency ของ Cargo ทั้งต้นไม้
    • Thunderbird เองก็ต้องมี Cargo workspace ของตัวเอง แต่ Cargo ไม่อนุญาตให้มี workspace ซ้อนกัน
    • วิธีแก้คือกำหนด workspace ของ Thunderbird เอง และตั้งค่าให้เครื่องมือบิลด์ระดับบน mach บิลด์ workspace นี้แทนของ Firefox
    • มีการเพิ่มคำสั่งย่อยใหม่ของ mach เพื่อซิงก์ dependency และ lockfile กับต้นทาง และทำ vendoring ของผลลัพธ์แบบ superset
  • XPCOM ถูกออกแบบโดยยึด C++ เป็นศูนย์กลาง ทำให้ประสบการณ์พัฒนา Rust ไม่ลื่นไหลนัก
    • การ implement และใช้งานอินเทอร์เฟซ XPCOM ต้องมี boilerplate จำนวนมาก
    • ใช้เครื่องมืออย่าง rust-analyzer ได้ไม่เต็มที่
    • Firefox ลดการพึ่งพา XPCOM ลงไปมากแล้ว แต่ Thunderbird ไม่ได้มีโอกาสสะสางแบบเดียวกันในช่วงที่ขาดการบำรุงรักษา
  • การรองรับโปรโตคอลเมลใหม่ต้อง implement ฟังก์ชันหลายร้อยตัวที่นิยามไว้ใน XPCOM
    • การ implement โปรโตคอลเดิมลดภาระด้วยการสืบทอดคลาส C++ ที่ให้พฤติกรรมร่วมกัน
    • แต่ใน Rust ไม่สามารถทำแบบนั้นได้ตรง ๆ จึงต้อง implement logic เฉพาะโปรโตคอลไว้ใน Rust
    • คลาส bridge ฝั่ง C++ จะเชื่อม crate ภายใน ews_xpcom เข้ากับโค้ดพฤติกรรมร่วมที่มีอยู่เดิม
  • วิธีสร้างคอมโพเนนต์ Rust ใน Thunderbird ถูกรวบรวมไว้ในเอกสาร

การจัดการคำขอ HTTP ให้เป็นสไตล์ Rust

  • Firefox มี HTTP stack อยู่แล้วผ่านคอมโพเนนต์เครือข่าย necko
  • necko เขียนด้วย C++ และเปิดให้ใช้ผ่าน XPCOM ทำให้การใช้โดยตรงจาก Rust ต้องมี boilerplate มาก
    • แม้แต่คำขอ GET แบบง่ายก็ยังต้องสร้างออบเจ็กต์ XPCOM หลายตัว
    • XPCOM จัดการอายุการใช้งานของ pointer แต่คอมไพเลอร์ Rust ไม่รู้เรื่องนี้ จึงต้องใช้บล็อก unsafe
    • อินเทอร์เฟซที่ต้องใช้เป็นแบบ callback
  • crate ภายในของ Thunderbird ชื่อ xpcom_async จะแปลงงาน asynchronous ของ XPCOM ให้เป็นไวยากรณ์ async/await ของ Rust
    • มันจะ buffer ข้อมูลที่เข้ามาผ่าน callback
    • implement trait Future ของ Rust เพื่อให้ฝั่งเรียกใช้ await ได้
    • Future ของ Rust มีลักษณะคล้าย Promise ของ JavaScript หรือ coroutine ของ Python
  • crate ภายใน moz_http ให้ HTTP client ที่ได้แรงบันดาลใจจาก reqwest
    • มันจัดการการสร้างออบเจ็กต์ XPCOM ที่จำเป็นให้
    • และให้การจัดการข้อผิดพลาดแบบสไตล์ Rust ที่ดีกว่ารูปแบบมาตรฐานของ XPCOM

XML serialization ของ EWS และ crate ใหม่

  • งานที่ยากที่สุดของ EWS คือการแปลงระหว่างโครงสร้างข้อมูลภายในของ Thunderbird กับ XML ที่ EWS ต้องการหรือส่งกลับมา
  • crate เดิมสำหรับ XML serialization/deserialization ไม่สามารถตอบโจทย์ได้
    • data model ของ serde ไม่เข้ากับ XML มากนัก ทำให้แยกแยะ attribute กับ element ได้ยาก
    • EWS ไวต่อ XML namespace แต่แนวคิดนี้ไม่คุ้นเคยในโลก serde
    • crate ตระกูล serde สำหรับ XML ต้องให้ใส่ annotation ระบุวิธี serialize ของทุกฟิลด์อย่างชัดเจน
    • EWS นิยาม type หลายร้อยตัว และแต่ละ type ก็มีฟิลด์อีกหลายสิบรายการ ทำให้ boilerplate มากเกินรับไหว
  • implementation เดิมที่อิง serde เพียงพอสำหรับการ deserialize XML มาเป็น Rust แต่ยังไม่พบเครื่องมือ serialize ที่น่าพอใจ
  • crate ใหม่ xml_struct ให้ trait สำหรับนิยามพฤติกรรม XML serialization และ procedural derive macro
    • มันสร้าง implementation ของ trait ให้กับโครงสร้างข้อมูล Rust โดยอัตโนมัติ
    • สร้างอยู่บน crate quick_xml เดิม
    • ตั้งเป้าไปที่การแมประหว่าง XML กับ Rust ที่มี boilerplate น้อย
    • ไม่พึ่งพาภายในของ Thunderbird/Firefox และยังอยู่ในช่วงพัฒนาเริ่มต้น
  • crate ใหม่ ews นิยาม type สำหรับงาน EWS และ API สำหรับ XML serialization/deserialization
    • สร้างบน xml_struct และ serde
    • ยังอยู่ในช่วงพัฒนาเริ่มต้น และเปิดสาธารณะบน GitHub แล้ว

แผนการทดสอบ การจัดการข้อผิดพลาด และการเชื่อมต่อ UI

  • ขณะนี้กำลังเสริม การทดสอบอัตโนมัติ ก่อนเพิ่มความสามารถหลักถัดไป
    • นอกจาก unit test แล้ว ยังเพิ่ม mock EWS server สำหรับ integration test ด้วย
    • ระหว่างการเสริมการทดสอบ พบและแก้ไข crash หลายจุดกับปัญหา double-sync แล้ว
    • ทำให้สามารถทดสอบและตรวจสอบความสามารถใหม่ได้ง่ายขึ้น
  • การจัดการข้อผิดพลาดของ EWS กำลังได้รับการปรับปรุง
    • พฤติกรรมข้อผิดพลาดของ EWS หลายกรณียังมีเอกสารไม่เพียงพอ
    • ทั้งคำขออาจล้มเหลวได้เพราะ throttling หรือโครงสร้างไม่ถูกต้อง
    • บางส่วนของคำขออาจสำเร็จ ขณะที่บางส่วนล้มเหลวเพราะ ID ไม่ถูกต้อง
    • ข้อผิดพลาดบางอย่างจัดการได้ในระดับโปรโตคอล แต่บางอย่างอาจต้องให้ผู้ใช้เข้ามาเกี่ยวข้องหรือแก้ไขได้ยาก
  • การรองรับโปรโตคอล EWS กำลังถูกขยายผ่าน crate ews และ crate ภายใน ews_xpcom พร้อมเชื่อมเข้ากับ UI ของ Thunderbird
    • แพตช์ล่าสุดทำให้สามารถเพิ่มบัญชี EWS เข้าใน Thunderbird ได้
    • สามารถซิงก์ลำดับชั้นโฟลเดอร์ของบัญชีจากเซิร์ฟเวอร์ระยะไกลได้
    • และแสดงโฟลเดอร์ที่ซิงก์แล้วใน UI ได้
    • ขณะนี้ความสามารถระดับอัลฟ่านี้ยังถูกซ่อนไว้หลัง build flag และค่าตั้งค่า
  • งานถัดไปคือความสามารถในการดึงรายการข้อความจากเซิร์ฟเวอร์ระยะไกล และการทำให้การรองรับอีเมลขาออกของ Thunderbird เป็นแบบทั่วไปมากขึ้น
  • เพื่อการบำรุงรักษา ทีมกำลังจัดทำเอกสารว่าคอมโพเนนต์แต่ละส่วนประกอบกันอย่างไร รวมถึงสถาปัตยกรรมโปรโตคอลเมลเดิมของ Thunderbird และทิศทางการปรับปรุงในอนาคต

ความสัมพันธ์ระหว่าง EWS กับ Microsoft Graph

  • EWS จะ ไม่สามารถใช้งานบน Exchange Online ได้หลังเดือนตุลาคม 2026
  • การสำรวจก่อนเริ่มโครงการพบว่ายังมีผู้ใช้จำนวนมากที่ใช้ Exchange Server แบบ on-premises ต่อไป
    • หลายองค์กรและสถาบันการศึกษายังรัน Exchange Server บนฮาร์ดแวร์ของตนเอง
    • การติดตั้งแบบ on-premises เหล่านี้โดยทั่วไปยังรองรับ EWS
    • แต่ไม่สามารถรองรับ Graph API ที่อิง Azure ได้
  • การรองรับ EWS จึงเป็นวิธีรองรับผู้ใช้กลุ่มนี้ในอนาคตอันใกล้
  • Graph API เองก็ยังมีปัญหาบางอย่างที่ยังไม่คลี่คลาย
    • Graph API ถูกออกแบบโดยคำนึงถึงบริการบนเว็บมากกว่าแอปเดสก์ท็อป
    • การเพิ่ม EWS ก่อนช่วยให้มีเวลาในการหาทางออกให้ปัญหาเหล่านั้น ก่อนจะทำการรองรับ Graph API
  • งานด้าน Rust และ EWS เป็นส่วนหนึ่งของความพยายามที่ใหญ่กว่านี้ เพื่อให้ Thunderbird พลิกฟื้น ลดเวลา turnaround และเพิ่มความยืดหยุ่นของแกนหลักของซอฟต์แวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-21
ความคิดเห็นบน Hacker News

  • ในเมื่อ EWS มีกำหนดถูกยกเลิก และจะถูกถอดออกในอีก 2 ปีแล้ว ไม่เข้าใจว่าทำไมถึงยังนำมาพัฒนา: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS เป็นวิธีเดียวที่ใช้งานได้จริงสำหรับให้ ไคลเอนต์ที่ไม่ใช่ Outlook ทำงานได้ ส่วน MAPI ก็ไม่ได้เป็น API แบบเปิดอะไรนัก
      ถ้า EWS หายไป ลูกค้าก็น่าจะย้ายออกไปไม่น้อย และช่วงแรกอาจยังไม่ถึงขั้นกระทบผลประกอบการของ Microsoft
      แต่สุดท้ายความจริงที่ว่าอีเมลทั้งหมดมีค่าเท่ากันก็จะปรากฏ และ Exchange Online อาจกลายเป็นเพียงเชิงอรรถในประวัติศาสตร์ได้ Microsoft ทำอีเมลแล้วพังหนัก ซึ่งมองเผิน ๆ ก็ชวนเขินอยู่บ้าง แต่ในความเป็นจริงอาจไม่ได้เป็นแบบนั้นเสมอไป
      การดูแลระบบอีเมลเป็นเรื่องเจ็บปวด และสิ่งที่ Microsoft ต้องการจริง ๆ ก็มีแค่ ข้อมูลและเมทาดาทา ที่ขุดออกมาแล้วเอาไปขายให้พวกหมกมุ่นกับข้อมูลรายอื่นได้เท่านั้น อีเมลโดยทั่วไปค่อนข้างนิ่งและมีขนาดใหญ่เมื่อวัดตามพื้นที่จัดเก็บ แต่ในการแลกเปลี่ยนระหว่างบุคคลอาจมีขุมทองซ่อนอยู่
      ทางที่ดีที่สุดคือให้เจ้าอย่าง AWS, Google รับความเจ็บปวดนั้นไป แล้วทำให้ลูกค้าใช้ Outlook จากนั้นก็เปลี่ยนให้เก็บข้อมูลรับรองไว้บนคลาวด์ของ Microsoft เหมือน Outlook เวอร์ชัน Electron ใหม่ และใช้ข้อมูลรับรองนั้นขุดข้อมูลอีเมลที่อยู่บนคลาวด์ของคนอื่น โดยให้ฝั่งนั้นแบกรับต้นทุนพื้นที่จัดเก็บไป ยอดเยี่ยมมาก
    • อย่างที่ Sean Burke กล่าวไว้ในบั๊ก Bugzilla ที่เกี่ยวข้อง ตอนนี้ EWS เป็นวิธีที่ดีที่สุดในการรองรับทั้ง Exchange Online และการติดตั้งแบบ on-premises: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API ก็เคยถูกพิจารณาแล้ว และอาจถูกพิจารณาอีกในอนาคต แต่ตอนนี้ยังครอบคลุมการรองรับได้น้อยกว่า EWS และขาดฟีเจอร์บางอย่างที่จำเป็นสำหรับแอปพลิเคชันเดสก์ท็อป
      แม้จะมีประกาศว่าจะถอดการรองรับ EWS ออกจาก Exchange Online แต่ในระยะสั้นมันยังมีคุณค่าในการเปิดทางให้ผู้ใช้จำนวนมากเข้าถึงได้ และในระยะยาวก็ยังช่วยรองรับผู้ใช้ที่ติดตั้งแบบ on-premises
    • เพราะเมื่อต้องรับมือกับอะไรอย่าง Exchange ในช่วงนี้แทบไม่มี ทางเลือกอื่นที่ใช้งานได้จริง เลย
    • ไม่ใช่ทุกคนที่ใช้ Exchange Online

  • ถ้าเป้าหมายเป็นแค่การเพิ่มจำนวนผู้ใช้ Thunderbird ในเชิงกลยุทธ์ก็พอสมเหตุสมผล แต่ในเชิงอุดมการณ์แล้ว การรองรับ JMAP ดูดีกว่ามาก

    • งานส่วนใหญ่ที่ทำสำเร็จในครั้งนี้น่าจะเป็นหัวใจสำคัญในการเพิ่ม การรองรับ JMAP ในอนาคตด้วย

  • ช่วงหลังได้ลองใช้ Thunderbird แทน Outlook แล้วเจอปัญหาแบบเดียวกับ Firefox ก่อนอัปเดต Quantum คือช้ามาก
    เวลาเปลี่ยนไปมาระหว่างโฟลเดอร์ที่มีอีเมลหลักร้อยถึงหลักพันฉบับ จะมีดีเลย์ที่เห็นได้ชัด ขณะที่ Outlook แทบจะเปลี่ยนได้ทันที

    • ถ้าใช้ Windows จากประสบการณ์ของผม Thunderbird แทบใช้ไม่ได้เลยจนกว่าจะเพิ่ม โปรไฟล์ Thunderbird เข้าเป็นข้อยกเว้นของ Windows Defender
    • ประสบการณ์ของผมตรงกันข้ามโดยสิ้นเชิง การใช้ Outlook กับอีเมลเป็นเรื่องทรมานมาก โดยเฉพาะการค้นหาที่ทำงานไม่ดี ผมใช้ expressionsearchNG ใน Thunderbird
      ส่วนปฏิทินกลับเป็นอีกเรื่อง ตอนนี้เลยต้องเปิดทั้งสองตัวคู่กัน ปัญหาหนึ่งน่าจะเป็น iCal bridge ไปยังเซิร์ฟเวอร์ Outlook ที่บริษัทบังคับให้ใช้
      ประกาศครั้งนี้น่าเสียดายที่ไม่ได้เปลี่ยนส่วนนั้น ผมเคยใช้แอดออน EWS ที่ Ericsson ดูแลอยู่ช่วงหนึ่ง: https://github.com/Ericsson/exchangecalendar
      แต่ดูเหมือนว่า Mozilla ทำให้อินเทอร์เฟซพังเร็วเกินไป จนทำให้นักพัฒนาปลั๊กอินจำนวนมากจากไป ตอนนี้กลับมาใส่ฟีเจอร์บางส่วนไว้ในคอร์อีกครั้ง ซึ่งผมไม่แน่ใจว่าเป็นกลยุทธ์ที่ดีหรือไม่ ผมคิดว่าควรโฟกัสที่ อินเทอร์เฟซที่เสถียร มากกว่า

  • ไม่ชอบ Exchange แต่ดีใจที่มีงานนี้ อย่างน้อยตอนนี้แม้จะติดอยู่กับ Windows ก็อาจ ส่งอีเมลข้อความล้วนจาก Exchange ได้สำเร็จเสียที

    • ถ้าทำแบบนั้น อีเมลอาจดูแย่ลงมากในไคลเอนต์อีเมลหลายตัวเพียงเพราะความเคร่งครัดทางเทคนิคหรือความโหยหาอดีต
      หลังจากเห็นว่าอีเมลข้อความล้วนถูกเรนเดอร์ด้วย ฟอนต์ monospace แทนที่จะเป็นวิธีที่เหมาะสมกว่านั้นบ่อยแค่ไหน ผมก็รู้สึกว่ายากจะอ้างเหตุผลให้ใช้ข้อความล้วนเพียงเพราะ “อีเมล HTML เป็นสิ่งน่ารังเกียจ”

  • คำพูดที่ว่า “ตลอดประวัติศาสตร์ 20 ปีของโครงการ Thunderbird ไม่เคยมีใครเพิ่มการรองรับโปรโตคอลเมลใหม่เลย” นั้นถูกต้องในเชิงเทคนิค แต่บริษัทยักษ์ใหญ่แต่ละแห่งต่างก็ต้องมีการตั้งค่าเฉพาะต่อไคลเอนต์อีเมลแต่ละตัว หรือก็คือวิธีเลี่ยง สำหรับการทำ OAuth2 out-of-band authentication และ Thunderbird ก็สะสมของพวกนั้นไว้ไม่น้อย
    สิ่งเหล่านี้ไม่ใช่โปรโตคอลเมลทั่วไป ไม่ใช่ IMAP, POP3, SMTP แต่ทำงานอยู่บน HTTPS
    การที่ “ไม่เคยเพิ่มโปรโตคอลเมลใหม่” เป็นเรื่องดี และการเปลี่ยนแปลงครั้งนี้ไม่ดี การรองรับการตั้งค่าแบบ proprietary นั้นใช้งานได้จริงและเข้าใจได้ แต่ไม่ใช่เรื่องดี
    มันแค่บรรเทาปัญหาที่อีเมลแตกออกเป็นรูปแบบย่อยเฉพาะบริษัทนับสิบแบบชั่วคราว และในระยะยาวกลับจะยิ่งกระตุ้นให้ผู้คนยอมรับรูปแบบย่อยเหล่านั้น

    • พนักงานเลือกผู้ให้บริการอีเมลของบริษัทไม่ได้ และสำหรับคน 99.99999% เรื่องนี้ไม่ใช่เนินที่ควรยอมตายเพื่อปกป้อง
      ในทางกลับกัน การทำให้ใช้ Thunderbird เป็นไคลเอนต์ได้ เป็นผลดีสุทธิและเป็นทางเลือกที่ใช้งานได้จริง
    • ไม่ใช่แค่หนึ่งในบริษัทยักษ์ใหญ่ แต่คือ Microsoft Exchange ซึ่งเป็นระบบที่ใช้กันแพร่หลายที่สุดอย่างท่วมท้นในอีเมลสำหรับงาน โดยเฉพาะ Exchange Online

  • ไม่เข้าใจว่าทำไมถึงเปลี่ยนชื่อเรื่อง บทความนี้เป็นบทความเกี่ยวกับ การเขียนโปรแกรมด้วย Rust
    “Bringing Exchange Support to Thunderbird” ดูเหมือนจะเป็นบทความเกี่ยวกับ Thunderbird และการรองรับ Exchange แต่เนื้อหานั้นไม่ใช่สิ่งที่จะรู้ได้จากบทความนี้

    • ย่อหน้าแรกของบทความเน้น Exchange มากกว่าภาษา ดังนั้น ตัวฟีเจอร์เอง จึงดูสำคัญกว่าการใช้งานภายใน ผู้ใช้ส่วนใหญ่ก็น่าจะสนใจเรื่องนั้นมากกว่า
    • เคยโพสต์บทความเดียวกันด้วยชื่อเต็มไปก่อนหน้านี้แล้ว แต่ไม่ได้รับความสนใจ: https://news.ycombinator.com/item?id=40095870
    • ไม่เข้าใจว่าพูดอะไร ช่วงครึ่งหลังทั้งหมดของบทความเป็นเรื่องเกี่ยวกับ การรองรับ Exchange ของ Thunderbird

  • การรองรับสเปกแบบ proprietary น่าจะมีประโยชน์ก็จริง แต่หวังว่า Mozilla จะให้ความสำคัญกับ การทำตามมาตรฐาน อย่างการค้นพบอัตโนมัติของเซิร์ฟเวอร์ส่งอีเมล (SMTP) ก่อน ตัวอย่างเช่น rfc6186 ออกมาตั้งแต่ปี 2011
    ตอนนี้ผู้ใช้ต้องกรอกชื่อโฮสต์และพอร์ตของเซิร์ฟเวอร์ SMTP เอง ซึ่งอาจโอเคสำหรับคนในเว็บนี้ แต่ไม่เป็นมิตรกับมนุษย์อีก 99.9% เลย
    ความพยายามที่ต้องใช้ในการทำ Exchange ทั้งชุดน่าจะมากกว่าการค้นพบเซิร์ฟเวอร์ส่งผ่าน DNS/SRV หลายลำดับขั้นด้วยซ้ำ ไม่เข้าใจลำดับความสำคัญของ Mozilla จริง ๆ

    • ตอนเพิ่มบัญชี Hotmail, Google, Yahoo ใน Thunderbird ผมว่าไม่ได้กรอกข้อมูลพวกนั้นนะ แค่ใส่อีเมลแต่ละอันเท่านั้น
      พวกนี้ถูกจัดการเป็น กรณีพิเศษ หรือเปล่า?

  • ว้าว ทำให้นึกถึงตอนทำงาน IT เมื่อราว 20 ปีก่อน สภาพแวดล้อมแทบทั้งหมดเป็น Microsoft มีแค่ไม่กี่คนที่ใช้ Linux
    Exchange เป็นหนึ่งในสิ่งที่หาลูกข่ายดี ๆ ได้ยากเสมอ และถ้าตอนนั้นมีสิ่งนี้ คง ดีใจจนตัวลอย แน่ ๆ

    • ตอนนี้ก็ยังดีใจจนตัวลอย
      การใช้ผลิตภัณฑ์ Microsoft บน Linux นี่เจ็บปวดจริง ๆ โดยเฉพาะถ้าไม่ใช้ Edge ก็ดูเหมือนว่า Teams เวอร์ชันเว็บ กำลังถูกเข้าสู่กระบวนการเลิกใช้งานแล้ว :(
    • เราก็มีปัญหาเดียวกัน แต่เลือกอีกทางหนึ่ง ทำให้บริษัท เลิกใช้ Exchange กับ SharePoint ได้ และหลังจากนั้นก็มีความสุขขึ้นมาก

  • เรื่องที่ว่า “ราวปี 2012 Mozilla ปล่อยมือจาก Thunderbird และส่งต่อความเป็นเจ้าของให้ชุมชน หลังจากนั้นไม่มีการบำรุงรักษาแบบจ้างงานจนกว่า Thunderbird จะกลับเข้าร่วม Mozilla Foundation อีกครั้งในปี 2017” นี่เป็นเรื่องอื้อฉาวจริง ๆ
    เป็นตัวอย่างเด่น ๆ ที่แสดงให้เห็น ลำดับความสำคัญที่กลับหัวกลับหาง ของ Mozilla

    • ไม่เห็นด้วย โลกย้ายไปสู่เมลแบบ เว็บ/แอปมือถือ แล้ว
      คุณอาจไม่ชอบเรื่องนั้น และผมเองก็ไม่ได้ดีใจมากมายเหมือนกัน แต่ก็เป็นความจริง และไม่คุ้มที่ Mozilla จะลงเงินสนับสนุน

  • อยากให้มี การนำเข้าไฟล์ PST มาให้โดยค่าเริ่มต้น เพื่อให้คนที่อยากย้ายออกจากการติดตั้ง Outlook สามารถเปลี่ยนผ่านได้อย่างราบรื่นโดยไม่ต้องไปยุ่งกับ Outlook เอง
    มีโปรเจกต์ฟรีที่อ่านไฟล์ PST ได้อยู่แล้ว แค่ต้องเอามารวมเข้ากับชุดผลิตภัณฑ์เท่านั้น

    • การส่งออก PST ด้วยโมดูล Exchange สำหรับ PowerShell มีมาตั้งแต่ Exchange 2010 แล้ว ดู “New-MailboxExportRequest” ได้ที่: https://learn.microsoft.com/en-us/powershell/module/exchange...
      แก้ไข: อ้อ ไม่ใช่สิ ใช้ได้เฉพาะ on-premises นี่มันโง่มากจริง ๆ