bardóczi ákos @post.r

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gmail esetén: 

AOL-on: 

Zimbra rendszerben: 

Horde-n: 

Hushmailen: 

Roundcube-on: 

Squirrelmailnél: