दुर्गम मेल सर्वर, या स्पैम के बिना जीवन

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



सबसे आम दृष्टिकोण "आरबीएल (DNSBL) का एक गुच्छा जोड़ें और जीवन का आनंद लें।" दृष्टिकोण पूरी तरह से थोड़ा अधिक सच नहीं है। दूसरा सबसे लोकप्रिय सामग्री फ़िल्टर है, जिसे अक्सर बहुत सारे पैसे के लिए खरीदा जाता है। यह दृष्टिकोण, भी, ज्यादातर मामलों में पूरी तरह से अनुचित है।



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



वैसे: यह लेख, निश्चित रूप से, उन प्रशासकों के उद्देश्य से है जो एक गुणवत्ता स्पैम फ़िल्टर बनाना चाहते हैं। हालांकि, दूसरी ओर, इसमें उन लोगों के लिए बहुत महत्वपूर्ण जानकारी है, जिन्हें केवल मेल के साथ काम करना है, लेकिन जो इलेक्ट्रॉनिक मेल अग्रेषण प्रक्रिया की सभी जटिलताओं में निपुण हैं।



इसलिए, यदि आप अपने उपयोगकर्ताओं को स्पैम या इसके विपरीत से बचाना चाहते हैं, अगर आप चाहते हैं कि कोई व्यक्ति गलती से आपके ईमेल से उपयोगकर्ताओं की रक्षा न करे - बिल्ली का स्वागत करें।



एक संक्षिप्त टिप्पणी: लेख पोस्टफ़िक्स मेल सर्वर की स्थापना के उद्देश्य से लिखा गया था, लेकिन सामान्य तौर पर यह प्रकृति में सैद्धांतिक है। वर्णित पोस्टफ़िक्स विकल्पों को कॉन्फ़िगरेशन फ़ाइल के संबंधित * _restriction मापदंडों में निर्दिष्ट किया जाना चाहिए, विवरण के लिए, किसी भी पोस्टफ़िक्स कॉन्फ़िगरेशन गाइड का संदर्भ लें।

SMTP प्रोटोकॉल के बारे में थोड़ा सा

ईमेल में नियमित मेल के लिए कई समानताएं हैं। अब हमारे लिए सबसे महत्वपूर्ण बात यह है कि इलेक्ट्रॉनिक "लिफाफे" पर सभी जानकारी सिर्फ दो पते हैं: प्राप्तकर्ता और प्रेषक, साथ ही डाकिया का डाक टिकट जिसने लिफाफा दिया।



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



जैसा कि आपको पता होना चाहिए, एसएमटीपी के माध्यम से इंटरनेट मेल मेल सर्वरों के बीच स्थानांतरित किया जाता है। इस प्रोटोकॉल का उपयोग करने वाला कोई भी संचार तीन आवश्यक हेडर से शुरू होता है: हेलो , मेल फ्रॉम और आरसीपीटी टू । अर्थात्, किसी भी डेटा को स्थानांतरित करने के लिए शुरू करने से पहले, सर्वर पहले खुद को (HELO) प्रस्तुत करता है, फिर प्रेषक (मेल फ्रॉम) और फिर प्राप्तकर्ता पते (RCPT TO) के रिटर्न एड्रेस की रिपोर्ट करता है। ये तीन हेडर इलेक्ट्रॉनिक लिफाफे पर हस्ताक्षर हैं, और लगभग सभी स्पैम को केवल उनके विश्लेषण के आधार पर समाप्त किया जा सकता है। मेरे सर्वर पर कुछ स्थानांतरित करने के अधिकांश प्रयास मेल FROM की तुलना में आगे नहीं जाते हैं, अर्थात्, पत्रों को जांच से पहले ही स्वीकार कर लिया जाता है, जो लोड को कम करता है। अर्थात्, ट्राम से पार्सल खोलने और एंथ्रेक्स बीजाणुओं की खोज करने के बजाय, मैं तुरंत डाकिया को नरक में भेज देता हूं।



तो, स्पष्ट रूप से स्पैम वाले ईमेल को स्वीकार न करने के लिए क्या किया जाना चाहिए? क्रम में चलते हैं।

डीएनएस के बारे में थोड़ा सा

एक बार इंटरनेट की भोर में, मेल सीधे मेल पते में निर्दिष्ट नोड्स तक पहुंचाया गया था। वह है, user@domain.com को एक पत्र देने के लिए, मेल सर्वर ने domain.com IP पते की तलाश की और पाया IP द्वारा पैकेज भेजने का प्रयास किया। फिर एमएक्स रिकॉर्ड दिखाई दिए, जिन्होंने एक बार मेल इंटरएक्शन के ऐसे संगठन की अधिकांश समस्याओं को हल किया था। हालाँकि, कुछ प्रोग्राम अभी भी मेल डिलीवरी के लिए A रिकॉर्ड्स के साथ काम कर सकते हैं। लेकिन आप निश्चित रूप से, अपने डोमेन के लिए कम से कम एक एमएक्स रिकॉर्ड है, है ना?



एमएक्स रिकॉर्ड में सर्वर के पते होते हैं, जिसमें निर्दिष्ट डोमेन के लिए पत्र वितरित किए जाने चाहिए। हालांकि, स्पैम का मुकाबला करने के लिए, एक तकनीक दिखाई दी है जो आपको उन सर्वरों के डीएनएस पते में निर्दिष्ट करने की अनुमति देती है जहां से निर्दिष्ट डोमेन से पत्र आ सकते हैं। उसका नाम सेंडर पॉलिसी फ्रेमवर्क है ।



मैं प्रौद्योगिकी के सभी विवरणों के विवरण में नहीं जाऊंगा, मैं सिर्फ इतना ही कहूंगा कि TXT रिकॉर्ड



v=spf1 +mx -all







आपके डोमेन के लिए SPF सत्यापन का समर्थन करने वाले सभी ग्राहक बताएंगे कि आपके डोमेन से पत्र केवल MX रिकॉर्ड में निर्दिष्ट सर्वर से आ सकते हैं। आप सभी को लिखने के बजाय नियम लिख सकते हैं -सभी ~ के बजाय। विवरण के लिए, Google और SPF की आधिकारिक साइट से संपर्क करें।



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



पोस्टफ़िक्स में एसपीएफ़ को कैसे कॉन्फ़िगर किया जाए यह आपको Google बताएगा, आप थोक में कोई गलती नहीं कर सकते, इसलिए हमने तकनीकी विवरणों के लिए समय बर्बाद नहीं किया।



DNS के बारे में कुछ महत्वपूर्ण बिंदु हैं। सबसे अधिक संभावना है कि आप जानते हैं कि मुख्य डीएनएस रिकॉर्ड, तथाकथित ए रिकॉर्ड, नाम को आईपी पते में अनुवाद करते हैं। उनके अलावा, CNAME रिकॉर्ड हैं जो एक मौजूदा नाम के लिए एक उपनाम प्रदान करते हैं। यह इन दो प्रकार के रिकॉर्ड हैं जो संपूर्ण डोमेन नाम प्रणाली का आधार बनाते हैं।



लेकिन कुछ उपयोगकर्ताओं को पता है कि रिवर्स रिकॉर्ड भी हैं जो आईपी को एक डोमेन नाम में अनुवाद करते हैं। उन्हें पीटीआर कहा जाता है। तो, दो अलिखित (कड़ाई से बोलने वाले) नियम हैं जो फिर भी सभी का पालन करते हैं:

• प्रत्येक ए रिकॉर्ड के लिए, एक दर्पण पीटीआर रिकॉर्ड होना चाहिए, अर्थात होस्ट नाम से DNS के माध्यम से हमें आईपी मिलता है, और आईपी द्वारा - एक ही होस्ट नाम वापस।
• MX रिकॉर्ड में पता हमेशा उस होस्ट का नाम (IP नहीं) होना चाहिए, जिसके लिए A रिकॉर्ड मौजूद है। अर्थात, आप MX रिकॉर्ड में IP या अन्य उपनाम (CNAME) नहीं रख सकते।

यदि आप इन आवश्यकताओं में से एक का पालन नहीं करते हैं, तो इस तथ्य के लिए तैयार रहें कि आपके डोमेन से कम से कम एक चौथाई मेल स्पैम के रूप में पहचाना जाएगा। यह एक साधारण थीसिस के कारण है: एक भरोसेमंद प्रेषक हमेशा नियमों के अनुसार हर चीज को धुनता है, इसलिए यदि नियमों का पालन नहीं किया जाता है, तो प्रेषक पर भरोसा नहीं किया जाना चाहिए, और इसलिए इसे उससे भी स्वीकार नहीं किया जाना चाहिए।



खैर, घर पर पीटीआर चेक को सक्षम करने के लिए, विकल्प का उपयोग करें



reject_unknown_client_hostname







इसके लिए यह आवश्यक है कि जिस आईपी से कनेक्शन बनाया गया है, वह पीटीआर के माध्यम से नाम के लिए हल करता है, और यह नाम वांछित आईपी में वापस बदल जाता है।



विकल्प द्वारा निर्दिष्ट कम कड़े प्रतिबंध है



reject_unknown_reverse_client_hostname







इस मामले में, सर्वर केवल पीटीआर रिकॉर्ड की उपस्थिति के लिए जांच करेगा, लेकिन संबंधित रिकॉर्ड ए के अस्तित्व की आवश्यकता नहीं होगी।

ग्रीटिंग की जाँच करना

इसलिए, कोई आपके सर्वर पर एक पत्र भेजना चाहता था। ट्रांसमिशन ग्रीटिंग - हेलो हेडर के साथ शुरू होता है। हेलो में, प्रेषक के पूरी तरह से योग्य डोमेन नाम (FQDN) को क्रमशः इंगित किया जाना चाहिए, यदि यह मामला नहीं है, तो आप तुरंत स्वीकार करने से इनकार कर सकते हैं। पोस्टफिक्स में, इसके लिए दो विकल्प हैं:



reject_invalid_helo_hostname

reject_non_fqdn_helo_hostname







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



हालाँकि, केवल सबसे बेवकूफ स्पैमर (और MS उत्पाद, लेकिन वे, जैसा कि आप जानते हैं, लिखित कानून नहीं हैं) FQDNs नहीं भेजते हैं, अंत में, gmail.com शुरू करना मुश्किल नहीं है। इसलिए, आपको हेलो पर करीब से नज़र डालने की ज़रूरत है। ऐसा करने के लिए, विकल्प का उपयोग करें



reject_unknown_helo_hostname







जो सर्वर से पत्रों के स्वागत पर रोक लगाता है, जो एक ऐसा पता प्रतीत होता है जिसके लिए कोई A या MX रिकॉर्ड नहीं है।

प्रेषक - क्या यह भरोसे के लायक है?

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



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



reject_non_fqdn_sender

reject_unknown_sender_domain







पहला वर्तनी पते की जाँच कर रहा है, दूसरा डोमेन के अस्तित्व की जाँच कर रहा है।



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



तकनीकी रूप से, यह बहुत सरलता से लागू किया जाता है: हमारा सर्वर एक आगामी SMTP सत्र खोलता है, जो प्रेषक के पते पर एक ईमेल भेजने की कोशिश करता है। अगर यह इस पते के साथ कदम भेजने के लिए RCPT को सफलतापूर्वक पूरा करने में सफल होता है, अर्थात्। यदि प्राप्त करने वाला सर्वर अचानक यह घोषित नहीं करता है कि निर्दिष्ट मेलबॉक्स उस पर नहीं है, तो यह माना जाता है कि हमें भेजा गया पता मौजूद है। स्वाभाविक रूप से, कोई डेटा (यानी एक पत्र) सत्यापन के दौरान प्रेषित होता है, RCPT के बाद सत्र बाधित होता है।



विकल्प वापसी पते के ऐसे चेक के लिए जिम्मेदार है



reject_unverified_sender







ऊपर से यह इस प्रकार है कि किसी भी पते के लिए जहां से आप अपने डोमेन से मेल भेजते हैं, आपके सर्वर पर एक बॉक्स होना चाहिए। अन्यथा, आपके पत्र प्राप्तकर्ता के पते पर रिटर्न पते के सत्यापन को पारित नहीं करेंगे और तदनुसार, गंतव्य तक नहीं पहुंचाया जाएगा। यह सभी प्रकार के मेलिंग और अन्य चीजों के लिए सच है, जैसे एक तरफा संचार जिसमें उत्तर की आवश्यकता नहीं होती है। उन सभी पतों के लिए हमेशा मेलबॉक्‍स बनाएं जिनसे आप मेल भेजते हैं। यदि आप किसी पते पर उत्तर प्राप्त नहीं करना चाहते हैं, तो बस उसे / dev / null में पत्र भेजें, लेकिन आपको इन पत्रों को स्वीकार करना होगा ।

क्या प्राप्तकर्ता बिल्कुल मौजूद है?

तो हम लिफाफे के आखिरी हेडर के लिए - प्राप्तकर्ता को। यहां सब कुछ सरल है: सबसे पहले, यह सत्यापित करना अच्छा होगा कि हमारे पास प्रेषित जानकारी आम तौर पर एक ईमेल पता है। इसके लिए निर्देश का उपयोग किया जाता है।



reject_non_fqdn_recipient







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



smtpd_reject_unlisted_recipient = yes







या एक निषेध विकल्प जिसका एक ही प्रभाव हो:



reject_unlisted_recipient







किसी भी स्थिति में, पोस्टफिक्स प्राप्तकर्ता के लिए मेलबॉक्स नहीं होने पर स्वीकृत डोमेन के लिए मेल स्वीकार करना बंद कर देगा। हालांकि, यह प्रतिबंध उन पतों को पत्राचार अग्रेषित करने को प्रभावित नहीं करेगा जो स्वीकृत डोमेन में नहीं हैं।



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



reject_unauth_destination







यह सभी अपंजीकृत उपयोगकर्ताओं को पत्र भेजने पर प्रतिबंध लगाता है (हां, आपको एसएमटीपी प्राधिकरण को कॉन्फ़िगर करना होगा)। हमेशा इस विकल्प का उपयोग करें! अन्यथा, आप जल्दी से सभी प्रकार के DNSBL में गिर जाएंगे।

एक सबटोटल के रूप में

ठीक उसी तरह, तीन लिफ़ाफ़ा हेडर के विश्लेषण के आधार पर, आप बड़ी मात्रा में स्पैम को फ़िल्टर कर सकते हैं। हालांकि, स्पैमर चालाक होते हैं, इसलिए यह अभी भी पर्याप्त नहीं है।

Greylisting

कभी-कभी मेल सर्वर अतिभारित होते हैं और एक पत्र प्राप्त नहीं कर सकते हैं। क्या आपको लगता है कि वे इस मामले में आने वाले अनुरोधों का जवाब देते हैं? अजीब तरह से पर्याप्त है, वे जवाब देते हैं - सर्वर अस्थायी रूप से अनुपलब्ध है, बाद में फिर से प्रयास करें। इस मामले में, कोई भी सामान्य प्रेषक कभी भी यह विचार नहीं करेगा कि सभी आगामी परिणामों के साथ एक पत्र वितरित नहीं किया जा सकता है। इसके विपरीत, प्रेषक पत्र को बाद में वितरित करने का प्रयास करेगा, इसे भेजने के लिए बदले में। यह तथ्य (और बिना किसी संदेह की आवश्यकता हो सकता है!) का उपयोग बहुत प्रभावी ढंग से किया जाता है: किसी अपरिचित होस्ट से कनेक्ट करने के हर पहले प्रयास के साथ, हमारा सर्वर एक अस्थायी त्रुटि के बारे में संदेश भेजेगा, और केवल दूसरी बार पत्र को छोड़ देगा। यह लगभग सभी शेष स्पैम को तुरंत समाप्त कर देता है, क्योंकि स्पैम सर्वर लगभग एक संदेश देने के लिए एक से अधिक प्रयास कभी नहीं करते हैं (अन्यथा वे कतार अतिप्रवाह से "पतन" करेंगे)। इस तकनीक को ग्रीलिस्टिंग कहा जाता है, और आधुनिक वास्तविकताओं में इसका उपयोग करना नितांत आवश्यक है।



एक अज्ञात मेजबान से पहले कनेक्शन पर पत्र देने में देरी एक छोटा (आमतौर पर आधे घंटे से अधिक नहीं) है। यही है, अगर एक सर्वर जिसे अभी तक हमारे पोस्टफिक्स के लिए नहीं जाना जाता है, वह एक ईमेल भेजना चाहता है, तो पहली बार इसे कनेक्ट करने की कोशिश करता है, यह अस्थायी अनुपलब्धता के बारे में एक त्रुटि प्राप्त करता है। यदि सर्वर कनेक्शन को हटा देता है, तो पत्र स्वीकार कर लिया जाता है, और सर्वर को विश्वसनीय नोड्स में दर्ज किया जाता है और इसमें से आगे के अक्षर बिना देरी के प्राप्त होते हैं।



मेरा यह भी सुझाव है कि Google पर Postfix में greylisting स्थापित करना आसान है, यह आसान है और आप गलत नहीं होंगे।

ब्लोकलिस्ट, या कैसे नहीं करना है

कुछ मेल प्रशासक स्पैम को फ़िल्टर करते समय तथाकथित DNSBL (RBL) पर भरोसा करते हैं - स्पैम को देखने वाले मेजबान के ब्लैक लिस्ट। इसलिए, अपने मेल सर्वरों में कभी भी कोई DNSBL चेक न जोड़ें। इसके दो कारण हैं: पहला, और सबसे बुनियादी, इस खंड के पहले वाक्य के दूसरे भाग में निहित है। नोड्स को इन सूचियों में पूरी तरह से यादृच्छिक रूप से दर्ज किया गया है और इस बात की कोई गारंटी नहीं है कि एक सामान्य मेजबान वहां नहीं मिलेगा (जिस पर, शायद, किसी समय वायरस ने स्पैम भेजा हो, लेकिन अब वायरस पहले से ही ठीक हो चुका है, या यह आसान और बहुत अधिक वास्तविक है - एक बाहरी बड़े नेटवर्क के लिए आईपी जिसमें स्पैमर घाव है)। दूसरा कारण अधिक सामान्य है: ऊपर प्रस्तावित फ़िल्टरिंग तंत्र किसी भी DNSBL की तुलना में बहुत अधिक कुशल है और तीसरे पक्ष के असत्यापित डेटा पर निर्भर नहीं करता है।

ऊपर की ओर, या बैरिकेड्स के दूसरी तरफ से देखें

उन्होंने स्पैम को फ़िल्टर करने का तरीका सीखा, लेकिन अब मैं कोशिश करूँगा कि सभी जानकारी को एक साथ लाने की कोशिश की जाए ताकि स्पैम में न आएं।



मेल सर्वर व्यवस्थापकों के लिए:

• हमेशा MX रिकॉर्ड संदर्भ A रिकॉर्ड करें।
• मेल सर्वर के लिए रिकॉर्ड में हमेशा मिरर वाला PTR रिकॉर्ड होना चाहिए।
• HELO हैडर से होस्ट के पास A या MX रिकॉर्ड होना चाहिए।
• हमेशा एसपीएफ रिकॉर्ड बनाएं (हां, यह सिर्फ जरूरी नहीं है, बल्कि सिर्फ एक अच्छा टोंड नियम है)।
• स्वीकृत डोमेन से भेजे गए सभी पत्रों के लिए, वापसी पते के लिए एक मेलबॉक्स मौजूद होना चाहिए और मेल प्राप्त करना चाहिए।

उन लोगों के लिए जो मेल भेजते हैं (कार्यक्रमों से, साइटों आदि से):

• हमेशा मौजूदा रिटर्न पते के साथ ही मेल भेजें।
• इसके लिए SPF नियमों की जांच किए बिना कभी भी अपने नियंत्रण से परे एक डोमेन से मेल न भेजें। उदाहरण के लिए, gmail.com वर्तमान में आपको किसी भी सर्वर को अपनी ओर से पत्र भेजने की अनुमति देता है, लेकिन yandex.ru और mail.ru एसपीएफ के माध्यम से सूचित करते हैं कि तीसरे पक्ष के सर्वर से उनकी ओर से भेजने पर करीबी ध्यान आकर्षित करना चाहिए, जिसकी व्याख्या स्मार्ट स्पैम फ़िल्टर द्वारा की जाती है इस ईमेल के लिए स्पैम रेटिंग में वृद्धि के रूप में।
• अनुचित तरीके से कॉन्फ़िगर किए गए SMTP सर्वर के माध्यम से मेल कभी न भेजें। ऊपर की सूची में जूँ के लिए सर्वर की जांच करना 5 मिनट का मामला है, खुदाई या nslookup उपयोगिता आपकी मदद करेगी।

सारांश

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



हालांकि, मेल सेट करते समय इस लेख में वर्णित बातों को कभी न भूलें, क्योंकि उपरोक्त पैरामीटर केवल संदर्भ फ़िल्टर का उपयोग करने के संबंध में परिमाण के आदेश द्वारा सर्वर पर लोड को कम कर सकते हैं, और इसके अलावा उत्कृष्ट फ़िल्टरिंग प्रदान करते हैं।



UPD: सबसे पहले, महत्वपूर्ण टिप्पणियों के लिए वनव का धन्यवाद। दूसरे, शुरू में मेरे द्वारा निहित, लेकिन स्पष्ट रूप से अभी भी पूरी तरह से समझा नहीं गया है, उपरोक्त विकल्पों का सारांश:



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

लेख का वास्तविक संस्करण

इस लेख का नवीनतम और सबसे वर्तमान संस्करण उबंटू की आधिकारिक रूसी-भाषा विकी-संसाधन प्रलेखन पर है। वहां आप स्वतंत्र रूप से रखी गई संदर्भ और प्रशिक्षण सामग्री को सुधार सकते हैं और पूरक कर सकते हैं, साथ ही साथ अपना खुद का भी जोड़ सकते हैं। यदि आपके पास अन्य उबंटू उपयोगकर्ताओं को बताने के लिए कुछ है, तो एक विशाल अनुरोध - help.ubuntu.ru पर संबंधित लेख लिखें या संपादित करें। यहां तक ​​कि छोटे सुधार और परिवर्धन के साथ, आप हजारों लोगों की मदद करेंगे, और उनमें से एक, बदले में, आपके लिए कुछ उपयोगी और दिलचस्प वर्णन करेगा।