2010-08-14 21 views
8

सभी क्लाइंट के लिए एमटीए संचार के लिए पोर्ट 587 का उपयोग करने की बढ़ती प्रवृत्ति है। यह एक मानक ट्रैक आरएफसी में है: http://www.ietf.org/rfc/rfc2476.txtमुझे एसएमटीपी संचार के लिए पोर्ट 587 का उपयोग करने के लिए डेवलपर्स को क्यों मनाने चाहिए?

मेरा प्रश्न "क्यों?" है। एक ही सर्वर पर चल रहे एक एसएमटीपी सर्वर के 2 उदाहरण क्यों हैं, यदि वे दोनों एक ही काम करते हैं? व्यवस्थापक के रूप में समस्या निवारण के लिए मुझे 2 चीजें देने के अलावा, यह कौन सी सुरक्षा सुविधा प्रदान करती है।

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

बस लगता है कि हम अपने लिए अधिक काम पैदा कर रहे बल्कि उसके बाद समस्या को हल करने और प्रमाणीकृत करने एसएमटीपी

उत्तर

6

कृपया देखें।

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

मुझे लगता है कि आप याद कर रहे हैं पोर्ट 587 है केवल प्रमाणीकृत है। आपको पोर्ट 587 पर अनधिकृत ईमेल स्वीकार नहीं करना चाहिए, भले ही प्राप्तकर्ता स्थानीय है या नहीं। हम (आईएसपी के रूप में), डायरेक्ट-टू-एमएक्स स्पैम को रोकने के लिए आउटबाउंड पोर्ट 25 को ब्लॉक करें। उदाहरण के लिए बोतलबंद कंप्यूटर से। पोर्ट 25 पर आउटबाउंड भेजने से हमारे आवासीय/गतिशील उपयोगकर्ता आधार को अवरुद्ध करने में (हम अभी भी पोर्ट 25 पर हमारे आईपी स्पेस से अनधिकृत रिले की अनुमति देते हैं), दुरुपयोग रिपोर्ट में 85 +% प्रतिशत गिरावट आई है।

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

यदि आप या तो एमयूए या एमटीए लिख रहे हैं, तो आपको दोनों का समर्थन करने की आवश्यकता है, और एमयूए के मामले में या कुछ ईमेल भेजता है, तो इसे 587 को टीएलएस का प्रयास करना चाहिए, और एसएमटीपी ऑथ, और केवल वापस असफल होना चाहिए 465, 25 अगर वह विफल रहता है।

+0

पोर्ट 465 के आस-पास क्या अपेक्षाएं हैं? एसएमटीपी ऑथ भी? – LamonteCristo

+0

465 एसएसटीपी एसएसटीपी के तहत है। जबकि 25 और 587 अनएन्क्रिप्टेड प्रारंभ करते हैं, और स्टार्टल्ट का उपयोग कर सकते हैं (यदि एक एसएसएल एन्क्रिप्टेड कनेक्शन सक्षम करने के लिए समर्थित है)। पोर्ट 465 शुरुआत से एसएसएल है। प्रमाणीकरण वैकल्पिक है, सर्वर निर्भर है। – Doon

+0

धन्यवाद, यह आपके स्पष्टीकरण के साथ 'क्लिक किया'। यह मेरे लिए नहीं हुआ कि सभी इनबाउंड एसएमटीपी सर्वरों में एमएक्स होना चाहिए, जबकि सभी पोर्ट 587 सर्वर इतने जुड़े नहीं हैं। यह बंदरगाह 25 के साथ चिंता का पृथक्करण विभाजित करता है। – LamonteCristo

10

के साथ शुरू हो रहा आरएफसी के माध्यम से एक त्वरित पढ़ने था और उनकी सोच दो क्षेत्रों में एसएमटीपी दुनिया विभाजित किया गया है: मेल परिवहन (यही वह है जो एसएमटीपी विकसित किया गया था) और मेल जमा कर रहा है।

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

ऐसा लगता है कि उन्हें लगता है कि यह दो सर्वर प्रकारों को आसान और शायद और भी सुरक्षित बनाएगा। आरएफसी बताता है कि एमटीए की तुलना में एमएसए में क्या अलग होना चाहिए। उदाहरण के लिए, आरएफसी प्रमाणीकरण के उपयोग को अनिवार्य करता है जबकि मूल एसएमटीपी प्रोटोकॉल में यह नहीं था (एसएमटीपी AUTH बाद में जोड़ा गया था, यह बहुत आरएफसी 2476 द्वारा लगता है, हालांकि एसएमटीपी AUTH स्वयं बाद में आरएफसी 2554 में निर्दिष्ट किया गया है जिसे बदल दिया गया है आरएफसी 4954 द्वारा)।

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

+0

+1 महान जानकारी के लिए, धन्यवाद डार्क डस्ट – LamonteCristo