Mozilla Thunderbird, Exchange desteğini yerel olarak getiriyor

 (blog.thunderbird.net)
1 puan yazan GN⁺ 2024-04-21 | 1 yorum | WhatsApp'ta paylaş
  • Kurumlarda ve eğitim kuruluşlarında yaygın olarak kullanılan Microsoft Exchange, Thunderbird tarafından 2024 Temmuz ESR’den itibaren yerel olarak desteklenecek; ilk kapsam e-postayla sınırlı olacak
  • Bu çalışma, Exchange Web Services(EWS) desteğinin ötesinde, 20 yılı aşkın süredir devam eden posta protokolü mimarisi ile eski C++ kodunun sınırlamalarını kademeli olarak düzenlemek için bir fırsat oluşturuyor
  • Uygulama dili olarak Rust seçildi; bunun başlıca nedenleri bellek güvenliği, yerel performans, modülerlik ve Firefox ile paylaşılan CI ile XPCOM birlikte çalışabilirliği
  • EWS entegrasyonu sürecinde xpcom_async, moz_http, xml_struct, ews gibi crate’ler oluşturuldu; bunlar XPCOM tabanlı HTTP çağrılarını ve XML serileştirmeyi Rust dostu şekilde sarıyor
  • EWS, Exchange Online’da Ekim 2026’dan sonra kullanılamayacak olsa da, çok sayıda şirket içi Exchange Server kullanıcısı bulunduğu için Thunderbird açısından hâlâ gerekli bir destek

2024 Temmuz ESR’de Exchange desteğinin kapsamı

  • Thunderbird, bir sonraki ESR(Extended Support) sürümünde 2024 Temmuz’da Exchange desteğini yerel olarak sunmayı planlıyor
  • İlk kapsam e-posta ile sınırlı
    • Takvim ve adres defteri desteği daha sonra eklenecek
    • Yakın zamana kadar Exchange özellikleri yalnızca eklentiler aracılığıyla kullanılabiliyordu
  • Hedeflenen uygulama, Microsoft’un Exchange Web Services(EWS) API’si
    • EWS, HTTP üzerinde çalışır
    • İstek ve yanıt gövdelerinde XML kullanır

20 yılı aşan posta mimarisinin yükü

  • Thunderbird’ün mevcut posta protokolü mimarisi, Thunderbird’ten daha eski koda dayanıyor
    • 20 yıldan uzun süre önce Netscape Communicator’ın bir parçası olarak geliştirildi
    • Mozilla, 2012’de Thunderbird’ün sahipliğini topluluğa devrettikten sonra, 2017’de yeniden Mozilla Foundation’a katılana kadar ücretli bakım yapılmadı
  • Büyük bir mimari yön olmadan geçici değişiklikler biriktikçe, modern standartları kullanmayan çok sayıda C++ kodu kaldı
  • Thunderbird projesinin 20 yıllık tarihinde yeni posta protokolü desteği hiç eklenmedi
    • Posta protokolleri modern kullanım kalıplarına göre değişirken ilgili yapı güncellenemedi
    • Kurumsal bilgi birikiminin önemli bir kısmı da kaybolmuş durumda
  • Exchange desteği, Thunderbird mimarisinin sınırlarını anlayıp bunları kademeli olarak çözmeye yönelik ilk organizasyon öncülüğündeki çalışma

Neden Rust seçildi

  • Thunderbird’ün yeni protokol desteği için uygulama dili olarak Rust seçildi
  • Seçim arkasında Rust’ın genel avantajları ile Thunderbird’e özgü koşullar birlikte yer alıyor
    • Bellek güvenliği: Thunderbird, e-posta gönderebilen herkesten girdi aldığı için güvenlik açıklarını azaltmak önemli
    • Performans: Rust yerel kod olarak çalışır
    • Modülerlik ve ekosistem: Rust’ın modül yapısı ve e-posta ile ilgili ekosisteminden yararlanılabiliyor
  • Thunderbird, Firefox kodu üzerine kurulu olduğu için Rust benimsemek için gerekli koşullar zaten mevcut
    • Firefox ile paylaşılan CI altyapısı Rust’ı destekliyor
    • Firefox’un XPCOM(Cross-Platform Component Object Model) birlikte çalışabilirlik katmanı sayesinde Rust, C++ ve JavaScript arasında çağrılar yapılabiliyor
  • Rust’ın tip sistemi ve araçları, yanlış kullanılmasının zor olduğu API’ler oluşturmaya yardımcı oluyor
    • Döngüsel referanslardan kaçınmak veya anlamsız değerlerle çağrılamayan fonksiyonlar yazmak mümkün
    • Belgeleme araçlarının dile yerleşik gelmesi küçük ekipler için faydalı
  • Modüler crate’ler olarak geliştirildiğinde Thunderbird for Android/K-9 Mail gibi başka projelerde de yeniden kullanılabiliyor

Derleme sistemi ve XPCOM kısıtları

  • Thunderbird içinde ilk Rust bileşenini çalıştırırken derleme sistemi ilk engel oldu
  • Thunderbird, Firefox koduna sıradan bir bağımlılık gibi eklenen bir yapıda değil
    • Derleme sırasında Firefox kodu alınıyor
    • Thunderbird kodu, Firefox’un bir alt ağacı olarak içe alınıyor
    • Derleme yapılandırma dosyasıyla bu alt ağaç işaret ediliyor
  • Firefox, tüm ağaç için Cargo bağımlılık grafiği oluşturmak amacıyla tek tek crate’leri tek bir Cargo workspace içinde topluyor
    • Thunderbird’ün de kendi Cargo workspace’ine ihtiyacı vardı ancak Cargo iç içe workspace’lere izin vermiyor
    • Çözüm olarak Thunderbird’e ait ayrı bir workspace tanımlandı ve üst derleme aracı mach, Firefox workspace’i yerine bunu derleyecek şekilde ayarlandı
    • Yeni mach alt komutlarıyla bağımlılıklar ve lockfile üst yapıyla senkronize ediliyor, ardından ortaya çıkan superset vendoring işlemine alınıyor
  • XPCOM, C++ merkezli tasarlandığı için Rust geliştirme deneyimi akıcı değil
    • XPCOM arayüzlerini uygulamak ve kullanmak için çok sayıda boilerplate gerekiyor
    • rust-analyzer gibi araçlardan tam verim almak zor
    • Firefox, XPCOM bağımlılığını büyük ölçüde azalttı ancak Thunderbird bakım boşluğu sırasında benzer bir temizlik yapamadı
  • Yeni posta protokolü desteği için XPCOM’da tanımlı yüzlerce fonksiyonun uygulanması gerekiyor
    • Mevcut protokol uygulamaları, ortak davranış sağlayan C++ sınıflarını miras alarak bu yükü azaltıyor
    • Rust’ta bu doğrudan yapılamadığı için protokole özgü mantık Rust’ta uygulanıyor
    • C++ köprü sınıfları, dahili ews_xpcom crate’ini mevcut ortak davranış koduna bağlıyor
  • Thunderbird’de Rust bileşenleri oluşturma yöntemi belgede açıklanıyor

HTTP isteklerini Rust tarzında ele almak

  • Firefox’ta necko ağ bileşeni üzerinden hazır bir HTTP yığını zaten bulunuyor
  • necko, C++ ile yazılmış ve XPCOM üzerinden açığa çıkarılmış durumda; bu yüzden Rust’ta doğrudan kullanımı çok fazla boilerplate gerektiriyor
    • Basit bir GET isteği için bile çok sayıda XPCOM nesnesi oluşturmak gerekiyor
    • XPCOM işaretçi ömrünü yönetiyor ama Rust derleyicisi bunun farkında olmadığı için unsafe blokları gerekiyor
    • Gerekli arayüzler callback tabanlı
  • Thunderbird’ün dahili xpcom_async crate’i, XPCOM asenkron işlerini Rust’ın async/await söz dizimine dönüştürüyor
    • Callback ile gelen veriyi tamponluyor
    • Rust’ın Future trait’ini uygulayarak çağıranın await kullanabilmesini sağlıyor
    • Rust’taki Future, JavaScript’teki Promise veya Python coroutine’lerine benziyor
  • Dahili moz_http crate’i, reqwest’ten ilham alan bir HTTP istemcisi sunuyor
    • Gerekli XPCOM nesnelerinin oluşturulmasını üstleniyor
    • Standart XPCOM hata işlemeden daha Rust tarzı bir hata yönetimi sağlıyor

EWS XML serileştirmesi ve yeni crate’ler

  • EWS’de en zor iş, Thunderbird’ün dahili veri yapıları ile EWS’nin istediği ya da sunduğu XML arasında dönüşüm yapmak
  • Mevcut XML serileştirme/ters serileştirme crate’leri gereksinimleri karşılamadı
    • serde veri modeli XML ile iyi uyuşmuyor; öznitelikler ile öğeleri ayırmak zor
    • EWS, XML namespace’lerine duyarlı ancak bu serde için alışıldık bir kavram değil
    • XML için serde tabanlı crate’ler, tüm alanların serileştirme biçiminin açıkça anotasyonla belirtilmesini gerektiriyor
    • EWS yüzlerce tip ve her tip için onlarca alan tanımladığından boilerplate yükü taşınamaz hale geliyor
  • Mevcut serde tabanlı uygulama, XML’i Rust’a ters serileştirmek için yeterliydi ancak tatmin edici bir serileştirme aracı bulunamadı
  • Yeni crate xml_struct, XML serileştirme davranışını tanımlayan trait’ler ve prosedürel derive macro sağlıyor
    • Rust veri yapıları için trait uygulamalarını otomatik üretiyor
    • Mevcut quick_xml crate’i üzerine inşa edildi
    • XML ile Rust arasında daha az boilerplate içeren bir eşleme hedefliyor
    • Thunderbird/Firefox iç bağımlılıkları yok ve erken geliştirme aşamasında
  • Yeni crate ews, EWS işlemleri için tipleri ve XML serileştirme/ters serileştirme API’lerini tanımlıyor
    • xml_struct ve serde temelli
    • Erken geliştirme aşamasında ve GitHub’da açık olarak yayımlanmış durumda

Testler, hata yönetimi ve UI bağlantı planı

  • Bir sonraki önemli özellikler eklenmeden önce otomatik testler güçlendiriliyor
    • Yalnızca birim testleri değil, entegrasyon testleri için sahte bir EWS sunucusu da eklendi
    • Testlerin güçlendirilmesi sürecinde bazı çökme ve double-sync sorunları ortaya çıktı ve düzeltildi
    • Böylece yeni özellikleri daha kolay test etmek ve doğrulamak mümkün hale geldi
  • EWS hata yönetimi iyileştiriliyor
    • EWS’nin hata davranışı çoğu zaman yetersiz belgelenmiş durumda
    • Tüm istek throttling veya hatalı yapı nedeniyle başarısız olabilir
    • İsteğin bazı bölümleri başarılı olurken bazıları hatalı kimlikler nedeniyle başarısız olabilir
    • Bazı hatalar protokol seviyesinde ele alınabilirken bazıları kullanıcı müdahalesi gerektirebilir veya çözülmesi zor olabilir
  • EWS protokol desteği, ews ve dahili ews_xpcom crate’leri üzerinden genişletiliyor ve Thunderbird arayüzüne bağlanıyor
    • Son yamalarla Thunderbird’e EWS hesabı eklemek mümkün hale geldi
    • Uzak sunucudaki hesap klasör hiyerarşisi senkronize edilebiliyor
    • Senkronize edilen klasörler arayüzde gösterilebiliyor
    • Şu anda alfa durumundaki bu özellik derleme bayrakları ve ayar değerlerinin arkasında gizli
  • Sıradaki çalışma, uzak sunucudan ileti listesini getirme ve Thunderbird’ün giden posta desteğini genelleştirme
  • Bakımı kolaylaştırmak için her bileşenin nasıl bir araya geldiği, mevcut Thunderbird posta protokolü mimarisi ve gelecekteki iyileştirme yönleri belgeleniyor

EWS ile Microsoft Graph arasındaki ilişki

  • EWS, Exchange Online üzerinde Ekim 2026’dan sonra kullanılamayacak
  • Proje ön araştırması, şirket içi Exchange Server kullanmaya devam eden önemli sayıda kullanıcı olduğunu gösterdi
    • Birçok şirket ve eğitim kurumu Exchange Server’ı kendi donanımı üzerinde çalıştırıyor
    • Bu tür şirket içi kurulumlar genellikle EWS’yi destekliyor
    • Azure tabanlı Graph API’yi destekleyemiyorlar
  • EWS desteği, yakın gelecekte bu kullanıcıları desteklemenin bir yolu olacak
  • Graph API tarafında hâlâ çözülmemiş bazı sorunlar var
    • Graph API, masaüstü uygulamalarından çok web tabanlı servisler düşünülerek tasarlandı
    • Önce EWS desteğini eklemek, Graph API desteği geliştirilmeden önce bu sorunlara çözüm bulmak için zaman kazandırabilir
  • Rust ve EWS çalışmaları, Thunderbird’ün geri dönüş süresini azaltma ve yazılımın çekirdek kısmının dayanıklılığını artırmaya yönelik daha geniş bir çabanın parçası

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-21
Hacker News yorumları

  • EWS zaten emekliye ayrılacak ve 2 yıl sonra kaldırılacak denirken bunu neden uyguladıklarını anlamıyorum: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS, Outlook dışındaki istemcilerin çalışabilmesi için tek gerçekçi yol; MAPI de pek açık bir API değil
      EWS ortadan kalkarsa epey müşteri de ayrılacaktır; başta Microsoft'un sonuçlarını etkileyecek kadar olmayabilir
      Sonunda tüm e-postaların eşit olduğu ortaya çıkar ve Exchange Online tarihte bir dipnot hâline gelebilir. Microsoft'un e-posta işinde büyük çuvallamış olması dışarıdan biraz utandırıcı görünür ama gerçekte ille de öyle değil
      Bir e-posta sistemi işletmek acı verici; Microsoft'un gerçekten istediği şey, kazıp çıkarıp başka veri takıntılılarına satabileceği veri ve metaveriden ibaret. E-posta, depolama alanı açısından çoğunlukla statik ve büyük olsa da kişiler arası alışverişten altın madeni çıkabilir
      İdeal olan, bu acıyı AWS, Google gibi yerlere yükleyip müşterilere Outlook kullandırmak. Sonra da yeni Electron sürümü Outlook'ta olduğu gibi kimlik bilgilerini Microsoft bulutunda saklayacak şekilde değiştirip, bu kimlik bilgileriyle başkalarının bulutlarındaki e-posta verilerini kazımak; depolama maliyetini de onlar üstlenir. Harika
    • Sean Burke'ün ilgili Bugzilla hatasında söylediği gibi, şu anda Exchange Online'ı ve şirket içi kurulumları birlikte desteklemenin en iyi yolu EWS: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API de değerlendirildi ve ileride yeniden değerlendirilebilir; ancak şu anda EWS'ye göre destek kapsamı daha dar ve masaüstü uygulamalarının ihtiyaç duyduğu bazı özelliklerden yoksun
      Exchange Online'da EWS desteğinin kaldırılacağı duyurulmuş olsa da, kısa vadede geniş bir kullanıcı kitlesine erişim sağlaması ve uzun vadede şirket içi kurulum kullanıcılarını desteklemesi açısından hâlâ değerli
    • Çünkü Exchange gibi bir şeyle uğraşırken bir süre daha gerçekçi başka seçenek neredeyse yok
    • Herkes Exchange Online kullanmıyor

  • Amaç sadece Thunderbird kullanıcı sayısını artırmaksa stratejik olarak mantıklı; fakat ideolojik açıdan JMAP desteği çok daha iyi görünüyor

    • Bu sefer yapılan işlerin çoğunun ileride JMAP desteği eklemek için de temel olacağını düşünüyorum

  • Yakın zamanda Outlook yerine Thunderbird'ü denedim; Quantum güncellemesi öncesi Firefox'la aynı sorun vardı. Çok yavaş
    Yüzlerce ila binlerce e-posta içeren klasörler arasında geçiş yaparken gözle görülür bir gecikme oluyor; Outlook'ta ise geçiş fiilen anında

    • Windows kullanıyorsanız, benim deneyimime göre Thunderbird profilini Windows Defender istisnalarına ekleyene kadar Thunderbird neredeyse kullanılamaz seviyede
    • Benim deneyimim tamamen tersi. E-posta için Outlook kullanmak çok acı verici; özellikle arama düzgün çalışmıyor. Thunderbird'de expressionsearchNG kullanıyorum
      Takvim tarafında ise tam tersi, bu yüzden şu anda ikisini yan yana çalıştırıyorum. Sorunlardan biri, işte kullanmak zorunda olduğum Outlook sunucusuna giden iCal köprüsü gibi görünüyor
      Bu duyuruyla o kısım ne yazık ki değişmiyor. Bir süre Ericsson'ın sürdürdüğü EWS eklentisini kullanmıştım: https://github.com/Ericsson/exchangecalendar
      Ancak Mozilla arayüzleri hızla kırarak birçok eklenti geliştiricisini uzaklaştırmış gibi görünüyor. Şimdi bazı işlevleri yeniden çekirdeğe koyuyorlar; bunun iyi bir strateji olduğundan emin değilim. Bence bunun yerine kararlı arayüzlere odaklanmalılar

  • Exchange'den nefret ediyorum ama bu çalışma sevindirici. Artık Windows'a mahkûm olduğum durumlarda bile Exchange üzerinden düz metin e-posta göndermeyi başarabilirim belki

    • Bunu yapmak, teknik saflık ya da eski günlere özlem nedeniyle e-postaların çeşitli istemcilerde çok daha kötü görünmesine yol açabilir
      Düz metin e-postaların daha makul bir şekilde değil de sabit genişlikli yazı tipiyle render edilmesinin ne kadar yaygın olduğunu gördükten sonra, sırf “HTML e-posta iğrençtir” diye düz metni gerekçelendirmeyi zor buluyorum

  • “Thunderbird projesinin 20 yıllık tüm tarihinde kimse yeni bir posta protokolü desteği eklemedi” sözü teknik olarak doğru; ancak her büyük şirketin OAuth2 out-of-band kimlik doğrulama uygulaması, e-posta istemcisine özel ayarlar, yani geçici çözümler gerektirdi ve Thunderbird de bunlardan epeyce biriktirdi
    Bunlar genel posta protokolleri değil. IMAP, POP3, SMTP değil; HTTPS üzerinde çalışıyorlar
    “Hiç yeni posta protokolü eklenmemiş olması” iyi bir şey ve bu değişiklik iyi değil. Tescilli ayar desteği pratik ve anlaşılabilir, ama iyi bir şey değil
    E-postanın şirketlere göre onlarca farklı varyanta bölünmesi sorununu sadece geçici olarak hafifletiyor; uzun vadede ise insanların bu varyantları kabullenmesini teşvik ediyor

    • Çalışanlar şirketlerinin e-posta sağlayıcısını seçemez ve %99,99999'u için bu, uğruna ölünmeye değer bir tepe değil
      Öte yandan Thunderbird'ü istemci olarak kullanabilmek net kazanç ve pratik bir tercih
    • Büyük şirketlerden biri değil; iş e-postasında açık ara en yaygın kullanılan Microsoft Exchange, özellikle de Exchange Online

  • Başlığın neden değiştirildiğini anlamıyorum. Bu yazı Rust programlama hakkında
    “Bringing Exchange Support to Thunderbird” Thunderbird ve Exchange desteğiyle ilgili bir yazı gibi görünüyor, ama içeriği bu yazıdan anlaşılmıyor

    • Yazının ilk paragrafı dilden çok Exchange’e odaklandığı için, uygulama ayrıntısından ziyade özelliğin kendisi daha önemli görünüyor. Çoğu kullanıcı da bunu daha çok önemser
    • Aynı yazıyı daha önce tam başlığıyla paylaşmıştım ama ilgi görmedi: https://news.ycombinator.com/item?id=40095870
    • Ne demek istediğini anlamıyorum. Yazının ikinci yarısının tamamı Thunderbird’ün Exchange desteği hakkında

  • Tescilli bir spesifikasyonu desteklemek faydalı olabilir, ama Mozilla’nın e-posta gönderim sunucusunu (SMTP) otomatik keşfetme gibi standart uygulamaları önceliklendirmesini isterdim. Örneğin rfc6186 2011’de çıktı
    Şu anda kullanıcıların SMTP sunucusunun ana makine adını ve portunu elle girmesi gerekiyor; bu sitedekiler için sorun olmayabilir ama insanlığın geri kalan %99,9’u için hiç kullanıcı dostu değil
    Exchange’in tamamını uygulamak için gereken çaba, DNS/SRV üzerinden gönderim sunucusu keşfinden muhtemelen birkaç mertebe daha büyüktür. Mozilla’nın önceliklerini gerçekten anlamıyorum

    • Thunderbird’e Hotmail, Google, Yahoo hesapları eklerken böyle bilgileri girmediğimi sanıyorum. Sadece her e-posta adresini yazmıştım
      Bunlar özel durum olarak mı ele alınıyor?

  • Vay, yaklaşık 20 yıl önce BT’de çalıştığım zamanları hatırlattı. Neredeyse tamamen Microsoft ortamıydı, sadece birkaç kişi Linux kullanıyordu
    Exchange her zaman düzgün bir istemci bulmanın zor olduğu şeylerden biriydi; o zamanlar bu olsaydı gerçekten havalara uçardım

    • Şimdi de havalara uçuyorum
      Linux’ta Microsoft ürünleri kullanmak gerçekten acı verici; özellikle Edge kullanmıyorsanız Teams web sürümünü kullanımdan kaldırma sürecine girmiş gibi görünüyor :(
    • Bizde de aynı sorun vardı ama farklı bir yol seçtik. Şirketin Exchange ve SharePoint’i bırakmasını sağladık; o zamandan beri çok daha mutluyuz

  • “2012 civarında Mozilla’nın Thunderbird’den elini çekip sahipliği topluluğa devretmesinden, 2017’de Thunderbird’ün Mozilla Foundation’a yeniden katılmasına kadar ücretli bakım olmaması” gerçekten skandaldı
    Mozilla’nın tersine dönmüş önceliklerini gösteren başlıca örneklerden biri

    • Katılmıyorum. Dünya web/mobil uygulama tabanlı e-postaya geçti
      Bundan hoşlanmayabilirsiniz; ben de çok mutlu değilim. Yine de gerçek bu ve Mozilla’nın fonlamasına değecek bir şey değildi

  • Outlook kurulumundan uzaklaşmak isteyenlerin Outlook’un kendisiyle uğraşmadan sorunsuz geçiş yapabilmesi için PST dosyası içe aktarmanın varsayılan olarak dahil edilmesini isterdim
    PST dosyalarını okuyan ücretsiz bir proje zaten var; sadece ürün ailesine entegre edilmesi gerekiyor