ग्रेलिस्टिंग क्या है, और मेरा ईमेल देर से क्यों पहुँचा?

ग्रेलिस्टिंग अपरिचित प्रेषकों को अस्थायी रूप से टाल देती है ताकि जाँचा जा सके कि वे फिर से प्रयास करते हैं या नहीं, इसलिए डिलीवरी किसी बाद के ऐसे प्रयास तक रुकी रहती है जो प्राप्तकर्ता की जाँचों में सफल हो।

किसी संदेश में बाद की डिलीवरी से पहले अस्थायी विफलता दिख सकती है। ग्रेलिस्टिंग इसका एक संभावित कारण है। थ्रॉटलिंग और अन्य अस्थायी समस्याएँ भी इसी श्रेणी का स्टेटस दे सकती हैं।

ग्रेलिस्टिंग कैसे काम करती है?

प्राप्तकर्ता सर्वर किसी अपरिचित भेजने वाले क्लाइंट को अस्थायी रूप से टाल देता है और जाँचता है कि क्या बाद का कोई प्रयास फिर से प्रयास माना जा सकता है।

RFC 6647 दुरुपयोग रोकने की इस तकनीक का वर्णन करता है। जो सॉफ़्टवेयर कभी फिर से प्रयास नहीं करता, वह इस जाँच से होकर डिलीवरी पूरी नहीं कर सकता।

प्राप्तकर्ता एक अस्थायी SMTP विफलता लौटाता है, जिससे संदेश को रखने और फिर से प्रयास करने की ज़िम्मेदारी भेजने वाले सिस्टम पर आ जाती है। फिर से प्रयास की जाँच पास करने पर यह बाधा हट जाती है। प्राप्तकर्ता के बाकी फ़िल्टरिंग नियम तब भी लागू रहते हैं।

प्राप्तकर्ता फिर से प्रयास को कैसे पहचानता है?

प्राप्तकर्ता नए प्रयास की जानकारी की तुलना पिछले प्रयास के रिकॉर्ड से करता है।

RFC 6647 भेजने वाले IP, एनवेलप सेंडर और पहले प्राप्तकर्ता को ट्रैक करने की सलाह देता है। एनवेलप सेंडर वह पता है जिस पर डिलीवरी विफल होने की सूचनाएँ भेजी जाती हैं।

इन पहचानकर्ताओं में बदलाव होने पर फिर से प्रयास एक नए संदेश जैसा दिख सकता है। इसलिए कई सर्वरों से भेजने पर मिलान जटिल हो सकता है, यह प्राप्तकर्ता की नीति पर निर्भर करता है।

RFC सलाह देता है कि सफल फिर से प्रयास के बाद उस IP से आगे का ट्रैफ़िक स्वीकार किया जाए। वह निष्क्रिय रिकॉर्ड की समय-सीमा समाप्त करने की भी सलाह देता है, ताकि यह अनुमति हमेशा के लिए न बनी रहे।

ग्रेलिस्टिंग कुछ अनचाहे ईमेल को क्यों रोक सकती है?

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

यह तकनीक फिर से प्रयास करने के व्यवहार की जाँच करती है। इससे यह तय नहीं होता कि संदेश की सामग्री सुरक्षित या वांछित है। फिर से प्रयास करने वाला दुरुपयोगी सॉफ़्टवेयर भी इसे पास कर सकता है।

इसलिए रिसीवर को फ़िल्टरिंग के दूसरे संकेतों की भी ज़रूरत होती है। ग्रेलिस्टिंग पार कर लेने से ऑथेंटिकेशन, सहमति या अच्छी सेंडिंग प्रतिष्ठा साबित नहीं होती।

विलंब कितनी देर तक रह सकता है?

विलंब इस पर निर्भर करता है कि सेंडर कब फिर से प्रयास करता है और रिसीवर किन प्रयासों को समय पर मानता है।

RFC 6647 सामान्य फिर से प्रयास शेड्यूल को समायोजित करने के लिए एक मिनट से 24 घंटे तक की डिफ़ॉल्ट फिर से प्रयास विंडो की सलाह देता है। यह फिर से प्रयासों को पहचानने के लिए रिसीवर की ओर की सीमा है। इससे उस अवधि के भीतर डिलीवरी का वादा नहीं होता।

उदाहरण के लिए, 30 सेकंड बाद किया गया फिर से प्रयास उस डिफ़ॉल्ट विंडो के लिए बहुत जल्दी है। 30 घंटे बाद किए गए फिर से प्रयास को नया प्रयास माना जा सकता है। योग्य फिर से प्रयास को भी रिसीवर की बाकी जाँचों से गुज़रना पड़ता है।

जो सेंडर केवल एक घंटे बाद फिर से प्रयास करता है, वह इस जाँच के ज़रिए उससे पहले डिलीवर नहीं कर सकता। दस मिनट में समाप्त होने वाले सत्यापन कोड के लिए, वह डिलीवरी कोड के बेकार हो जाने के बाद पहुँचती है।

ग्रेलिस्टिंग को किसी दूसरी विफलता से कैसे अलग करें?

रिप्लाई के विवरण और फिर से प्रयास के इतिहास का उपयोग करें। केवल अस्थायी स्टेटस कोड से ग्रेलिस्टिंग साबित नहीं होती।

अवलोकनइससे क्या साबित होता है
4xx, फिर सफल डिलीवरीएक अस्थायी विफलता दूर हो गई। ग्रेलिस्टिंग एक संभावित कारण है
समाप्ति तक बार-बार 4xx उत्तरडिलीवरी कभी पूरी नहीं हुई। उत्तर का टेक्स्ट और फिर से प्रयास का पैटर्न कारण पहचानने में मदद कर सकते हैं
5xx उत्तरउस SMTP अनुरोध के लिए स्थायी विफलता

RFC 6647 कनेक्शन समाप्त करते समय 421 और अन्य स्थितियों में 450 की चर्चा करता है। यह उत्तर के शब्द तय नहीं करता, इसलिए टेक्स्ट में ग्रेलिस्टिंग का नाम स्पष्ट रूप से होना ज़रूरी नहीं है।

स्थगित ईमेल और बाउंस अस्थायी और अंतिम परिणामों का वर्णन करते हैं।

भेजने वाले ऑपरेटर को क्या जाँचना चाहिए?

पुष्टि करें कि संदेश के लिए फिर से प्रयास किया जाता है और उसकी पहचान वाली जानकारी प्राप्तकर्ता की मिलान नीति के अनुकूल बनी रहती है।

जाँचें कि क्या फिर से प्रयास करने पर एनवेलप सेंडर बदलता है या भेजने वाला IP बदलता है। यह भी जाँचें कि क्या अलग-अलग प्राप्तकर्ता MX सर्वर फिर से प्रयास के एक ही इतिहास को पहचानते हैं।

RFC 6647 सुझाव देता है कि प्राप्तकर्ता सर्वर एक साझा ग्रेलिस्टिंग डेटाबेस रखें, क्योंकि फिर से प्रयास किसी दूसरे गंतव्य तक पहुँच सकता है। मिलान न होने पर वैध मेल बार-बार विलंबित हो सकता है।

विलंब बना रहे तो प्राप्तकर्ता ऑपरेटर को प्रयास के समय, IP और उत्तर का टेक्स्ट दें। RFC उन वैध प्रेषकों के लिए प्राप्तकर्ता द्वारा प्रबंधित अपवादों का समर्थन करता है जो ग्रेलिस्टिंग के साथ ठीक से काम नहीं करते।

क्या प्राप्तकर्ता को प्रमाणित सबमिशन को ग्रेलिस्ट करना चाहिए?

RFC 6647 सुझाव देता है कि ऑपरेटर अपनी सबमिशन सेवा के प्रमाणित क्लाइंट को ग्रेलिस्टिंग से बाहर रखें। ये क्लाइंट मेल सबमिट करने के लिए पहले ही प्रमाणीकरण कर चुके होते हैं, इसलिए यह जाँचना कि कोई अपरिचित प्रेषक फिर से प्रयास करता है या नहीं, एक टाला जा सकने वाला विलंब जोड़ता है। यह नियम उस प्राप्तकर्ता या सबमिशन सेवा पर लागू करें जो इसे नियंत्रित करती है।

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

संक्षेप में

  1. ग्रेलिस्टिंग फिर से प्रयास करने के व्यवहार को जाँचती है।

    अस्थायी विफलता भेजने वाले सर्वर से फिर से प्रयास करने को कहती है। इसका अर्थ स्थायी अस्वीकृति नहीं है।

  2. फिर से प्रयास करने पर स्वीकृति की गारंटी नहीं मिलती।

    प्रयास को प्राप्तकर्ता की समय और पहचान संबंधी जाँचों के साथ उसकी अन्य मेल नीतियों पर भी खरा उतरना होता है।

  3. समय दोनों सर्वरों पर निर्भर करता है।

    प्राप्तकर्ता की फिर से प्रयास वाली समय-सीमा और प्रेषक का शेड्यूल मिलकर देरी तय करते हैं।

  4. बार-बार टाली गई डिलीवरी की जाँच ज़रूरी है।

    कारण को ग्रेलिस्टिंग मानने से पहले जवाब का विवरण, फिर से प्रयास और प्रेषक के बदलते पहचानकर्ता जाँचें।

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया। जुड़ने के लिए तैयार।