Veelgemaakte fouten

Modul 8: Selitev in urejenost Vaše domene · Čas branja: 13 minut

Cilj učenja: Po tej lekciji boste znali prepoznati dvanajst najpogostejših napak pri e-pošti po njihovih znakih, pojasniti, zakaj pride do njih, in jih odpraviti.

Ključni pojmi: dvojni zapis SPF, preveč poizvedb SPF, DMARC prehitro na reject, DKIM ni vklopljen pri ponudniku pošiljanja, preusmeritev na Gmail, catch-all, obiskovalec kot pošiljatelj, odhodni strežnik brez avtentikacije, ime strežnika mail. brez ustreznega certifikata, poln poštni predal, pozabljen MX ob selitvi, POP3 na več napravah

Kako uporabljati to lekcijo

Vsaka napaka ima enako zgradbo: kaj vidite (znak, kot ga sporoči stranka), zakaj pride do napake in kako jo odpravite. Znaki so si pogosto podobni ("moja pošta ne prispe"), medtem ko je vzrok povsem drugačen. Zato je pri vsaki napaki navedeno tudi, kako jo potrdite: kateri dokaz morate poiskati, preden kaj spremenite. Ne ugibajte, najprej izmerite (lekcija 6.3).

Številke boste uporabili v nalogi.

Napake v DNS

Napaka 1: dva zapisa SPF.
Vidite: pošta na Gmail in Outlook.com nenadoma pristane v neželeni pošti, odkar ste povezali novo storitev (Microsoft 365, novičnik, računovodski program). V glavah je spf=permerror.
Zakaj: storitev je rekla "dodajte ta zapis SPF", in zdaj obstajata dva zapisa TXT, ki se začneta z v=spf1. Po RFC 7208 je to trajna napaka: SPF se sploh več ne upošteva.
Potrdite: poiščite zapise TXT Vaše domene in preštejte zapise v=spf1.
Rešitev: združite vse v en sam zapis (lekcija 4.2).

Napaka 2: več kot deset poizvedb SPF.
Vidite: enako, spf=permerror, vendar obstaja samo en zapis. Pogosto po dodajanju še enega zapisa include.
Zakaj: vsak include, a, mx, exists in redirect šteje eno poizvedbo DNS, tudi znotraj zapisov include. Nad deset je SPF neveljaven.
Potrdite: preverite SPF z rekurzivnim štetjem (naloga Z4.2).
Rešitev: odstranite storitve, ki jih ne uporabljate več, nadomestite a in mx z ip4/ip6, če so fiksni, ali naj storitev pošilja prek lastne poddomene za povratna sporočila (lekcija 7.1).

Napaka 3: DMARC takoj nastavljen na p=reject.
Vidite: odkar je nastavljen zapis DMARC, računi iz računovodskega programa ali pošta s spletnega mesta ne prispejo več. Prejemniki vrnejo 550 5.7.1 s sklicem na DMARC.
Zakaj: niso bili upoštevani vsi pošiljatelji. Kar ne prihaja prek usklajenega (alignment) SPF ali DKIM, se zdaj zavrne.
Potrdite: zapis DMARC in poročila (lekcija 4.5): kateri viri ne uspejo?
Rešitev: vrnite se na p=none z naslovom za poročila, popravite vse pošiljatelje, nato pa postopoma preidite na quarantine in reject (lekcija 4.4). To je tudi priporočena pot v tem tečaju.

Napaka 4: DKIM ni nastavljen pri ponudniku pošiljanja.
Vidite: novičniki pri vedno več prejemnikih ne pridejo v mapo »Prejeto«. V glavah: dkim=pass header.d= domena ponudnika, dmarc=fail.
Zakaj: ponudnik podpisuje s svojo lastno domeno, zato DMARC ne more uspeti prek DKIM, SPF pa prav tako ni usklajen.
Potrdite: glave testnega novičnika (naloga Z7.1).
Rešitev: avtenticirajte svojo domeno pri ponudniku (DKIM prek CNAME, lekcija 7.1).

Napake pri preusmeritvi in naslovih

Napaka 5: preusmeritev vsega na Gmail.
Vidite: pošta nekaterih pošiljateljev ne prispe na naslov Gmail, kamor pošiljate svojo poslovno pošto, ali pa pristane v neželeni pošti. Včasih pošiljatelji od Gmaila dobijo povratno sporočilo (bounce).
Zakaj: pri preusmeritvi pošta v Gmail prispe z Vašega strežnika, ki ni naveden v SPF prvotnega pošiljatelja. Brez DKIM ali pri pošiljatelju s p=reject DMARC ne uspe. Poleg tega se Gmailu preusmerjena neželena pošta zdi, kot da jo pošiljate Vi, kar škoduje Vašemu ugledu.
Potrdite: povratno sporočilo ali glave pri Gmailu (spf=fail ali softfail z Vašim strežnikom kot virom).
Rešitev: ne preusmerjajte, temveč dodajte poštni predal v aplikaciji Gmail na telefonu prek IMAP (lekciji 2.4 in 3.3).

Napaka 6: catch-all.
Vidite: veliko neželene pošte na naslovih, ki nikoli niso obstajali (xyz123@example.com), in poln poštni predal.
Zakaj: catch-all sprejme pošto za kateri koli možen naslov. Pošiljatelji neželene pošte poskušajo z naključnimi naslovi, in ti vsi pridejo noter. Če catch-all še dodatno preusmerjate navzven, postane to napaka 5 v velikem obsegu.
Potrdite: v poštnem predalu preverite, na katere naslove prejemnikov je šla neželena pošta.
Rešitev: izklopite catch-all in za vsak dejansko uporabljan naslov ustvarite alias ali poštni predal (lekcija 3.3).

Napaka 7: naslov obiskovalca kot pošiljatelj v obrazcu.
Vidite: sporočila prek kontaktnega obrazca včasih prispejo, včasih ne, zlasti ne od obiskovalcev z naslovom pri velikem ponudniku.
Zakaj: Vaše spletno mesto pošilja "v imenu" domene obiskovalca. Če ima ta domena nastavljeno p=reject ali p=quarantine, prejemnik pošto zavrne ali filtrira (lekcija 7.3).
Potrdite: preverite, kateri From uporablja obrazec.
Rešitev: v From uporabite lasten naslov, obiskovalca pa v Reply-To.

Napake pri nastavitvah

Napaka 8: odhodni strežnik brez avtentikacije.
Vidite: prejemanje deluje, pošiljanje ne. Sporočilo, kot je "relay access denied", "authentication required" ali 550 5.7.1. Na iPhonu je pogosto vzrok, da so polja za odhodni strežnik pustili prazna ("neobvezno").
Zakaj: odhodni strežnik posreduje pošto samo za tiste, ki se prijavijo. Sicer bi ga lahko kot orožje za neželeno pošto uporabil kdorkoli.
Potrdite: nastavitve odhodnega strežnika v poštnem programu.
Rešitev: vklopite avtentikacijo s polnim e-poštnim naslovom in geslom, vrata 587 s STARTTLS ali 465 s SSL/TLS (lekciji 1.4 in 2.3).

Napaka 9: mail.<domena> kot ime strežnika brez ustreznega certifikata.
Vidite: sporočilo o neveljavnem certifikatu ali "identitete strežnika ni mogoče preveriti", ali pa povezava sploh ne uspe.
Zakaj: program preveri, ali je ime strežnika navedeno v certifikatu. mail.example.com morda res kaže na strežnik, vendar ni navedeno v certifikatu. Ali pa ime po selitvi še vedno kaže na starega ponudnika.
Potrdite: preverite poštna vrata z imenom strežnika (naloga Z2.1 in Z8.4).
Rešitev: uporabite ime strežnika, ki ga navede ponudnik, in nikoli kar tako kliknite na "vseeno nadaljuj" (lekcija 2.1).

Napaka 10: poln poštni predal.
Vidite: pošiljatelji dobijo povratno sporočilo (bounce) s kodo 452 4.2.2 ali 552 5.2.2 (poštni predal poln). Vi sami ničesar ne opazite, ali le to, da nova pošta ne prihaja več.
Zakaj: poštni predal je dosegel svojo kvoto. Pogosto zaradi let nabiranja prilog ali map Poslano in Smeti, ki se nikoli ne izpraznita.
Potrdite: uporabo poštnega predala v nadzorni plošči ali spletni pošti.
Rešitev: počistite, arhivirajte ali povečajte kvoto (lekcija 3.2).

Napake pri selitvi

Napaka 11: pozabljen MX ob selitvi.
Vidite: po selitvi spletnega mesta ali domene pošta ne prihaja več, ali pa prihaja na mesto, kamor nihče ne gleda. Ali obratno: pošto ste preselili k novemu ponudniku, vendar MX še vedno kaže na starega.
Zakaj: pri zamenjavi imenskih strežnikov se preseli celotna cona. Če zapisi MX ponudnika pošte niso v novi coni, Vaša pošta kaže na nov spletni strežnik. Ali pa MX nikoli ni bil spremenjen.
Potrdite: poizvedujte MX pri pristojnem (avtoritativnem) imenskem strežniku (naloga Z8.2).
Rešitev: v dejansko aktivni coni nastavite pravilne zapise MX, nato pa še enkrat kopirajte pošto (lekcija 8.2).

Napaka 12: POP3 na več napravah.
Vidite: pošta je na prenosniku, ne pa na telefonu, ali obratno. Po menjavi prenosnika so leta pošte izginila.
Zakaj: POP3 prenese pošto s strežnika na eno samo napravo in jo tam pogosto tudi izbriše (lekcija 1.3).
Potrdite: vrsto računa v poštnem programu.
Rešitev: preklopite na IMAP; pošto, ki je samo lokalno shranjena, najprej povlecite v poštni predal IMAP.

Kaj imajo napake skupnega

Še enkrat preglejte seznam. Skoraj vsaka napaka nastane, ker je nekdo sledil posamičnemu navodilu ("dodajte ta zapis", "vklopite preusmeritev"), ne da bi videl celotno sliko. Rdeča nit tega tečaja:

• vedite, kdo pošilja pošto v imenu Vaše domene (popis, lekciji 4.2 in 8.1);
• spreminjajte eno stvar naenkrat in nato preverite;
• preberite dokaz: povratno sporočilo (lekcija 6.1), glave (lekcija 1.5), poročilo DMARC (lekcija 4.5) in DNS pri pristojnem strežniku.

Povzetek

• Napake v DNS: dva zapisa SPF, preveč poizvedb, DMARC prehitro na reject, DKIM ni vklopljen pri ponudniku pošiljanja.
• Napake naslovov: preusmeritev na Gmail, catch-all, naslov obiskovalca kot From.
• Napake nastavitev: brez avtentikacije za odhodno pošto, ime strežnika, ki ni navedeno v certifikatu, poln poštni predal.
• Napake pri selitvi: pozabljen MX, POP3 na več napravah.
• Vzrok vedno potrdite z dokazom, preden kaj spremenite.

Kviz

Naloga

Naloga Z8.3: Katera napaka je to? Prejmete osem kratkih primerov, vsak z opisanim znakom in koščkom dokaza (glavo, povratnim sporočilom, odgovorom DNS ali nastavitvijo). Za vsak primer izberite številko napake (od 1 do 12). Program preveri odgovore po vnaprej določenem ključu in ob napačnem odgovoru pokaže, kateri dokaz ste spregledali.

Za nadaljnje branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih je postopek podoben.

• Priročnik DirectAdmin 18.9: Ne prejemam več e-pošte
• Priročnik DirectAdmin 18.10: Ne morem poslati e-pošte
• Ne prejemam več e-pošte: tako poiščete vzrok
• Ne morem poslati e-pošte (prejemanje deluje)
• Posredovanje e-pošte na drug naslov (preusmeritve, uporaba catch-all ni priporočljiva)
• Brezplačen tečaj DNS 8.4: Pogosto narejene napake