जब भी किसी एप्लिकेशन को मेल भेजना होता है, चार पोर्ट सामने आते हैं: 25, 465, 587, और 2525। इनमें से दो submission स्टैंडर्ड हैं, 587 और 465, और 465 के बारे में सबसे ज़्यादा दोहराई जाने वाली सलाह 2018 से पुरानी हो चुकी है। पोर्ट 25 submission के लिए है ही नहीं, और 2525 एक कन्वेंशन है जिसके पीछे कोई स्टैंडर्ड नहीं है।
संक्षिप्त उत्तर: 587 को STARTTLS के साथ इस्तेमाल करें। 465 इस्तेमाल करें अगर आपका क्लाइंट सीधे TLS कनेक्शन खोलना पसंद करता है। 2525 इस्तेमाल करें अगर आपके नेटवर्क पर कुछ 587 को ब्लॉक करता है। एप्लिकेशन से मेल submit करने के लिए 25 का इस्तेमाल न करें।
हर पोर्ट वास्तव में क्या करता है?
पोर्ट दो आधारों पर भिन्न हैं: वे submission के लिए हैं या relay के लिए, और कनेक्शन में एन्क्रिप्शन कब शुरू होता है।
- 25 relay पोर्ट है। एक मेल सर्वर इसी के ज़रिए दूसरे सर्वर को संदेश सौंपता है। यह authenticated submission से पहले का है और इसमें दोनों में से किसी की भी अपेक्षा नहीं है।
- 587 submission पोर्ट है, जिसे RFC 6409 ने इसी उद्देश्य के लिए परिभाषित किया है। कनेक्शन प्लेनटेक्स्ट में खुलता है और क्रेडेंशियल भेजने से पहले
STARTTLSकमांड से TLS में अपग्रेड होता है। - 465 implicit-TLS submission पोर्ट है। TLS हैंडशेक पहले होता है और पूरा SMTP डायलॉग उसके अंदर चलता है, इसलिए कुछ भी बिना एन्क्रिप्शन के नहीं भेजा जाता। लाइब्रेरीज़ आमतौर पर इसे "SSL/TLS" या "SMTPS" लेबल करती हैं।
- 2525 को किसी स्टैंडर्ड ने SMTP के लिए असाइन नहीं किया है। प्रदाता इसे उन नेटवर्कों के लिए 587 के विकल्प के रूप में ऑफ़र करते हैं जो स्टैंडर्ड पोर्ट को ब्लॉक करते हैं।
465 और 587 के बीच का अंतर इस बारे में है कि TLS कब शुरू होता है, न कि यह कितना मज़बूत है। 465 पर कनेक्शन पहले बाइट से ही एन्क्रिप्टेड होता है। 587 पर यह एक राउंड ट्रिप बाद एन्क्रिप्टेड होता है, और सही तरीके से कॉन्फ़िगर किया गया सर्वर ऐसा होने तक AUTH को अस्वीकार कर देता है।
क्या पोर्ट 465 deprecated है?
नहीं, और यह पुरानी SMTP सलाह का सबसे आम नमूना है।
इतिहास वाकई भ्रमित करने वाला है। पोर्ट 465 को शुरुआत में TLS पर SMTP के लिए असाइन किया गया था, फिर 587 पर STARTTLS दृष्टिकोण के पक्ष में वापस ले लिया गया, और "465 is deprecated" सलाह यहीं से आती है। वह सलाह कुछ समय तक सही थी। फिर RFC 8314, जो जनवरी 2018 में प्रकाशित हुआ, ने मेल submission के लिए implicit TLS की सिफ़ारिश की और 465 को submissions सर्विस नाम के तहत इसके लिए फिर से स्थापित किया।
तो कोई पेज जो आपको बताता है कि 465 obsolete है, वह 2018 से पहले की स्थिति का वर्णन कर रहा है। 465 और 587 दोनों वर्तमान हैं। वह चुनें जिसे आपका क्लाइंट सबसे सहजता से सपोर्ट करता है, और 465 को प्राथमिकता दें अगर आप प्लेनटेक्स्ट-से-TLS अपग्रेड पर निर्भर नहीं रहना चाहते।
पोर्ट 25 क्यों ब्लॉक होता है, और मैं कैसे जाँचूँ?
आउटबाउंड पोर्ट 25 कई कंज़्यूमर ISPs और क्लाउड व होस्टिंग प्रदाताओं द्वारा ब्लॉक किया जाता है, क्योंकि किसी compromised मशीन पर एक unauthenticated relay पोर्ट वही तरीका है जिससे बल्क स्पैम भेजा जाता है। ब्लॉक हटाया जा सकता है या नहीं, यह इस पर निर्भर करता है कि किसने लगाया। कंज़्यूमर ISP आमतौर पर रेज़िडेंशियल लाइन के लिए इसे नहीं हटाएगा, जबकि क्लाउड प्रदाताओं में अंतर होता है: कुछ removal अनुरोध स्वीकार करते हैं, और कम से कम एक कोई छूट नहीं देता। दोनों में से कुछ भी मान लेने के बजाय अपने प्रदाता की प्रकाशित नीति जाँचें।
आप किसी ज्ञात मेल सर्वर से पोर्ट 25 पर कनेक्शन खोलकर और यह देखकर ब्लॉक की पुष्टि कर सकते हैं कि आपको 220 ग्रीटिंग मिलती है या टाइमआउट। मैन्युअल सेशन इसे देखने का सबसे स्पष्ट तरीका है, और telnet सेशन से SMTP कनेक्शन जाँचना इसे विस्तार से समझाता है।
अगर पोर्ट 25 ब्लॉक है, तो यह वह समस्या नहीं है जिसे हल करना है। एप्लिकेशन को वैसे भी 587 या 465 पर submit करना चाहिए।
Submission और relaying में क्या अंतर है?
Submission का मतलब है कि कोई मेल क्लाइंट या एप्लिकेशन एक नया संदेश उस सर्वर को सौंपता है जिसमें उसने authenticate किया है। Relaying का मतलब है कि एक सर्वर किसी मौजूदा संदेश को उसकी मंज़िल की ओर आगे भेजता है।
यह अंतर तय करता है कि कौन-सा पोर्ट और कौन-से नियम लागू होंगे। Submission के लिए authentication ज़रूरी है, यह सर्वर को संदेश भेजने से पहले उसे ठीक करने और साइन करने की अनुमति देता है, और यह 587 या 465 पर होता है। Relaying 25 पर सर्वरों के बीच होती है, और प्राप्तकर्ता पक्ष के स्पैम और रेपुटेशन सिस्टम इसी को आँकते हैं।
एप्लिकेशन जो अपना मेल भेजता है, वह हमेशा submission कर रहा होता है। अगर आप कुछ कॉन्फ़िगर कर रहे हैं और पोर्ट 25 की ओर बढ़ रहे हैं, तो कॉन्फ़िगरेशन सिस्टम के गलत आधे हिस्से का वर्णन कर रहा है।
Bird कौन-से पोर्ट स्वीकार करता है?
तीन, और पोर्ट 25 जानबूझकर उनमें नहीं है:
| पोर्ट | एन्क्रिप्शन |
|---|---|
| 465 | Implicit TLS (SMTPS) |
| 587 | STARTTLS |
| 2525 | STARTTLS |
587 और 2525 पर, STARTTLS चलने तक AUTH अस्वीकार कर दिया जाता है, इसलिए तीनों में से किसी पर भी क्रेडेंशियल बिना एन्क्रिप्शन के नहीं भेजे जाते। पोर्ट 25 submission के लिए ऑफ़र नहीं किया जाता।
होस्ट आपकी key के रीजन पर निर्भर करता है, जो key में ही प्रीफ़िक्स होता है: bk_eu1_... key eu1.smtp.bird.com के ज़रिए भेजती है, bk_us1_... key us1.smtp.bird.com के ज़रिए। Authentication आपकी सामान्य API key से होता है, किसी अलग SMTP क्रेडेंशियल से नहीं: username लिटरल स्ट्रिंग bird है और password key है।
SMTP पर submit किया गया मेल बिल्कुल वैसे ही ट्रीट होता है जैसे email API के ज़रिए भेजा गया मेल, उसी domain verification, DKIM signing, suppression handling, tracking, और events के साथ। SMTP पर email भेजें में पूरा कनेक्शन रेफ़रेंस है, दो एनोटेटेड सेशन हैं, एक 465 पर और एक 587 व 2525 के लिए साझा, और per-key defaults जो send को आकार देते हैं।
मैं कैसे पता करूँ कि मेरा क्लाइंट कौन-सा पोर्ट इस्तेमाल कर रहा है?
कहाँ देखना है यह सॉफ़्टवेयर पर निर्भर करता है, और पैटर्न एक जैसा है:
- एप्लिकेशन फ़्रेमवर्क इसे मेल कॉन्फ़िगरेशन में रखते हैं, आमतौर पर होस्ट के बगल में,
portयाMAIL_PORTसेटिंग के रूप में। - कंटेंट-मैनेजमेंट सिस्टम इसे किसी SMTP प्लगइन के सेटिंग्स पेज पर एन्क्रिप्शन ड्रॉपडाउन के साथ दिखाते हैं। वह ड्रॉपडाउन वही सेटिंग है जिसमें लोग गलती करते हैं: "SSL/TLS" का मतलब 465 है और "STARTTLS" का मतलब 587 या 2525, और दोनों का मेल न खाना एक ऐसा कनेक्शन बनाता है जो हैंग होता है या अस्वीकार हो जाता है, न कि कोई उपयोगी त्रुटि देता है।
- डिवाइस जैसे प्रिंटर और स्कैनर इसे नोटिफ़िकेशन या scan-to-email स्क्रीन के अंदर रखते हैं।
अगर मेल फ़ेल हो रहा है और आपको पोर्ट पर शक है, तो एप्लिकेशन कोड बदलने से पहले कनेक्शन को सीधे टेस्ट करें। मैन्युअल सेशन बताता है कि पोर्ट reachable है या नहीं, TLS negotiate होता है या नहीं, और authentication स्वीकार होता है या नहीं, जो नेटवर्क ब्लॉक को क्रेडेंशियल समस्या से अलग करता है।
संक्षेप में
587 को STARTTLS के साथ इस्तेमाल करें, जब तक कोई ख़ास वजह न हो।
यह RFC 6409 द्वारा परिभाषित submission पोर्ट है, और हर प्रमुख क्लाइंट और लाइब्रेरी इसे सपोर्ट करती है।
पोर्ट 465 deprecated नहीं है।
इसे एक बार TLS पर SMTP के लिए वापस ले लिया गया था, फिर RFC 8314 ने 2018 में इसे अनुशंसित implicit-TLS submission पोर्ट के रूप में बहाल किया। इसे obsolete बताने वाली सलाह उससे पहले की है।
पोर्ट 25 सर्वर-टू-सर्वर relay के लिए है।
होस्टिंग प्रदाता और कंज़्यूमर ISP स्पैम रोकने के लिए आउटबाउंड 25 को ब्लॉक करते हैं, और यह वह पोर्ट नहीं है जिस पर किसी एप्लिकेशन को submit करना चाहिए।
पोर्ट 2525 एक फ़ॉलबैक है जिसके पीछे कोई स्टैंडर्ड नहीं है।
कोई भी RFC इसे SMTP के लिए असाइन नहीं करता। प्रदाता इसे इसलिए ऑफ़र करते हैं क्योंकि कुछ नेटवर्क 587 को ब्लॉक करते हैं, और बाकी व्यवहार में यह 587 जैसा ही है।