About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (37),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),biztonság (8),mobil (8),OSINT (6),jog (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),Google (5),molbiol (5),felzárkóztató (5),webcserkészet (5),szájbarágó (5),plágium (4),Nobel-díj (4),kriminalisztika (4),terrorizmus (4),kultúra (4),big data (4),email (4),genetika (3),pszichológia (3),molekuláris biológia (3),biztonságpolitika (3),CRISPR (3),Android (3),online marketing (3),sajtó (3),élettudomány (3),gépi tanulás (3),Onedrive (3),üzenetküldés (3),jelszó (3),2015 (3),orvosi-fiziológiai (3),Apple (3),Gmail (3),reklám (3),konferencia (3),webkettő (3),biztonságtudatosság (3),kriptográfia (3),levelezés (3),magatartástudomány (3),azelsosprint (3),popszakma (3),hype (3),open source intelligence (3),torrent (3),nyelvtechnológia (3),bejutas (2),tweak (2),villámokosság (2),cas9 (2),Yoshinori Ohsumi (2),Hacktivity (2),génterápia (2),fiziológia (2),természetes nyelvfeldolgozás (2),Reblog Sprint (2),bűnügy (2),Pécs (2),nyílt forrású információszerzés (2),webkamera (2),deep web (2),P2P (2),Netacademia (2),arcfelismerés (2),DDoS (2),Balabit (2),bűnüldözés (2),TOR (2),kulturális evolúció (2),ransomware (2),hitelesítés (2),SPF (2),Whatsapp (2),neuropszichológia (2),szabad információáramlás (2),FUD (2),DKIM (2),2-FA (2),bolyai-díj 2015 (2),molekuláris genetika (2),jövő (2),sudo (2),IDC (2),cyberbullying (2),social engineering (2),malware (2),tartalomszolgáltatás (2),meetup (2),facebook (2),reblog (2),videó (2),titkosítás (2),kutatás (2),epic fail (2),pedofília (2),netkultúra (2),nyelvtudomány (2),vírus (2),hírszerzés (2),iOS (2),farmakológia (2),szociálpszichológia (2),tanulás (2),biológia (2),gépház (2),bulvár (2),bug (2),Tinder (2),öröklődő betegség (2),Yandex (2),könyv (2),beszélgetés rögzítése (2),pszeudo-poszt (2),Twitter (2)

Nyelvtechnológiával az adathalászat ellen


OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológiaAmikor 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.

OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológiaEgyszerű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.  

OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológiaA 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. 

OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológia

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:

OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológia

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.

OpenDNS NLP természetes nyelvfeldolgozás mintázatillesztés adathalászat email scam nyelvtudomány nyelvtechnológiaA 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

0 Tovább

Honnan tudható, hogy a címzett olvasta-e az emailed? 


email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAmikor 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. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAhogy í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. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésSok-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. 

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: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

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: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

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: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

AOL-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Zimbra rendszerben: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Horde-n: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Hushmailen: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Roundcube-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Squirrelmailnél: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

0 Tovább

A Gmail megmondja, hogy hiteles-e a levél. Tényleg?  


Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó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.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó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:

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

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.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

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.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

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.

0 Tovább

Meghamisított email - amit mindenkinek illene tudnia


 email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésAhogy 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. 

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés


 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.  
 
email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésA 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  
 
email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítésFelmerü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:  
 

email hamisítás ITsec spam scam levélszemét szájbarágó DKIM SPF DomainKeys hitelesítés

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 

0 Tovább

Nemzetközi piacra léphetne a freemail.hu?


Még nem tudni, hogy milyen újdonságok várhatóak a megújuló freemail.hu-tól, viszont elvben elképzelhető lenne az is, hogy világszerte használt óriás levelezőrendszerek versenytársa legyen. Ehhez persze szükség lenne angol nyelvű változatra, ezen kívül olyan feature-ökre, amiket más, mezei levelezőrendszerben nem talál meg a felhasználó.

Összegyűjtöttem néhány ötletet, közben pedig négy szempontot tartottam előtérben, mégpedig az egyszerűséget, a felhasználói élményt, máshol nem látott, haladó funkciók elérhetővé tételét és azt, hogy mindezt viszonylag egyszerűen le is lehessen programozni. Ezen kívül feltételeztem, hogy a felhasználók legalább egy nagyobb közösségi szolgáltatásban már regisztráltak. Az ötletek egy része az agyamból pattantak ki vagy egy enterprise level levelezőrendszerben, esetleg közösségi szolgáltatásban találkoztam velük, míg néhányat más levelezőrendszerekből loptam át. A feature-öknek önkényesen még egy-egy fantázianevet is adtam néhol, persze minden extra funkció opcionális lenne.

A felhasználói élményt és kényelmet fokozó lehetőségeket soroltam előre, míg az inkább technikai vagy haladó felhasználók számára érdekeseket a végére.

A felhasználók időnként hiányolják azt, hogy egy levél nem vonható vissza, amit egyszer elküldtünk, az kézbesítődik is, ha tud, viszont egyre több levelezőrendszernél bekapcsolható olyan lehetőség, ami azt a benyomást kelti, hogy a levelet vissza lehet vonni. Ilyen esetben nem valódi visszavonásról van szó, hiszen az eleve lehetetlen, hanem arról, hogy a levél bekerül egy várakozási sorba, majd ha a felhasználó nem gondolja meg magát, akkor történik meg a levél tényleges kiküldése. A funkció beépíthető lenne olyan módon, hogy a felhasználó beállítja, hogy a levél percben mennyi ideig tanyázzon a Kimenő mappában, ha addig nem gondolja meg magát, a levelezőrendszer már küldi is.

Gondolom sokakkal előfordult már, hogy vasárnap hajnalban, sakálrészegen álltak neki SMS-t vagy email írni, amit azt alaposan megbántak. Korábban erre a problémára kínált megoldást a Google Labsból a Gmail-hez elérhető kiegészítő Mail Goggles néven. Lényeg, hogy a Freemail [Másnap] funkció bekapcsolásával előre beállított nehézségű, de alapvetően fejben elvégezhető matematikai feladatok közül kellene ötöt megoldani egy perc alatt, a megfogalmazott levelet pedig a rendszer csak akkor engedné elküldeni, ha ezt az akadályt sikerrel vitte a felhasználó. Beállítható lenne egy időintervallum, amikor ennek mindenképp működnie kell, azaz hétvégén estétől hajnalig. A funkció lényege, hogy ha a józanul seperc alatt megoldható feladatokat nem sikerül megoldani részegen, akkor az a felhasználók többsége számára egy nyomatékos figyelmeztetés önmaguk felé, hogy akkor nagyon nem lenne érdemes üzenetet küldeniük.

Ma már minden valamire való szolgáltatástól elvárható, hogy legalább a legnagyobb social media felületekkel összedrótozhatóak legyenek. Ennek megfelelően ha a felhasználó a Freemail [Szülinap] funkciónak megengedné, hogy hozzáférjen a facebookos/Google plusos ismerőseihez, így az ő születési dátumukhoz, és beállítana egy előre megadott sablont, a Freemail [Szülinap] az ismerős email-címére automatikusan születésnapi köszöntő üzenetet tudna küldeni – még akkor is, ha mi simán elfelejtenénk. Persze érdemes lenne elvégezni azt a finomhangolást, hogy az összes ismerős kaphasson automatizált köszöntőt vagy csak az ismerősök egy bizonyos köre.

Ismerve, hogy a felhasználók átlagosan mennyi időt töltenek más közösségi szolgáltatásokban, ha már az összekapcsolás megtörtént, hasonlóan ahhoz, ahogy beállítható a Skype-kliensünkben, hogy ott is megjelenjen az, ami a Facebook-falunkon, a Freemail [Social]-lel megoldható lenne, hogy az oldalsávban a facebookos, twitteres, linkedines falunk tartalma pörögjön vagy éppenséggel egy RSS-feed.

Gyakori jelenség, hogy egy levelet félrecímeznek, nem véletlenül van minden levelezőrendszerben automatikus kitöltés a címzett mezőhöz. Viszont ha a levelezőrendszer még látja is a különböző szolgáltatásokban lévő kontaktjainkat, az első címzés után felajánlaná, hogy egy arcot kapcsoljunk az automatikusan mentődő címhez. A további levélküldést pedig többféleképp tenné egyszerűbbé.

A félreküldést küszöbölné ki és a címzést tenné kényelmesebbé, ha egy gyorskeresővel ellátott oldalpanelben az apró avatarképpel és névvel látszó ismerős nevére kattintva a levelezőrendszer autofillezné a címzett mezőt, ha korábban a levelezőpartnernek küldtünk levelet – a lényeg a képen van! Itt megjegyzem, hogy nem a Gmail sajátossága, hogy betölti a feladó fotóját is, ha tudja, a Gravatar [Globally Recognized Avatars] szolgáltatásban szinte már mindenkinek a fotója fenn van – legfeljebb nem tud róla – ennek megfelelően pl. a Fastmail és a Yandex Mail is megjeleníti webes felületen a feladó képét, ha az elérhető az email címe alapján. Ha pedig ilyen módon az avatar betöltése nem lehetséges, a rendszer lepecázhatná a képet egy olyan közösségi szolgáltatásból, amivel már összekapcsolta a felhasználó, illetve ha valakinek a profilja kívülről is látható, még erre sem lenne szükség a kép megjelenítéséhez.

Egy Freemail [Időzítő] lehetőséget bekapcsolva megoldható lenne, hogy egy előre megírt levelet a Freemail adott időpontban küldjön ki, ez ha nappalra van beállítva, egy fontos címzett mobilja akkor sem vinnyogna, ha a levelet az éjszaka közepén írtuk meg neki, de fontos, hogy mielőtt megkapja, azaz például reggel, amikor már esetleg nem vagyunk gép előtt.

Szintén hasznos kényelmi szolgáltatás lenne, ha egy oldalpanelből egy levelezőpartner nevére kattintva egyszerre lenne megjeleníthető az összes tőle érkezett és neki küldött levél.

A fontos, megválaszolandó levelek csillagozása hasznos dolog, viszont ha közben érkezik egy rakás levél és a megcsillagozott nincs a felhasználó szeme előtt, nagyobb valószínűséggel fogja elfelejteni. Így beállítható lehetne, hogy a felső vagy az alsó sávban a rendszer jelezze, hogy mennyi fontos levél várakozik még és azok egy kattintással a figyelmeztetősávból elérhetőek lennének.

Több levelezőrendszerben már rég alapszolgáltatás, hogy ha a levél szövegében előfordul például az a szó, hogy „CV”, „életrajz”, „csatolt” vagy bármi, aminél valószínűbb, hogy valamit valóban csatolni terveztünk a levélhez, de mégsem tettük, a levelezőrendszer a küldés gombra kattintás után rákérdez, hogy nem felejtettünk-e el mellékletet csatolni a levélhez esetleg.

A Freemail [Metatag] a kimenő, bejövő levelek feladóinak nevéből, a tárgyban előforduló szavakból, benne előforduló linkekből és különböző tartalmi elemekből generálhatna egy halmazt, aztán pedig a metacímkéket oldalpanelen megnyitva gyakoriságuk sorrendjében mutatná azokat, valamint ugyanitt kereshetőek is lennének. Így például előkukázható lenne az összes olyan levél, ami esetleg teljesen különböző feladótól jött teljesen különböző okból, de szerepel benne például a „pályázat” kifejezés.

Ha már metáknál tartunk, a Freemail [Sherlock] az előző elven működne lényegében, de nem a gyakori, releváns, hanem épphogy a legritkább kifejezéseket, szokatlan szófordulatokat gyűjtené össze. Így például be lehetne saccolni, hogy nem azonos-e esetleg a feladója két, különböző címről és névvel küldött levélnek, még akkor is, ha a levelek több éves időbeli különbséggel érkeznek.

Ha már úgyis bölcsészkedésnél tartunk, a leveleket opcionálisan fel lehetne dobni a Freemail [Coelho] bekapcsolásával, ami az aláírás elé vagy után tenne valamilyen rémes közhelyet Freemail [Coelho] aláírással. Ugyanezen az elven lehetne egy beépített mémgenerátor is, ahol a felhasználó kiválaszthatná egy jól ismert mém képét, amire a Freemail [Coelho] automatikusan rátenne egy feliratot a levél tárgya alapján, amit persze a felhasználó szerkeszthetne, majd pillanatok alatt hasonlóan az aláíráshoz illeszthetne.

Egy levelet PDF-be exportálni nem egy nagy bravúr, viszont teljesen más a helyzet, ha ez a lehetőség egyetlen klikkel elérhető. A Freemail [PDF] bekapcsolása után egyetlen kattintással a levelezőrendszer elkészíthetné a levél PDF másolatát és már kérdezné is, hogy hova mentse le. Ennek lenne egy másodlagos funkciója is: nagyon sok helyen a HTML formátumú levelekben lévő képek nem töltődnek be automatikusan adatvédelmi okból, hiszen ilyenkor a levél feladója láthatja, hogy a címzett a levelet elolvasta és azt is, hogy honnan, milyen operációs rendszerrel, milyen böngészővel, hiszen a kép végülis egy külső webszerverről töltődik be, ami ugye naplózza a letöltéseket, így a képek letöltését is. Ebben az esetben viszont a Freemail egyik IP-címét tudná csak naplózni, hiszen az tölti le önmagának és nyomtatja ki PDF-ben a levelet képekkel együtt.

Az automatikus mentés elemi minden olyan felületen, ahol szöveget írunk. Viszont előfordulhat, hogy egy átfogalmazott szöveg sokkal rosszabb, mint az eredeti és egy 10 perccel korábbi változatát szeretnénk előszedni. Ha a levelet a rendszer percenként mentené, akkor egy 25 percen keresztül fogalmazott levél esetén, percenkénti mentéssel persze 25 példány lenne a piszkozatok közt, ami persze eltűnik, amint a levelet elküldtük, addig viszont egy tetszőleges, korábbi változat előkukázható, ami sokkal egyszerűbb, mint a visszavonás gombbal játszani, hiszen lehet, hogy olyan szövegrészt is eltüntetünk vele, amit viszont szeretnénk meghagyni. A Freemail [Croquis] megoldaná.

Előfordulhat, hogy nem vagyunk otthon, egy publikus gépet használunk, valamilyen kisebb vagy éppen óriási fájlt le szeretnénk tölteni magunknak későbbre, viszont nincs nálunk pendrive sem, sem más egyéb, ráadásul még a netkapcsolat is siralmasan lassú, esetleg a tartalmat helyben le sem lehetne tölteni. Ekkor a Freemail [Crawl] használatával a Freemail a megjelölt URL-ről letöltené saját magának a tartalmat, amit ésszerű ideig tárolna, otthon le lehetne tölteni, majd küldene a levelező egy figyelmeztetést, hogy a félretett fájl meddig tölthető le, hasonlóan az ún. óriáslevelekhez, ahol a csatolt fájl szintén nem magában az emailben van, hanem fel van töltve a levelezőszolgáltatás tárhelyére.

Ha már tárhely, igaz, hogy ez nagyban függ attól, hogy az adatok tárolása hogyan van megoldva, szolgáltatói részről lehet, hogy praktikusabb lenne, ha a felhasználók nem kapásból 10 GB-t kapnának, hanem a regisztrációkor mondjuk 500 MB-t, ami aztán a felhasználói használati szokásaihoz alkalmazkodva – például a levelezőben töltött idő, a regisztráció óta eltelt idő és a forgalom függvényében - növekedne, ahogy ez működött régen a Yahoo levelezőjénél is.  

Hasonlóan egyrészt a felhasználót és a szolgáltató erőforrásait is védené, ha beállítható lenne, hogy a különböző mappák mennyi ideig tárolják a leveleket, a megadott idő lejárta után pedig törlődjenek, kerüljenek a kukába vagy kerüljenek át tömörített archívba, amit a belső keresőnek már nem kellene indexelnie.

Az előző megoldás mellett vagy helyett bevezethető lenne az a funkciói is, ami disaster prooffá teszi a levelezést, hasonlóan a nagyvállalati megoldásokhoz, csak éppenséggel fapados kivitelben: ha például a alicebobandeve@freemail.hu cím regisztrációjakor létrejönne egy alicebobandeve-bak@freemail.hu fiók is, aztán abba minden kimenő és bejövő levelünkből érkezne egy-egy példány, a néhány napnál régebbi leveleket pedig a rendszer alaposan betömörítené. Ekkor, ha valaki véletlenül törli az összes levelét mondjuk egy elszart  POP3-letöltéssel, az egész előkukázható lenne a másik fiókba való belépés után és nem kellene a szolgáltatónál könyörögni a mentésért, ezen kívül ha valaki más felhasználó fiókjába belépve a nevében küldene levelet, annak egy ilyen backup fiókban ugyancsak nyoma maradna, hiába törölné a támadó a levelet a kimenő levelek közül.

Tudjuk, hogy nagyon gyakori, hogy valaki egész egyszerűen úgy hagyja a gépét használat után mondjuk nyilvános helyen vagy iskolában, így utána bárki odaülhet, aztán úgy trollkodhat a másik fiókjában, ahogy csak akar. Ezt a kockázatot többféleképp lehetne csökkenteni. Ha mondjuk a felhasználó be akarna keményíteni, akkor beállíthatná, hogy egy-egy levél megnyitásához, új levél küldéséhez vagy a beállítások átállításához ismét be kelljen írni a jelszót valahány perc inaktivitás után. Inaktivitás alatt itt azt értem, amikor a felhasználó nem navigál el másik felületre mondjuk 1 percig.

A belépéskor opcionálisan lehetne kétlépcsős azonosítás, amiről itt a blogon már többször írtam, illetve a Yandex megoldásához hasonlóan mondjuk Freemail [Kulcs] mobilapp, ami az alkalmazás előre beállított PIN-kódjának megadása után kiköp egy olyan karaktersorozatot a felhasználó okosmobilján, ami érvényes belépési jelszó 1 percig. A hagyományos jelszólopással kapcsolatos kockázatot egy csapásra kiküszöbölné.  Az más kérdés, hogy ha valakinek a fiókjába nagyon be akarna lépni valaki, akkor ellopná az okosmobilját, miután leleste a Freemail [Kulcs] mobilalkalmazás PIN-jét...

Hasonlóan, a felhasználó a Freemail [Kulcs] vagy adott számra küldött SMS segítségével azonnal le tudná zárni a felhasználó a fiókját /*kényszerített átmeneti jelszó + minden aktív session lezárása*/, amint tudomást szerzett róla, hogy valaki belépett a fiókjába, majd az otthoni gépén fel tudná oldani a blokkolást.

A levelezőrendszerek körében szintén eléggé eredeti lenne, ha kiiktatható lenne a jelszóemlékeztető kérdés lehetősége [igaz, ezt most sem kötelező megadni], ami ugye nagyobb kockázatot jelent, mint amennyire a biztonságot fokozza, le lehetne tiltani, hogy másodlagos email-címre jelszóhelyreállítot küldjön a rendszer. Viszont meg lehetne adni 3-5 ismerős email címét, akik kapnának egy-egy rövid karakterláncot, majd ezeket külön-külön megkapná a fiók tulajdonosa, összeillesztené és csak úgy tudna új jelszót beállítani, ha már kicsukta magát. Na, ezt az ötletet a Facebooktól csentem.

A kényelmet nagyban fokozó szolgáltatás lenne, ha a Freemail [IMAP]-pal meg lehetne adni más postafiókunk IMAP4-elérését. Az ilyen módon bedrótozott külső postafiók egy új mappaként jelenne meg a Freemailben, de nem töltené le az összes levelet a másik helyről fölöslegesen, hanem hasonlóan a jól nevelt levelezőprogramokhoz csak a levelek fejlécét. Aztán az töltődne át ténylegesen, amit a felhasználó meg is nyit. Ezen kívül a Freemail-ből a külső fiókba lehetne átmásolni leveleket az IMAP-os mappába másoláson keresztül. A Freemail ilyen módon levelezőkliensként is működne, viszont nem zabálná a tárhelyet.

A Freemail [fancy] bekapcsolásával a Freemail magától generálna egy ékes-grafikus aláírást, ami a social webes elérhetőségeinket is tartalmazza, ha engedélyeztük azt. Hasonló elven, amikor levelet kapunk valakitől, a rendszer előkukázná az illető LinkedIN-profilját név vagy email-cím alapján és mutatná is az oldallécben, ahogy erre a Microsoft Exchnage-ben és a Google Appsben egyaránt van lehetőség egy kiegészítővel.

Persze, persze, az emailjeink aláírása lazán átszerkeszthető a beállításoknál, viszont ha bekapcsolható lenne a Freemail [szignó]-n keresztül több aláírás, a levél megírása után, alul, legördülő menüből választhatnánk ki, hogy az adott levél aljára melyik kerüljön, esetleg ne is legyen aláírás.

Az Out of Office jó ötletnek tűnt, amikor kitalálták, viszont ha valaki elmegy nyaralni, aztán minden, levelezőlistán keresztül neki is kézbesítődő levélre automatikusan küld Out of Office választ, az már zavaró lehet. Ha pedig spammernek, akkor kínos, mert a spammer biztos lesz benne, hogy élő postafiókot talált be. Kifinomultabban a Freemail [OOO]-val be lehetne állítani, hogy csak bizonyos, például címjegyzékben lévő, nem levlistás címzettek felé küldjön automatikus választ a távollétről.

A Thunderbird Display Mail User Agent addonjához hasonlóan a Freemail [Spy] egy kis ikonnal jelezné, hogy a feladó milyen levelezőrendszerből küldte a levelet, aminek még nem lenne önmagában túl sok értelme, ugyan innen gyanítható lenne, ha a feladó címét meghamisították, ha például egy Yahoo-s logo virít egy bme.hu-s cím mellett. Ha ez kiegészülne olyan funkcióval, ami azt is mutatja, hogy a levelet földrajzilag honnan küldték, na, az aztán igazán főnök lenne. A https://www.iplocation.net/ -ról elérhető adatbázisok valamelyikét lehetne alapul venni, aztán pedig adatforrásként a levelezőrendszernek csak ki kellene olvasnia a hosszú fejléc sorai közül a küldői IP-címet tartalmazó X-Originating-IP értéket vagy ha ilyen nincs, akkor a megfelelő Received: sort, ahol, ha máshogy nem, a hostname reverse alapján adódó IP-címhez tartozó országot alapul vennie – persze a helymeghatározás hibás lesz, ha az így következtetett ország időzónája és az az időzóna, amit ugyanúgy tartalmaz a hosszú fejléc, nem egyezik. Az esetek többségében viszont mutatná, hogy melyik városból jött a posta. Az esetek döntő többségében működne. Nos, mivel a szolgáltatás olyan adatokkal dolgozik, amit eleve megkapott a hosszú fejlécben, ezért annyira azért nem lenne emberiség ellenes dolog kiírni a valószínűsített várost vagy országot.

a freemail - igencsak rég

Réges régen, talán igaz sem volt, a két nagy levelezőóriásnál be lehetett állítani, hogy a postafiókunkat a saját domain-nevünkkel használhassuk, aztán először a Google jelentette be, hogy a Google Apps free változatát nem támogatják tovább nem sokkal később pedig a Microsoft tett ugyanígy.

Mondjuk freemium változatban a saját domain beállítható például a mail.ru-n – feltéve, hogy valaki eléggé jól tud oroszul – vagy az Oroszországból érzékeny dolgokat kitelepített Yandexen, ha pedig valaki echte ámerikai megoldáshoz ragaszkodik, a Zoho Mail 10 felhasználóig ingyenes saját domain névvel. Nos, elvben a Freemail eléggé nagyot dobbanthatna, ha lehetne saját domaint beállítani a levelezéshez, de például olyan módon, hogy a full ingyenes változatban ott virít a Freemailt promózó sor a saját domaines címekről küldött levelek végén, míg néhány garas befizetése után már nem.

Egy közösségibb dolog lenne az opcionális Reblog oldaldoboz, ahova a felhasználó néhány klikkel tudná hajigálni a hírlevelekben érkező, érdekes híreket vagy linkeket egy-egy mikroblogposztba.

Mind küldtünk már levelet olyannak, akiről tudtuk, hogy a postafiókjába csak az nem lát be, aki nem is akar, de a dolog elkerülhetetlen volt. Erre frappáns megoldás lenne az önmegsemmisítő levél, ami végülis egy Freemail-tárhelyen tárolt levél lenne, a címzett pedig csak egy linket kapna, amire kattintva a levelet el tudja érni. Be lehetne állítani, hogy a levél az elküldéstől számítva, valamint a megnyitástól számítva mennyi ideig lehet olvasható, így talán még a legkreténebb, nulla biztonságtudatossággal és a teljes céges adatvagyonnal rendelkező CEO-t is sikerülne megvédeni önmagától :)

A biztonságot ugyan nem, de geek-faktort fokozná egy Freemail [Wordcloud], amelyik az adott szövegben lévő szavak gyakorisága alapján az aljára legenerálná a levélre jellemző szófelhőt, aztán jót röhögni rajta. Ha még nem játszottál ilyennel, erre tessék szórakozni erre vagy éppen erre.

Volt már róla szó, hogy a teljes iparág mennyire rápörgött az emailek titkosítására, aztán megjelent egy rakás levelezőszolgáltató, amelyik webes felületen keresztül nyújtott PGP-szolgáltatást, magyarul újra feltalálták a kereket. Hogy mást ne mondjak, a szanaszét hype-olt Protonmail 14 évvel (!!) később újra feltalálta a Hushmailt.

Viszont aki levelezéshez használt Horde rendszert, tudja, hogy ott is van lehetőség PGP-kulcspárt importálni, aztán úgy titkosított leveleket küldözgetni, az más kérdés, hogy ha a privát kulcs nem csak a végponton van meg, az pont a PGP koncepcionális lényegének lábbal tiprása.

Ugyanakkor ha minden, így a levelezés is a weben van, igény van rá, abban pedig bízzunk, hogy a kulcsot a szerver tényleg eléggé ellophatatlan módon tárolja. A Freemailbe simán be lehetne építeni olyan funkciót, ami lehetővé teszi a PGP-kompatibilis titkosítás és digitális aláírást – legalább megismerik többen, hogy mi a jóég az a PGP – és lenne rá lehetőség, hogy a felhasználó a privát kulcsát törölje a Freemail szerveréről és a saját gépén tartsa, amit együtt tudna használni bármilyen levelezőklienssel. Illetve ha weben használná a PGP-t, a Freemail levele letöltődne kliensoldalra, a felhasználó titkosítaná vagy aláírná a böngészőben a privát kulcs betöltése mellett, majd a kliensoldal visszaküldené szerveroldalra és úgy küldené a levelet.

Lehet, hogy amit leírtam, azok közül többminden olyan dolognak tűnik, ami túl kevés felhasználót érdekelne ahhoz, hogy érdemes legyen leprogramozni, viszont ami biztos, hogy felfigyelnének a sokat látott Freemailre, másrészt nemzetközi színtéren a felhasználók „kis része” nem is jelentene annyira kevés felhasználót. Ekkor persze alaposan megváltozna az üzleti modell, a rendszert angol nyelven használó felhasználók miatt, akkorát menne’ a dolog, amekkorát magyar levelezőrendszer még nem.

Képek: Gravatar, Iminet, ic.co.uk

0 Tovább
«
12