bardóczi ákos @post.r

Akkor most engedtessék meg nekem, hogy kicsit edukáljam a T. Nethasználókat email-ügyileg. Kevés dolog van, amivel fel lehet húzni, ezek egyike, ha valakinek emailt írok, aztán arra nem érkezik válasz, ami ritkán ugyan, de előfordul.

Már régen ujjbegyemben van ez a téma, szóval gondoltam időszerű írnom róla, még akkor is, ha totál eleminek tűnik.

Alapvetően olyannak írok emailt, esetleg máshol üzenetet, akitől reálisan elvárom, hogy válaszolni is fog rá ésszerű időn belül, ami mondjuk 1-10 nap. Akár közeli, akár kevésbé közeli ismerősről van szó, sajátos tapasztalat, hogy minél többet ért el valaki az életben, precízebben az emberi nagysága minél nagyobb összességében nézve, annál kisebb a sansza, hogy egész egyszerűen nem fog válaszolni a kérdésemre, az más kérdés, hogy bizonyos esetekben esetleg az asszisztens vagy titkárság válaszol, azt pedig lehet tudni, hogy ki az, akit érdemes szükség esetén más csatornán megkeresni, mert ilyen is előfordulhat.

Nem tudom, hogy melyik pozitív pszichológiáról írt könyv előszavában olvastam már, ahol a szerző - aki egyidejűleg töltött be vezető tisztséget több gigaszervezetben, azaz alighanem kevés elfoglaltabb ember van, mint ő - leírta, hogy minden emailre válaszol, legfeljebb egyetlen sorban. Talán akkor vettem fel én is azt a megszokást, hogy függetlenül attól, hogy ki küldött emailt, minden személyre szóló levélre válaszolok per feladó, per adott téma, legalább egyszer, azaz tényleg az összesre, ami nem spam vagy eltéved levél.

Alapvetően teljesen ignorálni valakinek a levelét, ahhoz hasonlítható taplóságnak tartom, mint nem fogadni valakinek a köszönését vagy kézfogását. Na félreértés ne essen, irgalmatlan mennyiségű debil levelet kapok, amit átfutok, aztán megválaszolom egy-két-három szóban vérmérséklettől függően, esetleg csupa nagybetűvel. Ha ugyanabban a témában ismét ír az illető, azt már nem. Én megadtam azt a típusú tiszteletet, hogy válaszoltam neki, akkor is, ha szubjektív értékítélet alapján kreténségnek gondolom az egészet. Mi a másik oka ennek? Az, hogy ha úgy tetszik, ismeretelméleti szempontból nem zárhatom ki azt, hogy egyszer majd én kérdezek valakiről felkészületlenül vagy hülyeséget, aztán ha kapok rá egy velős, nem túl kedves választ, az is információértékű, ha nem is kellemes, ami arra sarkall majd, hogy felkészültebben kérdezzek, míg ha nem érkezik válasz, annak nincs ilyen üzenete.

Senki sem lesz kevesebb attól, hogy fél percet szán egy hülye levél megválaszolására, még csak időt sem veszít, inkább karban tartja azt, ami manapság totálisan kihalni látszik az emberekből és gusztus szerint a másik megbecsülésének, alázatnak vagy tiszteletnek hívják.

Ami pedig az érdekesebb emailben érkezett felvetéseket illeti, persze, azokra szivesen válaszolok bővebben. Vannak visszatérő játékosok, akik egy-egy adott témában írnak rendszeresen, holott egyszer már írtam nekik olyan levelet kimerítő módon, amihez nem tudok mit hozzátenni. Nemrég előfordult, hogy újra megírtam ugyanazt ugyanannak a feladónak, amit korábban is, de látszott, hogy intellektus híján nem nézett utána annak, amit korábban hivatkozásként küldtem neki.

Persze, minden interakció felzabál egy kicsit az ember idejéből és energiájából, de egy nem fölöslegesen, ha ésszel csinálja, a kapcsolódó játékszabályok röviden:  
1. pontosan annyit fordítsunk a válaszra, amennyit érdemes ráfordítani - viszont a másik felé mutatott tisztelet Téged tesz nagyobbá, ezért kellene a leghülyébb emailekre is reagálni, a leghülyébbeknek is legalább egyszer jár legalább egy válasz! 
2. Hiába találták ki a csillagozást, címkézést, levelek osztályozását a levelezőrendszerekben, ha fontos levél jön, azonnal szövegezd meg a választ rá, ha kell, aludj rá egyet, aztán másnap olvasd át és aztán küldd el, de ha azonnal megszövegezed, akkor kisebb eséllyel fogod elfelejteni azt, hogy el is küld.  Ha pedig felhúzott egy levél, aludj rá egyet, mielőtt válaszolsz, de azért válaszolj!
3. Az egésznek legyen egy kerete! Azt, hogy azonnal próbáljunk megválaszolni mindent, amikor érkezett, totál felejtős, elvégre lehetetlen lenne elmélyülni bármilyen, kicsit is normálisabb tevékenységben, ha azonnal válaszolnánk  minden feladónak az egész napunkat felzabálná. A megoldás pedig egyszerű, mint az UTP-kábel: érdemes kijelölni egy napszakot, esetleg két napszakot, amit emailezésre fordítunk, aztán akkor tömbösítve lehet az összessel foglalkozni.

Van pár levelem, amivel kapcsolatban a feladónak hónapokkal ezelőtt ígértem, hogy válaszolok, de még mindig nem ejtettem meg, mivel komplex témáról van szó, amit röviden nem igazán lehet kifejteni, ugyanakkor tudvalevő, hogy van egy lélektani határ terjedelemben, ami fölött megnő az esélye annak, hogy a címzett a levelet esetleg nem olvassa végig figyelmesen vagy a jól szerkesztettség ellenére elveszik benne a lényeg. Röviden fogalmazni úgy, hogy a lényeg is átmenjen pedig nem könnyű. Még nem küldtem el és pürézni tudnék önmagamtól.

Néhány pro tipp, avagy ahogyan az emailezés működne egy ideális világban:

0x100. Egyre nehezebb, de ha lehetséges, akkor a levelet ne ilyen-olyan webes szolgáltatás belső üzenetküldőjében küldjük, aminek az okait fejtegettem már korábban.

0x200. Nagyobb az esélye, hogy a levél el is ér a címzetthez, másrészt kiemelt figyelemmel fogja kezelni, ha valamilyen más csatornán ráírunk, hogy "üdv, küldtem emailt a user@domain.tld címedre, pls. nézz rá!" - ha esetleg a cím már nem él, akkor a címzett jó esetben válaszol, hogy küldjem másikra.

0x300. Gyerekek! Tartsuk up-to-date a címeinket, könyörgöm! Tudom, hogy minden szaros ingyenes postafiók bizonyos inaktivitás után nem fogad leveleket vagy megszűnik, de mégiscsak 2017-et írunk, szóval:
- ha egy címet már biztosan nem fogunk használni, irányítsuk át az összes rá érkező levelet az új címünkre, ideértve a spameket is, ez azért fontos, mivel tévesen minősíthet spamnek egy levelet a régi postafiókunk, amit ugye már nem nézünk. A régi mailboxra úgyis érkezik értesítés, hogy lekapcsolják, ha nem lépünk be valamennyi ideig, ezt is irányítsuk át az új címre, aztán amikor kell, szánjunk rá szaros fél percet, hogy belépünk a régibe
- egyáltalán, a spamvédelmet bízzuk a spamszűrőre, nem az a normális megoldás, hogy egyszerűen nem tesszük ki sehova a címünket, hanem az, hogy kitesszük valahova, ahol csöpp ésszel megtalálja az, aki írni szeretne nekünk, az elévült címeket pedig kapáljuk ki onnan, ahol azt tüntettük fel!
- Magyarországon minden eszelős hülyeségre hajlamos költeni a többség, de arra már nem, hogy 8-10 dolláros éves díjért vegyen egy domain nevet, ami egy átlagos szövegszerkesztési feladatnál nem bonyolultabb, de ha valaki totál láma hozzá, akkor kérje meg egy informatikában minimálisan jártas ismerősét. A .hu-s domaint inkább hanyagoljuk, egy generic TLD-vel egy nevet beregisztrálni meg olyan 1-2 perc jobb regisztrátoroknál. Ha ez megvan, és fel is van konfigurálva hozzá egy levelezőrendszer, egyszerűen nem fordul elő olyan, hogy a címünk megváltozik.

Már volt róla eléggé kimerítő poszt ugyanitt, szóval még egyszer nem írom le, de személyes használatra nagyon jó, saját domainnel ingyenesen használható megoldás a Zoho Mail, a Yandex Mail, esetleg a Mail.ru. ínyenceknek, ott az Exchange Online, a Fastmail, és a Hushmail, aki beéri gagyibbal is, annak bagóért a GMX/Mail.com, a Protonmail, a Yahoo, a FN.de, a mail.ch, igazából az összes kicsit is komolyan vehető email szolgáltatónál van lehetőség saját domain beállítására. Aztán ha valamelyik nem tetszik, egyszerűen át lehet költözni egy teljesen másik levelezőrendszerre, a régiből a leveleket áthúzni, a korábbi email cím pedig marad a régi. Ha van valami, ami fölött teljhatalmunk van, történjen bár mi is az interneten, az a saját domainünk, amit senki sem vehet el.

0x400. Rendszeresen ellenőrizzük a Spam foldert, mivel minden levelezőrendszerben előfordulhat, hogy tévesen osztályoznak egy legitim levelet spamnek, de a normálisabbak taníthatóak azzal, hogy a falspozitívokat áthelyezzük az Inboxba, a falsnegatívokat pedig a Spam mappába.

0x500. A legcizelláltabb - legalábbis számomra - hogy melyik levelemet milyen prioritással kezeljem. A minap egy totális baromság megválaszolásába folytam bele, közben pedig egy fontosabb levelet csak ma válaszoltam meg. Egybehangzóan azzal, amit korábban írtam, azaz, hogy a választ azonnal szövegezzük meg, a fejünkben a fontosság/értelmesség szerinti osztályozás gyorsabban fog menni, ha ezt mindig ugyanabban a napszakban tesszük.

Néhány évvel ezelőtt még azt mondtam, hogy ha valaki írna valamit, akkor írja emailen, különben nem válaszolok, aztán beláttam, hogy egyszerűen nem lehet a széllel szemben hugyozni ahol az instant üzenetküldők leuralták a világot, amiből már annyi van telepítve ide vagy oda, hogy nem is számolom. Azon persze egyesek roppant mód ki tudnak akadni, ha küldenek egy üzenetet valami kecskefasz közösségi webes szolgáltatásban, amit nem válaszolok meg, holott valójában arról van szó, hogy be se léptem, nem is olvastam, nem az a típus vagyok, akinek be van kötve az agyába  a Kéktakony Messenger, írhat valaki Viberen, Signalon, Telegramon, Threemán, Wire-en, meg a többi szaron, miközben dolgozom, úgysem nézem meg, csak amikor majd az emailjeimet is, ha valami sürgős, a másik úgyis felhív.

Az emberi hülyeség tényleg reménytelen: nem kevesen fene nagy udvariasságból boldogot-boldogtalant felvesznek a kontaktjaik közé minden hülye közösségi szolgáltatásban, akiről fogalmuk sincs, hogy kicsoda, arról meg főleg nem, hogy ez miért rizikós, egy-egy szutykos emailre meg sokszor annyit nem tudnak visszabüfizni, hogy "hamarosan válaszolok".

Nem, olyan nincs, hogy "még nem volt időm", "akartam válaszolni, de" és hasonlók, ha a világ legelfoglaltabb emberei képesek rá, akkor alighanem más is. A spamek és a notórius hülyék levelei ignorálhatók, mindenki másnak legalább egy válasz egy feltett kérdésre elvből jár.

kép forrása: xaviesteve.com

Amikor kérdezik tőlem, hogy a nyelvtudomány, konkrétabb nyelvtechnológia milyen módon hasznosítható az informatikai biztonság és az igazságügyi informatika területén, az első, ami eszembe jut, hogy milyen módon nem, ugyanakkor nem vagyok egyszerű helyzetben, mivel rendszerint nem ugrik be röviden és informatikusok számára is érthetően summázható, de komoly felhasználási módszer.

Egyszerűek persze vannak: tudtad, hogy egy bizonyos szövegben az írásjelek aránya, a mondatszerkesztés stílusa, többek szerint pedig a leggyakrabban és a legkevésbé gyakran használt 20-20 szó majdhogynem annyira egyedi, mint az ujjlenyomatunk? A nyelvtudomány pedig ötvözve a ma rendelkezésre álló informatikai eszközökkel, egy re elképesztőbb eredményeket érhet el, példaként írom, hogy bő két évvel ezelőtt a Venturebeat írt róla, hogy a bitcoin máig ismeretlen megalkotóját elvben lebuktathatja az általa használt nyelvezet. Ahogy egyre jobb és jobb, mesterséges intelligenciára támaszkodó szemantikai szótárak készülnek, nagyon közel állunk ahhoz, hogy egy plágiumot akkor is ki lehessen szúrni, ha azt valaki az eredeti, webről származó doksit más nyelvből fordította és még át is fogalmazta a szöveget! Az erre alkalmas algoritmusok ugyan nem számítanak kimondottan újnak, a IT-számítási kapacitás most érkezik oda, hogy ezek már a gyakorlatban is bevethetők legyenek ésszerű időráfordítás mellett, anélkül, hogy szuperszámítógépeket kellene bérelni méregdrágán és le kellene tölteni hozzá a fél internetet.  

A mostani poszt apropója egy cikk, ami valahogy csak tegnap jutott el hozzám. Az adathalász emailek és oldalak, amik egy-egy szolgáltatás nevében, annak arculati elemeit felhasználva kérik a felhasználót, hogy adja meg a felhasználói nevét és jelszavát, egyre kifinomultabbak és egyre nagyobb károkat okoznak szerte a világon. Többek szerint a világ legnagyobb bankrablását a Carbanak adathalász kampányon keresztül hajtották végre, ahol a felhasználók emailt kaptak különböző bankok nevében és például arra kérték őket, hogy biztonsági okokból lépjenek be és ellenőrizzék a beállításaikat. Ezt követően egy emailben linkelt adathalász oldalra csalták át őket, a felhasználók többségének pedig nem tűnt fel, hogy a böngésző címsorában lévő cím nem pontosan az a cím, amit akkor szoktak látni, amikor belépnek a megszokott ebanking felületre.

Az adathalász kampányt követően az OpenDNS egyik kutatója, Jeremiah O’Connor elkérte az esetről részletes reportot készítő Kasperskytől szinte az összes elérhető adatot. Mindezt azzal a feltevéssel, hogy szofisztikált adathalász kampány ide vagy oda, valamilyen rendszer vagy közös jellemző csak-csak fellelhető az adathalász levelekben. És talált is több ilyen szabályszerűséget, alapvetően a természetes nyelvfeldolgozás eszközeit bevetve.

O’Connor először egy alapos korpuszt épített a scammer levelek szövegezése alapján, ami kiindulási pont egy nyelv vagy nyelvjárás tanulmányozásakor. Az első dolog, aminek megállapításához nyelvtechnológiára sincs szükség, az adathalász levelek azon közös tulajdonsága, hogy egy adott szolgáltató nevéhez hasonló domainre csalják át az áldozatot, ilyen lehet például a microsoft-update-info[.]com, gmailboxes[.]com és hasonlók. Az egyik dolog, ami O’ Connornak feltűnt, hogy az adathalász domainek nevének formátuma rendszerint úgy épül fel, hogy azok tartalmazzák a megcélzott valódi szolgáltatás nevét ehhez van hozzácsapva valamilyen általános kifejezést, ami elaltatja a felhasználó éberségét, ilyen kifejezés lehet például az "update" egy Windows-frissítésre felszólító, valójában az áldozat gépére malware-t telepítő email esetén. Egy jól ismert név és egy általános kifejezés permutációja persze sokféle lehet, de nem végtelen, a felismert szabály alapján egészen pofás kis szótárat épített fel az OpenDNS kutatója, amit valahogy így kell elképzelni egy kamu Java-frissítésre kihegyezett oldal lehetséges neveit. 

Ezen kívül gyakori még a domainek torzítása hasonló karakterekkel, így például minden további nélkül lehetne regisztrálni az www.0tpbank.hu domain nevet egy adathalász oldal számára. A kutató viszonylag gyorsan tipizálta az adathalász levelekre jellemző nyelvezetet, természetesen nem szorítkozott a domain-nevek elemzésére. A végül elkészült NLPRank-technológia a leveleket egészében értékeli, azaz a gyanus domainekre mutató hivatkozások mellett azt is vizsgálja, hogy egy-egy levél milyen autonóm alhálózatból, ha úgy tetszik, az internet melyik "városából" érkezett. Ha a levél hosszú fejlécében lévő IP-címből az derül ki, hogy olyan AS felől érkezett, amelyik korábban már ontotta az adathalász emaileket, ezt súlyzottan figyelembe vette az algoritmus.

Ezen kívül az adott domainhez tartozó, a domain tulajdonosának adatait tartalmazó WHOIS-rekordban szereplő adatokat vetette össze olyan WHOIS-rekordokkal, amikkel korábban már találkoztak egy biztosan adathalász emailként azonosított domain kapcsán.

Hogy világosabb legyen, hiába regisztrál be egy spambáró mondjuk 100 domaint, a WHOIS-rekord adatai, amik persze maszkoltak, egyezőek vagy nagyon hasonlóak lesznek, ez pedig sok esetben alkalmas arra, hogy ha egy talicska domain ugyanahhoz a szervezethez vagy személyhez tartozik, természetesen akkor is, ha a valódi nevét és elérhetőségeit a WHOIS-rekord nem tartalmazza. A képet az OpenDNS blogjából csentem át, ebben az esetben adathalász oldalak domain-neveinek tömege volt ugyanahhoz a kamu kínai szervezethez beregisztrálva:

Ugyancsak az algoritmus lelkét adja, a domainek hasonlóságának, jelen esetben csaló voltának megsaccolásához kidolgozott módszer. Tekintsük a domain-nevet egy egyszerű sztringnek, azaz szövegnek. Ahogy írtam, az adathalász oldalak címe sokszor csak néhány betűnyi eltérést mutat a legitim szolgáltatás címéhez képest. Mégis, hogyan automatizálható a gyanus domain-nevek szűrése, azaz mikor mondható, hogy alapos rá a gyanú, hogy adathalász oldalról van szó a domain-név alapján? A scammer domain nevek általános sajátosságát figyelembe véve egy domain akkor gyanus, az a leggyakoribb, ha egy jól ismerthez képest két karakterben különbözik. Így például a googlemail.com és a nullásokkal írt g00glemail.com domain név közti különbség éppen két karakternyi, ami pedig nagyon fontos, hogy a szóban forgó lecserélt karakterek egymás közvetlen közelében vannak. Ezen kívül az okos algoritmus, hála a jól felépített szótárnak, azzal is tisztában van, hogy a o-betű nullával való helyettesítése, az l-betű egyes számjeggyel való helyettesítése és hasonlók az adathalász levelekre jellemző sajátosságok.

 

Ami miatt fontos a felhasználók biztonsága érdekében, hogy automatizáltan felismerhetőek legyenek a gyanus domain nevek, egy igencsak gyakorlati dolog: az OpenDNS névfeloldó szervereire a 60 millió felhasználótól naponta átlagosan 60 milliárdnyi DNS-kérés érkezett már 2015-ben, ha pedig az OpenDNS a névfeloldás szintjén felismeri a veszélyes domain-neveket, időben tudja figyelmeztetni a felhasználót, ha már rákattintott, de akár feketelistára is teheti az adott domain nevet.

A kimondottan apró eltéréseket és azok közti távolságot is figyelembe vevő algoritmusok ismerősek lehetnek a bioinformatika területéről, ahol egy-egy, kóros szövetből származó DNS vagy RNS részletének szekvenciáját kell meghatározni, az eltérés pedig egy-egy "betűnyi", azaz nukleotidnyi, egyszeresen vagy többszörösen, egymástól bizonyos távolságban. Ezek az ún. SNP-k nagyon sok esetben semmilyen életfunkcióban nem okoznak változást, megint más esetben súlyos betegségeket alakít ki egy-egy nukleotidnyi eltérés.

A néhol erős egyszerűsítések miatt elnézést kérek! Ahogy korábban is emlegettem, egy olyan korba csöppentünk, ahol minden korábbinál nagyobb szerepet kap az, hogy a kutató, fejlesztő rendelkezzen multidiszciplináris ismeretekkel és ezeket be is vesse, ha kell. Ezért vallom, hogy az egyetemeken, mi több, ahol lehetséges, már középiskolában meg kellene mutatni a tanulóknak, hogy mivel foglalkozik egy-egy cégnél a matematikus, a fizikus, a vegyész, a biológus, a nyelvész, a közgazdász vagy éppen az informatikus. Ugyanis sajnos ha ez elmarad és az egyik szakma képviselőit tömegesen neveli ki úgy a felsőoktatás, hogy még csak egy szemléletes képük sincs arról, hogy más szakmák képviselői mivel foglalkoznak, az nem csak azzal jár, hogy komolyabb helyeken bunkónak nézik őket. A súlyosabb hatás, hogy még csak az esély sem adatik meg nekik, hogy felkeltse az érdeklődésüket valami számukra egészen új dolog [ahogy az én érdeklődésemet felkeltette a nyelvtudomány olyan 24 éves koromban] illetve nem lesznek képesek olyan komplex problémák megoldására, amik az emlegetett multidiszciplináris tudást és holisztikus szemléletet igényelne.

Képek: wordstodeeds.com, komando.com, OpenDNS blog

Amikor emailt küldünk valakinek, annak reményében tesszük, hogy azt a címzett majd el is olvassa. Ugyanakkor bármikor bárki mondhatja, hogy az emailt nem kapta meg, spamben landolt, nem volt még ideje foglalkozni vele, ugyanakkor indokolt esetben, ha a levél kellően fontos volt, tudunk kellene, hogy a levelet a címzett olvasta-e és ha igen, akkor mikor is. Hogyan oldható meg mégis a feladat? Tökéletesen sehogy, de részmegoldás azért van.  

Sokak számára alighanem már csak amolyan megmosolyogtató emlék, hogy az emailek olvasottságáról a címzettől visszajelzést kérhetünk, ha levelezőrendszerünk támogatja azt a pattintott kőkorszakból ránk maradt funkciót, amiben kérelmezi a címzettet, hogy jelezzen vissza a feladónak emailen, ha a levelet elolvasta. Ezt tekinthetjük a klasszikus e-tértivevénynek. A lehetőséget szinte már senki sem használja, ugyanis alapvetően a felhasználók többsége nem akarja a címzettel tudatni, hogy a levelet elolvasta-e, ha fontos dologról van szó, úgyis jelentkezik majd, ha pedig nem, jobb elsumákolnia, aztán tud jönni valami vérszegény kifogással. 

Ahogy írtam, gyakorlatilag egy kihalt lehetőségről van szó, mivel még ha kérünk is ilyen visszajelzést, a címzett levelezőrendszere ezt vagy figyelembe veszi vagy sem, ha támogatott a visszajelzés funkció, a felhasználó még mindig dönthet róla, hogy küldjön visszajelzést, ne küldjön visszajelzést, esetleg a levelezőrendszer rá se kérdezzen, így soha senkinek ne küldjön olvasottsági visszajelzést. 

Ugyanakkor fennmaradt az a természetes igény, hogy a feladó tudhasson róla, hogy a levelét a címzett megkapta, olvasta, csak ha nem válaszol, tesz rá magasról vagy nem jutott el hozzá. Az egész pedig egy régi jó technikával szinte mindig kivitelezhető, hamarosan rátérek, hogy miért nem garantáltan mindig. 

Amikor egy webszerverről egy dokumentumot letöltünk, annak a naplófájljába bekerül többek közt, hogy milyen IP-címmel, milyen böngészővel és böngészőverzióval, milyen oprendszerrel és annak milyen verziójával, azaz milyen géppel történt a letöltés. Megjegyzem, ezek kombinációja sokszor már önmagában is igencsak egyedi. Már több, mint tíz évvel ezelőtt is úgy küldték a hírleveleket a szolgáltatók, hogy abban olyan grafikus elemeket, azaz képeket helyeztek el, amiket HMTL formátumú levélbe szerkesztettek bele, a képeket pedig ennek megfelelően nem csatolták az emailhez, hanem egy külső szerverről töltötték be a HTML megjelenítésnek megfelelően a címzettnél. Nyilvánvaló, hogy ha a levél normálisan megjelent, a hírlevél küldője visszajelzést kapott azzal kapcsolatban, hogy a levelét egyáltalán mennyien nyitották meg, hiszen látta, hogy mennyi különböző logbejegyzés van, ami a képi elemek szerverről való letöltődését tanusította. Biztonsági szempontból viszont nagyban gondolkozva igen nagy kockázatot jelent, ha tudható, hogy valaki pontosan milyen platformmal netezik, ráadásul az IP-címekhek kapcsolódó szervezet és annak helye egyre pontosabban azonosíthatóvá vált az évek folyamán. 

Sok-sok évvel ezelőtt már minden jólnevelt levelezőkliensben és webes levelezőrendszerben alapértelmezés volt, hogy a HTML-formátumú levelekben lévő távoli szerveren tárolt képeket nem tölti le automatikusan, hanem rákérdez a felhasználónál, hogy letöltse-e azokat. Ha a felhasználó úgy döntött, hogy ne töltse le, akkor a feladó nem értesült róla, hogy a címzett a levelet megkapta-e. Viszont könnyen lehet, hogy a címzett egyszerűen nem tudta elolvasni a levelet, mert ilyen-olyan lényegi információk nem szöveges formátumban, hanem egy képre írva voltak a levélben, mint például egy szilveszteri parti helyszíne. Így ha a címzettet érdekelte a dolog, mindenképp le kellett töltenie a képet, mint külső tartalmat is. 

Ez még mindig az ókor. Aztán jöttek az ügyesebb hírlevélkézbesítő rendszerek, amik minden egyes címzett leveléhez külön-külön, egy egyedi, távolról letölthető képet is linkeltek. 

Azaz például, ha valaki feliratkozott pistike@example.org címmel, akkor a hírlevélküldő az adott címhez és hírlevélhez generált egy egyedi nevű fájlt a szerveren, mondjuk http://hirlevelkuldo.tld/track/d1a3c5382be1a69c57f7caccbb8c6858.gif 

ahol a fura nevű GIF, tipikusan 1x1 pixeles átlátszó GIF-fájl a HMLT-levélbe volt ágyazva és ha a fájl a levéllel együtt letöltődött a szerverről, akkor az egyértelműen bizonyította, hogy a pistike@example.org címre kiküldött hírlevél kézbesítődött és Pistike meg is nyitotta azt, természetesen azzal az információval együtt, hogy mikor. 

Az ilyen típusú állandó feedback mesterkéltnek tűnhet, viszont olyan hírlevelet küldeni, amire a felhasználó valaha feliratkozott, a levelezőrendszer nem vágja azonnal spambe, drágább mulatság, mint amilyennek tűnik, a hírlevél küldője pedig érthető módon tudni szeretné, hogy mennyi értelme van egyáltalán hírlevelet küldözgetnie. 

Ezen kívül voltak még ilyen-olyan torzszülött megoldások, mint például a HTML-levélbe ágyazott JavaScript-kód, ami elvben a levél megnyitásakor lefut, érthető módon kicsit is normális levelezőrendszer nem tette lehetővé az azonnali kódfuttatást a levél megnyitásakor. 

Azaz maradt a jó öreg 1x1 pixeles megoldás, ami persze nem csak hírleveleknél vethető be, hanem minden további nélkül egyénileg küldött leveleknél is. Számos szolgáltató van, ami lehetővé teszi ilyen levelek küldését, úgy, hogy a részletekkel a feladónak ne kelljen foglalkoznia, ami viszont közös bennük, hogy sosem garantálják 100%-ra a visszajelzést, de az esetek többségében igen.  Ezek közül egyet mutatok be, utána pedig azt, hogy mindez hogyan kivitelezhető sokkal geekebb stílusban, bármilyen szolgáltató igénybevétele nélkül. Ezen kívül feltételezem, hogy a levelezéshez a legtöbben Gmail-t használnak, azt is webes felületen keresztül – ott viszont gyakorlatilag mindig működik. 

A http://www.getnotify.com/ oldalon egyszerűen csak regisztrálni kell azzal a saját email címünkkel, amelyikkel követett levelet szeretnénk küldeni, majd ha ez megvan, teljesen hagyományos módon megírhatjuk az emailt a címzettnek, nemes egyszerűséggel csak a címzett címének végére kell biggyeszteni a getnotify.com hosztnevet. Azaz ha a címzett pistike@example.org lenne, akkor a levelet a pistike@example.org.getnotify.com címre kell küldeni. 

A küldést követően a Getnotity a levelet átformázza HMLT-formátumúvá, akár HTML levél volt eredetileg, akár nem, majd elhelyez benne a kézbesítésre nézve teljesen egyedi nevű átlátszó fájlt, majd a levél fejlécét olyan módon módosítja, hogy levágja a .getnotify.com hosztnevet a cím végéről és továbbküldi a levelet a címzettnek. A címzett a levelet megkapja, megnyitja, a feladó pedig a Getnotify felületén keresztül értesül is róla, hogy a levél meg lett nyitva, mi több, ha a címzett a levelet többször is megnyitotta, az összes időpont szerepelni fog, amikor a levél meg lett nyitva. Hogy érthetőbb legyen, egy Gmail-es címre küldött levél kézbesítési reportja valahogy így néz ki: 

Mint látható, a report szinte mindent mutatna, ami a kézbesítődéssel kapcsolatos, ráadásul külön-külön, amennyiszer megnyitotta a címzett a levelet, ebben az esetben persze a tesztlevelet egy saját gmail-es címemre küldtem. Gyakorlatilag viszont a levél megnyitásának idején kívül semmilyen értelmes adat nem hámozható ki például a címzett földrajzi hollétét illetően, mert annak helyén a Google szerverei által odamókolt adatok vannak. Mi lehet a magyarázat? 

A Google nagyon jól tudja, hogy a Gmailt a többség webes felületen keresztül használja, ugyanakkor azt is, hogy ha azonnal betöltenék a távoli tartalmakat, az egyrészt felfedné a felhasználó hollétét, az általuk használt platformot, ugyanakkor emellett nyilván igény van rá, hogy a HTML-formátumú emaileket a felhasználók el tudják olvasni úgy, hogy azokban megjelennek a képek is. Éppen ezért nem is olyan rég a Gmail-ben az lett az alapértelmezett beállítás, hogy a távoli tartalmakat is automatikusan betölti a levél megnyitásakor, viszont nem az eredeti helyéről, hanem előzetesen a képet a Gmail a háttérben gyorsítótárazza a GoogleImageProxy-n keresztül, majd innen töltődnek be a képek ténylegesen. Ekkor viszont természetesen a küldő rendszer nem a valódi címzett címét és egyéb platformjellemezőit látja, hanem a GoogleImageProxy-ét fogja naplózni. Nem megyek bele olyan finom részletekbe, hogy a Google természetesen a háttérben nem Windows XP-s gépeket használ Firefox böngészővel a gyorsítótárazáshoz. 

Persze mezei levelezőrendszer esetén, ha a HTML-levéllel távolról letöltődik az apró, átlátszatlan kép, a feladó teljesen valid információkat kap a címzett által használt platformmal kapcsolatban is, ez viszont szinte mellékes, ha a fél világ Gmailt, Outlook.com-ot és hasonlókat használ levelezéshez, amik a GoogleImageProxy-hoz hasonló megoldást alkalmaznak. A filléres és fapados levelezőfelületeknél, mint amilyen a Horde, Squirrel vagy a Roundcube, a rendszer ideális esetben rákérdez, hogy betöltse-e a távoli tartalmat, amit a felhasználó jó esetben csak akkor engedélyez, ha a feladó számára megbízható.  

Érdekesség, hogy az egyik legkomolyabb levelezőrendszer, a Microsoft Exchange alapértelmezés szerint úgy tölti be a levelek megnyitásakor a képeket, hogy nem is kérdez rá, hogy a távoli tartalmat letöltse-e. Az ok alighanem az, hogy meglegyen az a típusú kényelem, amiért egy-egy felhasználó elvár, ha a cége egy Exchange üzemeltetéséért fizet. Ott az Exchange előzetesen persze alaposan átvizsgálja, hogy a levél tartalmaz-e kártékony kódot, amit akár egy képbe rejtettek el, de nem proxyzza magukat a képeket, hanem letölti azokat az eredeti helyükről, így ha tudjuk, hogy a címzett Exchange-t használ a cégnél, ritkábban magáncélra, ott jobban jobb lesz a „találati arány”. 

Végülis mennyire megbízható konkrétan a Getnotify? 

A saját súgóoldalán ugyan azt állítja, hogy a címzett semmit fog észlelni abból, hogy egy követett küldeményről van szó, ez igaz is és nem is. Az átlag felhasználó valóban semmit sem fog észlelni belőle, kicsit is jobban megnézve viszont ordít a trackelt levélről, hogy az egy köztes átjárón lett keresztülpréselve valami miatt. Éppen a Gmail nemrég vezette be azt az újítást, hogy a feladó mellett egy törött piros lakatot helyez el akkor, ha a feladó rendszere nem szavatolta, hogy az email csak titkosított csatornán kézbesítődhet, márpedig a Getnotify esetén ez a helyzet. 

A részleteket megnézve pedig egyre büdösebb lesz a dolog: 

Ami pedig már bizonyító erejű, ha megnézzük az emailt nyers formátumban, ahol nem csak az kerül ki, hogy a látszólag egyszerű szövegként küldött levél valójában egy egyszerű szövegnek tűnő HTML-levél benne egy-két érdekes képpel, ami sima nézetben nem látszik, hanem az is, hogy ha a feladó domain nevéhez DKIM-rekord tartozik, a fejlécben látható, hogy az sérült, lévén hogy a levelet valami út közben megváltoztatta, ez egyébként annak az esélyét is nagyban növeli, hogy a levél a címzettnél spamben landol. 

Összességében elmondható, hogy nem, bárki bármit is mond, máig nincs olyan csoda technika, ami biztosan szavatolná, hogy a levél olvasottságáról a feladó biztosan tudomást szerezzen, pláne nem úgy, hogy azt a címzett ne vegye észre, ha akarja, legalábbis hagyományos emailek esetében nincs és ez így van jól. Ez a technikailag meglehetősen egyszerű trükk viszont az esetek döntő többségében működik, csak személyre szóló levél küldésekor nem túl bizalomgerjesztő, ha a címzett észreveszi, hogy előzetes beleegyezése ellenére ellenőrizni akarta a feladó a levél olvasottságát, hiszen ahhoz vagyunk hozzászokva, hogy ez a címzett magánügye. Egy személyes hangvételű levélbe bele lehet varrni olyan linket, amiben valaminek a megtekintésére kérjük a feladót egy linken keresztül, ami persze olyan szerveren van tárolva, amihez a logjaihoz hozzáférünk, hiszen ekkor ugyanúgy szervernaplóba kerül a linkelt tartalom letöltése, csak éppen egyáltalán nem biztos, hogy kattintani is fog a linkre a címzett. 

Ami fontos, hogy olyan levelet, amilyet például a Getnotify.com készít, írhat bárki, aki olyan levelezőprogramot használ, amelyik támogatja a nyers HTML-szerkesztést, amiben csak egy saját tárhelyre mutató, akár láthatatlan képet lehet elhelyezni, ez lenne a kézműves megoldás. 

Megjegyzem, gyakorlatilag minden levelezőrendszerben tiltható, hogy a levél egyáltalán HTML-ben jelenjen meg vagy éppen az, hogy külső képeket töltsön be. Ha mégis ilyen levelet kapnánk, megbízunk a feladóban tipikusan néhány kattintással engedélyezhetjük a teljes megjelenítést. 

Mindegy, hogy a Getnotify-ről vagy szó vagy valamelyik másikról, a működési elve mindnek az, amit leírtam. A kukkoló funkciót különböző levelezőrendszerek esetén ezekkel a beállításokkal lehet teljesen hatástalanítani.  

Gmail esetén: 

AOL-on: 

Zimbra rendszerben: 

Horde-n: 

Hushmailen: 

Roundcube-on: 

Squirrelmailnél: 

Ha egy levelezőrendszernek hatékony a spamszűrő rendszere, azaz kevés legitim levél landol a szinte sosem nézett levélszemét mappába, ugyanakkor a bejövő levelek közt nincs spam, nyilván jó. Ha már a levelezőrendszer akarja eldönteni a felhasználó helyett, hogy mi levélszemét, kevésbé az. Arról már volt szó, hogy néha a Facebook üzenetküldő úgy viselkedik, mint a Bermuda-háromszög, arról is, hogy az emailek hitelesítése hogyan vagy hogyan nem történik, azokhoz képest most középhaladó téma jön.

Korábban írtam róla, hogy a Facebook üzenetküldési logikájának megváltozása miatt gyakorlatilag sosem lehetünk biztosak abban, hogy a másik felhasználónál kézbesítődik is, amit küldünk, majd nem sokkal később röviden arról, hogy a klasszikus levelezőrendszerek hogyan küzdenek a spam ellen.

Az utóbbiban spamvédelem szempontjából két, a feladó és a levelezőrendszer hosztneveihez kötődő azonosítási technikát emeltem ki, ami megnehezíti, hogy az emailek meghamisítsást és valaki más nevében küldjön levelet. Megnehezíti, de nem teszi lehetetlenné! Mindkét módszer szorosan kapcsolódik a domain-név szolgáltatáshoz, egyszerűsítve az SPF, azaz Sender Policy Framework csak azt ellenőrzi, hogy az adott domainről/levelezőrendszerből jogosult-e a feladó levelet küldeni, míg a DomainKeys és a továbbfejlesztéseként létrejött DKIM már alá is írja a levelet digitálisan, azaz tudja mutatni, hogy a levelet esetleg módosította-e valaki vagy valami miközben a feladótól a címzettig jutott. Végül megjegyeztem, hogy ezek csak annyit igazolnak, hogy a levelet az adott postafiókból küldték, de azt nem, hogy a feladó tényleg a postafiók tulajdonosa, erre már a magasabb szinten működő PGP alkalmas, hiszen a PGP-s digitális aláíráshoz a feladónak az aláíráshoz ott kell ülnie a gép előtt, hacsak nincs a beállítás elszúrva.

A levelezőrendszerekben vagy SPF van beállítva vagy DKIM, gyakran mindkettő, igazából nem is nagyon kell foglalkozni vele. A Gmailt ugyan csak azért nézegetem, hogy képbe kerüljek, ha valamit újítanak benne, a napokban lettem figyelmes a Gmail Labs egyik lehetőségére, amit bekapcsolva a Gmail egy, a levelek mellett lévő apró lakattal jelzi, hogy a Gmail meggyőződött a levél feladójának hitelességéről. A súlyos probléma csak az, hogy a feature ebben a formában súlyosan megtévesztő, mivel a kis lakat megjelenítéséhez megkövetel egy olyan rekordot is, amit a gigaméretű levelezőrendszereken kívül a többi feladó nem tűz a levélhez, saját domainnel használt levelezésnél pedig csak akkor működik hibátlanul, ha ahhoz valakinek saját szervere is van.

A hasznos kis lakatfunkció több tényezőt is ellenőriz a SPF-re és a DKIM-re támaszkodva, ezen kívül figyelembe vesz még egy rekordot, amiről nem írtam. Nos, igen, ha valaki úgy gondolta volna, hogy a levelek hitelesítésével kapcsolatos protokollokat már nem lehet hova tovább cizellálni, annak írom, hogy hát persze, hogy lehet: ez a DMARC, teljes nevén Domain-based Message Authentication, Reporting and Conformance.

Az SPF-re tekinthetünk úgy, mint a feladó postahivatal és helység azonosításáért felelős jelölőre, a DKIM-re pedig úgy, mint a levél írójának aláírására. [a PGP-re pedig úgy, mint a pecsétgyűrűvel levélre nyomott viaszos pecsétjére]. De a fenti Google-funkciót megkövetelő DMARC első ránézésére egyfelől egyszerű, másfelől viszont annyira elborult, hogy komolyan nem tudok rá életszerű analógiát hozni.

Ugyanis a DMARC nem mást csinál, mint a hitelességet hitelesíti, megvizsgálja, hogy az SPF rendben van-e, ha több küldő szerver is küldheti a levelet ["postahivatal"] és ezzel egybehangzóan a DKIM-mel is minden oké, ha esetleg azonos címről érkezhet elvben levél teljesen eltérő levelezőrendszerekből is. Visszapillantva az előző posztban hozott témához, a magyar levelezőrendszerek nem rendelkeznek saját küldő szerverrel, azaz SMTP-vel, így ha valaki nem webes felületen, hanem levelezőprogrammal vagy a mobiljával szeretne levelet küldeni a mobil beépített levelezőkliensével, akkor abban küldő szervernek a szolgáltató SMTP-szerverét fogja beállítani, aminek viszont semmi köze nem lesz a feladó domainhez és az ahhoz kapcsolódó hosztnevekhez. Ez UPC esetén smtp.upcmail.hu lesz, amire  @upcmail.hu-s azonosítóval lehet fellépni, Telekom esetén pedig a mail.t-online.hu az SMTP szerver, amivel a t-online.hu-s címmel léphetünk fel, ha nincs netszolgáltatásunk csak egy magentás mobilunk, akkor mail.t-email.hu hosztnévvel és így tovább. Azaz például az indamail-es levelet a Telekomon vagy az UPC SMTP szerverén keresztül nyomva szigorúan nézve semmi sem garantálja, hogy valóban a feladó mezőben lévő felhasználó küldte a levelet, mivel egy levelezőrendszer szervereinek semmi köze nincs a netszolgáltató szervereihez, a címzett szerver gondolhatja úgy, hogy a címzett csak oda lett kamuzva a levélhez, ha az például Citromail.hu-s, az egyszerűsítésekért bocs.

Azaz azt kellene valahogy elérni, hogy a Gmail-es címzettek postafiókjában ott legyen a kis lakat, ha esetleg tömegesen bekapcsolják ezt a funkciót, ez viszont csak akkor fog működni, ha a feladónál helyes SPF, DKIM és DMARC rekordok vannak beállítva. És itt kezdődik a totális rémálom: az SPF rekord ugye egy egyszerű dolog, viszont a DKIM-et már támogatnia kell a levelezőrendszernek, ami a levelet küldi, azaz nem elég csak a domainnév-szerveren léteznie az aláíráshoz szükséges publikus kulcsnak, magának a szervernek az aláírást el kell végeznie. Ez azért még minden komolyabb saját domaines levelezőrendszerben elérhető, úgy, mint a 10 felhasználóig ingyenes Zoho Mail vagy a Yandex Domains. Viszont a levelezőrendszerek többsége a postagalambnak nem mondja meg, hogy még egy DMARC értéket is oda kellene böknie. Például még a Microsoft Exchange Online esetén is csak alig egy éve van erre lehetőség és persze érdemes azt is figyelembe venni, hogy a DMARC-ot a címzett szervere majd vagy értelmezi vagy sem függően attól, hogy fel lett-e készítve rá.

Az előző levelezőrendszerekkel foglalkozó posztban írtam, hogy a Gmailen a kis nyílra kattintva kiderül, hogy a levelet formálisan ki küldte milyen domainről [ez a példában a whitehouse.gov volt], ezt követően ténylegesen milyen domainnel [ami egy filléres netszolgáltató szervere volt] és ki hitelesítette [ez a mező hiányzott, nem kötelező]. Azaz valahogy így:

A példában használt Zoho viszont nem támogatja a DMARC-ot, ezért eleve nem lehetett beállítani sem, megnéztem, hogy mi történik, ha a levél küldéséhez a szintén több tízmillió felhasználóval rendelkező Microsoft Exchnage Onlinet használom, persze megfelelő beállítás után.

Remek! Tehát nem a hosztnév virít a hitelesítő domain helyén, mint amelyik a feladóé annak ellenére, hogy az SPF szabálynak megfelel a levél, a DKIM ugyancsak szabályos, ahhoz nem is lehet hozzányúlni, mivel az az Exchange szerver belügye, legalábbis EOL esetén. A levél hosszú fejlécéből kiderül, hogy ez már tartalmaz szabályos DMARC jelölést is.

De akkor miért nem kapott lakatot? Egy lehetséges ok, hogy a DKIM hitelesítés szabályos ugyan, de az már nem a feladó címéhez tartozó domainnévhez lett hozzárendelve.

Az IT-s részletekről alighanem már így is többet írtam, mint amennyire az a töbséget érdekelheti, a kínos kérdés csak az, hogy akkor most a Gmail valóban meg tudja mondani automatizáltan, hogy egy email hiteles-e? Hát persze, hogy nem! Ugyan a DMARC-technika hatékonynak tűnik az email spoofing most ismert módszerei ellen, könnyen keltheti azt a megtévesztő benyomást a felhasználókban az addon, hogy amelyik levél mellett nincs lakat, az nem feltétlenül hiteles, ami pedig még rosszabb, hogy emellett azt a benyomást is, hogy amelyik mellett pedig van, az biztosan hiteles olyan értelemben, hogy a feladó írta. Na ez a tragikus. És persze az, hogy a Gmail, az Outlook, a YahooMail, a Yandex megint úgy tesz, mintha rajtuk kívül nem is létezne levelezőrendszer, szóval szépen alkalmazkodjon mindenki hozzájuk.

Mi a megoldás? Továbbra is az éberség és a józan eszünk. Ha valamilyen kétség merül fel azzal kapcsolatban, hogy egy beérkező levelet esetleg nem a feladója írt, nézzük meg a levél hosszú fejlécét, igaz, abban tudni kell, hogy mit is kellene benne nézni.

A posztot végig kísérte az a gondolat, hogy a levél feladóját és íróját ne keverjük, nyilván küldhet valaki akár közvetlenül más postafiókjából is levelet, ha annak a jelszava 10 éve ugyanaz és már a postit cetlit, amire rá van írva, úgy kellett a monitor szélére celluxozni. Azt, hogy a levél feladója és írója azonos, ahogy írtam, a PGP szavatolja. Igaz, alapvetően a PGP célja más, de nem alapvetően más. Mindkét megoldás végülis a levélhamisítás ellen hivatott védeni. Hogy mikor lesz PGP a Gmailben? Nyilván soha. Egyrészt azért, mert nem éreznék a felhasználók eléggé komfortosnak, ha a belépéshez használt jelszón kívül egy másikat is meg kellene adni egy-egy levél elküldése előtt, másrészt nyilván elkezdenének titkosítani is vele a felhasználók a digitális aláírás mellett, azaz csak a címzett és a feladó tudná elolvasni a levelet, maga a Google nem. Nos, ez nem érdeke egy olyan levelezőszolgáltatónak, ami a magánlevelek tartalmának befalásából él, igaz, az ebből szerzett információ jórészét arra használja fel, hogy a szolgáltatásai hagyományos értelemben használhatóbbak legyenek és hatékonyabb legyen a keresés.

 Ahogy egyre nagyobb részben folytatjuk a személyes és munkához kapcsolódó kommunikációt is a neten, folyamatosan vált egyre fontosabbá, hogy minden olyan eszköz, ami ezt biztosítja egyre stabilabb és biztonságosabb legyen. Ezeknek az szolgáltatásoknak az egyike az email, ami - ahogyan írtam a korábbi posztomban - mai formájában legalább három évtizede létezik, megelőzte a web születését közel tíz évvel, a net legősibb, máig széles körben használt szolgáltatása és alighanem minden webes óriást túl fog élni, amiről ma még nem gondolnánk, hogy valaha bizony vége lesz.  
 
Kiemelt fontosságú, hogy ha emailt kapunk, ellenőrizhető legyen, hogy a feladó valóban az-e, akinek gondoljuk, ezt pedig sokszor ugyan azokra a technikákra támaszkodva lehet megtenni, amit spamvédelem céljából kitaláltak. Egy durván meghamisított levél példáján mutatom be, hogy mikor mit érdemes nézni, az emailek hosszú fejléce minden webes levelezőrendszerben megjeleníthető, a legelterjedtebb Gmail esetén például a levél megnyitását követően a legördülő menüben a Show original pontra kattintva. 

 Amikor valaki egy nevet és egy hozzá tartozó email címet lát a feladó mezőben, teljesen természetesnek veszi, hogy a levelet az írta, akinek a neve és címe olvasható, nemde? Óriási tévedés! Az, hogy a feladó neve és a cím mezőben mi álljon, csupán egy adalék információ, amit a feladó szervere az email fejlécéhez hozzáfűz, viszont semmiféle megkötés nincs azzal kapcsolatban, hogy ott mi szerepelhet, mi több, még az sem megkötés, hogy ki legyen töltve. Viszont abban az esetben, ha valaki megmókolja a levelezőrendszert a levélküldés idejére olyan módon, hogy az valamilyen tetszőleges címet csapjon a levélhez, a levél elmegy ugyan, a címzettnél akár a spam mappába megy, akár sem, a levelezőrendszerek a címzettnél jó esetben figyelmeztetnek azzal kapcsolatban, hogy a levél valószínűleg hamisívány. Viszont, ahogy a frissen előállított példában látszik, simán lehet, hogy nem, annak ellenére, hogy minden arra utal, hogy a levél hamisítvány, mégsem jelzett a Gmail emiatt. Hamisított levélre utaló figyelmeztetést eredményezhet más is legitim levelek esetében, viszont érdemes tudni, hogy hogyan tudható meg esetleg több a valódi feladó kilétéről. 
 
Nosza, lássuk azt az előbb emlegetett hosszú fejlécet! 
 
Delivered-To: bardoczi@gmail.com 
Received: by 10.27.186.198 with SMTP id k189csp415282wlf; 
        Fri, 8 Jan 2016 03:48:06 -0800 (PST) 
X-Received: by 10.140.101.201 with SMTP id u67mr91933194qge.33.1452253686478; 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Return-Path: <president@whitehouse.gov> 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
        by mx.google.com with ESMTPS id r9si92146028qhb.7.2016.01.08.03.48.06 
        for <bardoczi@gmail.com> 
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Received-SPF: softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) client-ip=104.193.143.56; 
Authentication-Results: mx.google.com; 
       spf=softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) smtp.mailfrom=president@whitehouse.gov 
Received: from localhost ([::1]:63179 helo=ecbiz178.inmotionhosting.com) 
    by ecbiz178.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) 
    (Exim 4.85) 
    (envelope-from <president@whitehouse.gov>) 
    id 1aHVWX-000DKS-T9 
    for bardoczi@gmail.com; Fri, 08 Jan 2016 06:48:06 -0500 
Received: from 179.43.161.147 ([179.43.161.147]) by 
 secure178.inmotionhosting.com (Horde Framework) with HTTP; Fri, 08 Jan 2016 
 11:48:05 +0000 
Date: Fri, 08 Jan 2016 11:48:05 +0000 
Message-ID: <20160108114805.Horde.zOWNX3cXXgeNf-MxqaUvuw5@secure178.inmotionhosting.com> 
From: President of US <president@whitehouse.gov> 
To: bardoczi@gmail.com 
Subject: =?utf-8?b?aGFkw7x6ZW5ldA==?= - fake =?utf-8?b?bGV2w6ls?= 
Reply-to: akos@null.net 
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) 
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes 
MIME-Version: 1.0 
Content-Disposition: inline 
Content-Transfer-Encoding: 8bit 
X-OutGoing-Spam-Status: No, score=3.6 
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report 
X-AntiAbuse: Primary Hostname - ecbiz178.inmotionhosting.com 
X-AntiAbuse: Original Domain - gmail.com 
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] 
X-AntiAbuse: Sender Address Domain - whitehouse.gov 
X-Get-Message-Sender-Via: ecbiz178.inmotionhosting.com: authenticated_id: akos@genetics.bardoczi.net 
 
A valódi küldő felhasználó azonosítása és a feladó mező összevetése az első lépés.  
 
A hosszú fejléc sorai közt az X-szel kezdődők nem kötelezők a levelezőrendszerek számára. A levelezőrendszereknek nem kötelező hozzáfűzniük, hogy egy levelet pontosan milyen felhasználó vagy alkalmazás feladói felhatalmazásával küldenek, viszont ha nem totálisan hülyén van konfigurálva a levelezőrendszer, akkor tartalmaz ilyet, ez jelen esetben az "authenticated_id: " sor, amivel gyakorlatilag semmi sem stimmel. A sorban lévő akos@genetics.bardoczi.net csak annyit mond, hogy amikor a levelezőrendszer átvette kézbesítésre a levelet, akkor ezzel a felhasználói névvel lett feljogosítva a levélküldésre. Ha semmilyen azonosítás nem feltétele egy levél kiküldésének, ún. open relay szerverről beszélünk, azaz olyan levelezőszerverről, amin keresztül bárki bármit küldhet bármiféle azonosítás nélkül. Mivel valamikor rég ezeket előszeretettel használták a spammerek, open relay-t már nagyon keveset találunk, hiszen ha olyan helyről érkezik email, azzal valami teljesen biztos, hogy nem stimmel. Ugyan vannak a neten olyan oldalak, ahol egyszerűen csak meg kell adni, hogy mi kerüljön a feladó, a tárgy és az üzenet mezőbe, hova menjen az email, az ilyen levelek jobb helyeken közel biztos, hogy spamben landolnak, másrészt általában még az ilyen kamu emailek sem open relayen keresztül mennek, hiszen a hamisító szolgáltatás van feltüntetve küldésre feljogosított felhasználóként, ami persze csak a hosszú fejlécből derül ki. Viszont vegyük észre, hogy legalább van lehetőség azonnal kideríteni, ellentétben például a Facebook-üzenettel, amivel a továbbiakban nem fogom hasonlítgatni az emailt.  
 
A bűvös boríték és "vissza a feladónak", azaz envelope és return-path 
 
Ha jobban megfigyeljük a levelet, figyelmesek lehetünk az egyik Received sorban található "envelope-from <president@whitehouse.gov>" részre. Az envelope, azaz boríték azonosításához a levelezőrendszerek sokszor külön sort hoznak létre, akkor biztosan, ha az nem egyezik a valódi emailcímmel, ami felhasználói név is egyben. Még a Return-path sorban is a hamis email cím szerepel, ami azt a címet tartalmazza, ahova a címzett szerverének mailer daemonjától várja a visszaküldést akkor, ha a kézbesítés sikertelen valami miatt, azaz ide pattan vissza a feladóhoz a levél. Egy szó, mint száz, ebben az esetben (sem) szerepelt valami fényesen a legelterjedtebb kommersz levelezőrendszer a kamu levél kiszűrérében. 
 
A postás és a postahivatal  
 
Persze az azonosított feladó cím lehet, hogy még mindig nem mond semmit, az első Received sorban lévő szerver hosztneve és IP-címe már egyértelműen azonosítja, hogy mi is vette át a levelet küldés céljából elsőként:  
 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
 
Márpedig ha ennek utánanézünk például az ARIN adatbázisában, abból kiderül, hogy a levél egy mezei hosztingszolgáltatótól jött, ráadásul azon belül is egy olyan szerverről, ahova a filléres hosztingot igénylő ügyfelek oldalait teszik, mint amilyen az én életrajzi oldalam. Ennek ténye egyre valószínűtlenebbé teszi, hogy a levél valóban a Fehérházból jött volna.  
 
Amikor az email küldéshez szerver sem kell  
 
Megjegyzem, elvben az is megoldható, hogy valaki az otthoni gépére telepítsen olyan szolgáltatást, amin keresztül tud levelek küldözgetni úgy, hogy maga a levelezőszerver is az ő otthoni gépe. Normál esetben egy levelezőszerver IP-címéhez tartozik egy hosztnév, ebben az esetben a reverse hostname-re gondolok, azaz ha nem tudnánk, hogy a ecbiz178.inmotionhosting.com hosztnévhez a 104.193.143.56 cím tartozik, a cím alapján meg lehet nézni a hosztnevet, már ha van.   
 
Egy egyszerű internetszolgáltatással rendelkező gépnek viszont nincs feltétlenül szüksége arra, hogy ahhoz hosztnév legyen hozzárendelve, abban az esetben pedig, ha mégis van hozzárendelve, akkor arról általában süt, hogy otthoni felhasználók gépeinek, végfelhasználóknak kiosztott hosznévről van szó. Egy UPC-s magánelőfizető IP reverzje aaa.bbb.ccc.ddd cím esetén catv-aaa-bbb-ccc-ddd.catv.broadband.hu lesz, azaz látszik ugyan, de ebből azonnal kiderül az is, hogy nem szerverről, hanem valakinek az otthoni gépéről van szó, a címre egyszerűen elég rákeresni az európai és közel-keleti IP-ket nyilvántartó RIPE-adatbázisában, ha nem lenne elég egyértelmű. Hasonlóan például egy Vodafone-os magánelőfizető címe hiába reverselhető, a RIPE lekérdezés alapján egyértelmű, hogy magánelőfizetőről van szó és nem pedig levelezőszerverről:  
 
 Még egy kicsit a hamisított feladói címről  
 
Adott címről érkező levél esetén természetesnek vesszük, hogy arra simán válaszolva a címzettnél meg is érkezik valami. Amikor emailt küldünk valakinek, a kézbesítéshez többek közt a domain név szolgáltatáson keresztül le kell kérdezni a hosztnévhez tartozó ún. MX-rekordokat, ami azt dönti el, hogy a beérkező emaileket mely gépek kezeljék, azaz kik töltik be a postahivatalok szerepét, ha a domain-nevet tekintjük a címzett városának. Ez a freemail.hu esetén például fmx.freemail.hu ugyan a netes szolgáltatások szabványosításáért dolgozó IETF azt javasolja, hogy levelet fogadó domainhez legalább kettő MX-rekord, azaz „postahivatal” tartozzon arra az esetre, ha az első valami miatt nem érhető el vagy túlterhelt, de ne is legyen belőle 10-nél több. Persze könnyen lehet, hogy ha csak egy MX-rekord van, akkor az egy terheléselosztó vagy tűzfal, mögötte sok-sok postással. Mégis gyakoribb megvalósítás, hogy MX-rekordból több van, a secure.bardoczi.net domain esetén például 14, földrajzilag gondosan távol egymástól, épphogy a Holdon nincs.   
  
Viszont ha az email címben szereplő domainhez nem tartozik MX-rekord, akkor gyakorlatilag biztos, hogy kamu címről van szó, hiszen MX-rekord nélkül az adott domain nem tud emailt fogadni, az pedig életszerűtlen hogy úgy működjön egy domain név, amiről csak küldeni tud, de fogadni már nem. A genetics.bardoczi.net jelen esetben ilyen:  

http://mxtoolbox.com/SuperTool.aspx?action=mx%3agenetics.bardoczi.net&run=toolpage  

Mi lehet a célja egy ilyen emailes scamnek?  
 
Felmerül a kérdés, hogy a példában hozott scam emailnek mi lehet a célja, miért kér a feladó bankkártyaadatokat, ha ezek szerint a president@whitehouse.gov címre érkezett levelet úgysem kapná meg, mivel nem is ő küldte? És egyáltalán: mindig érdemes a levél tartalma alapján felállítani néhány forgatókönyvet azzal kapcsolatban, hogy valaki kamu címmel, kamu személyazonossággal vajon miért írja pont azt, amit? Ebben a levélben ugye arról van szó, hogy ha a címzett nem küldi a bankkártyaadatait, itt bizony vér fog folyni. Mivel a Gmail rövid fejlécéből nem derül ki semmi szokatlan, a laikus felhasználó gondolhatná, hogy ha a válasz gombra kattint, a levél a whitehouse.gov-os címre küldi a levelet, ha viszont kamu, úgyis visszapattanna, nemde? Igen ám, viszont abban az esetben, ha a válaszcím, azaz az a cím, amire a feladó a választ várja, eltér a feladó címétől, ilyenkor a levelezőrendszernek kötelező elhelyeznie egy Reply-to sort, amiben pedig az akos@null.net cím van, aminek aligha van bármi köze is a Fehérházhoz. Viszont amikor az egység sugarú felhasználó a válasz gombra kattint, egyáltalán nem veszi észre, hogy a címzett mezőben már más cím szerepel, mint amiről a levél érkezett, amit épp megválaszol és erre a levelezőprogramok nem is hívják fel a figyelmet!  
 
Jelen példa persze blőd, de gondoljunk bele, hogy a feladó mezőben simán szerepelhetne egy bank címe is, a levélben a bankra jellemző arculati elemekkel és persze hihetőbb szöveggel, a válaszcím pedig lehet bármilyen ingyenes mailszolgáltatónál létrehozott, esetleg totálisan visszakövethetetlen emailcím, amire a csaló a kért adatokat megkapja, ha az áldozat válaszol is rá.   
 
A spamekkel és scamekkel vívott automatizált küzdelem  
 
Felmerülhet a kérdés, hogy hogyan jelenthet csak a spam önmagában sok-sok százmillió dolláros össz-veszteséget évről évre, ha olyan levelekről van szó, amiket a felhasználó úgysem olvas el? Úgy, hogy a spamek küldése, fogadása mind használja az IT erőforrásokat, legyen szó akár az adatátvitelről, akár arról, hogy ezeket a leveleket a levelezőszervereknek fel kell dolgozniuk, ami ugye processzoridőben mérhető, és persze valameddig tárolni is kell őket, aminek szintén forintosítható-dollárosítható ára van. Ahogyan annak is, ha az alkalmazott megnyit egy spamet, ha az olvasására csak negyed percet szán, az is a munkaidejéből megy el. Mindezek bagatell apróságoknak tűnnek, de ha nagyban gondolkozunk, ha már felhasználók számilliói érintettek, érthető, hogy miért kerül nagyon sokba a spam, még ha jól is van szűrve, nem is beszélve arról az esetről, amikor egy fontos levél falspozitívként kerül spambe és valaki nem értesül időben valamiről, ami egyébként fontos lenne. A scam, azaz a megtévesztő levél más műfaj és máshogy is okoz költségeket és kellemetlenségeket, például ha a felhasználó olyan linkre kattint, amivel valamivel alaposan lefertőzi a gépét, amit az antivírus termék nem szúr ki.  
 
Ami a spamben és a scamben közös, hogy nyilván minél jobban hasonlítaniuk kell a legitim levelekhez, hogy megtévesszék a spam- és scamszűrő rendszereket és eljuthassanak a felhasználókig. Így a versenyfutás a spammerek és a levelek biztonságáért felelős fejlesztők és kutatók közt folyamatos. Alapvetően a legitim és fölösleges-kártékony levelek szűrése a tartalom és a fejléc automatizált elemzésével történik. A tartalom alapú elemzéssel itt egészen röviden foglalkozom. Igencsak kifinomult gépi tanuláson alapuló mechanizmusok dolgoznak a háttérben, amikor nagy mintán tanulják a szerverek, sokszor közösen, hogy mik a spamek és a legitim levelek jellemzői, ez alapján következtetnek.  
 
A gépi tanulás lényegéről korábban már itt írtam annak kapcsán, hogy hogyan idomítottak be egy gépet arra, hogy megkülönböztesse az előnyös és az előnytelen szelfiket. A kifinomult tanulóalgoritmusok helyett vegyük a legegyszerűbb hipotetikus spamszűrőt: ha tudjuk, hogy egy 1000 levélből álló mintában abból a 200-ból, ami tartalmazza a Viagra kifejezést pontosan 199 spam, akkor a jövőre nézve biztosak lehetünk benne, hogy ha jön egy levél, aminek a szövegezésében a Viagra szerepel, jó eséllyel ugyancsak spam lesz. Ez az ún. Bayes-valószínűségen alapuló szűrés.  
 
Vissza a fejlécekhez  
 
A levélszemét szűrésének tartalmi elemzést megelőző lépése viszont a – sokkal kisebb számításigényű – fejlécelemzés, ráadásul ha a fejléccel túl sokminden nem stimmel, a levelet esetleg a szűrő már nem is vizsgálja tartalmi szempontból. A header elemzésekor többek közt a levelezőrendszer olyan sajátosságok után kutat, amikről írtam a poszt első felében, azaz amik végképp nem jellemzők egy normális emailre. Másrészt idővel bevezettek olyan technológiákat, amik a fejlécben helyeznek el extra, az emailt hitelesítő sorokat, azaz olyan sorokat, amiket pillanatok alatt ki tud elemezni első körben a fogadó szerver. Ezek ugyan messze nem tökéletesek, de jobbak, mintha csak tartalom alapú elemzésre és az alapvető ellentmondások elemzésére támaszkodhatna a spamszűrő.  
 
A Sender Policy Framework, avagy SPF  
 
A legősibb és legegyszerűbb megoldást az SPF jelentette. Szinte minden levél hosszú fejlécében találunk SPF-re vonatkozó sort, ami mutatja, hogy a domainhez beállított SPF-szabályokkal összevetve a levelet milyennek értékelte a szerver. Az SPF-szabályokat pedig a doménnév szolgáltatásból tudja lekérdezni. A kiértékelés eredménye lehet semleges, legitim vagy éppenséggel bukó, de ezzel a levél sorsa természetesen nem dől el végleg, hanem csak hozzáad vagy kivon abból a pontszámból, ami fölött a fogadó szerver egy levelet spamnek talál.  
 
Példaként, ha az SPF-szabály IP-cím alapján van meghatározva a domainhez tartozó domain név szerverben, az egy ilyesmi bejegyzés lehet a domainhez tartozó rekordok közt:  
 
v=spf1 a:kuldoszerver.example.com –all  
 
Ez annyit jelent, hogy a fogadó fél megnézi a küldést végző hosztnév IP-címét vagy hosztnevét és ha az egyezik azzal az IP-címmel, ami a kuldoszerver.example.com domainhez tartozik, akkor az a levél legitim, minden más esetben viszont valószínűleg spam, ezért el kell dobni, amit a -all paraméter határoz meg.  
 
Az SPF szűrési logikája alapulhat még más egyéb tényezőkön is, a fenti példát azért választottam, mert a legegyszerűbb, de van még pár beállítási lehetőség bőven.  
 
Fontos, hogy az SPF nem élet és halál ura, azaz ha például egy adott domainről érkezik hamisított feladóval egy levél, amit biztosan nem a domainhez tartozó levelezőszerveren keresztül küldtek, akkor az az SPF szerint spam ugyan, viszont a kifinomultan konfigurált spamszűrő csak egy valószínűségi értéket rendel hozzá, hogy ennek alapján a levél elbuktott, legitim vagy semleges. Hosszú lenne kifejteni, de az SPF működésmódjából adódóan egyrészt még ez is megkerülhető a spammerek számára, másrészt elvben előfordulhat, hogy egy teljesen legitim levél repül spambe. Másrészt ahogy írtam, az SPF megléte a névszerveren  nem is kötelező.  
 
Példaként ha valaki nem webes felületről, hanem kliensprogramból használja a postafiókját, viszont Indamailt vagy Freemailt használ, amivel a levelek letölthetők ugyan, viszont küldeni levelezőprogramon keresztül nem lehet, a felhasználó kénytelen lesz más szervert használni a küldéshez, például a netszolgáltatója levélküldőjét, azaz SMTP-szerverét. Könnyen belátható, hogy az előző SPF-logika alapján a levél minimum spamgyanusnak lesz nyilvánítva a fejléce alapján, ilyen szempontból kész szerencse, hogy eléggé kevesen használnak levelezőprogramot böngésző helyett a levelezéshez, viszont akik igen, ezt általában tudják is. Azt hinnénk, hogy a túl szigorú SPF beállítás, azaz amikor a szűrést végző szerver nem csak lepontozza a levél hitelességét, hanem vakon az SPF alapján jár el és el is dobja azt, nem túl gyakori beállítás. Sajnos olyan cégek is gyakran rosszul konfigurálják a szűrést küldésre és fogadásra vonatkozóan, amikről nem hinnénk.    
 
DomainKeys, DKIM és az Identified Internet Mail  
 
Ezek a megoldások elvben nem voltak jobbak vagy rosszabbak, mint az SPF, hanem teljesen mások, gyakorlatilag viszont jóval korszerűbbek, számos olyan sajátossággal rendelkeztek, amik mégis nagyban megnehezítették egy-egy email meghamisítását.  
 
Mindháromnak az alapját az jelenti, hogy a domaint működtető névszerveren be van állítva egy publikus kulcs, amit a küldő szerver aláír, majd a fogadó fél szervere lekérdezve ezt a publikus kulcsot ugyancsak a névszerverről, a feladó legitimitásának azonosításán túl azt is ellenőrzik, hogy az emailt átvitel közben esetleg nem hamisították-e meg, ami sokkal gyakoribb és egyszerűbb, mint ahogy azt az Olvasó gondolná.  
 
Ugyanakkor több szempontból sokkal nagyobb rugalmasságot biztosít, mint az SPF, hogy mást ne mondjak, elvben az SPF egy sima szöveges rekord ugyan a névszerveren, mi több, lehet el kilométeres is, gyakorlatilag a fogadó fél gyakran nem értelmezi a szabályt, ha 255 karakternél hosszabb.  
 
A Yahoo által kitalált DomainKeys és a Cisco-tól származó IIM összegyúrásából született DKIM esetén viszont ugyanazzal az email-címmel való üzenet küldéséhez használhatjuk teljesen eltérő szolgáltatók küldő szervereit is, a küldő szerver egyszerűen csak hozzácsapja a nyilvános kulccsal és persze az általa használt titkosító algoritmussal kiszámított ellenőrzőösszeget, amit a fogadó fél majd ellenőriz. Ugyan a DomainKeys-t, azaz DK-t, amit gyakran kevernek a DKIM-mel, elvben felváltotta az utóbbi, gyakorlatilag viszont nagyon sok szerver előnyben részesíti, ha a levél a régivágású módszerrel is alá van írva. Annyira, hogy a példánál maradva a Gmail máig csak akkor fogad el teljesen hitelesnek egy levelet, ha helyes DomainKeys értéket is talál benne.  
Az alábbi ábrát az appmaildev.com-ról vettem át:  
 

Hogy a saját leveleink tartalmaznak-e SPF, DK és DKIM értékeket, valamint azok helyesek-e a http://www.appmaildev.com/en/dkim/ -en ellenőrizhetjük, ahol egy email-címre küldött levelet követően a szolgáltatás egy részletes elemzést fog visszaküldeni.  
 
Hasonló, kevésbé részletes, de áttekinthetőbb eredményt ad, ha  a http://dkimvalidator.com oldalon megjelenő email címre küldünk emailt, majd néhány másodperc múlva megnézzük az eredményt.  
 
Esetleg marginálisnak tűnik foglalkozni ilyen részletekkel, egyszer mindenkinek érdemes eljátszania vele azért is, mert abban az esetben, ha valaki egy beígért emailt nem kap meg, annak senki sem örül főleg akkor nem, ha fontos emailről lett volna szó.  
Az emailek itt ismertetett hitelesítése protokoll-szinten működik, még mindig összesen csak annyit bizonyít, hogy egy-egy adott levelet a feladó postafiókjából küldtek, azt viszont nem, hogy valóban a postafiók tulajdonosa küldte, nem pedig valaki, aki odament a lezáratlan gépéhez vicceskedni ebédidőben.  
 
Alkalmazásréteg szintjén a levelek hitelesítése a korábban tárgyaltaktól teljesen függetlenül a digitális aláírással oldható meg, aminek de facto standardja a PGP, aminek az alapjairől korábban írtam itt  a finomhangolásáról pedig ebben a posztban.  
 

Igaz, nemrég ígértem, hogy bemutatom, hogyan azonosítható egy webes felületről elküldött Gmail-es levél földrajzi helye, annak ellenére, hogy a Gmail-en keresztül küldött levél nem tartalmazza a kliens IP-címét - ellentétben a Google Apps-en keresztül küldött levelekkel, amik igen! -  mindez esélytelen lenne ésszerű terjedelemben úgy, hogy közérthető is legyen - viszont kommentben tippelni lehet!  
Képek: filterforge.com, pophangover.com, themetapicture.com