एक संदेश बाद में डिलीवर होने से पहले अस्थायी विफलता दिखा सकता है। Greylisting एक संभावित कारण है। थ्रॉटलिंग और अन्य अस्थायी समस्याएँ भी वही स्टेटस क्लास उत्पन्न कर सकती हैं।
Greylisting कैसे काम करती है?
प्राप्तकर्ता एक अपरिचित भेजने वाले क्लाइंट को अस्थायी रूप से स्थगित करता है और जाँचता है कि बाद का प्रयास पुनः प्रयास के रूप में योग्य है या नहीं।
RFC 6647 इस दुरुपयोग-रोधी तकनीक का वर्णन करता है। जो सॉफ़्टवेयर कभी फिर से प्रयास नहीं करता, वह इस जाँच से डिलीवरी पूरी नहीं कर सकता।
प्राप्तकर्ता एक अस्थायी SMTP विफलता लौटाता है, जिससे संदेश को बनाए रखने और फिर से प्रयास करने की ज़िम्मेदारी भेजने वाले सिस्टम पर रहती है। पुनः प्रयास की जाँच पास करने से वह बाधा दूर हो जाती है। प्राप्तकर्ता के अन्य फ़िल्टरिंग नियम फिर भी लागू होते हैं।
प्राप्तकर्ता पुनः प्रयास को कैसे पहचानता है?
प्राप्तकर्ता नए प्रयास की जानकारी की तुलना पहले वाले प्रयास के रिकॉर्ड से करता है।
RFC 6647 भेजने वाले IP, envelope sender और पहले प्राप्तकर्ता को ट्रैक करने की सिफ़ारिश करता है। Envelope sender वह पता है जो डिलीवरी-विफलता सूचनाओं के लिए उपयोग होता है।
इन पहचानकर्ताओं में बदलाव से पुनः प्रयास एक नए संदेश जैसा दिख सकता है। इसलिए कई सर्वरों से भेजना प्राप्तकर्ता की नीति के अनुसार मिलान को जटिल बना सकता है।
RFC सफल पुनः प्रयास के बाद उस IP से आगे के ट्रैफ़िक की अनुमति देने की सिफ़ारिश करता है। यह निष्क्रिय रिकॉर्ड की समय-सीमा समाप्त करने की भी सिफ़ारिश करता है, ताकि अनुमति को अनिश्चित काल तक बनाए रखने की ज़रूरत न हो।
Greylisting कुछ अनचाहे मेल को क्यों रोक सकती है?
यह उस भेजने वाले सॉफ़्टवेयर को रोकती है जो एक प्रयास करता है और अस्थायी विफलता पर छोड़ देता है।
यह तकनीक फिर से प्रयास करने के व्यवहार की जाँच करती है। यह स्थापित नहीं करती कि संदेश की सामग्री सुरक्षित या वांछित है। दुरुपयोगकारी सॉफ़्टवेयर जो फिर से प्रयास करता है, वह भी इसे पास कर सकता है।
इसलिए प्राप्तकर्ता को अन्य फ़िल्टरिंग सिग्नल की आवश्यकता होती है। Greylisting सफलतापूर्वक पास करना प्रमाणीकरण, सहमति या अच्छी भेजने वाली प्रतिष्ठा स्थापित नहीं करता।
देरी कितनी लंबी हो सकती है?
देरी इस पर निर्भर करती है कि प्रेषक कब फिर से प्रयास करता है और प्राप्तकर्ता किन प्रयासों को समय पर स्वीकार करता है।
RFC 6647 सामान्य पुनः प्रयास शेड्यूल को समायोजित करने के लिए एक मिनट से 24 घंटे तक की डिफ़ॉल्ट पुनः प्रयास विंडो की सिफ़ारिश करता है। यह पुनः प्रयास पहचानने के लिए प्राप्तकर्ता-पक्ष की सीमा है। यह उस अवधि में डिलीवरी का वादा नहीं करती।
उदाहरण के लिए, 30 सेकंड बाद का पुनः प्रयास उस डिफ़ॉल्ट विंडो के लिए बहुत जल्दी है। 30 घंटे बाद के पुनः प्रयास को नया प्रयास माना जा सकता है। योग्य पुनः प्रयास को भी प्राप्तकर्ता की अन्य जाँचों का सामना करना पड़ता है।
जो प्रेषक केवल एक घंटे बाद फिर से प्रयास करता है, वह इस जाँच से उससे पहले डिलीवर नहीं कर सकता। दस मिनट बाद समाप्त होने वाले सत्यापन कोड के लिए, वह डिलीवरी कोड के अनुपयोगी होने के बाद पहुँचती है।
Greylisting को किसी अन्य विफलता से कैसे अलग करें?
रिप्लाई विवरण और पुनः प्रयास इतिहास का उपयोग करें। केवल एक अस्थायी स्टेटस कोड greylisting साबित नहीं करता।
| अवलोकन | यह क्या स्थापित करता है |
|---|---|
4xx, फिर सफल डिलीवरी | एक अस्थायी विफलता समाप्त हुई। Greylisting एक संभावित कारण है |
बार-बार 4xx रिप्लाई, समय-सीमा समाप्ति तक | डिलीवरी कभी पूरी नहीं हुई। रिप्लाई टेक्स्ट और पुनः प्रयास पैटर्न कारण पहचानने में सहायता कर सकते हैं |
5xx रिप्लाई | उस SMTP अनुरोध के लिए एक स्थायी विफलता |
RFC 6647 कनेक्शन समाप्त करते समय 421 और अन्यथा 450 पर चर्चा करता है। यह रिप्लाई शब्दों को निर्धारित नहीं करता, इसलिए टेक्स्ट में greylisting का स्पष्ट नाम होना ज़रूरी नहीं है।
स्थगित ईमेल और बाउंस अस्थायी और अंतिम परिणामों का वर्णन करते हैं।
भेजने वाले ऑपरेटर को क्या जाँचना चाहिए?
पुष्टि करें कि संदेश फिर से प्रयास किया गया है और उसकी पहचान जानकारी प्राप्तकर्ता की मिलान नीति के लिए उपयुक्त बनी हुई है।
जाँचें कि पुनः प्रयास envelope sender बदलते हैं या भेजने वाले IP के बीच स्विच होते हैं। यह भी जाँचें कि क्या अलग-अलग प्राप्तकर्ता MX सर्वर समान पुनः प्रयास इतिहास पहचानते हैं।
RFC 6647 सिफ़ारिश करता है कि प्राप्तकर्ता सर्वर एक greylisting डेटाबेस साझा करें, क्योंकि पुनः प्रयास किसी अलग गंतव्य तक पहुँच सकता है। मेल न मिलने पर वैध मेल बार-बार देरी से पहुँच सकता है।
जब देरी बनी रहे तो प्राप्तकर्ता ऑपरेटर को प्रयास समय, IP और रिप्लाई टेक्स्ट प्रदान करें। RFC उन वैध प्रेषकों के लिए प्राप्तकर्ता-प्रबंधित अपवादों का समर्थन करता है जो greylisting के साथ ठीक से काम नहीं करते।
क्या प्राप्तकर्ता को प्रमाणित सबमिशन पर greylisting लागू करनी चाहिए?
RFC 6647 सिफ़ारिश करता है कि ऑपरेटर अपनी सबमिशन सेवा के प्रमाणित क्लाइंट को greylisting से बाहर रखें। वे क्लाइंट मेल सबमिट करने के लिए पहले से प्रमाणित हो चुके हैं, इसलिए यह जाँचना कि कोई अपरिचित प्रेषक फिर से प्रयास करता है या नहीं, एक टालने योग्य देरी जोड़ता है। इस नियम को उस प्राप्तकर्ता या सबमिशन सेवा पर लागू करें जो इसे नियंत्रित करती है।
भेजने वाले प्लेटफ़ॉर्म का उपयोग करने वाले एप्लिकेशन के लिए, संदेश का डिलीवरी परिणाम देखें। एक और एप्लिकेशन सेंड बनाना पहले प्रयास के greylisting मिलान को ठीक नहीं करता। इससे डुप्लिकेट बन सकते हैं।
संक्षेप में
Greylisting फिर से प्रयास करने के व्यवहार की जाँच करती है।
एक अस्थायी विफलता भेजने वाले सर्वर से दोबारा प्रयास करने के लिए कहती है। यह कोई स्थायी अस्वीकृति स्थापित नहीं करती।
फिर से प्रयास करने से स्वीकृति की गारंटी नहीं होती।
प्रयास को प्राप्तकर्ता की समय और पहचान जाँचों के साथ-साथ उसकी अन्य मेल नीतियों को भी पूरा करना होगा।
समय दोनों सर्वरों पर निर्भर करता है।
प्राप्तकर्ता की पुनः प्रयास विंडो और प्रेषक का शेड्यूल मिलकर देरी तय करते हैं।
बार-बार स्थगन की जाँच ज़रूरी है।
कारण greylisting है यह निष्कर्ष निकालने से पहले रिप्लाई विवरण, पुनः प्रयास और बदलते प्रेषक पहचानकर्ताओं की जाँच करें।