Pagpapadala ng SMTP sa Python: STARTTLS sa 587 o TLS sa 465?

Parehong dinadala ng dalawang paraan ng koneksyon ang parehong mensahe sa parehong relay account, at ang pagkakaiba ay kung saan nagsisimula ang TLS, hindi kung ano ang ipinapadala. Ang isa ay bumubukas sa plaintext at nag-a-upgrade sa loob ng koneksyon; ang isa ay naka-encrypt mula sa unang byte. Ang nag-iisang pagkakaibang iyon ang nagtatakda kung ano ang tatanggapin ng mahigpit na patakaran ng relay, kung ano ang maaaring maobserbahan ng intermediate na device, at kung aling mensahe ng error ang gugugulin mo ng isang hapon sa pagbasa. Ganito ako pumipili sa pagitan nila kapag ang isang application sa pribadong network ay naghahatid ng mensahe sa panloob na serbisyo ng pagpapadala.

Saan talaga naghihiwalay ang dalawang paraan

Ang gawain ay pareho sa dalawang kaso: mag-authenticate bilang aprubadong account, magpangalan ng pinapayagang sender, ilista ang mga tatanggap, at maghintay na akuin ng relay ang responsibilidad. Ang nagbabago ay ang pagkakasunod-sunod ng mga operasyon. Nagsisimula ang port 587 bilang sesyon ng SMTP sa plaintext, inaanunsyo ang STARTTLS sa tugon ng EHLO, at nag-a-upgrade lamang kung hihilingin ito ng client. Inaasahan ng port 465 ang handshake ng TLS bago bigkasin ang anumang utos ng SMTP.

Ang pagpapadala at relay ay magkaibang gawain, kaya ang mga numero ng port ay hindi mapagpapalit na ugali. Inilalarawan ng RFC 6409 ang pagpapadala ng mensahe bilang sariling serbisyo, at sinasaklaw ng RFC 8314 ang variant ng implicit TLS na iniaalok ng karamihan sa makabagong relay sa 465. Kung dokumentado ng iyong relay ang isa sa dalawa, mas mataas ang dokumentasyong iyon kaysa sa anumang kagustuhang nakuha mo mula sa dating employer.

Ano ang ibinibigay sa iyo ng STARTTLS sa 587

Ang pag-upgrade ay nangyayari sa loob ng usapan ng SMTP, kaya maaaring ianunsyo ito ng relay at maaaring tumanggi ang client na magpatuloy nang wala ito. Sa Python, nagtatapon ng exception ang starttls() kapag hindi iniaalok ng server ang extension, na ginagawang nakikitang pagpalya ang pagtatangkang mag-downgrade sa halip na tahimik na pag-login sa plaintext. Ang pag-uugaling iyon ang pangunahing argumento para sa paraan, at sulit na umasa rito nang sinasadya at hindi nagkataon.

Maliit ngunit totoo ang bintana ng pagkakalantad: nababasa ang paunang palitan ng EHLO, at walang nagdadala ng kredensyal bago ang pag-upgrade. Sa pribadong landas sa pagitan ng subnet ng application at panloob na relay, karaniwang katanggap-tanggap ang bintanang iyon. Sa landas na hindi mo kinokontrol, iyon mismo ang dahilan kung bakit pinipilit ng ilang team ang kabilang paraan.

Ang device na pumipigil na nag-aalis ng kakayahan ng STARTTLS ay gumagawa ng bigong pagpapadala, hindi pag-urong. Iyon ang resulta na gusto mo, at iyon din ang pinakamabilis na paraan upang matuklasan na may isang bagay na nagsusulat muli ng SMTP sa landas.

Ano ang binabago ng implicit TLS sa 465

Wala talagang yugto ng plaintext. Nagsasagawa ng handshake ng TLS ang client sa sandaling bumukas ang socket, binabalido ang sertipiko laban sa storage ng pagtitiwala nito, at pagkatapos lamang nito ay nagpapalitan ng EHLO, AUTH at ng mensahe. Walang makapagpapababa ng sesyon dahil walang estado ng plaintext na mapag-uusapan, at inaalis nito ang buong uri ng mga bigong panghihimasok.

Ang kapalit ay ang kakayahang masuri. Ang relay na sumasagot sa 465 gamit ang plaintext SMTP, o ang load balancer na tinapos ang TLS sa maling pangalan ng sertipiko, ay bigo sa handshake at binibigyan ka ng error sa SSL sa halip na error sa mail. Kapag nangyari iyon, ang problema ay nasa ilalim ng application, at walang dami ng pagbuo ng mensahe ang makakapag-ayos nito.

Isang function ng pagpapadala, dalawang transport

Halos hindi nagkakaiba ang code sa pagitan ng mga paraan, kaya ang pagpili ay dapat gawin mula sa patakaran ng relay at hindi sa kaginhawahan ng library. I-export muna ang mga setting, pagkatapos ay patakbuhin ang isang script na pumipili ng transport batay sa naka-configure na port.

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() binabalido ang chain at ang hostname, kaya ang pribadong CA ay dapat i-install sa storage ng pagtitiwala sa halip na iwasan gamit ang hindi nababalido na konteksto. Nagbabalik ang send_message() ng diksyunaryo ng mga tatanggap na tinanggihan ng relay; ang walang laman na diksyunaryo ay nangangahulugang tinanggap nito ang lahat. Ang timeout na labinlimang segundo ay panimulang punto, hindi isang value na naka-tune para sa iyong network.

Itago ang password sa labas ng image at sa labas ng mga log. Ang lihim na naka-mount sa runtime at nabasa sa environment ay ayos lang; ang pag-echo ng environment sa isang linya ng log ay hindi, at gayundin ang debug trace ng palitan ng AUTH.

Pumili ayon sa patakaran ng relay at landas, hindi ayon sa ugali

Tatlong kondisyon ang nagtatakda. Una, kung ano ang aktwal na inaanunsyo ng relay: ang serbisyong nakikinig lamang sa 587 na may STARTTLS ay hindi maabot sa 465, gaano man mo kagusto ang implicit TLS. Ikalawa, kung ang landas sa pagitan ng application at relay ay sapat na pinagkakatiwalaan upang tanggapin ang nababasang palitan ng EHLO. Ikatlo, kung may isang bagay sa gitna na nagsusulat muli o nagpo-proxy ng SMTP, dahil iyon ang nagtatakda kung ang panganib ng downgrade ay teoretikal o totoo.

Kapag iniaalok ng relay ang dalawa, kinukuha ko ang 465 para sa serbisyong tumatakbo nang walang pangangasiwa at ang 587 para sa isa kung saan may taong nanonood ng unang deployment, dahil lamang ang mga mensahe ng pagpalya ay tumuturo sa magkaibang layer. Ang kagustuhang iyon ay akin at hindi ito patakaran.

Anuman ang piliin mo, itala ang port, ang materyal ng pagtitiwala at ang domain ng sender kasama ng deployment. Pagkatapos ay magpadala ng isang awtorisadong test message at kumpirmahin na tinanggap ito ng relay, na itinatago ang resulta ng pagpapadala at anumang susunod na ulat ng paghahatid bilang magkahiwalay na talaan. Ang matagumpay na paghahatid sa relay ay katapusan ng responsibilidad ng application, hindi patunay na nakarating ang mensahe sa inbox.