Rakjuk rendbe a levelezés körüli tévhiteket

Például:

opsbears.com. IN TXT "v=spf1 a:obs-zyl-smtp01.opsbears.com a:obs-zyl-mailout01.opsbears.com include:spf.mandrillapp.com ~all"

Ez a TXT rekord azt mondja, hogy az opsbears.com domain feladójával az obs-zyl-smtp01, az obs-zyl-mailout01 szerver, valamint az spf.mandrillapp.com TXT rekordjában található összes mailszerver küldhet. A ~all a végén pedig azt mondja ki, hogy a nem megfelelő leveleket spamnek kell jelölni eldobás helyett.

És itt már el is érkeztünk a problémás részhez: az SPF csak az envelope sendert validálja, a From fejlécet (amit a user lát), nem. Tehát továbbra is bárki küldhet bármilyen feladóval, csak az envelope sendert kell másképp beállítani. Ha továbbítunk egy levelet, akkor az eredeti envelope sender helyett most már azt a postafiókot kell beleírnunk az envelopeba, amiről továbbítva lett. (Ez az SRS technológia.) Hogy ez miért nagyon hülye ötlet, abba itt nem mennék bele, a lényeg hogy aki ezt kitalálta, az szerintem aznap elfelejtette meginni a reggeli kávéját.

Az SPF technológiának van egy implicit következménye: az, hogy a saját netszolgáltatónk SMTP szerverén keresztül küldünk leveleket, már nem járható megoldás, hiszen nem fog megfelelni az SPF-nek. Már néhány éve divat az, hogy a tisztességes netszolgáltatók biztosítanak a 465-ös porton egy titkosított SMTP végpontot, ahol autentikálva tudunk levelet küldeni. A nem tisztességes szolgáltatók meg remélhetőleg szépen lassan ügyfélvesztésnek néznek elébe.

DKIM

A DKIM (Domain Keys Identified Mail) azt a célt szolgálja, hogy a küldő szervert azonosítani lehessen. Tehát ha megnézzük például az egyik szerverem megfelelő TXT rekordját, ezeket fogjuk látni:

obs-zyl-smtp01._domainkey.opsbears.com. IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA..."

Ez a rekord meghatározza azt a publikus kulcsot amivel az én levelező szerverem digitálisan aláír minden kimenő levelet. (Ezen felül létre lehetne hozni egy olyan rekordot is, ami megmondja, mi történjen a nem megfelelő levelekkel, de ez deprecated, van rá más technológia.)

DMARC

A DMARC rekord megint csak egy TXT DNS rekord, ami meghatározza, hogy mi történjen az SPF-nek vagy DKIM-nek nem megfelelő levelekkel. Nézzük a példát:

_dmarc.opsbears.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:***@opsbears.com\; aspf=r\; ri=86400"

Mint látható, azt állítottam be, hogy a nem megfelelő levelekkel ne történjen semmi (mert az SPF szerintem egy baromság), a problémás levelekről pedig a megadott e-mail címre kérek értesítést.

Ezekről a technológiákról általánosságban

Ez a három technológia arra született, hogy visszaszorítsuk a spameket, ám mint a mindenki postafiókjában kikötő gagyi locsolócső és egyéb reklámok bizonyítják, semmit sem használtak. Pusztán annyi változott, hogy a spammerek most random szolgáltatónál bérelnek VPS-eket és domaineket vásárolnak ahelyett, hogy zombigépek hadaival próbálkoznának. A levelek minden egyéb tekintetben úgy néznek ki, mintha legitim szolgáltatótól jönnének. Éppen ezért az én mailszerverem pl. nem fogad el olyan küldő domainről levelet, amely tulajdonosa nem nyilvános.

Mindamellett fontos megjegyezni, hogy ezen technológiák implementálása nélkül sokkal nagyobb esélybe kerülnek spam mappába a levelek pl. a Gmailnél.

Reverse DNS

Immáron közel 10 éve szinte senki nem tud levelezni, ha a küldő IP címre nincs beállítva normális PTR rekord és arra vonatkozó A rekord. (Forward-confirmed Reverse DNS). Ennek ellenére rendszeresen bele lehet futni olyan cégekbe, akik azt gondolják, hogy jó ötlet az irodai bérelt vonalon mailszervert üzemeltetni. Az ilyen cégek, még akkor is, ha esetleg a szolgáltatójuk állított be reverse DNS-t és ahhoz forwardot, problémákba fognak ütközni. Az a reverse, hogy ip-123-456-789-123.adsl.szolgaltatoneve.hu, ugyanis pontosan úgy néz ki, mint azok a reversek, amiket otthoni gépeknek osztanak ki és innentől kezdve elég sokan ki is szűrik őket.

Magyarán legyen normális, kézzel beállított reverse DNS, különben nem kell csodálkozni ha nem megy ki a levél.

Blacklist

Igen, vannak feketelisták. Vannak IP-re és vannak domain nevekre is. Ha a levelezőszerverünkön keresztül szemét megy ki, akár akarva, akár akaratlanul, akkor ki fogunk ilyeneken kötni. Ha valószínűsíthető, hogy szándékos szemetelés történt (pl. nem ellenőrzött e-mail címekre ment ki hírlevél), akkor akár permanensen is kiköthetünk egy ilyen listán és onnantól kezdve elég sok szerverre nem fogunk tudni levelet küldeni.

Ennek a kivédésére érdemes rendszeresen ellenőrizni a mailszerverünket, hogy nem megy-e át rajta olyan levél aminek nem kellene, valamint fel kell hívni a céges marketinges figyelmét arra, hogy a random info@ mailcimek, valamint a vásárolt címlisták megszórása olyan trükk, amit egyszer fog eljátszani. (A címlisták vásárlása egyébként illegális ha magánszemélyekről van szó, milliós bírságokat osztogatnak érte ha arra kerül a sor.) Ugyanebbe a kategóriába tartozik az is, amikor úgy gyűjtünk e-mail címet, hogy nem ellenőrizzük a megadott adatokat egy kiküldött megerősítő linkkel.

Ha már a marketingessel beszélünk, hívjuk fel a figyelmét arra, hogy a kiküldött hírlevél láblécében erősen ajánlott feltűntetni, hogy a feliratkozó mikor és hol iratkozott fel, melyik cég kezeli az adatait, mi az adatkezelési azonosítója, valamint egy linket amivel egy kattintással le tud iratkozni. Ellenkező esetben a felhasználók lehet hogy tévesen azonosítják be a levelet és spamnek jelölik, szóval egy ilyen levél kiküldése megint csak jó eséllyel egy one-time trükk.

Ha esetleg felkerültünk egy blacklistre, akkor lehet írni a tulajdonosnak, reménykedni és várni néhány hetet, amíg az infó mindenhonnan kipörög.

Whitelist

Ilyen is van. Vannak bizonyos szervezetek, amik azzal foglalkoznak hogy auditálják a levélküldési protokolljainkat. Ilyen pl a returnpath.net.

IP reputáció

Mivel a sima blacklisting nem elég, tekintve hogy új IP címet szerezni könnyű, utóbbi időben kezdett elterjedni az IP reputációs rendszer. Ez annyit tesz, hogy egy IP címet értékelünk az onnan érkezett levelek szerint, mennyi spam, mennyi nem, és ebből adatbázist építünk. Az IP reputációs rendszerek szemszögéből egy "szűz" IP cím majdnem annyira rossz mint egy spammer, tehát érdemes a nagy mennyiségű levél kiküldése előtt az IP címet "előmelegíteni".

Zárszó

Remélhetőleg sikerült néhány félreértést eloszlatni. Ha kérdésed van, esetleg úgy érzed, hogy mellényúltam, a kommentekben kidühöngheted magad. Érdemes még elolvasni Tamás Péter írását a Freemail spamszűrés működéséről.