ईमेल Obfuscation: 2026 में कौन-सा तरीका प्रभावी है?

 (spencermortensen.com)
5 पॉइंट द्वारा GN⁺ 29 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ईमेल address को spam harvester से बचाने के लिए अलग-अलग HTML·CSS·JavaScript obfuscation techniques का प्रयोग कर उनकी block rate की तुलना की गई
  • 426 text और 399 link samples पर टेस्ट के नतीजे में, ज़्यादातर JS-आधारित और CSS·SVG techniques ने 100% block rate दर्ज की
  • HTML entities और URL encoding जैसे पुराने तरीकों ने भी अब तक ऊँचा block प्रभाव बनाए रखा
  • दूसरी ओर image display, symbol substitution, और text direction reversal जैसी विधियाँ accessibility और usability को गंभीर रूप से नुकसान पहुँचाती हैं
  • 2026 के मानक पर JS conversion, AES encryption, और user interaction methods को ईमेल सुरक्षा के लिए सबसे सुरक्षित और व्यावहारिक साधन माना गया

ईमेल address obfuscation techniques की तुलना (2026 के मानक पर)

  • ईमेल address को spam harvester से छिपाने के लिए अलग-अलग obfuscation techniques और हर तकनीक के वास्तविक प्रभाव को आँकड़ों के साथ प्रस्तुत किया गया है
  • हर ईमेल address को अलग तरीके से सुरक्षित करने के बाद, 426 (text) और 399 (link) samples पर harvester access को मापकर block rate निकाली गई
  • ज़्यादातर JavaScript-आधारित techniques और कुछ CSS·SVG techniques ने 100% block rate दर्ज की
  • HTML entities और URL encoding जैसे पुराने तरीकों ने भी अब तक ऊँची block rate बनाए रखी
  • कुछ techniques accessibility या usability को गंभीर रूप से नुकसान पहुँचाती हैं, इसलिए व्यावहारिक उपयोग के लिए उपयुक्त नहीं हैं

1. सामान्य text ईमेल सुरक्षा techniques

  • ईमेल address को पेज पर सीधे दिखाते हुए, अलग-अलग HTML·CSS·JS techniques से harvester को उसे पढ़ने से रोकने का तरीका
  • कई techniques को मिलाकर segment-wise protection लागू करने पर प्रभाव को अधिकतम किया जा सकता है

  • कोई सुरक्षा नहीं (No protection)

    • block rate 0% (426 में से 0 block)
    • ईमेल address पूरी तरह exposed रहता है और सभी harvesters उसे collect कर लेते हैं

  • HTML entities (HTML Entities)

    • block rate 95%
    • server-side libraries इसे अपने-आप decode कर देती हैं, फिर भी व्यवहार में ज़्यादातर harvesters रुक जाते हैं

  • HTML comments (HTML Comments)

    • block rate 99%
    • केवल वे basic harvesters रुकते हैं जिनकी HTML tag parsing कमज़ोर होती है
    • तरीका सरल है, फिर भी block प्रभाव ऊँचा बना हुआ है

  • HTML SVG

    • block rate 100%
    • ईमेल address को SVG object के अंदर text के रूप में छिपाया जाता है
    • screen reader के लिए accessible रहता है
    • <object> element का उपयोग ज़रूरी है; <img> या inline SVG में source expose होने का जोखिम है
    • font dependency होने के कारण web font specify करना ज़रूरी है

  • CSS display:none

    • block rate 100%
    • style rules लागू न कर पाने वाले harvesters की सीमा का उपयोग करता है
    • accessibility बनाए रखी जा सकती है, और visual hiding के बजाय display:none के उपयोग की सिफारिश की गई है

  • JS string concatenation (Concatenation)

    • block rate 100%
    • बिना external dependency के आसानी से implement किया जा सकता है
    • पूरा ईमेल HTML source में मौजूद रहता है, इसलिए security के लिहाज़ से कमज़ोर है

  • JS Rot18

    • block rate 100%
    • ROT13 जैसी character rotation cipher का उपयोग
    • simple harvesters इसे decode नहीं कर पाते, लेकिन JS को ignore करने वाले collectors के सामने कमज़ोर है

  • JS conversion (Conversion)

    • block rate 100%
    • HTML में केवल meaningless string शामिल होती है, और JS function उसे असली ईमेल में बदलता है
    • ज़्यादातर harvesters DOM·JS execute नहीं कर पाते, इसलिए restore करना संभव नहीं
    • सरल होने के साथ बेहद प्रभावी technique

  • JS AES encryption

    • block rate 100%
    • AES-256 encryption का उपयोग कर ईमेल को सुरक्षित किया जाता है
    • browser की SubtleCrypto API का उपयोग होता है, और यह केवल HTTPS environment में काम करता है
    • JS file के बिना decrypt करना संभव नहीं

  • JS user interaction (User interaction)

    • block rate 100%
    • ईमेल तभी दिखता है जब user पेज के साथ interact करे
    • harvester के लिए DOM execution + user event simulation की ज़रूरत होती है, इसलिए यह व्यवहारिक रूप से लगभग असंभव है

  • HTML symbol substitution (Symbol substitution)

    • block rate 96%
    • “AT”, “DOT” आदि से replacement किया जाता है
    • user को इसे manually ठीक करना पड़ता है, इसलिए usability घटती है

  • HTML instructions (Instructions)

    • block rate 100%
    • ईमेल में “remove the .fluff” जैसे manual निर्देश जोड़े जाते हैं
    • इंसान या AI इसे समझ सकते हैं, लेकिन user inconvenience बहुत अधिक है

  • HTML image

    • block rate 100%
    • ईमेल address को image के रूप में दिखाया जाता है
    • visually impaired users के लिए inaccessible, copy भी नहीं किया जा सकता, यानी usability पूरी तरह टूट जाती है

  • CSS content

    • block rate 100%
    • ::after pseudo-element से ईमेल दिखाया जाता है
    • देखने में दिखता है, लेकिन copy नहीं किया जा सकता; HTML से भी restore संभव है
    • इसे बेकार technique माना गया है

  • CSS text direction (Text direction)

    • block rate 100%
    • direction: rtl से string को उलट दिया जाता है
    • अगर harvester CSS ignore करे तो इसे आसानी से decode किया जा सकता है
    • text उल्टा copy होता है, इसलिए usability घटती है

2. clickable link सुरक्षा techniques

  • mailto: link के href attribute को सुरक्षित करने की विधियाँ
  • अगर link text में ईमेल शामिल हो, तो अलग से text obfuscation technique भी साथ में लागू करनी होगी

  • कोई सुरक्षा नहीं

    • block rate 0% (399 में से 0 block)
    • ईमेल address पूरी तरह exposed

  • HTML entities

    • block rate 100%
    • server-side automatic decoding के बावजूद ज़्यादातर harvesters रुक जाते हैं

  • URL encoding

    • block rate 95%
    • decode करना आसान है, फिर भी व्यवहार में ज़्यादातर harvesters रुक जाते हैं

  • HTTP redirect

    • block rate 100%
    • mailto: link को सामान्य link जैसा दिखाकर छिपाया जाता है
    • .htaccess में 302 या 301 redirect सेट किया जाता है
    • nofollow, noindex से search engine indexing रोकी जाती है
    • mail field auto-fill के लिए QSA flag ज़रूरी

  • HTML SVG

    • block rate 100%
    • ईमेल link को SVG के अंदर छिपाया जाता है
    • accessibility बनी रहती है, <object> का उपयोग ज़रूरी है
    • font specify करना ज़रूरी है

  • JS string concatenation

    • block rate 100%
    • बिना external dependency के implement किया जा सकता है
    • ईमेल HTML में सीधे शामिल रहता है, इसलिए सुरक्षित नहीं

  • JS Rot18

    • block rate 99%
    • ROT13 जैसी character rotation
    • simple harvesters इसे decode नहीं कर पाते

  • JS conversion (Conversion)

    • block rate 100%
    • HTML में केवल fake link होता है और JS उसे असली mailto: में बदलता है
    • harvester केवल HTML तक पहुँच पाते हैं, इसलिए restore करना संभव नहीं
    • सरल और बेहद प्रभावी technique

  • JS AES encryption

    • block rate 100%
    • AES-256 से encrypted ईमेल link
    • browser की SubtleCrypto API का उपयोग, HTTPS आवश्यक

  • JS user interaction

    • block rate 100%
    • link तभी सक्रिय होता है जब user interaction करे
    • harvester के लिए इसे reproduce करना मुश्किल है

3. आलोचना और प्रतिवाद

  • “spammer web को scrape नहीं करते, leaked databases खरीदते हैं” इस दावे पर
    • इस पेज के ईमेल addresses सिर्फ इसी पेज पर public थे, फिर भी इन्हें हज़ारों spam मिले
  • “सुरक्षा की ज़रूरत नहीं” इस दावे पर
    • लोकप्रिय content को अधिक आक्रामक रूप से collect किया जाता है, इसलिए viral होने की संभावना को देखते हुए protection ज़रूरी है
  • “सिर्फ spam filter काफ़ी है” इस दावे पर
    • ये techniques बिना false positive के और मुफ़्त में implement की जा सकती हैं, इसलिए filter के साथ मिलाकर उपयोग करना बेहतर है
  • “तकनीक ज्ञात हो जाए तो बेकार हो जाती है” इस दावे पर
    • आँकड़े दिखाते हैं कि दशकों पुराने वही तरीके अब भी प्रभावी हैं

4. प्रयोग की कार्यप्रणाली

  • हर obfuscation technique से सुरक्षित किए गए ईमेल addresses को वास्तविक रूप से public करके harvester honeypot के रूप में चलाया गया
  • spam पहुँचने पर माना गया कि उस address की protection technique टूट गई
  • spammer के आधार पर messages को group करके sender-count आधारित आँकड़े निकाले गए
  • spam filtering से आँकड़े विकृत न हों, इसके लिए स्वयं mail server और client बनाए गए
  • text-based और link-based harvesters अलग होते हैं, इसलिए आँकड़ों को अलग-अलग रखा गया
  • sample size अभी छोटा है, लेकिन links बढ़ने के साथ आँकड़ों की reliability बेहतर होने की उम्मीद है

निष्कर्ष

  • JS-आधारित conversion, encryption, और user interaction techniques सबसे ऊँचा security और accessibility संतुलन देती हैं
  • CSS display:none और SVG object technique भी accessibility और block rate, दोनों में उत्कृष्ट हैं
  • symbol substitution, image, और text direction reversal जैसी विधियाँ usability को गंभीर रूप से नुकसान पहुँचाती हैं, इसलिए इनकी सिफारिश नहीं की जाती
  • अगर ईमेल public करना ज़रूरी हो, तो simple JS conversion या AES encryption method 2026 के मानक पर सबसे प्रभावी विकल्प हैं

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

1 टिप्पणियां

 
GN⁺ 29 일 전
Hacker News की राय

  • पहले मैं email scraping को लेकर सावधान रहता था, लेकिन अब बस अपनी वेबसाइट पर अपना email सार्वजनिक रखता हूँ
    spam filtering काफी अच्छी है
    फिर भी ऐसी technical review दिलचस्प लगी। यह देखकर हैरानी हुई कि आसान तरीके भी काफ़ी असरदार हैं

    • 2000 के शुरुआती दौर से मैंने अपने ब्लॉग पर mailto: link के साथ email plain text में डाल रखा है, लेकिन spam दिन में बस कुछ messages ही आते हैं
      शायद Zoho filtering अच्छी हो, लेकिन मुझे नहीं लगता कि यह बड़ी services से खास बेहतर है
    • ज़्यादातर scraping bots पहले से ही लाखों addresses इकट्ठा कर चुके होते हैं, इसलिए कुछ दुर्लभ email पर वे ध्यान नहीं देते
      इसलिए अपना कोई आसान तरीका इस्तेमाल करना ठीक है, लेकिन अगर उसे सार्वजनिक कर दिया जाए तो वह तुरंत बेअसर हो सकता है
    • अपनी company website पर email डालने के बाद मुझे महीने में 1,500 से ज़्यादा spam मिलते हैं
    • मैंने भी इसी तरह email सार्वजनिक रखा है, लेकिन अगर HTML entities या display:none जैसे आसान तरीकों से 90% से ज़्यादा रोकना संभव हो, तो इस पर फिर से विचार किया जा सकता है
    • मेरा मानना है कि email अंततः leak हो ही जाता है। लेकिन LLM-आधारित spam के filters से बच निकलने की संभावना बढ़ती जा रही है

  • मेरा email GitHub के popular open source repository commits में 90 से अधिक बार plain text में शामिल है
    फिर भी 8 साल में मुझे लगभग spam नहीं मिला
    < और > में घिरा हुआ format शायद scrapers को भ्रमित करता हो
    आजकल direct scraping से ज़्यादा email lists खरीदना आम लगता है

    • मैंने अपने domain पर wildcard addresses सेट किए हुए हैं
      git@, contact@, admin@ जैसे addresses पर अक्सर spam आता है
      हाल में finance@ जैसे नकली address पर CEO बनकर भेजे गए mails भी आए
      विडंबना यह है कि HN profile पर plain text में रखा email लगभग spam-मुक्त है

  • मेरा अनुमान है कि email scrapers HTML parse नहीं करते, बल्कि बस @ character के आसपास की strings ढूँढते हैं
    HTML parsing महँगी होती है, इसलिए ऐसा आसान तरीका ज़्यादा efficient हो सकता है
    शायद इसी वजह से HTML entities असरदार लगती हैं

    • scrapers ने शायद यह सीख लिया हो कि obfuscated addresses पर भेजे गए spam की response rate कम होती है
      इसलिए वे ऐसे addresses को पूरी तरह नज़रअंदाज़ करते होंगे
    • सही है, ज़्यादातर simple byte search का इस्तेमाल करते हैं, लेकिन blackhat marketing में अलग-अलग scraping techniques मौजूद हैं
    • आखिरकार बात इस पर आती है कि सामने वाला कितना ज़िद्दी है। अतार्किक attacker अंत तक पीछे पड़ सकता है
    • @ के आसपास token-based extraction भी हल्के बदलावों के साथ ठीक से काम कर सकता है

  • लेख अच्छा है, लेकिन अफ़सोस है कि इसमें पूरे domain का मालिकाना रखकर हर recipient को अलग email देने वाले तरीके का ज़िक्र नहीं है
    spam आने पर बस उसी address को block किया जा सकता है
    या फिर email का इस्तेमाल ही न करने वाली ज़िंदगी भी है। आजकल temporary email से ज़्यादातर काम चल जाता है

    • मैं भी 20 साल से यही तरीका इस्तेमाल कर रहा हूँ
      लेकिन ज़्यादातर spam इसलिए आता है क्योंकि दोस्त या परिवार वाले मेरा address apps के साथ share कर देते हैं
      सार्वजनिक email को एक आसान JavaScript linking method से 100% रोका जा सका
    • पहले मैंने हर व्यक्ति के लिए unique email बनाने की कोशिश की थी, लेकिन अंत में इसे whitelist-आधारित single address तक सरल कर दिया
      असर लगभग वही रहा और management बहुत आसान हो गया

  • वेबसाइट में tarpit email address छिपाने का तरीका भी है
    CSS से उसे छिपा देते हैं ताकि इंसान न देख पाए, और अगर bot उस पर mail भेजे तो उस IP को 24 घंटे के लिए block कर देते हैं

    • लेकिन इससे Google जैसे बड़े mail servers भी block होने का जोखिम है
      क्योंकि Gmail accounts से भी spam आता है, इसलिए side effects काफ़ी बड़े हो सकते हैं
    • इसी तरह की एक अवधारणा Project Honey Pot है

  • सामग्री अच्छी है, लेकिन मुझे लगता है शीर्षक 'Email address obfuscation' ज़्यादा उपयुक्त होता
    हालाँकि ऐसे लेख देखकर spammers भी सीख सकते हैं

    • “email” को “email address” की जगह इस्तेमाल करना भ्रम पैदा करता है। संदर्भ के हिसाब से इसे अक्सर “email message” समझा जा सकता है
    • Greg Egan की साइट पर contact information की प्रस्तुति इतनी कठिन थी कि उसे decode करना संभव नहीं हुआ

  • मैंने पहले यह जाँचने के लिए test किया था कि “me at foobar dot com” जैसे expression अब भी असरदार हैं या नहीं
    LLM का इस्तेमाल करके कई email obfuscation methods को खोलने की कोशिश की, तो CSS या JS-आधारित तरीकों को छोड़कर ज़्यादातर को समझा जा सकता था
    फिर भी आजकल spam filters अच्छे से काम करते हैं, इसलिए plain text email सार्वजनिक करने पर भी कोई बड़ी समस्या नहीं हुई
    बल्कि service notification mails ज़्यादा परेशान करते हैं

    • इससे बेहतर तरीका यह है कि visitor थोड़ा CPU इस्तेमाल करके unique token email बनाए
      abuse होने पर बस उसी address को retire किया जा सकता है
      अगर client और mail server ऐसे API को support करें तो आदर्श होगा
    • LLM-आधारित scrapers इंसानों से बेहतर instructions की व्याख्या कर सकते हैं
      इसलिए simple regex bots को रोकने वाली बुनियादी obfuscation अब भी उपयोगी है
    • इससे जुड़ी xkcd 1808 comic भी है

  • इस साल की शुरुआत में C में Brainfuck interpreter बनाते समय मैंने उसे email obfuscation के लिए आज़माया था
    हर email को Brainfuck program के रूप में store किया, और JS interpreter उसे चलाकर plain text दिखाता था
    JS किसी external domain से load होता था, और referer verify करने के बाद ही असली code भेजा जाता था
    बेशक JS चलाने वाले scrapers के सामने यह बेअसर है, लेकिन रचनात्मक obfuscation experiment के रूप में दिलचस्प था

    • जानना चाहता हूँ कि यह तरीका सिर्फ JS में XOR encryption करने से किस तरह अलग है
    • अगर scraper screenshots को LLM या OCR में दे दे, तो यह तरीका बेकार हो जाएगा

  • यह लेख email scrapers को और ज़्यादा स्मार्ट बनाने वाली guide जैसा भी लगता है

    • सही, लेकिन JS या CSS execution, SVG rendering जैसी चीज़ें अब भी महँगी operations हैं, इसलिए बड़े पैमाने के bots के लिए यह बोझिल रहती हैं