दूसरी पीढ़ी के ईमेल पर एक खुला विचार

Note: यह लेख सिर्फ मेरे विचारों को व्यवस्थित करने के लिए है। इस पर गहराई से नहीं सोचा गया है, और इसे अच्छा विचार मानने की ज़रूरत नहीं है। उम्मीदें जितनी हो सके उतनी कम रखकर पढ़ें।

ईमेल की समस्याएँ

• कई पुरानी तकनीकें आज भी इस्तेमाल हो रही हैं, लेकिन ईमेल हर बार इस्तेमाल करने पर मुझे परेशान करता है।
• यूज़र के नज़रिए से ईमेल काफ़ी अच्छी तरह काम करता है। कभी-कभी स्पैम की वजह से बहुत सारे ईमेल आ जाते हैं, लेकिन ईमेल पुराना, भरोसेमंद, समझने में आसान और खोजने में अपेक्षाकृत आसान है।
• लेकिन ईमेल का बैकएंड पूरी तरह अव्यवस्थित है।

ईमेल बैकएंड की समस्याएँ

• ईमेल की कई सुविधाओं के लिए स्पष्ट specification नहीं है। उदाहरण के लिए, reply भेजते समय संदेश के ऊपर जवाब लिखा जाए या नीचे, यह स्पष्ट नहीं है।
• ईमेल में कौन-सा HTML डाला जा सकता है, यह भी स्पष्ट नहीं है। कभी-कभी Microsoft Outlook, Microsoft Word के HTML renderer का अनुचित इस्तेमाल करता है।
• ईमेल को encrypt कैसे किया जाए, यह भी स्पष्ट नहीं है। OpenPGP जैसी चीज़ बनाई गई थी, लेकिन उसका लगभग इस्तेमाल नहीं हुआ और उसमें बड़ी खामियाँ हैं।
• ईमेल की प्रामाणिकता हमेशा सत्यापित नहीं की जा सकती थी। इसलिए SPF बनाया गया, लेकिन SPF ने भी सभी समस्याएँ हल नहीं कीं। फिर DKIM बनाया गया, लेकिन DKIM ने भी सभी समस्याएँ हल नहीं कीं। फिर DMARC बनाया गया, लेकिन DKIM में ही बड़ी खामियाँ होने के कारण DMARC को भी bypass किया जा सकता है।
• BIMI नाम की एक और परत जोड़ी गई, लेकिन वह भी DMARC पर निर्भर है, और DMARC DKIM पर निर्भर है, जबकि DKIM में खामियाँ हैं।
• DMARC होने पर भी 68.2% records p=none पर सेट हैं। इसका मतलब है कि DMARC मूल रूप से कुछ भी नहीं करता।
• ऊपर बताई गई सभी चीज़ों और आक्रामक anti-spam policies की वजह से self-hosted email चलाना बहुत मुश्किल है।
• और अंत में IP reputation management का मसला है। कुछ IP addresses दूसरे पतों की तुलना में ज़्यादा "clean" माने जाते हैं, खासकर SendGrid या AWS SES जैसे shared systems में। इससे bulk mail accounts रजिस्टर करना जटिल हो जाता है और वैध ईमेल भी अक्सर spam के रूप में वर्गीकृत हो जाते हैं।

दूसरी पीढ़ी के ईमेल पर परिकल्पना

• एक नया DNS record MX2 बनाया जाए। ज़्यादातर ईमेल सेवाओं के पास MX2 और MX records होंगे। पुरानी सेवाओं के पास सिर्फ MX होगा।
• अगर 20 साल पुराना कोई ईमेल client संदेश भेजने की कोशिश करेगा, तो वह MX record देखकर संदेश भेजेगा। आधुनिक clients MX2 देखकर संदेश भेजेंगे।
• MX2 लागू करने वाली ईमेल सेवाएँ एक public date प्रकाशित करेंगी, और उस तारीख़ के बाद MX record के ज़रिए भेजे गए सभी संदेशों को अपने-आप spam के रूप में वर्गीकृत करेंगी।

दूसरी पीढ़ी के ईमेल की प्राथमिकताएँ

1. ईमेल के लिए standardized HTML specification और conformance test suite उपलब्ध कराना।
2. ईमेल chain preference या ईमेल से जुड़ी अन्य preferences के लिए headers उपलब्ध कराना।
3. HTML view के साथ text-only non-HTML copy उपलब्ध कराना।
4. सभी MX2 records में public key शामिल होना चाहिए।
5. ईमेल की प्रामाणिकता और integrity की पुष्टि के लिए hash बनाना, उसे encrypt करना, और header में जोड़ना।
6. SPF, DKIM, DMARC को हटाकर केवल एक MX2 record पर standardize करना, ताकि self-hosted email stack सरल हो सके।
7. IP address की जगह domain के आधार पर ईमेल को authenticate करना।
8. MX2 लागू करने वाले clients OpenPGP की जगह लेने के लिए नई encryption scheme चुन सकें।

अतिरिक्त विचार

• बड़े आकार की फ़ाइलें साझा करने का कोई तरीका होना चाहिए।
• अगर Google और Microsoft शामिल नहीं होते, तो MX2 कभी वास्तविकता नहीं बनेगा।
• SMTP को HTTP, standardized REST API, और JSON body से बदलने पर भी विचार किया जा सकता है।
• HTML का इस्तेमाल करना अपने-आप में विवादास्पद हो सकता है। ईमेल मूल रूप से HTML के लिए डिज़ाइन नहीं किया गया था।
• नए standard को सख़्ती से लागू करने का एक अवसर है।

GN⁺ की राय

• ईमेल सिस्टम की जटिलता और सुरक्षा समस्याओं को हल करने की कोशिश काफ़ी दिलचस्प है। खासकर, ईमेल की प्रामाणिकता और integrity सुनिश्चित करने के लिए नया तरीका प्रस्तावित करना उपयोगी हो सकता है।
• लेकिन नया standard लाना बहुत मुश्किल काम है। खासकर Google और Microsoft जैसे बड़े players की भागीदारी अनिवार्य है।
• HTML के इस्तेमाल को लेकर विवाद अब भी मौजूद है। सुरक्षा समस्याओं को हल करने के लिए किसी दूसरी markup language पर विचार करने की ज़रूरत हो सकती है।
• नए standard को सख़्ती से लागू करना आदर्श है, लेकिन व्यावहारिक रूप से यह मुश्किल हो सकता है। standard drift और implementation errors को रोकने के लिए अतिरिक्त mechanisms की ज़रूरत होगी।
• ईमेल सिस्टम का केंद्रीकरण नए standard को लाने में मदद कर सकता है, लेकिन साथ ही यह कुछ विशेष कंपनियों पर निर्भरता भी बढ़ा सकता है।

[cometkim]

कम से कम rendering सुधार के मामले में, Google और Microsoft ने पहले ही निवेश किया है... क्योंकि दोनों ने AMP Email प्रोजेक्ट में भाग लिया और उसका समर्थन किया था।

[coremaker]

JSON की तरह data standard बनाना अच्छा है।
लेकिन rendering spec पर भी साथ में चर्चा करनी होगी, इसलिए यह आसान नहीं होगा।

HTML को चुनने का कारण भी
क्या HTML+CSS rendering spec पर मुफ़्त में सवारी करने के लिए नहीं था?

[ldmsys]

जैसा कि ऊपर कुछ लोगों ने पहले ही अत्यधिक उदाहरण के तौर पर Shop Mail का ज़िक्र किया है। व्यक्तिगत रूप से, मैं इस बात को लेकर काफ़ी संशय में हूँ कि पहले से अच्छी तरह चल रहे प्रोटोकॉल को खुलेआम deprecated के रूप में वर्गीकृत किया जाए और केवल किसी नए, असंगत प्रोटोकॉल standard के साथ ही compatibility बनाई जाए।

[unsure4000]

4. सभी MX2 records में public key शामिल होनी चाहिए।
   यह थोड़ा अजीब लगता है, क्योंकि ऐसा लगता है कि service providers इस public key को user द्वारा submit की गई public key के बजाय अपनी बनाई हुई public key बना देंगे...

[iolothebard]

इसलिए हमने SsapMail बनाया… (हूँ? नहीं, वो वाला नहीं… )

[xguru]

ईमेल सिस्टम सुविधाजनक और अच्छा है, लेकिन सच में लगता है कि प्रोटोकॉल में धीरे-धीरे सुधार की ज़रूरत है.
आने वाले कई दशकों बाद भी इसे इसी तरीके से इस्तेमाल करना थोड़ा...

[GN⁺]

Hacker News राय

Hacker News टिप्पणियों का संक्षिप्त सार

• ईमेल सिस्टम की जटिलता और interoperability

  • इंटरनेट ईमेल सेवा चलाने के अनुभव के आधार पर, ईमेल सिस्टम जटिल है, लेकिन इसे व्यापक रूप से अपनाया गया है और इसकी interoperability बहुत अच्छी है।
  • नया सिस्टम लाने में मौजूदा सिस्टम पर हुए विशाल R&D निवेश से मुकाबला करने की कठिनाई होती है।
  • अगर नया ईमेल सिस्टम प्रस्तावित करना हो, तो IETF या M3AAWG जैसी जगहों पर प्रस्ताव देना बेहतर होगा।

• ईमेल की अस्पष्टता और समस्याएँ

  • ईमेल headers में duplicate या परस्पर विरोधी values होने से भ्रम पैदा हो सकता है।
  • केवल ASCII वाले headers में 8-bit values शामिल होने जैसी कई समस्याएँ मौजूद हैं।
  • ईमेल thread प्रबंधन का तरीका भी standardize नहीं है, जिससे समस्याएँ पैदा होती हैं।

• ईमेल के केंद्रीकरण की समस्या

  • ईमेल का केंद्रीकरण वांछनीय नहीं है। कंपनियाँ मानवता के लिए सबसे अच्छे विकल्प के बजाय अपने हित में काम करने की अधिक संभावना रखती हैं।
  • self-hosted ईमेल बहुत कठिन नहीं है, और भरोसेमंद provider के जरिए इसे आसानी से host किया जा सकता है।

• HTML ईमेल की समस्याएँ

  • HTML ईमेल phishing, fraud जैसी समस्याएँ पैदा कर सकता है।
  • अगर ईमेल को फिर से डिज़ाइन किया जाए, तो HTML को हटाकर Markdown जैसे फ़ॉर्मैट का उपयोग करना बेहतर हो सकता है।

• ईमेल की asynchronous प्रकृति बनाए रखने की ज़रूरत

  • ईमेल asynchronous रहना चाहिए, और यह 24 घंटे काम करने की संस्कृति को रोकने वाली आख़िरी तकनीकी रक्षा पंक्ति है।
  • लोग बेहतर सिस्टम नहीं अपनाते, इसका एक कारण यही है।

• ईमेल सर्वर चलाने की कठिनाइयाँ

  • ईमेल सर्वर चलाना लगातार कठिन होता जा रहा है, क्योंकि बड़े providers की requirements पूरी करनी पड़ती हैं।
  • छोटे सर्वर बड़े providers या spammers के कारण बाहर होते जा रहे हैं।

• वैध ईमेल की परिभाषा

  • वैध ईमेल की परिभाषा व्यक्तिपरक है। spam इंटरनेट को बर्बाद कर रहा है, और इसे रोकने के लिए लागत लगाने का कोई तरीका चाहिए।

• ईमेल सिस्टम में सुधार की आवश्यकता

  • भले ही ईमेल सिस्टम को फिर से डिज़ाइन किया जाए, मौजूदा ईमेल सिस्टम को बनाए रखते हुए उसमें सुधार करना अधिक उचित है।
  • आधुनिक encryption सिस्टम और sender authentication सिस्टम लाने की ज़रूरत है।

• स्पैम-रोधी चेकलिस्ट

  • spam रोकने के लिए कुछ implementation changes की ज़रूरत है।
  • mail forwarder और SMTP server को जितनी जल्दी हो सके forwarding करनी चाहिए, और spam filtering को SMTP स्तर पर reject करना बेहतर है।

स्पैम-रोधी आइडिया चेकलिस्ट