Tudásbázis
Lásd, mikor nyitották meg az elküldött leveledet
Megnyitották-e az elküldött üzenetedet, mikor, hányszor, és melyik hivatkozásait követték. Bekapcsolva, hacsak ki nem kapcsolod, és őszintén beszél azokról a leolvasásokról, amelyeket nem tud megszerezni.
Részletek
- Két kapcsoló, nem egy, és mindkettő be van kapcsolva, amíg a postafiók ki nem kapcsolja őket. A megnyitás és a kattintás két különböző alku a levelet fogadó emberrel. A pixel azt jelenti, hogy az üzenetet megjelenítették, és semmi mást, míg az átírt hivatkozás egy tényleges látogatást vezet át rajtunk, és sok feladó az elsőt akarja, a másodikat pedig elutasítja. Az az üzenet, amelyet mindkettő kikapcsolásával küldtek, nem visz pixelt, átírt hivatkozást, sem olyan sort, amely követettnek mondaná. Az API-n keresztüli küldés a tracking: { opens, clicks } megadásával arra az egy üzenetre dönt a postafiók helyett, és mindkét irányban dönt: az a program, amely semmit nem akar rögzíttetni, ezt üzenetenként kimondja, és meg is kapja, bárhogy is áll a postafiók.
- Mindkét kapcsoló azt dönti el, mit visz a KÖVETKEZŐ üzeneted, és semmi mást. A már elküldött levél megtartja azt a pixelt és azokat az átírt hivatkozásokat, amelyekkel kiment, és a kapcsoló kikapcsolása után is jelent tovább, és ennek megállítása csak úgy menne, hogy elrontjuk a hivatkozásokat olyan üzenetekben, amelyek már mások kezében vannak, ami rosszabb dolog egy olvasóval szemben, mint tovább számolni. A követés kikapcsolása arról szóló döntés, mi megy ki mostantól; visszahívás nincs.
- Egyetlen megnyitáshoz vagy kattintáshoz sem tárolunk IP-címet, és nincs is oszlop, ahová tenni lehetne. Amit megtartunk, az az, amit a peremhálózat már a kérés beérkezése előtt tudott (egy ország, egy régió, egy város, egy időzóna, egyiket sem kerestük ki külön), plusz a cím és a felhasználói ügynök SHA-256 ujjlenyomata, olyan sóval, amely UTC szerint éjfélkor fordul. A lenyomat az, ami lehetővé teszi, hogy egy jelentés két eszközt mondjon két megnyitás helyett, egy nappal később pedig már senki, mi sem, nem tudja címhez kötni. A helyet a hálózatról, ne az emberről szóló tényként olvasd: aki VPN vagy vállalati proxy mögött van, azt olyan helyen jelentjük, ahol sosem járt.
- Kétféle feljegyzés áll a számok mögött. A találatsor felhasználói ügynököt, várost és ujjlenyomatot hordoz valakiről, aki sosem egyezett bele, hogy mérjék, és azért létezik, hogy megválaszolja a küldés utáni napokban feltett kérdéseket: szkenner volt-e, melyik eszköz, tényleg ő volt-e. A másik fajta maga az olvasás (első, utolsó és egy darabszám, üzenetenként és hivatkozásonként), ami a saját leveledről szóló tény, nem az azt megnyitó emberről.
- Az automatizált letöltéseket rögzítjük, majd nem számoljuk, ami más, mint eldobni őket. Az Apple Mail Privacy Protection funkciója minden üzenet minden távoli képét letölti kézbesítéskor, akár ránéz valaki, akár nem. Alapból be van kapcsolva, és a beszámítása minden feladónak 100% közeli, semmit nem jelentő megnyitási arányt adna, ezért a felhasználói ügynökből és abból ismerjük fel, milyen hálózatról jött a kérés, és gépként jelöljük meg. A vállalati szkennereket, a hivatkozás-ellenőrzőket, a fej nélküli böngészőket és mindent, ami a küldéstől számított tíz másodpercen belül érkezik, ugyanígy jelöljük meg, mert amit ember csinál, az nem történik ilyen gyorsan. A felhasználói ügynököt pontosan úgy tartjuk meg, ahogy érkezett, amellett, amit kiolvastunk belőle, mert az a karakterlánc az, amiből a hívás készült, és az a hívás, amelyet senki nem tud a bemenetéhez mérni, olyan hívás, amelyet senki nem tud kijavítani. Egy kliens bármit írhat oda, és sok szinte semmit nem mond, tehát ez állítás, nem tény. A jelentés kiírja, hányat szűrt ki, ahelyett hogy megmagyarázatlan rést hagyna a napló és az összeg között.
- A Gmail harmadik eset, és így is jelentjük. A képproxija azért tölt le, mert valaki megjelenítette az üzenetet, tehát a megnyitás valódi, míg az eszköz, a hely és a kliens egyszerűen nem megismerhető, a proxy pedig gyorsítótáraz, tehát a második és harmadik olvasás lehet, hogy sosem ér el hozzánk. A Gmailen keresztüli megnyitásszám alsó határ, nem végösszeg.
- A rögzített megnyitás hiánya nem bizonyítja, hogy egy üzenet olvasatlan maradt. A távoli képek blokkolása hétköznapi, hiszen sok kliens alapból bekapcsolva szállítja, és minden másik felkínálja, és ez teljesen elnyomja ezt, tehát az itteni csend egyik irányban sem bizonyíték, és ez az a válasz, amelyet a leggyakrabban kapsz. A termékben semmi nem jelenít meg egy nem követett vagy nem jelentett üzenetet „nem megnyitottként”, mert az azt jelentené, hogy elutasítást olvasunk bele egy hiányba.
- A kattintás erősebb bizonyíték, mint a megnyitás, ezért a kettőt soha nem olvasztjuk egy számba. A távoli képeket sokkal gyakrabban blokkolják, mint ahányszor a hivatkozások kattintatlanul maradnak, amitől a kattintásokkal és megnyitások nélkül álló üzenet biztosan olvasott. Üzenetenként legfeljebb 100 célcím kerül átírásra, mindegyik egyszer. Az ugyanarra a kampányoldalra mutató hivatkozás fejlécképből, gombból és láblécből egyetlen sor a saját számlálójával, mert ez egy kérdés háromszor feltéve, és a jelentés meg tudja mondani, melyik hivatkozást érte meg követni, nem csak azt, hogy valahol valamit követtek. E korlát fölött a maradék hivatkozások pontosan úgy maradnak, ahogy megírták őket, nem esnek ki, mert egy nem követett hivatkozás is működik, egy olyan üzenet viszont, amely csendben kétszázat elveszít belőlük, nem.
- Az átírt hivatkozást nem lehet olyasfelé irányítani, amit nem mi tettünk bele az üzenetbe. A célcím egy sorban áll, az URL pedig csak az azonosítóját viszi, tehát nincs lekérdezési paraméter, amellyel babrálni lehetne, és itt semmiből nem lehet nyílt átirányítást csinálni egy levélszolgáltató domainjén, ami az adathalász kampányok nyersanyaga. Az átirányítás 302, nem 301, mert az állandót a böngésző és minden közbeeső proxy gyorsítótárazza, és a számláló egynél megállna és ott maradna. Az a hivatkozás, amelynek az üzenetét azóta törölték, azt mondja, hogy a cím már nem mutat sehová, nem pedig egy puszta 404 választ ad.
- Csak a válasz új része íródik át; az alatta lévő idézett előzmény valaki más üzenete, és a hivatkozásaik az övék maradnak. Az Elküldöttekbe iktatott példányból kikerül a pixel, és minden hivatkozás visszakerül úgy, ahogy begépelted. E nélkül a saját elküldött leveled továbbítása egy címzett tokenjét továbbítaná egy idegennek, a saját kimenő mappádban lévő hivatkozásra kattintás úgy rögzülne, mintha a címzett kattintott volna, és a megőrzött példányod nem az lenne, amit írtál.
- Az egyetlen címzettes üzenet mindig megnevezi őt: nem lehetett más. Egy fölött annak megnevezése, melyik címzett nyitotta meg, azt jelenti, hogy mindenki saját törzsmásolatot kap, amit csak olyan üzeneten teszünk meg, amely elég kicsi ahhoz, hogy személyenként újraépíteni megfizethető legyen: a becsült méret szorozva a címzettek számával 8MB alatt kell maradjon. E kereten túl, és olyan lezárt üzeneten, amelynek egyetlen titkosított blokkja nem tud személyenként változni, egy törzs megy mindenkinek, a megnyitás pedig úgy rögzül, hogy valaki ezen az üzeneten, nem a listából kiválasztott néven. Az egymástól harminc másodpercen belül megnyitó két ember ott egy olvasásnak számít, ami ugyanennek a korlátnak a másik megfogalmazása. A harminc másodperc minden esetben az ablak: egy újrarajzolódó előnézeti panel, vagy egy visszagördített üzenet újra lekéri a képet, és nem számít második olvasásnak.
- Az egyik OpenEmail-postafiókból a másikba menő levél magától az olvasótól jelenti a megnyitásait. Az itteni olvasó minden 1×1-es képet eltávolít minden üzenetből, mielőtt az a képernyődre érne, a miénket is, tehát a pixel sosem töltődik le. Amikor egy üzenet megjelenik úgy, hogy a távoli képek látszanak, az olvasó rögzíti a megnyitást annál a példánynál, amelyet az a postafiók kapott, és a klienst OpenEmail néven nevezi meg. Aki rejtve tartja a képeket, arról semmi nem rögzül, ugyanúgy, mint bármely más kliensnél, amely blokkolja őket. A hivatkozásokat semmi nem távolítja el, tehát az egyik OpenEmail-postafiókból a másikba menő kattintás a szokásos módon jön vissza.
- A teljes jelentés elérhető a REST API-n az emails:read hatókör alatt, amely már eddig is lefedte az elküldött leveleket: egy lista, megnyitási és kattintási arányok az adott ablakban követett üzenetekre, és az egyedi találatok, az automatizáltakkal együtt, ha kéred. A találatonkénti napló példányonként 2000 sornál megáll, miközben a számlálók futnak tovább, tehát egy ciklusban letöltött pixel nem tud felduzzasztani egy táblát, amelyet senki nem néz.
- Az az üzenet, amelyet követés nélkül küldtek, egyáltalán semmit nem mutat, nem nulla megnyitást. A „senki nem nyitotta meg” és a „nem rögzítettünk” különböző válaszok, és a termékben semmi nem jeleníti meg őket egyformán.