SMTP: saruna starp pasta serveriem

1. modulis: Kā darbojas e-pasts · Lasīšanas laiks: 10 minūtes

Mērķis: Pēc šīs nodarbības Jūs varēsiet lasīt SMTP sarunu, izskaidrot, ko dara EHLO, MAIL FROM, RCPT TO un DATA, un pēc atbildes koda noteikt, vai kļūda ir pagaidu vai galīga.

Pamatjēdzieni: SMTP (RFC 5321), sesija, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, atbildes kods (2xx, 3xx, 4xx, 5xx), paplašinātais statusa kods, paplašinājumi (STARTTLS, AUTH, SIZE), null MX

Saruna vienkāršā tekstā

SMTP ir ļoti vecs protokols (pirmā versija ir no 1982. gada), tāpēc tas ir ļoti saprotams. Divi serveri sūta viens otram teksta rindas. Sūtītājs (klients) nosūta komandu, saņēmējs (serveris) atbild ar trīsciparu skaitli un neliela izskaidrojuma daļu. Šādu sarunu Jūs varat burtiski izlasīt kļūdas paziņojumā vai žurnāla failā, un tieši tāpēc to ir vērts saprast.

Zemāk ir pilna saruna. S: ir saņemošais serveris, C: ir sūtošais serveris. Vēstule iet no anna@example.com uz 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
   (no šī brīža savienojums ir šifrēts; klients atkal nosūta 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: Piedāvājums
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Sveiks, Jan, pielikumā piedāvājums.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

Komandas pa vienai

Vissvarīgākā atziņa: viss pirms DATA ir envelope (aploksne), viss pēc DATA ir saturs. Tas, kas ir norādīts MAIL FROM, un tas, kas ir galvenes rindā From:, tiek nodoti atsevišķi, un tiem nav obligāti jāsakrīt. Serveris piegādā, pamatojoties uz RCPT TO; rinda To: saturā piegādē nekādu lomu nespēlē.

Atbildes kodi

Svarīgākais ir koda pirmais cipars:

Aiz trim cipariem mūsdienu serveriem seko paplašinātais statusa kods formā class.subject.detail (RFC 3463), piemēram, 5.1.1. Pirmais cipars atkal ir 2, 4 vai 5. Otrais cipars norāda, par ko ir runa: 1 = adrese, 2 = pastkaste, 3 = pasta sistēma, 4 = tīkls un maršrutēšana, 5 = protokols, 6 = saturs, 7 = drošība un politika. Daži piemēri, kurus Jūs bieži redzēsiet:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (pagaidu)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (politika: spams, blokēšanas saraksts, DMARC)

5. modulī Jūs iemācīsieties lasīt pilnu atlēciena paziņojumu (bounce) un atradīsiet tabulu ar biežāk sastopamajiem kodiem.

Kāpēc pagaidu un galīgā atšķirība ir tik svarīga

Serveris, kas šaubās, bieži atbild ar 4xx. Pazīstams piemērs ir greylisting: serveris, kas sūtītāju vēl nepazīst, pirmo reizi saka "mēģiniet vēlāk". Īsts pasta serveris pēc dažām minūtēm atgriežas, bet daudzas spama programmas to nedara. Arī lielie saņēmēji izmanto 4xx, lai palēninātu tempu, ja viņi vēl neuzticas kādai IP adresei. Jums kā sūtītājam tas nozīmē: aizkavēšanos, bet ne zudumu. Sistēma to parasti atrisina pati.

5xx ir citādi. Tur sūtītājs vairs nemēģinās vēlreiz. Ja saņemat 5xx, kādam kaut kas ir jāmaina: adrese, saturs vai sūtošā domēna iestatījumi.

Slazds: daži serveri atdod 5xx, lai gan problēma ir pagaidu (piemēram, pilnai pastkastei 552 5.2.2), un citi atdod 4xx kaut kam, kas nekad neizdosies. Tāpēc vienmēr lasiet tekstu aiz koda, nevis tikai skaitli.

Kas ir atbildīgs?

Pēc 250 uz punktu, kas noslēdz DATA, atbildība pāriet uz saņemošo serveri. Ja tam pēc tam neizdodas ievietot vēstuli pastkastē, viņam pašam jānosūta kļūdas paziņojums atpakaļ. Tas ir sarežģītas parādības avots: backscatter. Serveris, kas vispirms pieņem visu un tikai vēlāk saprot, ka adrese nepastāv, nosūta atlēciena ziņojumu (bounce) uz envelope sūtītāja adresi. Ja tā bija viltota spamotāja izveidota adrese, nevainīga trešā persona saņem šo atlēciena ziņojumu. Tāpēc serveriem jau pie RCPT TO jānoraida tas, kas nav iespējams (skatiet arī catch-all nodarbībā 3.3).

Praksē: SMTP redzēšana savā vidē

Parasts lietotājs SMTP sarunu pilnībā reti redz, taču gabalos gan:

• atlēciena paziņojumā (bounce) ir sarunas pēdējā rinda, piemēram, Remote-MTA: mx1.mailprovider.example un Diagnostic-Code: smtp; 550 5.1.1 ...;
• saņemtas vēstules galvenes rindās par katru serveri ir Received: rinda ar EHLO nosaukumu un IP adresi (nodarbība 1.5);
• panelī ar pasta žurnālu, piemēram, E-mail Tracking DirectAdmin WebOké vidē, Jūs redzat par katru ziņojumu saņemošā servera atbildi. Pie citiem pakalpojumu sniedzējiem šādu funkciju var saukt, piemēram, ziņojumu izsekošana jeb mail log, un saturs ir līdzīgs.

Tātad Jums pašam nav jāveido savienojums ar pasta serveri, lai to varētu izlasīt. Ja tomēr vēlaties pamēģināt: ar openssl s_client -starttls smtp -connect server:25 Jūs varat sarunu vadīt pats manuāli, taču daudzi mājas interneta pakalpojumu sniedzēji bloķē izejošo trafiku uz portu 25 (nodarbība 1.4).

Kopsavilkums

• SMTP ir saprotama saruna: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Viss pirms DATA ir envelope (piegāde un kļūdu paziņojumi), viss pēc tam ir saturs ar galvenes rindām, kuras Jūs redzat.
• 2xx = izdevies, 4xx = pagaidu (vēlāk vēlreiz), 5xx = galīgs (bounce).
• Paplašinātais kods X.Y.Z pasaka, par ko ir runa; X.1 adrese, X.2 pastkaste, X.7 politika un drošība.
• Vienmēr lasiet tekstu aiz koda; serveri ne vienmēr ir konsekventi.

Tests

Uzdevums

Uzdevums Z1.2: Domēns, kas nesaņem pastu. Atrodiet domēna example.com MX ierakstus. Ievadiet, ko atradāt, un izvēlieties, ko sūtošais serveris darīs ar vēstuli uz info@example.com: (a) piegādās serverim ar prioritāti 0, (b) mēģinās izmantot A ierakstu, (c) uzreiz atteiksies, vai (d) mēģinās vēlreiz vēlāk. Programma reāllaikā pieprasa MX ierakstu un pārbauda atbildi.

Papildu lasāmviela

Šajos rakstos aprakstītās darbības attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem process ir līdzīgs.

• E-pasta sūtīšanas process / SMTP
• Mail delivery failed: kā izlasīt kļūdas paziņojumu un ko nozīmē kodi
• DirectAdmin rokasgrāmata 9.3: E-mail Tracking: kur palikusi mana vēstule?
• RFC 5321 (SMTP), 3. un 4.2. paragrāfs (atbildes kodi); RFC 3463 (paplašinātie statusa kodi); RFC 7505 (null MX)