आख़िर ये बराबर (=) के निशान क्या हैं?

• हाल में Twitter पर पुराने email उद्धरण फैलने के साथ यह सवाल उठा कि वाक्यों के अंत में बराबर (=) का निशान क्यों दिखाई देता है
• यह निशान ‘quoted-printable’ encoding प्रक्रिया से आता है, और लंबी पंक्तियों को ज़बरदस्ती तोड़ते समय यह दिखाने के लिए इस्तेमाल होता है कि पंक्ति आगे जारी है
• email ट्रांसमिशन के दौरान CRLF(carriage return + line feed) को line break के रूप में इस्तेमाल किया जाता है, लेकिन इसे Unix के NL में बदलते समय अगर decoding algorithm गलत काम करे तो बराबर का निशान बचा रह सकता है या अक्षर खो सकते हैं
• बराबर का निशान line break के अलावा non-ASCII characters (जैसे: =C2=A0) को दिखाने के लिए भी इस्तेमाल होता है, और गलत decoder इसे साधारण replacement की तरह संभालकर त्रुटि पैदा करता है
• समस्या की जड़ bug वाले decoding logic और अनुचित conversion handling में है, जो दिखाती है कि email को प्रोसेस करने वाला व्यक्ति तकनीकी रूप से अपर्याप्त था

---

email उद्धरणों में बराबर (=) के निशान की असलियत

• पिछले कुछ दिनों में Twitter पर पुराने email उद्धरण बड़ी संख्या में साझा किए गए, जिनमें वाक्यों के अंत में बराबर का निशान दिखना खास तौर पर नज़र आया

  • लेखक ने इसे code या OCR(ऑप्टिकल कैरेक्टर रिकग्निशन) त्रुटि समझने वाले दावों का खंडन किया
  • वास्तव में यह email को पढ़ने लायक फ़ॉर्म में बदलने की प्रक्रिया में हुई encoding handling error है

• email पहले साधारण text हुआ करता था, लेकिन लंबी पंक्तियों और विशेष अक्षरों को संभालने के लिए ‘quoted-printable’ encoding लाई गई

  • लंबी पंक्तियाँ तोड़ते समय पंक्ति के अंत में बराबर (=) जोड़कर यह बताया जाता है कि “यह पंक्ति आगे जारी है”
  • इस समय बराबर के निशान के बाद CRLF(carriage return + line feed) आता है

line break encoding और decoding त्रुटि

• email server मानक के तौर पर CRLF line break का उपयोग करते हैं, जबकि Unix सिस्टम केवल NL का उपयोग करते हैं

  • conversion के दौरान एक byte कम हो जाता है, और decoder अगर इसे गलत तरीके से संभाले तो बराबर का निशान रह जाता है या अक्षर गायब हो जाते हैं
  • उदाहरण के लिए, “non- =CRLF cloven” को गलत तरीके से प्रोसेस किया जाए तो वह “non- loven” बन सकता है, जहाँ ‘c’ गायब हो जाता है

• कुछ implementations पंक्ति के अंत में बराबर का निशान मिलने पर दो characters हटाने के तरीके से काम करती हैं

  • Unix फ़ॉर्मैट फ़ाइलों में यही algorithm गड़बड़ कर जाता है और बराबर का निशान जस का तस रह जाता है

बराबर के निशान का एक और उपयोग: non-ASCII character encoding

• बराबर का निशान line break के अलावा non-ASCII character encoding में भी इस्तेमाल होता है

  • उदाहरण: “=C2=A0” का मतलब non-breaking space(लाइन ब्रेक रोकने वाला स्पेस) है
  • यह email body में indentation या special characters दिखाने के लिए अक्सर आता है

• लेखक का अनुमान है कि कुछ converters ने =C2, =A0 जैसी चीज़ों को केवल search-replace से संभाला, सही decoder का उपयोग नहीं किया

तकनीकी पृष्ठभूमि और मानक

• RFC 2045 मानक quoted-printable encoding को transport के लिए परिभाषित करता है

  • प्राप्ति के बाद इसे decode करके साफ़ text के रूप में सहेजना ही सिद्धांत है
  • लेकिन वास्तविक implementations में यह प्रक्रिया छोड़ दी जाती है, जिससे line break handling errors बार-बार होती हैं

• उदाहरण code में (quoted-printable-decode-string "he=\nllo") सही तरह से "hello" में बहाल हो जाता है

  • ऐसा इसलिए है क्योंकि algorithm को SMTP server संदर्भ में CRLF मानकर दोबारा इस्तेमाल किया गया
  • Windows आधारित फ़ाइलों में यह सही काम करता है, लेकिन Unix आधारित सिस्टमों में असफल हो जाता है

निष्कर्ष

• email उद्धरणों में दिखने वाला बराबर का निशान quoted-printable encoding का अवशेष है, और
  line break handling तथा non-ASCII character decoding की खामियों के संयुक्त परिणाम के रूप में उभरता है
• समस्या का मूल कारण गलत decoder implementation और encoding conversion की त्रुटियाँ हैं
• लेखक इसे “तकनीकी समस्या और गलत processing का परिणाम” कहकर संक्षेपित करता है,
  और email conversion प्रक्रिया में मानकों के सूक्ष्म पालन की आवश्यकता पर ज़ोर देता है

[GN⁺]

Hacker News की राय

• इस लेख के मुख्य व्यक्ति Lars Ingebrigtsen हैं, जिन्होंने Emacs के email/Usenet reader package Gnus का manual लिखा था
  उनका manual चतुर, उपयोगी है, और उन्हें email parsing की अधिकांश लोगों से कहीं गहरी समझ है
  manual को यहाँ देखा जा सकता है, और एक दूसरा संस्करण इस लिंक पर है

  • वे सिर्फ manual के लेखक नहीं, बल्कि Gnus के developer भी हैं
    मुझे Oslo University (UiO) में वह समय याद है जब वे पहली बार Gnus बना रहे थे
    हमारे informatics विभाग के छात्रों के बीच वे एक छोटे star developer थे, और सब Emacs और Gnus इस्तेमाल करते थे

• यह घटना “खतरनाक हद तक जानने वाले व्यक्ति” का एक क्लासिक उदाहरण है
  यह तो पता था कि email साधारण text नहीं है, लेकिन यह नहीं पता था कि quoted-printable decoding को साधारण replacement की तरह handle नहीं किया जा सकता
  यह उसी तरह की bug है जैसे regex से HTML को सीधे parse करना; शुरू में सब ठीक लगता है, फिर बाद में कांग्रेस के सबूतों में ‘=’ चिन्हों की भरमार वाली स्थिति बन जाती है

  • इससे जुड़ा प्रसिद्ध Stack Overflow जवाब साझा किया गया। यह मज़ाकिया अंदाज़ में समझाता है कि HTML को regex से parse क्यों नहीं करना चाहिए
  • output ज़्यादातर पढ़ने लायक रहता है, इसलिए किसी को समस्या का पता नहीं चलता, और सालों बाद जब इसे कांग्रेस के सबूत के तौर पर जमा किया जाता है तब जाकर बात सामने आती है
  • अंत में “इस समय हमारे सबसे अच्छे लोग इस पर काम कर रहे हैं” वाले मज़ाक से बात खत्म की गई

• एक सवाल था, “mail server लंबी lines से नफरत क्यों करते हैं?”

  • SMTP एक line-based protocol है, इसलिए message body भी line दर line भेजी जाती है
    server को headers parse करने होते हैं, इसलिए इसे एक साधारण binary blob की तरह नहीं संभाला जा सकता
    IMAP में server को पूरी parsing करनी पड़ती है, और POP3 एक single-device दुनिया के लिए बना था, इसलिए आज के समय में वह उपयुक्त नहीं है
  • पहले mail को fixed-length buffer में line unit के हिसाब से process किया जाता था
    RFC 821 ने line length को अधिकतम 1000 bytes तक सीमित किया था, और compatibility के लिए 80 characters से कम पर line break करना आम बात थी
    इसलिए Base64 encoding भी हर 76 characters पर line break डालती है
  • जब SMTP design किया गया था तब memory बहुत ही सीमित थी
    उदाहरण के लिए PDP-11 में लगभग 512KB, VAX-11 में लगभग 2MB memory होती थी, और programmers byte level पर memory गिनते थे
  • SMTP command flow को सीधे दिखाते हुए, HELO, MAIL FROM, RCPT TO, DATA आदि से communication की संरचना समझाई गई
  • 1980s के university network BITNET का भी ज़िक्र आया, और याद किया गया कि तब भी line length limits थीं
    संबंधित दस्तावेज़ IBM official docs और Wikipedia पर देखे जा सकते हैं

• शुरुआत में लगा था कि यह लेख = == === .=. <== ==> <<== ==>> (==) => =~= जैसे operator meanings के बारे में होगा

  • इस पर “क्या यह चींटियों के लिए Haskell है?” जैसा मज़ाक किया गया
  • लेकिन कहा गया कि असली विषय उससे कहीं ज़्यादा दिलचस्प निकला

• मैंने व्यक्तिगत रूप से email archiving software खुद बनाया है
  20 साल से ज़्यादा समय से जमा हुई .eml files के edge case handling सबसे कठिन थे
  concept सरल है, लेकिन email हैरान कर देने लायक जटिल है

  • email standards शुरू से नए सिरे से नहीं बनाए गए थे, बल्कि पुराने systems को ज़बरदस्ती जोड़कर बनाया गया एक शापित standard हैं
    email address validation भी व्यवहार में लगभग असंभव है
  • मैंने console-based mail client बनाया था, जिसमें 25% C++ और 75% Lua से UI और processing define की गई थी
    कुछ सालों तक उसके थोड़े-बहुत users रहे, लेकिन MIME handling सबसे बड़ा दर्द था

• मुझे ‘=’ चिन्ह से ज़्यादा दिलचस्प यह लगा कि उसके आसपास के characters गायब हो रहे थे
  यह किसी off-by-one error जैसा लगा; मानो ‘=’ हटाने के बजाय असली text का कुछ हिस्सा ही गायब हो गया हो
  शायद CRLF/LF conversion का इससे संबंध हो सकता है

  • मूल लेख इस कारण को ठीक-ठीक समझाता है
  • इसी तरह सबूतों में characters गायब होने का रहस्य पैदा होता है

• यह समस्या अभी क्यों दिख रही है, इस पर जिज्ञासा थी
  पिछले कुछ दिनों से लोग पुराने emails को Twitter पर डाल रहे हैं; सवाल था कि ऐसा क्यों हो रहा है

  • शायद यह Epstein से जुड़े emails के सार्वजनिक होने की वजह से है
  • वास्तव में कहा गया कि DOJ ने Epstein emails अतिरिक्त रूप से जारी किए हैं

• कुछ लोगों ने कहा कि इस समस्या की वजह Gmail नहीं, बल्कि बीच के server पर हुआ conversion हो सकता है
  CRLF→LF conversion के अलावा, अगर quoted-printable को दो बार apply किया जाए तो ‘=’ बचे रह सकते हैं, इसलिए संभव है कि इसमें दो mail servers शामिल रहे हों

  • कुछ PDFs में Apple Mail.app का plist metadata दिखता है, इसलिए संभव है कि इसे किसी internal format से extract किया गया हो
  • कानूनी सबूत इकट्ठा करने की प्रक्रिया में ऐसी चीज़ें अक्सर होती हैं
    असल में कोई गैर-पेशेवर intern साधारण tools से data इकट्ठा करता है, वह कई बार convert होता है, और format टूट-फूट जाता है
    original पहले ही नष्ट हो चुका होता है, और अंत में सिर्फ आकार भर बचा हुआ टुकड़ा data रह जाता है
  • अक्सर emails को MS Outlook की PST files में import करते समय भी यह समस्या होती है
  • यह किसी एक Gmail dump जैसा नहीं, बल्कि कई systems के “मदद” करते-करते data बदल देने का नतीजा लगता है
  • कुछ लोगों की राय थी कि यही परिकल्पना सबसे अधिक विश्वसनीय लगती है

• archive.today के लेख में भी यही quoted-printable corruption दिखाई देता है
  संबंधित links हैं pastes.io/correspond और HN thread

• कहा गया कि Outlook से downloaded mail देखते समय ऐसा .eml viewer होना अच्छा होगा जो quoted-printable को अपने-आप decode कर दे