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 apibūdinti, kaip laiškas nukeliauja nuo siuntėjo iki gavėjo, 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ė, atsiėmimas (IMAP/POP3), vokas (envelope), antraštės

Paštas yra siunta, o ne pokalbio žinutė

Kai siunčiate pokalbio žinutę, ji keliauja per vieną įmonę: siuntėjo ir gavėjo programėlės kalbasi 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 įmonę, kitas Gmail, trečias Microsoft 365 ar savo įmonės serveryje. Vis dėlto laiškas pasiekia adresatą. Tai įmanoma todėl, kad visi pasaulio pašto serveriai laikosi tų pačių susitarimų.

El. paštą galima puikiai palyginti su paprastu paštu. Rašote laišką (žinutę), įdedate jį į voką su adresu (tai yra vokas, envelope), nunešate jį į pašto dėžutę (siuntimo serveris), pašto įmonė nustato, kur yra tas adresas (MX 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: Agnė siunčia laišką iš agne@example.com gavėjui jonas@example.net. Štai kas tada vyksta:

Pas mažesnius paslaugų teikėjus MSA, MTA ir MDA dažnai yra viena ir ta pati programa viename serveryje. Pas didelius teikėjus tai atskiri klasteriai. Jums tai didelės reikšmės neturi: tai yra vaidmenys, o ne atskiri įrenginiai.

Atkreipkite dėmesį į skirtumą tarp 1 ir 4 žingsnio. Abiem atvejais naudojamas SMTP, tai yra Simple Mail Transfer Protocol (RFC 5321). Tačiau 1 žingsnyje Jūs prisijungiate ir naudojate prievadą 587 arba 465; tai vadinama submission (RFC 6409). 4 žingsnyje du serveriai kalbasi tarpusavyje prievadu 25, neprisijungdami: gaunantysis serveris priima paštą savo domenams nuo bet kurio siuntėjo. Pamokoje 1.4 pamatysite, kodėl toks atskyrimas egzistuoja.

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

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

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, mx2. Po to jis pasiteirauja to pavadinimo IP adreso (A arba AAAA įrašas) ir užmezga ryšį.

Du ypatingi atvejai, su kuriais susidursite praktikoje:

• MX įrašo nėra. Tokiu atveju siuntėjas bando domeno paties A arba AAAA įrašą (vadinamasis „implicitinis MX" iš RFC 5321, 5.1 skyriaus). Tai yra senovės liekana, kuri veikia nepatikimai; 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 tokį įrašą. Siuntėjas tuomet iškart pasiduoda ir grąžina klaidos pranešimą, užuot bandęs toliau kelias dienas.

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

Eilė: el. paštui pristatymas 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 vėliau bando dar kartą, kaskart palikdamas vis didesnį laiko tarpą. RFC 5321 (4.5.4.1 skyrius) rekomenduoja tarp bandymų daryti bent 30 minučių pertrauką ir pasiduoti tik po 4-5 dienų. Daugelis serverių po kelių valandų jau iš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 valandai sugenda, joks laiškas neprarandamas. Tai taip pat paaiškina, kodėl kartais laiškas pasiekia adresatą tik po kelių valandų. 6 modulyje pamatysite, kaip atpažinti tokį vėlavimą.

Vokas ir antraštės: du adresai

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

• Vokas (envelope). Tai adresai, kuriuos serveriai naudoja tarpusavio SMTP pokalbyje: MAIL FROM (siuntėjas klaidos pranešimams, vėliau matomas kaip Return-Path) ir RCPT TO (gavėjas). Serveriai pristato laišką remdamiesi voku (envelope sender).
• Antraštės (headers). Tai yra tai, kas rašoma 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 antraštėse; todėl kiti jo nemato. Naujienlaiškių paslauga savo adresą nurodo kaip voko siuntėją (envelope sender), kad klaidos pranešimai pasiektų ją pačią, tuo tarpu From: lauke yra Jūsų adresas. O sukčius gali From: lauke nurodyti ką tik nori.

Kodėl tai svarbu: SPF tikrina voko siuntėją (envelope sender), o naudotojas mato From: lauką. Todėl egzistuoja DMARC, kuris tuos du dalykus susieja (4 modulis).

Kur gali nutikti klaida

Turėdami šį modelį, kiekvienos problemos atveju galite klausti: kurioje stotelėje kilo problema?

• Siuntimas nepavyksta (klaidos pranešimas iškart Jūsų programoje): 1 arba 2 žingsnis. Beveik visada tai nustatymai: prievadas, prisijungimas, slaptažodis (2 modulis).
• Gaunate grąžintą laišką (bounce): 3 arba 4 žingsnis. Gaunantysis serveris atmetė laišką arba toks 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 negauna, o Jūs negaunate jokio klaidos pranešimo: laiškas galbūt dar yra eilėje arba buvo tyliai nufiltruotas gavėjo pusėje. Čia padeda siuntimo serverio žurnalai (6 modulis).
• Į Jūsų domeną niekas nepatenka: 3 žingsnis. MX įrašai yra neteisingi, pavyzdžiui, po perkėlimo (8 modulis).

Praktikoje: kaip tai atrodo prieglobos pakete

WebOké prieglobos pakete vienas serveris kiekviename pakete atlieka visus vaidmenis: Jūsų pašto programa pristato laišką tam serveriui (1 ir 2 žingsniai), serveris išsiunčia jį į išorę (3 ir 4 žingsniai) ir priima paštą Jūsų domenui (5 žingsnis). DirectAdmin valdymo skydelyje su El. pašto sekimo įrankiu galite pamatyti, ar konkretus laiškas buvo pristatytas. Pas kitus paslaugų teikėjus tai 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čio serverio (MTA/MDA), o iš ten, į gavėjo pašto programą.
• Siuntimas iš Jūsų programos yra SMTP-submission su prisijungimu (587/465); serveriai tarpusavyje kalbasi SMTP protokolu prievadu 25; atsiėmimas vyksta naudojant IMAP arba POP3.
• Siunčiantysis serveris ieško domeno, esančio po @ ženklo, MX įrašų. Null MX (0 .) reiškia: šis domenas negauna pašto.
• Laiškas, kurio nepavyksta iškart pristatyti, lieka eilėje ir bandomas pristatyti iš naujo kelias dienas.
• Vokas (Return-Path) ir antraštė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. Suraskite domeno 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 patikrins realiuoju laiku.

Platesniam skaitymui

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

• El. laiškų siuntimo proceso / SMTP paaiškinimas
• DirectAdmin vadovas 8.7: IMAP arba POP3: kuo skiriasi?
• Nemokamas DNS kursas 4.1: MX įrašai ir prioritetas
• RFC 5321 (SMTP), 5.1 skyrius (MX ir implicitinis MX) bei 4.5.4.1 (bandymas iš naujo); RFC 7505 (null MX)