SMTP: pogovor med poštnimi strežniki

Modul 1: Kako deluje e-pošta · Čas branja: 10 minut

Cilj lekcije: Po tej lekciji boste znali prebrati SMTP-pogovor, razložiti, kaj počnejo EHLO, MAIL FROM, RCPT TO in DATA, ter iz odgovorne kode razbrati, ali je napaka začasna ali dokončna.

Ključni pojmi: SMTP (RFC 5321), seja, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, odgovorna koda (2xx, 3xx, 4xx, 5xx), razširjena statusna koda, razširitve (STARTTLS, AUTH, SIZE), null MX

Pogovor v navadnem besedilu

SMTP je zelo star protokol (prva različica je iz leta 1982) in je zato zelo berljiv. Dva strežnika si pošiljata vrstice besedila. Pošiljatelj (odjemalec) pošlje ukaz, prejemnik (strežnik) odgovori s tremi števkami in kratko razlago. Tak pogovor lahko dobesedno preberete v sporočilu o napaki ali dnevniku, zato se splača razumeti, kako deluje.

Spodaj je celoten pogovor. S: je prejemni strežnik, C: je pošiljajoči strežnik. Sporočilo gre od anna@example.com do jan@example.net.

S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (od tu naprej je povezava šifrirana; odjemalec znova pošlje EHLO)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Offerte
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hoi Jan, hierbij de offerte.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

Ukazi, eden za drugim

Najpomembnejše spoznanje: vse pred DATA je ovojnica, vse po DATA je vsebina. Kaj je navedeno v MAIL FROM in kaj v glavi From:, se dostavlja ločeno in se ne rabi ujemati. Strežnik dostavi glede na RCPT TO; vrstica To: v vsebini pri dostavi ne igra vloge.

Odgovorne kode

Prva števka kode je najpomembnejša:

Za tremi števkami je pri sodobnih strežnikih še razširjena statusna koda v obliki class.subject.detail (RFC 3463), na primer 5.1.1. Prva števka je spet 2, 4 ali 5. Druga števka pove, za kaj gre: 1 = naslov, 2 = poštni predal, 3 = poštni sistem, 4 = omrežje in usmerjanje, 5 = protokol, 6 = vsebina, 7 = varnost in pravilnik. Nekaj primerov, ki jih pogosto srečate:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (začasno)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (pravilnik: spam, seznam blokad, DMARC)

V modulu 6 se boste naučili prebrati celotno sporočilo o napaki (bounce) in najdete tabelo z najpogostejšimi kodami.

Zakaj je razlika med začasno in dokončno napako tako pomembna

Strežnik, ki dvomi, pogosto odgovori s kodo 4xx. Znan primer je greylisting: strežnik, ki pošiljatelja še ne pozna, prvič reče "poskusite pozneje". Pravi poštni strežnik se po nekaj minutah vrne, veliko programov za pošiljanje neželene pošte pa ne. Tudi veliki ponudniki uporabljajo 4xx, da upočasnijo tempo, kadar IP-naslovu še ne zaupajo. Za Vas kot pošiljatelja to pomeni: zamudo, ne pa izgube. Sistem to običajno sam reši.

Koda 5xx je drugačna. Tam pošiljatelj ne bo več poskušal. Če dobite 5xx, mora nekdo nekaj spremeniti: naslov, vsebino ali nastavitve pošiljajoče domene.

Past: nekateri strežniki vrnejo 5xx, čeprav je težava začasna (na primer pri polnem poštnem predalu 552 5.2.2), drugi pa vrnejo 4xx za nekaj, kar nikoli ne bo uspelo. Zato vedno preberite besedilo za kodo, ne samo številke.

Kdo je odgovoren?

Po 250 na piki za DATA je odgovornost na strani prejemnega strežnika. Če mu pozneje ne uspe shraniti sporočila v poštni predal, mora sam poslati sporočilo o napaki nazaj. To je vir neprijetnega pojava: backscatter. Strežnik, ki najprej sprejme vse, nato pa ugotovi, da naslov ne obstaja, pošlje sporočilo o napaki na naslov pošiljatelja iz ovojnice. Če je bil ta ponarejen s strani pošiljatelja neželene pošte, sporočilo o napaki prejme nedolžna tretja oseba. Zato bi morali strežniki tisto, kar ne bo uspelo, zavrniti že pri RCPT TO (glejte tudi catch-all v lekciji 3.3).

V praksi: SMTP v Vašem lastnem okolju

Navaden uporabnik SMTP-pogovora redko vidi v celoti, vidi pa dele:

• v sporočilu o napaki (bounce) je zadnja vrstica pogovora, na primer Remote-MTA: mx1.mailprovider.example in Diagnostic-Code: smtp; 550 5.1.1 ...;
• v glavah prejetega sporočila je za vsak strežnik vrstica Received: z imenom EHLO in IP-naslovom (lekcija 1.5);
• v nadzorni plošči z dnevnikom pošte, kot je Sledenje e-pošti v DirectAdmin pri WebOké, vidite za vsako sporočilo odgovor prejemnega strežnika. Pri drugih ponudnikih se to imenuje na primer sledenje sporočilom ali dnevnik pošte, vsebina pa je primerljiva.

Torej Vam za branje tega ni treba sami vzpostaviti povezave s poštnim strežnikom. Kdor bi to vendarle rad poskusil: z ukazom openssl s_client -starttls smtp -connect server:25 lahko pogovor izvedete ročno, vendar številni domači ponudniki internetnih storitev blokirajo odhodni promet na vratih 25 (lekcija 1.4).

Povzetek

• SMTP je berljiv pogovor: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Vse pred DATA je ovojnica (dostava in sporočila o napakah), vse po njem je vsebina z glavami, ki jih vidite.
• 2xx = uspešno, 4xx = začasno (pozneje znova), 5xx = dokončno (bounce).
• Razširjena koda X.Y.Z pove, za kaj gre; X.1 naslov, X.2 poštni predal, X.7 pravilnik in varnost.
• Vedno preberite besedilo za kodo; strežniki niso vedno dosledni.

Kviz

Naloga

Naloga Z1.2: Domena, ki ne prejema pošte. Poiščite zapise MX za example.com. Vnesite, kaj ste našli, in izberite, kaj pošiljajoči strežnik naredi s sporočilom za info@example.com: (a) dostavi ga strežniku s prioriteto 0, (b) poskusi z zapisom A, (c) takoj odneha ali (d) pozneje znova poskusi. Program v živo preveri zapis MX in pregleda odgovor.

Za nadaljnje branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.

• Razlaga postopka pošiljanja e-pošte / SMTP
• Neuspela dostava e-pošte: kako razumeti sporočilo o napaki in kaj pomenijo kode
• Priročnik DirectAdmin 9.3: Sledenje e-pošti: kam je izginilo moje sporočilo?
• RFC 5321 (SMTP), poglavje 3 in 4.2 (odgovorne kode); RFC 3463 (razširjene statusne kode); RFC 7505 (null MX)