ईमेल का भविष्य

• ऐसे माहौल में जहाँ AI inbox पढ़ता है, उसका सारांश बनाता है और काम भी करता है, sender verification ईमेल भरोसे की मुख्य शर्त बन जाती है
• SPF, DKIM, DMARC मिलकर email authentication की बुनियादी संरचना बनाते हैं, जो server authority, message integrity और failure policy को जोड़ती है
• जैसे-जैसे AI filter और AI assistant tools ईमेल अनुभव की standard feature बन रहे हैं, authentication result spam·phishing की पहचान और automated actions के लिए महत्वपूर्ण input value बन रहे हैं
• 2024 की शुरुआत में Google और Yahoo ने bulk senders के लिए DMARC configuration अनिवार्य करना शुरू किया, जिससे authentication infrastructure स्थिर delivery की बुनियादी शर्त बन गई
• authentication domain identity की पुष्टि करता है, लेकिन intent की गारंटी नहीं देता; automated email environment में यह impersonation की लागत और जटिलता बढ़ाने का काम करता है

---

ईमेल authentication: भरोसे की वह परत जिस पर ईमेल का भविष्य निर्भर है

• ईमेल लंबे समय से spoofing problem से जूझता रहा है, और कोई भी ईमेल के “From” field में कुछ भी डाल सकता था
• पहले सावधान उपयोगकर्ता थोड़े अलग domain name, अवास्तविक urgency, या अटपटी wording जैसे संकेतों से समस्या पहचान सकते थे
• AI के व्यापक उपयोग के साथ, उपयोगकर्ताओं का ईमेल संभालने का तरीका बदल रहा है, और अब यह अधिक महत्वपूर्ण हो गया है कि स्रोत को वास्तव में verify किया जा सकता है या नहीं, बजाय इसके कि message बस पहुँचा है या नहीं
• वे standards जिनके बारे में ज़्यादातर ईमेल users को कभी सोचने की ज़रूरत नहीं पड़ी, चुपचाप ईमेल अनुभव की नींव बन चुके हैं

ईमेल authentication क्या है

• ईमेल authentication तीन आपस में जुड़े standards से मिलकर बना है: SPF, DKIM, DMARC
• SPF यह जाँचता है कि message भेजने वाले server को उस domain की ओर से भेजने की अनुमति है या नहीं
• DKIM हर message पर cryptographic signature जोड़ता है, ताकि receiving server यह जाँच सके कि transit के दौरान उसमें बदलाव हुआ या नहीं
• DMARC, SPF और DKIM को साथ जोड़ता है और receiving server को निर्देश देता है कि check में fail हुए messages को reject करना है, quarantine करना है या pass होने देना है
• ये तीनों standards inbox को यह तय करने में सक्षम बनाते हैं कि बैंक या employer की तरफ़ से दिखने वाला message वास्तव में उसी domain से आया है या नहीं
• authentication के बिना spoofed messages और legitimate messages में फर्क करना संभव नहीं होता, और ईमेल interaction के तरीके बदलने के साथ यह समस्या और बड़ी हो रही है

AI ईमेल में कैसे शामिल हो रहा है

• ईमेल अनुभव में दो तरह के AI standard feature के रूप में स्थापित हो रहे हैं
• पहला है AI filtering, जो spam, phishing और attention-worthy messages की पहचान करता है
  • ऐसे systems कई वर्षों से मौजूद हैं, लेकिन उनके आधुनिक versions कहीं अधिक शक्तिशाली हो गए हैं
  • authentication results, AI filters के निर्णय लेने में लगातार अधिक केंद्रीय input बनते जा रहे हैं
• दूसरा है AI assistant tools, जो inbox का सारांश बनाते हैं, action items उजागर करते हैं, reply draft करते हैं और कुछ मामलों में user की ओर से कार्रवाई भी करते हैं
• Fastmail ने inbox में AI को integrate नहीं किया है, और user mail को background में models से process नहीं किया जाता
  • MCP server एक API endpoint है, जो केवल तब चुने गए AI client से जुड़ सकता है जब user ने स्पष्ट रूप से अनुमति दी हो
  • अगर user इसे connect नहीं करता, तो कुछ भी नहीं बदलता
• व्यापक ईमेल ecosystem में, inbox के भीतर autonomous ढंग से काम करने वाले AI assistants अब अधिक आम होते जा रहे हैं
• जब कोई इंसान किसी संदिग्ध ईमेल को पढ़ता है, तो वह यह देख सकता है कि sender domain में अतिरिक्त अक्षर हैं या request अटपटी लगती है
• AI assistants उन items को खोज सकते हैं जिन पर action चाहिए, content और urgency पढ़ सकते हैं, और उसी अनुसार व्यवहार कर सकते हैं
• अगर spoofed message पर्याप्त रूप से भरोसेमंद लगे, तो inbox तक पहुँचने से पहले authentication को ही उसे रोकना चाहिए

authentication अब infrastructure बन रहा है

• 2024 की शुरुआत में Google और Yahoo ने bulk senders से यह माँग शुरू की कि ईमेल की reliable delivery के लिए DMARC को सही तरह configure किया जाए
• इस बदलाव ने authentication को ऐसी चीज़ से बदलकर, जिसे sender कम प्राथमिकता दे सकता था, inbox तक पहुँचने की बुनियादी पूर्वशर्त बना दिया
• ईमेल authentication उसी दिशा में बढ़ रहा है जिस रास्ते से web पर HTTPS गुज़रा था
  • HTTPS best practice से expectation बना, और फिर infrastructure बन गया
  • भले ही browser address bar में lock icon का सटीक अर्थ सबको न पता हो, लेकिन किसी website पर उसका न होना एक ऐसा warning signal बन जाता है जिसे नज़रअंदाज़ नहीं किया जा सकता
• नए standards इसी authentication foundation के ऊपर बनाए जा रहे हैं
• BIMI verified senders को supported inboxes में सीधे logo दिखाने की सुविधा देता है
  • ऐसे समय में जब सिर्फ content देखकर AI-generated phishing पहचानना और कठिन हो रहा है, यह एक छोटा visual trust signal बन जाता है
• DKIM design की फिर से समीक्षा की जा रही है, जिसमें experimental ARC specification से मिले सबक शामिल हैं
  • यह complex email flows में changes को track और attribute करने में मदद करता है, ताकि filtering systems यह तय कर सकें कि malicious content कहाँ से आया
  • इससे गलत entity की reputation को नुकसान पहुँचने से बचाने में मदद मिलती है

सिर्फ authentication काफ़ी नहीं है

• authentication domain identity की पुष्टि करता है, लेकिन intent की नहीं
• कोई scammer जो मिलता-जुलता domain और सही तरह configured DMARC record रखता हो, sender authentication checks पास कर सकता है
• authentication impersonation की लागत और जटिलता को काफी बढ़ा देता है, और जैसे-जैसे ईमेल का भविष्य अधिक automated होता जाएगा, यह और महत्वपूर्ण होगा
• भविष्य का inbox आज अधिकांश users के inbox से अधिक तेज़, अधिक smart और अधिक capable होगा
• authentication वह चीज़ है जो इस भविष्य को सिर्फ सुविधाजनक नहीं, बल्कि भरोसेमंद भी बनाएगी
• ये standards कई वर्षों में mature हुए हैं, और जैसे-जैसे ईमेल अधिक automated होता जा रहा है, इस foundation पर आगे भी निर्माण करते रहना ज़रूरी है

ईमेल कहीं नहीं जा रहा

• ईमेल सबको चाहिए: बैंक statements भेजते हैं, डॉक्टर appointment details भेजते हैं, और दूसरी sites password reset भेजती हैं
• हर किसी के पास ईमेल है
• किसी technology की longevity का सबसे अच्छा संकेतक यह है कि वह पहले से कितने लंबे समय से मौजूद है, और ईमेल बहुत लंबे समय से मौजूद है
• Fastmail भविष्य के ईमेल को support करने वाले standards के development में अग्रिम पंक्ति में है, और सभी के लिए बेहतर ईमेल बनाने के लिए ईमेल के साथ आगे भी evolve करता रहेगा

[GN⁺]

Hacker News की राय

• यह वास्तव में कितना मददगार होगा, कहना मुश्किल है, लेकिन अगर ईमेल अधिक सुरक्षित हो जाए और संगठन, खासकर बैंक, सरकार और बीमा कंपनियाँ, closed secure mailbox जैसे विकल्प बनाना बंद करें, तो यह स्वागतयोग्य होगा
  वे कहते हैं, “secure message center में login करें,” और वहाँ ऐसे संदेश मिलते हैं जिनका format भी खराब होता है, जिन्हें बस थोड़े समय के लिए देखा जा सकता है और फिर वे हमेशा के लिए delete हो जाते हैं
  मेरा inbox कुछ हद तक searchable जीवन का रिकॉर्ड है, और ऐसे विकल्प उसे तोड़ देते हैं

  • ऐसे “message center” सिर्फ security की वजह से नहीं, बल्कि compliance की वजह से भी होते हैं
    उदाहरण के लिए, बीमा कंपनियों को HIPAA का पालन करना होता है, और health-related जानकारी सिर्फ दूसरे HIPAA-compliant सिस्टमों को ही भेजी जा सकती है
    इसके लिए उस सिस्टम के साथ BAA नाम का contract करना पड़ता है, जो email के साथ व्यावहारिक रूप से संभव नहीं है
    बीमा कंपनी दुनिया भर के हर email host के साथ contract नहीं कर सकती, और mail भेजने के बाद वह आखिर पहुँचेगी कहाँ, यह भी नहीं जान सकती
    यह भी बहुत मुश्किल है कि किन emails में health information है और किनमें नहीं, क्योंकि संदर्भ के अनुसार किसी व्यक्ति का नाम या IP address भी उस दायरे में आ सकता है
    इसलिए default यही बना दिया जाता है कि सब कुछ message center में भेजा जाए, और email security कितनी भी बेहतर हो जाए, यह हिस्सा बदलना मुश्किल है
  • सुरक्षित email बनाना है तो email से HTML/CSS support हटाना होगा, और inbox को invite-based तरीके से चलना चाहिए
    जैसे social network में friend add करते हैं, वैसे sender को पहले से approve करना चाहिए
  • ऐसे secure messaging platform backup को लगभग असंभव बना देते हैं
    मैंने medical clinic को ऐसे संदेश delete करते भी देखा है जो अदालत में उनके खिलाफ जा सकते थे
    इसलिए जो लोग मुझे ऐसी चीज़ें भेजते हैं, उनसे मैं कहता हूँ कि असली email भेजें
  • मेरा बैंक “महत्वपूर्ण संदेश पढ़ने के लिए app में login करें” वाली push notification भेजता है, जबकि आमतौर पर वह monthly statement जैसी चीज़ होती है
    फिर वह अलग से email भी भेजता है, जिससे कभी-कभी मैं उसे कोई दूसरा संदेश समझकर फिर से login कर लेता हूँ
    “इस संदेश को PDF के रूप में download करें” वाला button भी होता है, लेकिन असल में वह सिर्फ web browser wrapper में ले जाता है
  • मैंने हाल ही में बैंक से जानकारी माँगी थी, तो उन्होंने कहा कि email से नहीं भेज सकते, लेकिन डाक से भेज सकते हैं
    उन्होंने कहा कि यह अगले हफ्ते तक पहुँच जाएगी
    इसके पीछे निश्चित ही कई compliance कारण होंगे, लेकिन यह बिल्कुल भी समझदारी की बात नहीं लगती

• यह लेख पढ़ते-पढ़ते जब अंत तक पहुँचा तो हैरानी हुई। पूरा लेख किसी announcement या किसी नई चीज़ की भूमिका जैसा लगा, लेकिन आखिर में कुछ भी नहीं निकला
  हो सकता है मैं ही धीमा हूँ, लेकिन इसलिए मुझे समझ नहीं आया कि मुख्य निष्कर्ष क्या था

  • Fastmail user होने के नाते, कोई announcement न होना ही राहत की बात लगी
    जब भी कोई कंपनी उज्ज्वल भविष्य की बातें शुरू करती है, उसका मतलब अक्सर यह होता है कि मेरा user experience जल्दी ही खराब होने वाला है
  • “Fastmail के मुताबिक email का future” पढ़कर मैंने तुरंत किसी बड़े announcement की उम्मीद की थी
    असल में बात सिर्फ इतनी थी कि “अब DMARC pass करना होगा,” जबकि यह तो 2 साल से सच है
    यह बात सही है कि authentication spoofed domain को रोकने में मदद करता है, लेकिन मेरे हिसाब से सबसे बड़ी समस्या spoofed domain नहीं है
    हमलावर PayPal, Stripe जैसे payment platform से email भिजवाने का तरीका ढूँढ़ लेते हैं
    वे यह पता कर लेते हैं कि generated email में कौन-सी जानकारी जाती है, फिर company name को “कोई समस्या है, इस नंबर पर call करें” जैसा सेट कर देते हैं
    तब असली PayPal से आने वाले, सभी checks pass करने वाले वैध email के subject या body में वही company name आ जाता है और वह ज़रूरी व तात्कालिक लगता है
    ऐसे mails असली कंपनी से भेजे जाते हैं और सारी authentication भी pass करते हैं, इसलिए DMARC उन्हें पकड़ नहीं सकता, और हाल में हमलावरों को ठीक इसी तरह काम करते देखा जा रहा है
    मैं सच में उम्मीद कर रहा था कि Fastmail इस समस्या के लिए कुछ लेकर आएगा
  • “भविष्य का inbox आज ज़्यादातर लोगों के इस्तेमाल वाले inbox से अधिक तेज़, अधिक स्मार्ट और अधिक काम करने वाला होगा”
    कुल मिलाकर सार यही है। वहाँ तक कैसे पहुँचा जाएगा, यह पता नहीं, बस इतना कि email और तेज़ और स्मार्ट होगा
  • मेरा अनुभव भी ऐसा ही था। मैं किसी ठोस बात का इंतज़ार करता रहा, और अंत में निष्कर्ष बस यह निकला कि “email गायब नहीं होगा”
    सच कहूँ तो समझ नहीं आता कि यह पोस्ट क्यों डाली गई और इसे upvote क्यों मिले

• मुझे Fastmail पसंद है। मैं कुछ साल पहले Proton से वहाँ आया था, क्योंकि मुझे लगा कि encrypted email के trade-off उसकी कीमत के लायक नहीं हैं
  चाहे आप Proton पर पूरी तरह भरोसा करें, ज़्यादातर email तो आखिरकार AWS, Outlook, Gmail के बीच ही आते-जाते हैं
  मैं Fastmail की service से बहुत संतुष्ट हूँ। इसकी pricing ठीक है, बड़े inbox में भी यह बहुत तेज़ है, और यह बेकार features या bloat नहीं जोड़ता
  शुरुआत में मेरा इरादा operating system की default mail app इस्तेमाल करने का था, लेकिन Fastmail की app और website इतनी अच्छी लगी कि मैं बस वही इस्तेमाल करने लगा

  • मैं 9 साल से ज़्यादा समय से Fastmail इस्तेमाल कर रहा हूँ। खासकर app में offline support जुड़ने के बाद से तो इसे छोड़ने की कोई वजह ही नहीं बची
  • जानना चाहूँगा कि Proton में कौन-से trade-off थे
  • Fastmail desktop app सचमुच सिर्फ website को wrap करती है, और जो अतिरिक्त feature जोड़ा गया है वह है back button का न होना
    30 साल की webmail muscle memory इस “app” की वजह से बेकार हो जाती है
    लगता है किसी web developer ने desktop app developer बनने की कोशिश की है
    यह कोई गलती भी नहीं, बल्कि उन्होंने जानबूझकर previous page पर लौटने वाला keyboard shortcut न देने का फैसला किया है
    customer support ने कहा कि वे इसे “feature request” के रूप में जोड़ देंगे

• हम लगभग email के निर्णय को AI के हवाले कर रहे हैं, और साथ ही SPF/DKIM को मज़बूत करके उसकी भरपाई करने की कोशिश कर रहे हैं
  जैसे ताला और मज़बूत बनाया जा रहा हो, लेकिन master key और ज़्यादा लोगों में बाँटी जा रही हो

  • मुझे लगता है इस क्षेत्र में एक साथ कई चीज़ें चल रही हैं। Fastmail ने उनमें से सिर्फ एक को अपने हित में शब्दों में रखा है
    Fastmail email के बारे में किसी परम प्राधिकरण की तरह बात नहीं कर सकता
    Fastmail स्वयं email नहीं है, बल्कि email पर निर्भर एक service है

• जब तक inbox को एक जगह से दूसरी जगह ले जाना और अपनी पसंद के provider की ओर route करना संभव नहीं होता, तब तक ऐसी authentication systems बड़े पैमाने पर वास्तविक मूल्य देती नहीं दिखतीं
  अगर phone number port किया जा सकता है, तो सिद्धांततः email address भी port किया जा सकना चाहिए
  यहाँ बताए गए authentication systems इतनी मदद नहीं करते कि ऐसी portability संभव हो सके
  आप कोई भी provider इस्तेमाल करें, email domain name नहीं बल्कि व्यक्ति स्वयं authenticate हो सके, इसके लिए एक वैध तरीका चाहिए
  यानी ऐसा standard विकसित होना चाहिए जो hosting provider की ओर से ही sign कर सके

• 2026 में भी ईमेल में signature और encryption का डिफ़ॉल्ट न होना बेतुका है
  लेकिन जब तक बड़े ईमेल प्रदाताओं का business model इस बात पर निर्भर करता रहेगा कि हम उनका इस्तेमाल न करें, तब तक शायद ऐसा ही रहेगा

  • अगर ईमेल encrypt हो जाए, तो वह model सचमुच काम नहीं कर सकता
    inbox को वास्तव में उपयोगी बनाने के लिए हर तरह की machine learning processing चलनी पड़ती है, और उसके लिए ईमेल का unencrypted होना ज़रूरी है
  • बड़े providers में से कोई भी यह नहीं चाहता
    अगर ऐसा न होता, तो Microsoft के लिए Outlook data को 1000 partners के साथ share करना कहीं ज़्यादा मुश्किल होता
  • 2026 में ईमेल encryption को ज़ोर-शोर से आगे बढ़ाना, असली security practices से ज़्यादा checkbox requirements को महत्व देने का संकेत है
    encrypted email सुनने में अच्छा लगता है, लेकिन अगर वास्तविक threats को देखें, तो यह मौजूदा स्थिति की तुलना में बहुत कम सुरक्षा देता है और बहुत-सी functionality भी खो देता है
    बुनियादी तौर पर ईमेल पहले से ही मेरे computer से mail server तक, मेरे mail server से recipient के mail server तक, और recipient के mail server से recipient के computer तक encrypted होता है
    मेरे और recipient के अलावा, इसे केवल बीच के mail servers ही देख सकते हैं, और encrypted email से ज़्यादा से ज़्यादा इतना ही हासिल होता है कि इस प्रक्रिया में अहम भूमिका निभाने वाले कुछ entities को हटा दिया जाए
    खासकर email headers वैसे भी खुले रहते हैं, इसलिए सबसे अच्छे हालात में भी यह बहुत private communication नहीं बनता
    दूसरी तरफ, encrypted email server-side filtering जैसी processing को तोड़ देता है. spam handling के साथ भी यही समस्या है, खासकर उस भारी मात्रा में spam को देखते हुए जो spam folder तक भी नहीं पहुँचती, इसका कोई व्यावहारिक हल नहीं है
    users उम्मीद करते हैं कि वे webmail में login करके सीधे अपना mail पढ़ सकें, और webmail ही प्रमुख email client है
    इसे हल करने के लिए अगर server को key दे दी जाए, तो server फिर से ईमेल पढ़ सकने वाला entity बन जाता है और मौजूदा स्थिति से कोई फर्क नहीं रहता
    इससे भी बड़ी समस्या key distribution है. mail भेजने के लिए recipient की key ढूँढनी पड़ती है, और बड़े पैमाने पर इसका सबसे व्यावहारिक तरीका यही है कि mail server से user की public key पूछी जाए
    लेकिन वही server उस user को जाने वाले सभी messages intercept कर सकने वाला एकमात्र entity भी है, इसलिए वह अपनी key दे सकता है, encryption हटा सकता है, और फिर user के लिए दोबारा encrypt कर सकता है, और इसका पता लगना मुश्किल होगा
    PGP keyserver जैसे alternatives भी काम नहीं आते. जब PGP encryption में रुचि रखने वाले users की संख्या दस लाख से भी कम थी, तब भी PGP keyserver ecosystem कुछ साल पहले ढह गया था, और यह अरबों email users के पैमाने से तुलना ही नहीं कर सकता
    मुझे लगता है कि encrypted email, ईमेल कंपनियों के business model की वजह से नहीं, बल्कि इसलिए एक अव्यावहारिक सपना है क्योंकि email architecture पहले से ही पर्याप्त रूप से अच्छी security देता है और अतिरिक्त encryption के फ़ायदे को वास्तविक बनाना बहुत कठिन है
  • नया email, email नहीं बल्कि Matrix जैसा होगा, या अगर centralization स्वीकार करें तो Signal जैसा
    वह ऐसा system होना चाहिए जिसमें अच्छा user experience और बेहतरीन encryption हो

• लेख में DKIM को email forwarding में टूटने से बचाने की असफल ARC proposal का ज़िक्र है
  https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
  यह देखना दिलचस्प होगा कि क्या Google को ARC से हटकर किसी दूसरे तरीके की ओर राज़ी किया जा सकता है
  आजकल Gmail email server reputation को बहुत महत्व देता है, इसलिए जिन mail servers को वह पसंद नहीं करता, उनके साथ लगातार बुरा व्यवहार कर सकता है

• “दूसरा है AI support. inbox का summary बनाना, action items दिखाना, replies का draft तैयार करना, और कुछ मामलों में user की ओर से action लेना”
  यही हिस्सा सबसे दुष्ट है. आखिरकार bots bots से बात करेंगे, और इंसान बाहर हो जाएगा
  ईमेल की सारी समस्याएँ GPG से हल की जा सकती हैं, लेकिन तब Fastmail जैसी email services का business बर्बाद हो जाएगा
  क्योंकि वे user emails को पढ़ और analyze नहीं कर पाएँगी, ads नहीं बेच पाएँगी, user profiles को ad companies को नहीं बेच पाएँगी, और user data से AI को train भी नहीं कर पाएँगी
  मैं ईमेल का भविष्य उसी दिशा में देखना चाहता हूँ. अफ़सोस कि कोई GPG का इस्तेमाल नहीं करता, और लोगों को यह सिखाना भी काफ़ी मुश्किल है

  • आखिरकार हमें इसी रास्ते पर धकेला जाएगा, इसलिए धैर्य रखना चाहिए
    communication के असली होने को साबित करने का एकमात्र तरीका पहले से आमने-सामने key exchange करना होगा
    GPG बस उसका एक तरीका है, और कोई न कोई इसे संगठन स्तर पर आसान बनाने का तरीका लेकर आएगा
  • क्या Fastmail user emails को पढ़कर या analyze करके ads बेचता है? क्या Fastmail user emails से AI models train करता है?
    analysis के लिए message content से ज़्यादा metadata की कीमत होती है. GPG इसका हल कैसे करता है?

• मुझे उम्मीद थी कि यह लेख JMAP के बारे में होगा

  • इसी लेख से मुझे SPF, DKIM, DMARC के बारे में पता चला, और ये काफ़ी अच्छे technical improvements लगे
    यह message body encryption नहीं है, लेकिन इससे पता चलता है कि default email environment में अभी भी सुधार की गुंजाइश है
  • मुझे नहीं पता था कि JMAP क्या है, लेकिन इसके बारे में पढ़ने के बाद मैं सहमत हूँ

• यह निराशाजनक है कि hobby projects में सारे rules मानने और सही headers डालने के बाद भी ईमेल भेज पाना संभव नहीं होता
  jeremyevans का self-hosting email वाला लेख पढ़ने में मज़ेदार था, लेकिन वह सिर्फ receiving के बारे में है, sending को नहीं छूता
  https://code.jeremyevans.net/2021-07-29-running-my-own-email...