Mozilla Thunderbird đưa hỗ trợ Exchange native vào sản phẩm

 (blog.thunderbird.net)
1 điểm bởi GN⁺ 2024-04-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Thunderbird dự kiến sẽ hỗ trợ native Microsoft Exchange, vốn được dùng rộng rãi trong doanh nghiệp và cơ sở giáo dục, từ ESR tháng 7/2024; phạm vi đầu tiên chỉ giới hạn ở email
  • Công việc lần này không chỉ hỗ trợ Exchange Web Services(EWS), mà còn là cơ hội để từng bước xử lý các giới hạn của kiến trúc giao thức mail đã tồn tại hơn 20 năm và mã C++ cũ
  • Rust được chọn làm ngôn ngữ triển khai, với các lý do chính là an toàn bộ nhớ, hiệu năng native, tính mô-đun, CI dùng chung với Firefox và khả năng tương tác XPCOM
  • Trong quá trình tích hợp EWS, các crate như xpcom_async, moz_http, xml_struct, ews đã được tạo ra, bao bọc các lệnh gọi HTTP dựa trên XPCOM và tuần tự hóa XML theo cách thân thiện với Rust
  • EWS sẽ không còn dùng được trên Exchange Online sau tháng 10/2026, nhưng do vẫn còn nhiều người dùng Exchange Server tại chỗ, đây vẫn là hỗ trợ cần thiết cho Thunderbird

Phạm vi hỗ trợ Exchange trong ESR tháng 7/2024

  • Thunderbird dự kiến cung cấp hỗ trợ Exchange native trong bản ESR(Extended Support) tiếp theo, phát hành vào tháng 7/2024
  • Phạm vi ban đầu chỉ giới hạn ở email
    • Hỗ trợ lịch và sổ địa chỉ sẽ được bổ sung sau
    • Cho đến gần đây, các tính năng Exchange chỉ có thể dùng thông qua add-on
  • Đối tượng triển khai là API Exchange Web Services(EWS) của Microsoft
    • EWS hoạt động trên HTTP
    • Phần thân request và response dùng XML

Gánh nặng từ kiến trúc mail hơn 20 năm tuổi

  • Kiến trúc giao thức mail hiện tại của Thunderbird dựa trên mã còn cũ hơn cả Thunderbird
    • Được phát triển hơn 20 năm trước như một phần của Netscape Communicator
    • Sau khi Mozilla chuyển quyền sở hữu Thunderbird cho cộng đồng vào năm 2012, đã không có bảo trì có trả lương cho đến khi dự án gia nhập lại Mozilla Foundation vào năm 2017
  • Khi các thay đổi tạm thời tích tụ mà không có định hướng kiến trúc lớn, còn lại nhiều mã C++ không dùng các chuẩn hiện đại
  • Trong 20 năm của dự án Thunderbird, chưa từng có hỗ trợ giao thức mail mới nào được thêm vào
    • Trong khi các giao thức mail thay đổi để phù hợp với mẫu sử dụng hiện đại, các cấu trúc liên quan lại không được cập nhật
    • Nhiều tri thức tổ chức cũng đã biến mất
  • Hỗ trợ Exchange là nỗ lực do tổ chức dẫn dắt đầu tiên nhằm hiểu các giới hạn trong kiến trúc Thunderbird và từng bước giải quyết chúng

Vì sao chọn Rust

  • Rust được chọn làm ngôn ngữ triển khai hỗ trợ giao thức mới của Thunderbird
  • Bối cảnh lựa chọn gồm cả các ưu điểm chung của Rust lẫn điều kiện riêng của Thunderbird
    • An toàn bộ nhớ: Thunderbird nhận input từ bất kỳ ai gửi email, nên việc giảm lỗi bảo mật là rất quan trọng
    • Hiệu năng: Rust chạy dưới dạng mã native
    • Tính mô-đun và hệ sinh thái: Có thể tận dụng cấu trúc mô-đun của Rust và hệ sinh thái liên quan đến email
  • Thunderbird được xây dựng trên mã Firefox, nên điều kiện đưa Rust vào đã sẵn có
    • Hạ tầng CI dùng chung với Firefox hỗ trợ Rust
    • Lớp tương tác XPCOM(Cross-Platform Component Object Model) của Firefox cho phép gọi lẫn nhau giữa Rust, C++ và JavaScript
  • Kiểu dữ liệu và công cụ của Rust giúp tạo ra các API khó dùng sai
    • Có thể tránh tham chiếu vòng, hoặc tạo các hàm không thể gọi bằng giá trị vô nghĩa
    • Công cụ tài liệu hóa được tích hợp sẵn trong ngôn ngữ, hữu ích cho nhóm nhỏ
  • Nếu xây dựng thành các crate dạng mô-đun, chúng cũng có thể được tái sử dụng trong các dự án khác như Thunderbird for Android/K-9 Mail

Hệ thống build và ràng buộc XPCOM

  • Khi chạy component Rust đầu tiên trong Thunderbird, hệ thống build là trở ngại đầu tiên
  • Thunderbird không được gắn vào như một dependency thông thường của mã Firefox
    • Khi build, mã Firefox được lấy về
    • Mã Thunderbird được đưa vào như một subtree của Firefox
    • File cấu hình build trỏ tới subtree đó
  • Firefox gom các crate riêng lẻ vào một Cargo workspace để tạo đồ thị dependency Cargo cho toàn bộ tree
    • Thunderbird cũng cần Cargo workspace riêng, nhưng Cargo không cho phép workspace lồng nhau
    • Giải pháp là định nghĩa workspace riêng của Thunderbird và cấu hình công cụ build cấp trên mach build workspace này thay vì workspace của Firefox
    • Một subcommand mach mới đồng bộ dependency và lockfile với cấp trên, rồi vendoring superset kết quả
  • XPCOM được thiết kế xoay quanh C++, nên trải nghiệm phát triển bằng Rust không thật mượt
    • Việc triển khai và sử dụng interface XPCOM đòi hỏi nhiều boilerplate
    • Khó tận dụng đầy đủ các công cụ như rust-analyzer
    • Firefox đã giảm đáng kể phụ thuộc vào XPCOM, nhưng Thunderbird không thể làm các công việc dọn dẹp tương tự trong giai đoạn thiếu bảo trì
  • Hỗ trợ giao thức mail mới cần triển khai hàng trăm hàm được định nghĩa trong XPCOM
    • Các triển khai giao thức hiện có giảm gánh nặng bằng cách kế thừa các class C++ cung cấp hành vi dùng chung
    • Trong Rust không thể làm trực tiếp như vậy, nên logic riêng cho từng giao thức được triển khai trong Rust
    • Một class bridge C++ kết nối crate nội bộ ews_xpcom với mã hành vi dùng chung hiện có
  • Cách tạo component Rust trong Thunderbird được tổng hợp trong tài liệu

Xử lý request HTTP theo kiểu Rust

  • Firefox đã có sẵn HTTP stack thông qua component mạng necko
  • necko được viết bằng C++ và được expose qua XPCOM, nên dùng trực tiếp từ Rust cần nhiều boilerplate
    • Ngay cả một request GET đơn giản cũng cần tạo nhiều object XPCOM
    • XPCOM quản lý vòng đời con trỏ, nhưng trình biên dịch Rust không biết điều đó nên cần các block unsafe
    • Các interface cần dùng dựa trên callback
  • Crate nội bộ xpcom_async của Thunderbird chuyển các tác vụ bất đồng bộ XPCOM sang cú pháp async/await của Rust
    • Buffer dữ liệu đi vào qua callback
    • Triển khai trait Future của Rust để caller có thể await
    • Future của Rust tương tự Promise của JavaScript hoặc coroutine của Python
  • Crate nội bộ moz_http cung cấp HTTP client lấy cảm hứng từ reqwest
    • Xử lý việc tạo các object XPCOM cần thiết
    • Cung cấp cách xử lý lỗi đúng chất Rust hơn so với xử lý lỗi XPCOM tiêu chuẩn

Tuần tự hóa XML cho EWS và các crate mới

  • Công việc khó nhất trong EWS là chuyển đổi giữa cấu trúc dữ liệu nội bộ của Thunderbird và XML mà EWS yêu cầu hoặc cung cấp
  • Các crate tuần tự hóa/giải tuần tự hóa XML hiện có không đáp ứng yêu cầu
    • Mô hình dữ liệu của serde không khớp tốt với XML, nên khó phân biệt attribute và element
    • EWS nhạy với XML namespace, nhưng đây không phải khái niệm quen thuộc trong serde
    • Các crate họ serde dành cho XML yêu cầu chú thích rõ cách tuần tự hóa từng field
    • EWS định nghĩa hàng trăm type và hàng chục field cho mỗi type, nên lượng boilerplate là không thể kham nổi
  • Triển khai dựa trên serde hiện có đủ tốt để giải tuần tự hóa XML sang Rust, nhưng không tìm được công cụ tuần tự hóa thỏa đáng
  • Crate mới xml_struct cung cấp trait định nghĩa hành vi tuần tự hóa XML và macro derive thủ tục
    • Tự động tạo triển khai trait cho cấu trúc dữ liệu Rust
    • Được xây dựng trên crate quick_xml hiện có
    • Nhắm tới ánh xạ ít boilerplate giữa XML và Rust
    • Không phụ thuộc vào nội bộ Thunderbird/Firefox và đang ở giai đoạn phát triển ban đầu
  • Crate mới ews định nghĩa các type và API tuần tự hóa/giải tuần tự hóa XML cho công việc với EWS
    • Dựa trên xml_struct và serde
    • Đang ở giai đoạn phát triển ban đầu và được công khai trên GitHub

Kế hoạch kiểm thử, xử lý lỗi và kết nối UI

  • Trước khi đưa vào các chức năng lớn tiếp theo, nhóm đang củng cố kiểm thử tự động
    • Không chỉ unit test, một mock EWS server cho integration test cũng được thêm vào
    • Trong quá trình tăng cường kiểm thử, một số lỗi crash và double-sync đã lộ ra và được sửa
    • Các chức năng mới sẽ dễ kiểm thử và xác minh hơn
  • Xử lý lỗi EWS đang được cải thiện
    • Hành vi lỗi của EWS thường thiếu tài liệu
    • Toàn bộ request có thể thất bại do throttling hoặc cấu trúc sai
    • Một phần request có thể thành công, trong khi phần khác thất bại vì ID sai
    • Một số lỗi có thể xử lý ở cấp giao thức, nhưng một số có thể cần người dùng can thiệp hoặc khó giải quyết
  • Hỗ trợ giao thức EWS đang được mở rộng thông qua ews và crate nội bộ ews_xpcom, đồng thời được kết nối với UI của Thunderbird
    • Các patch gần đây cho phép thêm tài khoản EWS vào Thunderbird
    • Có thể đồng bộ cây thư mục của tài khoản từ server từ xa
    • Có thể hiển thị các thư mục đã đồng bộ trong UI
    • Hiện chức năng ở trạng thái alpha này được ẩn sau build flag và giá trị cấu hình
  • Công việc tiếp theo là tính năng lấy danh sách message từ server từ xa và tổng quát hóa hỗ trợ gửi mail của Thunderbird
  • Để phục vụ bảo trì, nhóm đang tài liệu hóa cách các thành phần kết hợp với nhau, kiến trúc giao thức mail hiện có của Thunderbird và hướng cải thiện trong tương lai

Quan hệ giữa EWS và Microsoft Graph

  • EWS sẽ không thể dùng trên Exchange Online sau tháng 10/2026
  • Khảo sát trước dự án cho thấy vẫn có khá nhiều người dùng tiếp tục sử dụng Exchange Server tại chỗ
    • Nhiều doanh nghiệp và cơ sở giáo dục vận hành Exchange Server trên phần cứng của riêng họ
    • Những cài đặt tại chỗ này nhìn chung hỗ trợ EWS
    • Chúng không thể hỗ trợ Graph API dựa trên Azure
  • Hỗ trợ EWS trở thành phương tiện để hỗ trợ những người dùng này trong tương lai gần
  • Graph API vẫn còn một số vấn đề chưa được giải quyết
    • Graph API được xây dựng với giả định về dịch vụ nền web, không phải ứng dụng desktop
    • Bổ sung hỗ trợ EWS trước giúp có thêm thời gian tìm lời giải cho các vấn đề đó trước khi xây dựng hỗ trợ Graph API
  • Công việc với Rust và EWS là một phần trong nỗ lực lớn hơn nhằm giảm thời gian turnaround của Thunderbird và tăng khả năng phục hồi cho phần lõi phần mềm

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-21
Ý kiến trên Hacker News

  • EWS đã được lên kế hoạch khai tử và sẽ bị gỡ bỏ sau 2 năm nữa, nên không hiểu vì sao lại triển khai: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS là cách thực tế duy nhất để các client không phải Outlook có thể hoạt động, còn MAPI thì không hẳn là API mở
      Nếu EWS biến mất, khá nhiều khách hàng cũng sẽ rời đi, và ban đầu có thể chưa đủ để ảnh hưởng đến kết quả kinh doanh của Microsoft
      Rồi cuối cùng sự thật rằng mọi email đều bình đẳng sẽ lộ rõ, và Exchange Online có thể chỉ còn là một chú thích trong lịch sử. Nhìn bề ngoài thì hơi ngượng vì Microsoft đã làm email rồi phá hỏng khá nặng, nhưng thực ra cũng không hẳn như vậy
      Vận hành hệ thống email là một cực hình, và thứ Microsoft thật sự muốn chỉ là dữ liệu và siêu dữ liệu mà họ có thể khai thác rồi bán cho những kẻ ám ảnh dữ liệu khác. Xét theo dung lượng lưu trữ, email nhìn chung khá tĩnh và lớn, nhưng các trao đổi giữa cá nhân với nhau có thể là mỏ vàng
      Lý tưởng nhất là để những nơi như AWS, Google gánh nỗi đau đó, còn khách hàng thì bị khiến dùng Outlook. Sau đó đổi sang mô hình lưu thông tin xác thực lên đám mây Microsoft, như Outlook phiên bản Electron mới, rồi dùng các thông tin xác thực đó để khai thác dữ liệu email nằm trên đám mây của người khác, còn chi phí lưu trữ thì bên kia chịu. Quá tuyệt vời
    • Như Sean Burke đã nói trong lỗi Bugzilla liên quan, hiện EWS là cách tốt nhất để hỗ trợ cả Exchange Online lẫn các bản cài đặt on-premises: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API cũng đã được xem xét và có thể sẽ được xem xét lại trong tương lai, nhưng hiện phạm vi hỗ trợ của nó hẹp hơn EWS và thiếu một số chức năng cần thiết cho ứng dụng desktop
      Dù đã có thông báo rằng hỗ trợ EWS trong Exchange Online sẽ bị gỡ bỏ, trong ngắn hạn nó vẫn có giá trị vì cho phép một nhóm người dùng rộng tiếp cận, và về dài hạn là hỗ trợ người dùng các bản cài đặt on-premises
    • Vì khi phải đối mặt với những thứ như Exchange, trong một thời gian nữa gần như không có lựa chọn thực tế nào khác
    • Không phải ai cũng dùng Exchange Online

  • Nếu mục tiêu chỉ đơn giản là tăng số người dùng Thunderbird thì về mặt chiến lược là hợp lý, nhưng về mặt lý tưởng thì hỗ trợ JMAP có vẻ tốt hơn nhiều

    • Phần lớn công việc đã làm lần này có lẽ cũng sẽ là cốt lõi để bổ sung hỗ trợ JMAP về sau

  • Gần đây tôi thử dùng Thunderbird thay cho Outlook, và nó có cùng vấn đề như Firefox trước bản cập nhật Quantum. Quá chậm
    Khi chuyển giữa các thư mục có hàng trăm đến hàng nghìn email, có độ trễ thấy rõ, trong khi Outlook chuyển gần như tức thì

    • Nếu dùng Windows, theo kinh nghiệm của tôi, Thunderbird gần như không thể dùng nổi cho đến khi thêm profile Thunderbird vào ngoại lệ của Windows Defender
    • Kinh nghiệm của tôi thì hoàn toàn ngược lại. Dùng Outlook cho email quá khổ sở, đặc biệt là tìm kiếm không hoạt động đúng. Trên Thunderbird tôi dùng expressionsearchNG
      Lịch thì ngược hẳn, nên hiện tôi đang chạy song song cả hai. Một vấn đề có vẻ là cầu nối iCal tới máy chủ Outlook mà công ty bắt dùng
      Thông báo lần này tiếc là không thay đổi phần đó. Tôi từng dùng add-on EWS do Ericsson duy trì một thời gian: https://github.com/Ericsson/exchangecalendar
      Nhưng có vẻ Mozilla đã phá vỡ giao diện quá nhanh, khiến nhiều nhà phát triển plugin bỏ đi. Giờ họ lại đưa một số tính năng vào lõi, nhưng tôi không chắc đó có phải chiến lược tốt không. Tôi nghĩ nên tập trung vào giao diện ổn định thì hơn

  • Tôi ghét Exchange, nhưng rất vui vì công việc này. Có lẽ giờ ngay cả khi bị kẹt trên Windows, tôi cũng có thể gửi thành công email văn bản thuần túy từ Exchange

    • Làm vậy có thể khiến email trông tệ hơn nhiều trên nhiều client email vì chủ nghĩa thuần túy kỹ thuật hoặc hoài niệm xưa cũ
      Sau khi thấy việc email văn bản thuần túy thường xuyên được render bằng phông chữ monospace thay vì theo cách hợp lý hơn phổ biến đến mức nào, tôi thấy khó biện minh cho văn bản thuần túy chỉ vì “email HTML là thứ đáng ghét”

  • Câu “trong toàn bộ lịch sử 20 năm của dự án Thunderbird, chưa ai từng thêm hỗ trợ cho một giao thức email mới” về mặt kỹ thuật là đúng, nhưng mỗi tập đoàn lớn đều cần thiết lập đặc thù theo từng client email, tức là các cách lách, để triển khai xác thực OAuth2 ngoài băng; Thunderbird cũng đã tích lũy khá nhiều thứ như vậy
    Những thứ này không phải là giao thức email thông thường. Chúng không phải IMAP, POP3, SMTP, mà chạy trên HTTPS
    “Chưa từng thêm giao thức email mới” là điều tốt, và thay đổi lần này thì không tốt. Hỗ trợ các thiết lập độc quyền là thực dụng và có thể hiểu được, nhưng không phải điều tốt
    Nó chỉ tạm thời giảm nhẹ vấn đề email bị phân mảnh thành hàng chục biến thể theo từng công ty, và về lâu dài sẽ khuyến khích mọi người chấp nhận các biến thể đó

    • Nhân viên không thể chọn nhà cung cấp email của công ty, và với 99,99999% người thì đây không phải ngọn đồi đáng liều chết để bảo vệ
      Trong khi đó, có thể dùng Thunderbird làm client là lợi ích ròng và là lựa chọn thực dụng
    • Không phải một trong các tập đoàn lớn nào đó, mà là Microsoft Exchange, đặc biệt là Exchange Online, thứ được dùng áp đảo nhất trong email công việc

  • Không hiểu vì sao tiêu đề lại bị đổi. Bài này là về lập trình Rust
    “Bringing Exchange Support to Thunderbird” nghe như một bài viết về Thunderbird và hỗ trợ Exchange, nhưng nội dung đó không phải điều có thể thấy từ bài này

    • Đoạn đầu của bài tập trung vào Exchange hơn là ngôn ngữ, nên bản thân tính năng có vẻ quan trọng hơn phần triển khai. Hầu hết người dùng cũng quan tâm điều đó hơn
    • Trước đó tôi đã đăng cùng bài này với tiêu đề đầy đủ nhưng không được chú ý: https://news.ycombinator.com/item?id=40095870
    • Không hiểu đang nói gì. Toàn bộ nửa sau của bài là về hỗ trợ Exchange của Thunderbird

  • Hỗ trợ đặc tả độc quyền có lẽ sẽ hữu ích, nhưng tôi mong Mozilla ưu tiên triển khai các tiêu chuẩn như tự động phát hiện máy chủ gửi email (SMTP). Ví dụ rfc6186 đã có từ năm 2011
    Hiện tại người dùng phải tự nhập hostname và cổng của máy chủ SMTP; với những người trên trang này thì có thể ổn, nhưng với 99,9% nhân loại còn lại thì hoàn toàn không thân thiện
    Nỗ lực cần để triển khai toàn bộ Exchange có lẽ lớn hơn việc phát hiện máy chủ gửi qua DNS/SRV vài bậc độ lớn. Thật sự không hiểu các ưu tiên của Mozilla

    • Tôi nhớ là khi thêm tài khoản Hotmail, Google, Yahoo vào Thunderbird thì không phải nhập những thông tin đó. Chỉ cần dùng từng địa chỉ email
      Những trường hợp này được xử lý như trường hợp đặc biệt à?

  • Chà, làm tôi nhớ lại thời làm IT khoảng 20 năm trước. Đó gần như là một môi trường Microsoft hoàn toàn, chỉ có vài người dùng Linux
    Exchange luôn là một trong những thứ khó tìm được client tử tế, và nếu lúc đó có cái này thì tôi chắc đã vui sướng như bay lên

    • Giờ tôi vẫn vui sướng như bay lên
      Dùng sản phẩm Microsoft trên Linux đúng là khổ sở, đặc biệt có vẻ họ đang trong quá trình khai tử bản web của Teams nếu bạn không dùng Edge :(
    • Chúng tôi cũng gặp vấn đề tương tự nhưng đã chọn con đường khác. Chúng tôi khiến công ty bỏ Exchange và SharePoint, và từ đó hạnh phúc hơn nhiều

  • Việc “khoảng năm 2012 Mozilla buông tay khỏi Thunderbird và chuyển quyền sở hữu cho cộng đồng, rồi không có bảo trì viên được trả lương cho đến khi Thunderbird quay lại Mozilla Foundation vào năm 2017” thật sự là một bê bối
    Đó là ví dụ tiêu biểu cho các ưu tiên bị đảo ngược của Mozilla

    • Không đồng ý. Thế giới đã chuyển sang email dựa trên ứng dụng web/di động
      Bạn có thể không thích điều đó, và tôi cũng không quá vui. Nhưng đó là sự thật, và Mozilla không đáng phải tài trợ cho nó

  • Tôi mong họ tích hợp sẵn nhập tệp PST để những người muốn rời khỏi cài đặt Outlook có thể chuyển đổi mượt mà mà không cần động đến chính Outlook
    Đã có các dự án miễn phí đọc được tệp PST, nên chỉ cần tích hợp vào bộ sản phẩm là được