Prvé e–mailové systémy boli vyvinuté koncom 60. a začiatkom 70. rokov 20. storočia. Tieto systémy boli prevažne súkromné malé systémy v rámci oddelení, s malou snahou sprístupniť jednotlivým e–mailovým systémom komunikáciu medzi sebou.

Koncom 70. a začiatkom 80. rokov 20. storočia sa stali dostupné verejné e–mailové služby prostredníctvom poskytovateľov AT&T Mail, MCI Mail a CompuServe. Poštové služby týchto poskytovateľov boli väčšinou využívané podnikateľmi a jednotlivcami. Výskumné a akademické e–mailové služby sa vyvinuli do toho, čo sa neskôr stalo Internetom. Pretože služby pre posielanie správ sa stávali populárnejšie a viacej používané, rástla aj potreba vzájomnej interoperability. Ako výsledok toho boli vyvinuté nasledujúce štandardy:

Koniec 90. rokov sľubuje pre elektronickú poštu niekoľko ďalších vývojových krokov:

Toto sú základné vylepšenia e–mailu, pokiaľ sa e–mail má stať prostriedkom pre elektronický obchod. Príkladom takéhoto bezpečnostného opatrenia je PEM (Privacy Enhanced Mail). Pre šifrovanie je možné použiť tiež algoritmus PGP (Pretty Good Privacy).

Obr. 1: Message Handling System (MHS)

UA (User Agent)
V systéme spracovania správ CCITT X.400 je UA aplikačný proces (program), ktorý poskytuje užívateľovi prístup k systému prenosu správ (Message Transfer System – MTS). UA vytvára rozhranie, prostredníctvom ktorého môže užívateľ využívať služby elektronickej pošty. Používateľ ho spúšťa až na základe potreby.

MTA (Message Transfer Agent)
Sú programy, ktoré majú na starosti vlastný prenos správ, nevšímajú si obsah správy. Zaujíma ich predovšetkým adresa príjemcu. Tieto MTA bežia na jednotlivých počítačoch a musia vzájomne spolupracovať. Takto vzájomne spolupracujúce MTA nazývame MTS (Message Transfer Systems).

V modeli X.400 je MTA súčasť systému obsluhy správ (Message Handling System – MHS), ktorá je zodpovedná za ukladanie alebo prenos správ ďalším MTA užívateľským agentom (User Agent – UA) alebo inému autorizovanému príjemcovi. MTA je v prostredí TCP/IP porovnateľný s poštovým agentom (Mail Transfer Agent).

MTS (Message Transfer System)
Proces, ktorý prenáša správy medzi užívateľmi. Za týmto účelom MTS využíva iba vlastné komponenty (MTA). MTS sa vyznačujú tým, že používajú jednotné konvencie a protokoly.

X.400
X.400 je štandard spracovania správ definovaný organizáciou CCITT.

Elektronická pošta je bezpochyby najrozšírenejšia zo všetkých služieb, ktoré Internet ponúka. Každý deň ju využíva veľké množstvo ľudí všetkých možných profesií. Elektronická pošta, ako väčšina služieb Internetu, je založená na modeli klient–server (obr. 2).

Základom elektronickej pošty je existencia tzv. poštovej schránky MAIL BOX, ktorá vychádza z filozofie P.O.BOXu (Post Office Box).

Každý užívateľ má vlastnú elektronickú poštovú schránku (mailbox) (jedinečný adresár pre ukladanie elektronickej pošty) a ostatní užívatelia môžu užívateľovi s touto schránkou posielať e–mailové správy. Tieto správy sa posielajú na e–mailovú adresu.

Obr. 2: Elektronická pošta v prostredí TCP/IP

E–mailová adresa je určená dvojicou údajov:

Pokiaľ je správa uložená v schránke príjemcu, môže užívateľ tejto schránky vyvolať akékoľvek pre neho dôležité alebo zaujímavé správy.

Pokiaľ nejaká e–mailová správa nemôže byť doručená, môže byť dočasne uložená v poštovom úrade (post office). Toto je služba, ktorá umožňuje ukladať správy s možnosťou periodicky kontrolovať, či je príjemca pripravený doručenú poštu prevziať.

Elektronická pošta nie je zaisťovaná nikdy jediným programom, vždy ide o spoluprácu viacerých programov, ktoré sú rôznym spôsobom špecializované napr.: existujú programy, ktoré sa starajú iba o prenos správ, prezeranie správ, vytváranie a ich odosielanie.

Základnými RFC dokumentami, ktoré sa zaoberajú elektronickou poštou, sú:

• RFC 821 [11] – definuje základný model elektronickej pošty a jej prenos pomocou protokolu SMTP,
• RFC 822 [12] – špecifikuje formát textových správ pre elektronickú poštu,
• RFC 1521 [13] – definuje rozšírenie elektronickej pošty MIME, ktoré umožňuje prenos aj iných súborov ako textových.

Telo (body) správy obsahuje vlastný text správy a z pohľadu systému elektronickej pošty nie je nijako štruktúrované – ani užívateľské zložky (UA), ani prenosové zložky (MTA) túto časť správy neinterpretujú (okrem špeciálnych prípadov, ako napríklad pri potrebe konverzie z jednej znakovej sady do druhej).

Naopak hlavička (header) musí byť veľmi presne štruktúrovaná. Hlavička obsahuje informácie, podľa ktorých sú jednotlivé správy odosielané, prenášané a doručované. Každý systém elektronickej pošty (MHS, Message Handling System) musí presne definovať, čo má byť v hlavičke obsiahnuté, a akým konkrétnym spôsobom to má byť vyjadrené. To preto, aby si užívateľské zložky (UA, User Agent) a prenosové zložky (MTA, Mail Transfer Agent) dokázali v hlavičke správy nájsť tie informácie, ktoré potrebujú k svojej činnosti.

Syntaxom hlavičky sa podrobne zaoberá dokument RFC 822 [12].

Hlavička sa musí nachádzať pred telom správy a telo správy musí byť od hlavičky oddelené najmenej jedným prázdnym riadkom (CRLF CRLF). To z toho dôvodu, že všetko, čo nasleduje za prvým prázdnym riadkom, sa považuje za text správy. Hlavičku správy dokument RFC 822 definuje ako postupnosť položiek, ktorým sa v origináli hovorí header fields (polia hlavičky). Každá položka hlavičky musí začínať na novom riadku (na prvej pozícii riadku) a môže pokračovať na ďalších riadkoch (v takom prípade, ale nikdy nesmie začínať od prvej pozície riadku). Každá položka začína nejakým kľúčovým slovom (zakončeným dvojbodkou), ktoré definuje jej význam. Za kľúčovým slovom zakončeným dvojbodkou nasleduje vlastný obsah príslušnej položky. Hranaté zátvorky "[" a "]" majú význam v mene počítača; signalizujú, že meno počítača nemá byť prekladané pomocou DNS (pozri obr. 3). Znak ";" má význam separátora. Používa sa napríklad pri oddeľovaní adresátov v hlavičke v poli To:. Text uzatvorený v oblých zátvorkách "(" a ")" je považovaný za komentár a pri interpretácii niektorých polí hlavičky je ignorovaný. Lomené zátvorky "<" a ">" zase označujú údaje prednostne určené pre poštový program. Napríklad poštovú adresu je možné zapísať aj takto:

• "Bill Gates" <bill@microsoft.com>
  
  
• Bill Gates <bill@microsoft.com>
  
  
• <Bill.Gates@microsoft.com>

Poštový program si potom z toho vezme iba údaje uzatvorené v lomených zátvorkách.

Dokument RFC 822 nepredpisuje povinné poradie jednotlivých položiek hlavičky. Údaje uvedené v hlavičke musia byť kódované v klasickom 7–bitovom ASCII formáte.

Položky hlavičky


Obr. 3: Príklad poštovej správy podľa RFC 822

Najdôležitejšie hlavičkové polia (obr. 3) sú definované v dokumente RFC 822 takto:

From:
E–mailová adresa odosielateľa, prípadne jeho skutočné meno. Pre toto pole existuje veľa formátov zápisu adresy. Jeden z možných zápisov je na obrázku 3.

To:
E–mailová adresa, eventuálne i meno príjemcu.

Cc:
Cc (Carbon Copy) za týmto kľúčovým slovom nasledujú adresy tých používateľov, ktorým sa dáva list alebo správa na vedomie. Jednotlivé adresy sa oddeľujú čiarkou.

Bcc:
Bcc (Blind Carbon Copy) tu sa špecifikujú adresy príjemcov kópie, u ktorých nechceme, aby túto skutočnosť adresát vedel. Toto pole sa pred odoslaním správy zmaže.

Reply–To:
Pole obsahuje adresu, na ktorú sa má odosielateľovi poslať prípadná odpoveď. Môže byť užitočné vtedy, ak máte niekoľko poštových adries, ale pritom chcete dostávať poštu iba na jednu adresu, ktorú používate najčastejšie.

In-Reply-To:
Obsah tohto poľa identifikuje predchádzajúcu korešpondenciu, ktorá je odpoveďou na vašu správu.

Subject:
Stručný popis obsahu správy.

Sender:
Špecifikuje odosielateľa správy (ak je to niekto iný než autor správy, pre ktorého je určená položka From:).

Date:
Dátum odoslania správy, vrátane údajov o časovom posuve vzhľadom k svetovému času.

References:
Obsah tohto poľa identifikuje inú korešpondenciu, na ktorú sa táto správa odkazuje.

Message–ID:
Reťazec, ktorým je správa identifikovaná – je automaticky generovaný poštovým programom.

Keywords:
Kľúčové slová charakterizujúce obsah. Jednotlivé slová sú od seba oddelené čiarkou.

Comments:
Poznámka; komentár.

Encrypted:
Šifrované (zastaralé).

Received:
Toto pole vloží do hlavičky každý poštový uzol (e-mailový server) na ceste medzi stanicami odosielateľa a príjemcu, ktorý sa danou správou zaoberal. Pole obsahuje: názov poštového uzla, číslo (id) správy, čas a dátum, kedy daný uzol správu obdržal, ďalej od ktorého poštového uzla správa pochádza a ktorý transportný software bol použitý k doručeniu správy. Tieto informácie sa uvádzajú z toho dôvodu, aby bolo možné vystopovať, kadiaľ správa išla a hľadať zdroj eventuálnych problémov. Pole Received: sa správne číta zdola nahor. V tomto poli sa môžu vyskytovať nasledujúce slová:

• from – počítač, z ktorého bola správa prijatá,
  
• by – počítač, ktorým bola správa prijatá,
  
• via – fyzická cesta,
  
• with – sieťový alebo poštový protokol,
  
• id – príjemcova identifikácia správy,
  
• for – pre koho je správa určená (napríklad: ak je adresátom bill@microsoft.com, potom sa tu zachováva pôvodný adresát – t.j. bill@microsoft.com).

Return–Receipt–To:
Pokiaľ hlavička obsahuje toto pole, zašle sa po úspešnom doručení do schránky adresáta potvrdenie na uvedenú adresu. Hodnotu takéhoto potvrdenia je treba brať s rezervou, pretože jeho nedoručenie nemusí znamenať, že správa nedorazila na miesto určenia.

X–anything:
Tento reťazec sa používa kvôli implementácii doplnkových vlastností, ktoré zatiaľ neboli uverejnené v dokumentoch RFC, alebo ktoré ani uverejnené nebudú. Príkladom je položka "X–Mailer:", ktorá obyčajne obsahuje typ a verziu poštového programu, z ktorého bola správa odoslaná. Ak poštový program nepozná význam niektorého poľa začínajúceho "X–" mal by ho ignorovať. Ďalšie položky tohoto typu sú napríklad X-Accept-Language:, X-Priority:, X-UIDL a pod.

Resent–
Pri automatickom odovzdávaní správy (napr. vrátení nedoručiteľnej správy) sa pred pôvodné hlavičkové polia vloží reťazec Resent- (napr. Resent-From alebo Resent-Cc a pod.).

Nie všetky uvedené kľúčové slová sú povinné; RFC 822 určuje minimálne požiadavky na hlavičku správy takto:

Date: 26 Aug 76 1429 EDT
From: Jones@Registry.org
Bcc:

alebo

Date: 26 Aug 76 1429 EDT
From: Jones@Registry.org
To: Smith@ Registry.org

Záznam v poli Bcc: môže byť prázdny, zatiaľ čo v poli To: je požadovaná aspoň jedna adresa.

Formát tela správy – rozšírenie MIME

Pôvodný dokument RFC 821 a RFC 822 obsahoval iba rámcové smernice pre formát tela poštovej správy. Znaková sada bola obmedzená základným sedembitovým ASCII kódom a počet znakov v jednom riadku bol obmedzený číslom 1000. To bol aj dôvod, prečo nebolo možné používať pri písaní poštových správ znaky s interpunkčnými znamienkami (ASCII kód takéto znaky neobsahuje). Okrem toho sa elektronická pošta ukázala byť vhodným prostriedkom aj pre prenášanie rôznych binárnych súborov (obrázky, audio, formátovaný text a pod.). Pretože binárny súbor musel mať sedembitový ASCII kód, používali sa rôzne riešenia – externé kódovacie schémy. Napríklad v Unixe sa používali programy uuencode a uudecode, ktoré umožňovali transformovať ľubovoľný binárny súbor do tvaru, ktorý vyhovoval norme RFC 821 [11].

Systémové riešenie bolo dosiahnuté prostredníctvom takzvaných rozšírení MIME (Multipurpose Internet Mail Extensions); ich špecifikácia je obsiahnutá v normách RFC 1521 a RFC 1522. MIME je štandardom, ktorý doplňuje normu RFC 822 a zároveň zabezpečuje spätnú kompatibilitu.

Obr. 4: Príklad poštovej správy podľa RFC 822, RFC 1521 (MIME)


Rozšírenie MIME zaviedlo tieto nové hlavičkové polia (obr. 4):

MIME–Version:
Prítomnosť tejto hlavičky v poštovej správe indikuje, že správa je zostavená podľa noriem RFC 2045 až RFC 2049.

Content–Type:
Špecifikuje typ a podtyp dát posielaných v tele správy (napr.: text, audio, video a pod.).

Content–Transfer–Encoding:
Toto pole špecifikuje typ kódovania, pomocou ktorého je správa transformovaná do formátu, ktorý vyhovuje RFC 821, t.j. do krátkych riadkov v sedembitovom ASCII kóde.

Content–ID:
Identifikácia správy použiteľná v možnom odkaze.

Content–Description:
Textový popis obsahu správy.

Vysvetlivky

RFC (Request for Comments) - Sada článkov, v ktorých sa dokumentujú a zverejňujú štandardy Internetu, návrhy štandardov a obecne odsúhlasené myšlienky.

DNS (Domain Name System) - Systém doménových mien. Distribuovaný hierarchický informačný systém využívaný v IP sieťach, umožňujúci preklad symbolických doménových mien (napr.: www.zoznam.sk) na číselné IP adresy (napr.: 195.85.36.45).

(c) 2004 Ing. Peter Gašparovič - www.pgasparovic.com

Literatúra

[1]  Feiber, W.: Encyklopedie počítačových sítí. Praha, Computer Press, 1996.
[2]  Břehovský, P.: Praktický úvod TCP/IP. České Budějovice, KOPP, 1994 .
[3]  Mrázek, L.: První kroky INTERNETEM aneb Je to na WWW!. České Budějovice, KOPP, 1995.
[4]  Šmrha, P. – Rudolf, V.: Internetworking pomocí TCP/IP. České Budějovice, KOPP, 1995.
[5]  Hejna, L.: Lokální počítačové síte. Praha, GRADA, 1994.
[6]  Falk, B.: Průvodce světem Internetu. Praha, Computer Press, 1995.
[7]  Lhotka, L.: SERVER v INTERNETU. České Budějovice, KOPP, 1997.
[8]  Peterka, J.: Co je čím ... v počítačových sítích. COMPUTERWORLD, 1994, č. 4, 7, 9, 17, 21, 35, 44.
[9]  Sterling, B.: Short History of the Internet. The Magazine of Fantasy and Science Fiction, 1993.
[10]  Dostálek, L. - Kabelová, A.: MIME – Multipurpose Internet Mail Extension. http://info.pvt.net/mime.htm, 1997.
[11]  Postel, J. B.: Simple Mail Transfer Protokol. RFC # 821, August 1982.
[12]  Crocker, D. H.: Standard For The Format Of Arpa Internet Text Messages. RFC # 822, August 1982.
[13]  Borenstein, N. - Freed, N.: MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC # 1521, September 1993.
[14]  Borenstein, N. - Freed, N.: Multipurpose Internet Mail Extension (MIME) Part One: Format of Internet Message Bodies. RFC # 2045, November 1996.
[15]  Rose, M.: Post Office Protocol – Version 3. RFC # 1225, May 1991.
[16]  Rose, M. - Myers, J.: Post Office Protocol – Version 3. RFC # 1725, November 1994.
[17]  Dresslerová, B. - Veselský, J. - Gombik, G.: LINUX Dokumentační projekt. Praha, Computer Press, 1998.
[18]  Šovčík, J.: Login. PC Revue, 1995, č. 4 až 8.
[19]  Palúch, P.: Poznáte LINUX?. PC Revue, 1998, č. 2.
[20]  Rivest, R.: The MD5 Message–Digest Algorithm. RFC # 1321, Apríl 1992.
[21]  Dostálek, L. a kol.: Velký průvodce protokoly TCP-IP Bezpečnost. Praha, Computer Press, 2001.

---