Moodul 3 · 3.3

Eesti

Nederlands English Deutsch Français Español Italiano Polski Português Română Čeština Ελληνικά Magyar Slovenčina Български Hrvatski Lietuvių Slovenščina Latviešu Eesti

Aliased, suunamine ja catch-all: mugav, kuid riskidega

Moodul 3: Mailboksi haldamine · Lugemisaeg: 11 minutit

Õpieesmärk: Pärast seda tundi oskad valida mailboksi, aliase, suunamise ja catch-alli vahel ning selgitada, miks suunamine välisele aadressile ja catch-all võivad su mailide kohaletoimetamist kahjustada.

Põhimõisted: mailboks, alias, forwarder (suunamine), sisemine ja väline suunamine, SPF katkeb suunamisel, SRS (Sender Rewriting Scheme), DKIM suunamisel, ARC (RFC 8617), catch-all, sõnastikurünnak, backscatter, saatmine teise aadressi nimel

Neli viisi, kuidas aadressi tööle panna

Kui tahad, et offerte@example.com töötaks, on sul neli võimalust:

Valik	Mis see on	Millal kasulik
Mailboks	Oma salvestuskoht oma parooliga. Saad sinna sisse logida.	Keegi peab sellega ise töötama või tuleb mailid eraldi säilitada.
Alias	Teine nimi olemasolevale mailboksile. Aadressile `offerte@` saadetud mail jõuab mailboksi `info@`.	Üks inimene mitme aadressiga.
Forwarder (suunamine)	Aadressile saadetud mail suunatakse edasi ühele või mitmele teisele aadressile. Midagi ei säilitata.	Aadress, mis peab jõudma mitme kolleegini; vana aadress, mis peab edasi töötama.
Catch-all	Kõik mailid mitteolemasolevatele aadressidele jõuavad ühte aadressi.	Peaaegu mitte kunagi (vt allpool).

Mõnes halduspaneelis on alias tehniliselt sama mis suunamine samas serveris asuvale aadressile. Oluline vahe on see: kas mail jääb samasse serverisse või läheb väljapoole?

Suunamine oma domeeni sees: pole probleemi

Kui suunad offerte@example.com aadressile info@example.com ja mõlemad on samas serveris, siis annab server maili lihtsalt üle mailboksi info@. Midagi ei liigu internetis, midagi ei kontrollita uuesti. See on turvaline ja usaldusväärne.

Suunamine väljapoole: kus läheb valesti

Teine lugu on, kui suunad maili edasi mõne teise osapoole aadressile, näiteks isiklikule aadressile Gmailis või Outlook.com-is. Siis saadab su server maili uuesti, nüüd Gmailile. Ja Gmail kontrollib maili nii, nagu see tuleks su serverist.

Oletame: klant@example.net saadab maili aadressile info@example.com. Su server suunab selle edasi Gmailile. Mida Gmail näeb?

Saatja (From): klant@example.net.
Envelope sender: ikka veel klant@example.net, kui su server seda ümber ei kirjuta.
Saatev server: su server, näiteks 192.0.2.25.

Gmail vaatab domeeni example.net SPF-kirjet. Seal su serverit loomulikult pole. SPF ebaõnnestub. Kui domeenil example.net on DMARC-reegel p=reject ja mailil pole kehtivat DKIM-allkirja, siis Gmail lükkab maili tagasi. Su server saab tagasitulnud kirja (bounce), mis läheb... algsele saatjale, kes saab nüüd veateate su serverist.

On kolm mehhanismi, mis seda leevendavad:

1. DKIM jääb (enamasti) alles

DKIM-allkiri (tund 4.3) asub maili enda sees. Kui su server suunab maili edasi muutmata kujul, siis example.net allkiri kehtib endiselt. DMARC läbib siis DKIM-i kaudu, isegi kui SPF ebaõnnestub. Seepärast ongi DKIM nii oluline: see on ainus asi, mis suunamise üle elab.

Aga see läheb katki, kui suunav server maili muudab: lisab alla teksti ("edastanud..."), muudab teemarida (lisab ette [SPAM]) või teisendab vormingut. Siis allkiri enam ei kehti.

2. SRS kirjutab envelope senderi ümber

SRS-iga (Sender Rewriting Scheme) muudab suunav server envelope senderi aadressiks oma domeenil, näiteks:

SRS0=HHH=TT=example.net=klant@example.com

Nüüd vaatab Gmail domeeni example.com SPF-kirjet ja seal su server on olemas. SPF läbib. Kui tuleb tagasitulnud kiri, saab su server aadressi tagasi tõlkida ja selle saata tegelikule saatjale.

Tähelepanu: SRS lahendab SPF-i probleemi, kuid mitte DMARC-i. Joondus (tund 4.4) võrdleb envelope senderi domeeni From-aadressiga. See on nüüd example.com versus example.net: ei ole joondatud. Seega peab DMARC ikkagi DKIM-i kaudu läbima.

3. ARC: vahendaja kinnitus

ARC (Authenticated Received Chain, RFC 8617, eksperimentaalne) lubab vahendajal fikseerida, mida ta nägi: "kui see mail minuni jõudis, läbisid SPF, DKIM ja DMARC edukalt". Suunav server allkirjastab selle kinnituse. Lõplik vastuvõtja võib otsustada seda kinnitust usaldada, kui ta usaldab vahendajat. Suured vastuvõtjad nagu Gmail ja Microsoft kasutavad ARC-i, kuid sellele ei saa kindlalt loota: see on teene, mitte õigus.

Ja rämpspost?

On veel üks probleem, ja see on sageli kõige suurem. Su rämpspostifilter ei peata kõike. Kogu rämpspost, mis sellest läbi pääseb, saadab su server nüüd edasi Gmailile. Gmaili jaoks näib, et su server saadab rämpsposti. See kahjustab tõsiselt su serveri mainet (ja jagatud majutuse puhul: kõigi sama serveri klientide mainet). Pärast seda paigutab Gmail ka su tegelikud mailid sagedamini rämpsposti.

Mis on parem?

Kas tahad lugeda oma äri-maili Gmaili või Outlooki rakenduses? Lisa mailboks siis IMAP-kontona (moodul 2). Rakendus toob maili otse su serverist. Midagi ei suunata edasi, midagi ei ebaõnnestu ja väljapoole ei lähe rämpsposti. Kui suunamine on siiski vajalik, sea rämpspostifilter rangeks juba enne suunamist.

Catch-all: miks peaaegu mitte kunagi

Üks catch-all püüab kinni kõik mailid mitteolemasolevatele aadressidele. Trükiviga nagu inof@example.com jõuab siis ikkagi kohale. See kõlab mugavalt, kuid:

Rämpspost. Rämpspostisaatjad saadavad massiliselt maile väljamõeldud aadressidele olemasolevatel domeenidel (a.jansen@, sales2@, xkq7@). Seda nimetatakse sõnastikurünnakuks. Ilma catch-allita lükkab su server selle kõik kohe tagasi. Catch-alliga jõuab kõik kohale, sageli sadu päevas.
Enam ei saa veateadet. Kes eksib su aadressis, ei saa bounce'i ja arvab, et tema mail jõudis kohale. Ilma catch-allita teab ta kohe, et aadress on vale.
Suunamine muudab olukorra hullemaks. Catch-all, mis suunab edasi Gmailile, saadab kogu selle rämpsposti Gmailile.
Backscatter. Server, mis võtab esmalt kõik vastu ja alles hiljem avastab, et aadressi pole olemas, saadab tagasitulnud kirja (võltsitud) saatjale. Seda nimetatakse backscatteriks: veateated süütutele inimestele, ja põhjus sattuda blokeerimisnimekirja.

Kas tahad hoida mõne lisa-aadressi, näiteks sagedase trükivea või vana aadressi jaoks? Loo selleks eraldi aliasid või forwarderid. Kasutad igal veebisaidil või e-poel oma aadressi (webshop-x@), et näha, kes su aadressi edasi müüb? Loo see aadress aliasena täpselt siis, kui hakkad seda kasutama.

Saatmine aliase pealt

Alias võib olla ka saatja. Näiteks tahad vastata aadressilt offerte@example.com, kuigi oled sisse logitud kui info@. See on võimalik, kuid:

Paljud mailiserverid kontrollivad tänapäeval, milline saatja aadress millise kasutajakontoga seotud on. Siis saad saata ainult oma aadressilt ja aliasidelt või forwarderitelt, mis osutavad su mailboksile. Suvaline muu aadress lükatakse tagasi ("account can not send emails from ..."). See kaitseb kuritarvitamise eest.
Oma mailiprogrammis lisad aliase lisaidentiteedina (Thunderbird: Identiteiten beheren ehk identiteetide haldamine; Apple Mail: lisa-aadressid konto juures, komadega eraldatuna; Outlook: välja Kust (From) kuvamine ja aadressi sisestamine).
SPF, DKIM ja DMARC toimivad tavapäraselt, kui alias asub samal domeenil ja saadad läbi oma serveri.

Praktikas: nii näeb see paneelis välja

DirectAdminis loote suunamised jaotises E-mail Manager, Forwarders. Catch-all asub jaotises Advanced Features, Catch-All E-mail; seal on "catch-all uitschakelen" (catch-alli väljalülitamine) soovitatav valik (mailid mitteolemasolevatele aadressidele lükatakse tagasi). Kui sul on ainult domeeninimi ilma paketita, siis asuvad suunamised Minu WebOké jaotises Minu domeenid, Doorsturingen. Teistes paneelides (cPanel, Plesk, Microsoft 365, Google Workspace) on sarnased osad, mõnikord nimede all nagu "aliased", "suunamine" või "rühmad".

Kokkuvõte

Alias või suunamine samas serveris on turvaline.
Väline suunamine lõhub SPF-i. SRS parandab SPF-i, kuid mitte DMARC-i joondust; ainult terve DKIM-allkiri päästab maili, ja ARC võib aidata.
Edasi suunatud rämpspost kahjustab su serveri mainet. Loe välist maili pigem IMAP-i kaudu rakenduses.
Catch-all tõmbab ligi rämpsposti, varjab trükivigu ja võib põhjustada backscatterit. Kasuta eraldi aliasid.
Saatmine aliase pealt on võimalik, su serveri reeglite piires.

Test

Ülesanne

Ülesanne O3.3: Oma aadresside inventuur. Koosta nimekiri kõigist oma domeeni aadressidest: mailboksid, aliased, suunamised ja kas catch-all on sisse lülitatud. Märgi iga suunamise juurde, kas see jääb su oma domeeni sisse või läheb väljapoole (Gmail, Outlook.com, mõni muu ettevõte). Seejärel vasta: millise välise suunamise saad asendada IMAP-kontoga rakenduses, ja kas mõni sisselülitatud catch-all saab välja lülitada? Täida kontrollnimekiri.

Ülesanne O3.3: Oma aadresside inventuur

Selle ülesande teed ise, keegi ei kontrolli seda. Märgi ära, mida tegid, ja märgi ülesanne tehtuks.

Catch-all puudub, või on teadlik põhjus üles kirjutatud.
Igal välisel suunamisel on põhjus, või on see asendatud IMAP-iga rakenduses.
Rämpspostifilter on sees enne iga välist suunamist.
Aadressid, millelt saadan (aliased), on mu programmis identiteedina seadistatud.

Millised aadressid sul on (postkast, alias, suunamine, catch-all) ja kuhu need suunduvad?

Millise välise suunamise asendad rakenduses IMAP-kontoga? Kas catch-all on sisse lülitatud ja kas selle saab välja lülitada?

Su linnukesed ja märkmed jäävad ainult sellesse brauserisse, me ei saada neid kuhugi. Kui oled sisse loginud, salvestame Minu kursustes ainult info, et tegid ülesande ära.

Rohkem lugemist

Nende artiklite sammud kehtivad WebOké paneelide kohta; teiste pakkujate juures toimib see sarnaselt.

Küpsised WebOké lehel

Küpsiste seaded

Vajalikud

Turundus