आधुनिक ईमेल उधार लिए गए हिस्सों से बनाया जा सकता है
आधुनिक web standards जैसे HTTP के ऊपर ईमेल को फिर से डिज़ाइन करने के प्रयास, spam नियंत्रण, पहचान, और उपयोगकर्ता सहमति पर लंबे समय से चल रही बहसों को फिर से जीवित कर रहे हैं। टिप्पणीकर्ता first-contact approval, mass mail को महँगा बनाने के लिए वैकल्पिक postage या micropayments, और चैट-शैली messaging के साथ कड़ी एकीकरण जैसे विचारों पर चर्चा करते हैं, साथ ही उन विशाल network effects को भी नोट करते हैं जो SMTP को बनाए रखते हैं और बड़े providers को reputation systems के जरिए शक्ति देते हैं। कई लोग अब भी संदेह में हैं कि कोई तकनीकी रूप से बेहतर replacement broad community और industry buy-in के बिना traction पा सकेगा, खासकर email की entrenched स्थिति और पिछले “ultimate” spam solutions की विफलता को देखते हुए.
पहला-संपर्क सहमति और “requests” इनबॉक्स
- कई लोगों को यह विचार पसंद है कि अज्ञात प्रेषक इनबॉक्स तक पहुँचने से पहले एक “requests” क्षेत्र में जाएँ, ठीक आधुनिक चैट ऐप्स की तरह।
- अन्य लोग नोट करते हैं कि ऐसे पैटर्न पहले से मौजूद हैं: सर्वरों पर greylisting, मैन्युअल whitelisting, पुष्टि लिंक या tokens वाले auto-replies, और Hey/Spark जैसी सेवाएँ।
- रिपोर्ट की गई उपयोगकर्ता प्रतिक्रियाएँ मिली-जुली हैं: कुछ कहते हैं कि लोग अतिरिक्त झंझट “नापसंद” करते हैं; दूसरों के अनुसार लगभग कोई शिकायत नहीं करता और उनसे संपर्क करने के लिए पुष्टि करने को तैयार रहते हैं।
- आलोचकों का तर्क है कि इससे समस्या बस दूसरी जगह चली जाती है: “requests” फ़ोल्डर नया spam फ़ोल्डर बन सकता है, जहाँ वैध पहली बार के संपर्क दब जाते हैं।
ईमेल बनाम प्रत्यक्ष संदेश
- कुछ लोग पूछते हैं कि क्या एक बेहतर email spec WhatsApp-शैली messaging की जगह ले सकता है; DeltaChat को ईमेल और चैट के बीच पुल बनाने के उदाहरण के रूप में उल्लेख किया जाता है।
- अन्य लोग अलग workflows पर ज़ोर देते हैं: ईमेल एक mailbox की तरह, जबकि chat-जैसी infinite threads; और legal work जैसी चीज़ों के लिए विषय-विशिष्ट threads निकालने में कठिनाई की शिकायत करते हैं।
स्पैम, postage, और सहमति
- कई प्रस्तावों में “postage” या प्रति-संदेश लागत शामिल है, जो आदर्श रूप से कम मात्रा पर बहुत सस्ती हो लेकिन पैमाने के साथ बढ़े, ताकि mass spam आर्थिक रूप से अव्यवहारिक हो जाए।
- micropayments को व्यापक रूप से अव्यावहारिक माना जाता है; identity churn मात्रा-आधारित pricing को कमजोर कर देती है।
- सुझाए गए विकल्प: स्पष्ट “Automated: 0/1” headers, जिनका प्रवर्तन reputation से हो; automated mail के लिए अनिवार्य consent; और प्रति-प्रेषक पूर्व-अनुमोदन plus quarantine।
- domain/IP स्तर पर reputation और blacklisting को आज के anti-spam का केंद्रीय हिस्सा बताया गया है, जबकि self-hosters अक्सर संघर्ष करते हैं।
प्रोटोकॉल, HTTP, और संगतता
- कुछ लोग HTTP और मौजूदा tools (MTA-STS, JMAP, Web Key Directory) पर निर्माण करना पसंद करते हैं, SMTP के सीधे replacement के बजाय incremental evolution के साथ।
- अन्य लोग “email over HTTP” को नापसंद करते हैं, DNS/MX/SRV और DANE को प्राथमिकता देते हैं, और content-addressed mail के mailing lists तोड़ने या metadata के unencrypted रहने जैसी समस्याओं की चेतावनी देते हैं।
- एक hybrid “NewEmail” overlay प्रस्तावित है, जो दोनों पक्षों द्वारा support होने पर delivery को auto-upgrade कर दे, जैसे iMessage बनाम SMS; backward compatibility को आवश्यक माना गया है।
UX, accessibility, और व्यापक संदेह
- कई लोग तर्क देते हैं कि वास्तविक समस्या UX और clients हैं, protocol नहीं; अन्य लोग सोचते हैं कि मौजूदा GUIs वैसे भी ठीक और विविध हैं।
- article की साइट पर accessibility समस्याओं और ध्यान भटकाने वाले UI की आलोचना की गई है।
- कई टिप्पणियाँ इतिहास पर ज़ोर देती हैं: “email को ठीक करो” और “spam हल करो” जैसी अनगिनत योजनाएँ विफल हुई हैं; email गहराई से स्थापित है, बड़े providers द्वारा “captured” है, और इतना अच्छा काम करती है कि कोई क्रांतिकारी बदलाव संभव नहीं लगता।