A levelezés biztonsági beállításainál a szolgáltatások bekonfigurálása a dolgom.

Az SSL-lel védett protokollokat úgy állítom be, hogy azok megfeleljenek az érvényes biztonsági követelményeknek éppúgy, mint az SSL védett weboldalak esetében. Az egyéb, kifejezetten az email forgalom hitelességét biztosító szolgáltatások érvényre juttatása azonban már az ügyfél DNS szolgáltatójának a feladata azon információk alapján, amit én az ügyfélnek a szolgáltatás beállítását követően átadok.

SPF

Az SPF az egyik legegyszerűbb biztonsági beállítás, használata megakadályozza, hogy a levél feladójának domain részét meghamisítsák. Kiszolgáló oldali konfigurálást nem igényel.

Az ügyfél DNS zónájába kell felvinni egy speciális TXT rekordot, ami tartalmazza azon gépek IP címeit, amelyekről a kimenő levelek a másik szolgáltató szerverére küldve lesznek.

A beérkező levélnél a címzett szervere megvizsgálja, hogy a küldő domain zónája rendelkezik-e SPF rekorddal, és ha igen, akkor leellenőrzi, hogy az IP cím, amelyről a levél érkezett szerepel-e az engedélyezett feladók között. Ha igen, akkor a spamszűrők a levéllel kegyesebben bánnak. Ha nem szerepel a listán, akkor pedig szigorúbban (felpontozásra kerül, és a karanténban végezheti).

Ha nincs ilyen rekord, akkor a levél sem pozitív, sem negatív megkülönböztetésben nem fog részesülni a spamszűrés folyamán.

DKIM

Hasonlóan az előző módszerhez, ez is hamisítás elleni védelem, azonban a levél egyes részeinek meghamisítása ellen is használható, és bonyolultabb működése miatt kiszolgáló oldalon is beállításokat igényel.

Egy adott domain zóna minden egyes szerverén, amely az adott zónával kapcsolatos kimenő leveleket kezelheti, generálunk egy SSL kulcspárt, és az adott kulcskészlet mellé egy azonosítót (célszerű erre a célra a szerver nevére utaló szöveget választani, ha nagyon sok levélküldő szerverünk lehet).

A kulcs privát része a levélküldő szerveren marad, a publikus része egy speciális TXT rekord formájában a DNS zónába kerül azon a néven, amilyen azonosítót választottunk.

Levélküldéskor az előre megadott levélfejlécek (Pl. feladó, címzett, tárgy, stb.) a szerveren a privát kulccsal aláírásra kerülnek, és egy plusz email fejléc formájában a levélbe kerülnek az adott kulcs azonosítójával együtt.

Amikor egy DKIM aláírással érkező levél érkezik a címzetthez, az a titkosított fejléc tartalmakat az adott azonosítóhoz tartozó, a DNS-ből kiolvasott publikus kulccsal visszafejti, és összeveti a levélben található, ugyanezen fejlécek aktuális tartalmával. Ha...

• nem egyezik a visszafejtett és az eredeti tartalom
• nem található az adott azonosítóhoz publikus kulcs a DNS-ben
• a titkosító és a publikus kulcsok nem tartoznak össze

..., akkor ugyanaz történik a levél elbírálásakor, mint az SPF esetén.

Ettől függetlenül vegyük észre, hogy nem csak a feladó domain zónájának a hamisítása ellen védekezhetünk a DKIM-mel, hanem megakadályozhatjuk, hogy más email tulajdonságokat is meghamisítsanak (pl. feladó címe/neve, címzett címe/neve, a levél tárgya, feladás ideje, a levél azonosítója, stb.).

ADSP

Az ADSP is csupán egy TXT rekord a domain DNS zónájában, és arra szolgál, hogy jelezzük: minden levelet aláírunk-e DKIM használatával, vagy sem, sőt, a legszigorúbb beállítással akár azt is sugallhatjuk, hogy a levelet kérdés nélkül dobja el a túloldal, ha abban nincs, vagy hibás a DKIM aláírás, ugyanis az hamis.

DMARC

Az előző módszerhez hasonló TXT rekord, ám sokkal részletesebb leírást tartalmaz arra vonatkozóan, hogy a túloldal hogyan kezelje azokat a leveleket, amelyek feladója a mi domainünket tünteti fel küldőként.

Az ADSP-vel ellentétben nem csak a DKIM-re, hanem az SPF hibákra is szőhetünk szabályokat, és a levelek kezelésére vonatkozó utasításokon túl, még riportokat is kérhetünk a levélforgalomról, amelyek alapján esetleg kezdeményezhetjük egyes hostok tiltólistára helyezését is, mivel értesülni fogunk arról, hogy milyen címekről próbálkoznak a mi nevünkben hamisított leveleket küldeni.