Python SMTP रिले सबमिशन: 587 वर STARTTLS की 465 वर TLS?

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

दोन्ही पद्धती प्रत्यक्षात कुठे वेगळ्या होतात

दोन्ही बाबतीत कार्य एकच आहे: मंजूर खाते म्हणून प्रमाणीकरण करा, परवानगी असलेल्या प्रेषकाचे नाव सांगा, प्राप्तकर्त्यांची यादी करा, आणि रिलेने जबाबदारी घ्यावी याची वाट पाहा। जे बदलते तो क्रियांचा क्रम आहे। पोर्ट 587 स्पष्ट मजकुराच्या SMTP सत्राने सुरू होतो, EHLO उत्तरात STARTTLS ची घोषणा करतो, आणि क्लायंटने मागितल्यासच अपग्रेड होतो। पोर्ट 465 कोणतीही SMTP आज्ञा बोलण्यापूर्वी TLS हँडशेकची अपेक्षा करतो।

सबमिशन आणि रिले वेगवेगळी कामे आहेत, म्हणून पोर्ट क्रमांक अदलाबदल करण्यायोग्य सवयी नाहीत। RFC 6409 संदेश सबमिशनचे स्वतंत्र सेवा म्हणून वर्णन करतो, आणि RFC 8314 बहुतेक आधुनिक रिले 465 वर देऊ करतात त्या अंतर्निहित-TLS प्रकाराचा समावेश करतो। तुमचा रिले दोन्हींपैकी एकाचे दस्तऐवजीकरण करत असेल, तर ते दस्तऐवज मागील नियोक्त्याकडून मिळालेल्या कोणत्याही पसंतीपेक्षा वरचढ आहे।

587 वर STARTTLS तुम्हाला काय देतो

अपग्रेड SMTP संभाषणाच्या आत होते, त्यामुळे रिले त्याची घोषणा करू शकतो आणि क्लायंट त्याशिवाय पुढे जाण्यास नकार देऊ शकतो। Python मध्ये, सर्व्हर ते विस्तार देऊ करत नाही तेव्हा starttls() अपवाद फेकतो, ज्यामुळे डाउनग्रेडचा प्रयत्न शांत स्पष्ट-मजकूर लॉगिनऐवजी दृश्य अपयशात बदलतो। हे वर्तन या पद्धतीचा मुख्य युक्तिवाद आहे, आणि त्यावर योगायोगाने नव्हे तर जाणीवपूर्वक विसंबून राहणे योग्य आहे।

उघड होण्याची खिडकी लहान पण वास्तविक आहे: सुरुवातीची EHLO देवाणघेवाण वाचनीय आहे, आणि अपग्रेडपूर्वी काहीही ओळखपत्रे वाहत नाही। अनुप्रयोगाचा सबनेट आणि अंतर्गत रिले यांच्यातील खाजगी मार्गावर ती खिडकी सहसा स्वीकारार्ह असते। तुम्ही नियंत्रित न करणाऱ्या मार्गावर, काही संघ दुसऱ्या पद्धतीवर आग्रह का धरतात त्याचे कारण तेच आहे।

STARTTLS क्षमता काढून टाकणारे इंटरसेप्शन उपकरण अपयशी सबमिशन तयार करते, फॉलबॅक नाही। हाच तो निकाल आहे जो तुम्हाला हवा आहे, आणि मार्गावर काहीतरी SMTP पुन्हा लिहीत आहे हे शोधण्याचा हा सर्वात वेगवान मार्गही आहे।

465 वर अंतर्निहित TLS काय बदलतो

स्पष्ट मजकुराचा टप्पाच नाही। सॉकेट उघडताच क्लायंट TLS हँडशेक करतो, आपल्या विश्वास संग्रहाविरुद्ध प्रमाणपत्राची पडताळणी करतो, आणि त्यानंतरच EHLO, AUTH आणि संदेशाची देवाणघेवाण करतो। कोणतेही सत्र डाउनग्रेड करू शकत नाही कारण वाटाघाटीसाठी स्पष्ट-मजकूर स्थितीच नाही, आणि यामुळे इंटरसेप्शन अपयशांचा संपूर्ण वर्ग दूर होतो।

ही देवाणघेवाण निदानक्षमता आहे। 465 वर स्पष्ट-मजकूर SMTP ने उत्तर देणारा रिले, किंवा चुकीच्या प्रमाणपत्र नावाने TLS संपवणारा लोड बॅलन्सर, हँडशेकवर अपयशी होतो आणि मेल त्रुटीऐवजी तुम्हाला SSL त्रुटी देतो। असे घडल्यास, समस्या अनुप्रयोगाच्या खाली आहे, आणि कितीही संदेश रचना केली तरी ती सुटणार नाही।

एक सबमिशन फंक्शन, दोन वाहतुकी

कोड दोन्ही पद्धतींमध्ये फारसा वेगळा नाही, म्हणून निवड लायब्ररीच्या सोयीवरून नव्हे तर रिले धोरणावरून झाली पाहिजे। आधी सेटिंग्ज निर्यात करा, नंतर कॉन्फिगर केलेल्या पोर्टवरून वाहतूक निवडणारी एकच स्क्रिप्ट चालवा।

export SMTP_HOST=smtp.relay.internal
export SMTP_PORT=587
export SMTP_USER=svc-notify
export [email protected]
export [email protected]
export SMTP_PASSWORD="$(cat /run/secrets/smtp_password)"

import os, smtplib, ssl
from email.message import EmailMessage

ctx = ssl.create_default_context()
msg = EmailMessage()
msg["From"] = os.environ["MAIL_FROM"]
msg["To"] = os.environ["MAIL_TEST_TO"]
msg["Subject"] = "relay submission test"
msg.set_content("One authorized test message from the app.")

host = os.environ["SMTP_HOST"]
port = int(os.environ.get("SMTP_PORT", "587"))

if port == 465:
    client = smtplib.SMTP_SSL(host, port, context=ctx, timeout=15)
else:
    client = smtplib.SMTP(host, port, timeout=15)
    client.ehlo()
    client.starttls(context=ctx)
    client.ehlo()

with client:
    client.login(os.environ["SMTP_USER"], os.environ["SMTP_PASSWORD"])
    refused = client.send_message(msg)

print("refused:", refused)

create_default_context() साखळी आणि होस्टनाव तपासते, म्हणून खाजगी CA विश्वास संग्रहात स्थापित करावा, पडताळणी न केलेल्या संदर्भाने टाळू नये। send_message() रिलेने नाकारलेल्या प्राप्तकर्त्यांचा शब्दकोश परत करते; रिकामा शब्दकोश म्हणजे त्याने सर्वांना स्वीकारले। पंधरा सेकंदांची मुदत ही सुरुवातीचा बिंदू आहे, तुमच्या नेटवर्कसाठी ट्यून केलेले मूल्य नाही।

पासवर्ड इमेजच्या बाहेर आणि लॉगच्या बाहेर ठेवा। रनटाइमला माउंट केलेला आणि पर्यावरणात वाचला जाणारा गुप्तांश ठीक आहे; पर्यावरण लॉग ओळीत प्रतिध्वनित करणे ठीक नाही, आणि AUTH देवाणघेवाणीचा डीबग ठसाही नाही।

सवयीने नव्हे, रिले धोरण आणि मार्गाने निवडा

तीन अटी हे ठरवतात। पहिली, रिले प्रत्यक्षात काय घोषित करतो: फक्त 587 वर STARTTLS सह ऐकणारी सेवा 465 वर पोहोचता येत नाही, तुम्हाला कितीही अंतर्निहित TLS आवडत असले तरी। दुसरी, अनुप्रयोग आणि रिले यांच्यातील मार्ग वाचनीय EHLO देवाणघेवाण स्वीकारण्याइतका विश्वासार्ह आहे का। तिसरी, मध्ये काहीतरी SMTP पुन्हा लिहिते किंवा प्रॉक्सी करते का, कारण डाउनग्रेडचा धोका सैद्धांतिक आहे की प्रत्यक्ष हे त्यावर ठरते।

रिले दोन्ही देऊ करतो तेव्हा, देखरेखीशिवाय चालणाऱ्या सेवेसाठी मी 465 घेतो आणि पहिली तैनाती माणूस पाहत असलेल्या सेवेसाठी 587, कारण अपयशाचे संदेश वेगवेगळ्या स्तरांकडे निर्देश करतात एवढ्याच कारणाने। ती पसंती माझी आहे आणि ती धोरण नाही।

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