bardóczi ákos @post.r

Nem, nem fizettek egy zsák arannyal a taxisok, hogy írjam meg ezt a posztot. Ami azt illeti, semmi helye nem lenne a blogon, ha nem lenne egy-két fontos vonatkozása: a biztonság és átláthatóság.

Volt ugye a hét elején ez a cirkusz az Uber miatt, amire mindent mondhatunk, csak azt nem, hogy Magyarországra specifikus jelenség. Az Origó sederített is egy remek ábrát azzal kapcsolatban, hogy mennyi országban volt már dráma ezzel kapcsolatban és mennyi országban tiltották meg az Ubert, ami azért eléggé erős, ha egybevetjük azzal, hogy ezek közt az államok közt vannak olyanok is, amiknél a történelmük szerves része a szabad versenyben való hit. Innentől kezdve bukik az az érvelés, ami szerint a magyar taxisokkal azért nem lehet egyetérteni, mert a social economy korában túl retrográd azt mondani, hogy az Uber igazságtalan azért, mert egyszerűen csak beszállt a versenybe egy bizonyos piacon, hiszen betiltották olyan helyeken is, ahol alapvetően a verseny szent és sérthetetlen.

kép: origo.hu

Ha van néhány dolog, amiben szinte vakon hiszek, az a véleménynyilvánítás szabadsága mellett a szabad verseny, mindkettőnél azzal a feltétellel, hogy nem sértheti aránytalan mértékben és közvetlenül másvalaki érdekeit. És itt jön be a képbe a biztonság.

A taxisok az unalomig ismételgetik, hogy nekik bizony feltételeknek kell megfelelniük, vizsgázniuk, a kocsijuk állapotát rendszeresen ellenőriztetni kell, míg az Uber sofőröknek nem. Az előbb leírtakból adódóan engem elvből totál nem érdekel, hogy ez nekik akkora költséget jelent, hogy amiatt már nem tudják felvenni a versenyt azokkal, akikre ezek a feltételek nem vonatkoznak. Viszont! Az tény, hogy a taxisok az átlagosnál jobbak a vezetésben, amiben nincs meglepő, hiszen ez a hivatásuk. Jól megválasztott taxitársaságok kocsijai biztonságosabbak is, egyébként is eleve komolyan vehető biztosítással szállítják az utast, az már-már mellékes, hogy a szintén jól megválasztott taxitársaság nem húzza le az utast olyan településen, ahol nem rögzített árakkal dolgoznak.  

Amit kiemelnék, végülis a szabad versenyre közvetetten visszavezethető dolog, nevezetesen az, hogy presztizs kérdés, hogy egy adott taxitársaság taxijával utazva senki ne szenvedjen súlyos balesetet például. Összességében összehasonlíthatatlanul nagyobb a valószínűsége annak, hogy valaki balesetet, akár súlyos balesetet szenvedjen egy uberes kocsiban, mintha jól megválasztott taxival utazott volna.

Az, hogy még nem volt elegendő nyilvánosságra került eset, amikor az Uber-sofőr hibájából olyan baleset történt, aminél a sofőt és az utas is feldobta a gumicsizmát, még nem jelenti azt, hogy amit írok, csak hipotetikus megállapítás lenne.

Márpedig ha valaki kenőmájasként végzi egyszer mondjuk a rakparton a kocsival együtt, akkor lesz ideje filózgatni rajta az örök vadászmeződön azon, hogy taxi helyett Ubert választva megérte-e spórolni párszáz forintot – a biztonságon.

Ha valaki az Uber-jelenséget ahhoz hasonlítaná, amikor a 90-es években a nagy zenei kiadók lemezeit mellett gyorsan el kezdtek terjedni az otthon készített zenék is, ami a kiadóknak nem tetszett, érdemes fejben tartani azt, hogy egy kis zenekar felvétele legfeljebb szar, de nem jelent veszélyt senki testi épségére. A másik, ami mintha elkerülte volna az újságírók többségének a figyelmét, hogy az Uberhez hasonlóan aljas büdös bunkó görény cég alighanem nem sok hasonló méretű van, amelyik óvja magát a nyilvánosságtól, mint ördög a tömjéntől, ahogy ebből a cikkből részletekbe menően kiderül, nem lehet Uber sofőr az, aki újságíró, esetleg csak úgy.

Ha olyan telefonál, akinek a száma nincs elmentve a mobilunk telefonkönyvében, de nem tudjuk fogadni a hívást, a többség utólag megpróbálja visszaívni a számot, hogy megtudja, ki és miért is kereste. Viszont több, mindössze néhány másodpercet igénylő módszer is van rá, amivel megállapítható, hogy egy telefonszám kihez is tartozik.  

A számra rákeresni persze a netes tudakozókban a legkézenfekvőbb, egyrészt ha az előfizető kérte, hogy ne szerepeljen a telefonkönyvben, ez nem fog sikerrel járni, másrészt ha van is találat, figyelembe kell venni, hogy a feltöltőkártyás előfizetők közül sokan olyan SIM-et használnak, amit esetleg használtan vettek, a családban vásárolta valaki, akinek a nevén maradt a szám, ezen kívül ha céges mobilról van szó, csak egy cég neve jelenik meg a találatok közt, ami nem sokat mond. Ezen kívül számos országban a mobilszám név szerinti regisztrálása nem kötelező, mint például Magyarországon vagy Svájcban, hanem teljesen opcionális, csak kényelmi funkciók elérése miatt érdemes beállítani, mint például Ausztriában.  

Azaz ha a tudakozó nem dob eredményt, akkor ötletesebb módszerekkel érdemes próbálkozni. Ha kilépünk a Facebook-fiókunkból, majd kattintunk az elfelejtett jelszó opcióra, majd megadjuk a mobilszámot nemzetközi formátumban, nagyon sok esetben kidobja a felhasználót névvel együtt, aki az adott mobilszámhoz hozzákapcsolta a Facebook fiókját, természetesen ne kérjünk új jelszót és az érintett semmit sem fog észrevenni az egészből. Viszont miután megvan a név, visszaléphetünk a Facebookra és rákereshetünk név szerint és ismét telefonszám szerint is az illetőre. Az egység sugarú felhasználó számára ezt olvasva jó ötletnek tűnik a Facebookról leszedni a hozzákapcsolt mobilszámot, valójában ahogy korábban írtam, nagyon rossz ötlet. A megoldás nem a hívószám foggal-körömmel való eltitkolása, hiszen az úgysem működik, hanem az ésszerű hívásszűrés.  A jelszóemlékeztetőben a +1 650 416 6464 -es számra kerestem.

Abban az esetben, ha nem járt sikerrel a facebookos keresés, a számot ugyancsak nemzetközi formátumban kell elmenteni egy tetszőleges névvel a mobilunkba, majd ezt követően újraindítani a Vibert. A Vibert szinte mindenki használja, az alapértelmezett beállítás pedig az, hogy aki a telefonkönyvünkben szerepel, azt azonnal mutatja a Viber-kontaktok közt is, ami a mi szempontunkból fontos, hogy általában képpel együtt. Ugyanis amikor valaki elkezdi használni a Vibert, az alkalmazás rákérdez, hogy a felhasználó szeretne-e avatarképet feltenni magáról és azt is, hogy a képet a Facebook profilképéből importálja-e, amire a felhasználók többsége nyájasan igennel válaszol. Van egy apró arcképünk, na és? Ha az arc nem ismerős, nyilván lehet screenshotot készíteni róla, majd egy képszerkesztővel kivágni az apró avatarképet, majd bedobni a Google Képkeresőbe. Szinte biztos, hogy lesz érdemi találat, mivel nagyon sokan azonos avatarképet használnak különböző közösségi szolgáltatásokban, amikor közül több a böngészőmotorok számára kereshető, ahogyan az is gyakori, hogy valaki egy jól sikerült Instagram-fotóját használja több helyen avatarképként. Megjegyzem, értelmesebbnek tűnik a screenshotot a mobilon keresztül kinyerni, mivel ott a fotó nagyobbnak tűnik. Valóban nagyobb, viszont rosszabb felbontású. Ha az asztali klienst használva készítünk screenshotot, az avatarkép pici lesz ugyan, de teljes, a Google Képkereső mintázatfelismerőjét pedig nem a kép mérete, hanem tényleges felbontása érdekli, ha egy 30x30-es arcképre például egy 300x300-as kép illeszkedik, az ugyanúgy meglesz.  

A LINE szolgáltatással teljesen hasonló a helyzet, mi több, még jobb. Ha a telefonkönyvünkben fenn van egy szám, a LINE újraindítása után a kontaktok közt megjelenik a felhasználó, akihez a mobilszám tartozik. Sok hasonlóságot mutat a Viberrel, viszont itt sokszor a teljes név vagy Facebook nicknév, kapásból látszódik, amit a Facebookból importált az app, azt pedig a felhasználónak rendszerint eszébe sem jut átírni, miért is tenné. Már csak azért is, mert az alkalmazás tervezői is abból az alapfeltevésből indultak ki, hogy akik fenn vannak egymás címjegyzékébe, úgyis ismerik egymást. Amit jó tudni, hogy a LINE viszont jelez a másik félnek, ha a mobilszáma alapján hozzáadtad a saját kontaktjaidhoz, de a mobilszámod nem látja, ehelyett a nevet, ami bármi lehet, amit megadsz. A screenshotos trükk természetesen itt is megjátszható.  

Megjegyzem, mindkét alkalmazásnál sokáig alapértelmezés volt, hogy még az utolsó belépés idejét is mutatta, amiből lehet következtetni nem csak arra, hogy az illető a szolgáltatást használja-e, hanem arra is, hogy a szám milyen valószínűséggel tartozik hozzá még mindig: ha valaki mondjuk 3 éve lépett be utoljára, nem biztos, hogy már hozzá tartozik a szám. Ezen kívül a Viberre és a LINE-ra is igaz, hogy esetleg az avatarképet mobilon mutatja, asztali kliensen viszont nem, esetleg éppen fordítva. A jelenség magyarázata, hogy ha valakinek egyszer volt fenn képe, amikor felkerült a kontaktjaink közé, majd a szolgáltatást nem használta a felhasználó, ezt követően telepítettük a saját kliensprogramunkat, a mobil a gyorsítótárából az avatarképet előcibálja, az asztali kliens viszont nem. A Viberre, a LINE-ra és a Whatsapp-ra is igaz, hogy nem szűnik meg az account önmagában attól, hogy valaki nem használja, mert például törli az alkalmazást.  

Ha a Google Hangounts-ban és a Facebook Messengerben engedélyezett, hogy kereshetők legyünk mobilszám alapján [igen, ez az alapértelmezés], akkor ott a kontaktlistához hozzáadva az ismeretlen számot, az illető profilja fel is fog tűnni képestől-nevestől az instant üzenetküldőben, ugyan a Facebook Messengernél ezt nem próbáltam ki most, mivel nem csak, hogy nem használom, nincs is telepítve. A Google Hangouts esetén pedig egyszerűen ki kell szedni a pipát a megfelelő helyről. 

A mobilszámok fellelhetősége szinte határtalan, sokszor a Skype-keresőjébe megadva egy mobilszámot, ugyancsak megjelenik a hozzá tartozó felhasználó, esetleg a valódi nevével együtt, beállítástól függően, ugyan ott nem alapértelmezés, hogy a mobilszám alapján kereshető legyen a felhasználó.  

Évekkel ezelőtt a Google keresőjének a "phone:" operátora kiadta az összes webhelyet, ahol a keresett telefonszám előfordult, mára sajnos ebben a formában ez a lehetőség nem érhető el. Az operátort a Google alighanem néhány felhasználó ostoba, de annál hangosabb jajveszékelése miatt szüntették meg, jobban belegondolva viszont mi a jó égnek írta ki valaki a mobilszámát egy webhelyre, azaz teljesen nyilvános felületre, ha nem akarta, hogy kereshető legyen? Ja, hogy véletlenül? Na erre helyesen azt kellett volna válaszolnia a Google-nek, hogy "tetszettek volna használni a józan eszüket" és kész. Viszont ne felejtsük el, hogy léteznek más általános célú keresőmotorok is, amikben még elérhető kimondottan a telefonszámok keresésére élesített keresőoperátor, ezeknek a hatékonysága azért egyre kisebb, mivel sok esetben magára a Google Search Engine-re támaszkodnak.  

Ez viszont nem jelenti azt, hogy telefonszámokat ne lehetne keresni a Google-ben, lehet éppenséggel, csak jóval nehezebb. A keresésnél az egyik, amit figyelembe kell vennünk, az országonként eltérő telefonszámformátum, amit a Wikipedián is megtalálunk másrész ami ehhez egyes államoknál szorosan, más államoknál szinte sehogy sem kapcsolódik, hogy az adott területen milyen a telefonszámok írásmódja és ehhez mennyire tartják magukat az ottaniak. A helyzeten tovább bonyolít, hogy számos országban a telefonszámok hossza sem kötött. Első lépésben meg kell állapítani, hogy a hívás melyik országból érkezett, ami eléggé egyértelmű. Ezt követően nézzük meg, hogy az adott országban milyen telefonszámformátum vagy formátumok vannak és ezeknek mi a többé-kevésbé konvencionális "helyesírása".  Egyszerűnek tűnik? Gyakorlat kérdése.

Magyarországon az általános 11, azaz 2+2+7 számjegyű telefonszámok a szerződéseken és a SIM-kártya csomagolásán azért szerepelnek +36 aa bbb-cccc formátumban, mert a szolgáltatók a saját tartományukon (aa) belül  három számjegyű altartományokat (bbb) használnak, majd ha az (cccc) megtelt, akkor új altartományt nyitnak, és azt kezdik feltölteni. Ezen kívül amolyan hungarikum, hogy a telefonszámok körzetszám után álló része sosem kezdődik 1-es számjeggyel, holott technikailag pár éve már kezdődhetne. A telefonszámok leírásának formátuma is ehhez igazodik, de nem mindig, a körzetszámok sosem olvadnak egybe a hívószámmal, gyakran perjel választja el a hívószámtól, ami 3+4-es tagolású, de nyilván előfordulhat ettől eltérő, például 4+3-as tagolás is. Ez a magyarázat fejfájdító bonyolításnak tűnik ugyan, de nem az. A keresésnél a hívószámokat idézőjelbe kell tenni, hogy ne matematikai műveletként értelmezze a kereső, viszont míg a "70 270-1700" kifejezésre keresve biztosan az életrajzi oldalam az első találat, addig a "70/270 1700"-ra keresve vagy az vagy sem. Ha eddig nem lenne elég bonyolult a dolog, hozzáteszem, hogy a Google nyilván nem tudja, hogy amit keresnénk telefonszám, azt viszont figyelembe veszi, hogy a keresést honnan indítjuk, így az előző hívószámra keresve Magyaroszágról az életrajzi oldalam az első találat, Japánból keresve például már egyáltalán nem biztos, ezért a haladóknak erősen ajánlott, hogy az adott ország VPN-jén vagy webes proxyján keresztül kapcsolódjanak a netre.

 

Visszatérve a telefonszámok hagyomány szerinti írásmódjára, sokszor semmi köze az írásmódnak ahhoz, hogy a számokat a szolgáltatók milyen szisztéma szerint osztják. Így például az ilyen téren igencsak mazochista franciák a 0A BB BB BB BB formátumtól sosem térnek el, hiába nehezebb megjegyezni kettesével a teljes számot, azonban akik nem tősgyökeres franciák, nagyobb valószínűséggel írják értelmesebb módon.

Míg a magyar példa ellentéte, hogy az USA-ban a +1 aaa bbb-cccc formátumtól gyakorlatilag sosem térnek el és tükrözi a szolgáltatók számkiosztásának logikáját, ahol az aaa jelzi a körzetszámot, amiről ugyan nem lehet megállapítani, hogy landline, azaz vonalas, adott államhoz kötött szám vagy olyan mobilszolgáltató száma, amit az előfizető az adott államban vásárolt. A bbb-cccc kiosztást pedig nem lenne érdemes megbolygatni, mivel a kognitív pszichológusok szerint éppen hét jel az, ami még kényelmesen fejben tartható.
 
Most pedig képzeljük el, hogy például a Google keresője már sok-sok évvel ezelőtt az ilyen szabályokat megtanulta évekkel ezelőtt az összes országra vonatkozóan, mivel szinte sosem tévedett a phone: keresőoperátor, amíg nyugdíjba nem küldték!  

A számok keresése sokszor hatékonyabb olyan keresőkkel, mint a nagy keresőmotorok találatait összesítő vagy éppenséggel a keresési előzményektől független módon listázó Dogpile vagy éppen a Duckduckgo,  de hasznosak lehetnek az olyan webkettes matuzsálemek is, mint a MyVIP vagy a HI5, amire nagyon sokan felregisztráltak valamikor, aztán el is felejtették, de fenn lehetnek még olyan adataik, amik még aktuálisak.

Még egy gondolat erejéig visszatérve a telefonszámok írásmódja szerinti keresésre, ha nagyon nem boldogulunk, magyar hívószám keresése esetén szóba jöhet az idézőjelek elhagyása mellett a "mobil", "tel" vagy "telefon" kifejezés hozzáadása. Viszont más nyelvek esetén némi nyelvismeretet igényel, hogy a telefonszámokat hogyan hivatkozzák az adott nyelvben. A németek nem sűrűn írják le, hogy "Rufnummer", annál gyakrabban, hogy "RN", míg az angol nyelvterületek némelyikén úgy hivatkozzák, hogy "handy". Ha ilyen megjelölésekről szeretnénk tájékozódni, a SZTAKI Szótára összehasonlíthatatlanul hatékonyabb, mint például a Google Translate vagy a Yandex Translate, amiről sokan nem tudják, de a szókincsét gyakorlatilag csak gépi tanulással bővíti, egészen kivételes esetekben nyúlnak bele kézileg, míg a hazai Origo-SZTAKI Szótár lektorált szótár.

Ami még fontos, hogy sose használjunk olyan szolgáltatást, ami pénzért kínálja az előfizetői adatokat. Ha valaki ilyen helyen rákeres a saját számára, könnyen belefuthat, hogy a szolgáltatás azt mondja ugyan, hogy mindent tud az előfizetőről, csak fizetés ellenében adja meg, holott a számot esetleg sehol sem adta meg a tulajdonosa, mert aznap vette feltöltőkártyás SIM-mel.

Kis színesként meg kell jegyeznem, hogy mi a legbűbájosabb kérdés, amit kapok néha: "Honnan tudod a számom?" xD

Két praktikus dolgot viszont nagyon érdemes megjegyezni: senki sem vonhat felelősségre azért, ha előtúrtad a számát, hiszen ő maga adta meg. Másrészt friss ismeretségnél nem érdemes azzal menőzni, hogy nagy valószínűséggel meg tudod állapítani valakinek a számát oda-vissza, mivel nagyon sokan alapvetően ostobák ilyen téren és valamiféle kukkolónak fognak gondolni.

Hogy a telefonszám görcsös titkolgatása olyan korban, amikor finomhangolható a bejövő hívások és SMS-ek szűrése, miért teljesen elhibázott és hogyan alakítható ki helyes policy ezzel kapcsolatban, számos pszichológiai vonatkozással is bír, amibe most nem megyek bele.

Ugyan ha eddig valakinek kimaradt volna, bárki megtudhatta másvalaki földrajzi helyét is csupán a skype-azonosító ismeretében.

Mindenek előtt látogassunk el a http://www.skresolver.com/ vagy épp más skype resolver oldalra. A felhasználói név mezőbe írjuk be a saját skype-azonosítónkat, majd kattintsunk a Grab IP address now! gombra. Szinte biztos, hogy megjelenik az az IP-cím, amivel a gépünk vagy a mobilunk a Skype-ra kapcsolódik, mi több, még azt is megmutatja, hogy az alkalmazás melyik hálózati porton figyel, tartja a kapcsolatot a külvilággal és jelzi az alkalmazás felé, ha bejövő hívás vagy üzenet érkezik. A lekérdezés ugyan nem minden esetben dob eredményt, de ennek inkább az az oka, hogy az ilyen szolgáltatások korlátozzák, hogy mennyi felhasználói név kérdezhető le. Ha a sajátunkra nem kapunk találatot, próbálkozzunk bátran más nevével, esetleg más resolverrel. Azt, hogy egy-egy IP-cím földrajzilag körülbelül hol helyezkedik el, a weben a https://www.iplocation.net/ oldalon kérdezhetjük le, ami több,  nagy pontosságú geoIP-adatbázis eredményét adja vissza.

Az IP-cím többek közt azért számít meglehetősen kényes információnak, mert ha valaki egy végponti eszközt, azaz közvetlenül az áldozat gépét szeretné hekkelni, első lépésként tudnia kell annak IP-címét. Az, hogy a Skype még a portszámot is kikotyogja, azért problémás, mert ha esetleg a Skype túl régen lett frissítve, egy korábban dokumentált sebezhetőséget kihasználva az alkalmazáson keresztül legrosszabb esetben hozzáférhet a gép vagy mobileszköz más adataihoz is. Aki jobban képben volt, azoktól elnézést kérek az egyszerűsítésekért.

Tehát a Skypenak szüksége van arra, hogy folyamatosan figyeljen, majd ha bejövő hívás érkezik, akkor a két felet közvetlenül, point-to-point módon kapcsolja össze, a forgalom lényegi része nem megy keresztül még egy világ túloldalán lévő szerveren, nyilván azért, hogy a hangminőség jobb legyen, a szolgáltatás erőforrásigénye ne legyen túl nagy. A skype alapértelmezett beállítása viszont az, hogy nem csak azokkal tud minket összekapcsolni, akik fent vannak a kontaktlistánkon, hanem abszolút bárkivel, azaz ha írunk egy pici programocskát, ami megszólít egy adott skype-felhasználói névvel rendelkező felhasználót vagy éppenséggel ezt a lekérdezést egy skype resolver szolgáltatásra bízzuk, az IP lekérdezhető.

A Skype asztali változatokra szánt kliensprogramjában nem alapértelmezés ugyan, viszont bekapcsolható, hogy csak a kontaktoknak legyen engedélyezett a közvetlen kapcsolódás, ekkor az IP-cím nyilván nem kérdezhető le csak úgy. Ami viszont nagyon fontos, hogy ezt hiába állítja be valaki, alighanem a mobiljára is telepítve van a Skype, ahol viszont egész mostanáig nem volt ilyen beállítási lehetőség. Márpedig a Skype folyamatosan lóg a hálón mobil esetén és egy-egy ilyen IP-cím megállapításnál vagy a mobilszolgáltató által leosztott IP-cím jön vissza, ami ugyan relatív gyakran változik, ha valaki otthon van – tipikusan hétköznap késő este - a mobilja pedig wifin keresztül kapcsolódik, a skype resolver az otthoni IP-címet köpi ki, ami sok esetben akár több hónapig is ugyanaz lehet!

A problémát súlyosbítja mobileszköz esetén, ha valaki valamilyen romhalmaz Androidot használ vagy az almás mobilja annyira régi, hogy az elvárhatóan biztonságos, legújabb iOS-t már nem tudja telepíteni rá.

A Skype mostanra változtatott, hogy Windows Phone-on és az Androidon mi a helyzet, nem tudom, viszont az iOS-en a haladó beállítások alatt a legfrissebb verzióban már letiltható a közvetlen kapcsolódás olyan irányból, aki nem közvetlen kontaktunk. Akinek újabb almás mobilja van, éljen a beállítási lehetőséggel, asztali gépen pedig mindenképp érdemes beállítani.

Hölgyeim! Ha a párotok lelép Tokióba üzleti útra egy hétre, a leírt módszerrel egyszerűen megnézhetitek, hogy nem Monte Carloban kurvázik-e véletlenül – kivéve persze, ha olvasta ezt a posztot, aztán átállította a mobilján a kapcsolódás módját.  

Ahogyan azt pici logikával kitalálhattátok, természetesen a többi  üzenetküldő program esetén is vagy így, vagy úgy, de gyakorlatilag mindig kinyerhető az IP-cím olyan módon, hogy az nem igényel felhasználói beavatkozást, azaz például az illetőnek nem kell kattintania valamire.

Üzenet a gépházból: mostantól minden héten lesz legalább egy poszt ami a nyílt forrású információszerzés egy-egy technikáját mutatja be. Néha apró praktikákat ejtek el, néha komolyabb technikákat mutatok be.

 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 

Még mielőtt rátérnék a kezdő email forensicsre, egy kis netkultúra egyenesen a Népszínház utcából, hogy hangulatba hozzak mindenkit: avagy mémriadó és változatok egy témára - csakis a legjobbak!

Poposan!  

Rockosan!

Star warsosan!

Skrillexesen!

Metálosan!

Ace venturás