Elektroninio laiško kelionė

1 modulis: Kaip veikia el. paštas · Skaitymo trukmė: 9 min.

Mokymosi tikslas: Po šios pamokos galėsite žingsnis po žingsnio paaiškinti, kaip laiškas nuo siuntėjo pasiekia gavėją, ir kiekviename žingsnyje nurodyti, kuri programa ar serveris atlieka darbą.

Pagrindinės sąvokos: pašto programa (MUA), siuntimo serveris (MSA, submission), pašto serveris (MTA), MX įrašas, eilė, pristatymas (MDA), pašto dėžutė, atsisiuntimas (IMAP/POP3), vokas (envelope), kopregelės

Paštas yra laiškas, ne pokalbio žinutė

Kai siunčiate pokalbio žinutę, ji keliauja per vieną bendrovę: siuntėjo ir gavėjo programėlės bendrauja su tais pačiais serveriais. El. paštas veikia kitaip. Siuntėjas ir gavėjas gali naudotis skirtingų paslaugų teikėjų paslaugomis: vienas pas prieglobos bendrovę, kitas Gmail, trečias Microsoft 365 arba savo įmonės serveryje. Vis dėlto laiškas pasiekia adresatą. Tai pavyksta todėl, kad visi pasaulio pašto serveriai laikosi tų pačių susitarimų.

El. paštą galima gerai palyginti su paprastu paštu. Rašote laišką (pranešimą), įdedate jį į voką su adresu (vokas, envelope), nunešate jį į pašto dėžutę (siuntimo serveris), pašto įmonė nustato, kur yra tas adresas (MX įrašo paieška), nugabena laišką į tinkamą rūšiavimo centrą (gaunantysis pašto serveris), o šis įdeda jį į gavėjo pašto dėžutę (mailbox). Gavėjas jį atsiima tada, kai jam patogu.

Stotelės iš eilės

Tarkime, Anna siunčia laišką iš anna@example.com gavėjui jan@example.net. Štai kas vyksta:

Mažų paslaugų teikėjų atveju MSA, MTA ir MDA dažnai yra viena ir ta pati programa viename serveryje. Didelių paslaugų teikėjų atveju tai atskiri klasteriai. Jums tai didelio skirtumo nedaro: tai yra vaidmenys, o ne atskiri įrenginiai.

Atkreipkite dėmesį į skirtumą tarp 1 ir 4 žingsnio. Abu žingsniai naudoja SMTP, Simple Mail Transfer Protocol (RFC 5321). Tačiau 1 žingsnyje prisijungiate ir naudojate prievadą 587 arba 465; tai vadinama submission (RFC 6409). 4 žingsnyje du serveriai bendrauja tarpusavyje prievadu 25, be prisijungimo: gaunantysis serveris priima paštą savo domenams nuo bet kurio siuntėjo. Pamokoje 1.4 sužinosite, kodėl toks atskyrimas egzistuoja.

3 žingsnis iš arčiau: MX įrašo paieška

Siunčiantysis serveris savaime nežino, kur example.net priima savo paštą. Jis užklausia DNS:

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

Mažiausias skaičius turi pirmenybę. Serveris pirmiausia bando mx1, o jei šis neatsako, bando mx2. Po to jis užklausia to pavadinimo IP adreso (A arba AAAA įrašas) ir užmezga ryšį.

Du ypatingi atvejai, su kuriais susidursite praktikoje:

• Nėra MX įrašo. Tada siuntėjas bando domeno A arba AAAA įrašą (vadinamasis "numanomas MX" iš RFC 5321, 5.1 paragrafo). Tai yra senovės liekana ir neveikia patikimai; kiekvienas paštą gaunantis domenas turėtų turėti MX įrašą.
• Null MX: 0 . Tai reiškia: "šis domenas niekada negauna pašto" (RFC 7505). Domenas example.com turi būtent tokį įrašą. Siuntėjas iš karto atsisako ir grąžina klaidos pranešimą, užuot bandęs kelias dienas iš eilės.

Kaip tiksliai veikia MX įrašai ir prioritetai, perskaitysite DNS kurso pamokoje 4.1.

Eilė: el. laiškas gali šiek tiek užtrukti

Laiškas ne visada pasiekia adresatą per sekundę. Jei gaunantysis serveris neatsako arba sako "pabandykite vėliau" (kodas, prasidedantis skaičiumi 4), laiškas lieka siuntimo serverio eilėje. Serveris bando iš naujo vėliau, kaskart darydamas vis ilgesnes pertraukas. RFC 5321 (4.5.4.1 paragrafas) rekomenduoja bent 30 minučių tarp bandymų ir atsisakyti tik po 4 iki 5 dienų. Daugelis serverių po kelių valandų iš karto siunčia įspėjimą ("delayed", dar nepristatyta), o po kelių dienų, galutinį klaidos pranešimą.

Tai yra stipri el. pašto savybė: jei pašto serveris neveikia valandą, nė vienas laiškas nedingsta. Tai taip pat paaiškina, kodėl laiškas kartais pasiekia adresatą tik po kelių valandų. 6 modulyje sužinosite, kaip atpažinti tokį vėlavimą.

Vokas ir kopregelės: du adresai

Kaip ir paprasto pašto atveju, laiškas turi dviejų rūšių adresus:

• Vokas (envelope). Tai adresai, kuriuos serveriai naudoja tarpusavyje SMTP pokalbio metu: MAIL FROM (siuntėjas klaidos pranešimams, vėliau matomas kaip Return-Path) ir RCPT TO (gavėjas). Serveriai pristato laišką pagal voko duomenis.
• Kopregelės (headers). Tai, kas parašyta pačiame laiške: From:, To:, Cc:, Subject:, Date:. Jūsų pašto programa tai rodo.

Dažniausiai jie sutampa, bet ne visada. BCC gavėjas yra voke, bet ne kopregelėse; todėl kiti jo nemato. Naujienlaiškio paslauga savo adresą nurodo kaip voko siuntėją, kad klaidos pranešimai pasiektų tą paslaugą, nors From: nurodytas Jūsų adresas. O sukčius gali From: įrašyti ką tik nori.

Kodėl tai svarbu: SPF tikrina voko siuntėją, o naudotojas mato From:. Štai kodėl yra DMARC, kuris šiuos du dalykus susieja tarpusavyje (4 modulis).

Kur gali atsirasti problemų

Turėdami šį vaizdą, prie kiekvienos problemos galite užduoti klausimą: kurioje stotelėje kažkas nutinka ne taip?

• Siuntimas nepavyksta (klaidos pranešimas iš karto Jūsų programoje): 1 arba 2 žingsnis. Beveik visada tai nustatymai: prievadas, prisijungimas, slaptažodis (2 modulis).
• Gaunate grąžintą laišką (bounce): 4 arba 5 žingsnis. Gaunantysis serveris atmetė laišką arba adresas neegzistuoja (6 modulis).
• Laiškas pasiekia adresatą, bet patenka į šlamšto aplanką: 5 žingsnis. Gavėjas nepasitiki laišku (4 ir 5 moduliai).
• Gavėjas nieko nemato, o Jūs negaunate jokio klaidos pranešimo: laiškas galbūt vis dar yra eilėje arba buvo tyliai atfiltruotas gavėjo pusėje. Čia padeda siuntimo serverio žurnalai (6 modulis).
• Paštas niekur nepasiekia Jūsų domeno: 3 žingsnis. MX įrašai yra neteisingi, pavyzdžiui, po perkėlimo (8 modulis).

Praktikoje: kaip tai atrodo su prieglobos paketu

Naudojant WebOké prieglobos paketą, vienas serveris paketui atlieka visus vaidmenis: Jūsų pašto programa pristato laišką tam serveriui (1 ir 2 žingsnis), serveris jį siunčia į išorę (3 ir 4 žingsnis) ir priima paštą Jūsų domenui (5 žingsnis). DirectAdmin valdymo skydelyje galite naudoti El. pašto sekimą, kad pamatytumėte, ar konkretus laiškas buvo pristatytas. Pas kitus paslaugų teikėjus veikia panašiai; ten tokia funkcija gali vadintis, pavyzdžiui, "pranešimų sekimas" arba "mail log".

Santrauka

• Laiškas keliauja nuo Jūsų pašto programos (MUA) per siuntimo serverį (MSA/MTA) iki gaunančiojo serverio (MTA/MDA) ir iš ten į gavėjo pašto programą.
• Siuntimas iš Jūsų programos yra SMTP-submission su prisijungimu (587/465); serveriai tarpusavyje bendrauja SMTP protokolu 25 prievadu; atsisiuntimas vyksta per IMAP arba POP3.
• Siunčiantysis serveris užklausia domeno, esančio po @, MX įrašų. Null MX (0 .) reiškia: šis domenas negauna pašto.
• Laiškas, kurio nepavyksta iš karto pristatyti, lieka eilėje ir yra bandomas pristatyti iš naujo kelias dienas.
• Vokas (Return-Path) ir kopregelės (From) yra du skirtingi siuntėjai. SPF tikrina pirmąjį, naudotojas mato antrąjį.

Testas

Užduotis

Užduotis Z1.1: Pirmojo pašto serverio paieška. Raskite gmail.com (arba savo domeno) MX įrašus. Nurodykite, kuris serveris bandomas pirmiausia, jo prioriteto skaičių ir vieną to serverio IP adresą (IPv4 arba IPv6). Programa tuos pačius duomenis užklausia tiesiogiai ir patikrina.

Papildomai paskaityti

Šiuose straipsniuose aprašyti žingsniai galioja WebOké valdymo skydeliams; pas kitus paslaugų teikėjus veikia panašiai.

• Kaip siunčiami el. laiškai (SMTP)
• DirectAdmin vadovas 8.7: IMAP arba POP3: kuo skiriasi?
• Nemokamas DNS kursas 4.1: MX įrašai ir prioritetas
• RFC 5321 (SMTP), 5.1 paragrafas (MX ir numanomas MX) ir 4.5.4.1 (bandymas iš naujo); RFC 7505 (null MX)