ईमेल पते का गहन विश्लेषण

• ईमेल पता सिर्फ़ username और domain का साधारण संयोजन नहीं है, बल्कि इसमें RFC standards में परिभाषित जटिल संरचना, नियम, और security pitfalls शामिल होते हैं
• local part (@ से पहले) में quoted form, comments, Unicode आदि जैसे आम तौर पर कम-ज्ञात कई वैध formats मौजूद हैं, लेकिन ज़्यादातर व्यावहारिक environments में उनका support नहीं होता
• हर ईमेल में Envelope Sender और From header नाम के दो sender addresses होते हैं, और यही अंतर spoofing और phishing का मूल कारण बनता है
• Gmail की dot (.) ignore policy, plus addressing, domain aliases जैसे provider-specific behaviors का security और validation पर सीधा असर पड़ता है
• ईमेल पते collect या validate करने वाला system बनाते समय RFC standards और वास्तविक behavior के बीच के gap को सही तरह समझना अनिवार्य है

---

बुनियादी संरचना

• ईमेल पता तीन हिस्सों से बना होता है: local part (@ से पहले), @ separator, और domain (@ के बाद)
• ऊपर से यह सरल लगता है, लेकिन हर हिस्से में ऐसे rules और edge cases होते हैं जो security, privacy, और validation को प्रभावित करते हैं

लोकल पार्ट (Local Part)

• अनुमत characters

  • standard unquoted form (dot-atom) में अनुमत characters: अंग्रेज़ी अक्षर a-z, A-Z, अंक 0-9, special characters . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • इसकी अधिकतम लंबाई 64 octets होती है; standard ASCII में यह 64 characters के बराबर है, लेकिन Unicode local part में अंतर आता है
    • octet का सटीक मतलब 8-bit group होता है, और networking (IPv4) में 0~255 range दिखाने के लिए इसका उपयोग होता है
    • 64 octets, 512-bit लंबाई के data block के बराबर होते हैं

• uppercase/lowercase भेद

  • RFC 5321 के अनुसार local part तकनीकी रूप से case-sensitive होता है, इसलिए [e-mail] और [e-mail] अलग-अलग mailboxes हो सकते हैं
  • व्यवहार में, सभी प्रमुख email providers case को अलग नहीं मानते, इसलिए store या compare करने से पहले lowercase में normalize करना सुरक्षित default है
  • domain part हमेशा case-insensitive होता है

• dot (.) addressing

  • dot, local part में अनुमत है, लेकिन तीन सीमाएँ हैं: dot से शुरुआत नहीं हो सकती, dot पर अंत नहीं हो सकता, और लगातार dots नहीं हो सकते
  • Gmail dot normalization: Gmail local part में dots को पूरी तरह ignore करता है, इसलिए [e-mail], [e-mail], [e-mail] सभी एक ही inbox में पहुँचते हैं
    • यह RFC standard नहीं, बल्कि Gmail का अपना behavior है
    • attacker dot-variant addresses से अलग accounts बनाकर single-account limits bypass करने या free trials बार-बार लेने के लिए इसका दुरुपयोग कर सकता है; यह एक वास्तविक attack vector है

• subaddressing (plus addressing)

  • separator का उपयोग करके local part में tag जोड़ा जा सकता है, और mail server tag को बनाए रखते हुए mail को base address पर deliver कर सकता है (RFC 5233 standard)
  • सबसे आम separator + है, और Gmail, Outlook, ProtonMail, Fastmail आदि इसे support करते हैं
    • Yahoo की कुछ configurations और कुछ Postfix settings में - इस्तेमाल होता है
    • qmail में = default separator है, और यही कारण है कि VERP में @ को = से encode किया जाता है
  • मुख्य उपयोग के मामले:
    • leak tracking: service-specific tag (जैसे [e-mail]) के साथ signup करके spam मिलने पर leak source पता करना
    • inbox filtering: mail rules के ज़रिए खास tag वाले address की mails को auto-classify करना
    • multiple accounts: जो services plus को normalize नहीं करतीं, उनमें एक ही email से अलग accounts बनाए जा सकते हैं
  • कई websites के email validators + को reject कर देते हैं, लेकिन यह validation code का bug है, email की सीमा नहीं

• quoted string form

  • local part को double quotes में घेरने पर ज़्यादातर character restrictions ढीली हो जाती हैं, जिससे spaces, @, consecutive dots, leading/trailing dots आदि की अनुमति मिलती है
  • उदाहरण: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • व्यवहार में लगभग सभी email providers quoted local part स्वीकार नहीं करते, इसलिए RFC के हिसाब से वैध होने पर भी वास्तविक उपयोग में बेकार है

• comments

  • parentheses के अंदर comments local part की शुरुआत या अंत में आ सकते हैं, और mail server उन्हें हटाकर deliver करता है; delivery पर इसका असर नहीं पड़ता
  • RFC 5322 के अनुसार यह तकनीकी रूप से वैध है, लेकिन आधुनिक समय में इसका उपयोग नहीं होता
  • parentheses को reject करने वाले validators RFC से अधिक सख्त हैं

• Unicode local part (EAI)

  • RFC 6530, 6531, 6532 में परिभाषित email address internationalization (EAI) local part में UTF-8 characters की अनुमति देता है
  • SMTP session में SMTPUTF8 extension का उपयोग करना होता है, और sending तथा receiving servers दोनों को इसका support चाहिए
  • 2026 तक इसका adoption सीमित है, और Unicode characters 2~4 octets लेते हैं, इसलिए दिखने वाले character count से पहले ही 64-octet limit तक पहुँचना संभव है

• ऐतिहासिक formats

  • Bang path (UUCP): DNS से पहले modem से जुड़े Unix machine networks में ! से अलग किए गए hostname path (machine1!machine2!user) का उपयोग करने वाली routing method; allowed character list में ! शामिल होने का यही कारण है। अब पूरी तरह अप्रचलित
  • percent hack: [e-mail] form की relay routing trick, जहाँ % character routing mechanism RFC 5321 में deprecated होने के बाद भी local part में अब भी वैध है
  • source routing: SMTP RCPT TO command में explicit relay hops की सूची (@relay1,@relay2:user@domain)। RFC 5321 में deprecated

• VERP (Variable Envelope Return Path)

  • bulk mail systems में bounce पैदा करने वाले सटीक recipient को track करने की technique
  • recipient address को envelope sender (MAIL FROM) में encode किया जाता है, और recipient address के @ को = से replace किया जाता है
    • उदाहरण: bounces+alice=[e-mail]
  • Mailchimp, SendGrid, Amazon SES आदि large-scale bounce handling के लिए VERP या उसके variants का उपयोग करते हैं

• SRS (Sender Rewriting Scheme)

  • जब server mail forward करते समय SPF checks pass कराने के लिए envelope sender को rewrite करता है, तब इस तरह का address format दिखाई देता है
  • इसका form SRS0=HASH=TT=originaldomain.com=[e-mail] होता है
  • multiple-hop forwarding में SRS1=HASH=[e-mail] form होता है
  • संरचना के हिसाब से यह वैध email address है, लेकिन यह infrastructure output है, इंसानों द्वारा इस्तेमाल किया जाने वाला address नहीं
  • HASH component timestamp और original address पर आधारित HMAC होता है, जो forgery रोकने और token validity period सीमित करने का काम करता है

डोमेन भाग (Domain Part)

• लेबल नियम

  • डोमेन, डॉट से अलग किए गए लेबलों से बना होता है, और हर लेबल में अंग्रेज़ी अक्षर a-z, अंक 0-9, और हाइफ़न - की अनुमति होती है
  • यह हाइफ़न से शुरू या समाप्त नहीं हो सकता, और 3री~4थी स्थिति में लगातार हाइफ़न नहीं हो सकते (हालाँकि xn-- से शुरू होने वाले Punycode लेबल अपवाद हैं)
  • एक लेबल की अधिकतम लंबाई 63 अक्षर, पूरे डोमेन की अधिकतम लंबाई 253 अक्षर, और पूरे ईमेल पते (addr-spec) की अधिकतम लंबाई 254 अक्षर है

• सबडोमेन

  • डोमेन कई स्तरों का हो सकता है, और 253 अक्षरों की कुल डोमेन लंबाई के अलावा सबडोमेन की गहराई पर कोई कठोर सीमा नहीं है
  • सामान्य उपयोग: मेल इन्फ्रास्ट्रक्चर (mail., smtp., mx.), संगठन विभाजन (sales.company.com), ESP सेंडिंग (email.company.com)

• IP address literal

  • डोमेन नाम की जगह square brackets के अंदर IP address का उपयोग किया जा सकता है: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • RFC 5321 के अनुसार यह वैध है, लेकिन सार्वजनिक मेल सर्वर इसे लगभग कभी स्वीकार नहीं करते, और इसका उपयोग आंतरिक मेल सिस्टम और SMTP टेस्टिंग में होता है

• सिंगल-लेबल डोमेन

  • बिना डॉट वाले डोमेन (जैसे user@localhost) कुछ संदर्भों में तकनीकी रूप से वैध हैं, लेकिन सार्वजनिक मेल सर्वर उन्हें अस्वीकार करते हैं
  • postmaster@localhost, Unix-आधारित सिस्टम में लोकल सिस्टम मेल का एक परंपरागत विशेष मामला है

• Internationalized Domain Name (IDN) और Punycode

  • DNS केवल ASCII को सपोर्ट करता है, इसलिए non-ASCII अक्षरों को Punycode (RFC 3492) में encode किया जाता है, और सभी encoded लेबल xn-- prefix से शुरू होते हैं
  • ईमेल क्लाइंट इन्हें native script में दिखाते हैं और SMTP इन्हें Punycode रूप में भेजता है
  • होमोग्राफ अटैक: अलग Unicode scripts के देखने में समान अक्षरों का उपयोग करके, प्रसिद्ध डोमेन जैसे दिखने वाले डोमेन रजिस्टर किए जा सकते हैं। ब्राउज़र संदिग्ध IDN के लिए Punycode दिखाने जैसी सुरक्षा देते हैं, लेकिन अधिकांश ईमेल क्लाइंट्स में ऐसी सुरक्षा नहीं होती, इसलिए ईमेल में यह हमला ज़्यादा प्रभावी होता है

• ट्रेलिंग डॉट (Trailing Dot)

  • DNS में हर डोमेन तकनीकी रूप से root zone को दर्शाने वाले trailing dot पर समाप्त होता है, लेकिन ईमेल में यह हमेशा implicit होता है और छोड़ दिया जाता है
  • अधिकांश validators [e-mail]. जैसे रूप को अस्वीकार करते हैं

• MX record

  • ईमेल पते का डोमेन ज़रूरी नहीं कि वही जगह हो जहाँ मेल सर्वर मौजूद हो; sending server, वास्तविक मेल सर्वर hostname पता करने के लिए MX(Mail Exchanger) DNS record देखता है
  • कम priority number का मतलब अधिक प्राथमिकता होता है, और अगर MX record बिल्कुल न हो तो डोमेन के A record पर fallback किया जाता है
  • अगर किसी डोमेन को कभी भी ईमेल प्राप्त नहीं करना चाहिए, तो null MX record (MX 0 .) प्रकाशित करके sending servers को स्पष्ट रूप से बताया जा सकता है कि वे डिलीवरी का प्रयास न करें (RFC 7505)

टॉप-लेवल डोमेन (TLD)

• मूल सामान्य TLD

  • शुरुआती इंटरनेट के 7 gTLD: .com (व्यावसायिक, अब unrestricted, Verisign द्वारा संचालित), .net (नेटवर्क, unrestricted), .org (संगठन, unrestricted), .edu (अमेरिका की मान्यता प्राप्त शैक्षणिक संस्थाएँ, restricted), .gov (अमेरिकी सरकार, restricted), .mil (अमेरिकी सेना, restricted), .int (संधि-आधारित अंतरराष्ट्रीय संगठन, बहुत अधिक restricted)
  • .arpa, IANA द्वारा प्रबंधित एक infrastructure TLD है, जिसका उपयोग reverse DNS lookup में होता है

• country code TLD (ccTLD)

  • ISO 3166-1 alpha-2 country code पर आधारित 2-अक्षरीय कोड, जिनकी संख्या लगभग 250 है
  • कुछ ccTLD का उपयोग दूसरे उद्योगों ने नए उद्देश्य से करना शुरू कर दिया है:
    • .io (British Indian Ocean Territory → tech कंपनियाँ), .tv (Tuvalu → media·streaming), .ai (Anguilla → AI कंपनियाँ), .co (Colombia → .com का विकल्प), .me (Montenegro → personal sites), .ly (Libya → URL shortening), .sh (Saint Helena → software projects)
  • ऐसे repurposed ccTLD का उपयोग करने पर तकनीकी रूप से आप उस देश की registry jurisdiction के अधीन होते हैं, और डोमेन पर नियंत्रण ICANN नहीं बल्कि मूल देश की registry का होता है

• sponsored TLD (sTLD)

  • प्रायोजक संगठन और पात्रता शर्तों वाले TLD: .aero (air transport, SITA प्रायोजित), .coop (cooperatives), .museum (museums), .jobs (employment), .xxx (adult), .post (postal), .cat (Catalan भाषा·संस्कृति)

• नए सामान्य TLD (2012 के बाद)

  • 2012 में ICANN ने नए gTLD applications खोल दिए, जिसके बाद 1,200 से अधिक नए TLD delegate किए गए
  • ईमेल validation पर महत्वपूर्ण प्रभाव: TLD की लंबाई 4~6 अक्षरों तक सीमित करने वाले validators टूट जाते हैं (.photography, .international, .construction आदि)
  • डेवलपर-संबंधित: .app, .dev, .web, .code / commercial: .shop, .store, .online / content: .blog, .news, .media / business: .tech, .agency, .cloud
  • कम registration cost और कुछ registries की कमजोर abuse policies के कारण, नए gTLD spam और phishing में असमान रूप से अधिक दिखाई देते हैं

• brand TLD

  • 2012 के ICANN expansion के दौरान बड़ी कंपनियों ने अपने खुद के TLD के लिए आवेदन किया: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • इनका अधिकांशतः सार्वजनिक ईमेल पतों में उपयोग नहीं होता; ये मुख्य रूप से आंतरिक उद्देश्यों के लिए होते हैं या बिल्कुल उपयोग में नहीं आते

• geographic·city TLD

  • शहरों और क्षेत्रों के अपने TLD: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • रजिस्ट्रेशन के समय आमतौर पर उस क्षेत्र से संबंध साबित करना ज़रूरी होता है

• internationalized TLD

  • non-ASCII scripts वाले TLD कई देशों में मौजूद हैं, और DNS में इन्हें Punycode में encode किया जाता है
    • .xn--p1ai (रूस, Cyrillic), .xn--fiqz9s (चीन, simplified Chinese), .xn--mgberp4a5d4ar (सऊदी अरब, Arabic script), .xn--h2brj9c (भारत, Devanagari script)

• reserved·documentation TLD

  • RFC 2606 और RFC 6761 में टेस्टिंग और documentation के लिए reserved TLD:
    • .test (public DNS में कभी मौजूद नहीं होता, इसलिए software testing के लिए सुरक्षित), .example (documentation examples के लिए), .invalid (जब निश्चित रूप से unresolved domain चाहिए), .localhost (loopback के लिए)
  • IANA ने documentation और examples के लिए example.com, example.net, example.org रजिस्टर कर रखे हैं, इसलिए इन्हें बिना किसी वास्तविक mailbox तक पहुँचने की चिंता के code examples में स्वतंत्र रूप से इस्तेमाल किया जा सकता है

• deprecated TLD

  • देश के समाप्त हो जाने पर हटाए गए ccTLD: .yu (Yugoslavia, 2010 में हटाया गया), .cs (Czechoslovakia, 1995 में हटाया गया), .dd (East Germany, 1990 में हटाया गया), .tp (East Timor, .tl से बदले जाने के बाद 2015 में पूरी तरह हटाया गया)
  • अपवाद: .su (सोवियत संघ), 1991 में विघटन के बावजूद अब भी सक्रिय डोमेन रखता है, और IANA कई वर्षों से इसके transition पर चर्चा कर रहा है, फिर भी यह सक्रिय बना हुआ है

ccTLD के 2nd-level domain

• कई ccTLD, रजिस्टर किए जा सकने वाले नाम और TLD के बीच एक functional 2nd-level category जोड़ते हैं
  • यूनाइटेड किंगडम: .co.uk, .org.uk, .gov.uk / ऑस्ट्रेलिया: .com.au, .edu.au / जापान: .co.jp, .ac.jp / भारत: .co.in, .gov.in / ब्राज़ील: .com.br, .gov.br
• ईमेल verification systems में organizational domain ढूंढना हो तो यह validation और organizational domain detection को प्रभावित करता है

• Public Suffix List (PSL)

  • publicsuffix.org पर community द्वारा मेंटेन की गई सूची, जिसमें वे सभी domain suffixes शामिल हैं जिन्हें इंटरनेट उपयोगकर्ता सीधे रजिस्टर कर सकते हैं
  • इसमें official delegations (.co.uk, .com.au) और private registries (github.io, wordpress.com, herokuapp.com) दोनों शामिल हैं
  • wildcard notation का उपयोग होता है (जैसे *.ck), exceptions को ! से दिखाया जाता है (जैसे !www.ck)
  • ईमेल validators और spam filters इसे पूरे domain string से organizational domain पहचानने के लिए उपयोग करते हैं
  • यह IETF standard नहीं है, लेकिन इस समस्या के लिए de facto standard है

ईमेल address format

• Basic address (Bare Address)

  • local@domain रूप का addr-spec, जो SMTP commands और simple contexts में उपयोग होता है

• Angle bracket format

  • SMTP में MAIL FROM और RCPT TO commands के लिए पते को angle brackets में wrap किया जाता है: MAIL FROM:<[e-mail]>
  • angle brackets, SMTP command syntax का हिस्सा हैं, स्वयं पते का हिस्सा नहीं

• Display Name Format

  • message headers (From, To, Cc) में इंसानों के पढ़ने योग्य नाम angle-bracket address से पहले आ सकता है: "John Doe" <[e-mail]>
  • display name में special characters हों तो quotes आवश्यक हैं
  • display name spoofing: sender display name को मनचाहे तरीके से सेट कर सकता है, इसलिए "PayPal Security <[e-mail]>" <[e-mail]> जैसे हमले संभव हैं
    • कई email clients inbox list में सिर्फ display name दिखाते हैं, इसलिए यह सबसे आम phishing techniques में से एक है

• Group syntax

  • RFC 5322 में परिभाषित कई recipients के लिए named group format: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • private recipients pattern: To: undisclosed-recipients:; — यह एक empty group syntax है, जहां actual recipients SMTP envelope (RCPT TO) में होते हैं और message header में दिखाई नहीं देते

• Encoded display names

  • पुराने email systems में display name के non-ASCII characters को RFC 2047 encoded word के रूप में संभाला जाता था: =?charset?encoding?encoded_text?=
  • encoding B (base64) या Q (quoted-printable) होती है
  • आधुनिक SMTPUTF8 support होने पर इस encoding wrapper के बिना headers में सीधे UTF-8 इस्तेमाल किया जा सकता है

हर ईमेल के दो sender

• Envelope sender (Envelope Sender / MAIL FROM)

  • यह SMTP MAIL FROM: command में सेट होता है और message content का हिस्सा नहीं होता
  • bounce routing के लिए उपयोग होता है, SPF checks में verify किया जाता है, और final receiving server इसे Return-Path: header के रूप में store करता है
  • इसे envelope from, reverse path, RFC5321.MailFrom भी कहा जाता है

• From header

  • message के From: header में मौजूद address, जिसे email client sender के रूप में दिखाता है
  • DMARC, SPF या DKIM alignment के साथ इसी की सुरक्षा करता है
  • sender इसे स्वतंत्र रूप से सेट कर सकता है, और अधिकांश mail servers पर कोई unique validation नहीं होती
  • ये दोनों पते पूरी तरह अलग हो सकते हैं, और यह सामान्य तथा अपेक्षित स्थिति है:
    • ESP bulk sending में MAIL FROM [e-mail] हो सकता है, जबकि From header [e-mail]
    • mailing list में MAIL FROM सूची का bounce address होता है, जबकि From header मूल पोस्ट करने वाले का
    • email forwarding में forwarding server, SRS से MAIL FROM को rewrite करता है, लेकिन From header मूल sender का ही रखता है
  • अगर domain पर DMARC लागू नहीं है, तो कोई भी पूरी तरह असंबंधित MAIL FROM इस्तेमाल करते हुए उस domain को From header में डालकर भेज सकता है

• Sender header

  • जब message का वास्तविक submitter, From address से अलग हो, तो वास्तविक प्रेषक की पहचान करता है: Sender: [e-mail]

• Reply-To header

  • यह बताता है कि reply कहां जाना चाहिए, और यह From address से अलग हो सकता है
  • phishing vector के रूप में इसका दुरुपयोग भी होता है: attacker From को वैध दिखाकर Reply-To को अपने address पर सेट कर देता है

• Null sender

  • MAIL FROM:<> एक वैध और महत्वपूर्ण SMTP structure है; empty envelope sender का उपयोग bounce messages, auto-replies, और उन messages के लिए होता है जिन्हें स्वयं bounce generate नहीं करना चाहिए
  • यह दो systems के बीच failure notifications के लगातार आदान-प्रदान से बनने वाले infinite bounce loop को रोकता है

Role-based addresses

• RFC 5321 requirement

  • postmaster@domain: RFC 5321 के अनुसार, mail स्वीकार करने वाले हर domain के लिए इस address पर भेजे गए mail को स्वीकार करना अनिवार्य है, कोई अपवाद नहीं

• RFC 2142 recommendation

  • abuse@domain (spam/abuse reports), hostmaster@domain (DNS zone management), security@domain (vulnerability disclosure/security reports), webmaster@domain (web server issues), noc@domain (network operations)

• Conventional role addresses

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ आदि आधिकारिक standard नहीं हैं, लेकिन व्यापक रूप से उपयोग होते हैं
  • role addresses आमतौर पर कई लोगों द्वारा साझा किए जाते हैं, इसलिए sensitive information भेजते समय कई team members उसे देख सकते हैं
  • abuse@ और postmaster@ पर शिकायत वाले mails आते हैं, इसलिए वे social engineering का लक्ष्य बनते हैं

• Catch-all addresses

  • यह किसी खास email address format के बजाय mail server configuration है, जिसमें किसी local part के लिए specific mailbox न होने पर भी delivery स्वीकार की जाती है
  • उपयोग के मामले: typos पकड़ना, developer testing, और औपचारिक alias system के बिना service-specific unique addresses बनाना
  • नुकसान: किसी भी local part पर delivery हो जाने से बहुत अधिक spam influx आता है, और SMTP probing द्वारा address validity जांचना असंभव हो जाता है (हर probe को success response मिलता है)

प्रदाता-विशिष्ट व्यवहार

• Gmail

  • डॉट नॉर्मलाइज़ेशन: लोकल पार्ट में मौजूद सभी डॉट को अनदेखा करता है
  • प्लस एड्रेसिंग: + डिलिमिटर को सपोर्ट करता है
  • @googlemail.com: जर्मनी और UK में ट्रेडमार्क विवाद के कारण @gmail.com का ऐतिहासिक उपनाम; दोनों डोमेन एक ही inbox में डिलीवर होते हैं
  • कैरेक्टर सीमा: लोकल पार्ट में केवल अंग्रेज़ी अक्षर, अंक और डॉट की अनुमति (प्लस एड्रेसिंग के लिए + सहित)। पूरा RFC character set समर्थित नहीं
  • लोकल पार्ट लंबाई सीमा: RFC के अधिकतम 64 कैरेक्टर से काफी कम, केवल 30 कैरेक्टर

• Microsoft (Outlook, Hotmail, Live)

  • कोई डॉट नॉर्मलाइज़ेशन नहीं: [e-mail] और [e-mail] अलग-अलग mailbox हैं
  • डोमेन alias: @hotmail.com, @live.com, @outlook.com alias कॉन्फ़िगरेशन में एक ही account को संदर्भित कर सकते हैं
  • प्लस एड्रेसिंग सपोर्ट करता है

• Apple (iCloud)

  • डोमेन alias: @icloud.com, @me.com, @mac.com एक ही inbox पर जाते हैं (.mac → .me → .icloud के रूप में service name change history)
  • प्लस एड्रेसिंग सपोर्ट करता है
  • Hide My Email: [e-mail] फ़ॉर्म का random alias generation, जिससे हर service या app के लिए अलग alias बनता है और वास्तविक पता छिपा रहता है

• ProtonMail / Proton

  • डोमेन alias: @proton.me, @protonmail.com, @pm.me एक ही inbox पर जाते हैं
  • प्लस एड्रेसिंग सपोर्ट करता है

• ईमेल alias services

  • disposable email से अलग, स्थायी और नियंत्रित forwarding address बनाने वाली services:
    • SimpleLogin (Proton का हिस्सा): custom और random alias के साथ किसी भी inbox में forward
    • Addy.io (पहले AnonAddy): SimpleLogin जैसा, self-hosting संभव
    • Firefox Relay (Mozilla): free plan में सीमित random alias
    • DuckDuckGo Email Protection: @duck.com alias
  • प्रेषक के लिए ये ऐसे पते बनाते हैं जिन्हें संरचनात्मक रूप से वास्तविक inbox पते से अलग पहचानना मुश्किल होता है
  • disposable email से मुख्य अंतर: alias स्थायी और नियंत्रित होते हैं, किसी खास alias को disable किया जा सकता है, service-वार भेजी गई मेल ट्रैक की जा सकती है, और इच्छित inbox में forward किया जा सकता है

disposable·temporary email

• ये बिना signup के inbox देते हैं, जो आम तौर पर थोड़े समय बाद expire हो जाते हैं; Mailinator, Guerrilla Mail, 10 Minute Mail, TempMail इसके प्रमुख उदाहरण हैं
• अधिकांश catch-all routing का उपयोग करते हैं, इसलिए उस डोमेन के किसी भी लोकल पार्ट पर भेजी गई मेल inbox तक पहुँच जाती है
• कई inbox public होते हैं, इसलिए पता जानने वाला कोई भी व्यक्ति संदेश पढ़ सकता है
• ज्ञात disposable domains की blocklist मौजूद है (disposable-email-domains GitHub repository सबसे ज़्यादा उद्धृत है), लेकिन यह हमेशा अधूरी रहती है, और block से बचने के लिए लगातार नए डोमेन अपनाए जाते हैं

वैलिडेशन

• तकनीकी वैधता बनाम व्यावहारिक वैधता

  • RFC के अनुसार वैध, लेकिन वास्तविक सर्वर पर लगभग कभी स्वीकार नहीं किए जाते: quotes के अंदर space (" "@example.com), quotes के अंदर @ ("user@name"@example.com), IP literal domain (user@[192.168.1.1]), single-character/single-label (a@b)
  • RFC के अनुसार वैध और व्यवहार में भी स्वीकार्य: [e-mail], [e-mail], [e-mail], [e-mail]
  • अधिकांश applications में practical validator, पूर्ण RFC-compliant validator से बेहतर होता है: बेसिक structure check, उचित character set validation, और वैकल्पिक रूप से डोमेन का DNS MX lookup

• सामान्य validator bugs

  • लोकल पार्ट में + अस्वीकार करना: [e-mail] पूरी तरह वैध है, और यह बहुत आम bug है
  • लोकल पार्ट में _ अस्वीकार करना: यह भी वैध है
  • लोकल पार्ट में % अस्वीकार करना: यह एक वैध character है; deprecated केवल percent-hack routing है
  • TLD लंबाई को 4~6 कैरेक्टर तक सीमित करना: .photography, .international, .construction जैसे सैकड़ों नए gTLDs block हो जाते हैं
  • hardcoded TLD list से validation: सूची लगातार बदलती रहती है, इसलिए validator पुराना पड़ जाता है
  • गलत कुल लंबाई सीमा: 254 की जगह 255 या 256 का उपयोग। RFC 3696 erratum 1690 ने व्यापक रूप से उद्धृत गलत मान 320 को 254 में सुधारा
  • लोकल पार्ट में uppercase अस्वीकार करना: RFC के अनुसार वैध
  • [e-mail] अस्वीकार करना: यह वैध है; second-level ccTLD pattern वाले multi-dot domains सामान्य हैं
  • .dev, .app, .io को TLD के रूप में अस्वीकार करना: ये सभी वैध delegated TLDs हैं

• लंबाई सीमाएँ

  भाग	सीमा
  लोकल पार्ट	64 octets
  डोमेन label	63 octets
  पूरा डोमेन	253 octets
  पूरा address (addr-spec)	254 octets

• लोकल पार्ट की सीमा characters में नहीं बल्कि octets में होती है, इसलिए multi-byte Unicode characters वाले EAI पते दिखने में 64 characters से छोटे होने पर भी octet limit तक पहुँच सकते हैं

• DNS-आधारित validation

  • MX record check: यह सत्यापित करता है कि डोमेन में MX record है या नहीं; यह तेज़ और कम-जोखिम वाला है। जो डोमेन A record fallback का उपयोग करते हैं (MX configured नहीं), वे इस check में fail हो सकते हैं
  • Null MX check: अगर डोमेन में MX 0 . है, तो वह स्पष्ट रूप से mail receive नहीं करता
  • SMTP RCPT TO probing: mail server से कनेक्ट करके RCPT TO command भेजी जाती है ताकि पता चले कि पता स्वीकार होगा या नहीं, लेकिन कई server address harvesting रोकने के लिए हर पते पर 250 response लौटाते हैं, इसलिए यह विश्वसनीय नहीं। catch-all domains हमेशा positive response देते हैं। probe IP के blacklist होने का जोखिम भी रहता है
  • ईमेल पते को पूरी तरह विश्वसनीय तरीके से validate करने का एकमात्र तरीका वास्तविक संदेश भेजकर उसकी डिलीवरी की पुष्टि करना है; बाकी सब heuristic हैं

सुरक्षा निहितार्थ

• display name spoofing

  • कोई भी व्यक्ति ईमेल का display name मनचाहा सेट कर सकता है, और जिन inbox views में केवल display name दिखता है, वहाँ उपयोगकर्ता यदि वास्तविक पता स्पष्ट रूप से न देखें तो वैध प्रेषक और छलावरण में अंतर नहीं कर सकते

• Punycode के जरिए homograph attack

  • अलग Unicode scripts के अक्षरों का उपयोग करके दिखने में बिल्कुल समान डोमेन रजिस्टर किए जा सकते हैं, जो किसी प्रसिद्ध वास्तविक डोमेन जैसे लगें
  • browsers के विपरीत, email clients आम तौर पर इसके बारे में कोई चेतावनी नहीं दिखाते

• Gmail डॉट ट्रिक से account bypass

  • क्योंकि Gmail डॉट को अनदेखा करता है, हमलावर किसी मौजूदा Gmail पते के dot-variant से service पर signup करके single-account limit को bypass कर सकता है, duplicate free trials ले सकता है, और मूल account owner के लिए भेजे गए ईमेल प्राप्त कर सकता है

• ईमेल address reuse

  • email providers त्यागे गए addresses को नए उपयोगकर्ताओं को फिर से आवंटित कर सकते हैं; तब नया account owner उन services के account recovery emails पा सकता है जिनमें पहले वाले owner ने वही पता इस्तेमाल किया था, और password reset के जरिए account hijack संभव हो सकता है
  • Gmail कहता है कि वह addresses को reassign नहीं करता, लेकिन कुछ अन्य providers में ऐतिहासिक रूप से reassign करने के उदाहरण रहे हैं

• subaddress tag exposure

  • यदि कोई [e-mail] से signup करता है, तो receiving service tag सहित पूरा पता देख सकती है
  • जो services plus tag हटाकर पता store करती हैं, वे base address को उजागर कर देती हैं; और जो पूरा पता जस का तस store करती हैं, वे account settings या data export में tracking strategy को प्रकट कर सकती हैं