Az elektronikus levél vagy e-levél (e-mail), ahogyan sok kedvelője nevezi, már több mint három évtizede használatban van. Olcsóbb és gyorsabb, mint a hagyományos levél, ezért az e-levél az internet kezdete óta népszerű alkalmazás. 1990 előtt jobbára csak a kutatók használták. Az 1990-es években aztán a nagyközönség is megismerte, és használata innentől kezdve exponenciális ütemben terjedt egészen addig, hogy mára a naponta elküldött e-levelek száma nagyságrendekkel meghaladja a papíralapú levelekét (snail mail). A hálózati kommunikáció egyéb formái, mint például az azonnali üzenetküldés és az IP-hálózaton keresztüli beszédátvitel használata nagymértékben megnőtt az elmúlt évtizedben, de az internetes kommunkáció igáslova az e-levél maradt. Az ipari szereplők széleskörűen alkalmazzák a vállalaton belüli kapcsolatokban, például arra, hogy a szerte a nagyvilágban, egymástól nagy távolságokra lévő alkalmazottak összetett projekteken dolgozhassanak. Sajnos, ahogyan a papíralapú levelek esetében is, az e-levelek nagy része – 10-ből kb. 9 – kacatlevél (spam, junk mail) [McAfee, 2010].
Akárcsak a kommunikáció egyéb formáinak, az e-levélnek is megvannak a saját konvenciói és stílusai. Mindenekelőtt nagyon informális, és túlságosan is csábító a használata. Azok az emberek, akik még álmukban se gondolnának arra, hogy telefonáljanak, sőt levelet írjanak egy Nagyon Fontos Személynek, egy másodpercig sem haboznak egy hanyagul megírt e-levél elküldésénél. A ranggal, életkorral és nemmel kapcsolatos fordulatok eltűnésével az e-levélváltások gyakran a tartalomra koncentrálnak, és nem a státusra. Az e-levél segítségével egy nyári munkára szerződött diák briliáns ötlete nagyobb hatású lehet, mint az ügyvezető alelnök ostobasága.
Az e-levél tele van olyan szlenggel, mint például a BTW (By The Way – apropó), ROTFL (Rolling On The Floor Laughing – gurulok a röhögéstől) és IMHO (In My Humble Opinion – szerény véleményem szerint). Sokan mosolyikonnak (smiley, emoticon) nevezett kis ASCII-szimbólumokat is használnak az e-leveleikben, például a mindenütt megtalálható „:-)”-t. Ha a jelkép nem lenne ismerős, forgassa el a könyvet az óramutató járásával megegyezően 90 fokkal. Ez a szimbólum és a többi mosolyikon segít az üzenet hangulatának közvetítésében. Ezek a kommunikáció egyéb tömör formáiban, például az azonnali üzenetküldésben is elterjedtek.
Az e-levél protokolljai is kialakultak a használatuk során. Az első e-levél rendszerek egyszerű fájlátviteli protokollokból álltak azzal a konvencióval, hogy az üzenetek (azaz a fájlok) első sora a címzettre utalt. Az idő múlásával azonban az e-levél eltávolodott a fájlátviteltől és számos képességgel ruházták fel, például az egyetlen üzenet több címzettnek való továbbításának lehetőségével. A mutimédiás képességek az 1990-es évek során váltak fontossá, hogy az üzenetekkel képeket és egyéb nem szöveges anyagokat is el lehessen küldeni. Az e-levelek olvasására szolgáló programok is sokkal összetettebbé váltak, a szöveges felhasználói felületről fokozatosan grafikusra váltottak, és lehetővé tették a felhasználóknak, hogy elérjék leveleiket laptopjaikról, bárhol is legyenek. Végül, a kacatlevél dominanciája miatt a levelek olvasására szolgáló programoknak és a levéltovábbító protokolloknak figyelmet kell fordítaniuk a kéretlen levelek megtalálására és törlésére is.
Az e-levelek ismertetésekor jobban fogunk koncentrálni az üzenetek felhasználók közötti továbbítására, mint a levélolvasó programok megjelenésére. Az architektúra átfogó ismertetését követően mégis a rendszernek a felhasználó által látható részével kezdjük az ismerkedést, mert ez a legtöbb olvasó számára ismerős.
Ebben a részben átfogó ismertetést adunk az e-levél rendszerek felépítéséről és arról, hogy mire képesek. Az e-levél rendszerek architektúrája a 7.7. ábrán látható. Két alrendszerből állnak, a felhasználói ügynökből (user agent), amely lehetővé teszi a felhasználók számára az üzenetek olvasását és küldését, valamint az üzenettovábbító ügynökből (message transfer agent), ami a leveleket eljuttatja a feladótól a címzettig. Az üzenettovábbító ügynökökre informálisan levelezőszerverekként (mail server) is fogunk hivatkozni.
A felhasználóiügynök-program grafikus, ritkábban szöveges és parancsalapú csatlakozó felületet nyújt az e-levél rendszerrel való érintkezésre. Ez magában foglalja az üzenetek írásához, megválaszolásához, a beérkező üzenetek megjelenítéséhez valamint az üzenetek iktatással, kereséssel és törléssel való rendszerezéséhez szükséges eszközöket. Az új üzeneteknek kézbesítés céljából levelezőrendszerbe történő küldését a levél feladásának (mail submission) nevezzük.
A felhasználói ügynök tevékenységeinek egy része automatizálható, feltételezve a felhasználó szándékát. Például a beérkező leveleket meg lehet szűrni törlés céljából, vagy hátrébb lehet sorolni a fontossági sorrendben azokat az üzeneteket, amelyek valószínűleg kacatlevelek. Néhány felhasználói ügynök fejlett szolgáltatásokat is tartalmaz, például automatikusan válaszol az e-levelekre („Most éppen a csodálatos szabadságomat töltöm, és el fog tartani egy darabig, mire visszaérek.”). A felhasználói ügynök azon a számítógépen fut, amelyen a felhasználó olvassa a leveleit. Ez is csak egy program, amit időnként le lehet futtani.
Az üzenettovábbító ügynökök általában rendszerfolyamatok. Ezek a levelezőszerver-gépeken a háttérben futnak abból a célból, hogy mindig elérhetők legyenek. Feladatuk, hogy a rendszeren keresztül automatikusan eljuttassák az e-leveleket a feladótól a címzettig az SMTP (Simple Mail Transfer Protocol – egyszerű levéltovábbító protokoll) segítségével. Ez az üzenettovábbítási lépés.
Az SMTP-t eredetileg az RFC 821 részletezte, aminek a módosításával jött létre a jelenleg érvényes RFC 5321. Ez összeköttetéseket használ a levelek elküldésére, és kézbesítés státusának, valamint az esetleges hibáknak a visszaküldésére. Számos alkalmazás létezik, amelyekben a továbbítás nyugtázása fontos, és akár jogi jelentősége is lehet („Tisztelt bíróság! Az e-levél rendszerem nem éppen megbízható, ezért úgy vélem, hogy az elektronikus idézés elveszett valahol.”).
Az üzenettovábbító ügynökök levelezési lista (mailing list) funkciót is megvalósítanak; az üzenet pontos másolatait mindenkinek továbbítják, aki szerepel az e-levél címlistáján. A fejlett szolgáltatások közé tartoznak még a szokásos másolatok (carbon copy) és vakmásolatok (blind carbon copy) készítése, a sürgős e-levelek, titkos (titkosított) e-levél, alternatív címzettnek szóló e-levél készítése arra az esetre, ha az elsődleges pillanatnyilag nem elérhető, valamint annak lehetősége, hogy a titkárnők elolvassák és megválaszolják főnökük e-levelét.
A felhasználói ügynökök és az üzenettovábbító ügynökök összekapcsolása adja a postaláda és a szabványos e-levél formátum koncepcióját. A postaládák (mailbox) tárolják a felhasználók által kapott leveleket. Ezeket a levelezőszerverek kezelik. A felhasználói ügynökök egyszerűen csak megmutatják a felhasználóknak postaládáik tartalmát. Ennek érdekében a felhasználói ügynökök levelezőszerver-parancsokat küldenek a postaládák manipulálása, azok tartalmának megvizsgálása céljából, üzenetek törlése érdekében és így tovább. A levélnek a postaládából történő kivétele a levél kézbesítése (3. lépés a 7.7. ábrán). Ennek az architektúrának a segítségével egy felhasználó több számítógépen különféle felhasználói ügynököket használhat postaládájának elérésére.
A levéltovábbító ügynökök a levelet szabványos formában továbbítják egymásnak. Az eredeti RFC 822 formátum módosításával, valamint a multimédiás tartalmak és a nemzetközi szövegek támogatásával jött létre a jelenleg érvényes RFC 5322. Ezt a sémát MIME-nak nevezik, és később részletesen tárgyaljuk. Mindezek ellenére az emberek az internetes e-levelekre még mindig RFC 822-ként hivatkoznak.
A kulcsötlet az üzenetformátumban a boríték (envelope) és a tartalom különválasztása. A boríték magába foglalja az üzenetet. Tartalmazza az üzenet továbbításához szükséges információkat, mint a címet, a prioritást és biztonsági szintet, amelyek mindegyike az üzenettől teljesen elkülönül. Az üzenettovábbító ügynökök, a postához hasonlóan a borítékot használják az útvonal meghatározására.
A borítékon belüli üzenet két részből áll: a fejlécből (header) és a szövegrészből vagy törzsből (body). A fejléc vezérlési információt tartalmaz a felhasználói ügynökök részére. A szövegrész teljesen az emberi címzettnek szól. Egyik ügynök sem foglalkozik sokat vele. A borítékok és szövegrészek a 7.8. ábrán láthatók.
A továbbiakban alaposabban is megvizsgáljuk az architektúra részeit, megnézzük azokat a lépéseket, amelyek az e-levél egyik felhasználótól másikig történő elküldéséhez szükségesek. Ez az utazás a felhasználói ügynökkel kezdődik.
A felhasználói ügynök általában egy program (melyet néha levélolvasónak vagy üzenetolvasónak neveznek), ami számtalan, az üzenetek létrehozásával, fogadásával, azok megválaszolásával és a postaládák kezelésével kapcsolatos parancsot képes értelmezni. Sok népszerű felhasználói ügynök létezik, mint például a Google gmail, Microsoft Outlook, Mozilla Thunderbird és az Apple Mail. Ezek külső megjelenése nagyon változatos. Egyes felhasználói ügynököknek menü- vagy ikonvezérelt felhasználói felülete van, melynek kezeléséhez egér, vagy a kisebb mobil eszközök esetén érintőképernyő szükséges. A régebbi felhasználói ügynökök, mint az Elm, mh és a pine szöveges felületet adnak, és 1 betűs parancsokat várnak a billentyűzetről. Funkcionálisan ezek megegyeznek, legalábbis a szöveges üzenetek esetében.
Egy felhasználói ügynök kezelőfelületének tipikus elemei láthatóak a 7.9. ábrán. Az Ön levélolvasója valószínűleg sokkal mutatósabb, de feltehetőleg egyenértékű funkciókkal bír. Amikor egy felhasználói ügynök elindul, általában összegzést ad a felhasználó postaládájában lévő üzenetekről. Az összegzés gyakran üzenetenként egyetlen sorból áll, és a sorok valamilyen szempont szerint rendezettek. Kiemeli az üzenet borítékjából vagy fejlécéből vett fontos mezők tartalmát.
A 7.9. ábrán hét összegző sor látható. A sorok a Feladó, Tárgy és Fogadás ideje mezőket tartalmazzák, ebben a sorrendben, amelyek megmutatják, hogy ki küldte az üzenetet, miről szól és mikor érkezett meg. Minden információ felhasználóbarát módon, az üzenetmezők alapján, de nem azok szó szerinti szöveges tartalmával jelenik meg. Tehát azok, akik elfelejtik megadni a Tárgy mezőt, gyakran azt tapasztalják, hogy a leveleikre adott válaszok nem szokták megkapni a legmagasabb prioritást.
Sok más mező vagy jelzés használata lehetséges. A 7.9. ábrán az üzenet tárgya mellett látható ikonok jelezhetik például az olvasatlan levelet (boríték), csatolmányt (gemkapocs) és a fontos levelet, amelyet legalábbis a küldő fontosnak tart.
Sokféle szempont szerinti rendezés is elképzelhető. A legáltalánosabb az üzenetek fogadási ideje szerinti sorba rendezés, kezdve a legújabbal, valamilyen jelzéssel ellátva arra vonatkozólag, hogy az üzenet új, vagy a felhasználó már elolvasta. Az összegzésben lévő mezőket és a rendezést a felhasználó igényének megfelelően testre szabhatja.
A felhasználói ügynököknek igény szerint meg kell tudniuk jeleníteni a beérkezett üzeneteket, hogy az emberek el tudják olvasni e-leveleiket. Gyakran az üzenet rövid előnézetét is megjelenítik, mint a 7.9. ábrán is, hogy segítsenek a felhasználóknak eldönteni, mikor olvassák tovább. Az előnézetek kis ikonokat vagy képeket használhatnak az üzenet tartalmának jellemzésére. A megjelenítéssel kapcsolatos tevékenységek közé tartozik a szöveg újraformázása, hogy kiférjen a kijelzőre, fordítás vagy a tartalom kényelmesebb formátumokra alakítása (például digitalizált beszéd átalakítása szöveggé).
Miután a felhasználó elolvasta az üzenetet, eldöntheti, hogy mit tegyen vele. Ez az üzenet elrendezése (message disposition). A lehetőségek közé tartozik az üzenet törlése, megválaszolása, továbbítása egy másik felhasználónak és az üzenet megtartása későbbi hivatkozás céljából. A legtöbb felhasználói ügynök képes a beérkezett leveleket tároló postaláda és a hozzá tartozó több, mentett leveleket tartalmazó mappa kezelésére. A mappák lehetővé teszik a felhasználó számára, hogy az üzeneteket feladók, témák vagy valamilyen más kategória szerint mentse el.
A felhasználói ügynök az iktatást automatikusan is elvégezheti, még mielőtt a felhasználó elolvasná az üzeneteket. Egy egyszerű példa erre, amikor az üzenet mezőinek és tartalmának megvizsgálása után, a felhasználó korábbi visszajelzéseit felhasználva kideríti, hogy az üzenet kacatlevél-e. Sok ISP és vállalat olyan szoftvert futtat, ami a leveleket fontos vagy kacatlevél címkével jelöli meg, így a felhasználói ügynök ennek megfelelően iktathatja ezeket. Az ISP-k és a vállalatok abban az előnyös helyzetben vannak, hogy sok felhasználó leveleit láthatják és lehetnek listáik az ismert kacatlevélküldőkről. Ha több száz felhasználó szinte egyszerre kap hasonló üzenetet, akkor az valószínűleg kacatlevél. A felhasználói ügynök azzal, hogy előre szétválogatja a leveleket a „valószínűleg szabályos” és a „valószínűleg kacatlevél” kategóriák szerint, a felhasználókat jelentős mennyiségű munkától kíméli meg.
Melyek a leggyakrabban előforduló kacatlevelek? Ezeket a fertőzött számítógépekből álló, ún. hálózati robotok (botnet) állítják elő, és a levelek tartalma attól függ, hogy a címzett hol él. Ázsiában hamis diplomákat kínálnak, az Egyesült Államokban olcsó gyógyszereket és egyéb kétes termékeket ajánlanak. Érvénytelen nigériai bankszámlákból még mindig sok van. A különféle testrészeket megnövelő pirulák mindenütt megtalálhatók.
A felhasználók más iktatási szabályokat is meghatározhatnak. Minden egyes szabály feltételből és cselekvésből áll. Például egy szabály kimondhatja, hogy a főnöktől érkező összes üzenet egy mappába kerül azonnali olvasás céljából, egy bizonyos levelezőlista üzenetei pedig egy másikba, későbbi elolvasás végett. Számos mappa látható a 7.9. ábrán. A legfontosabb mappák a Beérkezett üzenetek (Inbox) mappa, amiben azok a levelek vannak, amelyek nem lettek máshová áthelyezve, valamint a Kacatlevél (Junk Mail) mappa a kacatlevélnek vélt üzenetek számára.
Az olyan explicit szerkezeteken kívül, mint amilyenek a mappák, a felhasználói ügynököknek manapság a postaládában való keresésre számos más képességük is van. Ez a képesség is látszik a 7.9. ábrán. A keresési lehetőségekkel a felhasználók gyorsan megtalálhatnak olyan, valaki által a múlt hónapban küldött üzenetet, amiben például arról van szó, hogy „hol lehet olcsón okostelefont venni”.
Az e-levél hosszú utat tett meg az egyszerű fájlátvitel óta. A szolgáltatók ma már rendszeresen adnak postaládákat akár 1 GB tárhellyel, amiben egy felhasználó levélváltásai hosszú időre megmaradnak. A felhasználói ügynökök kifinomult levélkezelése, a keresés és az automatikus feldolgozás különféle formái teszik lehetővé, hogy az e-levelek ilyen nagy mennyiségben kezelhetők. Azok számára, akik évente több ezer üzenetet küldenek és fogadnak, ezeknek az eszközöknek az értéke felbecsülhetetlen.
Egy másik hasznos lehetőség valamilyen módon automatikusan reagálni a levelekre. Egy reakció lehet a beérkező e-levél továbbítása egy másik címre, például egy kereskedelmi személyhívó szolgáltató által üzemeltetett számítógép, amely rádiós vagy műholdas összeköttetéssel követi a felhasználót, és megjeleníti a Tárgy: sort a személyhívóján. Ezeknek az automatikus válaszadóknak vagy automatikus reagálóknak (autoresponder) a levelezőszerveren kell futniuk, mert a felhasználói ügynök nem mindig fut, és csak alkalomszerűen tölti le az e-leveleket. Emiatt a felhasználói ügynök nem tudja megvalósítani a valódi automatikus válaszadást. Az automatikus válaszadás kezelői felületét azonban általában a felhasználói ügynök biztosítja.
Az automatikus reagálásra egy másik példa a távollétet jelző ügynök (vacation agent). Ez egy olyan program, amely megvizsgálja a beérkező levelet és olyan unalmas választ küld a feladónak, mint például „Szia! Nyaralni mentem. Augusztus 24-én jövök vissza. Utána válaszolok.” Az ilyen válaszok megadhatják, hogy a közbenső időben felbukkanó sürgős esetekben hogyan kell eljárni, vagy megadhatják azoknak a személyeknek a nevét, akikhez a különböző problémákkal fordulni kell stb. Legtöbb távollétet jelző démon számon tartja, hogy kinek küldött már ilyen konzervlevelet, és többször nem ismétli meg azt. Ezek az ügynökök azonban csapdákat is rejtegetnek. Például nem tanácsos konzervlevelet küldeni válaszként egy nagy levelezőlistáról érkező üzenetre.
Most vizsgáljuk meg azt a forgatókönyvet, amikor az egyik felhasználó üzenetet küld a másiknak. Nem beszéltünk még a felhasználói ügynök egy másik alapvető szolgáltatásáról, a levél összeállításáról. Ez magába foglalja az üzenetek, illetve az üzenetekre adott válaszok elkészítését, és ezeknek az üzeneteknek a levelezőrendszer többi részébe való küldését kézbesítés céljából. Bár akármilyen szövegszerkesztő használható az üzenet törzsének elkészítéséhez, a szövegszerkesztők általában be vannak építve a felhasználói ügynökbe abból a célból, hogy segítsenek a címzésnél és az üzenethez kapcsolt számos fejlécmező kitöltésénél. Például egy üzenet megválaszolásakor az e-levél rendszer kiveheti a feladó címét a beérkezett e-levélből és automatikusan beszúrhatja azt a válasz megfelelő helyére. Az általános képességek közé tartozik még az aláírásblokk (signature block) hozzáfűzése az üzenet aljához, a helyesírás ellenőrzése és az üzenet érvényességét mutató digitális aláírások kiszámítása.
A levelezőrendszerbe küldött üzeneteknek szabványos formátuma van, amelyet a felhasználói ügynöknek megadott információ alapján kell előállítani. Az üzenetnek a továbbítás szempontjából legfontosabb része a boríték, a boríték legfontosabb része pedig a címzett címe. Ennek a címnek olyan formátumúnak kell lennie, amit az üzenettovábbító ügynök képes feldolgozni.
A cím elvárt formája felhasználó@dns-cím. Mivel tanulmányoztuk a DNS-t korábban ebben a fejezetben, azt az anyagot nem fogjuk itt megismételni. Érdemes azonban megjegyezni, hogy a címzésnek más formái is léteznek. Főleg az X.400 címek néznek ki egészen másként, mint a DNS-címek.
Az X.400 egy üzenetkezelő rendszerek számára készült ISO-szabvány, ami egykor az SMTP versenytársa volt. Az SMTP legyőzte, de az X.400-as rendszerek még mindig használatban vannak, többnyire az Egyesült Államokon kívül. Az X.400 címek attribútum=érték párokból tevődnek össze, amelyeket / jelek választanak el egymástól. Például:
/C=US/ST=MASSACHUSETTS/L=CAMBRIDGE/PA=360 MEMORIAL DR./CN=KEN SMITH/
Ez a cím megadja az ország nevét, az állam nevét, a helység nevét, az utca nevét és a házszámot, és egy szokványos személynevet (Ken Smith). Sok más attribútum is szóba jöhet, így annak is lehet levelet küldeni, akinek a pontos e-levél címe ugyan nem ismert, de ismert elegendő számú más attribútuma (például cég és betöltött állás).
Bár az X.400-címek jóval kényelmetlenebbek, mint a DNS-nevek, ez eldönthetetlen kérdés, mivel a felhasználói ügynökök felhasználóbarát álnevekkel rendelkeznek (ezeket néha beceneveknek is hívják), melyek lehetővé teszik, hogy a felhasználók bevigyenek vagy kiválasszanak egy személynevet, és megkapják a pontos e-levél címet. Tehát nem feltétlenül szükséges ténylegesen beírni ezeket a furcsa karakterláncokat.
Az utolsó pont, amire ki kell térnünk a levélküldéssel kapcsolatban, az a levelezési listákkal kapcsolatos. Ezek lehetővé teszik a felhasználóknak, hogy ugyanazt az üzenetet egyetlen parancs segítségével elküldjék egy listán szereplő összes embernek. Kétféleképpen is lehet működtetni egy levelezési listát. Működtetheti helyileg a felhasználói ügynök. Ebben az esetben a felhasználói ügynök külön levelet küld minden egyes címzettnek.
A másik lehetőség, hogy a listát a távolban egy üzenettovábbító ügynök üzemelteti. Az üzenetek terjesztésére ekkor az üzenettovábbító rendszerben kerül sor, amelynek az a hatása, hogy több felhasználó is beküldhet levelet a listára. Például, ha egy madárbarát csoportnak van egy birders nevű levelezési listája, ami a meadowlark.arizona.edu-n üzemel, akkor minden, a birders@meadowlark.arizona.edu címre küldött levél először eljut az Arizonai Egyetemre, és csak ott válik szét a lista tagjainak megfelelő üzenetekre, bárhol éljenek is a világban. A levelezési lista használói a címből nem tudják megállapítani, hogy ez egy levelezési lista. Lehet ez akár Gabriel O. Birders professzor személyes postaládája.
Térjünk most át a felhasználói felületről magukra a levélformátumokra. A felhasználói ügynök által küldött üzeneteknek szabványos formátumúnak kell lenniük, hogy az üzenettovábbító ügynökök képesek legyenek kezelni azokat. Először az alap ASCII e-leveleket vizsgáljuk meg az RFC 5322 használatával, ami az eredeti, RFC 822-ben ismertetett internet-üzenetformátumnak utolsó átdolgozása. Azután megvizsgáljuk az alapformátum multimédia-bővítményeit.
A levelek egy egyszerű borítékból (amit az SMTP részeként az RFC 5321 tárgyal), néhány fejlécmezőből, egy üres sorból és az üzenetrészből állnak. Minden fejlécmező (logikailag) egyetlen ASCII-szövegű sorból áll, amely tartalmazza a mező nevét, egy kettőspontot és a legtöbb mezőnél egy értéket. Az RFC 822-t évtizedekkel ezelőtt tervezték, és nem különbözteti meg tisztán egymástól a boríték- és a fejlécmezőket. A szabványt kicsit átdolgozták ugyan az RFC 5322-ben, teljesen átalakítani azonban nem lehetett a kiterjedt használata miatt. Normális esetben a felhasználói ügynök összerakja a levelet, majd átadja azt az üzenettovábbító ügynöknek, amely aztán a fejléc egyes mezőiből összeállítja a tényleges borítékot, ami némileg régimódi keveréke a borítéknak és üzenetnek.
Az üzenettovábbítással kapcsolatos legfontosabb mezőket a 7.10. ábrán soroltuk fel. A To: mező az elsődleges címzett DNS-címét tartalmazza. Egy üzenetnek több címzettje is lehet. A Cc: mező az esetleges másodlagos címzettek címét adja meg. A továbbításnál nincs különbség az elsődleges és másodlagos címzettek között. Ez teljesen pszichológiai természetű megkülönböztetés, amely pusztán a levelezőknek lehet fontos, azonban a levelezőrendszernek nem. A Cc: (Indigós másolat – Carbon copy) elnevezés bevett szokás, azonban kissé elavult, hiszen a számítógépek nem használnak indigót. A Bcc: (Vak indigós másolat – Blind carbon copy) hasonló a Cc: mezőhöz, ez a sor azonban kitörlődik minden elsődleges és másodlagos címzettnek küldött másolatból. Ez a sajátosság lehetővé teszi, hogy kívülállóknak is lehessen másolatot küldeni anélkül, hogy azt az elsődleges és másodlagos címzett megtudná.
A következő két mező a From: és Sender: rendre az üzenet szerzőjét, valamint elküldőjét adja meg. Ezek nem feltétlenül egyeznek meg. Például egy cégvezető megír egy levelet, de a titkárnője küldi el azt. Ebben az esetben a cégvezető szerepel a From: mezőben, míg a Sender: mezőben a titkárnő jelenik meg. A From: mező kötelező, a Sender: mező elhagyható, ha értékük megegyezik. Ezek a mezők abban az esetben szükségesek, ha a levél nem továbbítható és vissza kell küldeni a feladónak.
A levél útja mentén minden üzenettovábbító ügynök hozzáad egy Received: mezőt tartalmazó sort a levélhez. Ez a sor tartalmazza az ügynök azonosítóját, a dátumot, az időt és más információt, amelyek a forgalomirányító rendszerben levő hibák felderítéséhez használhatók.
A Return-Path: mezőt az utolsó üzenettovábbító ügynök ragasztja a levélhez, és arra szolgál, hogy megadja a feladóhoz visszavezető utat. Elvileg ez az információ a Received: mezőkből is összeállítható (kivéve a feladó postafiókjának nevét). Ez a mező azonban ritkán van kitöltve, és többnyire csak a feladó címét tartalmazza.
A 7.10. ábrán látható mezőkön kívül az RFC 5322 levelei tartalmazhatnak még néhány, a felhasználói ügynökök vagy az emberek által használt mezőt. A legáltalánosabbak ezek közül a 7.11. ábrán láthatók. Legtöbbjük jelentése könnyen megérthető, ezért nem ismertetjük mindegyiket részletesen.
A Reply-To: mezőt akkor használják, ha sem a szerző, sem a feladó nem szeretné látni a választ. Tegyük fel például, hogy egy marketingmenedzser ír egy e-levelet, amely egy új termékről számol be az üzletfeleknek. A levelet a titkárnő küldi el, de a Reply-To: mezőben az eladási osztály vezetőjének címe szerepel, aki képes a kérdéseket megválaszolni, és a rendeléseket felvenni. Ez a mező akkor is hasznos, ha a feladónak két e-mail címe van, és a másikra kéri a választ.
A Message-Id: egy automatikusan előállított szám, amit az üzenetek összekapcsolására (például amikor az In-Reply-To: mezőben használják) és a többszörös kézbesítés megakadályozására használnak.
Az RFC 5322 határozottan kijelenti, hogy a felhasználók kitalálhatnak saját használatra új fejlécmezőket. Az RFC 822 óta létező szabály alapján ezeknek X- karakterlánccal kell kezdődniük. A saját használatú és hivatalos mezők közti konfliktus elkerülése végett garantált, hogy semelyik hivatalos fejlécmező nem fog a jövőben sem X--lel kezdődni. Néhány okostojás egyetemista az X-Fruit-of-the-Day: vagy X-Disease-of-the-Week:-hez hasonló mezőket ragaszt a levelekhez, amelyek legálisak ugyan, de nem mindig az értelemről tanúskodnak.
A fejlécmezők után következik az üzenetrész. A felhasználók azt írnak ide, amit akarnak. Sokan ASCII-rajzokat tartalmazó aláírással, kisebb-nagyobb költőktől származó idézetekkel, politikai megjegyzésekkel, felelősségelhárító nyilatkozatokkal zárják leveleiket (például: Az XYZ cég nem felelős azért, amit mondok; valójában nem is érti meg).
Az ARPANET korai szakaszában az e-levelek kizárólag ASCII-karakterekből álló angol nyelven írt szöveges üzenetekből álltak. Ehhez tökéletesen megfelelt az RFC 822: megadta a fejlécmezőket, de a tartalmat teljesen a felhasználó tetszésére bízta. Az 1990-es években a világszerte használt internet és a gazdagabb tartalmak levelezőrendszeren keresztüli elküldésének igénye miatt ez a megközelítés már nem volt megfelelő. Problémák merültek fel az ékezetes betűket tartalmazó nyelveken (például francia, német) írt üzenetek küldésénél és fogadásánál, azoknál, amelyek nem latin betűkkel (például héber és orosz) vagy ábécé nélküli nyelveken íródtak (például kínai és japán), valamint a szöveget egyáltalán nem tartalmazó üzeneteknél (például hang, kép, vagy bináris dokumentumok és programok).
A megoldás a MIME (Multipurpose Internet Mail Extensions – többcélú hálózati levelezés kiterjesztés) kifejlesztése volt. Széles körben alkalmazzák az interneten átküldött üzeneteknél, de a tartalom meghatározásához más alkalmazásokban is, például web böngészésnél. A MIME részleteit az RFC 2045–2047, 4288, 4289 és 2049 tartalmazza.
A MIME alapötlete az, hogy használja tovább az RFC 822 által leírt formát (ez volt az RFC 5322 előfutára a MIME-javaslat idején), de adjon struktúrát az üzenet szövegrészének, és definiáljon kódolási szabályokat a nem ASCII-üzenetek átvitele számára. Azzal, hogy a továbbítandó MIME-üzenetek nem térnek el az RFC 822-től, tovább lehet használni a meglevő levéltovábbító ügynököket és protokollokat (amik az RFC 821-en alapultak akkor, és az RFC 5321-en ma). Csupán a küldésre és fogadásra való programokat kellett lecserélni, ezt pedig a felhasználók maguk is meg tudták tenni.
A MIME öt új üzenet-fejlécmezőt definiál, amelyek a 7.12. ábrán láthatók. Az első ezek közül egyszerűen megadja az üzenetet fogadó felhasználói ügynöknek, hogy ez egy MIME-üzenet, és azt, hogy a MIME melyik verzióját használja. Minden olyan üzenet, amelyben nem szerepel a MIME-version: fejlécmező egyszerű angol szöveges üzenetnek számít (vagy legalábbis olyannak, ami csak ASCII-karaktereket használ), és ennek megfelelően kerül feldolgozásra.
A Content-Description: fejlécmező egy ASCII-karakterlánc, amely megadja az üzenet típusát. Ez a fejlécmező azért kell, hogy a címzett eldönthesse, hogy érdemes-e visszakódolni az üzenetet. Ha a mező azt tartalmazza, hogy: „Fénykép Barbara versenyegeréről”, és az illető, aki kapja, nem kedveli a versenyegereket, akkor valószínűleg eldobja azt, és nem kódolja vissza nagy felbontású színes képpé.
A Content-Id: fejlécmező azonosítja a tartalmat. Ugyanazt a formátumot használja, mint a standard Message-Id: fejlécmező.
A Content-Transfer-Encoding: azt adja meg, hogy a szövegrészt milyen módszerrel csomagolták a hálózati átvitelre. A MIME fejlesztésének idején a legnagyobb gondot az okozta, hogy a levéltovábbító (SMTP) protokollok ASCII-üzeneteket vártak, amelyben a sorok hossza nem haladta meg az 1000 karaktert. Az ASCII-karakterek 7 bitet használnak fel minden 8 bites bájtból. Az olyan bináris adatok, mint a futtatható programok és képek, a bájtoknak mind a 8 bitjét felhasználják, akárcsak a kibővített karakterkészletek. Nem volt garancia ezeknek az adatoknak a biztonságos továbbítására. Ezért szükség volt valamilyen módszerre a bináris adatoknak az átviteléhez, amelynek segítségével a bináris adatokat át lehetett alakítani úgy, hogy azok hagyományos ASCII-levélnek tűnjenek. A MIME kifejlesztése óta az SMTP bővítményei lehetővé teszik a 8 bites bináris adatok átvitelét, de a bináris adatok még ma sem mindig mennek át hibátlanül a levelezőrendszeren, ha nincsenek átkódolva.
A MIME öt sémát bocsát rendelkezésre, plusz egy lehetőséget az új sémák használatára – biztos, ami biztos. A legegyszerűbb séma a sima ASCII-szöveg. Az ASCII-karakterek 7 biten kódolhatók, és az e-levél protokoll segítségével közvetlenül szállítani lehet azokat, feltéve, hogy egy sor nem haladja meg az 1000 karaktert.
A következő legegyszerűbb séma ugyanez, csak 8 bites karaktereket használ, azaz minden érték 0-tól 255-ig megengedett. A 8 bitet használó üzeneteknek továbbra is be kell tartaniuk a maximális sorhosszra vonatkozó korlátozást.
Vannak olyan üzenetek is, amelyek valódi bináris kódolást használnak. Ezek tetszőleges bináris fájlok, amelyek nemcsak 8 bitesek, hanem az 1000 karakteres sorhossz határt sem veszik figyelembe. A végrehajtható programok ebbe a kategóriába tartoznak. Manapság a levelezőszerverek képesek egyezkedni és megállapodni az adatok bináris (vagy 8 bites) formában történő küldésében, de visszaváltanak ASCII-módba, ha a két fél közül valamelyik nem támogatja ezt a kiterjesztést.
A bináris adatok ASCII-kódolását base64 kódolásnak (base64 encoding) nevezik. Ebben a sémában 24 bites csoportokat 6 bites egységekre tördelnek úgy, hogy minden egység értéke szerint egy legális ASCII-karakter formájában kerül átvitelre. A kód a következő: az „A” 0-nak, a „B” az 1-nek, a „C” a 2-nek stb. felel meg, majd a nagybetűket a 26 kisbetű követi, ezután jön a tíz szám, végül a + jel és a / jel, a 62-nek és a 63-nak megfelelően. Az == és = szekvenciák arra szolgálnak, hogy jelezzék, ha az utolsó csoport csak 16 vagy 8 bitet tartalmaz. A soremelés és kocsi-vissza jelek a kódban nem számítanak, így ezeket tetszés szerint lehet használni a rövid sorok elérése érdekében. Ezzel a sémával biztonságosan, de rossz hatékonysággal lehet tetszőleges bináris szöveget küldeni. Ez a kódolás nagyon népszerű volt a bináris átvitelre képes levelezőszerverek széles körű elterjedése előtt. Még mindig gyakran használják.
Azoknál az üzeneteknél, amelyek majdnem ASCII-formátumúak, és csak néhány nem ASCII-karaktert tartalmaznak, a base64 kódolás nem kifejezetten hatékony. Ilyenkor inkább az idézett nyomtatható karakteres kódolás (quoted-printable encoding) használható. Ez 7 bites ASCII, de a 127 feletti karakterek értékét egy egyenlőségjelet követő, két hexadecimális szám kódolja. A vezérlőkarakterek, néhány írásjel és matematikai szimbólum, valamint a sorvégi szóközök is ugyanígy kódoltak.
Végül, ahol jogos érvek szólnak ezek ellen a kódolások ellen, ott lehetőség van egy felhasználó által definiált kódolás megadására a Content-Trasfer-Encoding: fejlécmező segítségével.
A 7.12. ábrán utolsóként feltüntetett fejlécmező tulajdonképpen a legérdekesebb. Ez az üzenet tartalmának természetét határozza meg, és hatása jóval túlmutat az e-levélen. Például ha a webről letöltött tartalmakat MIME-típusokkal jelölik, akkor a böngésző tudja, hogyan kell azt megjeleníteni. Ugyanez a helyzet a valós időben letölthető multimédiás tartalmak és a valós idejű átvitel, például az IP-hálózaton keresztüli beszédátvitel esetén.
Az RFC 1521 kezdetben hét típust definiált. Minden típus egy vagy több altípussal rendelkezik. A típust és az altípust perjellel választják el, valahogy így: „Content-Type: video/mpeg”. Azóta több száz altípus jelent meg, más típusokkal együtt. Valahányszor egy új típusú tartalmat fejlesztenek ki, további bejegyzések jelennek meg. Az IANA kezeli a kijelölt típusok és altípusok listáját, ami megtekinthető a www.iana.org/assignments/media-types oldalon.
A 7.13. ábra megadja a típusokat, a gyakran használt altípusok példáival együtt. Röviden nézzük át ezeket, kezdve a text-tel. A text/plain kombináció az általános üzeneteket jelenti, amelyeket további kódolás és alakítás nélkül lehet fogadni és megjeleníteni. Ez teszi lehetővé az általános üzenetek MIME-formában való küldését mindössze néhány extra fejlécmező hozzáadásával. Amikor a világháló népszerűvé vált, bevezették a text/html altípust (az RFC 2854-ben), hogy weboldalakat is lehessen RFC 822-es e-levélben küldeni. Az RFC 3023 a kiterjeszthető jelölőnyelv (XML) számára létrehozta a text/xml altípust. Az XML-dokumentumok a világháló fejlődésével terjedtek el. A HTML-t és az XML-t a 7.3. alfejezetben fogjuk tanulmányozni.
A következő MIME-típus az image, ami az állóképek átvitelére alkalmazható. Számos elterjedt, tömörítéssel ellátott vagy anélküli formátum létezik manapság a képek tárolására és átvitelére. Számos ilyen formátum kezelését, köztük a GIF, JPEG és TIFF formátumokét is, csaknem az összes böngészőbe beépítették. Sok egyéb formátum és a nekik megfelelő altípusok léteznek még.
Az audio és video a hang, illetve a mozgókép átvitelére szolgál. Kérjük, vegye figyelembe, hogy a video csak képi információt tartalmazhat, hangot nem. Ha hangosfilmet szeretnénk átvinni, akkor lehet, hogy külön kell átvinnünk a hangot és a képet attól függően, hogy éppen milyen kódolási rendszert használunk. Az első mozgóképformátumot a szerény elnevezésű Moving Picture Experts Group (Mozgókép Szakértői Csoport, MPEG) javasolta, de azóta más formátumok is megjelentek. Az RFC 3003-ban pedig az audio/basic mellett bevezettek egy új hanghordozótípust, az audio/mpeg-et is, hogy az emberek MP3-hangfájlokat is küldhessenek az e-levelekben. A video/mp4 és audio/mp4 típusok az újabb, MPEG 4 formátumban tárolt mozgóképet és hangot jelzik.
A model típust a többi tartalomtípust követően vezették be. Ennek célja a 3D modelladatok leírása. Mostanáig azonban széles körben nem használják.
Az application egy gyűjtőtípus azon formátumok számára, amelyeket a többi típus egyike sem fed le, és az adatok értelmezéséhez valamilyen alkalmazásra van szükség. Példának a pdf, javascript és zip altípusokat soroltuk fel, amik a PDF-dokumentumokat, JavaScript-programokat és Zip tömörített fájlokat jelzik. A felhasználói ügynökök, ha ilyen tartalmat kapnak, akkor egy harmadik fél által készített függvénykönyvtárat vagy külső programot használnak a tartalom megjelenítésére. A megjelenítés történhet a felhasználói ügynökbe integráltan vagy azon kívül is.
A felhasználói ügynökök a MIME-típusok segítségével képessé válnak új típusú alkalmazástartalmak kezelésére, amint kifejlesztik azokat. Ez számottevő előny. Másrészről viszont, sok új formátumú tartalmat alkalmazások hajtanak végre vagy értelmeznek, ami némi veszélyt rejt magában. Egy tetszőleges végrehajtható program futtatása, amit a „barátoktól” kaptunk a levelezőrendszerben, nyilvánvalóan biztonsági kockázatot jelent. Ez a program sokféle kellemetlen kárt tud okozni a számítógépnek azon részeiben, amihez hozzáfér, különösen, ha írhatja és olvashatja a fájlokat, és használhatja a hálózatot. Kevésbé nyilvánvaló, hogy a dokumentumformátumok is ugyanilyen veszélyt jelenthetnek. Ennek az az oka, hogy az olyan formátumok, mint például a PDF, valójában álruhába bújt fejlett programozási nyelvek. Ezek ugyan értelmezett és hatókörükben korlátozott adatok, azonban az értelmezőben lévő hibák gyakran lehetővé teszik a fondorlatos dokumentumok számára, hogy kijátsszák a korlátozásokat.
Ezeken a példákon túlmenően sok más alkalmazási altípus is létezik, mivel sokkal több alkalmazás is van. Utolsó lehetőségként, ha más, megfelelőbb altípus nem ismert, az octet-stream jelzi a nem értelmezett bájtsorozatot. Az ilyen folyamok fogadásakor a felhasználói ügynök valószínűleg azt javasolja a felhasználónak, hogy fájlban tárolja azt. A további feldolgozás ezután a felhasználóra vár, aki feltehetőleg tudja, hogy miféle tartalom ez valójában.
Az utolsó két típus maguknak az üzeneteknek az összeállításánál és kezelésénél hasznos. A message típus lehetővé teszi egy üzenet teljes beágyazását egy másikba. Ez a séma például a levelek továbbítására használható. Ha egy teljes 822-es RFC formájú levél beágyazódik egy másikba, akkor az rfc822 altípus használandó. Ehhez hasonlóan, a HTML-dokumentumok beágyazása is gyakori. A partial altípus lehetővé teszi egy beágyazott üzenet több darabra tördelését és külön-külön történő átvitelét (például ha a beágyazott üzenet túl hosszú). A paraméterek lehetővé teszik a címzett állomáson a darabok sorrendhelyes összeállítását.
Végül az utolsó típus a multipart, amely lehetővé teszi, hogy egy üzenet több részből álljon, és minden rész eleje és vége tisztán elhatárolható legyen. A mixed altípus lehetővé teszi, hogy minden rész különböző típusú legyen anélkül, hogy a struktúrával szemben bármilyen további követelményt támasztana. Sok levelezőprogramban egy vagy több csatolt állományt is meg lehet adni a szöveges rész mellett. Ezeket a mellékleteket a multipart típus használatával küldik el.
A multipart ellentettje az alternative altípus, melynek segítségével ugyanazt az üzenetet küldhetjük el egyszerre több példányban, de különböző formátumokban. Egy üzenet például elküldhető egyszerre sima ASCII-, HTML- és PDF-formátumban. Egy jól tervezett felhasználói ügynök egy ilyen üzenetet a felhasználó igényeinek megfelelően jeleníti meg. Valószínűleg a PDF volna az első választás, ha ez lehetséges. A második választás a HTML lenne. Ha ezek közül egyik sem lehetséges, akkor marad a sima ASCII-szöveg. Először a legegyszerűbb résznek kell szerepelnie a levélben, majd ezt követhetik az egyre bonyolultabbak, hogy azok a felhasználók is értelmezhessék az üzenetet, ahol nincs MIME-képes felhasználói ügynök (például még egy ilyen régi felhasználói ügynökkel is el lehet olvasni a sima ASCII-szöveget). Az alternative altípus használható több nyelv esetén is. Ilyen környezetben a Rosetta kő egy korai multipart/alternative üzenetnek tekinthető.[34]
A másik két, példaként említett altípus közül az elsőt a parallel altípust akkor használják, ha minden részt egyszerre kell „megjeleníteni”. Például a filmek gyakran két részből, a mozgóképből és a hangból állnak. A filmek sokkal hatásosabbak, ha ezeket a részeiket egyszerre, nem pedig egymás után játsszák le. A digest altípust akkor használják, ha több üzenetet egyetlen összetett üzenetbe csomagolnak össze. Például az interneten néhány vitafórum összegyűjti az előfizetők leveleit, és bizonyos időszakonként szétküldi azokat a csoportnak egyetlen multipart/digest üzenetként.
A 7.14. ábrán a MIME-típusoknak e-levél üzenetekben történő alkalmazására, egy multimédiás üzenetre láthatunk példát. Ebben egy születésnapi köszöntés kerül átvitelre két alternatív formában: HTML és hang formájában. Ha a fogadó képes hangok lejátszására, a felhasználói ügynök le fogja játszani a hangot. Ebben a példában csak egy hivatkozás található a hangra, message/external-body altípusként, ezért a felhasználói ügynöknek először el kell hoznia a hálózatról a birthday.snd hangfájlt FTP segítségével. Ha a felhasználói ügynök nem képes hangok lejátszására, akkor csak a dalszöveg látszik síri csendben. A részeket két kötőjel, és az azt követő a boundary mezőben megadott (szoftveresen előállított) karakterlánc különíti el.
Vegyük észre, hogy a Content-Type fejlécmező háromszor fordul elő ebben a példában. Legfelül arra szolgál, hogy jelezze, az üzenet több részből áll, a részekben pedig azok típusát és altípusát adja meg. Végül a második rész szövegrészében meg kell adni a felhasználói ügynöknek az elhozandó fájl nevét. Hogy érzékeltessük ezt a kis különbséget, itt kisbetűket használtunk a fejlécmezőkben, egyébként minden fejlécmező érzéketlen a kis- és nagybetűk használatára. A Content-Transfer-Encoding fejlécmező ugyanúgy szükséges bármilyen külső szövegtörzs esetén, amely nem 7 bites ASCII-kódolású.
Miután bemutattuk a felhasználói ügynököket és a levélüzeneteket, készen állunk rá, hogy megnézzük, hogyan továbbítják a levéltovábbító ügynökök a leveleket a feladótól a címzetthez. A levelek továbbítását az SMTP-protokoll végzi.
Az üzenetek továbbításának legegyszerűbb módja az, hogy a forrásgép szállítási összeköttetést létesít a célgéppel, majd ezen átviszi az üzenetet. Eredetileg így működött az SMTP. Az évek során azonban az SMTP-nek két eltérő felhasználási módját különböztették meg. Az első a levél feladása (mail submission), ami az e-levél architektúrát bemutató 7.7. ábrán az 1. lépés. A felhasználói ügynökök ezzel küldik be az üzeneteket a levelezőrendszerbe kézbesítés céljából. A második felhasználási mód az üzenetek továbbítása az üzenettovábbító ügynökök között (a 7.7. ábrán a 2. lépés). Ez a sorozat egyetlen ugrással eljuttatja a levelet a küldőtől a fogadó üzenettovábbító ügynökig. A végső kézbesítést különféle protokollok végzik, amelyeket a következő alfejezetben ismertetünk.
Ebben az alfejezetben bemutatjuk az SMTP-protokoll alapjait és kiterjesztési mechanizmusát. Ezután megtárgyaljuk, miben különbözik a levél feladására és az üzenettovábbításra történő használata.
Az interneten belül, az e-levelek kézbesítése úgy történik, hogy a forrásgép TCP-összeköttetést teremt a célgép 25-ös portjával. Ezt a portot egy levelezőszerver figyeli, amelyik az SMTP (Simple Mail Transfer Protocol – egyszerű levéltovábbító protokoll) „nyelvet beszéli”. Ez a szerver fogadja a beérkező összeköttetés-kéréseket, aláveti azokat néhány biztonsági ellenőrzésnek, és átveszi az üzeneteket kézbesítésre. Ha egy üzenetet nem lehet kézbesíteni, akkor a kézbesíthetetlen üzenet első részét tartalmazó hibajelentéssel a feladó visszakapja azt.
Az SMTP egy egyszerű ASCII-protokoll. Ez nem hátrány, csak egy tulajdonság. Az ASCII-szövegek használata megkönnyíti a protokollok fejlesztését, tesztelését és nyomkövetését. A protokollok tesztelhetők a parancsok kézi elküldésével, és az üzenetek bejegyzései könnyen olvashatók. A legtöbb alkalmazási rétegbeli internetprotokoll (például HTTP) ma így működik.
Körüljárunk egy levelezőszerverek közötti üzenetátvitelt, amelynek során egy üzenet kézbesítése történik. A 25-ös porttal való TCP-összeköttetés létesítése után a kliens küldőgép megvárja, amíg a szerver fogadógép meg nem szólal. A szerver azzal kezdi, hogy küld egy sornyi szöveget, amelyben azonosítja magát, és megadja, hogy fel van-e készülve levelek fogadására. Ha nem, a kliens bontja az összeköttetést, és később újra próbálkozik.
Ha a szerver felkészült a levelek fogadására, akkor a kliens megadja, hogy kitől és kinek megy az e-levél. Ha a megadott címzett létezik a célgépen, akkor a szerver szabad utat ad a kliens számára az üzenetküldéshez. Ezután a kliens elküldi a levelet, és a szerver nyugtázza azt. Semmilyen ellenőrző összegre nincs szükség, mivel a TCP-összeköttetés megbízható bájtfolyamot biztosít. Ha van még e-levél, akkor azt is elküldi. Miután mindkét irányban megtörtént az összes e-levélcsere, az összeköttetés lebomlik. A 7.15. ábrán látható egy, az SMTP által használt számkódokat is feltüntető mintapárbeszéd a 7.14. ábrán levő levél elküldéséhez. A kliens (azaz küldő) által küldött sorokat C:, a szerver (azaz fogadó) által küldött sorokat pedig S: jelöli.
A kliens részéről az első parancs valójában a HELO. A HELLO különféle négybetűs rövidítései közül ez számos előnnyel rendelkezik legnagyobb versenytársához képest. Azt, hogy miért kellett minden parancsnak négybetűsnek lennie, már senki sem tudja.
A 7.15. ábrán levő üzenetnek csak egy címzettje van, tehát csak egy RCPT parancs látható. Több ilyen parancsot is ki lehet adni, ha ugyanazon levélnek több címzettje is van. Mindegyikre egyedileg jön nyugta vagy visszautasítás. Még ha néhány címzettől visszautasítás jön is (mert nem léteznek a célgépen), a többieknek akkor is el lehet küldeni az üzenetet.
Végül, a négybetűs parancsok szintaxisa ugyan szigorúan definiált, a válaszoké azonban kevésbé az. Egyedül a számkód számít igazán. Megvalósítástól függően bármilyen karaktersorozat állhat a kód után.
Az alap SMTP jól működik, de több szempontból korlátozott a működése. Nem rendelkezik hitelesítéssel. Ez azt jelenti, hogy a példabeli FROM parancs olyan feladót ad meg, amilyet csak akar. Ez meglehetősen hasznos kacatlevél küldéséhez. Egy másik korlátozás, hogy az SMTP ASCII-üzeneteket továbbít, nem bináris adatokat. Ezért volt szükség a base64 MIME-kódolásra a tartalom továbbításához. Ezzel a kódolással azonban a levéltovábbítás nem hatékonyan használja ki a sávszélességet, ami a hosszú üzeneteknél problémát jelent. A harmadik korlátozás az, hogy az SMTP nyílt szövegként küldi az üzeneteket. Nincs titkosítás, ami egy kissé elrejtené a személyes tartalmakat a kívácsi szemek elől.
Ezeknek, és számos más, az üzenetkezeléshez kapcsolódó problémának a megoldása érdekében az SMTP-t felülvizsgálták és egy kiterjesztési mechanizmussal látták el. Ez a mechanizmus kötelező része az RFC 5321 szabványnak. A kiterjesztett SMTP-t ESMTP-nek (Extended SMTP) nevezik.
Azok a kliensek, amelyek egy kiterjesztést szeretnének használni, kezdetben EHLO üzenetet küldenek HELO helyett. Ha ezt a szerver elutasítja, akkor a szerver egy általános SMTP-szerver, és a kliensnek a szokásos módon kell eljárnia. Ha elfogadja az EHLO-t, a szerver az általa támogatott kiterjesztésekkel válaszol. A kliens ezen kiterjesztések közül bármelyiket használhatja. Néhány gyakori kiterjesztést mutat a 7.16. ábra. Az ábra megadja a kiterjesztési mechanizmus által használt kulcsszót az új funkciók ismertetésével együtt. A kiterjesztéseket bővebben nem részletezzük.
Jobban ráérezhetünk arra, hogy hogyan működik az SMTP és más, a fejezetben ismertetett protokoll, ha ki is próbáljuk azokat. Mint minden esetben, először most is kerítenünk kell egy egy gépet internetkapcsolattal. UNIX- (vagy Linux-) rendszer esetén írjuk be a parancssorba, hogy
telnet mail.isp.com 25
és a mail.isp.com helyébe a saját szolgáltatónk levelezőszerverének DNS-nevét helyettesítsük! Windows XP rendszeren kattintsunk a Start, majd a Futtatás menüpontra, és írjuk be a fenti parancsot a párbeszédablakba. Vistás vagy Windows 7-es gépeken szükséges lehet először a telnet (vagy azzal egyenértékű) programot telepíteni, majd elindítani. Ez a parancs kiépít egy telnet- (azaz TCP-) összeköttetést az adott gép 25-ös portjára. A 25-ös port az SMTP-hez tartozik (a szokványos portokat lásd a 6.34. ábrán). Bizonyára valami ehhez hasonló választ kapunk:
Trying 192.30.200.66…
Connected to mail.isp.com
Escape character is ’^]’.
220 mail.isp.com Smail #74 ready at Thu, 25 Sept 2002 13:26 +0200
Az első három sort a telnet írja ki, hogy elmondja, éppen mit csinál. Az utolsó sor a távoli gép SMTP-kiszolgálójától származik: ebben jelenti be, hogy hajlandó beszélni velünk és fogadni az e-leveleket. Azt is megtudhatjuk, hogy milyen parancsokat fogad el, ha beírjuk, hogy
HELP
Ettől kezdve lehetséges egy olyan parancssorozat, mint amilyet a 7.16. ábrán láthattunk, ha a szerver hajlandó leveleket fogadni.
Eredetileg a felhasználói ügynökök ugyanazon a számítógépen futottak, mint amelyen az üzenetet elküldő üzenettovábbító ügynök. Ebben az elrendezésben a felhasználói ügynöknek az üzenet elküldéséhez mindössze arra van szüksége, hogy felvegye a kapcsolatot a helyi levelezőszerverrel egy olyan párbeszéd útján, mint amilyet az előbb ismertettünk. Ez az elrendezés azonban már nem a szokásos elrendezés.
A felhasználói ügynökök gyakran laptopokon, otthoni PC-ken és mobiltelefonokon futnak. Ezek nem mindig csatlakoznak az internetre. A levéltovábbító ügynökök az internetszolgáltatók és vállalatok szerverein futnak. Ezek mindig csatlakoznak az internetre. Ez a különbség azt jelenti, hogy egy bostoni felhasználói ügynöknek lehet, hogy fel kell vennie a kapcsolatot a seattle-i szabályos levelezőszerverével, ha el akar küldeni egy levelet, mert a felhasználó éppen utazik.
Önmagában ez a távoli kommunikáció nem jelent problémát. Pontosan erre a célra tervezték a TCP/IP-protokollokat. Egy internetszolgáltató vagy vállalat azonban általában nem szeretné bármely távoli felhasználó számára lehetővé tenni, hogy levelezőszerverének segítségével üzenetet küldjön máshová. Az internetszolgáltató vagy vállalat a szervert nem nyilvános szolgáltatásként működteti. Ráadásul, az ilyen nyílt levéltovábbítás (open mail relay) vonzza a kacatlevelet küldőket. Ennek az az oka, hogy lehetőséget biztosít az eredeti feladónak arra, hogy kezei tiszták maradjanak, és így az üzenetet még nehezebb legyen kacatlevélként azonosítani.
Ezen megfontolások alapján az SMTP-t normális körülmények között csak az AUTH kiterjesztéssel együtt használják levélfeladásra. Ez a kiterjesztés megvizsgáltatja a szerverrel a kliens azonosítóit (felhasználónevét és jelszavát) annak eldöntése érdekében, hogy a szervernek kell-e levelezési szolgáltatást nyújtania.
Számos más eltérés is van az SMTP levélfeladásra való használatának módjában. Például az 587-es portot részesítik előnyben a 25-össel szemben, és az SMTP-szerver ellenőrizheti és kijavíthatja a felhasználói ügynök által küldött üzenetek formátumát. Az SMTP korlátozott levélfeladásra való használatáról szóló további információért kérjük, tekintse meg az RFC 4409-et.
Miután a küldő levéltovábbító ügynök megkapta a levelet a felhasználói ügynöktől, kézbesíti azt a fogadó levéltovábbító ügynöknek az SMTP segítségével. Ennek érdekében a küldő a rendeltetési címet használja. Figyeljük meg a 7.15. ábrán látható, bob@ee.uwa.edu.au címre küldendő üzenetet! Melyik levelezőszervernek kell továbbítani az üzenetet?
A megfelelő levelezőszerverrel való kapcsolatfelvétel érdekében meg kell kérdezni a DNS-t. Az előző fejezetben leírtuk, hogyan tárol a DNS különböző típusú bejegyzéseket, beleértve az MX vagy levélcserélő bejegyzést. Ebben az esetben egy DNS-lekérdezés indul az ee.uwa.edu.au körzet MX bejegyzéseiért. A válasz egy rendezett lista lesz, amely egy vagy több levelezőszerver nevét és IP-címét tartalmazza.
A küldő levéltovábbító ügynök ezután létrehoz egy TCP-összeköttetést a 25-ös porton lévő levelezőszerver IP-címére, hogy elérje a fogadó levéltovábbító ügynököt, és az SMTP-t használva továbbítja az üzenetet. Ezt követően a fogadó levéltovábbító ügynök a bob felhasználónak küldött levelet Bob postaládájába helyezi, hogy Bob később elolvashassa azt. Ez a helyi kézbesítési lépés nagy levelezési infrastruktúra esetén esetleg a levélnek a számítógépek közti mozgatásával is járhat.
Ennek a kézbesítési folyamatnak a során a levél a kezdeti levéltovábbító ügynöktől a végső levéltovábbító ügynökig terjedő utat egyetlen ugrással teszi meg. Nincsenek közbenső szerverek az üzenettovábbítási szakaszban. Az azonban lehetséges, hogy ez a kézbesítési folyamat többször is megtörténik. Egy példát már ismertettünk korábban, amikor egy levéltovábbító ügynök egy levelezőlistát üzemeltet. Ebben az esetben az üzenet a lista számára érkezik. Ezután a levelet kiterjesztik a lista minden egyes tagjának szóló üzenetté, azaz elküldik minden egyes tag egyéni címére.
Egy másik példa az átjátszásra a következő. Bob végzett az M.I.T.-n, és a bob@alum.mit.edu címen is elérhető. Ahelyett, hogy mindkét felhasználói fiók leveleit elolvasná, Bob intézkedhet arról, hogy az erre a címre küldött leveleket továbbítsák a bob@ee.uwa.edu-ra. Ebben az esetben a bob@alum.mit.edu címre küldött levél két kézbesítésen esik át. A levelet először az alum.mit.edu levelezőszerverének küldik, azután továbbküldik az ee.uwa.edu.au levelezőszerverének. Mindkét szakasz teljes és egymástól független kézbesítés, abban a levéltovábbító ügynökök érintettek.
Egy másik szempont manapság a kacatlevél. Ma tízből kilenc elküldött üzenet kacatlevél [McAfee, 2010]. Kevesen szeretnének még több kacatlevelet, de nehéz elkerülni őket, mert közönséges levélnek álcázzák magukat. Az üzenet elfogadása előtt további ellenőrzések végezhetők a kacatlevél lehetőségeinek csökkentésére. A Bobnak szánt üzenet az alice@cs.washington.edu-ról lett elküldve. A fogadó levéltovábbító ügynök megkeresheti a küldő levéltovábbító ügynököt a DNS-ben. Ezzel lehetővé válik annak ellenőrzése, hogy a TCP-összeköttetés másik végének IP-címe összeillik-e a DNS-névvel. Még általánosabban, a fogadó ügynök megkeresheti a küldő tartományt a DNS-ben, hogy lássa, van-e annak levélküldési házirendje. Ezt az információt gyakran megadják a TXT és SPF bejegyzésekben. Ez azt jelezheti, hogy további ellenőrzések végezhetők. Például lehet, hogy a University of Washington -ról küldött leveleket mindig a june.cs.washington.edu hosztról küldik. Ha a küldő levéltovábbító ügynök nem june, akkor baj van.
Ha ezeknek az ellenőrzéseknek bármelyike kudarccal végződik, akkor valószínűleg meghamisították a levelet egy hamis feladási címmel. Ebben az esetben a levelet eldobják. Az ellenőrzéseken való átjutás azonban még nem jelenti azt, hogy a levél nem kacatlevél. Az ellenőrzések csupán azt biztosítják, hogy a levél valószínűleg a hálózatnak abból a tartományából érkezett, mint amit magáról állít. Az az elképzelés, hogy a kacatlevelet küldőket rákényszerítsék a helyes feladási címek használatára, amikor levelet küldenek. Ez a kacatlevelet könnyebben felismerhetővé és letörölhetőve teszi, ha nem kívánatos.
Levélüzenetünket már majdnem sikerült kézbesíteni, hiszen már megérkezett Bob postaládájába. Mindössze annyi van hátra, hogy a megjelenítés érdekében az üzenet egy másolati példányát tobábbítani kell Bob felhasználói ügynökéhez. Ez a 7.7. ábrán látható architektúra 3. lépése. Ez a feladat magától értetődő volt az internet korai időszakában, amikor a felhasználói ügynök és a levéltovábbító ügynök ugyanazon a gépen, külön folyamatként futott. A levéltovábbító ügynök egyszerűen hozzáfűzte az új üzeneteket a postaládafájl végéhez, a felhasználói ügynök pedig csak ellenőrizte a postaládafájlt, hogy érkezett-e új levél.
Manapság a felhasználói ügynök egy PC-n, laptopon vagy mobiltelefonon fut, tehát valószínűleg nem az internetszolgáltató vagy vállalat levelezőszerverén, hanem egy másik gépen. A felhasználók távolról is el szeretnék érni leveleiket, bárhol is vannak. Hozzá szeretnének férni leveleikhez a munkahelyükről, az otthoni PC-ikről, a laptopjukról, amikor üzleti úton vannak, és az internetes kávézókból, amikor a szabadságukat töltik. Szeretnének hálózat nélkül dolgozni, majd újra a hálózatra csatlakozni, hogy fogadhassák beérkezett leveleiket és elküldhessék kimenő leveleiket. Sőt minden egyes felhasználó több felhasználói ügynököt futtathat attól függően, hogy éppen melyik számítógépet kényelmes használni. Éppenséggel még több felhasználói ügynök is futhat egyszerre.
Ebben a helyzetben a felhasználói ügynöknek az a feladata, hogy megjelenítse a postaláda tartalmát, és lehetővé tegye a postaláda távolról történő kezelését. Számos különböző protokoll használható erre a célra, de az SMTP nem tartozik ezek közé. Az SMTP küldésalapú (push-based) protokoll. Fog egy üzenetet, majd csatlakozik a távoli szerverhez és továbbítja azt. A végső kézbesítést nem lehet ilyen módon megvalósítani, mert egyrészt a postaládát továbbra is a levéltovábbító ügynöknek kell tárolnia, másrészt a felhasználói ügynök lehet, hogy éppen nem csatlakozik az internetre, amikor az SMTP megpróbálja az üzeneteket neki továbbítani.
A végső kézbesítésre használt egyik legfontosabb protokoll az IMAP (Internet Message Access Protocol – internetes levél-hozzáférési protokoll). A protokoll 4. változatát az RFC 3501 határozza meg. Az IMAP használatához a levelezőszerver egy IMAP-szervert futtat, ami a 143-as portot figyeli. A felhasználói ügynök IMAP-kliensként fut. A kliens kapcsolódik a szerverhez, és elkezdi kiadni a 7.17. ábrán látható parancsokat.
Először is, ha szükséges, a kliens elindít egy biztonságos átvitelt (annak érdekében, hogy az üzeneteket és parancsokat titokban tartsa), és bejelentkezik vagy más módon igazolja hitelességét a szerveren. Miután bejelentkezett, számos parancsot használhat a mappák és parancsok listázásához, üzenetek vagy akár azok részeinek lekéréséhez, az üzenetek későbbi törlésre való megjelölésére és az üzenetek mappákba rendezéséhez. A keveredések elkerülése végett kérjük, jegyezze meg, hogy a „mappa” szót mi itt azért használjuk, hogy a fejezet további tartalma egységes legyen, melyben a felhasználónak egyetlen postaládája van, ami több mappából áll. Az IMAP részletes leírásában azonban e helyett a postaláda kifejezést használják. Tehát egy felhasználónak több IMAP-postaládája van, mindegyik tipikusan mappaként mutatkozik a felhasználónak.
Az IMAP számos más képességgel is rendelkezik. A leveleket például nem csak beérkezésük sorrendjében képes kezelni, hanem attribútumaik alapján is (például „Kérem az első üzenetet Alice-tól”). Kereséseket lehet indítani a szerveren, hogy megtaláljunk bizonyos kritériumoknak megfelelő üzeneteket úgy, hogy a kliensnek csak ezeket az üzeneteket kelljen letöltenie.
Az IMAP a korábbi kézbesítési protokollnak, a POP3-nak (Post Office Protocol, version 3 – postahivatal protokoll, 3. verzió) a tökéletesítése, amit az RFC 1939 határoz meg. A POP3 egyszerűbb protokoll, de kevesebb képességgel rendelkezik és a tipikus felhasználás során kevésbé biztonságos. A leveleket általában letöltik a felhasználói ügynököt futtató számítógépre ahelyett, hogy azok a levelezőszerveren maradnának. Ez könnyebbé teszi a szerver életét, de nehezebbé teszi a felhasználóét. Nem könnyű a leveleket több számítógépen olvasni, és ha a felhasználói ügynököt futtató számítógép tönkremegy, minden e-levél végleg elveszhet. Ennek ellenére a POP3 még mindig használatban van.
Egyedi protokollok is alkalmazhatók, mert a protokoll a levelezőszerver és a felhasználói ügynök között használatos, amelyeket ugyanaz a cég szállíthat. A Microsoft Exchange egy egyedi protokollal rendelkező levelezőrendszer.
Az IMAP-vel és az SMTP-vel szemben egyre népszerűbbek azok a levelezési szolgáltatások, amelyek a világhálót használják felületként a levelek küldésére és fogadására. A széles körben használt webes levelezőrendszerek közé tartozik a Google Gmail, a Microsoft Hotmail és Yahoo! Mail. A webes levelezőrendszer egyik példája azoknak a szoftvereknek (ebben az esetben ilyen a felhasználói ügynök), amelyek a világhálót használók számára szolgáltatást nyújtanak.
Ebben az architektúrában a szolgáltató, a szokásos módon, SMTP-vel levelezőszervereket futtat a 25-ös porton a felhasználók leveleinek fogadására. A felhasználói ügynök azonban itt eltérő. Ahelyett, hogy egy önálló program lenne, ez egy weblapok által nyújtott felhasználói felület. Ez azt jelenti, hogy a felhasználók bármilyen nekik tetsző böngészőt használhatnak arra, hogy hozzáférjenek leveleikhez és új üzeneteket küldjenek.
Még nem tanulmányoztuk a világhálót, de egy rövid ismertető, amelyhez később visszatérhetünk, a következő. Amikor a felhasználó meglátogatja az e-levél szolgáltató weboldalát, egy űrlappal találkozik, ahol megadhatja az azonosítóját és a jelszavát. Az azonosító és a jelszó eljut a kiszolgálóhoz, amely ellenőrzi azokat. Ha a belépés sikeres, a kiszolgáló megkeresi a felhasználó postaládáját, és készít egy weboldalt, amelyen kilistázza a postaláda aktuális tartalmát. Ezt a weboldalt aztán elküldi megjelenítésre a böngészőnek.
A postaláda tartalmát mutató weboldal több elemére is rá lehet kattintani, így az üzenetek olvashatók, törölhetők és így tovább. Annak érdekében, hogy a felületen keresztül reagálni lehessen, a weboldalak gyakran JavaScript-programokat tartalmaznak. Ezek a programok a kliensen futnak helyi eseményekre (például egérkattintás) adott válaszként, ugyanakkor képesek a háttérben üzeneteket fel- és letölteni annak érdekében, hogy előkészítsék a következő üzenetet a megjelenítéshez vagy egy új üzenetet az elküldéshez. Ebben a modellben a levélküldés a normál webes protokollok segítségével, adatoknak egy adott URL-re való elküldésével történik. A webszerver gondoskodik az üzenetnek a korábban bemutatott hagyományos levélkézbesítő rendszerbe juttatásáról. A biztonság érdekében a szabványos internetprotokollok is használhatók. Ezek a protokollok maguknak a weboldalaknak a titkosításával foglalkoznak, függetlenül attól, hogy a weboldal tartalma egy levélüzenet.
[34] A Rosetta kő a British Museumban látható ősi egyiptomi kőtöredék, amely írásos szöveget tartalmaz három nyelven. (A fordító megjegyzése)