bardóczi ákos @post.r

 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:  
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  
        (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 ) 
    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  
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 " 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