Az SMTP működése

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen RostásAttila (vitalap | szerkesztései) 2006. november 13., 12:32-kor történt szerkesztése után volt.

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

Tartalomjegyzék

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:<root @ wifi.tmit.bme.hu>
szerver: 250 ok
kliens: RCPT TO:<korn-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: root @ 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: root @ wifi.tmit.bme.hu (Cron Daemon)
kliens: To: root @ 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, „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 újrapró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 betartó módszerekre.

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.

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.

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

2.2 Szürkelista

A greylisting („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 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 visszautasítjuk, mintha nem is nyújtanánk SMTP-szolgáltatást, de a címet 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.

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.

2.3 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). 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, ezért 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.

Összefoglalva tehát elmondhatjuk, hogy ez a fajta szűrés addig lehet érdemben hatásos, amíg nem terjed el széles körben, mivel a spammerek könnyedén kijátszhatják.

2.4 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.

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.5 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.

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; 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.6 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 RFCxxx y.z 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:

  • Előírhatjuk, hogy a HELO során átadott hosztnév létezzen a DNS-ben (ezt a szabvány 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.
  • Lehetünk még szigorúbbak, és még azt is ellenőrizhetjük, hogy a megadott névhez valóban a kliens IP-je tartozik-e (tehát nem csak az IP->név, hanem a név->IP megfeleltetést is vizsgálhatjuk). A spamszűrés hatásosságát ez a módszer véleményünk szerint egyáltalán nem javítja, de arra mindenképpen ürügyet teremt, hogy egy szerver több levelet utasítson vissza.
  • 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.

2.7 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élba juttatá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. 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áé.

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.

2.8 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.

Haladás, hogy a széles körben elterjedt SpamAssassin [ref] 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 egy létező e-mail-címet tüntetnek fel (hamisan) feladóként az általuk küldött levelekben, és a cím tulajdonosa ezernyi, őt az általa állítólag küldött levelek kézbesíthetetlenségéről tájékoztató hibaüzenetet kap. 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.

2.9 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 [ref], 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 átlalá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 hamisítják, az RHS-listák találati aránya is messze elmarad a 100%-tól.

2.10 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 van arra, hogy a spamet megpróbáljuk megkülönböztetni a valódi emailtől.

2.10.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 [ref] 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.10.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 a TCP-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.10.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 [1], 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, 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.10.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 nem ezzel megegyező mértékben jobb hatásfokú.

2.10.5 Spamcsapdák

Megtehetjük, hogy olyan címeket is fenntartunk, amelyeken nem folyatunk 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 [ref]; 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.

2.11 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ú levelző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.11.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 konkért 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.11.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álodótt 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.11.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 az szolgáltató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 Potenciális zh-kérdések

  • Írja le egy tipikus SMTP-tranzakció menetét!
    • TCP kapcsolat felépítése az SMTP szerverrel (tipikusan 25-ös port)
    • kliens „bemutatkozik” HELO (szerver nyugtázza)
    • kliens megadja a (borítékon szereplő) feladót: MAIL FROM (szerver nyugtázza)
    • kliens megadja a (borítékon szereplő) címzettet: RCPT TO (szerver nyugtázza)
    • kilens megadja a levél tartalmát: DATA (szerver nyugtázza)
    • kliens kiadja a levél végét jelentő . -t. (A sor tartalma csak a pont.)
    • kliens elköszön: QUIT
    • Megjegyzés: az „ismert” To, From, stb. fejlécek, a levél tartalmával együtt a levéltörzsben szerepelnek.
  • Milyen módokon (nem mi alapján!) utasíthat el egy szerver egy nem kívánt levelet?
    • egyáltalán / adott IP címről nem fogad el TCP kapcsolatot az SMTP portra
    • az „ SMTP-dialógus” során utasítja el
      • ideiglenesen
      • véglegesen
    • ha már átvette a levelet az SMTP-tranzakció során, az SMTP szabvány szerint köteles megkísérelni kézbesíteni (vagy hibaüzenetet küldeni a feladónak)
  • Mit tehetünk a spam elleni védekezés érdekében a MAIL FROM sor átvételekor?
    • megvizsgálhatjuk, hogy létezik-e a feladó
      • a domént vizsgálhatjuk, van-e MX és / vagy A rekordja
      • „sender verify callback” technológiával megpróbálhatjuk azt is megnézni, fogad-e a címzett leveleket
      • az SPF
  • Mit tehetünk a spam elleni védekezés érdekében az RCPT TO sor átvételekor?
    • megpróbálunk kilóra védekezni
      • címzettek számának korlátozása
      • szurkosgödrözés
      • szürkelistázás
    • ellenőrizhetjük, hogy létezik-e a címzett
  • 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?

A HashCash az e-mail fejlécében elhelyezett hash lenyomata a feladó és a címzett e-mail címének, a dátumnak. A feladó oldalán relatíve sok munka (kb. 1 sec) a létrehozása, míg a fogadó oldal gyorsan tudja ellenőrizni. Értelme lenne, csak egyik nagy e-mail szolgáltató / kereskedelmi szoftver sem támogatja. És ráadásul a hackerek teljes hálózatokat "vehetnek" meg a hamis fejléc-hashek kialkítására.

  • 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?
    • „okos” fejléceket helyez el a levélben, akár arra is utalván, hogy miért gondolja, hogy nem kívánt a levél. Példa: a spamszűrő által hozzáadott fejléc egy ural2-re érkezett, megvizsgált, de kézbesített „viagra spamből”:
Spam-test: True ; 13.5 / 5.0 ;
 BAYES_99,DRUGS_ERECTILE,DRUGS_MUSCLE,DRUG_DOSAGE,HTML_FONT_BIG,HTML_MESSAGE,URI
 BL_AB_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL
Személyes eszközök