Gyakori hibák

Modul 8: Költözés és a domain rendbetétele · Olvasási idő: 13 perc

Tanulási cél: E lecke után Ön képes lesz a tizenkét leggyakrabban elkövetett e-mail hibát a tüneteik alapján felismerni, megmagyarázni, miért fordulnak elő, és megoldani őket.

Kulcsfogalmak: kettős SPF-rekord, túl sok SPF-lekérdezés, DMARC túl korán reject módban, DKIM nincs bekapcsolva egy küldőszolgáltatásnál, átirányítás Gmailre, catch-all, látogató mint feladó, kimenő szerver hitelesítés nélkül, mail. szervernév tanúsítvány nélkül, tele postafiók, MX elfelejtve egy költözés során, POP3 több eszközön

Hogyan használja ezt a leckét

Minden hibánál ugyanaz a felépítés: mit lát (a tünet, ahogy egy ügyfél jelezné), miért fordul elő, és hogyan oldja meg. A tünetek gyakran hasonlítanak egymásra ("nem érkezik meg a levelem"), miközben az ok egészen más. Ezért minden hibánál szerepel az is, hogyan erősítheti meg: milyen bizonyítékot keressen, mielőtt bármit megváltoztatna. Ne találgasson, előbb mérjen (4. lecke 6.3).

A számokat a feladatban fogja használni.

Hibák a DNS-ben

1. hiba: két SPF-rekord.
Ön ezt látja: a Gmailre és az Outlook.com-ra küldött levelek hirtelen a spamben landolnak, amióta egy új szolgáltatást (Microsoft 365, hírlevél, könyvelőprogram) kapcsolt össze a domainnel. A fejlécekben spf=permerror szerepel.
Miért: a szolgáltatás azt mondta, "adja hozzá ezt az SPF-rekordot", és most már két TXT-rekord kezdődik v=spf1-gyel. Az RFC 7208 szerint ez végleges hiba: az SPF ilyenkor egyáltalán nem számít.
Megerősítés: kérdezze le a domain TXT-rekordjait, és számolja meg a v=spf1-rekordokat.
Megoldás: vonja össze mindet egyetlen rekordba (4. lecke 2).

2. hiba: tíznél több SPF-lekérdezés.
Ön ezt látja: ugyanaz, spf=permerror, de csak egy rekord van. Gyakran a sokadik include hozzáadása után jelentkezik.
Miért: minden include, a, mx, exists és redirect egy-egy DNS-lekérdezésbe kerül, az include-okon belül is. Tíz fölött az SPF érvénytelen.
Megerősítés: egy SPF-ellenőrzővel rekurzívan számoltassa meg a lekérdezéseket (Z4.2 feladat).
Megoldás: távolítsa el a már nem használt szolgáltatásokat, cserélje le az a és mx mechanizmusokat ip4/ip6-ra, ha azok állandók, vagy küldesse az adott szolgáltatást egy saját bounce-aldomainen keresztül (7. lecke 1).

3. hiba: DMARC rögtön p=reject módban.
Ön ezt látja: amióta beállítottak egy DMARC-rekordot, a könyvelőprogramból érkező számlák vagy a weboldalról küldött levelek nem érkeznek meg. A fogadó szerverek 550 5.7.1 választ adnak, a DMARC-ra hivatkozva.
Miért: nem minden küldőt vettek számba. Ami nem igazodó SPF-en vagy DKIM-en keresztül érkezik, azt most elutasítják.
Megerősítés: a DMARC-rekord és a jelentések (4. lecke 5): mely források buknak el?
Megoldás: térjen vissza p=none módra egy jelentési címmel, javítsa ki az összes küldőt, majd lépésről lépésre haladjon tovább a quarantine, végül a reject felé (4. lecke 4). Ez a kurzus ajánlott iránya is.

4. hiba: a DKIM nincs beállítva a küldőszolgáltatásnál.
Ön ezt látja: a hírlevelek egyre több fogadónál nem érnek célba a beérkező levelek mappájában. A fejlécekben: dkim=pass header.d= a szolgáltatás domainje, dmarc=fail.
Miért: a szolgáltatás a saját domainjével ír alá, így a DMARC nem tud átmenni a DKIM-en keresztül, és az SPF sem igazodik.
Megerősítés: egy próbahírlevél fejlécei (Z7.1 feladat).
Megoldás: hitelesítse a domainjét a szolgáltatásnál (DKIM CNAME-en keresztül, 7. lecke 1).

Átirányítási és címhibák

5. hiba: minden átirányítása Gmailre.
Ön ezt látja: egyes feladóktól érkező levelek nem jutnak el a Gmail-címre, ahová az üzleti leveleit irányítja, vagy a spamben landolnak. Néha a feladók bounce-üzenetet kapnak a Gmailtől.
Miért: átirányításnál a levél az Ön szerveréről érkezik a Gmailhez, amely nem szerepel az eredeti feladó SPF-jében. DKIM nélkül, vagy ha a feladónak p=reject van beállítva, a DMARC elbukik. Emellett a Gmail szemszögéből az átirányított spam olyan spamnek tűnik, amelyet Ön küld, ami árt a reputációjának.
Megerősítés: a bounce vagy a fejlécek a Gmailnél (spf=fail vagy softfail, forrásként az Ön szerverével).
Megoldás: ne irányítsa át, hanem adja hozzá a postafiókot a telefonján a Gmail-alkalmazáshoz IMAP-on keresztül (2. lecke 4 és 3. lecke 3).

6. hiba: catch-all.
Ön ezt látja: rengeteg spam érkezik olyan címekre, amelyek sosem léteztek (xyz123@example.com), és tele van a postafiók.
Miért: a catch-all minden elképzelhető címre fogad levelet. A spammerek véletlenszerű címeket próbálgatnak, és ezek mind megérkeznek. Ha a catch-allt még tovább is irányítja kifelé, az az 5. hiba felnagyított változata lesz.
Megerősítés: nézze meg a postafiókban, mely fogadó címekre érkezett a spam.
Megoldás: kapcsolja ki a catch-allt, és minden ténylegesen használt címhez hozzon létre egy aliast vagy postafiókot (3. lecke 3).

7. hiba: a látogató címe feladóként egy űrlapon.
Ön ezt látja: a kapcsolatfelvételi űrlapon keresztül érkező üzenetek néha megérkeznek, néha nem, különösen nem egy nagy szolgáltatónál lévő címmel rendelkező látogatóktól.
Miért: a weboldala a látogató domainje "nevében" küld. Ha annak a domainnek p=reject vagy p=quarantine van beállítva, a fogadó elutasítja vagy kiszűri a levelet (7. lecke 3).
Megerősítés: nézze meg, milyen From címet használ az űrlap.
Megoldás: saját cím a From mezőben, a látogató a Reply-To mezőben.

Beállítási hibák

8. hiba: kimenő szerver hitelesítés nélkül.
Ön ezt látja: a fogadás működik, a küldés nem. Olyan üzenet jelenik meg, mint "relay access denied", "authentication required" vagy 550 5.7.1. iPhone-on gyakori: a kimenő szerver mezői üresen maradtak ("opcionális").
Miért: egy kimenő szerver csak a bejelentkezett felhasználók leveleit továbbítja. Egyébként bárki spamküldésre használhatná.
Megerősítés: a kimenő szerver beállításai a levelezőprogramban.
Megoldás: kapcsolja be a hitelesítést, a teljes e-mail-címmel és jelszóval, a 587-es porton STARTTLS-sel, vagy a 465-ösön SSL/TLS-sel (1. lecke 4 és 2. lecke 3).

9. hiba: mail.<domain> szervernévként megfelelő tanúsítvány nélkül.
Ön ezt látja: üzenet egy érvénytelen tanúsítványról vagy arról, hogy "a szerver azonosságát nem sikerült ellenőrizni", vagy a kapcsolat egyáltalán nem jön létre.
Miért: a program ellenőrzi, hogy a szervernév szerepel-e a tanúsítványban. A mail.example.com esetleg a szerverre mutat, de nincs benne a tanúsítványban. Vagy a név egy költözés után még mindig a régi szolgáltatóra mutat.
Megerősítés: ellenőriztesse a levelezési portokat a szervernévvel (Z2.1 és Z8.4 feladat).
Megoldás: használja a szolgáltató által megadott szervernevet, és soha ne kattintson csak úgy a "folytatás mindenképp" gombra (2. lecke 1).

10. hiba: tele postafiók.
Ön ezt látja: a feladók 452 4.2.2 vagy 552 5.2.2 bounce-üzenetet kapnak (a postafiók tele van). Ön semmit nem észlel, vagy csak azt, hogy nem érkezik új levél.
Miért: a postafiók elérte a kvótáját. Gyakran évek óta felgyülemlett mellékletek miatt, vagy mert a Küldés és a Kuka mappa soha nem ürül ki.
Megerősítés: a postafiók használata a vezérlőpanelen vagy a webmailben.
Megoldás: rendrakás, archiválás, vagy a kvóta növelése (3. lecke 2).

Hibák költözésnél

11. hiba: elfelejtett MX egy költözés során.
Ön ezt látja: a weboldal vagy a domain költöztetése után nem érkezik többé levél, vagy olyan helyre érkezik, ahová senki nem néz. Vagy fordítva: átköltöztette a levelezést egy új szolgáltatóhoz, de az MX még mindig a régire mutat.
Miért: egy névszervercsere esetén az egész zóna átkerül. Ha a levelezési szolgáltató MX-rekordjai nincsenek benne az új zónában, a levelezés az új webszerverre mutat. Vagy az MX-et sosem állították át.
Megerősítés: kérdezze le az MX rekordot a mérvadó névszervernél (Z8.2 feladat).
Megoldás: állítsa be a megfelelő MX-rekordokat abban a zónában, amely ténylegesen aktív, majd másolja át még egyszer a levelezést (8. lecke 2).

12. hiba: POP3 több eszközön.
Ön ezt látja: a levelek a laptopon vannak, de a telefonon nem, vagy fordítva. A laptop cseréje után évekre visszamenő levelek tűntek el.
Miért: a POP3 a szerverről egyetlen eszközre tölti le a leveleket, és onnan gyakran törli is őket (1. lecke 3).
Megerősítés: a fiók típusa a levelezőprogramban.
Megoldás: váltson át IMAP-ra; a csak helyben tárolt leveleket előbb húzza át az IMAP-postafiókba.

Ami közös a hibákban

Nézze át még egyszer a listát. Szinte minden hiba abból fakad, hogy valaki egy önálló utasítást követett ("adja hozzá ezt a rekordot", "kapcsolja be az átirányítást") anélkül, hogy az egészet átlátta volna. A kurzus vezérfonala:

tudja, ki küld levelet a domainje nevében (leltár, 4. lecke 2 és 8. lecke 1);
egyszerre csak egy dolgot változtasson, majd ellenőrizzen;
olvassa el a bizonyítékot: a bounce-üzenetet (6. lecke 1), a fejléceket (1. lecke 5), a DMARC-jelentést (4. lecke 5) és a DNS-t a mérvadó szerveren.

Összefoglalás

DNS-hibák: két SPF-rekord, túl sok lekérdezés, DMARC túl korán reject módban, DKIM nincs bekapcsolva egy küldőszolgáltatásnál.
Címhibák: átirányítás Gmailre, catch-all, a látogató címe From mezőként.
Beállítási hibák: nincs kimenő hitelesítés, a tanúsítványban nem szereplő szervernév, tele postafiók.
Költözési hibák: elfelejtett MX, POP3 több eszközön.
Mielőtt bármit megváltoztatna, mindig erősítse meg az okot bizonyítékkal.

Kvíz

Feladat

Z8.3 feladat: Melyik hiba ez? Nyolc rövid esettanulmányt kap, mindegyikhez egy tünettel és egy bizonyítékdarabbal (egy fejléccel, egy bounce-üzenettel, egy DNS-válasszal vagy egy beállítással). Válassza ki esetenként a hiba számát (1-től 12-ig). A rendszer egy rögzített kulccsal ellenőrzi a válaszokat, és hibás válasz esetén megmutatja, milyen bizonyítékot hagyott figyelmen kívül.

Z8.3. feladat: Melyik hiba ez?

A feladathoz tartozó fájl: casussen-z8-3.md

Nyissa meg a casussen-z8-3.md fájlt, és válassza ki esetenként a 8.3. leckéből a hiba számát.

1. eset

2. eset

3. eset

4. eset

5. eset

6. eset

7. eset

8. eset

Amit beír, és amit találunk, azt nem tároljuk. A böngészője megjegyzi a válaszait és azt, hogy teljesítette e a feladatot. Ha bejelentkezett, a Fiókomban csak azt tároljuk, hogy a feladat (majdnem) helyes volt; ott ezt is törölheti.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké vezérlőpaneljeire érvényesek; más szolgáltatóknál hasonlóan működik.

Sütik a WebOké oldalán

Sütibeállítások

Szükséges

Marketing