पासवर्ड रीसेट ईमेल तब पहुँचना चाहिए जब उसका लिंक अभी काम कर रहा हो। रसीद में सही ऑर्डर का विवरण होना चाहिए, और फिर से प्रयास के बाद वह दोबारा नहीं आनी चाहिए।
ये आवश्यकताएँ आपके एप्लिकेशन में शुरू होती हैं और ईमेल सेवा द्वारा संदेश स्वीकार करने के बाद भी जारी रहती हैं।
ट्रांज़ैक्शनल संदेश में क्या होना चाहिए?
प्राप्तकर्ता को वह जानकारी या कार्रवाई दें जो उस घटना के लिए ज़रूरी है जिसके कारण ईमेल भेजा गया। रसीद किसी ऑर्डर की पुष्टि करती है। रीसेट संदेश फिर से एक्सेस पाने का तरीका देता है।
पहचानने योग्य प्रेषक नाम का उपयोग करें। ऐसा विषय लिखें जो घटना की पहचान कराए। जब वर्कफ़्लो को सहायता की ज़रूरत हो, तो जवाब ऐसे पते पर भेजें जिसकी निगरानी आपकी टीम करती है।
उदाहरण के तौर पर, रसीद के लिए Receipt for order 8472 जैसा विषय रखें। उसमें ऑर्डर संदर्भ, खरीदी गई वस्तुएँ और सहायता संपर्क शामिल करें। रीसेट संदेश में रीसेट कार्रवाई सबसे पहले रखें और बताएँ कि वह कब समाप्त होगी।
HTML और सादे टेक्स्ट, दोनों तरह की सामग्री का परीक्षण करें। जाँचें कि मुख्य कार्रवाई संकरी स्क्रीन पर और छवियाँ बंद होने पर भी समझ में आती है।
प्रचार सामग्री को ज़रूरी खाता संदेशों से अलग रखें। ट्रांज़ैक्शनल बनाम मार्केटिंग ईमेल बताता है कि संदेश का उद्देश्य प्राप्तकर्ता के नियंत्रणों और भेजने की नीति को कैसे प्रभावित करता है।
प्रेषकों को कैसे प्रमाणित और अलग करना चाहिए?
प्रोडक्शन ट्रैफ़िक भेजने से पहले भेजने वाले डोमेन को प्रमाणित करें। Gmail की प्रेषक आवश्यकताओं के अनुसार निजी Gmail खातों पर भेजने वाले सभी प्रेषकों के लिए SPF या DKIM ज़रूरी है। प्रतिदिन 5,000 से अधिक संदेश भेजने वाले प्रेषकों को SPF, DKIM और DMARC की ज़रूरत होती है।
परिचालन और मार्केटिंग मेल के लिए अलग-अलग प्रेषक पहचानों का उपयोग करें। Yahoo का मार्गदर्शन बल्क मार्केटिंग को ट्रांज़ैक्शनल ट्रैफ़िक से IP या DKIM साइनिंग डोमेन के आधार पर अलग रखने की सलाह देता है। इन दोनों से प्रतिष्ठा के संकेत जुड़े होते हैं, इसलिए केवल अलग From पता इन्फ्रास्ट्रक्चर को अलग नहीं करता।
भेजने की मात्रा धीरे-धीरे बढ़ाएँ। Google का मार्गदर्शन अचानक उछाल के विरुद्ध चेतावनी देता है। मात्रा बढ़ाते समय डिफ़रल और बाउंस पर नज़र रखें, ताकि प्राप्तकर्ता सर्वर ट्रैफ़िक सँभाल न पाएँ तो आप दर घटा सकें।
डिलीवरेबिलिटी चेकलिस्ट प्रमाणीकरण और प्रेषक प्रतिष्ठा से जुड़े व्यापक काम को कवर करती है।
सप्रेशन और प्राथमिकताओं को कैसे सँभालें?
दोबारा भेजना उचित है या नहीं, यह तय करने से पहले जाँचें कि प्राप्तकर्ता क्यों ब्लॉक है। मार्केटिंग से ऑप्ट-आउट और ऐसा पता जिस पर डिलीवरी संभव नहीं, दोनों के लिए अलग-अलग कार्रवाई चाहिए।
Bird की श्रेणी नीति केवल मार्केटिंग से ऑप्ट-आउट के बाद भी ट्रांज़ैक्शनल मेल की अनुमति देती है। हार्ड बाउंस, मैन्युअल सप्रेशन और सभी संदेशों पर लागू ऑप्ट-आउट दोनों श्रेणियों को ब्लॉक करते हैं।
इसलिए ट्रांज़ैक्शनल श्रेणी प्राप्तकर्ता पर लगे हर प्रतिबंध को रद्द नहीं करती। जब Bird recipient_suppressed रिपोर्ट करे, तो सप्रेशन रिकॉर्ड और प्राप्तकर्ता की प्राथमिकताएँ जाँचें। वही संदेश दोबारा भेजने से न पता ठीक होता है, न वह नीति बदलती है।
रीसेट लिंक और कोड की समय-सीमा कैसे समाप्त होनी चाहिए?
समय-सीमा उसी एप्लिकेशन में लागू करें जो लिंक या कोड की जाँच करता है। ईमेल में लिखा टेक्स्ट किसी समाप्त क्रेडेंशियल को स्वीकार होने से नहीं रोक सकता।
OWASP, एप्लिकेशन सुरक्षा समुदाय, उपयुक्त समय-सीमा वाले यादृच्छिक रूप से बनाए गए रीसेट टोकन या कोड की सलाह देता है। वह इन्हें केवल एक बार उपयोग करने की भी सलाह देता है। सफल उपयोग के बाद क्रेडेंशियल को अमान्य कर दें, ताकि वही संदेश दूसरा रीसेट अधिकृत न कर सके।
खाते की कार्रवाई के लिए एक वैधता अवधि चुनें और वह अवधि संदेश में दिखाएँ। आपके एप्लिकेशन में और डिलीवरी में लगने वाले प्रतीक्षा समय को भी ध्यान में रखें। समय-सीमा समाप्त होने के बाद मिले ईमेल में नया रीसेट माँगने का रास्ता होना चाहिए।
किसी न भेजे गए रीसेट जॉब को फिर से प्रयास करने से पहले जाँचें कि उसका क्रेडेंशियल अब भी मान्य है या नहीं। केवल इसलिए क्रेडेंशियल की समाप्ति न बढ़ाएँ कि भेजने का एक प्रयास विफल हुआ। अन्यथा फिर से प्रयास क्रेडेंशियल को आपकी चुनी हुई अवधि के बाद भी उपयोग योग्य बनाए रख सकते हैं।
रीसेट URL के लिए OWASP HTTPS और एक भरोसेमंद गंतव्य डोमेन की सलाह देता है। इनबॉक्स को अनुरोधों से भरने से रोकने के लिए वह प्रति खाते रीसेट अनुरोधों को सीमित करने की भी सलाह देता है।
फिर से प्रयास दोहरे संदेश भेजने से कैसे बचते हैं?
व्यावसायिक घटना और उसके भेजने के ऑपरेशन का एक स्थायी रिकॉर्ड रखें। दोहराई गई ऑर्डर घटना को नया रसीद जॉब बनाने के बजाय मौजूदा जॉब ढूँढना चाहिए।
अनिश्चित प्रतिक्रिया के बाद उसी API अनुरोध को फिर से प्रयास करते समय वही idempotency कुंजी उपयोग करें। Bird का idempotency अनुबंध पूरी हुई प्रतिक्रिया को तीन घंटे तक रखता है। उस अवधि के बाद उसी कुंजी वाला दूसरा अनुरोध एक और संदेश बना सकता है।
इस सीमा के कारण पुराने फिर से प्रयासों के लिए आपका अपना घटना रिकॉर्ड ज़रूरी है। सबमिशन को पूरा मानने से पहले लौटाई गई message ID को घटना के साथ सहेजें।
डिलीवरी में स्थगन, अनिश्चित API प्रतिक्रिया से अलग है। Bird स्थगित डिलीवरी को अपने-आप फिर से प्रयास करता है। हर स्थगन पर नया संदेश भेजने से दोहरे संदेश जुड़ सकते हैं, जबकि मूल संदेश अभी प्रक्रिया में होता है।
आपको किसकी निगरानी करनी चाहिए और किस पर अलर्ट सेट करने चाहिए?
हर अपेक्षित संदेश को सबमिशन तक ट्रैक करें। हर प्राप्तकर्ता का परिणाम रिकॉर्ड करें। मापें कि उपयोगकर्ता इच्छित कार्रवाई पूरी करता है या नहीं।
Bird के डिलीवरी इवेंट स्वीकृति, डिलीवरी, स्थगन, बाउंस और अस्वीकृति में अंतर करते हैं। डिलीवरी का अर्थ है कि प्राप्त करने वाले सर्वर ने संदेश स्वीकार कर लिया। इससे यह सिद्ध नहीं होता कि संदेश इनबॉक्स में पहुँचा या पढ़ा गया।
भेजने के समय और प्राप्तकर्ता के परिणाम के साथ व्यावसायिक घटना का समय भी रिकॉर्ड करें। रीसेट संदेशों के लिए बीते समय की तुलना क्रेडेंशियल की शेष अवधि से करें। पूरे हुए रीसेट अपने एप्लिकेशन में मापें। ओपन-ट्रैकिंग इवेंट यह सिद्ध नहीं करता कि किसी व्यक्ति ने संदेश पढ़ा।
वर्कफ़्लो की परिचालन सीमाओं के आसपास अलर्ट सेट करें:
- न भेजे गए जॉब अपनी समाप्ति के करीब पहुँच रहे हैं।
- विफलताएँ आपकी सामान्य सीमा से ऊपर बढ़ रही हैं।
- वेबहुक प्रोसेसिंग पीछे छूट रही है।
हर अलर्ट के लिए ऐसा ज़िम्मेदार व्यक्ति तय करें जो उस पर कार्रवाई कर सके।
| विफलता | जाँचने योग्य साक्ष्य | ज़िम्मेदार और अगली कार्रवाई |
|---|---|---|
| ऑर्डर इवेंट के बाद कोई ईमेल नहीं भेजा गया | एप्लिकेशन जॉब और इवेंट रिकॉर्ड | एप्लिकेशन टीम: छूटे हुए जॉब को इस तरह बहाल करें कि पहले से भेजा गया ईमेल दोहराया न जाए |
| सप्रेस किया गया प्राप्तकर्ता | अस्वीकृति का कारण, सप्रेशन और प्राथमिकताएँ | सपोर्ट या सेंडिंग टीम: अगला प्रयास करने से पहले ब्लॉक की जाँच करें |
| बढ़ते डिलीवरी डेफ़रल | प्राप्तकर्ता इवेंट और भेजने की मात्रा | सेंडिंग टीम: प्राप्त करने वाले सर्वरों की प्रतिक्रियाएँ जाँचें और ट्रैफ़िक में अचानक उछाल को कम करें |
| पहुँचने तक रीसेट की समय-सीमा समाप्त | क्रेडेंशियल की समय-सीमा और इवेंट टाइमस्टैम्प | एप्लिकेशन टीम: देरी की जाँच करें और नया अनुरोध करने का रास्ता दें |
| दोहराई गई वेबहुक डिलीवरी | वेबहुक पहचानकर्ता और प्रोसेसिंग रिकॉर्ड | एप्लिकेशन टीम: उस इवेंट के लिए पहले से पूरा हो चुका काम छोड़ दें |
इवेंट स्वीकार करने से पहले वेबहुक सिग्नेचर सत्यापित करें। Bird की वेबहुक गाइड डुप्लिकेट हटाने के लिए webhook-id का उपयोग करती है, ताकि दोबारा भेजी गई सूचना से आपके एप्लिकेशन का काम दोहराया न जाए।
Bird से भेजने से पहले आपको क्या जाँचना चाहिए?
लाइव खाता संदेशों के लिए इस्तेमाल करने से पहले वर्कफ़्लो को सबमिशन, प्राप्तकर्ता के परिणाम और एप्लिकेशन रिकवरी तक टेस्ट करें।
- भेजने वाले डोमेन को सत्यापित करें। जाँचें कि ऑपरेशनल ट्रैफ़िक इच्छित पहचान और पूल का उपयोग करता है।
- टेम्पलेट प्रकाशित करें। प्रतिनिधि पैरामीटर के साथ रसीद का विवरण या रीसेट कार्रवाई टेस्ट करें।
- ऑपरेशनल सामग्री के लिए
category: "transactional"सेट करें। प्रलेखित सप्रेशन और प्राथमिकता नीति लागू करें। - बिज़नेस इवेंट का रिकॉर्ड और idempotency कुंजी सुरक्षित रखें। send endpoint से लौटाई गई message ID भी रखें।
- मेल सैंडबॉक्स से विफलता प्रबंधन को आज़माएँ। इसके सिम्युलेटेड परिणाम किसी असली इनबॉक्स तक पहुँचे बिना सामान्य इवेंट और webhook मार्गों से गुज़रते हैं।
- ईमेल लॉग में हर प्राप्तकर्ता की टाइमलाइन देखें। पुष्टि करें कि आपका एप्लिकेशन वही परिणाम संभालता है और अलर्ट उनके ज़िम्मेदार लोगों तक पहुँचाता है।