Ebben a fejezetben az e-mail fogalmával, és a köré sűrűsödő technológiákkal fogunk ismerkedni. Az e-mail fogalma kicsit homályos, legszélesebb értelemben annyit jelent, hogy valamilyen számítógéphálózaton át küldünk üzeneteket.
Az e-mail története a számítástechnika múltjába vész, hiszen minden többfelhasználós rendszeren volt valamilyen üzenetküldési lehetőség, és a kezdetleges számítógéphálózatok megjelenésével ez távoli gépek között is működött. Akkor még nagyon máshogy működött a levelezés, például alapos helyismeretre volt szükség, ugyanis a címzett postafiókjához vezető utat tartalmaznia kellett a címzésnek, körülbelül mintha a nekünk szóló leveleket Univerzum, Tejútrendszer, Bal hátsó kis csillagrendszer, harmadik bolygó (Föld), északi félteke, Európa, Kárpát-medence, legnagyobb folyómenti város jobb oldala, stb. módon kellene címezni.
Az ARPANET, a ma használt internet ősén kezdődött el a ma ismert levelezési rendszerek fejlődése, 1969-ben. Ahogy az ARPANET terjedt, úgy lett egyre több felhasználó, és úgy lett egyre nehezebben kezelhető a rendszer. A felhasználói tábor képzettségének csökkenése is szükségessé tett egyszerűsítéseket. Megszületett az SMTP, a DNS, a POP3 és seregnyi más hasonló betűszó, és kialakult a ma ismert levelezési rendszer. Ennek működését egy egyszerű levél egyszerű elküldésével mutatjuk be.
Egy levél élete
Történetünkben Alíz, az Alma Kft. dolgozója szeretne üzenetet küldeni Bélának, a Barack Kft. illetékesének. Ehhez szüksége van Béla e-mail címére. Az e-mail cím szabvány szerint két részből áll, a lokális részből és a domainnévből. A két részt a @ karakter (kukac, at, altgr-v) választja el egymástól.
E-mail cím
A lokális rész rendszerint egy felhasználó vagy egy szolgáltatás egyedi azonosítója (kovacs.bela, belus, sakk-lista, stb.), a domainnév pedig annak a számítógépnek a neve, ahol a címzett leveleit kezelik. Természetesen csak egy címzett lehet, és egy címzettnek egy helyre küldhetjük a levelet, tehát az e-mail címben csak egy @ karakter lehet. A szabvány nem engedi az ékezetes betűk használatát sem, sőt, betűkön, számokon, és a - _ . karaktereken kívül semmi mást.
MUA
A következő szükséges eszköz egy levelezőkliens, avagy MUA (Mail User Agent, levél felhasználói ügynök), még egyszerűbben levelezőprogram. Számtalan levelezőkliens létezik, kezdve a minden elképzelhető extrával felszerelt, grafikus felületen működő Thunderbirdtől olyan ősrégi, kevesek által használt, karakteres felületűekig, mint a pine vagy mutt.
Alapvető funkciói közé tartozik a levelek szerkesztése, letöltése, elindítása, megjelnítése. A kiegészítő funkciók közé tartozhat helyesírásellenőrzés, címjegyzékek kezelése, vírusellenőrzés, news/rss kezelése, csoportmunka-funkciók, stb.
Helyi e-mail szerver
Miután Alíz megírta a levelet, a levelezőprogramja elküldi valahová. A kérdés, hogy hová? Elméletben a legegyszerűbbnek az látszik, ha a levelezőprogram megkeresi a címzett leveleit fogadó gépet, és kézbesíti. Sajnos a később tárgyalandó biztonsági megfontolások ezt nem teszik lehetővé. Kénytelenek vagyunk a világ összes, e-mail forgalomban részt vevő számítógépét két csoportra osztani, az e-mail szerverek és a nem e-mail szerverek csoportjára.
A felosztás nem teljesen éles, még bőséggel vannak kivételek, de a lényeg, hogy az e-mail szerver egy, a levelezésre specializálódott számítógép, számtalan szűrő, ellenőrző és tároló funkcióval. Más e-mail szerverek fogadnak levelet tőle, és küldenek neki levelet.
A nem e-mail szerver számítógépek ezzel szemben bizonytalanok, ellenőrizetlenek, és potenciálisan veszedelmesek a józan e-mail forgalomra nézve. Ebbe a kategóriába tartozik minden asztali számítógép és laptop, természetesen. Ezek a páriák önmagukban nem tudnak levelezni, hiszen ahogy egyre súlyosbodik a spam és vírushelyzet, egyre kevesebb helyen fogadják el az ilyen gépekről érkező leveleket.
Ezért az ilyen gépeknek fönntartanak egy dedikált e-mail szervert, amely elfogadja az innen érkező leveleket, és továbbküldi a megfelelő irányba. Az otthonról vagy kisebb cégtől levelezőknek az internetszolgáltató nyújt (kellene, hogy nyújtson) ilyen szolgáltatást, nagyobb cégeknek, mint a példánkban szereplő Alma Kft. van saját e-mail szervere.
SMTP
Levelezőprogramunk és e-mail-szerverünk az SMTP (Simple Mail Transfer Protocol, egyszerű levélküldési protokoll) eljárást használva kommunikál. Ez, mint neve is mutatja, igen egyszerű: annyit tesz lehetővé, hogy egy címzettnek egy levelet elküldjünk. Semmi titkosítás, semmi azonosítás. Lássunk egy példabeszélgetést:
220 mail.cegnev.hu ESMTP PostfixHELO cegnev.hu250 Hello cegnev.huMAIL FROM:<tgeza@cegnev.hu>250 OkRCPT TO:<ugyfel@valahol.hu>250 OkDATA354 End data with <CR><LF>.<CR><LF>Subject: PéldaüzenetFrom: "Teszt Géza" <tgeza@valahol.hu>To: "Kedves Ügyfél" <ugyfel@valahol.hu>Jónapot kívánok!Ez egy próba.Viszontlátásra!.250 Ok: queued as 12345QUIT221 Bye
Dőlt betűvel az SMTP szerver üzenetei láthatók, kövér betűvel pedig a levelezőkliensünk utasításai. Lássunk pár jellegzetességet.
- Címzési anomália
- Az első, hogy akinek ténylegesen küldjük a levelet (RCPT TO: kezdetű sor), és hogy milyen címzettet írunk a levél szövegébe (To: kezdetű sor) az két teljesen különböző dolog. Ez teszi lehetővé mind a Bcc: fejléc használatát, mind a feladó bizonyos mértékű titkosítását. Soha ne bízzunk meg a levélben látható feladóban – könnyen lehet, hogy valaki csak megviccel minket, vagy éppenséggel félre akar vezetni aljas céljainak érdekében.
- ASCII kódolás
- A következő észreveendő részlet, hogy az egész kommunikáció szigorúan szöveges, ezért ha nem szöveget, hanem mondjuk képet szeretnénk küldeni, akkor azt is át kell fordítanunk valahogy szöveggé. Erre szolgálnak az uu vagy base64 kódolók/dekódolók, a több részletből álló üzenetek szervezéséhez pedig a MIME szabvány.
- Fejlécek és üzenet
- A harmadik nevezetesség, hogy az üzenet két részből áll. Először a feladó, a címzett és a levél tárgya jön, utána egy üres sor, majd a levél tartalma. Az első részben a fejlécek vannak, és az itt mutatott háromnál lényegesen több van belőlük. Kideríthető, több-kevesebb hitelességgel, hogy milyen úton járt a levél, milyen vírus/spamszűrésen esett át, milyen operációs rendszerről, milyen levelezőprogrammal, mikor küldték, stb. A fejlécekkel vigyázzunk, hiszen amint látható, az SMTP szerver az üzenet részeként kezeli őket, és semmilyen módon nem változtat rajta, legfeljebb hozzáfűz egy „itt is járt ez a levél” sort, azaz tetszés szerint hamisítható.
- Hibakódok
- A szerver üzenetei mindig egy számmal kezdődnek. Ezek a kódok mindenféle rejtett jelentéssel bírnak, amelyek minket most túlságosan nem érdekelnek. Ha hibaüzenetet kapunk, kiemelt helyen szerepel majd benne egy ilyen szám. A hibaüzenetek viszonylag ritkák, mert az átlag SMTP szerver nagyon makacs, ha el akar küldeni egy levelet, akár hetekig is próbálkozik, és ennyi idő alatt majdnem minden üzemzavar megoldhatő. Amivel találkozni lehet, az a „Címzett ismeretlen”, kicsit kevésbé sűrűn a „Tárterület megtelt” üzenet.
A különböző hátulütők kiküszöbölésére léteznek SMTP kiegészítések, más hátulütőket pedig az SMTP szabvány megsértésével kerülhetünk meg. Ezekről később lesz szó.
Fogadó oldali szerver
A levél sok SMTP szerveren át eljut a címzett szerveréhez. Ha két bonyolult felépítésű szervezet vírusirtóval, spamszűrővel ellátott rendszerből, levelezőlistán át levelez, akár több tucat helyen is járhat a levél, de előbb-utóbb megérkezik. Itt problémába ütközünk: eddig kliens küldte szervernek, illetve szerver küldte szervernek a levelet. Márpedig a szerverekről feltételezhetjük, hogy állandóan működnek. De most az utolsó szerverről egy kliensgépre kellene eljutnia a levélnek, és a kliens gépéről ezt nem tételezhetjük föl. Elméletben megoldás lehetne, hogy az SMTP szerver próbálkozik, amíg teheti, de ez nem megoldás.
A gyakorlatban működő megoldás az, hogy az utolsó szerveren a levél megpihen, és várja a címzettet, aki valamilyen, levélletöltésre vagy olvasásra szolgáló protokollal megközelíti. Ezeknek két fő változata létezik:
- POP3
- Egyszerűségben az SMTP-vel vetekedő protokoll, annyit tud, hogy bejelentkezhetünk, és letölthetjük a leveleinket. Egyszerűsége a nagyszerűsége, hiszen hibamentes, gyors, pontos. Ugyanakkor a levelek ott maradnak a kliensgépen, ahol elveszhetnek, és/vagy nem hozzáférhetőek, ha éppen nem azon gép előtt ülünk.
- IMAP
- Sokkal kiterjedtebb protokoll(család), a levelek szerveren tárolása, rendezése, osztályozása és vizsgálata mellett sokminden másra is alkalmas. Ennek megfelelően a szerveren nagyobb terhelést is okoz, amellett, hogy a levelek is ott foglalják a helyet, de mivel ez általában cél, az IMAP-ot használjuk, ha lehet.
Fogadó oldali MUA
Ez az a pont, ahol a levél élete a legváltozatosabb. Fejléceit kiértékelik (például hogy kért-e visszaigazolást a feladó, vagy hogy milyen karakterkódolással kell értelmezni a levél törzsét), különböző szempontok szerint megszűrik és csoportosítják, mellékleteit letöltik, archiválják, vagy éppenséggel örökre letörlik. Mindenképpen útjának végére ért, és elpihen.
Elméleti alapok - Alapvető beállítások - Alapállapot - Illemtan/Nettikett alapok - Levélírás - Címjegyzék - Titkosítás alapjai - Enigmail beállítása - Enigmail használata - Levelek kezelése - Szótár
© Tomka Gergely, SzSzI