पोस्टफ़िक्स reject_unknown_reverse_client_hostname: डिफ़ॉल्ट अज्ञात_client_reject_code (450) को 550 में बदलें। क्यों / जब मुझे नहीं करना चाहिए?

Question

SPAM के खिलाफ दैनिक लड़ाई में, कई बार ऐसा हुआ है जब मुझे जंगली इंटरनेट से जुड़ने वाले ग्राहकों से DNS आवश्यकताओं को भारी रूप से लागू करने के लिए लुभाया गया है।

विस्तार से, मैंने अपने smtpd_client_restrictions सेक्शन में reject_unknown_reverse_client_hostname सेटिंग जोड़ी होगी , जैसे कि:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

वैसे भी, मैंने नोट किया है कि इस तरह के प्रतिबंध को मारते समय, पोस्टफ़िक्स का व्यवहार unknown_client_reject_code450 "के लिए डिफ़ॉल्ट मान के रूप में काफी" नरम " होता है। इसलिए, क्लाइंट को रिट्रीट रखने के लिए आमंत्रित किया जाता है।

550 प्रतिक्रिया के लिए जांच करते समय, मैं आधिकारिक पोस्टफिक्स प्रलेखन पर निम्नलिखित कथन से मिला :

मैं पूरी तरह से पूरे आरएफसी 5321 के बारे में एक विशेषज्ञ नहीं हूं , लेकिन आरएफसी 821 को जानने के लिए पर्याप्त पुराना होने के नाते , मैं वास्तव में नहीं देखता कि क्यों, 450 के बजाय 550 प्रतिक्रिया, अधिकतम एसएमटीपी स्तर पर मेरे पोस्टफिक्स उदाहरण को प्रभावित कर सकती है ( RFC अनुपालन को तोड़ना), स्पष्ट रूप से यह देखते हुए कि अस्थायी त्रुटियों के मामले में, पोस्टफिक्स स्पष्ट सेटिंग की परवाह किए बिना 450 के साथ चिपकेगा।

तो, क्या कोई मुझे यह समझने में मदद कर सकता है कि इस तरह के प्रतिस्थापन के साथ समस्या क्या है?

---

पुनश्च: इस बीच, मैं एक "आराम" प्रतिबंध के साथ समाप्त हुआ:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

Answer 1

मैं दो व्यावहारिक उत्तरों के साथ शुरुआत करूंगा

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

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

इन लोगों के अलावा, एक उत्तर भी है जो सिद्धांत और RFC के लिए अधिक है

RFC धारा 4.2.1 में कहता है। उस:

अंगूठे का एक नियम यह निर्धारित करने के लिए कि क्या उत्तर 4yz या 5yz श्रेणी में फिट बैठता है (नीचे देखें) यह है कि उत्तर 4yz हैं यदि वे कमांड के रूप में या प्रेषक या रिसीवर के गुणों में परिवर्तन किए बिना सफल हो सकते हैं (जो कि) कमांड को पहचान के रूप में दोहराया जाता है और रिसीवर एक नया कार्यान्वयन नहीं करता है)।

रिवर्स लुकअप विफलता के मामले में, यह संभव होगा कि संदेश स्वयं किसी संदेश में बदलाव के बिना स्वीकार्य हो, बशर्ते कि DNS त्रुटि तय हो। इसलिए, यह एक अस्थायी त्रुटि होनी चाहिए।

ऐसे मामले में जहां संदेश स्पैम नहीं है, भेजने वाले संदेशवाहक sadadmin त्रुटि संदेश को नोटिस कर सकते हैं और DNS समस्या को ठीक कर सकते हैं, ताकि उपयोगकर्ता को हस्तक्षेप किए बिना और संदेश को फिर से भेजने के बिना संदेश को वितरित किया जा सके। और जब तक कि ईमेल भेजने वाला उपयोगकर्ता मेलस्वर और / या उसकी DNS प्रविष्टियों का प्रभारी न हो, भले ही उन्हें सीधे स्थायी उछाल मिले, वे इसके साथ कुछ भी करने में सक्षम नहीं होंगे - इसके विपरीत जैसे कि एक गलत वर्तनी का मामला पता।

बेशक, आप किसी भी कारण से किसी भी ईमेल को अस्वीकार करने के लिए अभी भी हमेशा अपने अधिकारों के भीतर हैं।

Comments

मैंने DNS की अस्थायी समस्याओं के बारे में सोचा था लेकिन .... ऐसा लगता है कि उन्हें कोई मुद्दा नहीं होना चाहिए ... " SMTP सर्वर हमेशा 450 के साथ उत्तर देता है जब अस्थायी त्रुटि स्थिति के कारण मैपिंग विफल हो जाती है "। इनमें अस्थायी DNS लुकअप समस्याएं शामिल होनी चाहिए। क्या तुम नहीं? दूसरे बिंदु (बोटनेट, ग्रीलिस्टिंग, आदि) के लिए, यह उचित लगता है: जब ग्राहक एक उचित कतार तंत्र को लागू नहीं करते हैं, तो 4XX प्रतिक्रिया 5XX के एक ही प्रभाव का उत्पादन करती है। वैसे भी मुझे अभी भी याद है कि इसका आरएफसी स्तर पर प्रभाव क्यों है।

— दामियानो वेरज़ुल्ली

@DamianoVerzulli यह तब लागू होगा जब मैपिंग में कोई त्रुटि हो, तब नहीं जब DNS गलत नाम वापस करने के लिए गलत है, और यह बाद में ठीक हो जाता है। किसी भी स्थिति में, मैंने RFC से संबंधित मुद्दों पर थोड़ा विस्तार किया है।

— जेनी डी

उचित RFC अनुभाग को इंगित करने के लिए धन्यवाद। मैं इस पर ध्यान केंद्रित कर रहा हूँ: "उत्तर 4yz अगर वे सफल हो सकता है, तो बार-बार कर रहे हैं बिना किसी परिवर्तन के आदेश के रूप में या गुण में की प्रेषक या रिसीवर"। मेरा पहला अनुमान है कि क्लाइंट के DNS होस्टनाम, साथ ही इसके रिवर्स DNS मैपिंग, प्रेषक के गुण हैं । क्या तुम नहीं? अन्यथा मैं यह नहीं देख सकता कि प्रेषक संपत्ति क्या हो सकती है। (BTW: कृपया मेरी टिप्पणियों को व्यक्तिगत रूप से न लें। मैं वास्तव में इस चर्चा में दिलचस्पी रखता हूं और वास्तव में आपके बिंदुओं की सराहना करता हूं! टिप्पणी के लिए धन्यवाद!)।

— दामियानो वेरज़ुल्ली

@DamianoVerzulli DNS hostname भेजने वाले की संपत्ति नहीं है और मेल करने वाले कॉन्फ़िगरेशन के भीतर बदला नहीं जा सकता। यह आधिकारिक DNS सर्वर द्वारा नियंत्रित किया जाता है, जो आमतौर पर एक ही सर्वर, ईमेल सर्वर का बहुत कम हिस्सा नहीं होता है। कभी-कभी इसे एक ही संगठन के भीतर भी नियंत्रित नहीं किया जाता है। (मैं इसे व्यक्तिगत रूप से नहीं ले रहा हूं - यह तथ्यों की चर्चा है, बिना किसी विज्ञापन होमिनम तर्कों के, व्यक्तिगत रूप से लेने के लिए कुछ भी नहीं है! मैं मानता हूं कि यह बहुत दिलचस्प है और मुझे नहीं लगता कि यह स्पष्ट है, यह होने के लिए एक मामला है। दूसरे पक्ष के लिए भी बनाया गया।)

— जेनी डी