Az SMTP működése

SMTP: Simple Mail Transfer Protocol. E-mail és spam továbbítására való.

1 Egy tipikus tranzakció

Egy tipikus tranzakció valahogy így fest:

szerver: 220 chardonnay.math.bme.hu ESMTP
kliens: HELO wifi.tmit.bme.hu
szerver: 250 chardonnay.math.bme.hu
kliens: MAIL FROM:<egyik_folianszereplocim@wifi.tmit.bme.hu>
szerver: 250 ok
kliens: RCPT TO:<masik_folianszereplocim@chardonnay.math.bme.hu>
szerver: 250 ok
kliens: DATA
szerver: 354 go ahead
kliens: Received: (qmail 845 invoked by alias); 14 Sep 2006 22:55:04 -0000
kliens: Delivered-To: egyik_folianszereplocim@wifi.tmit.bme.hu
kliens: Received: (qmail 843 invoked by uid 0); 14 Sep 2006 22:55:04 -0000
kliens: Date: 14 Sep 2006 22:55:03 -0000
kliens: Message-ID: <20060914225503.769.qmail@wifi.tmit.bme.hu>
kliens: From: egyik_folianszereplocim@wifi.tmit.bme.hu (Cron Daemon)
kliens: To: egyik_folianszereplocim@wifi.tmit.bme.hu
kliens: Subject: Cron <root@wifi> echo proba
kliens: X-Cron-Env: <SHELL=/bin/sh>
kliens: X-Cron-Env: <HOME=/root>
kliens: X-Cron-Env: <PATH=/usr/bin:/bin>
kliens: X-Cron-Env: <LOGNAME=root>
kliens: 
kliens: proba
kliens: .
kliens: 
szerver: 250 ok 1158274507 qp 24920
kliens: QUIT
szerver: 221 chardonnay.math.bme.hu

2 Mit tehetünk a spam ellen az SMTP-fázisban?

A spam elleni védekezésnél általában az a cél, hogy a levél kézbesítésének folyamata során minél hamarabb ismerjük fel, hogy a kézbesítendő levél spam, és minél hamarabb utasítsuk vissza az átvételét. A visszautasítás a következő módokon történhet:

• A TCP-kapcsolat elutasításával.
• Az SMTP-tranzakció során, szándékos időtúllépéssel.
• Az SMTP-tranzakció során, szándékos, idő előtti kapcsolatbontással.
• Az SMTP-tranzakció során, „ideiglenes hiba” jellegű kóddal – ekkor a kliens elvileg később újra próbálkozhat.
• Az SMTP-tranzakció során, „permanens hiba” jellegű kóddal – ezzel a szerver azt jelzi, hogy az adott üzenet kézbesíthetetlen, és nincs értelme újra megpróbálni.

Természetesen itt is és a továbbiakban is a de facto technikai lehetőségekről beszélünk, nem korlátozzuk magunkat az SMTP-t, mint protokollt betartó módszerekre (de azért törekszünk arra, hogy kiemeljük, ha valami teljesen ellentétes vele).

Az alábbi lista nem teljes; nem szól pl. a reputáció-alapú módszerekről és néhány egyébről (pl. DomainKeys). Eddig nem volt időm elegendően elmerülni bennük ahhoz, hogy kellő igényességgel tudjak róluk írni - patches welcome. :)

A feldolgozásnak minél további részéig jutunk el, annál több erőforrást pazaroltunk el az adott, érdektelen és értéktelen üzenetre. Ennek jobb megértése végett tekintsük át röviden egy e-mail kézbesítésének folyamatát.

A levél döntően három részből áll: egy „borítékból” (envelope), fejlécekből (headers) és levéltörzsből (body), ami további részekre tagozódhat, ha a levél csatolmányokat is tartalmaz. Ha mi vagyunk a spam áldozatai, akkor számunkra a levél kézbesítése úgy kezdődik, hogy SMTP-szerverünknek kapcsolatkérő adatcsomagot küld egy távoli számítógép (a továbbiakban kliens). Ebben a fázisban a kliensről nem tudunk sokat: tudjuk az IP-címét, és ez alapján (az esetek döntő többségében) meg tudjuk mondani, melyik országban található fizikailag, és hogy melyik internetszolgáltató hálózatához kapcsolódik. (A GeoIP ingyenes adatbázisa országszintű "geo-lokációt" tesz lehetővé; van fizetős adatbázis, ami elvileg azt is tartalmazza, egy-egy IP melyik városban található, de ez már elég esetleges.)

2.1 Ország-alapú szűrés

Sok szerver már ekkor megtagadja a kapcsolat fogadását, ha a kliens pl. kínai IP-címmel rendelkezik, mivel Kínából rengeteg spam érkezik, viszont sok szervezet egyáltalán nem folytat legitim levelezést kínai partnerekkel. Természetesen ez a szűrés elvileg nagyon pontatlan, a gyakorlatban mégis a spam jelentős részét megállítja, általában anélkül, hogy legitim levelek is áldozatául esnének – feltéve, hogy valóban nincs kínai partnerünk. Más országokat is említhetnénk: pl. a fejlődő országok zöméből egy átlagos kis cég kizárólag spamet fog kapni.

Hasonlóan természetesen lehetőség van „spambarát” – vagy annak vélt – szolgáltatók szűrésére is.

A feladó IP-je alapján variálhatjuk azt is, legfeljebb mekkora vagy legfeljebb hány címzettnek szóló levelet vagyunk hajlandók átvenni, vagy legfeljebb hány párhuzamos SMTP-kapcsolatot engedélyezünk.

2.2 Nolisting

Ha egy domainnek több MX-rekordja van, akkor elvileg először a legnagyobb (legkisebb számértékű) prioritással rendelkezőhöz kell kapcsolódni; ha ez nem elérhető, akkor a másodikhoz, s.í.t.

A gyakorlatban a spammerek, főként régebben, az elsődleges MX elérhetetlensége esetén nem próbálkoztak a másodikkal. Így jó módszer (volt) az, hogy az ember legnagyobb prioritású MX-ként egy olyan szervert adott meg, amely nem létezik vagy nem fut rajta SMTP-szerver. A spammerek lepattannak róla, a legitim kliensek pedig próbálkoznak a következővel (amely a valódi MX).

Mostanra a spammerek egy része eleve a második, vagy a legkisebb prioritású MX-szel próbálkozik először, részben a nolisting viszonylagos (bár valószínűleg még mindig csekély) elterjedtsége miatt, részben pedig azért, mert a másodlagos MX-eken esetenként kevésbé szigorú a spamszűrés. A fegyverkezési versenyben a következő lépés az, hogy a másodlagos MX csak olyan kliensek SMTP-kapcsolatait fogadja, akik nemrég megpróbáltak kapcsolódni az elsődleges MX-hez is. Ilyen működést valósít meg pl. az mxallowd Linux alatt.

Az ilyen szűrés elvileg egyetlen legitim levél elvesztését sem eredményezi, ha a küldő SMTP-megvalósítása szabványosan működik; a spamnek valamekkora hányada pedig biztosan fennakad rajta. A nolisting.org statisztikái szerint a spammerek 78%-a a két MX közül csak az egyiket próbálja meg megszólítani, de ezeket az adatokat kezeljük fenntartásokkal, mivel csak 579 spamforrás kísérleteit elemezték.

A nolisting (beleértve az mxallowd-szerű megoldással bővített nolistinget is) addig maradhat hatásos, amíg sok spammer nem szabványos SMTP-megvalósításokat használ.

2.3 Szürkelista

A greylisting (amerikaiul graylisting; „szürkelista”) fogalmat két különböző, bár hasonló értelemben használják. Mindkét esetben arra a feltételezésre alapozva próbálunk spamet szűrni, hogy a spammer minden levél kézbesítését csak egyszer kísérli meg. Ez a feltételezés többé-kevésbé helytálló, vagy legalábbis hosszú ideig az volt: a spammereknek nem érte meg valódi levelezőszervert fenntartani, amely rendelkezett volna várakozási sorral és később újfent megpróbálta volna kézbesíteni azokat a leveleket, amelyeket elsőre valamilyen átmeneti probléma miatt nem sikerült. Mára már nem egyértelműen ez a helyzet, mivel a spammerek arra törekszenek, hogy valódi, legitim SMTP-szerverek (pl. a zombik szolgáltatóiéi) továbbítsák a spamet, ezek pedig igenis újra meg fogják kísérelni a kézbesítést, ha elsőre nem sikerült.

A kétféle szürkelista közül az egyszerűbb módszer lényege az, hogy ha egy korábban sosem látott IP-címről kezdeményez velünk valaki SMTP-kapcsolatot, akkor ezt vagy

• visszautasítjuk, mintha nem is nyújtanánk SMTP-szolgáltatást, vagy
• eleve ideiglenes hibakódot mondunk a kliensnek;

de a címét megjegyezzük, és ezt az ideiglenes tiltást néhány perccel később feloldjuk. A legitim levelezőszerver ismét megpróbálkozik a kézbesítéssel, ami ezúttal sikerül, a spammer pedig ennyi idő után remélhetőleg feladja. Az első néhány perc alatt a tiltást fenntartjuk.

A módszer előnye az, hogy (extrém, valószerűtlen esetektől eltekintve) garantáltan nem akadályozza meg legitim e-mail kézbesítését, és tagadhatatlanul csökkenti a bejövő spam mennyiségét. Hátránya az, hogy a normális körülmények között szinte azonnali e-mail-továbbítást lelassítja, esetleg jelentősen. A késleltetést a levelet kézbesítő szerver (a szürkelistázós szerver kliense) csökkentheti azzal, hogy gyakrabban próbálkozik a kézbesítéssel; a greylisting tehát egy olyan technika, amely a spam elleni harc jegyében minden legitim levelező számára drágábbá teszi az email továbbítását. Az ilyesmi mindig igen sajnálatos, és elvileg kerülendő -- ettől azonban a greylisting a gyakorlatban vitathatatlanul hatásos, és mivel az alkalmazása miatti pluszköltség nem annál jelentkezik, aki használja, valószínűleg még jó darabig nem fog kimenni a divatból.

Ha sokezer felhasználónk van, akkor nem lesz túl hatásos a szűrés, mert a spammer az első néhány percben (amikor még tiltjuk a kapcsolatait) esetleg nem jut a címlistája végére, és a tiltás feloldásakor lehet, hogy még csak mondjuk a c betűnél tart.

2.4 Dinamikus IP-címek szűrése

Lekérdezhetjük a kliens IP-címéhez tartozó DNS-bejegyzést is; ha van ilyen, megpróbálhatjuk belőle kikövetkeztetni, hogy az IP-cím dinamikus-e (ha sok a címhez tartozó névben a szám és szerepel benne a „pool” szó, az jó indikáció lehet, de a spamdyke pl. ennél bonyolultabb heurisztikákat is megvalósít, ill. léteznek a dinamikusnak vélt IP-címeket tartalmazó, akár DNS-sel lekérdezhető adatbázisok is). Ha a cím dinamikus, visszautasíthatjuk a kapcsolat fogadását arra hivatkozva, hogy a dinamikus IP-jű számítógépek szíveskedjenek a szolgáltatójuk által biztosított szerveren keresztül kézbesíteni a leveleiket.

Ezt a szűrést azért alkalmazzák sok helyen, mert a spammerek gyakran kísérelnek meg dinamikus IP-című, általában gyanútlan otthoni felhasználók tulajdonában levő számítógépeken keresztül leveleket küldeni.

A szűrésnek akkor van igazán értelme, ha elfogadjuk azt a két, nem feltétlenül megalapozott feltételezést, miszerint

1. a szolgáltatónak van használható SMTP-szervere, amelyen keresztül a felhasználó levelezhetne, ha akarna; és
2. a spammer képtelen ezt az SMTP-szervert igénybe venni a felhasználó számítógépén keresztül.

Főleg a második feltételezés igényel bővebb magyarázatot. A szűrés kitalálója valószínűleg arra gondolt, hogy a spammer bizonyára nem tudja, mi a szolgáltató SMTP-szerverének a címe, vagy ha tudja is, a zombi-szoftver nincs felkészítve annak a használatára; esetleg hogy az SMTP-szerver használata hitelesítéshez van kötve, és, mivel a spammer vélhetően nincs a felhasználónév és a jelszó birtokában, nem küldheti leveleit azon a szerveren át.

Amennyiben az adott dinamikus IP-jű számítógép open proxy, a spammer valószínűleg tényleg nem tudja, melyik SMTP-szervert kellene használnia – és, noha kideríthetné, ez egyszerűen nem éri meg a fáradságot, amíg csak kevés címzett szűri ki a dinamikus című feladóktól érkező leveleket.

Ha a kézbesítést megkísérlő gép zombi, akkor viszont feltehetjük, hogy a spammer minden olyan információnak a birtokában van, amelyet a felhasználó valaha is tárolt, megtekintett vagy begépelt a számítógépén – ide értve a szolgáltató SMTP-szerverének használatához szükséges hitelesítőinformációkat is.

Ez a fajta szűrés addig lehet érdemben hatásos, amíg nem terjed el széles körben, mivel a spammerek viszonylag könnyedén kijátszhatják.

2.5 Reverse DNS nélküli kliensek szűrése

Lehetőség van arra, hogy a reverse DNS-bejegyzés (az IP-címhez tartozó név) nélküli kliensek leveleit ne fogadjuk el; valamint arra is, hogy ellenőrizzük, az IP-címhez tartozó névhez valóban az a cím tartozik-e, amelyről a kliens kapcsolódni próbál. A szűrés mögött meghúzódó ideológia szerint a legitim levelek küldői „bizonyára” rendelkeznek valódi DNS-bejegyzésekkel; így, ha valakinek nincs, akkor „nyilvánvalóan” csakis spammer lehet. A szűrés hatásossága kérdéses. Nem elterjedt, de van, ahol használják. Érzésem szerint kimutatható lenne, hogy a bejövő spam 5%-át megfogja -- de sajnos a bejövő legitim levelek hasonló hányadát úgyszintén.

Egy időben az OM levelezőszerverének sem volt reverse-bejegyzése, és -- legalábbis egy sulinetes levelezési lista tanúsága szerint -- voltak olyanok, akik emiatt nem kaptak meg fontos leveleket.

2.6 Kliens-IP-nkénti rátalimit

Megtehetjük, hogy bármely konkrét IP-től legfeljebb x darab levelet vagy SMTP-kapcsolatot vagy címzettet fogadunk el percenként; a többi próbálkozásra ideiglenes hibakódot küldünk vagy el sem fogadjuk a TCP-kapcsolatkérést. Ez akkor lehet jó, ha rengeteg felhasználónk van, és a spammerek sokszor megpróbálják ugyanazt a levelet ezek jelentős részének elküldeni. Ha a spammernek nincs valódi mail queue-ja, akkor jó eséllyel csak a kézbesítések töredéke lesz sikeres.

Ugyanakkor persze ha valahonnan tényleg sok legitim e-mail jönne rövid időn belül, akkor az első néhány utániak kézbesítését feleslegesen késleltetjük. Fehérlistával kombinálva ez a hátrány kiküszöbölhető (persze új és érdekes kérdés, mely IP-k és hogyan kerüljenek a fehérlistára), úgyhogy lehet értelme ilyet csinálni.

Ez a módszer arra is jó, hogy méltányos módon segít időben „szétkenni” a tartalom alapján működő szűrők okozta terheléstüskéket azáltal, hogy eléri, hogy egyetlen nagy intenzitással küldő kliens ne éheztethesse ki a többi kis intenzitásút. Ha globális rátakorlátot vezetnénk be a terheléstüskék elkerülése érdekében, akkor a gyakran próbálkozók előnyben lennének a ritkábban próbálkozókkal szemben.

Hasonló rátalimitet persze feladó- vagy címzett-domainenként is beállíthatunk.

2.7 Feketelisták

Számos nemzetközi DNS-alapú feketelista (RBL – Realtime Blackhole List) működik azzal a céllal, hogy a spamszűrést segítse. Ezek olyan adatbázisok, amelyek a DNS segítségével kérdezhetők le, és megmondják, hogy egy adott IP-cím eleme-e a listának, vagy nem (és ha igen, esetleg azt is, hogy milyen típusú „kihágás” miatt). Az elterjedt MTA-k (különösen a nyílt forráskódúak) általában támogatják az ilyen listák lekérdezését.

Ha a kliens IP-je rajta van a listán, akkor általában ideiglenes hibakóddal az SMTP-tranzakció során visszautasítják a levelet, és a hibaüzenet szöveges részében hivatkoznak a feketelistára, így a kliens elvileg megtudja, mit kell tennie annak érdekében, hogy levele célba érjen (vagyis hogy hogyan tud lekerülni a feketelistáról).

Jól látszik, hogy ilyen listák használata esetén az üzemeltető egy lényegében ismeretlen harmadik félre bízza annak eldöntését, kitől szeretne levelet kapni, és kitől nem. A feketelisták teljesen változó és önkényes szempontok alapján vesznek fel és távolítanak el IP-címeket az adatbázisaikból; ezeket a szempontokat pedig változó minőségben dokumentálják a weboldalukon.

Általában semmilyen garancia nincs arra, hogy egy tetszőleges feketelistán nem lesz rajta egy fontos partnerünk internetszolgáltatójának teljes címtartománya pl. azért, mert a szolgáltató egyik felhasználója egyszer egy spamnek látszó levelet küldött valakinek, aki emiatt „feljelentette” a szolgáltatót a lista üzemeltetőjénél.

Vannak listák, amelyek elvileg a „hibásan beállított” számítógépek (pl. open relay, open proxy) címeit tartalmazzák; elvileg egy cím eltávolítható a listáról, ha a gazdája „kijavítja” a számítógépe konfigurációját, amit általában a listához tartozó program automatikusan ellenőriz.

Más listák a dinamikus IP-címeket próbálják összegyűjteni; megint mások azokat az IP-címeket, amelyekről semmilyen legitim levelezésre nem használt ún. „spamtrap” (spam-csapda) címekre levelet küldtek; stb.

A listák között abban is van különbség, hogy aktívan vagy passzívan keresik a listázandó címeket; hogy a használatuk ingyenes, avagy előfizetési díjhoz kötött; hogy a listáról le lehet-e kerülni a vélt konfigurációs hiba kijavításával, vagy fizetni is kell a lista működtetőjének, esetleg örökös a tagság; stb.

Az IP-alapú szűrés általánosságban rendkívül pontatlan: abból, hogy egy spammer egyszer használt egy IP-címet, nem következik, hogy csak ő használja, vagy hogy legközelebb is azt a címet fogja használni.

Manapság nincs olyan IP-alapú feketelista, amit nyugodt szívvel közvetlenül fel lehetne használni a levélszűrésben: biztos, hogy szükség lesz kézzel karbantartott fehérlistára, amelyre azokat a címeket írjuk fel, amelyektől annak ellenére szeretnénk leveleket kapni, hogy rajta vannak a feketelistán. Ez kis forgalmú levelezőszerverek esetében még megtehető, nagyobb forgalom esetén azonban már nem.

A nagyobb forgalmú szervereknél a feketelisták a tartalomszűrést segítik: azok a levelek, amelyeket kézbesítő kliens rajta van egy vagy több feketelistán (vagy amely a fejlécek tanúsága szerint megjárt feketelistázott levelezőszervert is), magasabb spam-pontszámot kapnak.

A módszer alapötletét felhasználva lehetne olyan szűrőt konstruálni, amelynek adatbázisát több együttműködő, egymásban megbízó szervezet együttesen tartja karban; a listára automatikusan felkerülhetnének azok a címek, amelyek valamelyik résztvevőnek (nagy mennyiségű) spamet próbálnak küldeni, így a többiek a továbbiakban megtakaríthatják a tartalomszűrés költségeit az adott címről érkező levelek esetén. Természetesen a „listatagság” viszonylag gyorsan el kell, hogy avuljon ahhoz, hogy a hamis pozitív bejegyzések ne okozzanak nagy kárt.

2.8 "Early talker"-ek szűrése

Az SMTP szerint a TCP-kapcsolat felépülése után az első üzenetet, egy bannert, a szerver küldi a kliensnek. A banner tartalma viszont a kliens számára lényegében érdektelen. A spammer sietni akar, ezért nem várja meg a bannert, hanem rögtön elkezdi küldeni az SMTP-beszélgetés kliensoldali részét (akár úgy, hogy egyetlen parancs nyugtáját sem várja meg, hanem egyben átküldi az egész tranzakciót; a szerver meg majd szép sorban válaszolgat a benne levő parancsokra).

Ha a banner elküldésével pár másodpercet várunk, kiderül, hogy a kliens elkezd-e adni a banner megkapása előtt. Ha nem, ügyes spammerrel vagy legitim SMTP-klienssel állunk szemben. Ha igen, ügyetlen spammerrel vagy idióta SMTP-klienssel.

Ez a szűrés egyszerűsége ellenére meglepően hatásos; egyelőre tényleg viszonylag sok az early talker, akiket így kiszűrhetünk. Legitim, de idióta SMTP-kliensből, aki nem várja meg a bannert, rendkívül kevés van, úgyhogy ez a szűrés viszonylag veszélytelen is.

2.9 HELO-ellenőrzés

Az SMTP-tranzakció során a kliens először egy „HELO” (ESMTP esetén „EHLO”, de ez a mi szempontunkból mindegy) üzenettel „bemutatkozik” a szervernek. A HELO üzenetben az RFC2821 3.6. és 4.1.1.1. pontja szerint meg kell adni a kliens DNS-nevét, vagy, ha ilyen nincs, akkor az IP-címét.

Azokat a leveleket, amelyeket olyan kliens próbál kézbesíteni, amely ezt a szabályt nem tartja be, a szerver elvileg visszautasíthatja. A tapasztalat azt mutatja, hogy számos esetben a spammerek valóban érvénytelen HELO-üzeneteket küldenek, viszont sajnos sok legitim levelezőszerver is.

Mint az IP-alapú feketelisták esetében, itt is különböző mértékben lehetünk szigorúak. Az alábbiakban néhány elterjedt és kevésbé elterjedt gyakorlatot mutatok be:

• Előírhatjuk, hogy a HELO során átadott hosztnév létezzen a DNS-ben (ezt a protokoll elvileg megköveteli). Sok esetben a kliensek olyan hosztnéven mutatkoznak be, ami csak a belső hálózatukon érvényes, vagy már megszűnt, vagy még nem jegyezték be; úgyhogy ilyenkor is szükség van kivétellistára, ha nem tudjuk vagy akarjuk elmagyarázni a kliens üzemeltetőjének, hogy a rendszere nem szabványkonform.
• Előírhatjuk, hogy a HELO során átadott hosztnévhez a DNS-ben tartozzon MX-rekord. Ezt a szabvány nem követeli meg; ha így járunk el, még több levelet minősítünk tévesen spamnek.
• Előírhatjuk, hogy a HELO során a kliens azt a hosztnevet adja át, amely a DNS szerint az IP-címéhez tartozik. A szabvány ezt sem követeli meg, ráadásul rengeteg olyan kliens van, amely ezt nem tartja be, és esetleg nem is tudja betartani (pl. mert címfordító átjárón keresztül kapcsolódik az Internetre, és nem tudja, milyen forráscímet kapnak az adatcsomagjai, így azt sem tudja megállapítani, milyen nevet kellene küldenie a HELO üzenethez). Ennek ellenére vannak olyan szerverek, amelyek ilyen rendszer szerint szűrnek.
• Azt is ellenőrizhetjük, hogy a megadott névhez valóban a kliens IP-je tartozik-e (tehát nem az IP->név, hanem a név->IP megfeleltetést is vizsgálhatjuk). Kérdéses, hogy ez javítja-e a spamszűrés hatásosságát.
• Bizonyos HELO-sztringeket eleve kizárhatunk (pl. „localhost”, vagy a saját szerverünk neve).
• Természetesen lehetőségünk van arra is, hogy a HELO-ellenőrzés eredményét is a tartalomszűrés során vegyük figyelembe, és a levél spam-pontszámát módosítsuk a kimeneteltől függően.

Mindig azt kell mérlegelni, hogy valamilyen szűrés várhatóan sokkal nagyobb arányban érinti-e a spameket, mint a legitim leveleket; a HELO-ellenőrzéseknél ez kérdéses.

2.10 MAIL FROM-ellenőrzés

A HELO üzenet után a kliens egy MAIL FROM: <feladó@címe> jellegű üzenetet küld; az itt megadott cím az e-mail borítékján szereplő feladó („envelope sender”), és nem feltétlenül azonos a levél fejlécében szereplő feladóval (a levelezőprogramok ez utóbbit jelenítik meg).

Elvileg a levél kézbesítésének sikertelenségét ettől eltérő rendelkezés hiányában az itt megadott címre küldött hibaüzenettel kellene jelezni. Mivel a spammer nem szeretne hibaüzenetet kapni, mindenképpen hamis címet állít be feladóként (emiatt a spam kézbesíthetetlenségével kapcsolatos hibaüzenetek célbajuttatásával nem is érdemes bajlódni). Ha észrevesszük, hogy a MAIL FROM üzenetben megadott cím hamis, a levelet visszautasíthatjuk; ezzel megkíméljük magunkat a hibaüzenet kézbesítésével kapcsolatos nehézségektől, egyszersmind arra a félre hárítjuk ezeket, aki a hamis cím ellenére elfogadta a levelet, vagyis elvileg „pedagógiailag” is helyesen járunk el.

A cím triviálisan hamis, ha nem lehet rá levelet küldeni. Ennek az eldöntése viszont sajnos nem egyszerű. Ha a DNS-ben nincs sem MX, sem A típusú rekord az adott domain-névhez, akkor könnyű dolgunk van: a cím hamis (vagy ideiglenesen elérhetetlen a domain DNS-szervere). Ha viszont van MX, akkor a cím elvileg lehet helyes, de gyakorlatilag még mindig lehet hamis – például egy létező domain nem létező felhasználójáé, vagy nem a valódi feladóé.

Bizonyos levelezőszerverek ilyenkor ún. „sender verify callback”-et („feladó-ellenőrző visszahívást”) kísérelnek meg: úgy tesznek, mintha levelet próbálnának küldeni a megadott címre. Felveszik a kapcsolatot a címért felelős levelezőszerverrel, és magát a levélküldést leszámítva lebonyolítanak vele egy olyan SMTP-tranzakciót, amelyben a képzelt levél címzettjeként a MAIL FROM-ban megadott e-mail-cím szerepel. Ha a távoli szerver elfogadja ezt a címet, akkor jó, és a cím vélhetőleg létezik (teljesen biztosak még ekkor sem lehetünk benne, de ennél jobban nem tudunk róla megbizonyosodni); ha azonban hibaüzenetet kapunk, akkor a címet hamisnak feltételezzük, és mi is visszautasítjuk az állítólag onnan küldött levél elfogadását. Ez a módszer jelentősen meghosszabbíthatja az e-mail kézbesítéséhez szükséges időt, hiszen ha pl. az állítólagos feladó címéért felelős SMTP-szerveren greylist van, akkor a sender verify callback végrehajtásához először azon is át kell verekednünk magunkat. Közben viszont a mi kliensünk valószínűleg timeoutol (vagy az első callbackes hibánál mi is hibát jelzünk neki), és esetleg csak sokkal később próbálkozik újra.

Ezt a problémát súlyosbítja, hogy a sender verify callback eredményét a módszer viszonylagos drágasága miatt előszeretettel cache-elik (tehát megjegyzik, hogy az X feladó ellenőrzése sikertelen volt). Tegyük fel, hogy az A levelezőszerver levelet kapna a user@domain címről, és sender verify callbackel próbálkozik, domainért felelős B MX-szerveren viszont szürkelista van. A sender verify callback-próbálkozás a szürkelista miatt ideiglenes hibával zárul, A pedig cache-eli ezt az eredményt és órákig nem próbálkozik újra a callback-kel. A kliens szintén ideiglenes hibaüzenetet kap, tehát időnként még próbálkozik a levél kézbesítésével, de A a cache-elt sender verify callback failure miatt mindig elutasítja a levelet. Mire A legközelebb megpróbálja a sender verify callbacket, B szürkelistájából talán már eltűnt az előző próbálkozással kapcsolatos bejegyzés, így a próbálkozás ismét fennakad a szürkelistán.

Ha a levél át is jut végül, órákkal meghosszabbodott a kézbesítéséhez szükséges idő, holott látszólag minden résztvevő teljesen méltányolható módon próbált fellépni a spam ellen, és ezen intézkedések közül önmagában egyik sem eredményezett volna többórás késést.

2.11 SPF – Sender Policy Framework

Az SPF keretében speciális DNS-rekordok segítségével egy domain tulajdonosa elvileg meghatározhatja, mely IP-címeken üzemelő kliensek küldhetnek a domain nevében e-mailt, vagyis kik használhatják fel a domaint a MAIL FROM üzenetükben feladóként.

A valóságban rendkívül kevés domainben léteznek az ezzel kapcsolatos rekordok, és ezért nagyon kevés szerver használja levélszűrésre az SPF-et. Mivel azonban kevesen használják levélszűrésre, a domainek gazdái nem éreznek motivációt arra, hogy SPF-rekordokat készítsenek; így aztán az SPF gyors térnyerésére a közeljövőben nem lehet számítani. Állítólag paradox módon a leginkább a spammerek domainjeire jellemző, hogy tartalmaznak érvényes SPF rekordot.

Haladás, hogy a széles körben elterjedt SpamAssassin képes az SPF-rekordok alapján növelni vagy csökkenteni a levelek spam-pontszámát.

Ha valóban minden domainnek lennének SPF-rekordjai, akkor a spammerek dolga valamivel nehezebb lenne, mert olyan domaint kellene a MAIL FROM üzenetben megadniuk, amelynek a nevében a rendelkezésükre álló IP-cím jogosult levelet küldeni – de a hamisítás még mindig nem lenne kizárva.

Az SPF leginkább az ún. backscatter (kb. „hátraszórás”) ellen hatásos. Backscatter akkor jön létre, ha spammerek vagy vírusok a címzettjüket feladóként tüntetik fel, majd nemlétező címre (de létező domainbe) próbálják kézbesíteni a levelet. Ha a domain MX-e a levelet átveszi, és csak később ellenőrzi, hogy a címzett létezik-e, és ha nem, hibaüzenetet küld az állítólagos feladónak, amelyhez a feladó "eredeti levelét" is csatolja, akkor ez az MX lesz az, ami végeredményben a spamet vagy vírust kézbesíti. (Egyébként a patcheletlen qmail például így jár el.) Míg SPF nélkül gyakorlatilag tetszőleges e-mail-cím megadható a MAIL FROM üzenetben, addig SPF használata esetén legalább a domainek köre korlátozva lenne, tehát backscatterrel csak az kaphatna spamet, akinek a domainjéből az SPF-rekordok alapján a spammer jogosult levelet küldeni.

Sajnos az SPF-fel komoly gondok is vannak. Ezek közül néhány:

• Ellehetetleníti a mail aliasokat (amik úgy szórnak szét leveleket, hogy közben meghagyják az envelope sendert).
• Ha van secondary MX-ünk, akkor tőle minden domainből jövő levelet át kell vennünk -- vagyis az SPF csak akkor érhet valamit, ha a secondary (pontosabban: az összes) MX ellenőrzi.
• Az SPF TXT rekordokat használ, így ütközik a TXT rekordok egyéb felhasználásaival (ezekből mondjuk nincs sok).

2.12 Domain-alapú (RHS) feketelisták

Az IP-alapú listák problémáit hivatottak elkerülni az RHS (Right Hand Side, „jobbkéz felőli”) feketelisták, amelyek nem IP-címeket, hanem a spammerek által használt domaineket (az e-mail-címek „kukactól” jobbra eső részét, innen a név) sorolják fel.

A listázási politikák különbözősége itt is megfigyelhető: van pl. olyan lista, amely azokat a domaineket sorolja fel, amelyeknek nincs működő postmaster@ vagy abuse@ címe. A lista üzemeltetője feltehetően azt reméli, hogy ilyen módon nyomást gyakorolhat ezeknek a domaineknek a fenntartóira, és elérheti, hogy ezt a két címet – amelyek létezése valóban általános elvárás a műszaki szakemberek részéről – létrehozzák és üzemeltessék.

Az RHS-listák elvileg használhatóbbak lennének, mint az IP-alapúak, mivel domaint változtatni valamivel nehezebb és költségesebb, mint IP-címet. Ha a spammerek valóban a saját domainjeik nevét tüntetnék fel a MAIL FROM üzenetekben, az RHS-listák hatásosságához nem férne kétség; mivel azonban a MAIL FROM-ot a spammerek gyakran hamisítják, az RHS-listák találati aránya is messze elmarad a 100%-tól.

2.13 RCPT TO-fázis

A MAIL FROM után a kliens „RCPT TO: <címzett1@domain1>” jellegű üzenetek sorával megadja, kiknek szól a kézbesítendő üzenet. Ez a címzett a „borítékon” szereplő címzett (angolul envelope recipient); nem feltétlenül azonos az e-mail fejlécében szereplő címzettel. A fejléc a levél kézbesítésében (legalábbis az SMTP-fázisban) egyáltalán nem jut szerephez.

Természetesen az „RCPT TO” üzenet beérkezése után is vannak lehetőségeink arra, hogy a spamet megpróbáljuk megkülönböztetni a valódi emailtől.

2.13.1 Címzettek számának korlátozása

A valóságtól nem teljesen elrugaszkodott az a feltételezés, hogy egy legitim e-mailnek általában maximum pár tucat címzettje van; ha tehát valaki több száz felhasználónknak akarja elküldeni ugyanazt az üzenetet, akkor az „bizonyára” spam.

Tévedés jellemzően akkor lehetséges, ha pl. egy listserv levelezési listáról érkező levélről van szó; mivel azonban az ilyen listák ritkák, akár fel is sorolhatjuk azokat a klienseket, akiktől elfogadunk sok száz címzettet.

A szűrés sajnos nem túl hatásos, mivel a spammerek igyekeznek semmivel sem feltűnni, így pl. egy-egy levelüknek szintén csak pár tucat címzettje van. A sokcímzettes spam inkább a spam hőskorában volt jellemző, amikor a spam terítését egy-egy open relay levelezőszerverre bízták. A spammernek így csak egyetlen példányt kellett kézbesítenie a spamből; ha az összes címzettet megadta, az open relay elvégezte helyette a piszkos munkát. Ezek az idők elmúltak.

2.13.2 Tarpitting

A tarpitting (kb. „szurkosgödrözés”) módszer a fentihez hasonlít. A lényege az, hogy ha egy feladó sok címzettet sorol fel, akkor minden további címzett megadása után egyre többet várunk a nyugtázással; így egyrészt feltartjuk a spammert, másrészt pedig egy kritikus érték fölötti címzett-mennyiség esetén időtúllépés miatt meg fog szakadni az SMTP-kapcsolat.

Ez a módszer sem hatásosabb, mint a címzettek számának merev korlátozása, csak esetleg némi elégtételt jelent az üzemeltetőnek, hogy valamit tett a spammer életének megnehezítése érdekében.

2.13.3 A címzett validálása

Az RCPT TO: után megadott e-mail-címről előbb vagy utóbb mindenképpen el kell döntenünk, hogy valódi-e, hiszen a mi feladatunk lesz az e-mailt oda kézbesíteni, ha átvesszük a feladótól. Célszerű ezt a vizsgálatot azonnal elvégezni, és, ha a cím nem létezik, a levelet permanens hibakóddal visszautasítani. Így nem nálunk keletkezik a kézbesíthetetlenség miatt hibaüzenet, amit el kellene juttatnunk a feladónak (ha nem lenne hamis a címe), hanem annál, aki a mi részünkre próbálta a félrecímzett levelet kézbesíteni. Egy gonddal tehát mindenképpen kevesebb; ráadásul, ha ugyanarról az IP-címről sok nemlétező címre próbálnak levelet küldeni, akkor valószínűleg joggal feltételezhetjük, hogy találomra próbálgatnak a mi domainünkbe tartozó címeket abban a reményben, hogy valamelyik majd csak működik, és a további egy-két órán át érdemi vizsgálat nélkül elutasíthatjuk ennek a kliensnek a próbálkozásait.

Ha a próbálkozásokról másokat is értesíteni tudunk, az hasznos lehet, mert akkor hozzájuk ez a spammer akkor sem fog tudni spamet küldeni, ha egy ottani e-mail-címet amúgy eltalálna. Ehhez hasonló célokkal jött létre a DShield, bár nem konkrétan a spam, hanem általában a tömeges, szőnyegbombázásszerű, próbálkozáson alapuló támadások közös felismerésére.

Sajnos a címzett létezésének ellenőrzése nem feltétlenül egyszerű: ha pl. a mi szerverünk csak fogadja a leveleket, hogy aztán elossza őket a belső levelezőszerverek között (vagy pláne csak puffereljük őket egy ügyfél számára, akinek nincs állandó internetkapcsolata), akkor külön karban kell tartani a létező felhasználók listáját a külső szerveren is, vagy, ha szerencsénk van, és a belső felhasználók adatai egy címtárban vannak, akkor ennek a címtárnak a lekérdezésére fel kell készítenünk a levelezőszervert is. Ha a belső és a külső szervereket nem ugyanazok a személyek, esetleg nem ugyanaz a szervezet üzemelteti, akkor ez nehézségekbe ütközhet; ilyen és hasonló problémák miatt sok helyen meg sem kísérlik a címzettek validálását, hanem minden, a helyi domainbe szóló levelet átvesznek, ezzel hozzájárulva a backscatter-problémához (l. feljebb).

A létező címzettnek szóló spam ellen ez a fajta szűrés önmagában értelemszerűen nem hatásos, de a spammel járó járulékos problémák – elsősorban a backscatter – enyhítésében nagy segítséget nyújt.

2.13.4 Greylisting

Korábban már volt szó a szürkelistákról és arról, hogy két különböző, bár hasonló módszert is hívnak így. A két módszer közül a kifinomultabb az, hogy nem IP-címenként listázunk, hanem {IP;feladó;címzett} hármasonként. Tehát, ha egy adott IP-című kliens adott feladóval egy adott címzettnek akar levelet küldeni, akkor az első kísérletkor és további néhány percen át ideiglenes hibakóddal megtagadjuk a levél átvételét; ezután pedig átvesszük a levelet, ha a kliens még nem adta fel.

Ez a szürkelista lényegesen összetettebb megoldás a korábban tárgyaltnál, tapasztalataink szerint azonban kis méretekben nem ezzel megegyező mértékben jobb hatásfokú.

Ha sok ezer felhasználónk van, akkor már nem jó csak a kliens IP-címe alapján szürkelistázni, hiszen az első próbálkozása után néhány perccel már átvesszük a leveleit, akkor is, ha olyan címzetteknek szólnak, amelyek eddig nem szerepeltek. Márpedig ha mind az n*10^k felhasználónkat egyenként megpróbálják megcímezni, akkor lehet, hogy a listának a tizedéig se jutnak el, mire a szürkelista időzítője lejár és elkezdjük a spammert legitim levelezőszervernek tekinteni. Ilyenkor csak az itt tárgyalt bonyolultabb greylist-megoldás ér valamit.

2.13.5 Spamcsapdák

Megtehetjük, hogy olyan címeket is fenntartunk, amelyeken nem folytatunk legitim levelezést, de amelyeket közzéteszünk olyan helyeken, ahol spammerek megtalálhatják: weblapokon, fórumokban stb. Ha ilyen címre érkezik levél, akkor az szinte biztosan spam vagy vírus, úgyhogy a feladót a továbbiakban kezelhetjük fokozott gyanakvással; a levelet átadhatjuk a tartalomszűrőnek, hogy tanuljon belőle; a levéltörzsből képzett hash-t elküldhetjük a spam-hasheket gyűjtő adatbázisoknak (pl. Pyzor); stb.

Ha különösen a szívünkön viseljük az Internet sorsát, akkor megpróbálhatjuk automatikusan értesíteni a feladó szolgáltatóját; sőt, esetleg a levéltörzsben található URL-eket kiszolgáló szerverek szolgáltatóit; sőt, esetleg a hatóságokat is. Mivel azonban – legalábbis hazánkban – általában a kézzel írt spam-jelentésekre sem kap az ember érdemi választ, kétséges, hogy az ilyen automatikus jelentéseknek sok haszna lenne. (Az NHH szokott válaszolni, de a kifinomultabb spammerek üldözését meg sem kísérli.)

2.14 A levél tartalmának vizsgálata

Az SMTP-tranzakció következő lépése az, hogy a kliens elküldi az e-mail fejlécét és törzsét. Ezután az SMTP-szervernek el kell döntenie, hogy a levelet elfogadja, vagy elutasítja. A levéltörzs és a fejléc vizsgálata azonban még segíthet annak eldöntésében, hogy a levél spam-e, avagy sem.

Mivel ezek a vizsgálatok a legköltségesebbek (ezek igénylik a legtöbb processzoridőt), a bevezetésükhöz nagyobb forgalmú levelezőszerverek esetében szinte biztos, hogy géppark-bővítésre is szükség van.

Ezek a vizsgálatok még inkább heurisztikák, mint a korábbiak; a leveleket éppen ezért spam-pontszámmal szokták ellátni aszerint, hogy hány és milyen „spamszerű” jellemzőt sikerül bennük felfedezni, és csak a kiugróan magas pontszámú leveleket dobják el/utasítják vissza. A többinek a fejlécében a szerver elhelyez egy új mezőt, vagy átírja a „Subject:” mezőt, hogy később a felhasználó levelezőprogramja automatikusan a „spam-gyanús” levelek közé sorolhassa, de a felhasználónak még esélye legyen megbizonyosodni arról, hogy valóban nem legitim levél.

2.14.1 A fejléc elemzése

Az e-mailek fejléce sok információt tartalmaz a levélről. A fejlécet nagyrészt a levelet küldő levelezőprogram állítja össze, és azok a szerverek, amelyeken a levél áthalad, esetleg újabb mezőkkel bővítik.

Mivel a spammerek általában nem hagyományos levelezőprogramokat használnak, hanem az e-mailek tömeges előállítására írt célszoftvereket, vannak olyan fejléc-sorok, amelyekről a spam – bizonyos konfidenciaszinttel – felismerhető.

Gyakori például, hogy a spamet kicsit előredátumozzák (a Date: mezőbe későbbi dátumot írnak, mint amikor a levelet ténylegesen elküldik). Ez azért jó, mert így azoknál a felhasználóknál, akik dátum szerint rendezik a leveleiket, a spam aránylag hosszú ideig vezetheti a listát a valódi e-mailek előtt. Ha tehát olyan levelet kapunk, ami látszólag a jövőből érkezett, akkor az talán spam – vagy csak rosszul jár az órája annak, aki küldte.

Szintén a dátummezővel kapcsolatos heurisztika alapja az, hogy a spamben szereplő dátummezők gyakran hibásak (pl. nem létező időzónát adnak meg, vagy a formátumuk nem megfelelő). Ennek hasonló okai lehetnek, mint az előredátumozásnak, mindenesetre valamivel nagyobb bizonyosságot jelent atekintetben, hogy spammel állunk szemben.

Megvizsgálhatjuk a Received: fejlécsorokat. Elvileg minden levelezőszerver, amelyen a levél áthalad, beszúr egy olyan sort a fejlécbe, amelyben rögzíti a saját címét, a dátumot, és azt, hogy ő milyen IP-című klienstől kapta a levelet, és esetenként azt is, hogy az a kliens milyen nevet küldött a HELO üzenetben.

Ennek a sornak a formátuma sajnos nem elegendően rögzített, úgyhogy az automatikus elemzése nehézkes; ennek ellenére megpróbálhatjuk megállapítani, hogy azon szerverek közül, amelyeket a levél állítólag megjárt, nincs-e feketelistán valamelyik, és ha igen, ez néhány ponttal növelheti az adott levél spam-pontszámát.

Természetesen figyelembe kell venni, hogy a Received: sorok is hamisíthatók: csak annak a sornak a valódiságában lehetünk biztosak, amelyet mi magunk állítottunk elő. A spammernek azonban nem érdeke olyan levelezőszervereket feltüntetni a fejlécben, amelyek az üzenet pontszámát növelik, úgyhogy ebből a szempontból a hamisíthatóság nem okoz problémát.

A Received: sorokban megadott HELO-k vizsgálata során kiderülhet, hogy a levelet kézbesítő valamelyik számítógép olyan nevet használt a HELO fázisban, amelyik biztosan nem az övé, hanem valamelyik nagy szolgáltatóé: msn.com, yahoo.ca stb. Legitim emailben ez nem gyakori, spamben viszont annál inkább. Ugyanez vonatkozik az olyan HELO üzenetekre, amelyekben egy dinamikus IP-címhez tartozó hosztnév szerepel (pl. „h0002a5d76857.ne.client2.attbi.com”) – a valódi levelezőszervereknek általában „szebb” a neve.

A fejléc alapján még sokféleképpen következtethetünk arra, hogy a levél esetleg spam; a teljesség igénye nélkül:

• A From: mező a valódi levelekben általában a feladó nevét is tartalmazza, a spam esetében pedig gyakran csak egy e-mail-címet.
• A From: mezőben szereplő e-mail-címben a felhasználónév számokra végződik vagy számokkal kezdődik, esetleg vegyesen tartalmaz betűket és számokat. Különösen gyanús ez, ha a feladó domainje valamelyik „nagy” e-mail-szolgáltató: msn.com, hotmail.com, email.com, bigfoot.com stb.
• Van Reply-To: fejléc, de üres.
• A To: mezőben a név helyén is a címzett e-mail-címe szerepel.
• A Subject: mezőben felkiáltójel és kérdőjel is található (pl: „Vl/\GR4? Nálunk féláron!” – de ellenpéldát is könnyű találni: „ezt meg hogy gondoltad?!”).
• A Subject: mezőben (általában a végén, sok szóköz karakter után) azonosítószám található.
• A Subject: mező csupa nagybetűből áll.
• A Message-Id: mező felépítéséből esetenként lehet arra következtetni, hogy spamküldő eszközzel hozták létre az e-mailt. Ez a mező amúgy arra szolgál, hogy minden e-mailt egy remélhetőleg egyedi azonosítóval lásson el, és elvileg tartalmaznia kell annak a hosztnak a nevét is, amelyen az üzenet létrejött. Néhány triviális hamisítványt ez alapján ki lehet szűrni (pl. a Message-Id csak akkor végződhet @aol.com-ra, ha a feladó domainneve is ez).
• Valamelyik fejlécsort az átvitelt segítő, de a sor közvetlen elolvasását nehezítő kódolással (quoted-printable vagy base64) látják el, holott ezt a tartalma nem indokolja.
• A levél „magas prioritású”. Néhány levelezőprogram kezel olyan prioritással kapcsolatos fejlécmezőket, amik a levél megjelenését befolyásolják; ezeket kevesen használják, de a spammerek természetesen minden eszközt megragadnak, hogy a levelüket az előtérbe tolják.
• A levelet több felhasználónak címezték, és a felhasználónevek hasonló hangzásúak vagy ugyanazzal a betűvel kezdődnek; még gyanúsabb, ha a címzettek ráadásul ABC-sorrendben szerepelnek.
• A Subject: mezőben h.é.z.a.g.o.s.a.n í.r.t szöveg van.
• A levélben bizonyos fejlécek azt a látszatot próbálják kelteni, mintha a levelet valamely gyakori levelezőprogrammal írták volna, viszont az a program ezt a konkrét kombinációt sosem állítja elő.
• A Subject: mező tartalmazza a címzett címét vagy felhasználónevét.
• stb.

Önmagában a fentiek közül egyik sem elegendő ahhoz, hogy biztosak legyünk abban, hogy az adott levél spam, de ha sok árulkodó jellel találkozunk, általában nem tévedünk, ha a levelet a kukába dobjuk. Hogy mi a „sok”, az bátorság kérdése: minél kevesebbet tekintünk soknak, annál több legitim emailt vélünk tévesen spamnek (az első áldozatok azok a kereskedelmi hírlevelek lesznek, amelyeket tényleg kértünk), de annál kevesebb spamet kapunk.

2.14.2 HashCash

Olyan módszer is van, amellyel egy üzenet bizonyíthatja magáról, hogy nem spam: ez a HashCash. A HashCash lényege az, hogy a levél fejlécében egy olyan adatot kell elhelyezni, amely függ a feladótól, a címzettől és a dátumtól, és előállítása egy átlagos számítógép számára kb. egy másodpercet vesz igénybe, az adat helyességének ellenőrzése viszont ennek csak a töredékét. Ez a normális levelezés során nem eredményez észrevehető lassulást, levelek millióinak szétküldését viszont megnehezíti.

Egyelőre rendkívül kevés helyen foglalkoznak a HashCash-fejlécekkel, így kicsit hasonló a helyzet, mint az SPF esetében: nem érdemes bajlódni a HashCash előállításával, mivel úgysem vizsgálja meg senki; ugyanakkor viszont nem érdemes megvalósítani a HashCash-fejlécek értelmezését, mert úgysem küld senki HashCash-es levelet. A SpamAssassin egy ideje képes negatív pontszámot adni az érvényes HashCash-„bélyeggel” ellátott leveleknek, ami ugyan fontos lépés a HashCash elterjedése felé, de a nagy, kereskedelmi e-mail-rendszerek támogatása nélkül valószínűleg nem lehet áttörő sikerre számítani.

További probléma, hogy mivel a spammerek egyre gyakrabban rendelkeznek kiterjedt zombihálózattal (akár olyan módon, hogy bérbe veszik azt egy erre specializálódott bűnözőtől), a HashCash előállításához szükséges számításokat is el tudják végezni elosztottan, így a módszer hosszú távú hatásossága sajnos kérdéses.

2.14.3 A levéltörzs vizsgálata

Ha a fejléc alapján nem sikerült dűlőre jutni, megvizsgálhatjuk a levél törzsét is.

Reguláris kifejezésekkel számos tipikus spam-szófordulat felismerhető, és további heurisztikus vizsgálatokat végezhetünk pl. a csatolt képek, HTML-fájlok állományneveivel ill. a csatolmányokat egymástól elválasztó vezérlőszekvenciákkal kapcsolatban is.

Ha a levél tartalmaz HTML formátumú részt, akkor a HTML elemzése is segíthet a spam felismerésében. Ha nagy, villogó betűket tartalmaz, az pl. mindenképpen gyanús, de a fejléc vizsgálatához hasonlóan itt is rengeteg apró jel van, amelyeket egy erre felkészített szoftver automatikusan megkeres és pontszámot rendel hozzájuk.

Ha a levéltörzsben URL-ek vannak, akkor a spamekben hirdetett URL-ek hosztneveit tartalmazó feketelisták alapján szintén adhatunk spam-pontokat. Ezekre kevésbé jellemző, hogy tévednének, mint az IP-alapú feketelistákra, úgyhogy viszonylag sok pontot is érhet egy-egy találat.

Vannak olyan adatbázisok (razor, pyzor, dcc), amelyek a spamek teljes szövegéből képzett, csekély módosításokra érzéketlen lenyomatokat tárolnak; ha egy levél szerepel ezekben az adatbázisokban, tippelhetünk arra, hogy spam. Mivel azonban az adatbázisba való felvétel gyakran automatizált folyamat eredménye, nem tudhatjuk biztosan, nem tévesen nézett-e valaki spamnek egy levelet, amit utána beküldött az adatbázisba; sőt, akár az is lehet, hogy az üzleti vetélytárs hírleveleit „jelenti fel” valaki ezeknél a szűrőknél.

A levéltörzsben előforduló szavak és kifejezések statisztikai elemzése és az eredmény összevetése korábban megfigyelt levelek értékeivel szintén segíthet a spam felismerésében. Több ilyen módszer is létezik; ezek közül két viszonylag elterjedt a SpamAssassin Bayes szűrője és a bogofilter. Némi „tanítgatás” után a találati arányuk jóval 80% fölé vihető.

3 Irodalom

• Sender Reputation in a Large Webmail Service - a Google által használt reputáció-alapú spamszűrő értékelése

• Realtime spam outbreak monitor - Mely országokból jön éppen a legtöbb spam?

• Ez a thread a spamassassin-users levlistán többek között arra világít rá (valós mérések alapján), hogy minél messzebbről jön egy levél, annál nagyobb eséllyel spam; valamint hogy ha windowsos gép küldi, akkor szinte biztosan spam. :)

4 Potenciális zh-kérdések

• Írja le egy tipikus SMTP-tranzakció menetét! Milyen üzneteket küld a kliens, és milyeneket a szerver?
• Milyen módokon (nem mi alapján!) utasíthat el egy szerver egy nem kívánt levelet? Melyiknek mi a következménye a levél későbbi sorsát illetően?
• Mit tehetünk a spam elleni védekezés érdekében a HELO sor átvételekor? Az egyes módszereket értékelje is!
• Mit tehetünk a spam elleni védekezés érdekében a MAIL FROM sor átvételekor? Az egyes módszereket értékelje is!
• Mit tehetünk a spam elleni védekezés érdekében az RCPT TO sor átvételekor? Az egyes módszereket értékelje is!
• Mi a greylisting? Hogy működik? Van értelme?
• Mi a tarpitting? Hogy működik? Van értelme?
• Mi a HashCash? Hogy működik? Van értelme?
• Mi a tarpitting az SMTP kontextusában? Hogyan működik? Értékelje!
• Mi az SPF? Hogy működik? Van értelme?
• Miért jó ill. miért rossz IP-alapú feketelistákat használni a spamszűrésben? Hogyan érdemes ezeket használni?
• Miért jó ill. miért rossz domain-alapú feketelistákat használni a spamszűrésben? Hogyan érdemes ezeket használni?
• Hogyan segítheti elő egy spamszűrő a felhasználó saját spamszűrését anélkül, hogy ő maga leveleket dobna el?
• Mi a sender verify callback? Mire való? Értékelje! Milyen problémát kell elkerülni a megvalósításakor?
• Mi a backscatter? Mi okozza és hogyan lehet ellene védekezni?
• Mi a nolisting? Hogyan működik? Értékelje!