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