Visbiežāk pieļautās kļūdas

8. modulis: Pārcelšanās un Jūsu domēna sakārtošana · Lasīšanas laiks: 13 minūtes

Mācību mērķis: Pēc šīs nodarbības Jūs varēsiet pēc pazīmēm atpazīt divpadsmit biežāk pieļautās e-pasta kļūdas, izskaidrot, kāpēc tās rodas, un tās novērst.

Pamatjēdzieni: dubults SPF ieraksts, pārāk daudz SPF uzmeklējumu, DMARC pāragri iestatīts uz reject, DKIM nav ieslēgts pie nosūtīšanas pakalpojuma, pāradresācija uz Gmail, catch-all, apmeklētāja adrese kā sūtītājs, izejošais serveris bez autentifikācijas, mail. servera nosaukums bez atbilstoša sertifikāta, pilna pastkaste, MX aizmirsts pārcelšanās laikā, POP3 vairākās ierīcēs

Kā izmantot šo nodarbību

Katrai kļūdai ir vienāda uzbūve: ko Jūs redzat (pazīme, kā klients to apraksta), kāpēc tas notiek, un kā to novērst. Bieži pazīmes ir līdzīgas ("mans e-pasts nenonāk galā"), bet cēlonis ir pavisam cits. Tāpēc pie katras kļūdas ir arī norādīts, kā to apstiprināt: kādus pierādījumus meklēt, pirms kaut ko mainīt. Neminiet, vispirms izmēriet (nodarbība 6.3).

Numurus izmantosiet uzdevumā.

Kļūdas DNS

1. kļūda: divi SPF ieraksti.
Jūs redzat: e-pasti uz Gmail un Outlook.com pēkšņi nonāk mēstuļu mapē, kopš esat pievienojis jaunu pakalpojumu (Microsoft 365, jaunumu vēstuli, grāmatvedības programmu). Galvenēs ir redzams spf=permerror.
Kāpēc: pakalpojums teica "pievienojiet šo SPF ierakstu", un tagad ir divi TXT ieraksti, kas sākas ar v=spf1. Saskaņā ar RFC 7208 tā ir pastāvīga kļūda: SPF vairs vispār netiek ņemts vērā.
Apstipriniet: uzmeklējiet sava domēna TXT ierakstus un saskaitiet v=spf1 ierakstus.
Risinājums: apvienojiet visu vienā ierakstā (nodarbība 4.2).

2. kļūda: vairāk nekā desmit SPF uzmeklējumi.
Jūs redzat: to pašu, spf=permerror, bet ir tikai viens ieraksts. Bieži pēc kārtējā include pievienošanas.
Kāpēc: katrs include, a, mx, exists un redirect maksā vienu DNS uzmeklējumu, arī tie, kas atrodas pašos include ierakstos. Virs desmit SPF kļūst nederīgs.
Apstipriniet: izmantojiet SPF pārbaudi, kas rekursīvi saskaita uzmeklējumus (uzdevums Z4.2).
Risinājums: noņemiet pakalpojumus, ko vairs neizmantojat, aizstājiet a un mx ar ip4/ip6, ja tie ir nemainīgi, vai ļaujiet pakalpojumam sūtīt caur savu atgriezenisko (bounce) apakšdomēnu (nodarbība 7.1).

3. kļūda: DMARC uzreiz iestatīts uz p=reject.
Jūs redzat: kopš ir iestatīts DMARC ieraksts, rēķini no grāmatvedības programmas vai vietnes e-pasti vairs nenonāk galā. Saņēmēji atbild ar 550 5.7.1 ar atsauci uz DMARC.
Kāpēc: ne visi sūtītāji bija ņemti vērā. Viss, kas nenāk caur saskaņotu (aligned) SPF vai DKIM, tagad tiek noraidīts.
Apstipriniet: DMARC ieraksts un pārskati (nodarbība 4.5): kuri avoti neiztur pārbaudi?
Risinājums: atgriezieties pie p=none ar pārskata adresi, salabojiet visus sūtītājus, tad soli pa solim pārejiet uz quarantine un reject (nodarbība 4.4). Tā arī ir šī kursa ieteicamā pieeja.

4. kļūda: DKIM nav iestatīts pie nosūtīšanas pakalpojuma.
Jūs redzat: jaunumu vēstules arvien vairāk saņēmēju starpā nenonāk iesūtnē. Galvenēs: dkim=pass header.d= pakalpojuma domēns, dmarc=fail.
Kāpēc: pakalpojums paraksta ar savu domēnu, tāpēc DMARC nevar iztur pārbaudi caur DKIM, un arī SPF nav saskaņots.
Apstipriniet: testa jaunumu vēstules galvenes (uzdevums Z7.1).
Risinājums: autentificējiet savu domēnu pie pakalpojuma (DKIM caur CNAME, nodarbība 7.1).

Kļūdas ar pāradresāciju un adresēm

5. kļūda: visa pāradresācija uz Gmail.
Jūs redzat: e-pasti no dažiem sūtītājiem nenonāk Gmail adresē, uz kuru pāradresējat savu darba e-pastu, vai nonāk mēstuļu mapē. Dažkārt sūtītāji saņem atgriezenisko paziņojumu (bounce) no Gmail.
Kāpēc: pāradresējot, e-pasts Gmail pienāk no Jūsu servera, kas nav iekļauts sākotnējā sūtītāja SPF ierakstā. Bez DKIM vai ar sūtītāju, kuram ir p=reject, DMARC neiztur pārbaudi. Turklāt pāradresēta mēstule Gmail acīs izskatās kā mēstule, ko sūtāt Jūs, kas kaitē Jūsu reputācijai.
Apstipriniet: atgriezeniskais paziņojums vai galvenes Gmail (spf=fail vai softfail ar Jūsu serveri kā avotu).
Risinājums: nepāradresējiet, bet pievienojiet pastkasti Gmail lietotnē telefonā, izmantojot IMAP (nodarbība 2.4 un 3.3).

6. kļūda: catch-all.
Jūs redzat: daudz mēstuļu uz adresēm, kas nekad nav pastāvējušas (xyz123@example.com), un pilna pastkaste.
Kāpēc: catch-all pieņem e-pastu jebkurai iedomājamai adresei. Mēstuļu sūtītāji izmēģina nejaušas adreses, un visas tās nonāk iekšā. Ja catch-all vēl arī pāradresējat uz ārpusi, rodas 5. kļūda lielā mērogā.
Apstipriniet: pastkastē apskatiet, uz kurām saņēmēja adresēm mēstules tika sūtītas.
Risinājums: izslēdziet catch-all, un katrai reāli izmantotai adresei izveidojiet aliasu vai pastkasti (nodarbība 3.3).

7. kļūda: apmeklētāja adrese kā sūtītājs formā.
Jūs redzat: ziņas no kontaktformas dažkārt nonāk galā, dažkārt nē, īpaši no apmeklētājiem ar adresi pie lielas pakalpojumu sniedzēja.
Kāpēc: Jūsu vietne nosūta e-pastu "apmeklētāja vārdā", izmantojot viņa domēnu. Ja tam domēnam ir p=reject vai p=quarantine, saņēmējs noraida vai filtrē e-pastu (nodarbība 7.3).
Apstipriniet: apskatiet, kādu From formas lauks izmanto.
Risinājums: savu adresi laukā From, apmeklētāju laukā Reply-To.

Kļūdas iestatīšanā

8. kļūda: izejošais serveris bez autentifikācijas.
Jūs redzat: saņemšana darbojas, sūtīšana nē. Paziņojums, piemēram, "relay access denied", "authentication required" vai 550 5.7.1. iPhone bieži: izejošā servera lauki atstāti tukši ("izvēles").
Kāpēc: izejošais serveris pārsūta e-pastu tikai tiem, kas pieteikušies. Citādi jebkurš varētu to izmantot kā mēstuļu raidītāju.
Apstipriniet: izejošā servera iestatījumi pasta programmā.
Risinājums: ieslēdziet autentifikāciju ar pilnu e-pasta adresi un paroli, portu 587 ar STARTTLS vai 465 ar SSL/TLS (nodarbība 1.4 un 2.3).

9. kļūda: mail.<domeins> kā servera nosaukums bez atbilstoša sertifikāta.
Jūs redzat: paziņojumu par nederīgu sertifikātu vai "nevar pārbaudīt servera identitāti", vai savienojums vispār neizdodas.
Kāpēc: programma pārbauda, vai servera nosaukums ir norādīts sertifikātā. mail.example.com varbūt norāda uz serveri, bet nav minēts sertifikātā. Vai arī nosaukums pēc pārcelšanās joprojām norāda uz veco pakalpojumu sniedzēju.
Apstipriniet: pārbaudiet pasta portus kopā ar servera nosaukumu (uzdevums Z2.1 un Z8.4).
Risinājums: izmantojiet servera nosaukumu, ko norāda pakalpojumu sniedzējs, un nekad vienkārši neklikšķiniet uz "tomēr turpināt" (nodarbība 2.1).

10. kļūda: pilna pastkaste.
Jūs redzat: sūtītāji saņem atgriezenisko paziņojumu (bounce) ar 452 4.2.2 vai 552 5.2.2 (pastkaste pilna). Jūs pats nemanāt neko, vai tikai to, ka vairs nepienāk jauns e-pasts.
Kāpēc: pastkaste ir sasniegusi savu kvotu. Bieži gadu gaitā uzkrātu pielikumu dēļ, vai tāpēc, ka mapes Sent un Trash nekad netiek iztukšotas.
Apstipriniet: pastkastes izmantojums panelī vai tīmekļa pastā.
Risinājums: sakārtojiet, arhivējiet, vai palieliniet kvotu (nodarbība 3.2).

Kļūdas pārcelšanās laikā

11. kļūda: MX aizmirsts pārcelšanās laikā.
Jūs redzat: pēc vietnes vai domēna pārcelšanas vairs nepienāk e-pasts, vai tas pienāk vietā, kur neviens neskatās. Vai pretēji: esat pārcēlis e-pastu uz jaunu pakalpojumu sniedzēju, bet MX joprojām norāda uz veco.
Kāpēc: nomainot nosaukumu serverus, visa zona tiek pārcelta līdzi. Ja pasta pakalpojumu sniedzēja MX ieraksti nav iekļauti jaunajā zonā, Jūsu e-pasts norāda uz jauno tīmekļa serveri. Vai arī MX nekad nav mainīts.
Apstipriniet: pieprasiet MX no autoritatīvā nosaukumu servera (uzdevums Z8.2).
Risinājums: ievietojiet pareizos MX ierakstus zonā, kas tiešām ir aktīva, un pēc tam vēlreiz kopējiet e-pastu (nodarbība 8.2).

12. kļūda: POP3 vairākās ierīcēs.
Jūs redzat: e-pasts ir klēpjdatorā, bet ne telefonā, vai pretēji. Pēc klēpjdatora nomaiņas pazuduši gadiem uzkrāti e-pasti.
Kāpēc: POP3 iegūst e-pastu no servera uz vienu ierīci un bieži to tur izdzēš (nodarbība 1.3).
Apstipriniet: konta veids pasta programmā.
Risinājums: pārejiet uz IMAP; e-pastu, kas atrodas tikai lokāli, vispirms pārvelciet uz IMAP pastkasti.

Kas šīm kļūdām ir kopīgs

Apskatiet sarakstu vēlreiz. Gandrīz katra kļūda rodas, jo kāds sekoja atsevišķai instrukcijai ("pievienojiet šo ierakstu", "ieslēdziet pāradresāciju"), neredzot kopainu. Šī kursa galvenā doma:

• zināt, kas sūta e-pastu Jūsu domēna vārdā (uzskaite, nodarbība 4.2 un 8.1);
• mainīt vienu lietu vienlaikus un pēc tam pārbaudīt;
• lasīt pierādījumus: atgriezenisko paziņojumu (nodarbība 6.1), galvenes (nodarbība 1.5), DMARC pārskatu (nodarbība 4.5) un DNS pie autoritatīvā servera.

Kopsavilkums

• DNS kļūdas: divi SPF ieraksti, pārāk daudz uzmeklējumu, DMARC pāragri iestatīts uz reject, DKIM nav ieslēgts pie nosūtīšanas pakalpojuma.
• Adrešu kļūdas: pāradresācija uz Gmail, catch-all, apmeklētāja adrese laukā From.
• Iestatīšanas kļūdas: nav autentifikācijas izejošajam pastam, servera nosaukums, kas nav minēts sertifikātā, pilna pastkaste.
• Pārcelšanās kļūdas: MX aizmirsts, POP3 vairākās ierīcēs.
• Vienmēr apstipriniet cēloni ar pierādījumiem, pirms kaut ko maināt.

Tests

Uzdevums

Uzdevums Z8.3: Kāda ir kļūda? Jūs saņemsiet astoņus īsus gadījumus, katram ar pazīmi un nelielu pierādījumu gabalu (galveni, atgriezenisko paziņojumu, DNS atbildi vai iestatījumu). Katram gadījumam izvēlieties kļūdas numuru (no 1 līdz 12). Programma pārbauda ar fiksētu atslēgu un, ja atbilde ir nepareiza, parāda, kādu pierādījumu Jūs palaidāt garām.

Vairāk lasīt

Šajos rakstos aprakstītie soļi attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem process ir līdzīgs.

• DirectAdmin rokasgrāmata 18.9: Es vairs nesaņemu e-pastu
• DirectAdmin rokasgrāmata 18.10: Es nevaru nosūtīt e-pastu
• Vairs nesaņemat e-pastu: šādi noskaidrojiet cēloni
• Es nevaru nosūtīt e-pastu (saņemšana gan darbojas)
• E-pasta pārsūtīšana uz citu adresi (forwarders, catch-all adrese nav ieteicama)
• Bezmaksas DNS kurss 8.4: Biežāk pieļautās kļūdas