Python SMTP રિલે સબમિશન: 587 પર STARTTLS કે 465 પર TLS?

બંને કનેક્શન મોડ એક જ સંદેશ એક જ રિલે ખાતામાં પહોંચાડે છે, અને ફરક એ છે કે TLS ક્યાં શરૂ થાય છે, શું મોકલાય છે તે નહીં. એક સ્પષ્ટ ટેક્સ્ટમાં ખૂલે છે અને બેન્ડની અંદર અપગ્રેડ થાય છે; બીજું પહેલા બાઇટથી જ એન્ક્રિપ્ટ થયેલું હોય છે. એ જ એક ફરક નક્કી કરે છે કે કડક રિલે નીતિ શું સ્વીકારશે, વચ્ચેનું ઉપકરણ શું જોઈ શકશે, અને કયો ભૂલ સંદેશ તમે આખી બપોર વાંચશો. ખાનગી નેટવર્ક પરની એપ્લિકેશન આંતરિક સબમિશન સેવાને સંદેશ સોંપે ત્યારે હું આ બે વચ્ચે કેવી રીતે પસંદગી કરું છું તે આ રહ્યું.

બે મોડ ખરેખર ક્યાં અલગ પડે છે

કાર્ય બંને કિસ્સામાં સરખું જ છે: મંજૂર ખાતા તરીકે પ્રમાણીકરણ કરો, મંજૂર પ્રેષકનું નામ આપો, પ્રાપ્તકર્તાઓની યાદી બનાવો, અને રિલે જવાબદારી સ્વીકારે તેની રાહ જુઓ. જે બદલાય છે તે ક્રિયાઓનો ક્રમ છે. પોર્ટ 587 સ્પષ્ટ ટેક્સ્ટ SMTP સત્ર તરીકે શરૂ થાય છે, EHLO જવાબમાં STARTTLS જાહેર કરે છે, અને ક્લાયન્ટ માગે તો જ અપગ્રેડ થાય છે. પોર્ટ 465 કોઈપણ SMTP આદેશ બોલાય તે પહેલાં TLS હેન્ડશેકની અપેક્ષા રાખે છે.

સબમિશન અને રિલે અલગ કામ છે, તેથી પોર્ટ નંબરો અદલાબદલી કરી શકાય તેવી ટેવો નથી. RFC 6409 સંદેશ સબમિશનને પોતાની સેવા તરીકે વર્ણવે છે, અને RFC 8314 એ ગર્ભિત-TLS પ્રકારને આવરી લે છે જે મોટાભાગના આધુનિક રિલે 465 પર આપે છે. જો તમારો રિલે બેમાંથી એકનું દસ્તાવેજીકરણ કરે છે, તો તે દસ્તાવેજ પાછલા નોકરીદાતા પાસેથી મળેલી કોઈપણ પસંદગી પર પ્રાધાન્ય ધરાવે છે.

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, ફક્ત એટલા માટે કે નિષ્ફળતાના સંદેશા અલગ સ્તરો તરફ ઇશારો કરે છે. એ પસંદગી મારી છે અને તે નીતિ નથી.

તમે ગમે તે પસંદ કરો, પોર્ટ, વિશ્વાસ સામગ્રી અને પ્રેષકનું ડોમેન તૈનાતી સાથે નોંધો. પછી એક અધિકૃત પરીક્ષણ સંદેશ મોકલો અને ખાતરી કરો કે રિલેએ તે સ્વીકાર્યો, સબમિશન પરિણામ અને પછીના કોઈપણ ડિલિવરી રિપોર્ટને અલગ રેકોર્ડ તરીકે રાખો. રિલેને સફળ સોંપણી એ એપ્લિકેશનની જવાબદારીનો અંત છે, સંદેશ ઇનબોક્સ સુધી પહોંચ્યો તેનો પુરાવો નહીં.