अस्थायी ईमेल जनरेटर कुछ समय के लिए चलने वाला मेलबॉक्स बनाता है, जिसका पता काम करता है, ताकि साइनअप फ़ॉर्म, पासवर्ड रीसेट का प्रवाह या वन-टाइम कोड भेजने की प्रक्रिया को नकली बनाने की जगह शुरू से अंत तक परखा जा सके। वह मेलबॉक्स असली मेल स्वीकार करता है, उसे कुछ देर रखता है, और फिर गायब हो जाता है। यही गुण उसे टेस्ट में उपयोगी बनाता है और किसी स्थायी संपर्क के रूप में बेकार।
यह गाइड उन तीन चीज़ों को अलग करती है जिन्हें लोग अस्थायी ईमेल कहकर मिला देते हैं, बताती है कि डिस्पोज़ेबल इनबॉक्स वह क्या हल करता है जो कोई स्टब नहीं कर सकता, इतनी सारी सेवाएं इन डोमेन को क्यों ठुकराती हैं, और कब आपको इसकी ओर मुड़ना ही नहीं चाहिए। अंत तक आप बिना अंदाज़े के तय कर पाएंगे कि सार्वजनिक डिस्पोज़ेबल डोमेन, फ़ॉरवर्डिंग अलियास और अपने ही डोमेन के कैच-ऑल मेलबॉक्स में से कौन सा चुनना है, और इस साइट का अस्थायी ईमेल टूल उसी फ़ैसले का व्यावहारिक साथी है।
डिस्पोज़ेबल मेलबॉक्स क्या होता है?
डिस्पोज़ेबल मेलबॉक्स वह मेलबॉक्स होता है जो थोड़े समय के लिए मौजूद रहता है और बिना किसी साइनअप के बनाया जा सकता है। उसका एक पता होता है, वह मेल ले सकता है, और उसकी एक समय सीमा होती है। बाकी सब कुछ प्रदाता के हिसाब से बदलता है: मेल कितने समय तक रखा जाता है, पता अनुमान लगाकर ढूंढा जा सकता है या नहीं, इनबॉक्स सार्वजनिक है या नहीं, और अटैचमेंट सहेजे जाते हैं या नहीं।
पता आमतौर पर किसी साझा डोमेन पर होता है। यही सबसे ज़रूरी संरचनात्मक तथ्य है, क्योंकि इसका मतलब है कि उस डोमेन का इस्तेमाल हज़ारों बेजुड़ लोग एक ही समय में करते हैं, और उस डोमेन की साख उन सबके बीच बंटी होती है। जब उस डोमेन का एक उपयोगकर्ता उसका दुरुपयोग करता है, तो बाकी सब उसका नतीजा कहीं ब्लॉकलिस्ट में दर्ज होने के रूप में भुगतते हैं। मेलबॉक्स खुद यह नहीं बताता कि इस हफ़्ते डोमेन पर कौन-कौन अजनबी सक्रिय रहे, और आपके अपने टेस्ट के भीतर ऐसा कुछ भी नहीं जो उनसे मिली इस स्थिति को सुधार सके।
वह मेलबॉक्स फ़ॉरवर्डिंग अलियास नहीं है, और यही फ़र्क़ सबसे ज़्यादा धुंधला किया जाता है। अलियास उस डोमेन पर होता है जो आपके नियंत्रण में है और वह ऐसे इनबॉक्स पर भेजता है जो पहले से आपका है, यानी मूल मेलबॉक्स स्थायी होता है और अलियास केवल एक इशारा है। डिस्पोज़ेबल मेलबॉक्स खुद मेलबॉक्स है, और उसकी अवधि खत्म होने के बाद उसके पीछे कुछ नहीं बचता।
इसका एक और पहलू है जिसे नज़रअंदाज़ करना महंगा पड़ता है। अस्थायी पता एक ऐसा मान है जिसे आपके इनबॉक्स तक पहुंचने की अनुमति है या नहीं, इस पर किसी और का नियंत्रण नहीं है। इसलिए जब कोई टेस्ट उस पते पर मेल भेजता है, तो वह मेल किस सर्वर तक पहुंचता है और वहां कितनी देर रुकता है, यह भी आपके हाथ में नहीं होता।
अस्थायी मेलबॉक्स, अलियास और कैच-ऑल डोमेन में क्या फ़र्क़ है?
फ़ॉरवर्डिंग अलियास एक स्थिर पहचान है जिसकी उम्र जानबूझकर तय की जाती है। आप उसे एक बार बनाते हैं, किसी असली इनबॉक्स की ओर इंगित करते हैं, और हर उस जगह इस्तेमाल करते हैं जहां कोई सेवा ईमेल पता मांगती है। मेल आपके ही अकाउंट पर पहुंचता है, अलियास को बाद में बंद किया जा सकता है, और चूंकि डोमेन आपका है, उस अलियास की डिलीवरी आपकी अपनी साख है, किसी अजनबी की नहीं।
कैच-ऑल डोमेन उसी विचार का औद्योगिक रूप है। उस डोमेन का हर पता, केवल वे नहीं जो आपने बनाए, स्वीकार किया जाता है और एक मेलबॉक्स या एक प्रोसेसिंग स्क्रिप्ट की ओर भेज दिया जाता है। इससे हर टेस्ट रन के लिए बिना किसी तैयारी के नया पता बनाया जा सकता है, क्योंकि जिस क्षण पता गढ़ा गया, उसी क्षण वह वैध होता है। कैच-ऑल मेलबॉक्स के साथ आने वाले स्पैम जोखिम और संचालन की बारीकियों पर अलग से ध्यान देना ज़रूरी है, क्योंकि एक बार सार्वजनिक होने पर ऐसा डोमेन जल्दी ही स्कैनरों की सूची में आ जाता है।
सार्वजनिक डिस्पोज़ेबल मेलबॉक्स इसी सौदे के दूसरे सिरे पर बैठता है। उसकी कोई कीमत नहीं होती और किसी DNS रिकॉर्ड की ज़रूरत नहीं होती, और बदले में वह बाकी सबके साथ एक ही डोमेन बांटता है, ऐसी अवधि लेकर आता है जो आपने चुनी नहीं होती, और उसे वही सेवा ब्लॉक कर सकती है जिसकी आप परीक्षा कर रहे हैं। किसी जल्दी वाली हाथ की जांच के लिए वह सुविधाजनक है। रोज़ रात चलने वाली पाइपलाइन के लिए वह ऐसी रुक-रुक कर आने वाली विफलता का स्रोत है जिसका कारण ढूंढना मुश्किल होता है।
तीनों में से चुनाव इस बात पर निर्भर करता है कि आपको कितना नियंत्रण चाहिए और कितनी मेहनत करने को तैयार हैं। जिसे शून्य लागत चाहिए, वह साझा डोमेन का जोखिम भी स्वीकार करे। जिसे स्थिरता चाहिए, वह अपना डोमेन ले और कैच-ऑल चलाए।
सत्यापन परीक्षण में डिस्पोज़ेबल इनबॉक्स क्या हल करता है?
यह जो समस्या हल करता है, वह बहुत साफ़ है: ऐसा प्रवाह जो किसी पते पर लिंक या कोड भेजता है, और फिर इस बात का इंतज़ार करता है कि कोई उसका कुछ करे। नकली मेलर यह पक्का कर सकता है कि संदेश कतार में डाला गया। वह यह पक्का नहीं कर सकता कि संदेश में दिया लिंक चलता है, संदेश में दिया कोड स्वीकार होता है, या लिंक में दिया टोकन समय पर समाप्त होता है।
असली इनबॉक्स यही खाई भरता है। टेस्ट बनाए गए पते के साथ पंजीकरण करता है, संदेश आने का इंतज़ार करता है, उसमें से लिंक या कोड निकालता है, उस पर चलता है, और नतीजे पर दावा करता है। डिलीवरी के रास्ते को असल में कवर करने वाला यही एक रूप है, और इसी वजह से डिस्पोज़ेबल इनबॉक्स परीक्षण की ज़रूरी चीज़ों में गिने जाते हैं। इस क्रम का पूरा विस्तृत रूप ईमेल सत्यापन टूल से जुड़ी सामग्री में दिया गया है।
एक दूसरा, कम शोर वाला फ़ायदा भी है। असली इनबॉक्स संदेश को ठीक वैसा दिखाता है जैसा पाने वाला देखेगा, जिसमें रेंडरिंग, भेजने वाले का नाम, विषय पंक्ति और हिस्सों का क्रम शामिल है। वे टेम्पलेट दोष जो स्टब कभी नहीं दिखाता, जैसे कोई चर जो भर ही नहीं पाया, टूटा हुआ लिंक, या खाली पहुंचती विषय पंक्ति, तुरंत सामने आ जाते हैं जब कोई व्यक्ति या कोई पार्सर असली संदेश पढ़ता है।
तीसरा फ़ायदा यह है कि डिलीवरी के समय का व्यवहार भी दिख जाता है। असली इनबॉक्स पर आप देख सकते हैं कि संदेश कितनी देर में पहुंचा, किस सर्वर से आया, और क्या उसके हेडर उस अपेक्षा से मेल खाते हैं जो आपकी स्कीमा रखती है। नकली रास्ते में ये सारे संकेत या तो मौजूद ही नहीं होते या कृत्रिम होते हैं।
इतनी सारी सेवाएं डिस्पोज़ेबल डोमेन क्यों ब्लॉक करती हैं?
ब्लॉक करना ऐसी सूची से चलता है जो प्रकाशित की जाती है। विक्रेता अस्थायी मेल से जुड़े डोमेन की सूचियां बेचते या बांटते हैं, और कोई साइनअप फ़ॉर्म सबसे पहले भेजे गए पते को उस सूची से मिलाकर देखता है। यह जांच सस्ती है, इसमें उपयोगकर्ता का कोई सत्यापन नहीं चाहिए, और यह स्वचालित दुरुपयोग का बड़ा हिस्सा रोक देती है।
परीक्षण के लिए इसका नतीजा यह है कि वह ब्लॉकलिस्ट उस वातावरण का हिस्सा है जिसमें आपके टेस्ट चलते हैं, और वह आपके नियंत्रण में नहीं है। जो डोमेन आज काम करता है, वह कल किसी सूची में आ सकता है, और आपकी पाइपलाइन बिना आपकी ओर से किसी बदलाव के विफल होने लगेगी। स्वचालित सूट में रुक-रुक कर आने वाली सत्यापन विफलताओं का यही सबसे आम कारण है।
उससे भी बुरी बात यह है कि विफलता अक्सर कुछ नहीं बताती। फ़ॉर्म एक सामान्य त्रुटि लौटाता है, टेस्ट संदेश का इंतज़ार करते हुए समय समाप्त होने की शिकायत करता है, और असली कारण यह था कि कोई मेल भेजे जाने से पहले ही पंजीकरण ठुकरा दिया गया, यह कई परत पीछे छिपा रहता है। इसलिए जो सूट साझा सार्वजनिक डोमेन पर चलता है, वह ऐसा सूट है जिसका हमेशा के लिए बिना समझाया हुआ अस्थिरता बजट मौजूद रहता है। इलाज यह है कि जब भी डिलीवरी का इंतज़ार समय से बाहर चला जाए, भेजा गया पता और फ़ॉर्म का कच्चा उत्तर दर्ज कर लिया जाए, ताकि अगली बार विफलता देखने वाले व्यक्ति के पास पहचान करने के लिए दोनों तथ्य मौजूद हों।
कई प्रदाता डोमेन या पते के अग्रभाग के हिसाब से दर सीमा भी लगाते हैं, जिससे दूसरी तरह की रुक-रुक विफलता पैदा होती है। जो पाइपलाइन कुछ मिनटों में सैकड़ों मेलबॉक्स बनाती है, वह पा सकती है कि प्रदाता ने मना करना शुरू कर दिया है, और यहां भी लक्षण ठुकराए गए अनुरोध के रूप में नहीं, बल्कि गुम संदेश के रूप में दिखता है।
टेस्ट सूट को अपना मेल रास्ता कैसे बनाना चाहिए?
मेल के रास्ते को ऐसे डोमेन के आसपास गढ़ें जो आपके नियंत्रण में हो। किसी मेलबॉक्स या प्रोसेसिंग स्क्रिप्ट की ओर कैच-ऑल मोड़ें, और हर रन के लिए एक अनोखा टोकन डोमेन के साथ जोड़कर नया पता बनाएं। कुछ भी तैयार करने की ज़रूरत नहीं पड़ती, डिलीवरी की ज़िम्मेदारी आपकी अपनी होती है, और आपकी पाइपलाइन के पास या फ़ेल होने का फ़ैसला किसी तीसरे पक्ष की सूची नहीं करती।
संदेश को आंख से नहीं, कोड के ज़रिए पढ़ें। जो पार्सर संदेश के मुख्य भाग से पहला लिंक या पहला बहु-अंकीय कोड निकाल लेता है, वह दावे को निर्णायक बना देता है, और निर्णायक दावा ही टेस्ट और प्रदर्शन के बीच का फ़र्क़ है। जब टेम्पलेट बदल जाए तब भी टिकने वाले निष्कर्षण के नियम ईमेल पते के नियम वाली सामग्री के साथ पढ़ना काम का रहता है।
इकाई स्तर के टेस्ट के लिए डिलीवरी को पूरी तरह छोड़ दें। स्थानीय कैप्चर सर्वर संदेश भेजने के बजाय उसे लेता है, जिससे टेस्ट तेज़ रहता है और नेटवर्क उस चक्र से बाहर हो जाता है। ज़्यादातर सूट के लिए यही सही चूक है, और असली डिलीवरी उन गिने-चुने टेस्ट के लिए बचाकर रखनी चाहिए जिन्हें सचमुच उसकी ज़रूरत है।
पतों को पहचानने योग्य रखें। ऐसा अग्रभाग जो वातावरण और रन की पहचान कराए, और उसके बाद आपका अपना डोमेन, इस बात को संभव बनाता है कि मिले संदेश को उस टेस्ट तक वापस जोड़ा जा सके जिसने उसे पैदा किया, और जिनकी ज़रूरत नहीं रही उन्हें हटाया जा सके। अग्रभाग के बिना साझा कैच-ऑल इनबॉक्स संदेशों का ऐसा ढेर बन जाता है जिसे कोई किसी से जोड़ नहीं सकता, और जिस इनबॉक्स को कोई जोड़ न सके, उसे खाली करने की हिम्मत भी कोई नहीं करता।
एक और आदत जोड़ें: संदेश पढ़ने के बाद उसे तुरंत अलग रखें। जो टेस्ट संदेश मिलने के बाद उसे वहीं छोड़ देता है, वह अगली बार उसी इनबॉक्स में मौजूद पुराने संदेशों से भ्रमित हो सकता है। हर रन की शुरुआत में इनबॉक्स को खाली मानना और पहले आ चुके संदेशों को नज़रअंदाज़ करने का नियम रखना, इस भ्रम से बचाता है।
अस्थायी ईमेल का इस्तेमाल कब नहीं करना चाहिए?
कुछ मामले ऐसे हैं जहां डिस्पोज़ेबल इनबॉक्स ग़लत औज़ार है, और उन्हें नाम लेकर बताना ज़रूरी है क्योंकि उनमें फंसना आसान है। पहला मामला ऐसे किसी असली अकाउंट से जुड़ा है जो मायने रखता है। जिस सेवा पर आप असल में निर्भर हैं, उसका पंजीकरण ऐसे मेलबॉक्स से करना जो एक घंटे में समाप्त हो जाएगा, ऐसा अकाउंट बनाता है जिसे आप वापस नहीं पा सकते, और किसी भी सुविधा के लिए यह कीमत ठीक नहीं है।
दूसरा मामला वह प्रवाह है जिसमें प्रोडक्शन डेटा रखना पड़ता है। आपके संगठन से बाहर का मेलबॉक्स आपकी डेटा रखने की नीति से बाहर है और आपके ऑडिट रिकॉर्ड से भी बाहर, इसलिए असली ग्राहक की जानकारी वाला कोई भी संदेश उससे होकर कभी नहीं गुज़रना चाहिए। नियमों की नज़र में यह परीक्षण की छूट नहीं, बल्कि जानकारी का खुलासा है। अगर किसी टेस्ट को सचमुच प्रोडक्शन संदेश का आकार चाहिए, तो उस आकार को काल्पनिक मानों के साथ दोबारा बनाएं, असली संदेश को किसी बाहरी इनबॉक्स से न गुज़ारें।
तीसरा मामला वह है जो किसी सीमा को चकमा देने के लिए बनाया गया हो। डिस्पोज़ेबल पता किसी सेवा के बार-बार मुफ़्त आज़माइश पाने का तरीका नहीं है, और इस तरह इस्तेमाल करना उपयोग की शर्तों का उल्लंघन भी है और इस बात का भ्रामक संकेत भी कि उत्पाद आम उपयोगकर्ता के लिए कैसे व्यवहार करता है। ईमानदार तस्वीर यह है कि यह औज़ार आपके अपने सिस्टम की परीक्षा के लिए है, और केवल उसी के लिए।
चौथा मामला ज़्यादा बारीक है: ऐसा प्रवाह जिसे उपलब्ध अवधि से ज़्यादा देर तक जीवित रहना है। अगर कोई टेस्ट एक घंटे बाद मेलबॉक्स जांचता है और मेलबॉक्स दस मिनट तक ही चलता है, तो टेस्ट ऐसी वजह से विफल होगा जिसका परीक्षण किए जा रहे सॉफ़्टवेयर से कोई लेना-देना नहीं है। प्रतीक्षा को सूट में शामिल करने से पहले अवधि जांच लें, और अगर प्रदाता कोई अवधि नहीं बताता, तो उसी को उत्तर मान लें।
पांचवां मामला यह है कि कोई प्रवाह आपके अपने वातावरण पर निर्भर हो। अगर कोई टेस्ट आपके ही स्टेजिंग मेल सर्वर पर चलना चाहिए, तो बाहरी डिस्पोज़ेबल पता उसमें फ़िट ही नहीं होता, क्योंकि वह नेटवर्क से बाहर ले जाता है और आपकी पाइपलाइन को ऐसी सेवा पर निर्भर कर देता है जिसकी उपलब्धता आप तय नहीं करते।
संदेशों के बारे में क्या ध्यान रखें?
टेस्ट मेलबॉक्स को मिला संदेश आमतौर पर काल्पनिक होता है, पर वह फिर भी असली ईमेल है जिसे किसी असली सिस्टम ने बनाया है, और उसमें असली मान भी हो सकते हैं। जो प्रतिस्थापन शब्द भर ही नहीं पाए, ट्रैकिंग लिंक के भीतर मौजूद भीतरी होस्टनाम, और डिबग हेडर, ये सब आम तौर पर मिलते हैं, और इन सबकी शिकायत दर्ज कराना चाहिए, नज़रअंदाज़ नहीं करना।
इनबॉक्स को थोड़ी देर का नतीजा मानें और रन पूरा होने पर उसका सारा सामान हटा दें। जो स्टेजिंग मेलबॉक्स हज़ारों बिना पढ़े संदेश जमा कर लेता है, वह ऐसा लॉग है जिसकी कोई रखने की नीति नहीं, और बिना नीति वाला लॉग आख़िरकार वह चीज़ अपने भीतर रख लेता है जो उसे नहीं रखनी चाहिए।
टेस्ट जो संदेश बनाता है, वे एक सस्ती सुरक्षा जांच भी देते हैं। अगर किसी एक पते के लिए बनाया गया पासवर्ड रीसेट लिंक किसी दूसरे पते के लिए भी काम कर जाए, या सत्यापन टोकन की अवधि खत्म ही न हो, तो मेलबॉक्स पर चलने वाला टेस्ट इसे ऐसे पकड़ लेगा जैसे कोई इकाई स्तर का टेस्ट नहीं पकड़ सकता। इसी तरह, अगर एक ही कोड अलग-अलग अकाउंट पर स्वीकार हो जाए, तो वह संदेश नकली नहीं, आपके सिस्टम की खामी है।
संदेशों के आकार और संख्या पर भी नज़र रखें। जो रन सौ संदेश पैदा करता है जबकि उसे तीन की उम्मीद थी, वह ऐसी खामी की ओर इशारा है जिसे दिखावटी सफलता से ढक दिया गया। संख्या की ऊपरी सीमा तय करना और उससे ऊपर जाने पर टेस्ट को असफल मानना, इस तरह की गुमनाम वृद्धि को जल्दी पकड़ता है।
यहां चर्चा किया गया हर मेलबॉक्स, पता और संदेश सॉफ़्टवेयर परीक्षण का हिस्सा है। बनाए गए पते काल्पनिक रिकॉर्ड हैं जो आपके अपने प्रवाहों की परीक्षा के लिए बने हैं, और इनका उपयोग किसी की पहचान बनाने, किसी और के अकाउंट तक पहुंचने, दर सीमा या सत्यापन नियंत्रणों को दरकिनार करने, या ऐसा मेल पाने के लिए नहीं किया जाना चाहिए जो किसी के लिए मायने रखता हो।