SMTP: a levelezőszerverek közötti párbeszéd

Modul 1: Hogyan működik az e-mail · Olvasási idő: 10 perc

Tanulási cél: E lecke után Ön képes lesz elolvasni egy SMTP-párbeszédet, el tudja magyarázni, mit tesz az EHLO, a MAIL FROM, a RCPT TO és a DATA, és egy válaszkódból meg tudja állapítani, hogy egy hiba ideiglenes vagy végleges.

Kulcsfogalmak: SMTP (RFC 5321), munkamenet, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, válaszkód (2xx, 3xx, 4xx, 5xx), bővített állapotkód, bővítmények (STARTTLS, AUTH, SIZE), null MX

Egy párbeszéd egyszerű szövegben

Az SMTP egy nagyon régi protokoll (az első változata 1982-ből származik), ezért igen jól olvasható. Két szerver szöveges sorokat küld egymásnak. A küldő (a kliens) egy parancsot küld, a fogadó (a szerver) egy háromjegyű számmal és egy rövid magyarázattal válaszol. Egy ilyen párbeszédet szó szerint visszaolvashat egy hibaüzenetben vagy egy naplófájlban, és pontosan ezért érdemes megérteni, hogyan működik.

Alább egy teljes párbeszéd látható. Az S: a fogadó szervert jelöli, a C: a küldő szervert. A levél a anna@example.com címről a jan@example.net címre megy.

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
   (innentől a kapcsolat titkosított; a kliens újra elküldi az EHLO-t)
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

A parancsok egyenként

A legfontosabb felismerés: minden, ami a DATA előtt van, a boríték része, minden, ami utána jön, a tartalom. Ami a MAIL FROM-ban szerepel, és ami a From: fejlécben áll, külön kerül megadásra, és nem szükséges egyeznie. A szerver a RCPT TO alapján kézbesít; a tartalomban szereplő To: sornak a kézbesítésnél nincs szerepe.

A válaszkódok

A kód első számjegye a legfontosabb:

A három számjegy után a modern szervereknél egy bővített állapotkód található class.subject.detail (osztály.tárgy.részlet) formában (RFC 3463), például 5.1.1. Az első szám ismét 2, 4 vagy 5 lehet. A második szám azt mondja meg, miről van szó: 1 = cím, 2 = postafiók, 3 = levelezőrendszer, 4 = hálózat és útvonalválasztás, 5 = protokoll, 6 = tartalom, 7 = biztonság és szabályzat. Néhány gyakran előforduló példa:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (ideiglenes)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (szabályzat: spam, letiltólista, DMARC)

A 6. modulban megtanulja egy teljes bounce elolvasását, és egy táblázatot is talál majd a leggyakoribb kódokkal.

Miért olyan fontos az ideiglenes és a végleges hiba közti különbség

Egy szerver, amely bizonytalan, gyakran 4xx kóddal válaszol. Jól ismert példa erre a greylisting: egy szerver, amely még nem ismeri a küldőt, első alkalommal azt üzeni, hogy "próbálja meg később". Egy valódi levelezőszerver néhány perc múlva visszatér, sok spamprogram viszont nem. A nagy fogadó szolgáltatók is gyakran használnak 4xx kódot a tempó lassítására, ha egy IP-címben még nem bíznak meg. Az Ön, mint küldő számára ez azt jelenti: késedelem, de nem veszteség. A rendszer ezt rendszerint magától megoldja.

Az 5xx más helyzet. Ott a küldő nem próbálkozik újra. Ha 5xx választ kap, valakinek változtatnia kell valamin: a címen, a tartalmon vagy a küldő domain beállításain.

Egy buktató: bizonyos szerverek 5xx-et adnak, miközben a probléma valójában ideiglenes (például egy teli postafiók esetén 552 5.2.2), mások pedig 4xx-et adnak olyasmire, ami soha nem fog sikerülni. Ezért mindig olvassa el a kód mögötti szöveget, ne csak a számot.

Ki a felelős?

A DATA lezáró pontjára adott 250 után a felelősség a fogadó szerveré. Ha ezután mégsem sikerül a levelet a postafiókba helyeznie, saját magának kell hibaüzenetet visszaküldenie. Ez egy kellemetlen jelenség forrása: a backscatter. Az a szerver, amely előbb mindent átvesz, és csak később jön rá, hogy a cím nem létezik, bounce-ot küld a boríték szerinti feladónak. Ha azt egy spammer hamisította, egy ártatlan harmadik fél kapja meg a bounce-ot. Ezért a szervereknek már a RCPT TO lépésnél vissza kellene utasítaniuk azt, ami nem teljesíthető (lásd még a catch-all témát a 3.3 leckében).

A gyakorlatban: SMTP a saját környezetében

Egy hétköznapi felhasználó ritkán látja a teljes SMTP-párbeszédet, de részleteiben igen gyakran:

• egy bounce-ban megjelenik a párbeszéd utolsó sora, például Remote-MTA: mx1.mailprovider.example és Diagnostic-Code: smtp; 550 5.1.1 ...;
• egy beérkezett levél fejlécében szervereként egy Received: sor szerepel az EHLO-névvel és az IP-címmel (1.5 lecke);
• egy levelezési naplóval rendelkező felületen, mint amilyen az E-mail követés a DirectAdminben a WebOké rendszerében, üzenetenként megtekintheti a fogadó szerver válaszát. Más szolgáltatóknál ez hasonló módon, például üzenetkövetés vagy mail log néven jelenik meg, és a tartalma is hasonló.

Önnek tehát nem kell kapcsolódnia egy levelezőszerverhez ahhoz, hogy mindezt el tudja olvasni. Aki szeretné kipróbálni: az openssl s_client -starttls smtp -connect server:25 paranccsal kézzel is lefolytathatja a párbeszédet, de sok otthoni internetszolgáltató blokkolja a kimenő forgalmat a 25-ös porton (1.4 lecke).

Összefoglalás

• Az SMTP egy olvasható párbeszéd: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Minden, ami a DATA előtt áll, a boríték része (kézbesítés és hibaüzenetek), minden, ami utána jön, a tartalom a látható fejlécsorokkal együtt.
• 2xx = sikerült, 4xx = ideiglenes (később újra), 5xx = végleges (bounce).
• A bővített kód, az X.Y.Z, megmondja, miről van szó: X.1 cím, X.2 postafiók, X.7 szabályzat és biztonság.
• Mindig olvassa el a kód mögötti szöveget; a szerverek nem mindig következetesek.

Kvíz

Feladat

Z1.2 feladat: Egy domain, amely nem fogad e-mailt. Keresse meg az example.com MX-rekordjait. Töltse ki, mit talált, és válassza ki, mit tesz egy küldő szerver az info@example.com címre szánt levéllel: (a) kézbesíti a 0 prioritású szervernek, (b) megpróbálja az A-rekordot, (c) azonnal feladja, vagy (d) később újra megpróbálja. A program élőben lekérdezi az MX-rekordot, és ellenőrzi a választ.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké kezelőfelületeire vonatkoznak; más szolgáltatóknál ez hasonlóan működik.

• Az e-mailek küldési folyamata / SMTP
• Mail delivery failed: így olvassa ki a hibaüzenetet, és mit jelentenek a kódok
• DirectAdmin útmutató 9.3: E-mail követés: hová lett az e-mailem?
• RFC 5321 (SMTP), 3. és 4.2. szakasz (válaszkódok); RFC 3463 (bővített állapotkódok); RFC 7505 (null MX)