Python SMTP bidalketa: STARTTLS 587an edo TLS 465ean?

Konexio modu biek mezu bera eramaten dute relay kontu berera, eta aldea TLS non hasten den da, ez zer bidaltzen den. Bata testu garbian irekitzen da eta bandaren barruan berritzen da; bestea lehen bytetik enkriptatuta dago. Alde bakar horrek erabakitzen du relay politika zorrotz batek zer onartuko duen, tarteko gailu batek zer behatu dezakeen eta zein errore-mezu igaroko duzun arratsalde oso bat irakurtzen. Honela aukeratzen dut haien artean aplikazio batek sare pribatu batean mezua barne-bidalketa zerbitzu bati ematen dionean.

Non bereizten dira benetan bi moduak

Zeregina berbera da bi kasuetan: onartutako kontu gisa autentifikatu, baimendutako bidaltzaile bat izendatu, hartzaileak zerrendatu eta relayak erantzukizuna har dezan itxaron. Aldatzen dena eragiketen ordena da. 587 portua SMTP saio gisa hasten da testu garbian, STARTTLS iragartzen du EHLO erantzunean, eta bezeroak eskatzen badu soilik berritzen da. 465 portuak TLS eskuko keinu bat espero du edozein SMTP agindu ahoskatu aurretik.

Bidalketa eta relaya lan desberdinak dira, eta horregatik portu-zenbakiak ez dira trukagarriak diren ohiturak. RFC 6409 dokumentuak mezu-bidalketa zerbitzu propio gisa deskribatzen du, eta RFC 8314k relay moderno gehienek 465ean eskaintzen duten TLS inplizituaren aldaera biltzen du. Zure relayak bietako bat dokumentatzen badu, dokumentazio horrek aurretiazko enplegatzaile batean eskuratutako edozein lehentasunen gainetik dago.

Zer ematen dizu 587ko STARTTLSek

Berritzea SMTP elkarrizketaren barruan gertatzen da, beraz relayak iragar dezake eta bezeroak uko egin diezaioke hori gabe jarraitzeari. Pythonen, starttls() salbuespen bat botatzen du zerbitzariak luzapena eskaintzen ez duenean, eta horrek degradazio-saiakera huts egite ikusgai bihurtzen du, testu garbiko saio-hasiera isil baten ordez. Jokabide hori da moduaren aldeko argudio nagusia, eta komeni da nahita bertan fidatzea, ez ustekabean.

Esposizio-leihoa txikia baina erreala da: hasierako EHLO trukea irakurgarria da, eta berritzearen aurretik ezerk ez darama kredentzialik. Aplikazioaren azpisare baten eta barne-relay baten arteko bide pribatuan, leiho hori onargarria izan ohi da. Kontrolatzen ez duzun bide batean, horixe da talde batzuk beste moduan tematzeko arrazoia.

STARTTLS gaitasuna kentzen duen atzemate-gailu batek huts egindako bidalketa sortzen du, ez atzerakada. Hori da nahi duzun emaitza, eta bidea SMTP berridazten ari den zerbait dagoela jakiteko modurik azkarrena ere bada.

Zer aldatzen du 465eko TLS inplizituak

Ez dago testu garbiko faserk batere. Bezeroak TLS eskuko keinua egiten du socket-a ireki bezain laster, ziurtagiria bere konfiantza-biltegaren aurka balioztatzen du eta ondoren soilik trukatzen ditu EHLO, AUTH eta mezua. Ezerk ezin du saioa degradatu, ez baitago negoziatzeko testu garbiko egoerarik, eta horrek atzemate-hutsegiteen klase oso bat ezabatzen du.

Trukea diagnostikagarritasuna da. 465ean SMTP testu garbiarekin erantzuten duen relay batek, edo ziurtagiri-izen okerrarekin TLS amaitzen duen karga-balantzatzaile batek, eskuko keinuen huts egiten du eta SSL errore bat ematen dizu posta errore baten ordez. Hori gertatzen denean, arazoa aplikazioaren azpitik dago, eta mezua eraikitzeak ez du konponduko.

Bidalketa-funtzio bat, bi garraiobide

Kodea ia ez da aldatzen moduen artean, eta horregatik hautua relayaren politikatik egin behar da, ez liburutegiaren erosotasunetik. Lehenengo esportatu ezarpenak, eta gero exekutatu konfiguratutako portutik garraiobidea hautatzen duen script bakarra.

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() katea eta ostalari-izena egiaztatzen ditu, beraz CA pribatu bat konfiantza-biltegian instalatu behar da, egiaztatu gabeko testuinguru batekin saihestu beharrean. send_message() relayak baztertutako hartzaileen hiztegi bat itzultzen du; hiztegi hutsak denak onartu dituela esan nahi du. Hamabost segundoko denbora-muga abiapuntua da, ez zure sarerako doitua dagoen balio bat.

Eduki pasahitza iruditik eta erregistroetatik kanpo. Exekuzio-denboran muntatuta eta ingurunean irakurrita dagoen sekretua ondo dago; ingurunea erregistro-lerro batean islatzea ez dago ondo, ezta AUTH trukearen arazketa-arrastoa ere.

Aukeratu relayaren politikaren eta bidearen arabera, ez ohiturarekin

Hiru baldintzak erabakitzen dute. Lehenik, relayak benetan iragartzen duena: 587an soilik STARTTLSekin entzuten duen zerbitzu bat ezin da 465ean iritsi, nahiago baduzu ere TLS inplizitua. Bigarrenik, aplikazioaren eta relayaren arteko bidea nahikoa fidagarria den EHLO truke irakurgarri bat onartzeko. Hirugarrenik, erdian dagoen ezerk SMTP berridazten edo proxifikatzen duen, horrek erabakitzen baitu degradazio-arriskua teorikoa edo erreala den.

Relayak biak eskaintzen dituenean, 465 hartzen dut gainbegiratu gabe funtzionatzen duen zerbitzu baterako eta 587 lehen hedapena pertsona batek ikusten duen zerbitzu baterako, hutsegite-mezuek geruza desberdinetara jotzen dutelako soilik. Lehentasun hori nirea da eta ez da politika bat.

Aukeratu duzuna aukeratu, erregistratu portua, konfiantza-materiala eta bidaltzailearen domeinua hedapenarekin batera. Ondoren bidali baimendutako proba-mezu bat eta egiaztatu relayak onartu duela, bidalketaren emaitza eta geroagoko entrega-txostenak erregistro bereizi gisa gordez. Relayari egindako entrega zuzena aplikazioaren erantzukizunaren amaiera da, ez mezua sarrera-ontzi batera iritsi denaren froga.