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.

---