👊 👩🏻‍⚕️ 👤 मेल व्यवस्थापक के लिए सैद्धांतिक न्यूनतम। कम्युनिगेट प्रो सर्वर पर मेल सेट करना 🛩️ 👨🏻‍🎤 👁‍🗨

यह आलेख बुनियादी जानकारी प्रदान करता है जिसे आपको अपने मेल सर्वर को प्रशासित करने के लिए जानना होगा, कुछ पाठ (~ 30%) मानक प्रोटोकॉल या व्यापक रूप से उपयोग किए जाने वाले प्रथाओं को संदर्भित करता है, और इसलिए न केवल कम्युनिट प्रो के लिए प्रासंगिक है।

व्यवस्थापक
खाते बनाएँ

सेटअप जारी रखें जहां से हमने पिछले लेख में छोड़ा था। हमने पहले ही सर्वर इंस्टॉल कर लिया है और मुख्य डोमेन का नाम चुन लिया है। उपयोगकर्ताओं को आरंभ करने का समय आ गया है हम उपयोगकर्ता-> डोमेन व्यवस्थापक पृष्ठ पर जाते हैं और मुख्य डोमेन का चयन करते हैं:

डोमेन में पहले से ही 2 सेवा उपयोगकर्ता हैं - पोस्टमास्टर - मुख्य व्यवस्थापक और pbx - की ओर से तकनीकी खाता और उसकी सेटिंग जिसमें डिफ़ॉल्ट वॉयस एप्लिकेशन लॉन्च किए गए हैं (निम्नलिखित लेखों में वॉयस फ़ंक्शन के बारे में अधिक वर्णन किया जाएगा)

एक नया उपयोगकर्ता बनाना आसान है - एक नाम दर्ज करें, उदाहरण के लिए, खाता बनाएं बटन के बगल में पाठ बॉक्स में प्राप्तकर्ता और उस पर क्लिक करें। आपको नया उपयोगकर्ता सेटिंग पृष्ठ दिखाई देगा, जहाँ आप खाते के लिए पासवर्ड दर्ज कर सकते हैं - "कम्युनिट पासवर्ड" फ़ील्ड:

स्वागत

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

डीएनएस

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

मेल डिलीवरी के लिए मुख्य प्रोटोकॉल एसएमटीपी है, इसका उपयोग सर्वर और क्लाइंट से सर्वर (लेकिन इसके विपरीत नहीं) के बीच किया जाता है।
इस मामले में, मेल भेजने के लिए सर्वर से पत्र भेजने की प्रक्रिया आगे भेजने के लिए हम पत्र के पंजीकरण (प्रस्तुत) को कॉल करेंगे, और पत्र को पते पर भेजने की प्रक्रिया (एसएमटीपी के मामले में, पते अन्य सर्वर पर हैं)।

इस प्रोटोकॉल के पूर्ण संचालन के लिए, एमएक्स प्रकार के डीएनएस रिकॉर्ड की आवश्यकता होती है। उनमें तीन फ़ील्ड हैं - मेल डोमेन का नाम, प्राथमिकता और डोमेन की सेवा करने वाले सर्वर का नाम। प्रकार का एक DNS रिकॉर्ड प्रत्येक सर्वर नाम के लिए मौजूद होना चाहिए।

सर्वोच्च प्राथमिकता वाला रिकॉर्ड मुख्य मेल सर्वर माना जाता है, और बाकी बैकअप सर्वर हैं।

उदाहरण के लिए:

>nslookup -type=MX google.com google.com MX preference = 50, mail exchanger = alt4.aspmx.l.google.com google.com MX preference = 10, mail exchanger = aspmx.l.google.com google.com MX preference = 20, mail exchanger = alt1.aspmx.l.google.com google.com MX preference = 30, mail exchanger = alt2.aspmx.l.google.com google.com MX preference = 40, mail exchanger = alt3.aspmx.l.google.com aspmx.l.google.com internet address = 74.125.143.26 alt1.aspmx.l.google.com internet address = 173.194.64.26 alt2.aspmx.l.google.com internet address = 74.125.142.26 alt3.aspmx.l.google.com internet address = 74.125.140.26 alt4.aspmx.l.google.com internet address = 173.194.74.26

ग्राहक आईपी (ग्राहक आईपी)

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

CGPro व्यवस्थापक पैनल में, क्लाइंट पते "पता सूची" प्रकार फ़ील्ड द्वारा सेट किए जाते हैं, इस प्रकार का फ़ील्ड अन्य सेटिंग्स (सेटिंग-> नेटवर्क-> क्लाइंट आईपी पृष्ठ) में भी सक्रिय रूप से उपयोग किया जाता है:

रिसीवर (श्रोताओं)

प्रत्येक प्रोटोकॉल जिसके लिए कम्युनिट प्रो प्रो कनेक्शन स्वीकार कर सकता है, उसके पास रिसीवरों की अपनी सूची है (सर्वर ऑब्जेक्ट जो सॉकेट बनाते हैं), उदाहरण के लिए एसएमटीपी (सेटिंग्स-> मेल-> एसएमटीपी-> प्राप्त करना -> "श्रोता"):

प्रत्येक रिसीवर एक विशिष्ट पोर्ट और एक विशिष्ट आईपी पते पर सॉकेट खोलता है (यह आवश्यक है ताकि CGPro एक वेब सर्वर के साथ एक ही मशीन पर खड़ा हो सके - वेब सर्वर एक आईपी पर 80 वें पोर्ट पर कब्जा कर लेता है, और दूसरी तरफ CGPro)।

डिफ़ॉल्ट रूप से, SMTP मॉड्यूल में केवल 25 वां पोर्ट कॉन्फ़िगर किया गया है, डिफ़ॉल्ट रूप से सेट किए गए 2 और जोड़ें:

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

सुरक्षा

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

इस वजह से, ऐसे कई उपाय हैं, जिन्हें कम से कम थोड़े समय के लिए करने की जरूरत है ताकि स्पैमर के जीवन को जटिल बनाया जा सके।

प्रसारण

Relaying सर्वर द्वारा एक पत्र की रसीद है जो इसे पता करने वाले को आगे भेजती है।

SMTP, सिद्धांत रूप में, आपको तृतीय-पक्ष सर्वर के लिए इच्छित ईमेल को पंजीकृत करने की अनुमति देता है, लेकिन व्यवहारिक रूप से सभी प्रेषकों के लिए इस विकल्प को बंद करना बेहतर है, क्योंकि यदि आप स्पैमर्स के नियंत्रण में एक आईपी पते से अन्य सर्वर को भेजने की अनुमति देते हैं, तो इन सर्वरों के प्रशासक सबसे अधिक संभावना है कि आप से सभी पत्र अवरुद्ध कर देंगे। ।

रिले सेटिंग्स पृष्ठ पर हैं <nobr /> सेटिंग्स-> मेल-> SMTP-> रिले और डिफ़ॉल्ट मान काफी इष्टतम हैं:

मुख्य बात यह है कि उन्हें दुर्घटना से या किसी विशेष कारण के बिना बदलना नहीं है।

हैडर चेक

SMTP पत्र प्राप्त करते समय मुख्य हेडर प्रेषक और प्राप्तकर्ता होते हैं। SMTP सत्र के एक उदाहरण पर विचार करें:

 220 mycgpro.com ESMTP CommuniGate Pro 6.0.4 is glad to see you! helo 250 mycgpro.com domain name should be qualified Mail from:sender@gmail.com 250 sender@gmail.com sender accepted rcpt to: recipient@mycgpro.com 250 recipient@mycgpro.com will leave the Internet data: 354 Enter mail, end with "." on a line by itself From: Name That Everybody See <tvoya@mama.com> Tra ta ta Prishli mne deneg na telephon! . 250 90001 message accepted for delivery

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

(MIME प्रारूप और इंटरफ़ेस में उपरोक्त के SMTP सत्र में प्राप्त पत्र)

"रिटर्न-पथ" चेक का सार यह है कि मेल से कमांड प्राप्त होने पर, सर्वर पते के डोमेन भाग को पुनः प्राप्त करता है और DNS में इस डोमेन की उपस्थिति के लिए जांच करता है। इस चेक का एक बढ़ा हुआ संस्करण भी है - रिवर्स कनेक्ट, इस चेक का उपयोग करते समय, CGPro प्रेषक सर्वर से जुड़ता है और जाँचता है कि क्या यह सर्वर मेल से कमांड के नाम के साथ प्रेषक के लिए पत्र स्वीकार करता है।

एक काफी लोकप्रिय रिटर्न-पथ चेक SPF चेक है। इसके लिए एक विशेष प्रारूप में TXT प्रकार के DNS रिकॉर्ड की आवश्यकता होती है, इन रिकॉर्डों को SPF रिकॉर्ड कहा जाता है। उनमें मेल डोमेन का नाम और IP पतों की एक सूची है जो इस डोमेन भाग के साथ अक्षरों के वैध प्रेषक हैं। उदाहरण के लिए:

 >nslookup -type=TXT google.com google.com text = "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31~all"

इस पद्धति का मुख्य नुकसान यह है कि यह केवल उन प्रेषकों के साथ काम करता है जिनके सर्वर प्रशासक इस चेक को जानते और उपयोग करते हैं। WebAdmin में, एक पृष्ठ सेटिंग्स पर मेल रिसेप्शन सेटिंग्स एकत्र की जाती हैं-> मेल-> SMTP-> प्राप्त करना:

हम आरबीएल और सामान्य ब्लैकलिस्ट पर विचार नहीं करेंगे क्योंकि इस प्रकार के चेक काफी प्रसिद्ध हैं (मुख्यतः इस तथ्य के कारण कि रूस और सीआईएस के कई लोग नियमित रूप से खुद को उनमें पाते हैं) और स्थापित करने में कोई कठिनाई नहीं होनी चाहिए।

पत्र प्रसंस्करण

पत्र की प्राप्ति पर, यह तुरंत .tmp के साथ आधार निर्देशिका के क्यू फ़ोल्डर में हार्ड ड्राइव पर लिखा जाना शुरू होता है। जैसे ही प्राप्त करने की प्रक्रिया पूरी हो जाती है, एक्सटेंशन .msg में बदल जाता है और संदेश प्राप्त करने वाले मॉड्यूल को सामान्य कतार में रख देता है।

सर्वर के अचानक रिबूट या शटडाउन के मामले में, कतार (क्यू फ़ोल्डर की .msg फाइलें) से पत्र बस फिर से उसमें डाल दिए जाते हैं।

कतार

कतारों में, एक मॉड्यूल द्वारा पंजीकृत पत्र अन्य मॉड्यूल और / या उपयोगकर्ता बक्से में वितरण की प्रतीक्षा कर रहे हैं।

संदेश कतार में निम्नलिखित घटनाएं होती हैं:

प्राप्तकर्ता के पते का विश्लेषण और अनुवाद।
हम सर्वर-वाइड नियम लागू करते हैं।
कतार फ़ाइल को एक या अधिक तार्किक कतारों में रखा जाता है (यह निर्भर करता है कि कौन से मॉड्यूल अक्षर के प्राप्तकर्ता हैं)
डोमेन या उपयोगकर्ता नियम लागू करें
प्राप्तकर्ता मॉड्यूल में प्रसंस्करण पत्र।

रूटर (रूटर)

हर बार जब कम्युनिटिंग प्रो एक मेलिंग पते का सामना करता है, तो वह राउटर मॉड्यूल से गुजरता है। व्यवस्थापक, संदेश रूटिंग (जैसे नियम, डोमेन और उपयोगकर्ता उपनाम) के प्रबंधन के लिए सहायक उपकरण के अलावा, एक शक्तिशाली उपकरण है जो सीधे एड्रेस प्रोसेसिंग प्रक्रिया को सुविधाजनक पहुंच प्रदान करता है - रूटिंग टेबल:

इस तालिका में प्रत्येक पंक्ति का प्रारूप है:

[रिले उपसर्ग:] [रिकॉर्ड प्रकार उपसर्ग:] बाएं = दाएं [; टिप्पणी]

तालिका की योजना इस प्रकार है - रिकॉर्ड्स को एक समय में देखा जाता है, ऊपर से शुरू होता है, यदि अगले एक का उपयोग पते को बदलने के लिए किया गया था, तो नए पते को शुरुआत से ही रूटिंग मॉड्यूल के इनपुट को खिलाया जाता है।

डिफ़ॉल्ट रूप से, तालिका में प्रविष्टियां सभी सर्वर संचालन और कार्यों में पाए गए पते के लिए काम करती हैं। रिकॉर्डिंग केवल 3 प्रकार के ऑपरेशनों में से एक के लिए भी काम कर सकती है यदि इसे संबंधित उपसर्ग - "मेल", "एक्सेस" और "सिग्नल" के साथ चिह्नित किया गया हो।

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

तार्किक कतार

पत्र भेजने के लिए 4 प्रकार की कतारें हैं - अन्य सर्वरों (SMTP) को, स्थानीय मेलबॉक्सों (LOCAL) को, तृतीय-पक्ष कार्यक्रमों ( PIPE ) को और मेलिंग सूचियों (LIST) को।

इनमें से प्रत्येक रेखा कई अन्य में विभाजित है। उदाहरण के लिए, प्रत्येक प्राप्तकर्ता डोमेन के लिए एक SMTP कतार है, और प्रत्येक खाते के लिए एक LOCAL कतार है। यह आपको बड़े हिस्से में पत्र देने की अनुमति देता है - एक कनेक्शन में कई पत्र या मेलबॉक्स खोलना।

नियम

नियमों को दो तरीकों से लागू किया जाता है - शुरुआत में सभी अक्षरों के लिए सर्वर नियम (डिलीवरी कतार में रखे जाने से पहले), और फिर डोमेन और उपयोगकर्ता नियम, लेकिन केवल LOCAL स्थानीय मेल कतार से पत्रों के लिए। आंतरिक डिवाइस के दृष्टिकोण से डोमेन नियम उपयोगकर्ताओं के नियमों से बिल्कुल अप्रभेद्य हैं, लेकिन सभी डोमेन खातों पर लागू होते हैं।

नियम लागू करने की ऐसी प्रणाली का अर्थ है कि डोमेन और उपयोगकर्ता नियम केवल आने वाले संदेशों को प्रभावित कर सकते हैं (आउटगोइंग संदेश LOCAL कतार में नहीं आते हैं)। अर्थात्, केवल सर्वर नियम आउटगोइंग संदेशों पर किसी भी हेरफेर को करने के लिए उपयुक्त हैं।

बक्से प्राप्त करना

जैसे भेजने के मामले में, बहुत सारे प्रोटोकॉल हैं जिनके द्वारा आप POP, IMAP, XIMSS, HTTP सर्वर (AirSync, WebUser) पर संग्रहीत मेलबॉक्सों की सामग्री प्राप्त कर सकते हैं। लेकिन मेलबॉक्स प्राप्त करने में लगभग हमेशा एक ग्राहक को जानकारी का अनुरोध करने को प्रमाणित करना शामिल होता है।

इन प्रोटोकॉल में कोई विशेष सेटिंग नहीं है - सब कुछ सही बॉक्स से बाहर काम करना चाहिए।

उपयोगकर्ता नाम को पूरी तरह से क्लाइंट सेटिंग्स में निर्दिष्ट करना उचित है, जिसमें डोमेन भाग भी शामिल है (यदि आपका क्लाइंट, आउटलुक के कुछ संस्करणों की तरह, स्वचालित रूप से '@' प्रतीक द्वारा डोमेन भाग को काट देता है, तो आप इसके बजाय '%' का उपयोग कर सकते हैं)।

संक्षेप में कहना

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

राउटर eng \ rus
नियम eng1 , eng2 \ rus1 , rus2

मेल व्यवस्थापक के लिए सैद्धांतिक न्यूनतम। कम्युनिगेट प्रो सर्वर पर मेल सेट करना

व्यवस्थापकखाते बनाएँ