Mozilla Thunderbird Menghadirkan Dukungan Native untuk Exchange

 (blog.thunderbird.net)
1 poin oleh GN⁺ 2024-04-21 | 1 komentar | Bagikan ke WhatsApp
  • Thunderbird akan mendukung Microsoft Exchange, yang banyak digunakan di perusahaan dan institusi pendidikan, secara native mulai ESR Juli 2024; cakupan awalnya terbatas pada email
  • Pekerjaan ini bukan sekadar menambahkan dukungan Exchange Web Services (EWS), tetapi juga menjadi momentum untuk secara bertahap merapikan keterbatasan arsitektur protokol email yang sudah berusia lebih dari 20 tahun serta kode C++ lama
  • Rust dipilih sebagai bahasa implementasi, dengan alasan utama keamanan memori, performa native, modularitas, serta CI yang dibagi dengan Firefox dan interoperabilitas XPCOM
  • Dalam proses integrasi EWS, dibuat crate seperti xpcom_async, moz_http, xml_struct, dan ews, yang membungkus pemanggilan HTTP berbasis XPCOM dan serialisasi XML agar lebih ramah bagi Rust
  • EWS tidak akan tersedia di Exchange Online setelah Oktober 2026, tetapi karena masih banyak pengguna Exchange Server on-premises, dukungan ini tetap diperlukan di Thunderbird

Cakupan dukungan Exchange pada ESR Juli 2024

  • Thunderbird berencana menyediakan dukungan Exchange secara native pada rilis ESR (Extended Support) berikutnya, yaitu Juli 2024
  • Cakupan awalnya terbatas pada email
    • Dukungan kalender dan buku alamat akan ditambahkan setelahnya
    • Hingga baru-baru ini, fitur Exchange hanya dapat digunakan melalui add-on
  • Target implementasinya adalah API Exchange Web Services (EWS) dari Microsoft
    • EWS berjalan di atas HTTP
    • Isi request dan response menggunakan XML

Beban arsitektur email yang berusia lebih dari 20 tahun

  • Arsitektur protokol email Thunderbird saat ini didasarkan pada kode yang lebih tua daripada Thunderbird sendiri
    • Dikembangkan lebih dari 20 tahun lalu sebagai bagian dari Netscape Communicator
    • Setelah Mozilla menyerahkan kepemilikan Thunderbird kepada komunitas pada 2012, tidak ada pemeliharaan berbayar hingga proyek ini bergabung kembali dengan Mozilla Foundation pada 2017
  • Karena perubahan sementara menumpuk tanpa arah arsitektur besar, masih banyak kode C++ yang tidak menggunakan standar modern
  • Selama 20 tahun proyek Thunderbird berjalan, belum pernah ada dukungan protokol email baru yang ditambahkan
    • Ketika protokol email berubah mengikuti pola penggunaan modern, struktur terkait tidak ikut diperbarui
    • Banyak pengetahuan institusional juga telah hilang
  • Dukungan Exchange adalah pekerjaan yang dipimpin organisasi pertama untuk memahami keterbatasan arsitektur Thunderbird dan mengatasinya secara bertahap

Alasan memilih Rust

  • Rust dipilih sebagai bahasa implementasi untuk dukungan protokol baru Thunderbird
  • Latar belakang pemilihannya mencakup keunggulan umum Rust dan kondisi khusus Thunderbird
    • Keamanan memori: Thunderbird menerima input dari siapa pun yang mengirim email, sehingga mengurangi bug keamanan menjadi hal penting
    • Performa: Rust berjalan sebagai kode native
    • Modularitas dan ekosistem: Struktur modul Rust dan ekosistem terkait email dapat dimanfaatkan
  • Karena Thunderbird dibangun di atas kode Firefox, prasyarat untuk mengadopsi Rust sudah tersedia
    • Infrastruktur CI yang dibagi dengan Firefox mendukung Rust
    • Lapisan interoperabilitas XPCOM (Cross-Platform Component Object Model) milik Firefox memungkinkan pemanggilan antar-Rust, C++, dan JavaScript
  • Tipe dan tooling Rust membantu membuat API yang sulit disalahgunakan
    • Misalnya menghindari referensi siklik, atau membuat fungsi yang tidak bisa dipanggil dengan nilai yang tidak bermakna
    • Tool dokumentasi sudah menjadi bagian bawaan bahasa, sehingga berguna bagi tim kecil
  • Jika dibuat sebagai crate modular, komponen ini dapat digunakan kembali oleh proyek lain seperti Thunderbird for Android/K-9 Mail

Batasan build system dan XPCOM

  • Saat menjalankan komponen Rust pertama di dalam Thunderbird, build system menjadi hambatan pertama
  • Thunderbird bukanlah struktur yang melekat seperti dependensi umum pada kode Firefox
    • Saat build, kode Firefox diambil
    • Kode Thunderbird diambil sebagai subtree Firefox
    • File konfigurasi build menunjuk ke subtree tersebut
  • Firefox menggabungkan masing-masing crate ke dalam satu workspace Cargo untuk membuat grafik dependensi Cargo seluruh tree
    • Thunderbird juga membutuhkan workspace Cargo sendiri, tetapi Cargo tidak mengizinkan workspace bertumpuk
    • Sebagai solusi, workspace Thunderbird sendiri didefinisikan, lalu tool build tingkat atas mach dikonfigurasi untuk membuild workspace ini alih-alih workspace Firefox
    • Subcommand mach baru menyinkronkan dependensi dan lockfile dengan tingkat atas, lalu mem-vendor superset hasilnya
  • XPCOM dirancang dengan fokus pada C++, sehingga pengalaman pengembangan Rust tidak mulus
    • Implementasi dan penggunaan interface XPCOM membutuhkan banyak boilerplate
    • Tool seperti rust-analyzer sulit dimanfaatkan secara memadai
    • Firefox telah banyak mengurangi ketergantungan pada XPCOM, tetapi Thunderbird tidak sempat melakukan pembersihan serupa selama masa kosong pemeliharaan
  • Dukungan protokol email baru memerlukan implementasi ratusan fungsi yang didefinisikan di XPCOM
    • Implementasi protokol yang ada mengurangi beban dengan mewarisi class C++ yang menyediakan perilaku bersama
    • Di Rust, hal ini tidak bisa dilakukan secara langsung, sehingga logika per protokol diimplementasikan di Rust
    • Class bridge C++ menghubungkan crate internal ews_xpcom dengan kode perilaku bersama yang sudah ada
  • Cara membuat komponen Rust di Thunderbird didokumentasikan di dokumentasi

Menangani request HTTP dengan gaya Rust

  • Firefox sudah memiliki stack HTTP melalui komponen networking necko
  • necko ditulis dalam C++ dan diekspos melalui XPCOM, sehingga jika digunakan langsung dari Rust membutuhkan banyak boilerplate
    • Bahkan request GET sederhana pun memerlukan pembuatan banyak objek XPCOM
    • XPCOM mengelola masa hidup pointer, tetapi compiler Rust tidak mengetahuinya, sehingga diperlukan blok unsafe
    • Interface yang diperlukan berbasis callback
  • Crate internal Thunderbird xpcom_async mengubah pekerjaan asinkron XPCOM menjadi sintaks async/await Rust
    • Data yang masuk melalui callback dibuffer
    • Mengimplementasikan trait Future milik Rust agar pemanggil dapat melakukan await
    • Future di Rust mirip dengan Promise di JavaScript atau coroutine di Python
  • Crate internal moz_http menyediakan klien HTTP yang terinspirasi oleh reqwest
    • Menangani pembuatan objek XPCOM yang diperlukan
    • Menyediakan penanganan error yang lebih Rust-like daripada penanganan error XPCOM standar

Serialisasi XML EWS dan crate baru

  • Pekerjaan paling sulit dalam EWS adalah mengonversi antara struktur data internal Thunderbird dan XML yang dibutuhkan atau diberikan oleh EWS
  • Crate serialisasi/deserialisasi XML yang ada tidak memenuhi kebutuhan
    • Model data serde tidak cocok dengan XML, sehingga sulit membedakan atribut dan elemen
    • EWS sensitif terhadap namespace XML, tetapi ini bukan konsep yang familier bagi serde
    • Crate keluarga serde untuk XML mengharuskan cara serialisasi setiap field dianotasi secara eksplisit
    • EWS mendefinisikan ratusan tipe dan puluhan field per tipe, sehingga boilerplate menjadi tidak tertangani
  • Implementasi berbasis serde yang ada sudah cukup untuk mendeserialisasi XML menjadi Rust, tetapi tidak ditemukan tool serialisasi yang memuaskan
  • Crate baru xml_struct menyediakan trait yang mendefinisikan perilaku serialisasi XML dan macro derive prosedural
    • Menghasilkan implementasi trait secara otomatis untuk struktur data Rust
    • Dibangun di atas crate quick_xml yang sudah ada
    • Bertujuan memetakan XML dan Rust dengan boilerplate yang minim
    • Tidak bergantung pada internal Thunderbird/Firefox dan masih dalam tahap pengembangan awal
  • Crate baru ews mendefinisikan tipe untuk pekerjaan EWS serta API serialisasi/deserialisasi XML
    • Berbasis xml_struct dan serde
    • Masih dalam tahap pengembangan awal dan tersedia secara publik di GitHub

Rencana pengujian, penanganan error, dan koneksi UI

  • Sebelum memasukkan fitur utama berikutnya, pengujian otomatis sedang diperkuat
    • Selain unit test, mock EWS server untuk integration test juga ditambahkan
    • Dalam proses memperkuat pengujian, beberapa crash dan masalah double-sync terungkap dan diperbaiki
    • Fitur baru menjadi lebih mudah diuji dan diverifikasi
  • Penanganan error EWS sedang diperbaiki
    • Perilaku error EWS sering kali kurang terdokumentasi
    • Seluruh request dapat gagal karena throttling atau struktur yang salah
    • Sebagian request dapat berhasil sementara sebagian lainnya gagal karena ID yang salah
    • Beberapa error dapat ditangani di level protokol, tetapi sebagian memerlukan intervensi pengguna atau mungkin sulit diselesaikan
  • Dukungan protokol EWS diperluas melalui crate ews dan crate internal ews_xpcom, serta sedang dihubungkan dengan UI Thunderbird
    • Patch terbaru memungkinkan akun EWS ditambahkan ke Thunderbird
    • Hierarki folder akun dapat disinkronkan dari server remote
    • Folder yang telah disinkronkan dapat ditampilkan di UI
    • Saat ini fitur berstatus alfa ini disembunyikan di balik build flag dan nilai konfigurasi
  • Pekerjaan berikutnya adalah fitur mengambil daftar pesan dari server remote dan generalisasi dukungan email keluar Thunderbird
  • Untuk pemeliharaan, dokumentasi sedang dibuat tentang bagaimana tiap komponen dirangkai, arsitektur protokol email Thunderbird yang ada, dan arah perbaikan ke depan

Hubungan EWS dan Microsoft Graph

  • EWS tidak dapat digunakan di Exchange Online setelah Oktober 2026
  • Riset awal proyek menunjukkan masih ada cukup banyak pengguna yang terus memakai Exchange Server on-premises
    • Banyak perusahaan dan institusi pendidikan menjalankan Exchange Server di hardware mereka sendiri
    • Instalasi on-premises seperti ini umumnya mendukung EWS
    • Graph API berbasis Azure tidak dapat didukung
  • Dukungan EWS menjadi sarana untuk mendukung pengguna seperti ini dalam waktu dekat
  • Graph API masih memiliki beberapa masalah yang belum terselesaikan
    • Graph API dibuat dengan mempertimbangkan layanan berbasis web, bukan aplikasi desktop
    • Dengan menambahkan dukungan EWS lebih dahulu, ada waktu untuk mencari solusi atas masalah tersebut sebelum membuat dukungan Graph API
  • Pekerjaan Rust dan EWS adalah bagian dari upaya yang lebih besar untuk mengurangi turnaround Thunderbird dan meningkatkan ketahanan inti perangkat lunaknya

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-21
Opini Hacker News

  • Saya tidak mengerti kenapa ini diimplementasikan, padahal EWS sudah dijadwalkan untuk dihentikan dan akan dihapus dua tahun lagi: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS adalah satu-satunya cara yang realistis agar klien non-Outlook bisa berfungsi, sementara MAPI bukan API yang benar-benar terbuka
      Kalau EWS hilang, cukup banyak pelanggan juga akan pergi, dan pada awalnya mungkin belum sampai memukul kinerja Microsoft
      Namun pada akhirnya akan terlihat bahwa semua email itu setara, dan Exchange Online bisa menjadi catatan kaki dalam sejarah. Dari luar, ini agak memalukan karena Microsoft seperti gagal besar dalam urusan email, tetapi kenyataannya tidak selalu begitu
      Mengoperasikan sistem email itu menyakitkan, dan yang benar-benar diinginkan Microsoft hanyalah data dan metadata yang bisa mereka tambang lalu jual ke para penggila data lain. Email pada dasarnya statis dan besar dari sisi penyimpanan, tetapi dalam pertukaran antarindividu bisa ada tambang emas
      Idealnya, biarkan pihak seperti AWS dan Google menanggung rasa sakitnya, lalu buat pelanggan memakai Outlook. Setelah itu ubah agar kredensial disimpan di cloud Microsoft, seperti Outlook versi Electron baru, lalu gunakan kredensial itu untuk menambang data email di cloud orang lain sementara biaya penyimpanannya ditanggung pihak sana. Luar biasa
    • Seperti yang dikatakan Sean Burke di bug Bugzilla terkait, saat ini EWS adalah cara terbaik untuk mendukung Exchange Online maupun instalasi on-premise: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API juga sudah dipertimbangkan dan bisa dipertimbangkan lagi ke depannya, tetapi saat ini cakupan dukungannya lebih sempit daripada EWS dan kurang beberapa fitur yang dibutuhkan aplikasi desktop
      Meski sudah ada pengumuman bahwa dukungan EWS akan dihapus dari Exchange Online, dalam jangka pendek EWS masih bernilai untuk memungkinkan akses bagi basis pengguna yang luas, dan dalam jangka panjang untuk mendukung pengguna instalasi on-premise
    • Karena saat berhadapan dengan sesuatu seperti Exchange, untuk sementara hampir tidak ada pilihan realistis lain
    • Tidak semua orang memakai Exchange Online

  • Kalau tujuannya sekadar menambah jumlah pengguna Thunderbird, secara strategis ini masuk akal, tetapi secara ideologis dukungan JMAP tampak jauh lebih baik

    • Sebagian besar pekerjaan yang sudah dilakukan kali ini tampaknya juga akan menjadi inti untuk menambahkan dukungan JMAP ke depannya

  • Baru-baru ini saya mencoba Thunderbird sebagai pengganti Outlook, dan masalahnya mirip Firefox sebelum pembaruan Quantum. Terlalu lambat
    Saat berpindah antar folder yang berisi ratusan hingga ribuan email, ada jeda yang terasa jelas, sedangkan di Outlook perpindahannya praktis instan

    • Jika memakai Windows, berdasarkan pengalaman saya, Thunderbird hampir tidak bisa dipakai sebelum profil Thunderbird ditambahkan ke pengecualian Windows Defender
    • Pengalaman saya justru sepenuhnya kebalikan. Memakai Outlook untuk email itu sangat menyakitkan, terutama karena pencariannya tidak berfungsi dengan baik. Di Thunderbird saya memakai expressionsearchNG
      Untuk kalender justru sebaliknya, jadi sekarang saya menjalankan keduanya berdampingan. Salah satu masalahnya sepertinya adalah bridge iCal ke server Outlook yang wajib saya pakai di perusahaan
      Sayangnya pengumuman ini tidak mengubah bagian itu. Dulu saya sempat memakai add-on EWS yang dipelihara Ericsson: https://github.com/Ericsson/exchangecalendar
      Namun tampaknya Mozilla mematahkan antarmuka dengan cepat sehingga membuat banyak pengembang plugin pergi. Sekarang mereka memasukkan kembali sebagian fungsi ke core, tetapi saya tidak yakin itu strategi yang baik. Menurut saya mereka sebaiknya berfokus pada antarmuka yang stabil

  • Saya tidak suka Exchange, tetapi pekerjaan ini menyenangkan untuk dilihat. Sekarang, bahkan saat terjebak di Windows, mungkin saya akhirnya bisa berhasil mengirim email teks biasa dari Exchange

    • Kalau begitu, karena purisme teknis atau nostalgia masa lalu, email bisa terlihat jauh lebih buruk di berbagai klien email
      Setelah melihat betapa seringnya email teks biasa dirender dengan font monospace, bukan dengan cara yang lebih masuk akal, saya merasa sulit membenarkan teks biasa hanya dengan alasan “email HTML itu menjijikkan”

  • Pernyataan bahwa “selama 20 tahun sejarah proyek Thunderbird, belum pernah ada orang yang menambahkan dukungan protokol email baru” secara teknis benar, tetapi tiap perusahaan besar membutuhkan pengaturan khusus per klien email, alias workaround, untuk implementasi autentikasi OAuth2 out-of-band, dan Thunderbird juga sudah mengumpulkan cukup banyak hal semacam itu
    Itu bukan protokol email umum. Bukan IMAP, POP3, atau SMTP, melainkan berjalan di atas HTTPS
    “Belum pernah menambahkan protokol email baru” adalah hal yang baik, dan perubahan kali ini bukan hal yang baik. Mendukung konfigurasi proprietary itu praktis dan bisa dimengerti, tetapi bukan hal baik
    Ini hanya meredakan sementara masalah email yang terpecah menjadi puluhan varian per perusahaan, dan dalam jangka panjang justru mendorong orang menerima varian-varian seperti itu

    • Karyawan tidak bisa memilih penyedia email perusahaan mereka, dan bagi 99,99999% orang ini bukan bukit yang layak dipertaruhkan nyawa untuk dipertahankan
      Sebaliknya, bisa memakai Thunderbird sebagai klien adalah keuntungan bersih dan pilihan yang praktis
    • Ini bukan salah satu dari sekian perusahaan besar, melainkan Microsoft Exchange, terutama Exchange Online, yang sejauh ini paling umum dipakai untuk email kantor

  • Saya tidak tahu kenapa judulnya diubah. Tulisan ini adalah tentang pemrograman Rust
    “Bringing Exchange Support to Thunderbird” terlihat seperti tulisan tentang dukungan Thunderbird dan Exchange, tetapi isinya bukan sesuatu yang bisa diketahui dari tulisan ini

    • Karena paragraf pertama tulisan ini lebih berfokus pada Exchange daripada bahasanya, fitur itu sendiri tampak lebih penting daripada implementasinya. Sebagian besar pengguna juga lebih peduli soal itu
    • Saya sebelumnya sudah memposting tulisan yang sama dengan judul lengkap, tetapi tidak mendapat perhatian: https://news.ycombinator.com/item?id=40095870
    • Saya tidak mengerti maksudnya. Seluruh bagian akhir tulisan ini membahas dukungan Exchange di Thunderbird

  • Dukungan untuk spesifikasi proprietary memang berguna, tetapi saya berharap Mozilla memprioritaskan implementasi standar seperti autodiscovery server submission email (SMTP). Misalnya, rfc6186 sudah ada sejak 2011
    Saat ini pengguna harus memasukkan sendiri hostname dan port server SMTP; mungkin itu tidak masalah bagi orang-orang di situs ini, tetapi sama sekali tidak ramah bagi 99,9% umat manusia lainnya
    Upaya yang diperlukan untuk mengimplementasikan Exchange sepenuhnya kemungkinan beberapa orde besaran lebih besar daripada discovery server submission lewat DNS/SRV. Saya benar-benar tidak memahami prioritas Mozilla

    • Seingat saya, saat menambahkan akun Hotmail, Google, dan Yahoo ke Thunderbird, saya tidak memasukkan informasi semacam itu. Saya hanya memakai alamat email masing-masing
      Apakah ini ditangani sebagai kasus khusus?

  • Wah, ini mengingatkan saya pada masa bekerja di TI sekitar 20 tahun lalu. Lingkungannya hampir sepenuhnya Microsoft, hanya beberapa orang yang memakai Linux
    Exchange selalu menjadi salah satu hal yang sulit dicari klien yang layak, dan kalau ini sudah ada waktu itu, saya pasti akan senang bukan main

    • Sekarang pun saya senang bukan main
      Menggunakan produk Microsoft di Linux benar-benar menyakitkan, dan khususnya kalau tidak memakai Edge, sepertinya mereka sedang dalam proses menghentikan versi web Teams :(
    • Kami juga punya masalah yang sama, tetapi mengambil jalan lain. Kami membuat perusahaan meninggalkan Exchange dan SharePoint, dan sejak itu kami jauh lebih bahagia

  • Bahwa “sekitar 2012 Mozilla melepas Thunderbird dan menyerahkan kepemilikannya kepada komunitas, lalu tidak ada pemeliharaan berbayar sampai Thunderbird bergabung kembali dengan Mozilla Foundation pada 2017” benar-benar sebuah skandal
    Itu contoh utama prioritas Mozilla yang terbalik

    • Saya tidak setuju. Dunia sudah beralih ke email berbasis aplikasi web/mobile
      Anda mungkin tidak menyukainya, dan saya juga tidak terlalu senang. Namun itu fakta, dan tidak layak didanai Mozilla

  • Saya berharap impor file PST disertakan secara bawaan agar orang-orang yang ingin lepas dari instalasi Outlook bisa beralih dengan mulus tanpa harus mengutak-atik Outlook itu sendiri
    Sudah ada proyek gratis untuk membaca file PST, jadi tinggal diintegrasikan ke rangkaian produknya