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!
- A Feladó (From) mező a legtöbb esetben nem jelenik meg az üzenet összeállításakor, ezt a szoftver maga kezeli, hiszen többnyire egyetlen postafiókkal dolgozunk az adott alkalmazásban. Ha viszont több postafiókot kezelünk, akkor ez a mező láthatóvá válik, és a listájából kiválaszthatjuk, melyik postafiók nevében akarjuk az új üzenetet elküldeni.
- A Címzett (To) mező egy vagy több e-mail címet vár, akinek vagy akiknek az üzenetet továbbítani akarjuk. Az itt rögzített címzetteket elsődleges címzetteknek is nevezzük. Alkalmazástól függ, hogy a címeket vesszővel vagy pontosvesszővel elválasztva kell-e felsorolnunk.
- A Másolat vagy Másolatot kap (Cc vagy Carbon copy) mezőben azoknak az e-mail címét adjuk meg, akiknek tájékoztatásul vagy más indokból szintén el akarjuk küldeni az üzenetet. Ezektől a címzettektől emiatt többnyire nem is várunk el reakciót, vagy bármiféle választ, ugyanakkor egyes levelező alkalmazások az ilyen címzettű üzeneteket másképp jelzik a címzettek számára. Mind a Címzett, mind a Másolatot kap szerkesztőmezőkbe kerülő címzettek a beérkezett üzenet fejlécében látni fogják, hogy rajtuk kívül még kik kapták meg az üzenetet.
- Nem úgy a Titkos másolat (Bcc vagy Blind carbon copy) mezőbe kerülő címzettek esetében. Az ide kerülő címzettek csak saját magukat látják címzettnek. Megtehetjük tehát, hogy csak ebbe a mezőbe viszünk be címeket, így egyik címzett sem fogja látni, kik kapták még meg az üzenetet.
Á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.
- A Tárgy (Subject) mezőbe az üzenet témáját kell begépelnünk, lehetőleg minél tömörebben. Ez azért javasolt módszer, mert a levelező alkalmazások az üzenet néhány adatát, köztük a tárgyat jelenítik csak meg a Beérkező levelek mappában. A tömör megfogalmazással a címzettek hamar átfésülhetik üzeneteiket, ami a képernyőolvasó alkalmazásokat használóknak is jelentős könnyebbség. Kitöltése elmaradhat, de a legtöbb alkalmazás rákérdez, hogy valóban így akarjuk-e elküldeni az üzenetet. A Tárgy mezőt az üzenet célba juttatására és más jellemzők megadására is felhasználhatjuk, illetve felhasználják az üzenetkezelő alkalmazások: a válaszlevél tárgyát kiegészíti Re:, a továbbítottét az FW:, vagy ha egy szervezetnek küldünk üzenetet, a Tárgy elejére beszúrhatjuk a To: vagy Címzett: szócskát, hogy pontosan kinek szánjuk a levelet; a víruskereső alkalmazások a [Spam] szócskát szúrják be a Tárgy elejére, jelezve a küldemény levélszemét voltát.
- Üzenetünket a levél törzsébe (message body) gépeljük. Levelező rendszertől függ, mekkora lehet az üzenet mérete – ebbe a korlátba azonban nem szoktunk belefutni, hiszen egy hosszabb tartalmat célszerű fájl mellékletként az üzenethez csatolni.
- A levél törzsét kiegészíthetjük egy vagy több fájllal, melléklettel vagy csatolmánnyal (attachment). Az alkalmazások a csatolmányt vagy a levéltörzs részeként jelenítik meg, a levél szövegébe ágyazva, vagy külön mezőként jelenítik meg azt. A csatolmány típusa, száma és mérete a szabványokban nincs korlátozva, a különféle levelező rendszerek azonban számos típus-, szám- és méretbeli korlátozásokkal élhetnek.
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?
- A típusbeli korlátozás azt jelenti, hogy nem csatolhatunk futtatható, programként funkcionáló fájlokat. A Windows 10 rendszerben ilyennek számítanak az EXE, MSI, CMD, VBS, COM, BAT, az Androidon az APK, macOS-en az APP és az OSX, iOS-en az IPA kiterjesztésű fájlok. Ha mégis ez a célunk, akkor csomagoljuk be azt egy jelszóvédett tömörített fájlba, és azt csatoljuk az üzenethez. A praktikus megoldás egy felhőtárhely vagy más megosztás használata, feltöltve a küldendő fájlokat, majd az üzenetben a megosztás címét megadva.
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.
- Méretbeli korlátozással biztos sokan találkoztak már, hiszen számos rendszer tiltja az 5MB, 20-25MB vagy annál nagyobb fájlok csatolását. Erre a problémára szintén a megosztások használata a megoldás.
- A számbeli korlátozás nem elsősorban a darabszámra utal, hanem a csatolt fájlok összméretére kell figyelnünk. Nyilván, ha sok-sok fájlt szeretnénk elküldeni, és jelentősebb méretkorlát sem állja utunkat, akkor célszerű egy fájlba csomagolni azokat a csatolás előtt, vagy egy megosztásban elérhetővé tenni azokat.
Összefoglalás
Végül foglaljuk össze az elektronikus levelek mezőivel kapcsolatos ismereteket!
- Az elektronikus levél (message) nem más, mint egy szabványos felépítésű, szerkezetű fájl.
- 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 mezők szabványos névvel (header field name) és tartalommal (header field body) rendelkeznek.
- A felhasználó által kezelt mezők a következők: Feladó (From), Címzett (To), Másolat (CC vagy Carbon copy), Titkos másolat (Bcc vagy Blind carbon copy), Tárgy (Subject), a levél törzse (message body) és a melléklet (attachment).
- A levéltörzs formátuma lehet egyszerű szöveg (plain text), HTML (HyperText Markup Language) vagy RTF (Rich Text Format).
- Az üzenetek része, hogy mely karakterkódolási szabvány szerint íródott. Azonban az üzenet készítésekor és továbbításakor felléphetnek olyan konverziók, értelmezési problémák, aminek eredményeként az üzenet tárgya, törzse és a melléklet fájlneve a címzettnél értelmezhetetlen zagyvaságnak tűnik.
- A csatolmányok küldését a szabvány nem korlátozza, azonban a levelező rendszerek számos típus-, szám- és méretbeli korlátozással élhetnek.
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!