Az elektronikus levelezés már az internet kezdete óta velünk van (és már régebben is). Toldozzuk, foltozzuk, de a vége mindig az, hogy valami nem jó.
Töri óra indul!
Nagyjából a 60-as években született még az ős UNIX-ok korában az első levelezési megoldás, one-to-one elven működve. Az ARPANET aztán persze fejlődött, és szükség volt egy lényegesebben jobb megoldásra, így született meg a 70-es évek körül a ma használatos SMTP őse, amit aztán jól RFC-be is foglaltak 1982-ben. Ezt 2008-ban frissítették, de maradjunk annyiban, hogy az alap szolgáltatás működése gyakorlatilag 37+ éve nem változott.
Ha a sok rövidítés és Wikipedia link után még mindig olvasod, akkor gratulálok, az előszűrés megvolt 🙂
Mi a baj az e-mail ma ismert megvalósításával?
Szögezzük le, hogy nem magával a kommunikációs formával van a gond. Levélre szükség van. Hivatalos közegben, üzleti kommunikációban nem lehet egy chat beszélgetést iktatni, hivatkozni rá. Ugye te sem adnál vagy fogadnál árajánlatot chaten?
Tehát a probléma technikai jellegű. Ma elképesztően sok erőforrást használunk el arra, hogy egy szöveget eljuttassunk A-ból B-be. És amennyire egyszerű és régi az egész, annyira bonyolult a háttérben. Nem véletlen, hogy a legtöbb cég már nem akar ennek üzemeltetésével foglalkozni, és rábízza egy harmadik félre az egészet.
Amivel az átlag felhasználó találkozik, az a spam, címhamisítás. Hiába vannak már megoldások arra, hogy egy küldő szervert megfelelően azonosítsunk, ezek a technológiák nem terjedtek el eléggé (DKIM, DMARC, SPF). Ha használjuk is, akkor max annyira, hogy a spam detektálásba beleszámítjuk, de a hitelesítés hiánya miatt nem dobjuk el azonnal a kapcsolatot. Mert hát sok helyen nincs bevezetve ez. Tehát megint csak a háttérben pazarlunk el energiát arra, hogy ezeket a leveleket megvizsgáljuk.
Miért nem használják az e-mail azonosítási technológiákat?
Nagyon egyszerű: mert a levelezés a háttérben már ezek nélkül is egy irtózatosan összetett rendszer. Külön van a levéltovábbító szerviz, a kliens-kommunikáció, a spamszűrő, és ezek önmagukban is macerásak, mivel egy 37+ éves elgondolás toldozásai. Egyszer nem lett újragondolva egyik sem, mert folyamatosan a visszafelé kompatibilitáson lovagoltak.
Most mondhatnánk, hogy majd megoldja a szolgáltató, akire rábíztuk, de a probléma ettől még nem szűnik meg, ugyanazzal az őstulokkal kell dolgozni, ami sérülékeny, kijátszható.
Miért nem tervezik újra az e-mailt?
A fent említett visszafelé kompatibilitás az egyik „akadálya”. Amit persze az emberek maguknak állítanak, mert elhatározás kérdése. Alapvetően nem kell egyszerre leváltani valamit, ami nem jó. Történt már ilyen nem egyszer: vajon hányan emlékeznek a Gopherre? És tegyék fel a kezüket, akik rendszeresen használnak hagyományos FTP-t. Ezek is kivesztek már (FTP-t még használnak hosting szolgáltatóknál, de a többség már ott is lecserélte valami modernebb eszközre. Tehát ez a kivezetés pont az orrunk előtt zajlik.).
Mi a megoldás az e-mail elavulására?
Ma már rengeteg adatot továbbítunk nagy biztonsággal, akár szabványos REST API-kon, vagy akár SOAP-on keresztül is. Gondoljunk csak arra, hogy a pénzünket rábízzuk ezekre a webes csatornákra, de a levelezéssel meg küzdünk, saját magunknak építve vele akadályokat, s vele együtt plusz költségeket.
Azt gondolom, hogy rendelkezésünkre állnak azok a hitelesítési formák, amelyekkel kikerülhetjük a tömeges szemétküldést (vajon hány kéretlen üzenetet kapunk előhitelesítést igénylő chat-en keresztül, és hányat hagyományos e-mailben?), és a csalásokat is.