Mõlemad ühendusrežiimid kannavad sama sõnumi samasse relee kontole ja erinevus on selles, kust TLS algab, mitte selles, mida saadetakse. Üks avaneb lihttekstina ja uuendatakse kanali sees; teine on krüpteeritud esimesest baidist. See üks erinevus otsustab, mida range relee poliitika aktsepteerib, mida vahepealne seade näha saab ja millist veateadet sa terve pärastlõuna loed. Nii valin nende vahel, kui privaatvõrgus olev rakendus annab sõnumi üle sisemisele saatmisteenusele.

Kus need kaks režiimi tegelikult lahku lähevad

Ülesanne on mõlemal juhul sama: autentida heakskiidetud kontona, nimetada lubatud saatja, loetleda adressaadid ja oodata, kuni relee vastutuse üle võtab. Muutub toimingute järjekord. Port 587 algab lihttekstilise SMTP-seansina, teatab EHLO vastuses STARTTLS-ist ja uuendatakse ainult siis, kui klient seda palub. Port 465 eeldab TLS-kätlust enne, kui ükski SMTP-käsk välja öeldakse.

Edastus ja relee on erinevad tööd, mistõttu pordi numbrid ei ole vahetatavad harjumused. RFC 6409 kirjeldab sõnumite edastamist omaette teenusena ja RFC 8314 hõlmab kaudse TLS-i varianti, mida enamik kaasaegseid releesid pordil 465 pakub. Kui sinu relee dokumenteerib ühe kahest, on see dokumentatsioon ülimuslik mis tahes eelistuse ees, mille omandasid varasemalt tööandjalt.

Mida STARTTLS pordil 587 sulle annab

Uuendus toimub SMTP vestluse sees, nii et relee saab seda teatada ja klient saab keelduda ilma selleta jätkamast. Pythonis viskab starttls() erindi, kui server seda laiendit ei paku, mis muudab allaviimise katse nähtavaks tõrkeks vaikse lihttekstilise sisselogimise asemel. See käitumine on režiimi peamine argument ja sellele tasub teadlikult tugineda, mitte juhuslikult.

Kokkupuute aken on väike, kuid reaalne: algne EHLO vahetus on loetav ja miski enne uuendust ei kanna volitusi. Privaatsel teel rakenduse alavõrgu ja sisemise relee vahel on see aken tavaliselt vastuvõetav. Teel, mida sa ei kontrolli, on see põhjus, miks mõned meeskonnad nõuavad teist režiimi.

Kaudpealtkuulamisseade, mis eemaldab STARTTLS-i võime, tekitab ebaõnnestunud edastuse, mitte tagasilanguse. See on tulemus, mida soovid, ja see on ka kiireim viis avastada, et miski kirjutab teel SMTP-d ümber.

Mida kaudne TLS pordil 465 muudab

Lihtteksti faasi pole üldse. Klient teeb TLS-kätluse kohe, kui pesa avaneb, valideerib sertifikaadi oma usaldushoidla vastu ja alles seejärel vahetab EHLO, AUTH ja sõnumi. Miski ei saa seanssi allaviia, sest pole lihtteksti olekut, millest läbi rääkida, ja see kõrvaldab terve klassi pealtkuulamise tõrkeid.

Kompromiss on diagnoositavus. Relee, mis vastab pordil 465 lihttekstilise SMTP-ga, või koormusjaotur, mis lõpetab TLS-i vale sertifikaadi nimega, ebaõnnestub kätlusel ja annab sulle SSL-vea postivea asemel. Kui see juhtub, on probleem rakendusest allpool ja ükski sõnumi koostamine ei paranda seda.

Üks edastusfunktsioon, kaks transporti

Kood erineb režiimide vahel vaevalt, mistõttu tuleks valik teha relee poliitika, mitte teegi mugavuse järgi. Ekspordi esmalt seaded ja käivita seejärel üks skript, mis valib transpordi konfigureeritud pordi järgi.

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() kontrollib ahelat ja hostinime, seega privaatne CA tuleb paigaldada usaldushoidlasse, mitte sellest kinnitamata kontekstiga mööda minna. send_message() tagastab sõnastiku adressaatidest, mille relee tagasi lükkas; tühi sõnastik tähendab, et see võttis kõik vastu. Viieteistkümne sekundi ajapiirang on lähtepunkt, mitte sinu võrgu jaoks häälestatud väärtus.

Hoia parool kujutisest ja logidest eemal. Käitusajal kinnitatud ja keskkonda loetud saladus on korras; keskkonna kajastamine logireal ei ole, samuti mitte AUTH-vahetuse silumisjälg.

Vali relee poliitika ja tee järgi, mitte harjumuse järgi

Kolm tingimust otsustavad. Esiteks, mida relee tegelikult teatab: teenus, mis kuulab ainult pordil 587 STARTTLS-iga, ei ole pordil 465 kättesaadav, ükskõik kui väga sa kaudset TLS-i eelistad. Teiseks, kas tee rakenduse ja relee vahel on piisavalt usaldusväärne, et aktsepteerida loetavat EHLO vahetust. Kolmandaks, kas miski keskel kirjutab SMTP-d ümber või puhverserverina edastab, sest see otsustab, kas allaviimise risk on teoreetiline või tegelik.

Kui relee pakub mõlemat, võtan 465 järelevalveta töötava teenuse jaoks ja 587 selle jaoks, kus inimene jälgib esimest juurutust, puhtalt seetõttu, et tõrketeated osutavad erinevatele kihtidele. See eelistus on minu oma ja see ei ole poliitika.

Mida iganes valid, kirjuta port, usaldusmaterjal ja saatja domeen juurutuse kõrvale. Seejärel saada üks volitatud testkiri ja kinnita, et relee võttis selle vastu, hoides edastuse tulemuse ja kõik hilisemad kohaletoimetamisaruanded eraldi kirjetena. Edukas üleandmine releele on rakenduse vastutuse lõpp, mitte tõestus, et sõnum jõudis postkasti.

Seotud artiklid