A 70-es években az internet születésekor, amikor elképzelték az
e-mail protokoll alapjait, senki nem gondolt arra, hogy napjainkra egy valós emailre többszöröse vírust tartalmazó, káros vagy kéretlen levél (SPAM) jut. Mivel az e-mail küldés költsége rendkívül alacsony, sokan használják különféle dolgok népszerűsítésére, terjesztésére. Hamar jött a felismerés, hogy a kéretlen levelek ellen védekezni kell. Első körben az internetszolgáltatók
spamszűrőkkel próbálták megoldani ügyfeleik védelmét. A spamszűrők általában úgy működnek, hogy különböző szempontok alapján pontozzák a beérkező e-maileket, amiket az elért pontszám alapján megjelölnek, vagy törölnek. A levél pontértéke spamre utaló tartalom, a feladó e-mail címe vagy IP-je publikus tiltólistán való szereplése alapján nőtt. Később kiegészült a pontozás egyéb szempontokkal is pl. kulcsszavak a tartalomban, automatikusan generált e-mail stb. Sok ügyféllel rendelkező szolgáltatók öntanuló szűrőket is elkezdtek alkalmazni, ahol a felhasználók is minősíthettek spamnek egy bizonyos e-mailt.
Az effajta spamszűrés azonban kevésnek bizonyult, a spammerek úgy alakították a tartalmakat, hogy minél több szűrőn átjussanak. Nyilvánvalóvá vált, hogy e-mail küldés során ellenőrizni kell, hogy egyrészt a küldő levelezőszerver jogosult-e egy bizonyos e-mail címről levelet küldeni, másrészt pedig ellenőrizni kell, hogy valóban az küldte-e a levelet, aki feladóként szerepel. Mostanság egyre több internetszolgáltató kezdte ezeket a protokollokat használni a spamek szűrésének érdekében. Azonban így óhatatlanul azok a felhasználók kerültek hátrányba, akik saját levelezésükkel nem készültek fel ezekre a követelményekre. Tulajdonképpen kicsit fordított lett a helyzet, a legális e-mail küldőnek kell bizonyítani azt, hogy valóban jogosult e-mailt küldeni. Vizsgáljuk meg a két legfontosabb megoldást!
SPF rekord (Sender Policy Framework)
Ahogy a fentiekből látszik, korábban nem volt korlátozás, egy bizonyos e-mail címmel bármilyen levelezőszervert lehetett küldésre használni. Ennek korlátozására fejlesztették ki az
SPF rekordot. Ez a domain DNS zónájában szereplő bejegyzés arra hivatott, hogy megmondja melyek azok az IP címek, amikről kimehet egy e-mail feladótól levél. A legegyszerűbb eset, ha valaki egyetlen levelezőszervert használ, ez esetben annak az IP-je kell szerepeljen az SPF rekordban. Van amikor viszont szükséges, hogy bizonyos e-mail címről más rendszer is tudjon automatikusan levelet küldeni, pl. egy webáruház esetén ilyen az automatikus visszaigazolás. Ilyenkor a webáruház IP-jét is fel kell venni az SPF rekordba. Rendszerünkben működő tárhelyek és webáruházak esetén olyan SPF rekordot tudunk biztosítani, amiben szerepel az összes szerver IP címe, ami a kommunikációban részt vehet. Abban az esetben viszont, ha valakinek más szolgáltatónál van a domainje, ott kell hozzáadja az
UnasShop rendszer tartományát az SPF rekordjához.
Mi van akkor, ha valaki nem állít be SPF rekordot? Ez a fogadó fél szerverétől függ. Van amelyik internetszolgáltató nem ellenőrzi még a rekord meglétét. Amelyik viszont igen, ott is több eljárás fordulhat elő: van ahol nem fogadnak e-mailt, ha nincs SPF rekord és van, ahol pedig a protokollnak megfelelően csak arról az IP címről fogadják el a levelet, ami az SPF rekordban szerepel. Ha más IP címről érkezik, akkor az törlésre kerül.
Hogyan kell beállítani az SPF rekordod? Manapság már minden valamire való szolgáltató biztosít adminisztrációs felületetet a tárhelyek kezelésére, illetve a kapcsolódó domainek DNS rekordjainak módosítására. Az SPF rekordot itt kell beállítani általában TXT rekord hozzáadásával. Tisztában vagyunk vele, hogy ez egy kis informatikai hozzáértést igényel, így az
UNAS rendszerben működő tárhelyek esetén ügyfélszolgálatunk készségesen segít ennek beállításában.
DKIM aláírás (DomainKeys Identified Mail)
Egyszerűen megfogalmazva a
DKIM protokoll arra való, hogy egy osztott kulcsos digitális aláírás kerüljön be az e-mailbe, ami alapján ellenőrizhető, hogy a megfelelő jogosultsággal rendelkező fél küldte, vagy sem. Történetét tekintve a
Yahoo "enhanced DomainKeys" és a
Cisco "Identified Internet Mail" fejlesztéseinek ötvözésével jött létre. Ez a fajta aláírás azonban különbözik az egyszerű digitális aláírástól annyiban, hogy ebből a felhasználó nem lát semmit, de a levél forrásában benne van, a levelezőszerverek ellenőrizni tudják. A DKIM nyilvános kulcsú titkosítást (public key encryption) alkalmaz, ami két kulcsból áll, egy titkos (private), és egy nyilvános (public) kulcsból. Rendszerint a publikus kulcsot a feladó domainjének névszervere szolgáltatja, DNS rekordként. A titkos kulcs pedig az e-mail aláírásához szükséges. A folyamat megkezdésekor az e-mailt feladó levelezőszerver az e-mailt a titkos kulcs segítségével aláírja, amit az e-mail fejlécében helyez el. A fogadó levelezőszerver pedig a domainhoz tartozó névszervertől megkapott publikus kulccsal ellenőrzi az aláírás helyességét. Ezzel a megoldással egyrészt garantálható, hogy biztosan a feladótól származik az e-mail, de az is, hogy azt útközben sem módosították.
Mi van ha nem így küldjük a levelet, és hogy kell beállítani? Az SPF rekordhoz hasonlóan a DKIM-et is szolgáltatók különbözően ellenőrzik, és különbözően jelölik meg, vagy járnak el a kézbesítésnél. A beállítása bonyolultabb, mint az SPF rekordé, mivel nem csak DNS rekordot kell készíteni, hanem a levelezőszervert is konfigurálni kell arra, hogy a titkos kulcs segítségével aláírja az egyes e-maileket. Mivel itt a legapróbb beállítási hiba is ahhoz vezethet, hogy tömegesen nem érkeznek meg a levelek, az átlagos felhasználó ezzel már lehet, hogy nem tud megbirkózni, noha a szolgáltató lehetőséget ad az adminisztrációs felületen.
Mi a jövő? Jön a DMARC!
Annyi már most elmondható, hogy a fenti megoldásokra egyre több hangsúlyt fognak fektetni a szolgáltatók, érdemes mindenkinek felkészülni rá. Ha a domainjét olyan szolgáltatónál tartja, aki nem készül fel ezekre, akkor érdemes váltani. Természetesen a küzdelem tovább folyatódik a SPAM-ek ellen, sorra jönnek ki az újabb megoldások, amelyek a fentieket tökéletesítik, pl. a
DMARC. Ezek inkább arra lesznek hivatottak, hogy a fentiek miatt tévesen kiszűrt e-mailek sorsáról rendelkezzenek.
