Mozilla Thunderbird में Exchange सपोर्ट नेटिव रूप से आएगा

 (blog.thunderbird.net)
1 पॉइंट द्वारा GN⁺ 2024-04-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उद्यमों और शैक्षणिक संस्थानों में व्यापक रूप से इस्तेमाल होने वाले Microsoft Exchange को Thunderbird जुलाई 2024 ESR से नेटिव रूप से सपोर्ट करने की योजना में है, और शुरुआती दायरा ईमेल तक सीमित होगा
  • यह काम Exchange Web Services(EWS) सपोर्ट से आगे जाकर, 20 साल से अधिक पुराने मेल प्रोटोकॉल आर्किटेक्चर और पुराने C++ कोड की सीमाओं को धीरे-धीरे सुलझाने का अवसर बन रहा है
  • इम्प्लीमेंटेशन भाषा के रूप में Rust चुनी गई है; इसके मुख्य कारण memory safety, native performance, modularity, और Firefox के साथ साझा CI व XPCOM interoperability हैं
  • EWS integration के दौरान xpcom_async, moz_http, xml_struct, ews जैसे crates बनाए गए, जो XPCOM-based HTTP calls और XML serialization को Rust-friendly तरीके से wrap करते हैं
  • EWS Exchange Online में अक्टूबर 2026 के बाद उपलब्ध नहीं रहेगा, लेकिन on-premises Exchange Server इस्तेमाल करने वाले बहुत से users के कारण Thunderbird के लिए यह सपोर्ट अब भी आवश्यक है

जुलाई 2024 ESR में Exchange सपोर्ट का दायरा

  • Thunderbird अगले ESR(Extended Support) release, यानी जुलाई 2024 में Exchange सपोर्ट नेटिव रूप से देने की योजना में है
  • शुरुआती दायरा ईमेल तक सीमित है
    • Calendar और address book सपोर्ट बाद में जोड़ा जाएगा
    • हाल तक Exchange functionality केवल add-ons के जरिए ही उपलब्ध थी
  • इम्प्लीमेंटेशन लक्ष्य Microsoft की Exchange Web Services(EWS) API है
    • EWS HTTP के ऊपर काम करता है
    • request और response body XML का उपयोग करते हैं

20 साल से अधिक पुराने मेल आर्किटेक्चर का बोझ

  • Thunderbird का मौजूदा मेल प्रोटोकॉल आर्किटेक्चर Thunderbird से भी पुराने code पर आधारित है
    • इसे 20 साल से अधिक पहले Netscape Communicator के हिस्से के रूप में विकसित किया गया था
    • 2012 में Mozilla द्वारा Thunderbird का ownership community को सौंपने के बाद, 2017 में Mozilla Foundation में फिर से शामिल होने तक paid maintenance नहीं था
  • बड़े architectural direction के बिना temporary changes जमा होते गए, जिससे आधुनिक standards का इस्तेमाल न करने वाला बहुत सा C++ code बचा रह गया
  • Thunderbird project के 20 वर्षों में किसी नए mail protocol का support कभी जोड़ा नहीं गया था
    • mail protocols आधुनिक usage patterns के हिसाब से बदलते रहे, लेकिन संबंधित structure अपडेट नहीं हो पाया
    • बहुत सारा institutional knowledge भी खत्म हो चुका है
  • Exchange support Thunderbird architecture की सीमाओं को समझने और उन्हें क्रमिक रूप से हल करने का पहला संगठन-चालित प्रयास है

Rust चुनने के कारण

  • Rust को Thunderbird के नए protocol support की implementation language के रूप में चुना गया
  • चयन के पीछे Rust के सामान्य फायदे और Thunderbird-विशिष्ट स्थितियां दोनों हैं
    • Memory safety: Thunderbird किसी भी व्यक्ति से input प्राप्त करता है जो ईमेल भेजता है, इसलिए security bugs कम करना महत्वपूर्ण है
    • Performance: Rust native code के रूप में चलता है
    • Modularity और ecosystem: Rust के module structure और email-related ecosystem का लाभ लिया जा सकता है
  • Thunderbird Firefox code के ऊपर बना है, इसलिए Rust adoption की स्थितियां पहले से मौजूद हैं
    • Firefox के साथ साझा CI infrastructure Rust को support करता है
    • Firefox के XPCOM(Cross-Platform Component Object Model) interoperability layer के जरिए Rust, C++, JavaScript के बीच calls संभव हैं
  • Rust के types और tools ऐसे APIs बनाने में मदद करते हैं जिन्हें गलत तरीके से इस्तेमाल करना कठिन हो
    • circular references से बचा जा सकता है, या ऐसी functions बनाई जा सकती हैं जिन्हें meaningless values के साथ call नहीं किया जा सके
    • documentation tools भाषा में default रूप से शामिल हैं, जो छोटी team के लिए उपयोगी है
  • Modular crates के रूप में बनाने पर Thunderbird for Android/K-9 Mail जैसे दूसरे projects में भी reuse संभव है

Build system और XPCOM constraints

  • Thunderbird के अंदर पहला Rust component चलाते समय build system पहली बाधा बना
  • Thunderbird Firefox code की सामान्य dependency की तरह जुड़ी संरचना नहीं है
    • build के समय Firefox code लाया जाता है
    • Thunderbird code को Firefox के subtree के रूप में लाया जाता है
    • build configuration file से उस subtree की ओर इशारा किया जाता है
  • Firefox पूरे tree का Cargo dependency graph बनाने के लिए individual crates को एक Cargo workspace में इकट्ठा करता है
    • Thunderbird को भी अपना Cargo workspace चाहिए था, लेकिन Cargo nested workspaces की अनुमति नहीं देता
    • समाधान के रूप में Thunderbird का अपना workspace define किया गया, और upper build tool mach को Firefox workspace के बजाय इसे build करने के लिए configured किया गया
    • नए mach subcommand से dependencies और lockfile को parent के साथ sync किया जाता है, और resulting superset को vendoring किया जाता है
  • XPCOM C++-centric design वाला है, इसलिए Rust development experience smooth नहीं है
    • XPCOM interfaces को implement और use करने में बहुत boilerplate चाहिए
    • rust-analyzer जैसे tools का पूरा लाभ लेना मुश्किल है
    • Firefox ने XPCOM dependency काफी कम कर दी है, लेकिन Thunderbird maintenance gap के दौरान वैसा cleanup नहीं कर पाया
  • नए mail protocol support के लिए XPCOM में defined सैकड़ों functions का implementation चाहिए
    • मौजूदा protocol implementations shared behavior देने वाली C++ classes inherit करके बोझ कम करते हैं
    • Rust में यह सीधे संभव नहीं, इसलिए protocol-specific logic Rust में implement की जाती है
    • C++ bridge class internal crate ews_xpcom और मौजूदा shared behavior code को जोड़ती है
  • Thunderbird में Rust components बनाने का तरीका documentation में संकलित है

HTTP requests को Rust-जैसे तरीके से संभालना

  • Firefox में necko networking component के जरिए HTTP stack पहले से मौजूद है
  • necko C++ में लिखा गया है और XPCOM के जरिए expose होता है, इसलिए Rust से सीधे इस्तेमाल करने में बहुत boilerplate लगता है
    • सरल GET request के लिए भी कई XPCOM objects बनाने पड़ते हैं
    • XPCOM pointer lifetimes manage करता है, लेकिन Rust compiler यह नहीं जानता, इसलिए unsafe blocks चाहिए
    • जरूरी interfaces callback-based हैं
  • Thunderbird का internal crate xpcom_async XPCOM asynchronous work को Rust की async/await syntax में बदलता है
    • callbacks से आने वाला data buffer करता है
    • Rust के Future trait को implement करता है ताकि caller await कर सके
    • Rust का Future, JavaScript के Promise या Python coroutine जैसा है
  • internal crate moz_http, reqwest से प्रेरित HTTP client देता है
    • जरूरी XPCOM objects बनाने को handle करता है
    • standard XPCOM error handling की तुलना में अधिक Rust-like error handling देता है

EWS XML serialization और नए crates

  • EWS में सबसे मुश्किल काम Thunderbird internal data structures और EWS द्वारा मांगे या दिए जाने वाले XML के बीच conversion है
  • मौजूदा XML serialization/deserialization crates जरूरतें पूरी नहीं कर पाए
    • serde का data model XML से अच्छी तरह मेल नहीं खाता, इसलिए attributes और elements अलग करना मुश्किल है
    • EWS XML namespaces के प्रति sensitive है, लेकिन यह serde में familiar concept नहीं है
    • XML के लिए serde family के crates में हर field की serialization method को explicitly annotate करना पड़ता है
    • EWS सैकड़ों types और हर type में दर्जनों fields define करता है, इसलिए boilerplate संभालना मुश्किल हो जाता है
  • मौजूदा serde-based implementation XML को Rust में deserialize करने के लिए पर्याप्त थी, लेकिन संतोषजनक serialization tool नहीं मिला
  • नया crate xml_struct XML serialization behavior define करने वाला trait और procedural derive macro प्रदान करता है
    • Rust data structures के लिए trait implementation अपने-आप generate करता है
    • मौजूदा quick_xml crate के ऊपर बनाया गया है
    • XML और Rust के बीच कम-boilerplate mapping को लक्ष्य बनाता है
    • Thunderbird/Firefox internals पर निर्भर नहीं है और शुरुआती development stage में है
  • नया crate ews EWS tasks के लिए types और XML serialization/deserialization API define करता है
    • xml_struct और serde पर आधारित है
    • शुरुआती development stage में है और GitHub पर public है

Testing, error handling, UI connection plans

  • अगले major features जोड़ने से पहले automated tests मजबूत किए जा रहे हैं
    • unit tests के साथ-साथ integration tests के लिए mock EWS server जोड़ा गया है
    • testing को मजबूत करने की प्रक्रिया में कुछ crashes और double-sync समस्याएं सामने आईं और ठीक की गईं
    • नए features को test और verify करना आसान हो गया है
  • EWS error handling में सुधार हो रहा है
    • EWS का error behavior अक्सर पर्याप्त रूप से documented नहीं होता
    • पूरी request throttling या गलत structure के कारण fail हो सकती है
    • request के कुछ हिस्से सफल हो सकते हैं और कुछ गलत ID के कारण fail हो सकते हैं
    • कुछ errors protocol level पर handle किए जा सकते हैं, लेकिन कुछ में user intervention चाहिए या उन्हें सुलझाना मुश्किल हो सकता है
  • EWS protocol support ews और internal ews_xpcom crates के जरिए extend हो रहा है और Thunderbird UI से जोड़ा जा रहा है
    • हालिया patch से EWS account को Thunderbird में add करना संभव हुआ
    • remote server से account की folder hierarchy sync की जा सकती है
    • synced folders को UI में दिखाया जा सकता है
    • फिलहाल यह alpha-stage feature build flag और settings values के पीछे छिपा है
  • अगला काम remote server से message list लाने की functionality और Thunderbird के outgoing mail support को generalize करना है
  • Maintenance के लिए यह document किया जा रहा है कि हर component कैसे जुड़ता है, मौजूदा Thunderbird mail protocol architecture क्या है, और भविष्य की improvement direction क्या होगी

EWS और Microsoft Graph का संबंध

  • EWS Exchange Online में अक्टूबर 2026 के बाद इस्तेमाल नहीं किया जा सकेगा
  • project की preliminary research में पाया गया कि on-premises Exchange Server का इस्तेमाल जारी रखने वाले users की संख्या काफी है
    • कई enterprises और educational institutions अपने hardware पर Exchange Server चलाते हैं
    • ऐसी on-premises installations आम तौर पर EWS support करती हैं
    • Azure-based Graph API support नहीं कर सकतीं
  • EWS support निकट भविष्य में ऐसे users को support करने का साधन बनेगा
  • Graph API में अभी भी कुछ अनसुलझे मुद्दे हैं
    • Graph API desktop applications के बजाय web-based services को ध्यान में रखकर बनाई गई है
    • पहले EWS support जोड़ने से Graph API support बनाने से पहले उन समस्याओं के समाधान खोजने का समय मिल सकता है
  • Rust और EWS पर काम Thunderbird के turnaround को कम करने और software core की resilience बढ़ाने के बड़े प्रयास का हिस्सा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-21
Hacker News की राय

  • समझ नहीं आता कि इसे क्यों implement किया जा रहा है, जबकि EWS पहले ही deprecate होने वाला है और दो साल बाद हटा दिया जाएगा: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS ही गैर-Outlook clients के काम करने का इकलौता व्यावहारिक तरीका है, और MAPI कोई खास खुला API नहीं है
      EWS हटने पर काफी ग्राहक भी चले जाएंगे, और शुरुआत में शायद इससे Microsoft के results पर चोट लगने लायक असर न पड़े
      फिर आखिरकार यह बात सामने आएगी कि सभी email बराबर हैं, और Exchange Online इतिहास में बस एक footnote बन सकता है। ऊपर से देखने में यह थोड़ा शर्मनाक लगेगा कि Microsoft ने email में बड़ी गड़बड़ कर दी, लेकिन असल में जरूरी नहीं कि ऐसा ही हो
      email systems चलाना दर्दनाक है, और Microsoft सच में सिर्फ data और metadata चाहता है जिसे निकालकर दूसरे data-obsessed लोगों को बेचा जा सके। storage के हिसाब से email आमतौर पर static और बड़ा होता है, लेकिन लोगों के बीच होने वाले आदान-प्रदान में सोने की खान मिल सकती है
      आदर्श रूप से AWS, Google जैसी जगहों को यह दर्द उठाने दें, और customers से Outlook इस्तेमाल करवाएं। फिर नए Electron version वाले Outlook की तरह credentials को Microsoft cloud में store करवाने पर shift करें, और उन्हीं credentials से दूसरों के cloud में पड़े email data को mine करें, जबकि storage cost वे लोग उठाएं। बहुत बढ़िया
    • जैसा Sean Burke ने संबंधित Bugzilla bug में कहा था, अभी EWS ही Exchange Online और on-premises installations दोनों को support करने का सबसे अच्छा तरीका है: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API पर भी विचार हुआ है और आगे फिर विचार हो सकता है, लेकिन फिलहाल इसका support scope EWS से छोटा है और desktop application के लिए जरूरी कुछ capabilities इसमें नहीं हैं
      भले ही Exchange Online में EWS support हटाने की घोषणा हो चुकी है, फिर भी short term में बड़े user base को access देना और long term में on-premises installation users को support करना अब भी मूल्यवान है
    • क्योंकि Exchange जैसी चीज़ों से निपटते समय फिलहाल कोई व्यावहारिक दूसरा विकल्प बहुत कम है
    • हर कोई Exchange Online इस्तेमाल नहीं करता

  • अगर लक्ष्य बस Thunderbird users बढ़ाना है, तो strategy के लिहाज से यह समझ में आता है, लेकिन ideology के लिहाज से JMAP support कहीं बेहतर दिखता है

    • इस बार जो काम किया गया है, उसका ज्यादातर हिस्सा आगे JMAP support जोड़ने में भी core साबित होगा

  • हाल में Outlook की जगह Thunderbird इस्तेमाल करके देखा, लेकिन इसमें Quantum update से पहले वाले Firefox जैसी समस्या थी। बहुत धीमा
    सैकड़ों से हजारों mails वाले folders के बीच switch करते समय साफ delay दिखता है, जबकि Outlook में यह लगभग तुरंत हो जाता है

    • अगर आप Windows इस्तेमाल करते हैं, तो मेरे अनुभव में Thunderbird profile को Windows Defender exception में जोड़ने से पहले Thunderbird लगभग इस्तेमाल के लायक नहीं था
    • मेरा अनुभव बिल्कुल उलटा है। mail के लिए Outlook इस्तेमाल करना बहुत पीड़ादायक है, खासकर search ठीक से काम नहीं करती। Thunderbird में मैं expressionsearchNG इस्तेमाल करता हूं
      calendar के लिए मामला ठीक उलटा है, इसलिए अभी दोनों को साथ-साथ चला रहा हूं। एक समस्या शायद उस Outlook server तक जाने वाला iCal bridge है जिसे company में इस्तेमाल करना पड़ता है
      इस announcement से वह हिस्सा दुर्भाग्य से नहीं बदलेगा। कुछ समय तक मैंने Ericsson द्वारा maintain किया गया EWS add-on इस्तेमाल किया था: https://github.com/Ericsson/exchangecalendar
      लेकिन लगता है Mozilla ने interfaces को तेजी से तोड़कर कई plugin developers को दूर कर दिया। अब वे फिर कुछ features को core में डाल रहे हैं, लेकिन मुझे नहीं पता यह अच्छी strategy है या नहीं। मेरे हिसाब से उन्हें stable interfaces पर ध्यान देना चाहिए

  • Exchange पसंद नहीं है, लेकिन यह काम अच्छा लगा। अब शायद Windows में फंसे रहने पर भी Exchange से plain text mail सफलतापूर्वक भेज पाऊं

    • ऐसा करने पर technical purity या पुराने दिनों की nostalgia के कारण कई email clients में mail कहीं ज्यादा खराब दिख सकता है
      जब मैंने देखा कि plain text emails कितनी बार किसी बेहतर तरीके के बजाय monospace font में render होते हैं, तो सिर्फ “HTML email घृणित है” के आधार पर plain text को justify करना मुश्किल लगा

  • “Thunderbird project के पूरे 20 साल के इतिहास में किसी ने नया mail protocol support add नहीं किया” यह बात technically सही है, लेकिन हर बड़ी company के OAuth2 out-of-band authentication implementations के लिए email client-specific special settings, यानी workarounds, चाहिए थे और Thunderbird ने भी ऐसी काफी चीज़ें जमा कर ली हैं
    ये सामान्य mail protocols नहीं हैं। ये IMAP, POP3, SMTP नहीं, बल्कि HTTPS के ऊपर चलते हैं
    “कभी नया mail protocol add नहीं किया” अच्छी बात है, और यह बदलाव अच्छा नहीं है। proprietary settings support practical और समझने लायक है, लेकिन अच्छी बात नहीं है
    यह email के company-specific दर्जनों variants में बंटने की समस्या को थोड़ी देर के लिए कम करता है, और long term में लोगों को ऐसे variants स्वीकार करने के लिए बढ़ावा देता है

    • employees अपने company email provider नहीं चुन सकते, और 99.99999% लोगों के लिए यह जान देकर लड़ने वाली लड़ाई नहीं है
      दूसरी ओर Thunderbird को client के रूप में इस्तेमाल कर पाना net benefit और practical choice है
    • यह बड़ी companies में से कोई एक नहीं, बल्कि work email में भारी रूप से सबसे आम इस्तेमाल होने वाला Microsoft Exchange, खासकर Exchange Online है

  • समझ नहीं आ रहा कि शीर्षक क्यों बदला गया। यह लेख Rust programming के बारे में है
    “Bringing Exchange Support to Thunderbird” Thunderbird और Exchange support के बारे में लेख जैसा लगता है, लेकिन इसकी जानकारी इस लेख से नहीं मिलती

    • लेख का पहला पैराग्राफ भाषा से ज़्यादा Exchange पर केंद्रित है, इसलिए implementation से ज़्यादा feature खुद अहम लगता है। ज़्यादातर users भी उसी की ज़्यादा परवाह करते हैं
    • यही लेख पहले पूरे title के साथ पोस्ट किया था, लेकिन ध्यान नहीं मिला: https://news.ycombinator.com/item?id=40095870
    • समझ नहीं आ रहा आप क्या कह रहे हैं। लेख का पूरा दूसरा हिस्सा Thunderbird के Exchange support के बारे में है

  • proprietary specifications का support उपयोगी तो होगा, लेकिन अच्छा होता अगर Mozilla email submission server (SMTP) auto-discovery जैसी standards implementation को प्राथमिकता देता। उदाहरण के लिए rfc6186 2011 में आया था
    अभी users को SMTP server का hostname और port खुद डालना पड़ता है, जो इस साइट के लोगों के लिए ठीक हो सकता है, लेकिन बाकी 99.9% इंसानों के लिए बिल्कुल friendly नहीं है
    पूरा Exchange implement करने में लगने वाली मेहनत DNS/SRV के जरिए submission server discovery से शायद कई orders of magnitude ज़्यादा होगी। Mozilla की priorities सच में समझ नहीं आतीं

    • मुझे नहीं लगता कि Thunderbird में Hotmail, Google, Yahoo accounts जोड़ते समय मैंने ऐसी जानकारी डाली थी। बस हर email address ही इस्तेमाल किया था
      क्या इन्हें special cases के तौर पर handle किया जाता है?

  • वाह, करीब 20 साल पहले IT में काम करने का समय याद आ गया। लगभग पूरी तरह Microsoft environment था और बस कुछ लोग Linux इस्तेमाल करते थे
    Exchange हमेशा उन चीज़ों में से था जिसके लिए अच्छा client ढूंढना मुश्किल होता था, और अगर उस समय यह होता तो मैं सच में खुशी से झूम उठता

    • आज भी खुशी से झूम उठूंगा
      Linux पर Microsoft products इस्तेमाल करना सच में बहुत दर्दनाक है, खासकर अगर आप Edge इस्तेमाल नहीं करते तो लगता है कि वे Teams web version को बंद करने की प्रक्रिया में हैं :(
    • हमारे पास भी वही समस्या थी, लेकिन हमने अलग रास्ता चुना। हमने company से Exchange और SharePoint छुड़वा दिए, और उसके बाद से हम कहीं ज़्यादा खुश हैं

  • “लगभग 2012 में Mozilla ने Thunderbird से हाथ खींचकर ownership community को सौंप दी, और 2017 में Thunderbird के फिर से Mozilla Foundation में शामिल होने तक paid maintenance नहीं था” — यह सच में scandal था
    यह Mozilla की उलटी priorities दिखाने वाला classic example है

    • सहमत नहीं। दुनिया web/mobile app-based mail की ओर बढ़ गई थी
      आपको यह पसंद न हो सकता है, और मैं भी इससे बहुत खुश नहीं हूं। फिर भी यह सच है, और Mozilla के लिए इसमें funding देना worth नहीं था

  • अच्छा होगा अगर Outlook install से दूर जाने वाले लोग Outlook को छेड़े बिना smoothly switch कर सकें, इसके लिए PST file import built-in शामिल कर दिया जाए
    PST files पढ़ने वाला free project पहले से मौजूद है, बस उसे suite में integrate करना है

    • PowerShell के लिए Exchange module का इस्तेमाल करके PST export Exchange 2010 से मौजूद था। “New-MailboxExportRequest” देखें: https://learn.microsoft.com/en-us/powershell/module/exchange...
      Edit: अरे, नहीं। यह तो on-premises only है। यह सच में बेवकूफी है