E-mail mezők (#312)

 Frissítve: 2021 március 10.

Miről szól ez a cikk?
Mielőtt egyetlen elektronikus levelet fogadnánk vagy küldenénk, nem árt összefoglalni, hogy egy elektronikus levél milyen mezőkből áll, melyiket miért, hogyan, és mely esetekben kell kitölteni. Már csak azért sem lesznek haszontalanok ezek az ismeretek, mert könnyebben, gyorsabban és tudatosabban kezelhetjük leveleinket, illetve előzhetünk meg tipikus hibákat.

Tartalomjegyzék

Nem meglepő módon az elektronikus levelek formátumát nemzetközi szabványok rögzítik. Az üzenetkezelő alkalmazások pedig ezekhez igazodnak, legyenek azok üzenetforgalmazó kiszolgálók vagy levelező ügyfél alkalmazások vagy webappok. Ebben a cikkben azokat az elemeket v esszük sorra, amikkel hétköznapi felhasználóként találkozni szoktunk.

A levelező rendszer szempontjából egy elektronikus levél (message) nem más, mint egy szabványos felépítésű, szerkezetű fájl. Mi ezt a fájlt nem látjuk, közvetlenül nem is kezeljük, hiszen ezt a levelező alkalmazás elrejti előlünk. Mi csupán azokat a szabványban előírt kötelező és opcionális mezőket töltjük ki, amelyekkel levelünk megtelik tartalommal és kézbesíthetővé válik. Ezen jellemzők egy része mindenki számára magától értetődő, mint például a címzett vagy a tárgy. Ugyanakkor a levél törzsének HTML vagy szöveg formátuma, esetleg a szöveg írásához használt karakterkészlet kódolása már nem annyira ismert jellemző. Cikkünkben először sorra vesszük a levél részeit, majd igyekszünk egyikről másikról kicsit több érdekességet és hasznos tudnivalót összefoglalni.

1. Az e-mail részei

Egy elektronikus levél két részből áll: a fejlécből (header) és a törzsből vagy tartalomból (body).

A fejléc számos mezőt (field) tartalmaz, amelyek egy részét, mi felhasználók, közvetlenül elérjük és kezeljük (látjuk, leolvashatjuk, megadhatjuk és módosíthatjuk tartalmukat), míg a többit a levelező rendszer kezeli, és többnyire elrejti előlünk, vagy csak közvetetten értesülünk róluk (például az üzenet elküldésének és fogadásának dátuma vagy a levéltörzs kódolása).

A mezők szabványos névvel (header field name) és tartalommal (header field body) rendelkeznek. A kettőt az üzenetfájlban kettőspont választja el. A mezők nevét a levelező alkalmazások a felhasználó saját nyelvére fordítva vagy más szempontok szerint ugyan szabadon módosíthatják az alkalmazás felületén, de a kész üzenetben a szabványos elnevezéseket kell használniuk.

A levél tartalmát a felhasználó adja meg, vagy egy automatikus levélküldésre képes alkalmazás állítja be az előre beállított tartalmat.

A fejléc mezői az üzenetfájlban soronként követik egymást, majd ezeket követi a levél törzse. Egy-egy mező sorhossza kezdetben 78, a mai szabványok szerint már 998 karakter lehet.

Tipp: No persze, ne gondoljuk, hogy ez valódi akadály például sok száz vagy ezer címzett megadásához. Nem véletlenül emeltük ki a sorhossza szót, ugyanis a szabvány soronként korlátozza azok hosszát. Ha sok a címzett, akkor újabb és újabb sorokban lehet folytatni a címzettek felsorolását – ezt hívja a szabvány folding-nak, hajtogatásnak. Ez nekünk felhasználóknak sem jelent tehát korlátot, hiszen a hajtogatásról a levelező alkalmazás maga gondoskodik.

2. A fejléc felhasználó által kezelt mezői

Egy elektronikus levélnek vannak kötelező elemei, amiket küldés előtt mindenképpen meg kell adnunk, illetve célszerű, illik megadnunk. Nézzük, melyek ezek!

Álljunk meg egy szóra!
Az üzenet elküldéséhez legalább egy e-mail címet meg kell adnunk a Címzett, a Másolatot kap vagy a Titkos másolat mezőben.

Tipp: Az e-mail cím több forrásból is származhat: begépelhetjük emlékezetből, eközben a legtöbb alkalmazás a korábban már használt e-mail címet felismerve, felkínálhatja azt, illetve kiválogathatjuk azt a levelező alkalmazás részét képező címtárból és/vagy névjegyalbumból. Terjed az a megoldás is, hogy a Címzett szerkesztőmezőre lépve, vagy egérrel belekattintva megkapjuk a legutóbbi címzettek listáját.

Tipp: A Címzett, Másolatot kap és Titkos másolat mezőkbe nem csak e-mail cím, hanem úgynevezett terjesztési csoport vagy elosztólista neve is kerülhet. Alkalmazástól függ, hogy lehetőségünk van-e tetszőleges számú elektronikus levélcímet egy névvel ellátott terjesztési csoportba foglalni. A küldés előtt az alkalmazás kibontja a csoport címeit, és az e-mail címeket az alkalmazás szabályai szerint helyezi be a mezőbe.

Ezek azok a mezők, amelyekkel minden levelező alkalmazásban találkozhatunk. A mindennapokban mindössze a Címzett és a Tárgy mezőket, valamint a levél törzsét szoktuk kitölteni, esetleg csatolmánnyal kiegészíteni. Mégis érdemes még egy kicsit elidőzni a Tárgy, a levéltörzs és a csatolmány mellett, mert igen furcsa jelenségekkel és korlátozásokkal szembesülhetünk, és nem árt tisztában lenni néhány tulajdonságukkal.

3. A levéltörzs formátuma

Az első levelező alkalmazások még csak szöveges tartalmat voltak képesek továbbítani, vagyis a levéltörzs csak karaktereket tartalmazhatott. Ez akkoriban nem jelentett problémát, hiszen az akkori szöveges felhasználói felületű operációs rendszerekben nem volt mód másféle tartalom kezelése.

A grafikus felhasználói felületek terjedésével igény lett tetszőleges tartalom továbbítására. Így terjedhettek el a HTML (HyperText Markup Language) és az RTF (Rich Text Format) formátumot kezelni képes levelező rendszerek. A HTML formátumú levéltörzset a legtöbb levelező alkalmazás helyesen jeleníti meg, míg az RTF formátumot célszerű a Microsoft saját rendszerei közötti levelezésre használni. A levelező alkalmazások többnyire a HTML formátumot részesítik előnyben, illetve állítják be alapértelmezettként. Ha valakinek ez gondot jelent, például a látássérült sorstársaink esetében, akkor a partnereinek célszerű jeleznie, hogy az úgynevezett egyszerű szöveg (plain text) formátumot állítsák be, illetve lehetőség szerint ne használjanak szövegen kívül mást az üzenetükben.

A levelező alkalmazásokban beállíthatjuk, hogy a három formátum közül melyiket akarjuk alkalmazni, illetve üzenetenként is módosíthatunk a formátumon.

4. A levéltörzs kódolása

Az internetes elektronikus levelezést 7-bites ASCII karakterkódolásra (és ahogy írtuk, egyszerű szöveg formátumúra) tervezték. A fejlődés nem állt meg, így a mai levelező rendszereket már felkészítették az úgynevezett 8 és 16 bites Unicode UTF karakterkódolási szabványok kezelésére is. Ennek ellenére számtalan esetben tapasztalhatjuk, hogy a tárgy és a levéltörzs szövege (illetve a csatolmány fájlneve) olvashatatlan halandzsa. Ennek oka kettős: egyrészt a különböző architektúrákon, operációs rendszereken más-más karakterkészletben íródhatott az üzenet, mert például nem az egységes Unicode szabvány szerinti kódkészletet használták, másrészt ugyanez lehet az ok az idegen nyelvű üzenetek esetében is. Az üzenetnek ugyan része a használt karaktertábla vagy kódkészlet, ami az üzenet összeállításakor lesz az alkalmazás része a szabvány előírásainak megfelelően, ennek ellenére adódhatnak értelmezési, konverziós problémák.

A levelező alkalmazások ugyan megpróbálnak igazodni az üzenet formátumához, de számos esetben (helyi kódkészlet hiánya), ez sikertelen lesz. Ilyen esetben meg lehet kérni a feladót, hogy próbálja csak az ASCII kódtábla betűit használva megismételni az üzenetet vagy a címzett nyelvi beállításait használva megírni azt.

Tipp: Hasonló jelenséget tapasztalhattak a korai mobil- és okostelefon tulajdonosok SMS küldéskor, amikor határokon átnyúló, vagy más GSM rendszerekbe irányuló rendszerekbe és/vagy más gyártó termékét használónak szólt az üzenet. A kezdeti években a grafikus hangulatjelek küldése és fogadása sem volt problémamentes, hiszen az eltérő gyártók más-más jelet jeleníthettek meg a képernyőn. Ez a probléma mára megoldódott az egységes Unicode karakterkészlet és a szintén szabványosított hangulatjelek bevezetésével. Így ma már például az Android és az iPhone operációs rendszerek között is helyesen jelennek meg a különféle üzenetek.

A folyamatos szabványosítási törekvéseknek köszönhetően ma már igen ritkán találkozhatunk ezzel a problémával.

5. A csatolmányról

Ejtsünk néhány szót a csatolmányról! Említettük, hogy ugyan a szabványban nincs korlátozás a használatukat illetően, a levelező rendszerek, az ISP szolgáltatók, de még maguk az alkalmazások és kiszolgálók mégis számos típus-, szám- és méretbeli korlátozással élhetnek, a levélforgalom szabályozott mederben tartásához. Mit jelentenek ezek a korlátozások a mindennapokban?

Tipp: A jelszóvédelem azért szükséges, mert a levelező rendszerek képesek belekukkantani a tömörített RAR, ZIP stb. fájlokba, veszélyes tartalom után kutatva. Arra is ügyelnünk kell, hogy a jelszóvédelem terjedjen ki a fájlnevekre is, ugyanis alapesetben számos tömörítő alkalmazás a jelszóvédelem ellenére a tömörített fájlban lévő fájlnevet nem titkosítja! A tömörítő alkalmazásoknak ezt a kívánságot sok esetben külön jelezni kell.

Összefoglalás

Végül foglaljuk össze az elektronikus levelek mezőivel kapcsolatos ismereteket!

VÉGE.

Infopanel
Készült: 2021 március 10.
Operációs rendszer: Windows 10 (20H2, 2010b19042)
Szint: kezdő, ECDL: M02/S1/4.3
Kategória: Online alapismeretek → Kommunikációs fogalmak → E-mail fogalmak

Mennyire találtad hasznosnak ezt a cikket?

Válassz egy csillagot!

Szavazatszám: 0, Átlag: 0

Még nem szavazott senki! Legyél az első, aki értékeli ezt a bejegyzést!

Sajnálom, hogy ez a cikk nem volt hasznos számodra!

Segíts nekem, hogy jobb legyen ez a cikk!

Írd le, mit hiányolsz ebből a cikkből!