एक संदेश लीजिए। मान लीजिए Bright Parcel नाम की एक काल्पनिक दुकान में अभी-अभी एक विज़िटर ने quietfox42@veylax.com पते से साइन-अप किया है, और उसका सिस्टम कन्फ़र्मेशन ईमेल पर Send जैसा कुछ दबा देता है। थोड़ी देर बाद वह संदेश विज़िटर की स्क्रीन पर होता है, और एक दिन बाद इनबॉक्स सर्विस पर कहीं भी नहीं रहता। यह लेख उसका पूरा रास्ता दिखाता है।
तो टेंप मेल कैसे काम करता है? यह इंटरनेट मेल की आम मशीनरी ही इस्तेमाल करता है, बस एक मोड़ के साथ: पाने वाला सिरा अपने डोमेनों के किसी भी यूज़रनेम का मेल ले लेता है और उसे बहुत थोड़े समय रखता है। भेजने वाले का सर्वर DNS में डोमेन का MX रिकॉर्ड खोजता है, सूचीबद्ध होस्ट से पोर्ट 25 पर SMTP से जुड़ता है, और संदेश सौंप देता है। फिर टेंप मेल सिस्टम उसे पार्स करता है, इनबॉक्स में दिखाता है, और तय समय पर हटा देता है। VookMail पर डोमेनों के MX रिकॉर्ड एक मेल डिलीवरी प्रोवाइडर की ओर जाते हैं, जो SMTP सत्र लेता है और हर संदेश को HTTPS से VookMail को फ़ॉरवर्ड कर देता है।
चरण 1: भेजने वाले से निकलना
Bright Parcel की एप्लिकेशन संदेश बनाती है। संदेश संरचित टेक्स्ट होता है, जिसकी बनावट Internet Message Format (RFC 5322) के अनुसार होती है: From, To और Subject जैसे हेडर, फिर एक खाली पंक्ति, फिर बॉडी। एप्लिकेशन आम तौर पर उसे सीधे डिलीवर नहीं करती। वह उसे जाने वाली मेल सर्विस को सौंप देती है, या तो पोर्ट 587 (या शुरू से TLS के साथ 465) पर प्रमाणित SMTP कनेक्शन से, या भेजने वाली कंपनी की वेब API से।
पहली देरी यहीं हो सकती है। कई एप्लिकेशन जाने वाले मेल को जॉब क्यू में डालती हैं और उन्हें बैच में निपटाती हैं, खासकर मार्केटिंग प्लैटफ़ॉर्म। इसलिए जिस पल वेबसाइट "अपना ईमेल देखें" कहती है, वह मेल के निकलने के पल से कुछ आगे हो सकता है। हमारे उदाहरण में मान लीजिए क्यू में बीस सेकंड लगते हैं। तब तक पाने वाले की तरफ़ कुछ नहीं पहुंचा है, और कोई टेंप मेल सेवा उसे देख या तेज़ नहीं कर सकती।
चरण 2: पता लगाना कि veylax.com का मेल कहां जाता है
जाने वाला सर्वर @ के बाद का हिस्सा पढ़ता है, यहां veylax.com, और DNS से उस डोमेन के MX रिकॉर्ड मांगता है। MX (मेल एक्सचेंजर) रिकॉर्ड उस सर्वर का नाम बताता है जो डोमेन का मेल लेता है। ज़ोन-फ़ाइल की लिखावट में किसी डोमेन के रिकॉर्ड ऐसे दिख सकते हैं। नाम समझाने के लिए गढ़े गए हैं:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
3600 TTL (टाइम टू लिव) है, यानी वे सेकंड जितनी देर कोई रिज़ॉल्वर इस जवाब को कैश कर सकता है। 10 और 20 प्राथमिकताएं हैं: भेजने वाले सबसे छोटे नंबर को पहले आज़माते हैं, और वह न मिले तो बड़े वाले पर लौटते हैं। होस्टनेम का अपना A (IPv4) या AAAA (IPv6) रिकॉर्ड होना चाहिए। MX रिकॉर्ड को होस्टनेम की ओर इशारा करना चाहिए, सीधे किसी IP पते या CNAME एलियास की ओर नहीं।
यह लुकअप आप खुद किसी भी डोमेन के लिए चला सकते हैं:
| सिस्टम | कमांड |
|---|---|
| Windows Command Prompt | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS और Linux | dig MX example.com +short |
दुरुपयोग रोकने वाले सिस्टम यही लुकअप उन डोमेनों को पकड़ने में इस्तेमाल करते हैं जो मेल को जाने-पहचाने डिस्पोज़ेबल ढांचे की ओर भेजते हैं। यह एक वजह है कि कुछ वेबसाइटें टेंप मेल डोमेन तब भी पहचान लेती हैं जब डोमेन खुद नया हो।
DNS के दो किनारे वाले मामले
जिस डोमेन का MX रिकॉर्ड न हो, वह अपने आप पहुंच से बाहर नहीं हो जाता। SMTP का मानक RFC 5321 एक विकल्प तय करता है: भेजने वाला डोमेन के अपने A या AAAA रिकॉर्ड को मान लिए गए मेल होस्ट की तरह ले सकता है। जो डोमेन कोई मेल नहीं चाहता, वह null MX (RFC 7505) से यह कह सकता है, जो प्राथमिकता 0 और होस्ट की जगह एक अकेले डॉट वाला MX रिकॉर्ड है। टेंप मेल डोमेन ज़ाहिर है सामान्य MX रिकॉर्ड छापते हैं, क्योंकि मेल पाना ही उनका पूरा मकसद है।
जब कोई सेवा नया डोमेन जोड़ती है, तब कैशिंग भी आड़े आ सकती है। जिन रिज़ॉल्वरों को हाल में "ऐसा कोई रिकॉर्ड नहीं" का जवाब मिला हो, वे उसे तब तक रख सकते हैं जब तक नेगेटिव कैश का समय खत्म न हो, जिसे डोमेन का SOA रिकॉर्ड तय करता है (RFC 2308)। इसलिए बिल्कुल नए डोमेन को हर भेजने वाले से भरोसे से मेल पाने में कुछ समय लग सकता है।
चरण 3: दो सर्वरों की बातचीत
Bright Parcel का जाने वाला सर्वर अब पसंदीदा MX होस्ट से पोर्ट 25 पर TCP कनेक्शन खोलता है। SMTP टेक्स्ट प्रोटोकॉल है: क्लाइंट कमांड भेजता है और सर्वर क्रमांक वाले जवाब देता है। हमारे संदेश का एक सरल सत्र यह है, जिसमें S: पाने वाला है और C: भेजने वाला। होस्ट और साइज़ का आंकड़ा इसी गढ़े हुए उदाहरण के हैं।
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(TLS handshake, then EHLO again)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (headers, blank line, body, then a line with a single dot)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| कमांड | मकसद | टेंप मेल के लिए इसका मतलब |
|---|---|---|
EHLO | भेजने वाले की पहचान बताता है और पूछता है कि सर्वर क्या सपोर्ट करता है | जवाब में STARTTLS जैसे एक्सटेंशन और अधिकतम SIZE की सूची होती है |
STARTTLS | कनेक्शन को TLS में बदलता है (RFC 3207) | सिर्फ़ इसी एक पड़ाव को सुरक्षित करता है। यह एंड-टू-एंड एन्क्रिप्शन नहीं है |
MAIL FROM | एनवेलप भेजने वाले को तय करता है, यानी जहां बाउंस जाते हैं | अक्सर दिखने वाली From पंक्ति से अलग होता है, खासकर बल्क भेजने वालों में |
RCPT TO | पाने वाले का नाम बताता है | कैच-ऑल रिसीवर अपने डोमेनों के किसी भी यूज़रनेम पर 250 देता है |
DATA | संदेश की सामग्री शुरू करता है | अकेली पंक्ति में एक डॉट पर खत्म होता है |
QUIT | सत्र बंद करता है | डिलीवरी DATA के बाद वाले 250 से पहले ही तय हो चुकी थी |
वह पल जब ज़िम्मेदारी हाथ बदलती है
वह आखिरी 250 पूरे सत्र की सबसे अहम पंक्ति है। वहां तक संदेश Bright Parcel के सर्वर का है, और कनेक्शन टूटे तो वह फिर कोशिश करता है। उसके बाद पाने वाले ने ज़िम्मेदारी स्वीकार कर ली। भेजने वाले का डैशबोर्ड अब आम तौर पर "delivered" कहेगा, जिसका मतलब सिर्फ़ इतना है कि यह पड़ाव सफल रहा। इसका मतलब यह नहीं कि किसी इंसान ने कुछ देखा।
रिप्लाई कोड लोगों को दिखने वाले बहुत-से व्यवहार को समझा देते हैं:
- 2xx सफलता है, और
250का मतलब स्वीकार किया गया। - 3xx बीच का कदम है, और
354भेजने वाले से संदेश भेजने को कहता है। - 4xx अस्थायी विफलता है, जैसे
421या451। भेजने वाला संदेश को अपनी क्यू में रखता है और दोबारा कोशिश करता है। - 5xx स्थायी विफलता है, जैसे
550(मेलबॉक्स उपलब्ध नहीं या ठुकराया गया) या552(बहुत बड़ा)। भेजने वाला हार मान लेता है और आम तौर पर बाउंस संदेश बनाता है।
4xx और 5xx का फ़र्क ज़्यादातर "धीमे" मेल की व्याख्या करता है। अगर पाने वाला यहां 451 कहता, शायद ग्रेलिस्टिंग (RFC 6647) की वजह से, तो हमारा संदेश Bright Parcel की क्यू में पड़ा रहता, न खोया हुआ, न डिलीवर हुआ। RFC 5321 सलाह देता है कि दोबारा कोशिश का अंतराल आम तौर पर कम से कम 30 मिनट और हार मानने का समय कम से कम चार-पांच दिन हो, हालांकि असली सिस्टम अपनी योजना खुद तय करते हैं, और कई जल्दी दोबारा कोशिश करते हैं। इसीलिए एक कन्फ़र्मेशन कुछ सेकंड में दिख सकता है और अगला बीस मिनट में, और दोनों में कुछ गलत नहीं होता।
पतों के दो सेट
SMTP में पतों की दो परतें होती हैं। एनवेलप, यानी MAIL FROM और RCPT TO, वह है जो सर्वर रूटिंग के लिए इस्तेमाल करते हैं। हेडर, यानी From:, To: और Subject:, संदेश की सामग्री का हिस्सा हैं और वही हैं जो आप स्क्रीन पर देखते हैं। वे अलग हो सकते हैं। कोई न्यूज़लेटर To: subscribers दिखा सकता है जबकि एनवेलप का पाने वाला आपका अस्थायी पता था। इसलिए पाने वाला सिस्टम संदेशों को एनवेलप के पाने वाले के हिसाब से रखता है, जो भरोसेमंद मान है। इसी वजह से आखिरी डिलीवरी पर जुड़ने वाला Return-Path हेडर दिखने वाले From पते की जगह एनवेलप भेजने वाले को दर्ज करता है।
चरण 4: quietfox42 को मौजूद क्यों नहीं होना पड़ा
RCPT TO पर आम मेल सर्वर जांचता है कि मेलबॉक्स मौजूद है या नहीं, और न हो तो 550 कहता है। टेंप मेल डोमेन उल्टे ढंग से चलता है। वह कैच-ऑल, यानी वाइल्डकार्ड, रिसीवर की तरह चलता है: हर लोकल पार्ट (@ से पहले का हिस्सा) स्वीकार होता है।
यही एक चुनाव तुरंत बनने वाले पते संभव करता है। जब VookMail आपको रैंडम पता दिखाता है, तो किसी मेल सर्वर पर कुछ बनाना नहीं पड़ा। जब आप नया दबाते हैं, अपना यूज़रनेम टाइप करते हैं, डोमेन चुनते हैं और तीर दबाते हैं, तो वह नाम पहले से "मौजूद" है, क्योंकि डोमेन सारे नाम स्वीकार करता है। एप्लिकेशन को बस वे संदेश दिखाने हैं जिनका पाने वाला आपकी स्क्रीन पर लिखे पते से मेल खाता हो।
उन नामों पर दो छोटे नियम लागू होते हैं। मानक कहता है कि लोकल पार्ट केस-सेंसिटिव हो सकता है, पर लगभग सारे असली सिस्टम Test@ और test@ को एक ही मेलबॉक्स मानते हैं, इसलिए टेंप मेल सिस्टम समझदारी से केस को एक जैसा कर देता है ताकि भेजने वाले की कैपिटल लिखावट इनबॉक्स को दो हिस्सों में न बांट दे। और RFC 5321 लोकल पार्ट को 64 ऑक्टेट तक सीमित करता है, पूरे पते की व्यावहारिक सीमा 254 अक्षर है, इसलिए बनाए गए नामों को उससे काफ़ी भीतर रहना चाहिए।
चरण 5: मेल प्रोटोकॉल से वेब रिक्वेस्ट तक
हमारा संदेश अब एक ऐसी मशीन ने स्वीकार कर लिया है जो SMTP बोलती है। इनबॉक्स दिखाने वाली वेबसाइट एक वेब एप्लिकेशन है। दोनों को जोड़ने के लिए कुछ चाहिए।
पूरे इंटरनेट के सामने खड़ा मेल सर्वर चलाना असल मेहनत है: TLS, कनेक्शनों की बाढ़, क्यू, मैलवेयर, और अच्छी साख बनाए रखना। इसलिए कई आधुनिक एप्लिकेशन SMTP का हिस्सा किसी विशेष इनबाउंड प्रोवाइडर को दे देती हैं और संदेश वेब रिक्वेस्ट के रूप में पाती हैं, जिस पैटर्न को अक्सर इनबाउंड पार्स वेबहुक कहा जाता है। VookMail यही मॉडल इस्तेमाल करता है। यह ऐसे काम करता है:
- प्रोवाइडर के MX होस्ट भेजने वाले के सर्वर से संदेश लेते हैं, ऊपर के सत्र की तरह।
- प्रोवाइडर उसे पैकेज करता है, या तो कच्चे MIME स्रोत के रूप में या पहले से पार्स किए फ़ील्ड के रूप में, जैसे भेजने वाला, पाने वाले, सब्जेक्ट, टेक्स्ट, HTML और अटैचमेंट।
- वह उस पैकेज को टेंप मेल एप्लिकेशन के चलाए एंडपॉइंट पर HTTPS POST में भेजता है, जो उन दो बिंदुओं के बीच सामग्री को एन्क्रिप्ट करता है।
- एप्लिकेशन सफलता का स्टेटस लौटाती है। अगर वह पहुंच से बाहर हो या एरर दे, तो अच्छा प्रोवाइडर अपनी नीति के हिसाब से दोबारा कोशिश करता है।
- एप्लिकेशन रिक्वेस्ट की जांच करती है, पाने वाले को किसी पते से मिलाती है और संदेश को अस्थायी रूप से स्टोर करती है।
| चिंता | खुद होस्ट किया SMTP रिसीवर | इनबाउंड प्रोवाइडर और HTTPS |
|---|---|---|
| एक्सपोज़र | पोर्ट 25 इंटरनेट के हर होस्ट के लिए खुला | SMTP ट्रैफ़िक प्रोवाइडर लेता है, और ऐप को सिर्फ़ HTTPS रिक्वेस्ट दिखती हैं |
| ट्रैफ़िक में उछाल | ऑपरेटर को क्षमता खुद जुटानी पड़ती है | प्रोवाइडर का ढांचा उछाल संभालता है |
| MIME पार्सिंग | ऑपरेटर को पार्सर लिखना या संभालना पड़ता है | अक्सर प्रोवाइडर करता है, हालांकि कच्चा स्रोत फिर भी इस्तेमाल हो सकता है |
| वेब ऐप से मेल | मेल स्पूल से ऐप तक पुल चाहिए | संदेश किसी भी API रिक्वेस्ट की तरह आता है |
| निर्भरता | बाहरी पक्ष कम | प्रोवाइडर की उपलब्धता और कॉन्फ़िगरेशन पर टिका |
आखिरी पंक्ति एक असली कीमत है। अगर किसी इनबाउंड प्रोवाइडर में आउटेज या कॉन्फ़िगरेशन की समस्या हो, तो उसके पीछे के हर डोमेन की डिलीवरी तब तक रुक सकती है जब तक वह ठीक न हो, भले टेंप मेल वेबसाइट खुद सामान्य चल रही हो। उस दौरान अस्थायी एरर से ठुकराए गए संदेश अब भी पहुंच सकते हैं जब असली भेजने वाले दोबारा कोशिश करें, यह इस पर निर्भर है कि उनकी क्यू उन्हें कितनी देर रखती है।
एंडपॉइंट की हिफ़ाज़त
वेबहुक एंडपॉइंट सार्वजनिक URL है, इसलिए कोई भी उस पर नकली संदेश भेजने की कोशिश कर सकता है। सावधान इम्प्लीमेंटेशन आम तौर पर कई बचाव जोड़ते हैं:
- सिग्नेचर वेरिफ़िकेशन, जिसमें प्रोवाइडर हर रिक्वेस्ट पर दस्तखत करता है और एप्लिकेशन मेल न खाने वाली रिक्वेस्ट ठुकरा देती है।
- गुप्त पाथ या टोकन जो सिर्फ़ प्रोवाइडर और एप्लिकेशन को पता हो।
- रिक्वेस्ट को प्रोवाइडर की प्रकाशित एड्रेस रेंज तक सीमित करना, जहां ऐसी रेंज हों।
- साइज़ की सीमाएं, जो मेमोरी और स्टोरेज की रक्षा के लिए बहुत बड़े पेलोड को जल्दी ठुकराती हैं।
- आइडेम्पोटेंसी। प्रोवाइडर दोबारा कोशिश करते हैं, इसलिए वही संदेश दो बार आ सकता है, और Message-ID या प्रोवाइडर का इवेंट ID डुप्लिकेट रोकता है।
चरण 6: संदेश को खोलना
जो आता है वह अभी ऐसी चीज़ नहीं जिसे इंसान आराम से पढ़ सके। MIME (Multipurpose Internet Mail Extensions, RFC 2045 से आगे) एक ही संदेश को अलग-अलग फ़ॉर्मेट के कई हिस्से ले जाने देता है। हमारा कन्फ़र्मेशन ईमेल कुछ ऐसे सजा हो सकता है, उदाहरण के लिए एक इनवॉइस जोड़ दिया गया है:
| हिस्सा | इसमें क्या होता है |
|---|---|
multipart/mixed | अटैचमेंट होने पर बाहरी कंटेनर |
multipart/alternative | वही सामग्री दो बार, text/plain और text/html के रूप में। रीडर वह सबसे समृद्ध रूप दिखाता है जिसे वह सपोर्ट करता है |
multipart/related | HTML के साथ इनलाइन इमेज का समूह, जिन्हें cid: पहचानकर्ताओं से जोड़ा जाता है |
| अटैचमेंट वाला हिस्सा | Content-Disposition: attachment हेडर और फ़ाइलनाम, फिर फ़ाइल का एन्कोड किया डेटा |
इन सबके ऊपर हेडर होते हैं, जिनमें Message-ID, Date और Received ट्रेस पंक्तियां शामिल हैं, जो हर उस सर्वर को दर्ज करती हैं जिससे संदेश गुज़रा। अगर कभी जानना हो कि देरी कहां हुई, तो Received पंक्तियों के टाइमस्टैम्प देखने की जगह हैं।
पार्सर को कई एन्कोडिंग भी उलटनी पड़ती हैं। Base64 बाइनरी अटैचमेंट ले जाता है और उन्हें करीब एक तिहाई फुला देता है, इसलिए 10 MB की फ़ाइल लगभग 13 से 14 MB का संदेश बन जाती है। Quoted-printable ज़्यादातर ASCII टेक्स्ट को संभालता है और खास वर्ण =XX के रूप में लिखता है। charset= वैल्यू बताती है कि टेक्स्ट कैसे एन्कोड है, आम तौर पर UTF-8, जो कई भाषाओं में इस्तेमाल होने वाली सेवा के लिए बहुत मायने रखता है। और गैर-ASCII वर्णों वाली सब्जेक्ट लाइनें RFC 2047 की =?UTF-8?B?...?= या =?UTF-8?Q?...?= लिखावट इस्तेमाल करती हैं।
HTML को दिखाने लायक सुरक्षित बनाना
ईमेल का HTML अजनबी लिखते हैं, इसलिए व्यूअर को उसे वेबसाइट के संदर्भ में कोड चलाने नहीं देना चाहिए। सावधान इम्प्लीमेंटेशन आम तौर पर स्क्रिप्ट, इवेंट हैंडलर एट्रिब्यूट और खतरनाक URL स्कीम हटा देते हैं, और संदेश को अलग फ़्रेम में दिखाते हैं ताकि उसके स्टाइल और सामग्री आसपास के पेज को प्रभावित न कर सकें।
रिमोट इमेज पर भी सोचना पड़ता है। एक को लोड करना उसके भेजने वाले को बताता है कि संदेश खोला गया, और ट्रैकिंग पिक्सल ऐसे ही काम करते हैं। VookMail छिपे हुए ट्रैकिंग पिक्सल हटा देता है और इमेज तब तक बंद रखता है जब तक आप इजाज़त न दें।
पार्स किए गए टेक्स्ट से व्यूअर कुछ काम का भी कर सकता है। हमारे कन्फ़र्मेशन संदेश के लिए VookMail वेरिफ़िकेशन कोड या कन्फ़र्मेशन लिंक संदेश के ऊपर दिखाता है, ताकि किसी को लंबे टेम्पलेट में स्क्रॉल करके उसे ढूंढना न पड़े।
अटैचमेंट
अटैचमेंट डिकोड करके अस्थायी रूप से स्टोर किए जाते हैं ताकि उन्हें डाउनलोड किया जा सके। VookMail पर .exe, .bat और .apk जैसी आम प्रोग्राम फ़ाइलें नहीं ली जातीं, .zip जैसे आर्काइव पर चेतावनी दिखती है, और अधिकतम साइज़ लागू होते हैं। अटैचमेंट संदेशों के साथ ही डिलीट हो जाते हैं। याद रखिए कि फ़ाइल की सुरक्षा का इससे कोई लेना-देना नहीं कि वह कहां स्टोर थी: मैक्रो वाला दस्तावेज़ अस्थायी इनबॉक्स से डाउनलोड करने पर भी उतना ही खतरनाक है।
चरण 7: स्क्रीन तक पहुंचना
हमारा संदेश अब स्टोर हो चुका है, पर quietfox42@veylax.com दिखाता ब्राउज़र अभी यह नहीं जानता। वेब एप्लिकेशन के पास पता लगाने के कई तरीके हैं:
| तकनीक | कैसे काम करती है | समझौते |
|---|---|---|
| शॉर्ट पोलिंग | पेज हर कुछ सेकंड में सर्वर से पूछता है | सरल और भरोसेमंद, पर बार-बार रिक्वेस्ट करती है |
| लॉन्ग पोलिंग | रिक्वेस्ट तब तक खुली रहती है जब तक कोई खबर या टाइमआउट न आए | खाली जवाब कम, खुले कनेक्शन ज़्यादा |
| Server-Sent Events | सर्वर से ब्राउज़र तक एक लंबी चलने वाली स्ट्रीम | एक दिशा में कुशल, अपने आप दोबारा जुड़ती है |
| WebSockets | स्थायी दोतरफ़ा कनेक्शन | पूरी तरह इंटरैक्टिव, पर अलग ढांचा चाहिए |
VookMail का इनबॉक्स हर कुछ सेकंड में मेल देखता है, और रिफ्रेश बटन हाथ से देखता है, जैसे तब जब आपका डिवाइस सो गया हो या नेटवर्क टूट गया हो। वे कुछ सेकंड आम तौर पर सफ़र का सबसे छोटा हिस्सा होते हैं। अगर मेल धीमा लगे, तो समय लगभग हमेशा पहले कहीं गया होता है, भेजने वाले की क्यू में या किसी दोबारा कोशिश में।
पता बनाना बॉट सुरक्षा के एक छोटे हिस्से से भी गुज़रता है: विज़िटर के ब्राउज़र में एक छोटी गणना, जिसे प्रूफ़ ऑफ़ वर्क कहते हैं। आम विज़िटर को इसकी लगभग कोई कीमत नहीं चुकानी पड़ती, और यह थोक में पते बनाना महंगा कर देता है।
पता कहीं और भी खोला जा सकता है। चूंकि पता खुद इनबॉक्स की पहचान है, इसे दूसरे डिवाइस पर ले जाने के लिए बस पता आगे देना काफ़ी है। VookMail का QR बटन उसे ऐसे कोड की तरह दिखाता है जिसे फ़ोन स्कैन कर सकता है, ताकि वही इनबॉक्स वहां खुल जाए, और Android और Huawei ऐप मेल उसी तरह दिखाते हैं। यह सुविधाजनक है, और यही दिखाता है कि ये इनबॉक्स कम प्राइवेसी वाले क्यों हैं: जो भी किसी पते को जानता या अंदाज़े से पा लेता है वह उस इनबॉक्स को खोल सकता है। रैंडम पता सुरक्षित चुनाव है, क्योंकि उसका अंदाज़ा छोटे नाम से कहीं कठिन है।
चरण 8: डिलीशन
हमारे कन्फ़र्मेशन के आने के लगभग एक दिन बाद वह चला जाता है। टेंप मेल सिस्टम में रिटेंशन आम तौर पर हर स्टोर किए संदेश पर टाइमस्टैम्प और एक तय समय पर चलने वाले जॉब से लागू होता है जो सीमा से पुराना सब कुछ हटा देता है। अलग फ़ाइलों के रूप में रखे अटैचमेंट उसी समय जाते हैं। दूसरे डिज़ाइन स्टोरेज-स्तर की एक्सपायरी इस्तेमाल करते हैं, जिसमें डेटाबेस खुद टाइम-टू-लिव सेटिंग से पुराने रिकॉर्ड हटा देता है। बैच जॉब एक वजह हैं कि सेवाएं एक्सपायरी को "लगभग" एक दिन बताती हैं, क्योंकि ठीक पल इस पर निर्भर है कि जॉब कब चलता है। VookMail पर संदेश, अटैचमेंट और पते लगभग 24 घंटे के भीतर डिलीट हो जाते हैं, और हटाएं बटन आपको चीज़ें पहले हटाने देता है।
छोटा रिटेंशन एक साथ दो काम करता है। यह प्राइवेसी की रक्षा करता है, और यह क्षमता की भी ज़रूरत है: डिस्पोज़ेबल इनबॉक्स में बहुत सारा मार्केटिंग मेल आता है, और उसे ज़्यादा देर रखना किसी के काम का नहीं। हमारी प्राइवेसी पॉलिसी और मेथडोलॉजी पेज डेटा संभालने के बारे में और बताते हैं।
ध्यान दीजिए कि डिलीशन किस चीज़ को नहीं छूता। Bright Parcel के पास पता अब भी उसकी कस्टमर टेबल में है, और उसके लॉग अब भी दिखाते हैं कि वह "delivered" हुआ था। जो गया है वह सिर्फ़ इनबॉक्स की तरफ़ की कॉपी है।
पूरा रास्ता एक तालिका में
| चरण | घटक | प्रोटोकॉल या तंत्र | आम पोर्ट या फ़ॉर्मेट |
|---|---|---|---|
| रचना | ऐप या मेल क्लाइंट | RFC 5322 संदेश, MIME | हेडर और हिस्सों वाला टेक्स्ट |
| सबमिशन | भेजने वाले की मेल सर्विस | SMTP सबमिशन या भेजने की API | 587 या 465 |
| रूटिंग लुकअप | DNS रिज़ॉल्वर | MX, फिर A या AAAA क्वेरी | DNS, पोर्ट 53 |
| रिले | भेजने वाले का सर्वर पाने वाले के MX तक | अवसरवादी STARTTLS के साथ SMTP | 25 |
| इनबाउंड रिसेप्शन | मेल डिलीवरी प्रोवाइडर | डोमेनों के लिए कैच-ऑल स्वीकृति | जवाब 250, 4xx, 5xx |
| फ़ॉरवर्डिंग | प्रोवाइडर से VookMail तक | HTTPS रिक्वेस्ट | 443 |
| प्रोसेसिंग | टेंप मेल एप्लिकेशन | MIME पार्सिंग, सैनिटाइज़िंग, स्टोरेज | डेटाबेस और फ़ाइल स्टोरेज |
| डिस्प्ले | ब्राउज़र या मोबाइल ऐप | हर कुछ सेकंड में जांच, साथ में हाथ से रिफ्रेश | HTTPS |
| एक्सपायरी | तय समय पर सफ़ाई | रिटेंशन नियम | VookMail पर लगभग एक दिन |
SPF, DKIM और DMARC कहां आते हैं
ये तीनों ईमेल की लगभग हर चर्चा में आते हैं, इसलिए ठीक-ठीक समझना मददगार है कि इस रास्ते पर ये कहां बैठते हैं। तीनों इस बारे में हैं कि संदेश किसने भेजा यह कैसे साबित हो। इनमें से कोई भी तय नहीं करता कि अस्थायी पता उसे पा सकता है या नहीं।
SPF (RFC 7208) DNS का TXT रिकॉर्ड है जो उन सर्वरों की सूची देता है जिन्हें एनवेलप भेजने वाले में किसी डोमेन का इस्तेमाल करके भेजने की इजाज़त है, और पाने वाले जुड़ने वाले IP को उससे मिलाते हैं। DKIM (RFC 6376) क्रिप्टोग्राफ़िक सिग्नेचर है जो भेजने वाला डोमेन चुने हुए हेडर और बॉडी पर जोड़ता है, और DNS में रखी पब्लिक की से जांचा जाता है। DMARC (RFC 7489) एक नीति है जो पाने वालों को बताती है कि जब संदेश दिखने वाले From डोमेन के साथ SPF और DKIM अलाइनमेंट में फ़ेल हो तो क्या करना है, और रिपोर्ट कहां भेजनी हैं।
हमारे संदेश के लिए ये जांचें चरण 3 के आसपास होती हैं। Bright Parcel के सर्वर को उसके SPF रिकॉर्ड से जांचा गया, और उसका DKIM सिग्नेचर उसकी प्रकाशित की से जांचा जा सकता है। पाने वाला प्रोवाइडर उन नतीजों से स्पूफ़िंग पर निशान लगा सकता है। फ़ॉरवर्डिंग चीज़ें थोड़ी उलझा देती है: DKIM सिग्नेचर तब तक बचा रहता है जब तक संदेश बदला न जाए, जबकि SPF नतीजा सिर्फ़ आखिरी जुड़ने वाले सर्वर से जुड़ा होता है। जब मेल रिले हो, तो ARC (Authenticated Received Chain, RFC 8617) पहले के नतीजे दर्ज कर सकता है। लेकिन आखिर में संदेश को डिलीवर MX रिकॉर्ड और पाने वाले की स्वीकृति ही करती है।
जब संदेश कभी न पहुंचे
ऊपर का हर चरण एक जगह है जहां संदेश रुक सकता है। भेजने वाले के सिरे से शुरू करके चलना आम तौर पर समस्या सबसे जल्दी ढूंढ देता है।
| चरण | क्या गलत हुआ | आप क्या देखते या करते हैं |
|---|---|---|
| भेजने से पहले | पते में टाइपो | मेल कहीं और गया या बाउंस हुआ। कॉपी बटन इस्तेमाल कीजिए |
| भेजने वाले से निकलना | संदेश क्यू में है, या बैच धीमे हैं | कुछ सेवाओं में एक-दो मिनट सामान्य है। इंतज़ार कीजिए |
| भेजने वाले से निकलना | साइट चुपचाप डिस्पोज़ेबल डोमेन छोड़ देती है | कुछ नहीं आता। इसका सम्मान कीजिए और वहां स्थायी पता या एलियास इस्तेमाल कीजिए |
| SMTP | 4xx जवाब और बाद में दोबारा कोशिश | संदेश देर से आता है, जो कुछ मिनट या उससे ज़्यादा हो सकती है |
| SMTP | संदेश साइज़ सीमा से बड़ा है | 552 से ठुकराया जाना और भेजने वाले को बाउंस |
| इनबाउंड प्रोवाइडर | आउटेज या DNS समस्या | समस्या सुलझने तक सभी डोमेनों की डिलीवरी रुक सकती है |
| इनबॉक्स | समय की खिड़की निकल गई, या पता डिलीट हो गया | संदेश इतनी देर से आता है कि देखा नहीं जा सकता |
जब भेजने वाला सिरा आपका हो, तब विफलता पढ़ना
अगर आप अपनी एप्लिकेशन टेस्ट कर रहे हैं, तो आप किसी यूज़र से कहीं ज़्यादा देख सकते हैं, और हमारी गाइड डेवलपर्स के लिए अस्थायी ईमेल टेस्ट डिज़ाइन पर और आगे जाती है। जांच का एक समझदार क्रम:
- अपनी एप्लिकेशन के मेल लॉग या भेजने वाले प्रोवाइडर का डैशबोर्ड खोलिए। क्या संदेश स्वीकार हुआ, और उसका अंतिम स्टेटस क्या दिखता है?
- बाउंस या वेबहुक इवेंट देखिए जो पाने वाले की तरफ़ से 5xx बताते हैं। कोड के बाद का टेक्स्ट अक्सर वजह बता देता है।
- ऊपर की कमांड से अपने सर्वर के नेटवर्क से पाने वाले डोमेन के MX रिकॉर्ड रिज़ॉल्व कीजिए। वहां रिज़ॉल्वर की समस्या कहीं और नहीं दिखेगी।
- पक्का कीजिए कि आपके भेजने वाले डोमेन पर SPF, DKIM और DMARC कॉन्फ़िगर हैं, क्योंकि कुछ पाने वाले बिना प्रमाणीकरण के मेल को शक की नज़र से देखते हैं।
- साइज़ या सामग्री की फ़िल्टरिंग को बाहर करने के लिए एक छोटा प्लेन-टेक्स्ट संदेश भेजिए।
- हर टेस्ट के लिए अलग यूज़रनेम इस्तेमाल कीजिए ताकि पता रहे कि कौन-सा संदेश किस रन से आया।
अगर कोई संदेश इनबॉक्स में देर से पहुंचे, तो उसके Received हेडर नीचे से ऊपर पढ़िए। दो टाइमस्टैम्प के बीच बड़ा फ़ासला दिखाता है कि किस पड़ाव ने उसे रोका, उन सर्वरों की घड़ियों के किसी भी अंतर का ध्यान रखते हुए।
कई डोमेन क्यों चलाए जाते हैं?
VookMail आपको 30 से ज़्यादा डोमेनों में से चुनने देता है। इसकी व्यावहारिक वजहें हैं। टेस्टर डोमेन के हिसाब से प्रोजेक्ट या टेस्ट सूट अलग कर सकते हैं। अगर एक डोमेन में DNS या डिलीवरी की समस्या हो, तो बाकी चलते रह सकते हैं। और एक नाम पर निर्भरता कम होती है, जो तब काम आती है जब भेजने वाले सिस्टम भेजने वालों के साथ पाने वाले डोमेनों को भी परखते हैं।
कई डोमेन उन वेबसाइटों से बचने का औज़ार नहीं हैं जो जान-बूझकर डिस्पोज़ेबल पते ठुकराती हैं। अगर कोई सेवा टेंप मेल डोमेन ठुकराती है, तो वह संकेत दे रही है कि उसे स्थायी संपर्क चाहिए, और सही चुनाव उस सेवा के लिए आपका असली पता या स्थायी एलियास है। यह इनकार फ़ॉर्म पर हो सकता है, चरण 2 जैसी डोमेन सूची या MX लुकअप से, या बाद में, जब भेजने वाला भेजने से मना कर दे।
यह रास्ता सुरक्षा के बारे में क्या बताता है
संदेश का पीछा करने के बाद आप ठीक-ठीक देख सकते हैं कि हर सुरक्षा कितनी दूर तक पहुंचती है।
एन्क्रिप्शन पड़ाव-दर-पड़ाव लगता है। STARTTLS हर सर्वर-से-सर्वर पड़ाव की रक्षा करता है जब दोनों सिरे उसे सपोर्ट करें, और वह अक्सर अवसरवादी होता है, इसलिए कनेक्शन प्लेन टेक्स्ट पर लौट सकता है जब तक MTA-STS (RFC 8461) जैसी नीति कुछ और ज़रूरी न करे। HTTPS फ़ॉरवर्डिंग और देखने वाले पड़ावों की रक्षा करता है। इनमें से कुछ भी एंड-टू-एंड एन्क्रिप्शन नहीं है: संदेश संभालने वाला हर सिस्टम उसे पढ़ सकता है।
पहुंच दूसरा आधा हिस्सा है। पासवर्ड के बिना पते को जानना ही प्रवेश देता है, इसलिए वहां कोई गोपनीय चीज़ कभी न भेजने दें। छोटा रिटेंशन किसी भी एक्सपोज़र का नुकसान सीमित करता है, पर इसका मतलब यह भी है कि इनबॉक्स रिकॉर्ड का काम नहीं कर सकता। और चूंकि सामग्री पर भरोसा नहीं किया जा सकता, फ़िशिंग और मैलवेयर इस इनबॉक्स में भी वैसे ही आ सकते हैं जैसे किसी और में। अस्थायी इनबॉक्स आपके असली पते की रक्षा करता है, और अगर आप कोई बुरी फ़ाइल खोलें तो आपके डिवाइस के लिए बहुत कम करता है। उचित इस्तेमाल प्राइवेसी, स्पैम पर काबू और टेस्टिंग हैं, जैसा हमारी नियम और शर्तें बताती हैं, और ज़रूरी अकाउंट कहीं और रखने चाहिए।
VookMail पर यह कैसा दिखता है
ऊपर की सारी मशीनरी आपके आने से पहले ही तैयार है। जब आप VookMail खोलते हैं, तो एक पता तैयार मिलता है। आप नया दबाकर यूज़रनेम टाइप कर सकते हैं और डोमेन चुन सकते हैं, या वह पीला रैंडम बटन इस्तेमाल कर सकते हैं जिसका वर्णन हमारी गाइड VookMail कैसे इस्तेमाल करें में है। रजिस्टर करने को कुछ नहीं, क्योंकि डोमेन पहले से हर नाम स्वीकार करता है। जब कोई भेजने वाला मेल डिलीवर करता है, तो MX रिकॉर्ड के पीछे का प्रोवाइडर उसे SMTP से लेता है और HTTPS से फ़ॉरवर्ड कर देता है, और पेज अगली बार जांचे तो वह अटैचमेंट के साथ आपके इनबॉक्स में दिख जाता है। लगभग एक दिन बाद वह चला जाता है।
यह सेवा Google Play और Huawei AppGallery पर ऐप के रूप में भी उपलब्ध है।
कुछ और तकनीकी सवाल
इनबाउंड ईमेल कौन-सा पोर्ट इस्तेमाल करता है?
मेल सर्वरों के बीच डिलीवरी TCP पोर्ट 25 पर SMTP से होती है। पोर्ट 587 और 465 जाने वाले मेल को अपने प्रोवाइडर तक पहुंचाने के लिए हैं, इसलिए वे चरण 3 में नहीं, चरण 1 में आते हैं। इसीलिए पोर्ट 25 रोकने वाला घरेलू कनेक्शन भी आम तौर पर अपने प्रोवाइडर के ज़रिए भेज सकता है।
क्या टेंप मेल सेवा मेरे संदेश देख सकती है?
तकनीकी रूप से, हां। संदेश सेवा तक पढ़ने लायक रूप में पहुंचता है, क्योंकि तभी वह आपको दिखा सकती है, और रास्ते में उसे संभालने वाले डिलीवरी प्रोवाइडर के साथ भी यही है। आम होस्टेड ईमेल पर भी यह सच है, जब तक सामग्री एंड-टू-एंड एन्क्रिप्टेड न हो। यह संवेदनशील चीज़ों को अस्थायी इनबॉक्स से दूर रखने की एक और वजह है।
जब मुझे कुछ नहीं दिखता, तब भेजने वाला क्यों सोच सकता है कि संदेश डिलीवर हुआ?
क्योंकि भेजने वाले के डैशबोर्ड पर "delivered" पाने वाले सर्वर के 250 जवाब को कहता है। उस बिंदु के बाद की घटनाएं, जैसे फ़ॉरवर्डिंग का कदम या इनबॉक्स साफ़ होने के बाद देर से आना, भेजने वाले को नहीं दिखतीं।
क्या भेजने वाला जान सकता है कि मेरा पता कैच-ऑल है?
अक्सर। वेरिफ़िकेशन टूल डोमेन पर कोई गढ़ा हुआ यूज़रनेम आज़मा सकता है, और अगर सर्वर उसे स्वीकार कर ले, तो डोमेन शायद कैच-ऑल है। इतने से यह साबित नहीं होता कि डोमेन डिस्पोज़ेबल है, क्योंकि कई आम कंपनी डोमेन भी ऐसे ही कॉन्फ़िगर होते हैं, इसलिए ऐसे टूल आम तौर पर इसे दूसरे संकेतों के साथ मिलाते हैं।
क्या संदेश के जवाब काम करते हैं?
आपकी तरफ़ से जवाब डिज़ाइन का मकसद नहीं हैं, क्योंकि इनबॉक्स मुख्य रूप से पाता है। अगर आपको दोतरफ़ा आदान-प्रदान चाहिए, तो आम मेलबॉक्स या जवाब सपोर्ट करने वाली एलियास सर्विस बेहतर बैठती है।
प्रोडक्ट के बारे में और जानने के लिए हमारा FAQ देखिए। VookMail PAYATE के मुफ़्त टूल्स के नेटवर्क का हिस्सा है।