E-pasta vēstules ceļojums

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

Mērķis: Pēc šīs nodarbības Jūs varēsiet soli pa solim aprakstīt, kā vēstule no sūtītāja nonāk pie saņēmēja, un katrā solī pateikt, kura programma vai kurš serveris veic darbu.

Pamatjēdzieni: pasta programma (MUA), nosūtīšanas serveris (MSA, submission), pasta serveris (MTA), MX ieraksts, rinda, piegāde (MDA), pastkaste, saņemšana (IMAP/POP3), envelope, galvenes

Pasts ir pasts, nevis tērzēšanas ziņa

Ja Jūs sūtāt tērzēšanas ziņu, tā iet caur vienu uzņēmumu: sūtītāja lietotne un saņēmēja lietotne runā ar vieniem un tiem pašiem serveriem. E-pasts darbojas citādi. Sūtītājs un saņēmējs var atrasties katrs pie cita pakalpojumu sniedzēja: viens pie hostinga uzņēmuma, otrs pie Gmail, trešais pie Microsoft 365 vai pie sava uzņēmuma servera. Tomēr vēstule nonāk mērķī. Tas izdodas, jo visi pasaules pasta serveri ievēro vienas un tās pašas vienošanās.

E-pastu var labi salīdzināt ar parasto pastu. Jūs uzrakstāt vēstuli (ziņojumu), ieliekat to aploksnē ar adresi (envelope), aiznesat to līdz pastkastītei (nosūtīšanas serveris), pasta uzņēmums noskaidro, kur atrodas adrese (MX meklēšana), aizved vēstuli uz pareizo šķirošanas centru (saņemošais pasta serveris), un tas ieliek to saņēmēja pastkastē (pastkaste). Saņēmējs to izņem tad, kad Viņam ir ērti.

Pieturas pēc kārtas

Pieņemsim, ka Anna sūta vēstuli no anna@example.com uz jan@example.net. Notiek šādi:

Maziem pakalpojumu sniedzējiem MSA, MTA un MDA bieži vien ir viena un tā pati programma vienā serverī. Lieliem pakalpojumu sniedzējiem tie ir atsevišķi klasteri. Jums tas praktiski neko nemaina: tās ir lomas, nevis atsevišķas ierīces.

Pievērsiet uzmanību atšķirībai starp 1. un 4. soli. Abos izmanto SMTP, Simple Mail Transfer Protocol (RFC 5321). Taču 1. solī Jūs piesakāties un izmantojat portu 587 vai 465; to sauc par submission (RFC 6409). 4. solī divi serveri sarunājas savā starpā uz porta 25, nepieslēdzoties ar pieteikšanos: saņemošais serveris pieņem pastu saviem domēniem no jebkura sūtītāja. Nodarbībā 1.4 Jūs redzēsiet, kāpēc šāds nodalījums pastāv.

3. solis tuvplānā: MX meklēšana

Nosūtošais serveris pats no sevis nezina, kur example.net saņem savu pastu. Viņš jautā DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Mazākajam skaitlim ir priekšroka. Serveris vispirms mēģina mx1, un, ja tas neatbild, tad mx2. Pēc tam viņš noskaidro šī nosaukuma IP adresi (A vai AAAA ieraksts) un izveido savienojumu.

Divi īpaši gadījumi, ar kuriem Jūs varat sastapties praksē:

• Nav MX ieraksta. Tad sūtītājs mēģina izmantot paša domēna A vai AAAA ierakstu (tā saucamais "netiešais MX" no RFC 5321, 5.1. punkta). Tas ir palieka no agrākiem laikiem un nedarbojas uzticami; katram domēnam, kas saņem pastu, būtu jābūt MX ierakstam.
• Null MX: 0 . Tas nozīmē: "šis domēns nekad nesaņem pastu" (RFC 7505). Domēnam example.com ir tieši šāds ieraksts. Sūtītājs uzreiz padodas un nosūta atpakaļ kļūdas paziņojumu, nevis turpina mēģināt vēl dienām ilgi.

Par to, kā tieši darbojas MX ieraksti un prioritātes, Jūs varat lasīt DNS kursa nodarbībā 4.1.

Rinda: e-pasts drīkst nedaudz paildzināties

Vēstule ne vienmēr tiek piegādāta sekundes laikā. Ja saņemošais serveris neatbild vai saka "mēģiniet vēlāk vēlreiz" (kods, kas sākas ar 4), vēstule paliek nosūtīšanas servera rindā. Serveris mēģina vēlreiz vēlāk, katru reizi ar nedaudz lielāku intervālu. RFC 5321 (4.5.4.1. punkts) iesaka vismaz 30 minūtes starp mēģinājumiem un padošanos tikai pēc 4 līdz 5 dienām. Daudzi serveri pēc dažām stundām jau nosūta brīdinājumu ("delayed", vēl nav piegādāts), bet pēc dažām dienām galīgo kļūdas paziņojumu.

Tas ir e-pasta spēcīga īpašība: ja pasta serveris stundu nedarbojas, neviena vēstule nepazūd. Tas ir arī iemesls, kāpēc vēstule dažkārt nonāk pie saņēmēja tikai vairākas stundas vēlāk. 6. modulī Jūs redzēsiet, kā atpazīt šādu aizkavēšanos.

Envelope un galvenes: divas adreses

Tāpat kā parastā pastā, vēstulei ir divu veidu adreses:

• Envelope. Tās ir adreses, kuras serveri izmanto savstarpēji SMTP sarunā: MAIL FROM (sūtītājs kļūdu paziņojumiem, vēlāk redzams kā Return-Path) un RCPT TO (saņēmējs). Serveri piegādā, pamatojoties uz envelope.
• Galvenes (headers). Tas ir tas, kas rakstīts pašā vēstulē: From:, To:, Cc:, Subject:, Date:. Jūsu pasta programma tās parāda.

Parasti tās sakrīt, bet ne vienmēr. BCC saņēmējs gan ir norādīts envelope, bet ne galvenēs; tāpēc citi viņu neredz. Jaunumu vēstuļu pakalpojums norāda savu adresi kā envelope sūtītāju, lai kļūdu paziņojumi nonāktu pie pakalpojuma, kamēr From: ir norādīta Jūsu adrese. Un krāpnieks var ierakstīt From: laukā jebko, ko vēlas.

Kāpēc tam ir nozīme: SPF pārbauda envelope sūtītāju, lietotājs redz From:. Tāpēc pastāv DMARC, kas šos divus savieno kopā (4. modulis).

Kur var rasties kļūdas

Ar šo shēmu Jūs varat jebkuras problēmas gadījumā jautāt: kurā pieturvietā tas noiet greizi?

• Nosūtīšana neizdodas (kļūdas paziņojums uzreiz Jūsu programmā): 1. vai 2. solis. Gandrīz vienmēr iestatījumi: ports, pieteikšanās, parole (2. modulis).
• Jūs saņemat atpakaļ atlēciena paziņojumu (bounce): 3. vai 4. solis. Saņemošais serveris noraidīja vēstuli, vai adrese nepastāv (6. modulis).
• Vēstule nonāk, bet surogātpasta mapē: 5. solis. Saņēmējs neuzticas vēstulei (4. un 5. modulis).
• Saņēmējs neko neredz, un Jūs nesaņemat nekādu kļūdas paziņojumu: vēstule, iespējams, vēl atrodas rindā vai saņēmēja pusē tikusi klusi atfiltrēta. Šeit palīdz nosūtīšanas servera žurnāla ieraksti (6. modulis).
• Pasts nemaz nenonāk pie Jūsu domēna: 3. solis. MX ieraksti nav pareizi, piemēram, pēc pārcelšanās (8. modulis).

Praksē: šādi tas izskatās hostinga pakotnē

WebOké hostinga pakotnē viens serveris uz katru pakotni veic visas lomas: Jūsu pasta programma piegādā vēstuli šim serverim (1. un 2. solis), serveris nosūta to tālāk (3. un 4. solis) un saņem pastu Jūsu domēnam (5. solis). DirectAdmin ar E-mail Tracking Jūs varat katrai vēstulei redzēt, vai tā ir piegādāta. Citiem pakalpojumu sniedzējiem tas darbojas līdzīgi; tur šādu funkciju sauc, piemēram, par "ziņojumu izsekošanu" vai "mail log".

Kopsavilkums

• Vēstule iet no Jūsu pasta programmas (MUA) caur nosūtīšanas serveri (MSA/MTA) uz saņemošo serveri (MTA/MDA) un no turienes uz saņēmēja pasta programmu.
• Nosūtīšana no Jūsu programmas ir SMTP-submission ar pieteikšanos (587/465); serveri savstarpēji sazinās ar SMTP uz porta 25; saņemšana notiek ar IMAP vai POP3.
• Nosūtošais serveris meklē domēna, kas atrodas aiz @, MX ierakstus. Null MX (0 .) nozīmē: šis domēns nesaņem pastu.
• Vēstule, kuru nevar uzreiz piegādāt, paliek rindā un tiek mēģināta piegādāt atkārtoti vairākas dienas.
• Envelope (Return-Path) un galvenes (From) ir divi dažādi sūtītāji. SPF skatās uz pirmo, lietotājs uz otro.

Tests

Uzdevums

Uzdevums Z1.1: Pirmā pasta servera atrašana. Atrodiet domēna gmail.com (vai sava domēna) MX ierakstus. Norādiet, kurš serveris tiek mēģināts pirmais, ar tā prioritātes skaitli, un vienu šī servera IP adresi (IPv4 vai IPv6). Programma tieši tagad pieprasa tos pašus datus un pārbauda tos.

Papildu lasāmviela

Šajos rakstos aprakstītie soļi attiecas uz WebOké paneļiem; citiem pakalpojumu sniedzējiem tas darbojas līdzīgi.

• E-pasta sūtīšanas process / SMTP
• DirectAdmin rokasgrāmata 8.7: IMAP vai POP3: kāda ir atšķirība?
• Bezmaksas DNS kurss 4.1: MX ieraksti un prioritāte
• RFC 5321 (SMTP), 5.1. punkts (MX un netiešais MX) un 4.5.4.1. punkts (atkārtota mēģināšana); RFC 7505 (null MX)