डेवलपर और QA के लिए टेस्ट ईमेल पते: स्टेजिंग जो ट्रांज़ैक्शनल मेल में छिपा लेती है, उसे कैसे पकड़ें

मान लीजिए आपकी टीम नया पासवर्ड रीसेट ईमेल रिलीज़ करती है। QA स्टेजिंग पर साइन-ऑफ़ कर देती है: मैसेज आता है, लिंक चलता है, टेंपलेट सही दिखता है। रिलीज़ के दो दिन बाद सपोर्ट के पास टिकटों की कतार लग जाती है। Gmail पते वाले लोग कहते हैं कि ईमेल कभी आया ही नहीं। कुछ बड़ी कंपनियों के लोग कहते हैं कि आया, पर पहली बार क्लिक करने पर लिंक “पहले ही इस्तेमाल हो चुका” था। स्टेजिंग और प्रोडक्शन के बीच कोड किसी ने नहीं बदला, और हर टेस्ट अब भी पास हो रहा है।

तो इसे कौन-सा डेवलपर्स का टेस्ट ईमेल एड्रेस पकड़ पाता? कोई एक नहीं। रोज़ के डेवलपमेंट के लिए लोकल SMTP कैचर ठीक है, ऑटोमेटेड टेस्ट के लिए आपके प्रोवाइडर का सैंडबॉक्स या आपका अपना टेस्ट डोमेन, और यह जांचने के लिए कि प्रोडक्शन जैसे सेटअप से निकला मेल किसी अजनबी के डोमेन तक पहुंचता है, असली बाहरी इनबॉक्स। VookMail जैसा अस्थायी इनबॉक्स उस आखिरी ज़रूरत को बिना किसी सेटअप के पूरा करता है, क्योंकि पेज लोड होते ही पता तैयार मिलता है। फिर बड़े मेलबॉक्स प्रोवाइडर पर सीड अकाउंट वह हिस्सा संभालते हैं जो इनमें से कोई नहीं देख सकता। इस गाइड का बाकी हिस्सा इन विकल्पों में से चुनने, गड़बड़ी होने पर उसे पढ़ने, और रिलीज़ में शामिल होने वाली जांचों के बारे में है।

वह रीसेट स्टेजिंग पर पास क्यों हुआ

स्टेजिंग और प्रोडक्शन उतने कम अलग नहीं होते जितना डिप्लॉयमेंट डायग्राम बताता है, और ईमेल इन फ़र्कों को ज़्यादातर फ़ीचर से ज़्यादा उजागर करता है। एक मैसेज आपके ऐप, कतार, प्रोवाइडर, DNS, पाने वाले के सर्वर और पाने वाले के क्लाइंट से गुज़रता है। स्टेजिंग में इनमें से लगभग सबका वर्ज़न अलग हो सकता है।

पहला टिकट लीजिए, यानी वे Gmail यूज़र जिन्हें कुछ नहीं मिला। मान लें स्टेजिंग किसी प्रोवाइडर सबडोमेन से भेजती है जो महीनों पहले ऑथेंटिकेट हुआ था, जबकि प्रोडक्शन रीब्रांड के साथ आए नए From डोमेन से भेजता है। Google के सेंडर दिशानिर्देश सभी भेजने वालों से SPF या DKIM से ऑथेंटिकेशन मांगते हैं, और Gmail की एरर तालिका बिना ऑथेंटिकेशन वाले मेल के लिए 5.7.26 बताती है। आपके अपने डोमेन का आंतरिक QA मेलबॉक्स वही मैसेज बिना रुकावट ले सकता है, क्योंकि आपका सर्वर आपके अपने रिले पर भरोसा कर सकता है। यह टेस्ट कभी फ़ेल हो ही नहीं सकता था।

दूसरे टिकट का, यानी “पहले ही इस्तेमाल हुआ” लिंक का, कारण अलग है। कॉर्पोरेट सिक्योरिटी गेटवे अक्सर आने वाले मेल के लिंक को व्यक्ति के देखने से पहले स्कैन करने के लिए खोल लेते हैं। अगर आपका लिंक साधारण GET रिक्वेस्ट पर टोकन इस्तेमाल कर लेता है, तो स्कैनर उसे खत्म कर देता है, और कर्मचारी मरे हुए लिंक पर क्लिक करता है। आपका कोई भी स्टेजिंग मेलबॉक्स वह स्कैनर नहीं चलाता, जब तक आपकी अपनी कंपनी में ऐसा कोई न हो।

ये दोनों बग एक ही जगह से नहीं दिखते। एक के लिए ऐसे रिसीविंग सिस्टम तक असली डिलीवरी चाहिए जिसे आप नहीं चलाते। दूसरे के लिए लिंक के व्यवहार में बदलाव चाहिए, जिसे टेस्ट से ज़्यादा आसानी से कोड रिव्यू पकड़ लेता है। यही परतों में टेस्टिंग की वजह है: हर तरह का पता एक सवाल का जवाब देता है और बाकी पर चुप रहता है।

स्टेजिंग और प्रोडक्शन में अक्सर क्या अलग होता है	यह क्या छिपा सकता है
भेजने वाला डोमेन और From पता	गायब या बेमेल SPF और DKIM
प्रोवाइडर अकाउंट या सब-अकाउंट	सैंडबॉक्स मोड, भेजने की सीमाएं, अलग IP प्रतिष्ठा
पाने वाले	आंतरिक डोमेन जो आप पर भरोसा करते हैं, और अलाउलिस्ट जो खराब पते छिपा लेती हैं
क्लिक ट्रैकिंग	बदले हुए लिंक जो टूट जाते हैं, या बिना वैध सर्टिफ़िकेट वाला ट्रैकिंग डोमेन
वॉल्यूम	कतारें और रेट लिमिट जो सिर्फ़ लोड में असर दिखाती हैं
सप्रेशन लिस्ट	प्रोडक्शन के वे पते जो एक बार बाउंस हुए और अब चुपचाप छोड़ दिए जाते हैं
बेस URL सेटिंग	गलत होस्ट की ओर इशारा करने वाले लिंक

कौन-सा पता किस सवाल का जवाब देता है

ये रहे विकल्प, और हर एक का वह सवाल जिसका जवाब वह सच में दे सकता है।

लोकल कैचर: “मेरे ऐप ने क्या बनाया?”

SMTP कैचर वह सब स्वीकार कर लेता है जो आपका ऐप भेजता है और उसे बिना डिलीवर किए वेब पेज में दिखाता है। Mailpit एक लोकप्रिय ओपन-सोर्स विकल्प है। डिफ़ॉल्ट रूप से वह SMTP के लिए पोर्ट 1025 पर सुनता है और अपना वेब इंटरफ़ेस पोर्ट 8025 पर देता है, इसलिए आप अपनी डेवलपमेंट सेटिंग localhost:1025 पर रखते हैं और http://localhost:8025 खोलते हैं। Nodemailer का Ethereal भी इसी तरह का विचार है, जिसमें होस्टेड नकली SMTP सेवा है। कैचर तेज़ और निजी है, और उससे आप किसी भी पते पर भेज सकते हैं, बिना किसी असली व्यक्ति तक पहुंचने के जोखिम के। लेकिन वह DNS, ऑथेंटिकेशन या फ़िल्टरिंग के बारे में कुछ नहीं बताता, क्योंकि इंटरनेट पर कुछ जाता ही नहीं।

फ़्रेमवर्क का टेस्ट हेल्पर: “क्या मेरे कोड ने सही मेल मांगा?”

ज़्यादातर फ़्रेमवर्क टेस्ट के दौरान भेजे जाने वाले मेल को मेमोरी में दर्ज कर सकते हैं। Laravel में Mail::fake() है, Django मैसेज django.core.mail.outbox में इकट्ठा करता है, और Rails में ActionMailer::Base.deliveries है। इनसे यह जांचें कि कोई जॉब सही प्राप्तकर्ता और टोकन के साथ एक ही बार चलता है। ये सबसे तेज़ फ़ीडबैक देते हैं, और कैचर से भी कम बाहरी दुनिया को टेस्ट करते हैं।

प्रोवाइडर का टेस्ट मोड: “क्या मेरा इंटीग्रेशन काम करता है?”

प्रोवाइडर यहां अलग-अलग तरह की मदद देते हैं, और इन फ़र्कों से फ़र्क पड़ता है। Amazon SES में मेलबॉक्स सिम्युलेटर है जिसके पते success@simulator.amazonses.com, bounce@simulator.amazonses.com और complaint@simulator.amazonses.com जैसे हैं, जो आपकी प्रतिष्ठा को नुकसान पहुंचाए बिना वही नतीजे पैदा करते हैं। नया SES अकाउंट सैंडबॉक्स में शुरू होता है, जहां वह सिर्फ़ वेरिफ़ाई किए पतों पर भेज सकता है। SendGrid का सैंडबॉक्स मोड, जो mail_settings.sandbox_mode.enable से सेट होता है, आपकी रिक्वेस्ट को डिलीवर किए बिना जांचता है। Postmark इसी काम के लिए POSTMARK_API_TEST टोकन मानता है। ये API की गलतियों और बाउंस व शिकायत वाले वेबहुक के लिए अच्छे हैं, और ये साबित नहीं करते कि मेल किसी तक पहुंचा। अपने प्रोवाइडर के मौजूदा दस्तावेज़ देखें, क्योंकि ये फ़ीचर बदलते रहते हैं।

आपका अपना टेस्ट डोमेन: “क्या पूरा फ़्लो बार-बार काम करता है?”

ऑटोमेटेड एंड-टू-एंड टेस्ट के लिए ऐसा डोमेन या सबडोमेन सेट करें जिसे आप कंट्रोल करते हों, जिसमें कैच-ऑल मेलबॉक्स या इनबाउंड वेबहुक हो, ताकि आपका टेस्ट कोड API से मेल पढ़ सके। इसे सेट करने में मेहनत लगती है, पर यह निजी और स्थिर है, और किसी और की वेबसाइट पर निर्भर नहीं करता। जिन डोमेन के आप मालिक नहीं हैं, उन पर पते गढ़ें नहीं। testuser@gmail.com का कोई मालिक हो सकता है, और आप जो भेजेंगे वह उसे मिलेगा। RFC 2606 example.com और .test व .example टॉप-लेवल नाम इसलिए रिज़र्व करता है कि डॉक्यूमेंटेशन और टेस्ट डेटा के पास इशारा करने के लिए कोई सुरक्षित जगह हो। ये नाम मेल पा नहीं सकते, इसलिए फ़िक्स्चर के लिए सही हैं और डिलीवरी टेस्ट के लिए बेकार।

असली बाहरी अस्थायी इनबॉक्स: “क्या किसी अजनबी का डोमेन इसे पाएगा?”

यहां अस्थायी इनबॉक्स अपनी जगह कमाता है। यह ऐसे डोमेन पर असली मेलबॉक्स है जिसे आप कंट्रोल नहीं करते और जिस पर आपकी कोई अलाउलिस्ट नहीं है। आपके मैसेज को MX रिकॉर्ड ढूंढना, SMTP कनेक्शन बनाना और स्वीकार होना पड़ता है। VookMail पर डोमेन के MX रिकॉर्ड एक मेल डिलीवरी प्रोवाइडर की ओर इशारा करते हैं जो मैसेज पाकर उसे HTTPS पर फ़ॉरवर्ड करता है। नया पता होने का मतलब कोई इतिहास नहीं भी है: न पुराने मैसेज, न आपकी सप्रेशन लिस्ट में पहले का बाउंस, न फ़िल्टर। इसलिए “मैंने नए पते से साइन-अप किया और कुछ नहीं मिला” को दोहराने का यह तेज़ तरीका है। यह उनके लिए भी काम का है जो डेवलपर नहीं हैं। डिज़ाइनर या प्रोडक्ट मैनेजर आपके टूल का कोई एक्सेस लिए बिना देख सकता है कि नए यूज़र को क्या मिलता है।

बड़े मेलबॉक्स प्रोवाइडर पर सीड अकाउंट: “यह कहां पहुंचता है?”

एक डोमेन पर डिलीवर हुआ मैसेज आपको दूसरे डोमेन के स्पैम फ़ोल्डर के बारे में कुछ नहीं बताता। उन प्रोवाइडर पर, जो आपके यूज़र असल में इस्तेमाल करते हैं, असली अकाउंट का एक छोटा सेट रखें, और टेंपलेट या डोमेन में बड़े बदलाव से पहले देखें कि मेल कहां पहुंचता है। फिर रिलीज़ के बाद बाउंस और शिकायतों के आंकड़े देखें। अगर आपका मेल स्पैम की समस्या जैसा दिखता है, तो ये अकाउंट वह जगह हैं जहां आप उसे सबसे पहले देखेंगे।

तरीका	इंटरनेट से गुज़रता है	सेटअप	ऑटोमेशन	कंटेंट की प्राइवेसी	सबसे अच्छा चरण
फ़्रेमवर्क टेस्ट हेल्पर	नहीं	कुछ नहीं	बहुत बढ़िया	प्रोसेस के अंदर रहता है	यूनिट और फ़ीचर टेस्ट
लोकल SMTP कैचर	नहीं	कम	अच्छा	लोकल रहता है	डेवलपमेंट
प्रोवाइडर टेस्ट मोड	आम तौर पर नहीं	कम	अच्छा	प्रोवाइडर के पास रहता है	इंटीग्रेशन टेस्ट
आपका अपना टेस्ट डोमेन	हां	मध्यम से ज़्यादा	अच्छा	आपके नियंत्रण में	CI एंड-टू-एंड, स्टेजिंग
अस्थायी इनबॉक्स	हां	कुछ नहीं	सुझाया नहीं जाता	इसे सार्वजनिक मानें	मैनुअल QA और रिलीज़ से पहले की जांच
सीड अकाउंट	हां	मध्यम	सीमित	मध्यम	प्लेसमेंट जांच

अस्थायी इनबॉक्स से मैनुअल रन

यह स्टेजिंग या प्रोडक्शन जैसे माहौल पर साइन-अप फ़्लो से गुज़रने का दोहराया जा सकने वाला तरीका है। एक बार आदत पड़ जाए तो इसमें करीब दस मिनट लगने चाहिए।

1. पक्का करें कि माहौल क्रेडेंशियल को छोड़कर प्रोडक्शन जैसी ही प्रोवाइडर कॉन्फ़िगरेशन इस्तेमाल करता है, और उसमें सिर्फ़ गढ़ा हुआ डेटा है। अगर ऐसा नहीं है, तो यह लिख लें, क्योंकि इससे आपके निष्कर्ष सीमित हो जाते हैं।
2. VookMail खोलें और नया दबाएं। ऐसा यूज़रनेम लिखें जिसमें टेस्ट का कोड हो, जैसे email-signup-03-x7, 30 से ज़्यादा डोमेन में से एक चुनें और तीर दबाएं। अगर मेल में कुछ भी संवेदनशील हो सकता है तो पीला रैंडम बटन इस्तेमाल करें, क्योंकि जो भी किसी पते को जानता या अंदाज़े से पा लेता है, वह उस इनबॉक्स को खोल सकता है।
3. कॉपी दबाएं और गढ़े हुए प्रोफ़ाइल डेटा के साथ नए यूज़र के रूप में रजिस्टर करें।
4. सबमिट करने का समय और मैसेज दिखने का समय नोट करें। इनबॉक्स हर कुछ सेकंड में जांचता है, इसलिए मिनटों का फ़ासला आपकी कतार या प्रोवाइडर की ओर इशारा करता है। पक्का करना हो तो रिफ्रेश दबाएं।
5. मैसेज को वैसे पढ़ें जैसे नया यूज़र पढ़ेगा: भेजने वाले का नाम, विषय, प्रीव्यू टेक्स्ट, बॉडी, बटन, सादा लिंक, फ़ुटर। VookMail मैसेज के ऊपर पकड़े गए कोड और कन्फ़र्मेशन लिंक दिखाता है, जो मोटे तौर पर जांच है कि आपका कोड और लिंक आसानी से पहचाने जाते हैं।
6. इसे इमेज बंद करके देखें। VookMail इमेज तब तक बंद रखता है जब तक आप अनुमति न दें, और छिपे हुए ट्रैकिंग पिक्सल हटा देता है। अगर उस हाल में मैसेज का कोई मतलब नहीं बनता, तो आपके कुछ यूज़र भी यही देख रहे हैं। हालांकि अपने ओपन ट्रैकिंग को परखने के लिए इस इनबॉक्स का इस्तेमाल न करें, क्योंकि पिक्सल चलेंगे ही नहीं।
7. QR बटन दबाएं, टेस्ट फ़ोन से पता स्कैन करें और वही इनबॉक्स वहां खोलें, ताकि असली डिवाइस पर असली लिंक टैप कर सकें, खासकर अगर आप यूनिवर्सल लिंक या ऐप लिंक इस्तेमाल करते हैं।
8. वेरिफ़िकेशन पूरा करें और पक्का करें कि अकाउंट की स्थिति ठीक वैसे बदलती है जैसे बदलनी चाहिए।
9. नीचे की चेकलिस्ट से नेगेटिव केस चलाएं: लिंक दोबारा इस्तेमाल करें, एक्सपायरी का इंतज़ार करें, दोबारा भेजने का अनुरोध करें।
10. अपने सबूत सेव करें: स्क्रीनशॉट, समय और इस्तेमाल किया गया पता। मैसेज करीब एक दिन में हट जाते हैं, इसलिए अगले हफ़्ते लिखी बग रिपोर्ट के पास दिखाने को कुछ नहीं होगा।
11. हटाएं दबाएं और अगर आपकी प्रक्रिया मांगे तो टेस्ट अकाउंट हटा दें।

एक ब्राउज़र में कई पते रखे जा सकते हैं, इसलिए बुलाने वाला और बुलाया गया, या ईमेल बदलने के पुराने और नए पते, एक साथ खुले रह सकते हैं। अगर आप अपने टेस्ट में फ़ाइलें अटैच करते हैं, तो याद रखें कि VookMail .exe जैसी आम प्रोग्राम फ़ाइलें मना करता है और आर्काइव पर चेतावनी दिखाता है, इसलिए वहां अटैचमेंट का रद्द होना आपकी तरफ़ की बग नहीं भी हो सकती।

गड़बड़ी को पढ़ना

“ईमेल कभी नहीं आया” कोई लक्षण है जो करीब छह जगहों में से किसी में भी हो सकता है, और टीमें गलत जगह से शुरू करके घंटे गंवा देती हैं। अपने कोड से बाहर की ओर रास्ते पर चलें, और जहां पहली बार मैसेज दिखना बंद हो जाए, वहीं रुकें।

1. क्या ऐप ने कोशिश की? एप्लिकेशन लॉग में भेजने की कोशिश और किसी एक्सेप्शन को खोजें। ऐसा जॉब देखें जो बना ही नहीं, जो अक्सर इसलिए होता है कि कोई शर्त या फ़ीचर फ़्लैग गलत था।
2. क्या वर्कर चला? अटके, फ़ेल या दोबारा चलाए गए जॉब देखें। डिप्लॉय के बाद रीस्टार्ट न किया गया क्यू वर्कर पुराना कोड चला सकता है, और रीट्राई नीति डुप्लिकेट भेज सकती है।
3. क्या प्रोवाइडर ने स्वीकार किया? अपने प्रोवाइडर के एक्टिविटी लॉग में प्राप्तकर्ता या Message-ID खोजें। Accepted, deferred, bounced और dropped चार अलग कहानियां हैं।
4. क्या वह सप्रेस हुआ? अगर उस पते ने पहले बाउंस या शिकायत की थी, तो कई प्रोवाइडर आगे के भेजे चुपचाप छोड़ देते हैं। यह अक्सर उन टेस्टरों को पकड़ता है जो पुराना पता दोबारा इस्तेमाल करते हैं।
5. पाने वाले सर्वर ने क्या कहा? प्रोवाइडर लॉग आम तौर पर SMTP का जवाब दिखाते हैं, और वह टेक्स्ट पूरी जांच की सबसे काम की लाइन है।
6. क्या DNS सही है? असल में भेजने वाले डोमेन के लिए SPF, DKIM और DMARC जांचें।
7. क्या वह वहां है पर छिपा है? स्पैम फ़ोल्डर, टैब और क्लाइंट फ़िल्टर आखिर में आते हैं, जब सीड अकाउंट आपको दिखा सके।

SMTP का जवाब आपको क्या बता रहा है

RFC 5321 के तहत 4 से शुरू होने वाला जवाब अस्थायी विफलता है, और भेजने वाले को बाद में फिर कोशिश करनी चाहिए। 5 से शुरू होने वाला जवाब स्थायी है। RFC 3463 के बेहतर स्टेटस कोड उसके बाद और ब्योरा जोड़ते हैं। गढ़ी हुई एक लॉग लाइन कुछ ऐसी दिख सकती है, सिर्फ़ फ़ॉर्मैट दिखाने के लिए:

सिर्फ़ उदाहरण: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"

इसे बाएं से दाएं पढ़ें। 5 का मतलब है कि दोबारा कोशिश से फ़ायदा नहीं होगा। 5.7 वाला परिवार सुरक्षा या नीति से जुड़ा है, जो आपको DNS और साइनिंग की ओर भेजता है, प्राप्तकर्ता के पते की ओर नहीं। नीचे की तालिका आम पैटर्न के लिए शुरुआती बिंदु देती है।

आप क्या देखते हैं	सबसे संभावित परत	पहले कहां देखें
प्रोवाइडर लॉग में कुछ नहीं	ऐप या कतार	एप्लिकेशन लॉग और फ़ेल हुए जॉब
प्रोवाइडर कहता है “dropped” या “suppressed”	प्रोवाइडर की सप्रेशन लिस्ट	टेस्ट पता हटाएं, या नया इस्तेमाल करें
API सफलता लौटाता है, पर भेजा गया कुछ भी लॉग नहीं होता	सैंडबॉक्स मोड अब भी चालू	उस माहौल की प्रोवाइडर सेटिंग
5.1.1 या मिलता-जुलता	प्राप्तकर्ता का पता	टाइपो, और फ़ॉर्म वैलिडेशन जिसने पता बदल दिया
Gmail पर 5.7.26	ऑथेंटिकेशन	SPF, DKIM और From डोमेन से अलाइनमेंट
4xx डिफ़रल जो कुछ देर बाद ठीक हो जाते हैं	पाने वाला आपको धीमा कर रहा है	वॉल्यूम, प्रतिष्ठा, या नया भेजने वाला IP
बाहरी इनबॉक्स पर डिलीवर, Gmail पर गायब	पाने वाले की नीति या फ़िल्टरिंग	सीड अकाउंट और Google के सेंडर दिशानिर्देश
आता है, पर लिंक कहता है “already used”	स्कैनर लिंक को पहले ही खोल रहा है	टोकन GET पर नहीं, POST पर इस्तेमाल करें
लिंक सुरक्षा चेतावनी पर ले जाता है	क्लिक-ट्रैकिंग डोमेन	ट्रैकिंग सबडोमेन का सर्टिफ़िकेट
दो बार आता है	रीट्राई लॉजिक	जॉब की आइडेम्पोटेंसी और वे टाइमआउट जो रीट्राई शुरू करते हैं
बहुत देर से आता है	कतार	वर्कर की क्षमता, और क्या रीसेट मेल बल्क मेल के साथ एक ही कतार में है

आखिरी पंक्ति डिज़ाइन की एक बात है जिस पर एक वाक्य और बनता है। अगर पासवर्ड रीसेट न्यूज़लेटर भेजने के साथ एक ही कतार में हैं, तो वे उसके पीछे इंतज़ार करते हैं। ट्रांज़ैक्शनल मेल को उसकी अपनी कतार दें, और हो सके तो अपना सबडोमेन और भेजने की स्ट्रीम भी, ताकि मार्केटिंग की समस्या लॉगिन में देरी न करे।

वे कमांड जो खोज को छोटा करती हैं

इसमें से ज़्यादातर आप अपने टर्मिनल से ही जांच सकते हैं। इन उदाहरणों में उदाहरण वाले नामों की जगह अपने नाम रखें।

• dig +short MX example.com दिखाता है कि कोई डोमेन मेल कहां पाता है। खाली जवाब को ध्यान से देखना चाहिए, क्योंकि RFC 5321 भेजने वालों को address रिकॉर्ड पर लौटने की छूट देता है, जबकि 0 . वाला जवाब RFC 7505 के तहत null MX है, यानी डोमेन कोई मेल नहीं लेता।
• dig +short TXT example.com दूसरे टेक्स्ट रिकॉर्ड के साथ SPF रिकॉर्ड दिखाता है।
• dig +short TXT selector._domainkey.example.com DKIM कुंजी दिखाता है। असली सेलेक्टर मैसेज के DKIM-Signature हेडर में s= की वैल्यू से लें।
• dig +short TXT _dmarc.example.com DMARC नीति दिखाता है।
• openssl s_client -starttls smtp -connect smtp.example.com:587 जांचता है कि आप अपने रिले तक पहुंच सकते हैं और उसका सर्टिफ़िकेट दिखाता है। यहां विफलता का मतलब फ़ायरवॉल या TLS की समस्या है, कंटेंट की बात बहुत बाद में आती है।
• swaks --to qa@example.test --from app@example.test --server localhost:1025 हाथ से एक सादा मैसेज भेजता है। यह आपके ऐप को बायपास करता है, इसलिए आप जान सकते हैं कि समस्या आपके कोड की है या रास्ते की।

हेडर के स्तर के सबूत के लिए सबसे भरोसेमंद नज़रिया किसी बड़े प्रोवाइडर पर आपके कंट्रोल वाला मेलबॉक्स है। Gmail में मैसेज खोलें, तीन बिंदु वाला मेनू इस्तेमाल करें और Show original चुनें, जो सबसे ऊपर SPF, DKIM और DMARC के नतीजे दिखाता है। ध्यान रखें कि एक रिसीवर का “pass” दूसरे के लिए गारंटी नहीं है।

हर फ़्लो में क्या जांचें

“क्या यह पहुंचा?” पहला सवाल है, और आम तौर पर सबसे कम दिलचस्प। इसके बाद हर फ़्लो के गड़बड़ होने के अपने तरीके हैं।

पासवर्ड रीसेट

OWASP की Forgot Password Cheat Sheet यहां आधार बनाने के लिए संदर्भ है। वह मांग करती है कि खाता हो या न हो, संदेश एक-सा रहे, जवाब एक जैसे समय में आएं, टोकन रैंडम, लंबे, सुरक्षित रूप से रखे हुए और एक बार चलने वाले हों, और रीसेट पेज पर Referrer-Policy: no-referrer हो।

• रिक्वेस्ट पेज रजिस्टर्ड और गैर-रजिस्टर्ड पतों के लिए वही संदेश दिखाता है, और लगभग उतना ही समय लेता है। अनजान पतों के लिए तुरंत जवाब उतना ही बता देता है जितना शब्द बताते।
• लिंक एक बार चलता है। उसे दूसरी बार खोलें तो साफ़ समझाइश मिलती है और दूसरा अनुरोध करने का रास्ता।
• नया रीसेट मांगने पर पुराने लिंक अमान्य हो जाते हैं, या आपका डिज़ाइन जान-बूझकर कुछ और कहता है।
• एक्सपायरी सर्वर लागू करता है, और उसे इंतज़ार करके, या टेस्ट माहौल में समय बदलकर टेस्ट किया गया है।
• सफल रीसेट कन्फ़र्मेशन ईमेल भेजता है, और बाकी सेशन आपकी नीति के हिसाब से संभाले जाते हैं।
• लिंक खोलने से अपने आप कुछ नहीं बदलता। टोकन तब इस्तेमाल होता है जब फ़ॉर्म सबमिट होता है।
• रीसेट पेज अपना URL थर्ड-पार्टी एनालिटिक्स या एरर ट्रैकिंग को नहीं भेजता।
• रेट लिमिट IP के साथ-साथ हर अकाउंट पर भी लागू होती हैं, ताकि कोई किसी अजनबी का इनबॉक्स न भर सके।
• मिले-जुले केस या प्लस साइन वाले पते सादे पतों जैसे ही काम करते हैं।

साइन-अप वेरिफ़िकेशन

• एक साइन-अप एक ही मैसेज भेजता है, जॉब के रीट्राई होने पर भी।
• लिंक या कोड एक बार चलता है, और एक्सपायर्ड-लिंक पेज आगे का रास्ता देता है।
• दोबारा भेजना या तो पिछला टोकन अमान्य करता है या डिज़ाइन के मुताबिक उसके साथ चलता है, और रेट-लिमिट होता है।
• अनवेरिफ़ाइड अकाउंट पर ठीक वही पाबंदियां हैं जो आपने चाहीं।
• रजिस्टर्ड पते से दोबारा साइन-अप करने पर किसी अनजान विज़िटर को यह नहीं पता चलता कि अकाउंट मौजूद है, अगर आपका प्रोडक्ट इसे संवेदनशील मानता है। आम पैटर्न यह है कि इसके बजाय मौजूदा मालिक को ईमेल भेजा जाए।
• लिंक सही माहौल की ओर जाता है। प्रोडक्शन से जुड़ने वाला स्टेजिंग मैसेज देर-सबेर प्रोडक्शन का डेटा बदल देगा।

लॉगिन कोड और मैजिक लिंक

• कोड काफ़ी लंबे हैं, जल्दी एक्सपायर होते हैं और कोशिशों की सीमा है।
• मैजिक लिंक बटन वाला लैंडिंग पेज दिखाते हैं, और उसी POST पर इस्तेमाल होते हैं, इसलिए स्कैनर का GET कोई नुकसान नहीं करता।
• लिंक को दूसरे डिवाइस पर खोलने पर वही होता है जो आपका डिज़ाइन कहता है, और यूज़र समझ सकता है कि क्या हुआ।
• विषय में कोड तभी हो जब आपने तय किया हो कि यह स्वीकार्य है, क्योंकि नोटिफ़िकेशन उसे लॉक स्क्रीन पर दिखाते हैं।

ईमेल पता बदलना

• कन्फ़र्मेशन नए पते पर जाता है, और कन्फ़र्म होने तक कुछ नहीं बदलता।
• पुराने पते पर सूचना जाती है, ताकि असली मालिक बिना इजाज़त के बदलाव पर कदम उठा सके।
• बदलाव के बाद बाकी बचे रीसेट टोकन काम करना बंद कर देते हैं।
• दो अस्थायी इनबॉक्स इसे हाथ से जल्दी चलाना आसान बना देते हैं।

न्योते, रसीदें और नोटिफ़िकेशन

• बिना अकाउंट वाले व्यक्ति को न्योता साइन-अप पर ले जाता है जिसमें पता पहले से भरा या लॉक होता है, जैसा डिज़ाइन में है। एक्सपायर्ड या रद्द किया गया न्योता यह साफ़ कहता है।
• किसी दूसरे अकाउंट से न्योता स्वीकार नहीं हो सकता, जब तक आपका डिज़ाइन इसकी इजाज़त न दे।
• रसीदें यूज़र के लोकेल के हिसाब से सही रकम, मुद्राएं, तारीखें और टाइम ज़ोन दिखाती हैं, और अटैचमेंट के नाम समझदार हैं और वे ठीक से खुलते हैं।
• पसंद में बदलाव अगले भेजे जाने वाले मेल से लागू होते हैं।
• गैर-ज़रूरी मेल में चालू अनसब्सक्राइब है, और अकाउंट व सुरक्षा का मेल साफ़ अलग है। पाठक की तरफ़ से यह कैसा दिखता है, यह हमारा न्यूज़लेटर की भरमार वाला लेख दिखाता है।
• हर समर्थित भाषा के लिए अनूदित टेंपलेट मौजूद हैं, जहां ज़रूरी हो वहां सही राइट-टू-लेफ़्ट लेआउट के साथ, और विषय में कोई बिना अनुवाद का टुकड़ा नहीं है।

टोकन कोड की समीक्षा

इनबॉक्स से टेस्टिंग व्यवहार दिखाती है। छोटा कोड रिव्यू ऐसी डिज़ाइन खामियां पकड़ता है जो कोई इनबॉक्स नहीं दिखाएगा। रीसेट, वेरिफ़िकेशन और मैजिक लिंक के पीछे का कोड पढ़ते समय ये चीज़ें देखें।

• रैंडम का स्रोत। यह क्रिप्टोग्राफ़िक रूप से सुरक्षित जेनरेटर होना चाहिए, जैसे Python में secrets.token_urlsafe(32), Node में crypto.randomBytes(32) या PHP में random_bytes(32)। टाइमस्टैम्प, बढ़ती ID या ईमेल का हैश स्वीकार्य नहीं।
• लंबाई। लिंक टोकन में आम तौर पर कम से कम 128 बिट की रैंडमनेस होती है। छह अंकों का कोड तभी ठीक है जब एक्सपायरी कड़ी हो और कोशिशों की सीमा हो।
• स्टोरेज। टोकन का हैश रखें, ताकि डेटाबेस लीक होने पर काम करने वाले रीसेट लिंक न बंटें।
• तुलना। जहां आप गुप्त वैल्यू की सीधी तुलना करते हैं, वहां hmac.compare_digest, hash_equals या crypto.timingSafeEqual जैसा कॉन्स्टेंट-टाइम फ़ंक्शन इस्तेमाल करें।
• उद्देश्य। वेरिफ़िकेशन टोकन रीसेट टोकन की तरह काम न करे, और एक अकाउंट का टोकन दूसरे पर न चले।
• एक्सपायरी। एक्सपायरी का समय सर्वर के पास रहे, ताकि लिंक बदलकर उसे बदला न जा सके।
• अमान्य करना। टोकन का इस्तेमाल, किसी और रास्ते से पासवर्ड बदलना, या ईमेल बदलना, तीनों बाकी टोकन रद्द करें।
• लॉगिंग। टोकन वाले पूरे URL एप्लिकेशन लॉग, एनालिटिक्स इवेंट या एरर ट्रैकर तक न पहुंचें। अपने HTTP एक्सेस लॉग भी जांचें।

हेडर और ऑथेंटिकेशन

कैचर में रॉ सोर्स खोलें ताकि देखें कि आपके ऐप ने क्या बनाया, और बड़े प्रोवाइडर पर अपने कंट्रोल वाले मेलबॉक्स में, ताकि देखें कि प्रोवाइडर और नेटवर्क ने क्या जोड़ा।

हेडर या तत्व	क्या जांचें
From	सही ब्रांड नाम, ऐसे डोमेन पर जिसके आप मालिक हैं और जिसे ऑथेंटिकेट करते हैं
Reply-To	निगरानी वाला मेलबॉक्स, या जान-बूझकर छोड़ा हुआ
Return-Path	बाउंस डोमेन, जो आपके डोमेन से अलाइन हो अगर आप DMARC के लिए SPF पर निर्भर हैं
DKIM-Signature	मौजूद हो, और d= डोमेन From डोमेन से अलाइन हो
Message-ID	मौजूद और अनोखी, क्योंकि प्रोवाइडर लॉग में ट्रेसिंग के लिए यही आपकी कुंजी है
Content-Type	HTML और सादे टेक्स्ट, दोनों हिस्सों वाला multipart/alternative
List-Unsubscribe, List-Unsubscribe-Post	बल्क और मार्केटिंग मेल पर मौजूद, RFC 8058 के तहत वन-क्लिक अनसब्सक्राइब सपोर्ट के साथ
Auto-Submitted	ऑटोमेटेड मेल पर auto-generated, जैसा RFC 3834 में परिभाषित है, ताकि रिप्लाई लूप रोकने में मदद मिले

नया भेजने वाला डोमेन जारी करने से पहले कुछ नियम जांचें। SPF मूल्यांकन में दस DNS लुकअप से ज़्यादा नहीं होने चाहिए (RFC 7208), और अपने रिकॉर्ड में एक और वेंडर जोड़ने के बाद सीमा पार कर लेना फ़ेल होने का आसान तरीका है। DKIM के लिए प्रोवाइडर का सेलेक्टर रिकॉर्ड पब्लिश और वेरिफ़ाई होना चाहिए। DMARC के लिए आपके From डोमेन पर रिकॉर्ड चाहिए, जो आम तौर पर रिपोर्टिंग चालू करके p=none से शुरू होता है और अलाइनमेंट पक्का होने पर कड़ा किया जाता है।

वॉल्यूम भी नियम बदल देता है। Google के दिशानिर्देश किसी भेजने वाले को तब बल्क मानते हैं जब वह एक दिन में निजी Gmail अकाउंट को करीब 5,000 मैसेज भेजता है, और बल्क भेजने वालों को SPF, DKIM और DMARC चाहिए, प्रमोशनल मेल पर वन-क्लिक अनसब्सक्राइब, और यूज़र द्वारा रिपोर्ट की गई स्पैम दर 0.3% से नीचे, जिसमें 0.1% सुझाया गया लक्ष्य है। दूसरे प्रोवाइडर के अपने नियम हैं। उदाहरण के लिए Amazon SES, 5% बाउंस दर या 0.1% शिकायत दर पर अकाउंट को समीक्षा में डाल देता है। योजना बनाने से पहले मौजूदा आंकड़े अपने प्रोवाइडर के दस्तावेज़ों से पढ़ें, क्योंकि वे बदलते रहते हैं।

पते की हैंडलिंग और वैलिडेशन

फ़ॉर्म वैध पतों को उससे ज़्यादा बार मना करते हैं जितना लोग सोचते हैं, और अपस्ट्रीम वैलिडेशन बग बिल्कुल डिलीवरी फ़ेल होने जैसा दिख सकता है। अपना वैलिडेशन इनसे टेस्ट करें।

इनपुट	अपेक्षित हैंडलिंग	आम बग
user+tag@example.com	स्वीकार करें	रेगुलर एक्सप्रेशन प्लस साइन को मना कर देता है
User@Example.COM	स्वीकार करें, और डोमेन को केस-इनसेंसिटिव मानें	सिर्फ़ केस से अलग डुप्लिकेट अकाउंट
o'brien@example.com	स्वीकार करें	मना कर दिया जाता है, या एस्केप न होने पर क्वेरी या टेंपलेट तोड़ देता है
first.last@sub.example.co.uk	स्वीकार करें	वैलिडेशन मानता है कि डोमेन में एक ही बिंदु है
आगे या पीछे की खाली जगह	पहले ट्रिम करें	सही पेस्ट पर “Invalid email”
बहुत लंबा पता	लोकल हिस्से के लिए 64 अक्षर और कुल 254 की सीमा लागू करें	छोटा डेटाबेस कॉलम उसे चुपचाप काट देता है
अंतर्राष्ट्रीय डोमेन और पते	साफ़ संदेश के साथ लगातार स्वीकार करें या मना करें	एन्कोडिंग या लॉगिंग में क्रैश
बिना मेल रास्ते वाला डोमेन	चेतावनी दें या मना करें	ऐसा अकाउंट जो कभी वेरिफ़ाई नहीं हो सकता

फ़ॉर्म में ढीला वैलिडेशन करें, फिर कन्फ़र्मेशन ईमेल से साबित होने दें कि पता काम करता है। सख्त रेगुलर एक्सप्रेशन आपके असली यूज़र गंवाता है और यह बहुत कम बताता है कि मेलबॉक्स मौजूद है या नहीं।

अगर आपका प्रोडक्ट प्रोडक्शन में अस्थायी डोमेन मना करता है, तब भी आपकी QA प्रक्रिया को स्टेजिंग पर निकलने का रास्ता चाहिए। विकल्पों में प्रोडक्शन के बाहर टेस्ट डोमेन की अलाउलिस्ट, टेस्ट माहौल में जांच बंद करने वाला फ़्लैग, या आपका अपना टेस्ट डोमेन शामिल हैं। टेस्टिंग आसान बनाने के लिए प्रोडक्शन का नियम कमज़ोर न करें। और अगर आप तय कर रहे हैं कि यह नियम रखना भी है या नहीं, तो हमारा लेख वेबसाइटें अस्थायी ईमेल क्यों ब्लॉक करती हैं मालिक के नज़रिए से इसकी लागत और फ़ायदे बताता है।

यह कैसे रेंडर होता है

रेंडरिंग वह जगह है जहां डिज़ाइनर की समीक्षा सबसे ज़्यादा काम आती है, और इसके लिए असली क्लाइंट में असली मैसेज चाहिए।

• सादा टेक्स्ट वाला हिस्सा अच्छा पढ़ा जाता है और पूरा लिंक शामिल करता है। वहां “नीचे दिए बटन पर क्लिक करें” किसी काम का नहीं।
• डार्क मोड में लोगो दिखते रहते हैं और कॉन्ट्रास्ट बना रहता है। VookMail में डार्क मोड है, जो एक शुरुआत है, और आपके यूज़र जिन क्लाइंट को पसंद करते हैं वही असली परीक्षा हैं।
• इमेज ब्लॉक होने पर भी कॉल टू एक्शन असली टेक्स्ट लिंक या HTML बटन रहता है।
• बटन टैप करने लायक बड़े हैं, और लंबे URL फ़ोन का लेआउट नहीं तोड़ते।
• प्रीव्यू टेक्स्ट सोच-समझकर लिखा गया है, उसमें टेंपलेट की बची हुई भाषा नहीं।
• हेडिंग सिमेंटिक हैं, कॉन्ट्रास्ट पर्याप्त है, लिंक का टेक्स्ट वर्णनात्मक है, और HTML में भाषा एट्रिब्यूट है।
• गायब डेटा से “Hi {first_name}” या “Hi ,” नहीं बनता।
• मैसेज का साइज़ करीब 102 KB से काफ़ी नीचे रहता है, जिस बिंदु पर Gmail के लंबे मैसेज को काटने की बात आम तौर पर कही जाती है। कटने से आपका फ़ुटर और बॉडी का अनसब्सक्राइब लिंक छिप सकता है।

हादसों से बचाव के उपाय

शर्मिंदा करने वाली ईमेल घटनाएं ज़्यादातर कॉन्फ़िगरेशन की गलतियां होती हैं: स्टेजिंग का मेल असली ग्राहकों तक पहुंच जाना, टेस्ट कुंजी पर प्रोडक्शन, localhost के लिंक। कुछ सेटिंग इनमें से ज़्यादातर को रोक देती हैं।

हर माहौल के लिए अलग क्रेडेंशियल रखें, एनवायरनमेंट वेरिएबल या सीक्रेट मैनेजर में। प्रोडक्शन के बाहर प्राप्तकर्ता की अलाउलिस्ट इस्तेमाल करें ताकि मेलर सिर्फ़ मंज़ूर टेस्ट डोमेन पर डिलीवर करे और बाकी सब को रीडायरेक्ट या ड्रॉप कर दे। हर लिंक एक सेटिंग से बनाएं, जैसे APP_URL, ताकि टेंपलेट में कोई हार्ड-कोड किया हुआ होस्ट न हो। गैर-प्रोडक्शन विषयों में [STAGING] जैसा उपसर्ग लगाएं, ताकि गलत जगह पहुंचा मैसेज पाने वाले को तुरंत समझ आए।

अगर आप प्रोडक्शन डेटा स्टेजिंग में कॉपी करते हैं, तो कोई भी मेल वर्कर शुरू होने से पहले हर असली पते को नकली पते से बदल दें। क्रम मायने रखता है, क्योंकि जो वर्कर पहले शुरू हो जाए वह तुरंत शेड्यूल्ड मेल निपटाने लग सकता है। और हर माहौल के लिए सैंडबॉक्स मोड को सोच-समझकर ट्रैक करें। प्रोडक्शन के सैंडबॉक्स में रहते हुए लॉन्च करना एक जाना-पहचाना हादसा है: API सफलता लौटाता है, लॉग साफ़ दिखते हैं, और कोई मेल बाहर नहीं जाता।

ऑटोमेटेड सूट आपके नियंत्रण वाले इंफ़्रास्ट्रक्चर पर रहें

सार्वजनिक अस्थायी इनबॉक्स CI के लिए गलत निर्भरता है। किसी और का वेब पेज स्क्रैप करना कमज़ोर तरीका है, और आपके बिल्ड ऐसे कारणों से फ़ेल होंगे जिनका आपके कोड से लेना-देना नहीं। यह आपका टेस्ट ट्रैफ़िक ऐसी सेवा पर भी डालता है जिसे आप नहीं चलाते। वहां के मैसेज पते को जानने वाला कोई भी पढ़ सकता है, इसलिए कोई ऑटोमेटेड चीज़ उन पर निर्भर नहीं होनी चाहिए।

एक समझदार व्यवस्था ऐसी दिखती है। फ़्रेमवर्क हेल्पर जांचते हैं कि सही मेल मांगा गया। आपके टेस्ट स्टैक में एक Mailpit कंटेनर असली मैसेज पाता है, और आपका टेस्ट उसे Mailpit के HTTP API (GET /api/v1/messages) से पढ़ता है, लिंक निकालता है और उसे फ़ॉलो करता है। प्रोवाइडर का टेस्ट मोड वेबहुक और एरर हैंडलिंग को परखता है। आपके अपने टेस्ट डोमेन पर रात का जॉब असली प्रोवाइडर से भेजता है और नतीजा इनबाउंड वेबहुक से पढ़ता है, ताकि आपको रोज़ संकेत मिले कि असली डिलीवरी अब भी चल रही है।

अस्थायी मेल टेस्टिंग के इंसानी हिस्सों का है: खोजी सत्र जहां आपको जल्दी नई पहचान चाहिए, रिलीज़ से पहले का स्मोक टेस्ट, किसी यूज़र की रिपोर्ट दोहराना, कॉपी और डिज़ाइन की समीक्षा, और फ़ोन पर टेस्टिंग। आखिरी के लिए, QR बटन या Google Play या Huawei AppGallery का ऐप इनबॉक्स को टेस्ट डिवाइस तक पहुंचा देता है। जांचें कि लिंक ऐप इंस्टॉल होने पर उसे खोलते हैं और न होने पर काम करने वाले वेब पेज पर लौट आते हैं, और ऐप नए लॉगिन की मांग किए बिना वेरिफ़ाई की स्थिति पहचान लेता है।

हैंडओवर के बाद भी टिकने वाला टेस्ट केस

एक-से टेस्ट केस हर रिलीज़ में दोहराना और टेस्टरों के बीच देना आसान होते हैं। इस उदाहरण में वे फ़ील्ड हैं जो आम तौर पर मायने रखते हैं।

फ़ील्ड	उदाहरण
टेस्ट ID	EMAIL-RESET-03
फ़्लो	पासवर्ड रीसेट, टोकन का दोबारा इस्तेमाल
पूर्व-शर्तें	स्टेजिंग पर वेरिफ़ाई किया हुआ टेस्ट अकाउंट, नए अस्थायी पते के साथ
चरण	रीसेट मांगें, लिंक खोलें, नया पासवर्ड सेट करें, वही लिंक फिर खोलें
अपेक्षित नतीजा	दूसरा इस्तेमाल समझाता है कि लिंक अब वैध नहीं है और नया अनुरोध करने को कहता है
सबूत	स्क्रीनशॉट, हो सके तो Message-ID, समय, इस्तेमाल किया गया पता
माहौल	स्टेजिंग बिल्ड नंबर और मेल कॉन्फ़िगरेशन

टेस्ट ID को यूज़रनेम में रखना, जैसे email-reset-03-x7, हर इनबॉक्स को उसके केस से जोड़ता है और दो टेस्टरों को एक पते पर टकराने से रोकता है। छोटा रैंडम प्रत्यय इसलिए है कि नाम का अंदाज़ा लगाकर कोई भी इनबॉक्स खोल सकता है।

सार्वजनिक इनबॉक्स में क्या न भेजें

किसी भी अस्थायी इनबॉक्स को ऐसा मानें कि पता जानने वाला कोई भी उसे पढ़ सकता है, और उसी हिसाब से टेस्ट करें।

• सिर्फ़ गढ़ा हुआ डेटा भेजें: नकली नाम, नकली ऑर्डर, नकली पते। असली ग्राहक का डेटा वहां नहीं जाना चाहिए, और जहां आप काम करते हैं उसके हिसाब से उसे भेजना आपके लिए कानूनी समस्या भी बना सकता है।
• असली सिस्टम के लिए API कुंजी, डेटाबेस क्रेडेंशियल या एडमिन न्योते कभी न भेजें।
• टेस्ट अकाउंट नियमित रूप से हटाएं, खासकर विशेषाधिकार वाले। सार्वजनिक इनबॉक्स से जुड़ा एडमिन टेस्ट यूज़र अंदर आने का रास्ता है, अगर कोई और वह इनबॉक्स खोलकर रीसेट मांग ले। चूंकि साफ़ होने के बाद पता आपके लिए रिज़र्व नहीं रहता, यह जोखिम टेस्ट के बाद भी बना रहता है।
• अस्थायी पते को असली प्रोडक्शन अकाउंट या ऐसी थर्ड-पार्टी सेवा का मालिक कभी न बनाएं जिस पर आपकी कंपनी निर्भर है।
• रिटेंशन अवधि जानें। मैसेज और अटैचमेंट करीब एक दिन बाद चले जाते हैं, और ब्योरा प्राइवेसी पॉलिसी में है।

अपने प्रोडक्ट को टेस्ट करना अस्थायी ईमेल के सबसे साफ़ जायज़ इस्तेमालों में से एक है। इसे वैसा ही रखें: उन्हीं सिस्टम को टेस्ट करें जिनके आप मालिक हैं या जिन्हें टेस्ट करने का आपको अधिकार है। अस्थायी इनबॉक्स का इस्तेमाल दूसरी कंपनियों की सेवाओं पर उनकी शर्तों के खिलाफ़ अकाउंट बनाने, ट्रायल बटोरने, या किसी और के साइन-अप फ़ॉर्म पर लोड टेस्ट करने के लिए न करें। नियम और शर्तें स्वीकार्य इस्तेमाल बताती हैं, और कार्यप्रणाली पेज समझाता है कि सेवा कैसे काम करती है। VookMail PAYATE के फ्री टूल नेटवर्क का हिस्सा है।

रिलीज़ से पहले

1. असल प्रोडक्शन भेजने वाले डोमेन के लिए SPF, DKIM और DMARC वेरिफ़ाई हैं, और From डोमेन अलाइन है।
2. प्रोडक्शन मेलर प्रोडक्शन क्रेडेंशियल पर है, सैंडबॉक्स मोड बंद है, और एक असली मैसेज से पक्का किया गया है।
3. साइन-अप वेरिफ़िकेशन नए बाहरी पते पर मिला, लिंक एक बार इस्तेमाल हुआ, एक्सपायरी टेस्ट की गई।
4. पासवर्ड रीसेट शुरू से अंत तक टेस्ट हुआ, जिसमें अनजान पतों के लिए एक-से जवाब और कन्फ़र्मेशन संदेश शामिल हैं।
5. रीसेट और मैजिक-लिंक टोकन फ़ॉर्म सबमिट पर इस्तेमाल होते हैं, ताकि स्कैनर का GET उन्हें खत्म न करे।
6. ईमेल बदलने पर नए और पुराने, दोनों पतों पर मेल जाता है।
7. सभी लिंक HTTPS पर प्रोडक्शन होस्ट की ओर इशारा करते हैं, क्लिक ट्रैकिंग से बदले गए लिंक भी।
8. ट्रांज़ैक्शनल मेल बल्क मेल से अलग है, कम से कम उसकी कतार में।
9. HTML और सादा टेक्स्ट दोनों मौजूद और पढ़ने लायक हैं, डार्क मोड और ब्लॉक की गई इमेज जांची गई हैं।
10. अगर डोमेन या टेंपलेट काफ़ी बदला है, तो सीड अकाउंट पर प्लेसमेंट जांच।
11. गैर-ज़रूरी मेल पर अनसब्सक्राइब काम करता है, और अनूदित टेंपलेट देखे जा चुके हैं।
12. सबूत रिलीज़ टिकट से जुड़े हैं, और बाउंस व शिकायत के आंकड़े ऐसे डैशबोर्ड पर हैं जिसे लॉन्च के बाद कोई देखेगा।

डेवलपर इस बारे में जो सवाल पूछते हैं

असली इनबॉक्स ने मेरा मेल ले लिया। क्या मैं Gmail पर सुरक्षित हूं?

नहीं। एक डोमेन पर डिलीवरी बताती है कि आपका मैसेज निकला, उसे रास्ता मिला और वहां स्वीकार हुआ। Gmail के अपने ऑथेंटिकेशन नियम और फ़िल्टरिंग हैं, और हर दूसरे बड़े प्रोवाइडर के भी। इस सवाल के लिए सीड अकाउंट और Google के Postmaster Tools इस्तेमाल करें।

क्या मैं वही टेस्ट पता दोबारा इस्तेमाल कर सकता हूं?

एक सेशन में कर सकते हैं, पर नया पता ज़्यादा साफ़ टेस्ट देता है। पुराने पतों में सप्रेशन एंट्री और पुराने मैसेज जमा हो जाते हैं, और अस्थायी सेवा पर वैसे भी इनबॉक्स करीब एक दिन बाद साफ़ हो जाता है।

मेल मेरे कैचर तक आता है पर बाहर नहीं। कहां से शुरू करूं?

कैचर बस यह दिखाता है कि आपके ऐप ने मैसेज बनाया, उसके आगे कुछ नहीं, इसलिए प्रोवाइडर के एक्टिविटी लॉग से शुरू करें। ज़्यादातर बार जवाब सैंडबॉक्स सेटिंग, सप्रेशन एंट्री, गलत क्रेडेंशियल, या ऑथेंटिकेशन का नाम लेने वाला SMTP रिजेक्शन होता है।

रीसेट लिंक कितनी देर वैध रहे?

इतनी देर कि नुकसान सीमित रहे और इतनी कि धीमा मेल पहुंच सके। कई टीमें 15 मिनट से एक घंटे के बीच कहीं तय करती हैं, पर यह आपके जोखिम और मेल कितनी जल्दी डिलीवर होता है इस पर निर्भर है, और आपके यूज़र का मेल आपके नियंत्रण से बाहर देर से आ सकता है। जो भी चुनें, एक्सपायर्ड स्थिति टेस्ट करें और लोगों को बताएं कि आगे क्या करना है।