6. modulis · 6.3
Pasts nenonāk: soli pa solim
6. modulis: Kļūdu paziņojumi un problēmu risināšana · Lasīšanas laiks: 11 minūtes
Mācību mērķis: Pēc šīs nodarbības Jūs varēsiet sistemātiski noskaidrot, kāpēc kāds e-pasts nenonāk galā vai nonāk surogātpasta mapē, gan kā sūtītājs, gan kā saņēmējs, un zināsiet, kādi dati Jums būs vajadzīgi, ja lūgsiet palīdzību.
Pamatjēdzieni: sūtītāja puse un saņēmēja puse, atlēciena paziņojums (bounce), pasta žurnāls jeb e-pasta izsekošana, surogātpasta mape, noteikumi un filtri, testa vēstule uz savu ārējo adresi, Authentication-Results, testēšanas rīki, kad risinājums ir saņēmēja ziņā
Vispirms pareizais jautājums
"Mans e-pasts nenonāk galā" var nozīmēt dažādas lietas:
- vēstule nekad nav nosūtīta (paliek mapē Izejošie, programmā parādās kļūdas paziņojums);
- vēstule ir nosūtīta, bet atgriezusies ar atlēciena paziņojumu (bounce);
- vēstule ir piegādāta, bet saņēmējam tā nonāk surogātpastā vai citā mapē;
- vēstule ir piegādāta, bet saņēmējs to nevar atrast vai apgalvo, ka nav to saņēmis;
- Jūs pats vairs nesaņemat vēstules no viena vai vairākiem sūtītājiem.
Katrai no šīm situācijām ir cits sākumpunkts. Zemāk redzamais soļu plāns darbojas kā lēmumu koks: pēc katra soļa Jūs zināt vairāk, un bieži vien pēc diviem vai trim soļiem problēma ir skaidra.
Kā sūtītājam: septiņi soļi
1. solis. Vai vēstule tiešām ir nosūtīta?
Vai tā ir mapē Nosūtītie (Sent)? Vai tā vēl ir mapē Izejošie, vai arī Jūsu programma parādīja kļūdas paziņojumu? Tad problēma ir sūtīšanas posmā pie Jums: servera nosaukums, ports, pieteikšanās, parole vai pārāk liels pielikums (nodarbība 1.4, 2.1). Pārbaudiet tīmekļa pastā (webmail): ja tur nosūtīšana izdodas, problēma ir Jūsu programmā.
2. solis. Vai pienāca atlēciena paziņojums (bounce)?
Apskatiet savu iesūtni (un surogātpasta mapi) ziņām no Mailer-Daemon vai Mail Delivery System. Ja tāda atrodas, izlasiet to (nodarbība 6.1) un sameklējiet kodu (nodarbība 6.2). Vairumā gadījumu šeit jau noskaidrosiet cēloni.
3. solis. Nav atlēciena paziņojuma: ko saka pasta žurnāls?
Meklējiet vēstuli sava pakalpojumu sniedzēja žurnālā. Hostinga vadības panelī to bieži sauc par e-pasta izsekošanu vai pasta žurnālu, Microsoft 365 vidē ziņojumu izsekošanu (message tracing), Google Workspace vidē e-pasta žurnālu. Jūs redzēsiet:
| Statuss | Nozīme | Nākamais solis |
|---|---|---|
| Piegādāts | Saņēmēja serveris ir pieņēmis vēstuli (kods 250) | 4. solis: tagad atbildība ir saņēmēja pusē |
| Atlikts | Saņēmējs (vēl) nav to pieņēmis, mēģinājums tiek atkārtots | Apskatiet iemeslu; bieži tā ir pagaidu palēnināšana (nodarbība 6.4) |
| Neveiksmīgs | Galīgi noraidīts | Ir arī atlēciena paziņojums; izlasiet iemeslu |
| Nav atrodams | Jūsu serveris vēstuli nekad nav saņēmis | Atgriezieties pie 1. soļa, vai arī vēstule tika sūtīta caur citu pakalpojumu (vietni, jaunumu vēstuli) |
4. solis. Piegādāts, bet saņēmējs to neredz.
Pēc koda 250 vēstule atrodas saņēmēja pusē. Saņēmējs var to ievietot surogātpastā, karantīnā pie sava pasta administratora vai pārvietot ar kādu noteikumu. Lūdziet saņēmējam apskatīties mapē Spam vai Nevēlamie e-pasti, citās mapēs, kā arī noskaidrot, vai administratoram ir kāda karantīna. Jūs pats to redzēt nevarat.
5. solis. Pārbaudiet savu domēnu.
Vai Jūsu vēstules biežāk nonāk surogātpastā, vai nenonāk pie viena konkrēta liela saņēmēja? Pārbaudiet SPF, DKIM un DMARC ar kādu rīku (E-pasta pārbaudi, Domēna veselību, internet.nl vai MXToolbox). Pievērsiet uzmanību jo īpaši:
- tieši vienam SPF ierakstam, kas nepārsniedz desmit uzmeklēšanas, un kas ietver visus pakalpojumus, kuri sūta pastu (nodarbība 4.2);
- DKIM atslēgai pie selektora, kas norādīts Jūsu vēstulē (nodarbība 4.3);
- DMARC ierakstam, un kāda politika tajā norādīta (nodarbība 4.4).
6. solis. Nosūtiet testa vēstuli un izlasiet galvenes.
Nosūtiet to pašu vēstuli (ar to pašu sūtītāju un vēlams arī to pašu saturu) uz savu adresi Gmail un Outlook.com vidē. Atveriet tur galvenes (Gmail vidē: "Rādīt oriģinālu"). Apskatiet Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=x header.b=Ab12Cd34;
spf=pass (google.com: domain of info@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=info@example.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.comJa visur redzams pass (trīs reizes), autentifikācija ir kārtībā, un nonākšana surogātpastā ir saistīta ar reputāciju vai saturu. Ja redzams fail, softfail, none vai temperror, Jūs zināt, kas jālabo. Testēšanas pakalpojumi, piemēram, mail-tester, sniedz līdzīgu pārskatu ar novērtējumu.
7. solis. Apskatiet nosūtīšanas serveri.
Kurš IP adrese piegādāja vēstuli (nodarbība 5.1)? Vai tai ir pareizs PTR ieraksts? Vai tā ir kādā bloķēšanas sarakstā (nodarbība 5.2)? Vai tā ir Jūsu pakalpojumu sniedzēja adrese, vai Jūsu paša interneta pieslēguma adrese? Ja tas ir paša pieslēgums, tas nozīmē, ka Jūsu programma nenosūta pastu caur pakalpojumu sniedzēja serveri.
Kā saņēmējam: seši soļi
Ja Jūs pats vairs nesaņemat pastu, vai trūkst vēstuļu no viena sūtītāja:
- Apskatieties tīmekļa pastā (webmail), arī mapēs Spam un Nevēlamie. Ja vēstule tur ir, problēma ir Jūsu programmā vai tālrunī (parole, POP3 citā ierīcē, kas izņem pastu, kāds noteikums; nodarbība 1.3, 3.1).
- Vai Jūsu pastkaste vai pakete ir pilna? Pilna pastkaste noraida jaunas vēstules (nodarbība 3.2).
- Filtri un noteikumi: surogātpasta filtrs, kas surogātpastu uzreiz dzēš, bloķēts sūtītājs, servera noteikums, kas pāradresē.
- Vai Jūsu MX ieraksts ir pareizs? Vai tas norāda uz serveri, kur atrodas Jūsu pastkaste? Pēc pārcelšanās vai savienošanas ar Microsoft 365 vai Google Workspace šeit bieži rodas kļūda (DNS kursa nodarbība 4.1, nodarbība 8.2).
- Vai šai adresei ir iestatīta pāradresācija? Tad vēstule nonāk tur, nevis Jūsu pastkastē (nodarbība 3.3).
- Lūdziet sūtītājam viņa atlēciena paziņojumu. Tas precīzi parāda, ko atbildēja Jūsu serveris.
Kad risinājums ir citas puses ziņā?
Visu pats atrisināt nevarat. Lūk, kā saprast, kad problēma ir kādam citam:
- Saņēmēja ziņā ir, ja: pastkaste pilna, adrese likvidēta, vēstule piegādāta, bet atrodas viņa surogātpastā vai karantīnā. Lūdziet viņam saglabāt Jūsu adresi kā drošu sūtītāju vai kontaktpersonu.
- Jūsu pakalpojumu sniedzēja ziņā ir, ja: nosūtīšanas serveris atrodas kādā bloķēšanas sarakstā, tam nav pareiza PTR ieraksta, vai kāds liels saņēmējs to palēnina vai bloķē. Nosūtiet līdzi pilnu atlēciena paziņojumu.
- Pakalpojuma, kas sūta Jūsu vārdā (interneta veikals, grāmatvedības programma, jaunumu vēstuļu pakalpojums), ziņā ir, ja: šī pakalpojuma vēstules neiztur SPF vai DKIM pārbaudi. Šis pakalpojums Jums sniegs pareizos ierakstus.
Palīdzības lūgšana: ko nosūtīt līdzi?
Ar šiem datiem jebkurš atbalsta dienests var vēstuli uzreiz atrast:
- sūtītāja adresi un saņēmēja adresi;
- nosūtīšanas datumu un laiku (ar laika joslu);
- pilnu atlēciena paziņojumu vai rindiņu ar kodu;
- ja vēstule ir nonākusi galā, bet atrodas surogātpastā: tās vēstules pilnas galvenes;
- kuru pasta programmu vai pakalpojumu izmantojāt.
Nekad nesūtiet līdzi savu paroli. Neviens nopietns pakalpojumu sniedzējs to nekad neprasīs.
Praksē: tā tas izskatās
WebOké vidē 3. soli atradīsiet DirectAdmin sadaļā E-mail Tracking, bet 5. soli Mans WebOké vidē kartītē Set E-mail vai Domain / Email veselība. Ja Jums nav konta, izmantojiet publiski pieejamo E-pasta pārbaudi un Domēna veselību vietnē weboke.nl. Pie citiem pakalpojumu sniedzējiem šīs sadaļas sauc citādi, taču gandrīz katrā vadības panelī ir pasta žurnāls un DNS pārvaldība, un neatkarīgie rīki darbojas ar jebkuru domēnu.
Kopsavilkums
- Vispirms noskaidrojiet, ko tieši nozīmē "nenonāk galā": nav nosūtīts, atlēciena paziņojums, piegādāts, bet surogātpastā, vai Jūs pats nesaņemat.
- Sūtītājs: nosūtīts? atlēciena paziņojums? pasta žurnāls? piegādāts = risinājums saņēmēja ziņā; tad domēns, testa vēstule ar galvenēm, nosūtīšanas serveris.
- Saņēmējs: tīmekļa pasts, vieta, filtri, MX, pāradresācija, atlēciena paziņojums no sūtītāja.
Authentication-Resultstesta vēstulē uzreiz parāda, vai SPF, DKIM un DMARC iztur pārbaudi.- Ja lūdzat palīdzību, nosūtiet līdzi adreses, laiku un pilnu atlēciena paziņojumu vai galvenes.
Tests
Uzdevums
Uzdevums O6.3: Problēmas izsekošana. Izvēlieties reālu problēmu no savas vides (vēstuli, kas nenonāca galā vai nonāca surogātpastā), vai izmantojiet mācību gadījumu "rēķini uz Hotmail nonāk tikai pēc dienas". Izejiet cauri soļu plānam un pierakstiet, ko atradāt katrā solī. Noslēgumā atbildiet: kur bija problēma, kura puse rīkojās, un ko Jūs darījāt vai prasījāt? Pēc tam redzēsiet kontrolsarakstu un parauga atbildi mācību gadījumam.
Uzdevums O6.3: Problēmas izsekošana
Izejiet cauri nodarbības 6.3 soļu plānam ar savu problēmu, vai izmantojiet mācību gadījumu: grāmatvedības birojs sūta rēķinus no savas pastkastes. Klienti ar Hotmail adresi tos dažreiz saņem tikai pēc dienas, Gmail klienti uzreiz. Atsitiens (bounce) nenāk, bet pēc 24 stundām nāk brīdinājums delayed (bounce-2.txt).
Fails šim uzdevumam: bounce-2.txt
Praktikas gadījums: nosūtīts (mapē Nosūtītie); nav atgriezts ziņojums, bet aizkaves ziņojums ar 451 4.7.500; pasta žurnālā "atlikts" ar to pašu iemeslu; SPF, DKIM un DMARC ir kārtībā (nav cēlonis); Microsoft palēnina nosūtīšanas servera IP adresi. Rīkoties ir jāsūta serverim (pakalpojumu sniedzējam). Ziņojiet par to ar aizkaves ziņojumu, nesūtiet atkārtoti, un steidzamiem rēķiniem vienojieties par citu maršrutu, ja nepieciešams.
Jūsu atzīmes un piezīmes paliek tikai šajā pārlūkprogrammā; mēs tās nekur nesūtām. Ja esat pieteikušies, sadaļā Mani kursi saglabājam tikai to, ka uzdevums ir paveikts.
Papildu lasāmviela
Šajos rakstos aprakstītie soļi attiecas uz WebOké vadības paneļiem; pie citiem pakalpojumu sniedzējiem process ir līdzīgs.
- Jūsu e-pasts nenonāk pie adresāta vai nonāk mēstuļu mapē: kā to noskaidrot
- Vairs nesaņemat e-pastu: šādi noskaidrojiet cēloni
- Es nevaru nosūtīt e-pastu (saņemšana gan darbojas)
- Pārbaude, vai e-pasts ir piegādāts, ar Email Tracking DirectAdmin
- WebOké rokasgrāmata 7.4: E-pasts nenonāk: pārbaudiet to pats
- DirectAdmin rokasgrāmata 9.4: Mana pasta nonāk saņēmējam surogātpastā
- Domēna veselība (jebkura domēna bezmaksas pārbaude): https://www.weboke.lv/domena-veseliba
