Základy elektronickej pošty v TCP/IP 5

Dokumenty RFC 821 a RFC 822 obsahovali iba rámcové smernice pre formát tela poštovej správy. Znaková sada bola obmedzen


Dokumenty RFC 821 a RFC 822 obsahovali 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 1 000. 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 apod.).
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ť íubovolný binárny súbor do
tvaru, ktorý vyhovoval norme RFC 821.
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.
Rozšírenie MIME zaviedlo tieto nové hlavičkové polia:
MIME-Version: Toto je jediné pole MIME, ktoré nezačína reťazcom "Content".
Položka špecifikuje verziu MIME. DÖvodom zavedenia tohoto kíúčového slova je
zabezpečenie kompatibility, t.j. podía prítomnosti tejto položky v správe
klient rozpozná, že ide o správu rozšírenú podía MIME a verziu MIME, podía
ktorého bola správa rozšírená. V súčasnosti sa používa MIME vezia 1.0. V
budúcnosti mÖžu prísť ďalšie verzie MIME s inými typmi hlavičkových polí.
Správa zostavená podía RFC 2045 až RFC 2049 musí toto hlavičkové pole obsahovať
vždy. Pole musí byť uvedené pred ostatnými hlavičkovými poliami MIME.
Content-Type: Pole popisuje typ dát obsiahnutých v tele správy tak, aby klient,
ktorý túto správu obdrží, mohol zvoliť vhodný spÖsob prezentácie jej obsahu.
Hlavičkové pole špecifikuje charakter obsahu správy pomocou typu a podtypu,
prípadne pomocou doplnkových informácií. Doplnkové informácie sú uvedené za
bodkočiarkou ako parametre v tvare parameter=hodnota. Parametrov mÖže byť za
sebou uvedených aj viacej, ale vždy musia byť oddelené bodkočiarkou. Na poradí
parametrov nezáleží:
Content-Type: typ/podtyp; parameter1=hodnota; parameter2=hodnota...
Typ kíúčové slovo, ktoré určuje o aký typ dát ide a podtyp, je bližšia
špecifikácia obsahu správy. Napríklad hlavičkové pole Content-Type: image/jpeg
informuje príjemcu správy o tom, že obsahom správy je obrázok vo formáte jpeg.
RFC 2045 až RFC 2049 obsahuje niekoíko základných typov. Ďalšie typy mÖžu byť
podía RFC 2048 registrované odoslaním príslušného dokumentu na adresu:
ietf-types@iana.org.
Typy sa rozdeíujú na dve skupiny:
Typy popisujúce typ prenášaných dát:
Text: Tento typ je určený pre posielanie textových informácií. Text je kódovaný
v niektorej z podporovaných znakových sád, znakovú sadu určuje parameter
charset. Jednotlivé znakové sady sú uverejnené na:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets Primárny podtyp je
plain, ktorý označuje neformátovaný text. lApplication: Binárne dáta
pochádzajúce z rÖznych aplikačných programov (databáz, textových procesorov,
tabuíkových kalkulátorov, kompresných programov apod.). Primárnym typom je
neutrálny octet-stream, ďalšou možnosťou je napr. postscript. lImage: Dáta
reprezentujúce (statický) obrázok. RFC 1521 definuje dva základné podtypy, gif
a jpeg. Ďalšie typy sú uverejnené na:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types.
Audio: Telo správy obsahuje zvuk. Primárnym podtypom je basic (mono so
vzorkovacím kmitočtom 8 kHz). lVideo: Obsahom tela správy je video, primárny
podtyp je mpeg.
Model: Modelom sa rozumie reprezentácia troch a viac dimenzionálnych systémov,
v ktorých je možné zaviesť pravouhlú súradnicovú sústavu. Objekt sa skladá z
elementov, ktoré majú medzi sebou definované vzťahy. Model mÖže zah+ňať faktory
ako je sila, rýchlosť, zrýchlenie, hybnosť, čas atď. Primárnym podtypom je
iges, ďalšou možnosťou je napr. VRML. Popisom tohoto typu sa podrobnejšie
zaoberá dokument RFC 2077.
Typy špecifikujúce, že správa sa skladá z niekoíkých častí:
Message: Tento typ umožňuje odoslať e-mailovú správu ako telo inej správy
(rfc822), dlhú správu odoslať ako niekoíko kratších (partial) alebo namiesto
tela správy odoslať informácie, že správa sa nachádza na danom serveri
(external-body). Typy je možné nájsť na adrese:
ftp://ftp.isi.edu/in-notes/iana/assignments/
access-types.
Multipart: Telo správy tohto typu obsahuje niekoíko rÖznych častí. Každá časť
tela začína reťazcom, ktorý je definovaný v parametre boundary (v hlavičkovom
poli Content-Type).
Jednotlivé čiastkové správy nie sú interpretované podía RFC 822. Definovaným
podtypom je aj Multipart/Encrypted, ktorý špecifikuje šifrovanú správu.

Vysvetlivky
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.

NajdÖležitejšie hlavičkové polia
NajdÖležitejšie hlavičkové polia 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. lTo: E-mailová adresa, eventuálne i meno
príjemcu.
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 (Blind Carbon Copy): Tu sa špecifikujú adresy príjemcov kópie, u ktorých
nechceme, aby túto skutočnosť adresát vedel.
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.
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.
Organization: Organizácia, ktorá vlastní počítač, z ktorého bola správa
odoslaná.
Message-ID: Reťazec, ktorým je správa identifikovaná je automaticky generovaný
poštovým programom.
Received: Toto pole vloží do hlavičky každý poštový uzol 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. lReturn-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ť.
Nie všetky uvedené kíúčové slová sú povinné, RFC 822 požaduje položky Date,
From, Bcc alebo To. Záznam v poli Bcc: mÖže byť prázdny, zatiaí čo v poli To:
je požadovaná aspoň jedna adresa.
Rozšírenie MIME zaviedlo tieto nové hlavičkové polia:
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 apod.).
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.
1 0764 / pen









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.