Textová povaha poštovních zpráv

Elektronická pošta v Internetu sloužila od samého počátku k zasílání textových zpráv. Zpráva se skládala ze slov a vět a dělila se na řádky. Jazykem zpráv byla angličtina a znakový soubor byl vymezen kódovou tabulkou US-ASCII.

Pomocné informace pro efektivní a bezpečné zasílání a příjem dopisů byly umístěny v záhlaví dopisu. Záhlaví se skládá z dohodnutých názvů hlaviček a jejich hodnot. Názvy hlaviček pocházejí rovněž z angličtiny. Jsou to vlastně klíčová slova nebo zkratky slov, které jsou čitelné a srozumitelné uživateli elektronické pošty.

Příkazy pro odesílání dopisů a odpovědi na ně jsou rovněž slovy nebo zkratkami slov v angličtině.

Při běžném používání elektronické pošty se zajímáme o vlastní obsah dopisů a nestaráme se o podrobnosti jejich záhlaví, natož pak o příkazy, které používá odesílající poštovní server. Prostudujeme-li však blíže možnosti záhlaví dopisu a příkazy pro přenos, objeví se textová podoba poštovních zpráv v její úplnosti.

Z poštovní zprávy v jejím zdrojovém (textovém) tvaru můžeme získat řadu užitečných informací, které lze využít v problémových situacích nebo při studiu elektronické pošty jako komunikačního systému.

I volně přístupné webové poštovní systémy mívají prostředky pro zobrazení dopisu v textové formě. Ikony, kterými se zdrojová forma vyvolá, nebývají zvýrazněné. Někdy možnost zobrazení zdrojového tvaru dopisu úplně chybí.

Formát textových zpráv

Již v r. 1982 byl zveřejněn dokument RFC 822, který na dlouhou dobu určil závazný formát textových zpráv přenášených v Internetu. Zpráva se skládá z řádek textu v kódu ASCII zakončených znaky konce řádku (CRLF). Tvoří ji záhlaví a tělo (které může být i prázdné). Záhlaví je od těla odděleno prázdným řádkem; prázdný řádek obsahuje jen znaky CRLF.

Záhlaví textové zprávy

Záhlaví je tvořeno jednotlivými hlavičkami. Hlavička se skládá z klíčového slova (název hlavičky), které je od obsahu hlavičky odděleno dvojtečkou. Obsah hlavičky je buď volný (např. Subject) nebo formátovaný (např. From). Název hlavičky a její obsah se většinou umístí do jedné řádky. Jestliže ne, pak pokračování obsahu hlavičky začíná bílými znaky (tabulátor, mezera) na dalším řádku. Formátování obsahu hlavičky má sloužit k ulehčení zpracování zprávy na počítači.

Jednotlivé hlavičky sdružuje RFC 822 do skupin podle významu.

Cesta

Return-Path: adresa, odkud zpráva přišla.

Received: záznam poštovního serveru o příjmu zprávy (odkud, kým převzata, kdy, protokol, jedinečné označení zprávy příjemcem, pro koho). 

Odesílatel

From: od koho, adresa autora zprávy.

Sender: odesláno kým, adresa skutečného odesilatele. 

Příjemce

To: prvotní příjemce zprávy.

Cc: druhotní příjemci zprávy.

Bcc: další příjemci zprávy, jejichž adresy se neobjevují v záhlaví zpráv pro

prvotní a druhotné příjemce.   

Volitelné hlavičky

• Message-ID: představuje jedinečné označení zprávy na cestě od odesilatele k příjemci. Slouží jako odkaz na zprávu. Třebaže je zařazena mezi volitelné hlavičky, je její užívání prakticky nezbytné.
• Resent-xxx: skupina hlaviček upřesňujících přijatou a znovuzasílanou zprávu (xxx představuje obvyklé hlavičky původní zprávy – from, to, date, aj.).
• In-Reply-To: obsahuje identifikátor původní zprávy, na kterou nová zpráva odpovídá. Hlavička může obsahovat více identifikátorů v případě „odpověď na odpověď“.
• References: obsahuje identifikátor původní zprávy, na kterou nová zpráva odpovídá nebo na niž odkazuje.
• Keywords: slova nebo slovní spojení v uvozovkách, oddělená čárkou.
• Subject: téma zprávy, v praxi povinná neprázdná hodnota.
• Comments: komentář k obsahu zprávy.

Comments: To: "eahil-l@spriwww.spri.se" <eahil-l@spriwww.spri.se>, "eahil-board@spriwww.spri.se" 



<eahil-board@spriwww.spri.se>

Uživatelské hlavičky

Tyto hlavičky určuje uživatel. Nesmějí být definovány v žádné rozšiřující specifikaci. Začínají vždy řetězcem "X-".

Tělo textové zprávy

Tělo se skládá z řádek textu v kódu ASCII zakončených znaky konce řádku (CRLF). Podle RFC 821 je maximální délka řádku dlouhá 1 000 znaků, včetně znaků CRLF. Žádné vnitřní členění těla není předepsáno.

Poštovní adresa a schránka (RFC 2821)

Adresa může označovat poštovní schránku (adresa jednotlivce) nebo skupinu. Adresu lze nakonec vyjádřit vzorcem: lokální-část@doména. Skupinovou adresu lze vyjádřit vzorcem: fráze:[označení_poštovní_schránky];.

Adresa jednotlivce může být jednoduchá ve tvaru

Příklad adresy skupiny: novaci:

Skupinové jméno uživatele je "novaci" a skupinu tvoří tři uživatelé se jménem novakx. Jméno skupiny je odděleno dvojtečkou od adres jednotlivců a celá skupinová adresa je zakončena středníkem.

Známým příkladem skupinové adresy je: "undisclosed-recipients:;". Tato obsahuje jen skupinové jméno ("fráze") a část "poštovní schránka" je prázdná, tj. není uvedena žádná adresa jednotlivce.

Jména v adrese před výrazem v ostrých závorkách neslouží k místnímu směrování, hrají jen pomocnou úlohu pro uživatele. Místní směrování je řízeno jen výrazem v ostrých závorkách.

Doménová část adresy musí být doménové jméno nebo doména. IP adresy se, až na výjimky, nepoužívají.

Poštovní schránce obvykle odpovídá určitý adresář nebo soubor v souborovém systému. V RFC 2821 se říká, že výrazy "poštovní adresa" a "poštovní schránka" lze zaměňovat.

V praxi se stává, že umístění poštovní schránky nemusí být uživateli známé a dostupné jinak než pomocí poštovního klienta. Byly zavedeny pojmy pro označení vzdálené a místní poštovní schránky.

V unixových systémech existuje poštovní schránka společná pro všechny uživatele pošty na daném počítači, která se nazývá systémová poštovní schránka, a soukromé schránky jednotlivých uživatelů v jejich domovských adresářích. Uživatel má možnost zprávu ze systémové schránky odebrat a přesunout do soukromé schránky nebo ji v systémové schránce po přečtení ponechat.

Zvláštním případem je adresa Postmaster@domain. Je určena správci poštovního systému. Zápis místní části není citlivý na velká/malá písmena.

Souhrnný příklad zprávy (některé hlavičky vynechány)

Received: from vse.vse.cz ([146.102.16.2])

by cibetka.vse.cz (Lotus Domino Release 6.5.4FP3)

with ESMTP id 2007041717401102-2028 ;

Tue, 17 Apr 2007 17:40:11 +0200 

Received: by vse.vse.cz (Postfix)

id C7EC313437; Tue, 17 Apr 2007 17:40:05 +0200 (CEST)

Delivered-To: pinkas@vse.cz

. . .

Received: from ns.stk.cz (ns.stk.cz [195.113.71.229])

by vse.vse.cz (Postfix) with ESMTP id 69BD513401

for <pinkas@vse.cz>; Tue, 17 Apr 2007 17:40:03 +0200 

(CEST)

Received: from fw.stk.cz (fw-e1.stk.cz [195.113.71.238])

by ns.stk.cz (Postfix) with ESMTP id 2D4CF171506

for <Pinkas@vse.cz>; Tue, 17 Apr 2007 17:06:17 +0200 

(CEST)

Received: from gw.stk.cz (gw.stk.cz [195.113.71.203])

by fw.stk.cz (Postfix) with ESMTP id 25474310062

for <Pinkas@vse.cz>; Tue, 17 Apr 2007 17:06:17 +0200 

(CEST)

Received: from PC185672166012 (nblindas.stk.cz [10.215.199.201])

by gw.stk.cz with ESMTP; Tue, 17 Apr 2007 17:06:02 +0200

From: =?iso-8859-2?Q?Linda_Skolkov=E1?= <l.skolkova@stk.cz>

To: "'Otakar Pinkas'" 

Přenos zpráv a protokol SMTP

K přenosu textových zpráv mezi odesílatelem a příjemcem slouží protokol SMTP (viz RFC 821). Využívá služeb zabezpečeného spojení (TCP). Odesílající strana zasílá přijímající straně příkazy a samotnou zprávu a dostává odpovědi ve formě čísel s doprovodným textem. Zprávy mohou obsahovat pouze znaky z první poloviny ASCII tabulky vyjádřitelné v sedmibitovém kódu. Přenos se uskutečňuje v rámci SMTP relace. Zpráva vytvořená podle RFC 822 se vloží do SMTP obálky, která řídí doručování zprávy, ale koncovému příjemci se nezasílá.

SMTP relace

SMTP relace je komunikace typu klient/server. Klient je odesilatelem a server příjemcem. Po počátečním navázaní spojení a odpovědi serveru se klient představí a zasílá své příkazy a přijímá odpovědi serveru. V určitém okamžiku odešle vlastní zprávu. Jedná se vlastně o dialog řízený klientem. Jestliže není cílový server přístupný, je možno požádat o zprostředkování další SMTP server. Příkazy odesilatele nejsou citlivé na velká malá/písmena. Nicméně je vhodné dodržovat velikost písmen v lokální části adresy. Doménová jména nejsou rovněž citlivá na velká/malá písmena.

Poštovní transakce je tvořena třemi příkazy:

odesilatel: MAIL FROM: <adresa_odesilatele>

odesilatel: RCPT TO: <adresa_příjemce>

odesilatel: DATA

Zasílání příkazů závisí na stavu serveru. Na jednotlivé příkazy klienta může server odpovědět kladně nebo záporně. Další příkazy lze zadávat tehdy, když přijde kladná odpověď. Příkazy jsou vždy ukončeny znaky . Jestliže jsou příkazy syntakticky nesprávné, lze je opravit a v dialogu pokračovat.

Příkaz RCPT TO: lze opakovat pro různé příjemce. Mají-li příjemci poštovní schránku na stejném počítači, lze vlastní dopis v části DATA odeslat jen jednou.

Dvojice MAIL FROM a RCPT TO (včetně hodnot) tvoří SMTP obálku, která se skládá z adresy odesilatele a adresy příjemce.

Příkaz DATA označuje začátek vlastní zprávy, která je vložena na novém řádku za tímto příkazem. Konec zprávy se vyznačuje tečkou na první pozici posledního řádku, za níž následuje jen znak konce řádku.

Viděli jsme, že zpráva má strukturu záhlaví, prázdná řádka, tělo. V tomto pořadí se jednotlivé části skutečně zasílají.

Odesílající program musí zkontrolovat, zda se ukončující řádek zprávy nenachází náhodou před vlastním koncem zprávy. Jestliže ano, musí ukončující tečku zdvojit. Program příjemce ji musí zase odstranit.

Příkazy MAIL FROM: a MAIL TO: jsou obdobou hlaviček From: a To: ze záhlaví dopisu. Jestliže je lokální část adresy příjemce v RCPT TO: nesprávná, SMTP server svému protějšku oznámí chybu a klient transakci ukončí, čímž ušetří zbytečné odeslání zprávy. Zná-li správnou adresu příjemce, může zprávu poslat dále (RFC 821, forwarding - odst. 3.2).

Pomocí příkazu HELO se klient představí a příkazem QUIT relaci ukončí. Příkaz NOOP slouží jen k udržování spojení a RSET ruší aktuální relaci, ale neukončuje navázané spojení mezi klientem a serverem.

Příkazy HELO, MAIL, RCPT, DATA, NOOP a QUIT jsou povinné.

Příklad relace

#?-:nbsp;

Symboly S: a K: označují server (příjemce) a klienta (odesílatel).

S: 220 vse.cz ESMTP CommuniGate Pro 4.1.8

K: HELO n412h02.vse.cz

S: 250 vse.cz is pleased to meet you



K: MAIL FROM: <opinkas@quick.cz>

S: 250 opinkas@quick.cz sender accepted



K: RCPT TO: <ypinkas@vse.cz>

S: 250 ypinkas@vse.cz will leave the Internet



K: DATA

S: 354 Enter mail, end with "." on a line by itself

K: Date: 26 May 2006 18:19:00

K: From: <opinkas@quick.cz>

K: To: <ypinkas@vse.cz>

K: Subject: rucne

K: 

K: Odesilatel MAIL FROM: je z domény quick.cz.

K: .

S: 250 21909570 message accepted for delivery

K: QUIT

S: 221 vse.cz CommuniGate Pro SMTP closing connection

Informace přidávané ze SMTP komunikace do textu zprávy

Zpráva SMTP může být zaslána z odesílajícího serveru na server adresáta přímo, tj. bez účasti dalších SMTP serverů. Může být zaslána také zprostředkovaně. V každém případě se do přenášené zprávy zařadí hlavička Received: od každého ze SMTP serverů, kterým zpráva prochází. Proto se její velikost mírně zvětšuje. Hlavička Received: obsahuje cenné údaje pro vysledování cesty zprávy a okolností jejího zaslání.

Poslední SMTP server zařadí do záhlaví zprávy hlavičku Return-Path:, která odkazuje na původního odesilatele uvedeného v příkazu MAIL FROM:.

Return-Path: <opinkas@quick.cz>

Received: from n412h02.vse.cz ([146.102.64.219] verified) by vse.cz (CommuniGate  Pro SMTP 4.1.8) with SMTP id 21909570 for 



ypinkas@vse.cz; Fri, 26 May 2006 18:17:19 +0200

From: opinkas@quick.cz

To: ypinkas@vse.cz

Date: May 26 2006 18:19:00

Message-ID: <auto-000021909570@vse.cz>

Odesilatel FROM (obálka) je z domény quick.cz.

Nové typy zpráv (MIME) a změny v přenosu

V polovině devadesátých let minulého století vznikla v Internetu potřeba přenášet elektronickou poštou složitější typy dokumentů a umožnit výměnu zpráv v národních abecedách. Vznikla řada pěti návazných RFC dokumentů společně označovaných jako MIME (víceúčelové rozšíření internetové pošty). Jedná se o RFC 2045 - 2049.

V souhrnu dokumentu RFC 2045 byly stanoveny cíle nového standardu, a to:

• umožnit zápis textu v těle dopisu i v jiných znakových sadách než v US-ASCII,
• definovat a podporovat netextové formáty zpráv (obrázky, zvuky, aj.),
• vkládat několik souborů a zpráv do jednoho těla zprávy,
• vyjadřovat textové hlavičky záhlaví pomocí jiné znakové sady než US-ASCII.

S ohledem na existující poštovní systémy bylo třeba zachovat sedmibitovou kompatibilitu. Toho bylo dosaženo překódováním osmibitových dat pomocí sedmibitových znaků ASCII. Pomocí protokolu SMTP se po překódování přenášejí zprávy obdobně jakoby šlo o zprávy v US-ASCII. Jestliže mezi odesilatelem a příjemcem nehrozí zásah SMTP serveru nepodporujícího MIME, lze dopis poslat v osmibitovém kódování bez převodu. Nové typy zpráv a způsob kódování si vyžádaly zavedení dalších hlaviček záhlaví zprávy.

Nové hlavičky

Nové hlavičky spolu s určením kódovacích pravidel obsahu dopisu umožnily další rozvoj elektronické pošty. Možnosti jsou nyní opravdu velké: lze vytvářet jednoduché nebo strukturované dopisy různých typů: multipart/alternative, multipart/mixed, message/xxx, atp.

Přehled

• MIME-Version: vyjadřuje, že zpráva vyhovuje standardu MIME.
• Content-Type: vyjadřuje typ a podtyp zprávy, ev. používanou znakovou sadu, aby klientský program mohl zprávu správně zobrazit.
• Content-Transfer-Encoding: specifikuje použité kódování těla zprávy, které bylo provedeno s cílem bezpečného přenosu dat v podmínkách, kdy je omezena znaková sada nebo typ přenášených dat.
• Content-ID: jedinečně označuje tělo dané zprávy a používá se k odkazu na jiné tělo zprávy (např. vnější).
• Content-Description: umožňuje textově popsat tělo dané zprávy (např. obrázku).

Kódování zpráv podle MIME

Přehled

Podle RFC 2045 lze určit tyto druhy kódování těla zprávy:

• 7 bit - používá se, jestliže záhlaví neobsahuje hlavičku Content-Transfer-Encoding. Jedná se o standardní hodnotu. Předpokládá se, že se tělo zprávy opravdu skládá z řádek textu v US-ASCII, které jsou max. 998 znaků dlouhé. Neobsahují uvnitř řádku znaky CR, LF ani nulový znak (hexadecimální 0).
• 8 bit - stejné použití a význam, avšak v těle zprávy se mohou vyskytnout znaky s hodnotou vyšší než 127. Hlavička "Content-Transfer-Encoding: 8bit" uvedena být musí.
• binary - tělo zprávy je libovolná posloupnost bytů (neplatí omezení pro řádky).

Tato kódování vlastně kódováním nejsou, protože se vstupní řetězec nepřevádí na cílový, data jsou přenášena tak, jak jsou, beze změny.

• base64 - tělo je kódováno pomocí abecedy "base64", která je podmnožinou tisknutelných znaků US-ASCII.
• quoted-printable - tělo zprávy je kódováno znak po znaku tak, že jednomu znaku na vstupu se přiřadí jeho hodnota v kódové tabulce. Hodnota se vyjadřuje hexadecimálně jako dvojice, které předchází znak "=" (rovná se). Platí omezení délky řádku na 76 znaků, proto se musí dlouhé řádky rozdělit na kratší s potřebným vyznačením pomocí rovnítka. Protože se rovnítko používá pro zobrazení kódovaných znaků, musí se samo rovnítko vyjádřit jako =3D. Řetězec „3D“ je kódové zobrazení znaku „rovná se“. Znaky „tabulátor“ a „mezera“ se na konci řádky vyjadřují jako =09 a =20.

Příklad

Znaku "A" odpovídá zápis =41. Jednomu znaku obecně odpovídá trojice =XY, kde X a Y jsou hexadecimální číslice (0,1 až 9, A, B, C, D, E, F).

Kódování metodou "quoted-printable"

. . .

Subject: =?iso-8859-2?Q?Dom=E1c=ED_=FAkol_z_IZI216/2?=

Date: Sun, 20 May 2001 22:09:55 +0200

MIME-Version: 1.0 

boundary="----=_NextPart_000_0021_01C0E179.9A067220"

. . .  

Content-Type: text/plain; charset="iso-8859-2"

Content-Transfer-Encoding: quoted-printable



Dobr=FD den.

Pos=EDl=E1m V=E1m odkaz na HTML str=E1nku (dom=E1c=ED =FAkol), kter=E1 =. . .

Kromě metody "quoted-printable" se užívá metoda "base64". Před standardizací se dopisy kódovaly metodou "uuencode" a "uudecode". U nás se obsah dopisu kóduje většinou podle normy ISO-8859-2, pro přenos se využívá quoted-printable nebo base64. Někdy se texty dopisů pro přenos vůbec nekódují.

Kódování metodou "base64"

Kódování base64 nenahrazuje jedno zdrojové písmeno jiným cílovým znakem. Zdrojový text se rozdělí na šestibitové skupiny a ty se nahrazují písmeny z cílové abecedy, která obsahuje právě 64 znaků. Znaky cílové abecedy leží v první polovině ASCII tabulky. Tři písmena na vstupu (čtyři šestice bitů) jsou zakódována čtyřmi písmeny na výstupu. Krátký příklad ukazuje MIME hlavičky a zakódovaný text (ypinkas).

MIME-Version: 1.0

Content-Type: application/octet-stream; name="ypinkas.txt"

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="ypinkas.txt"



eXBpbmthcw==

Pomocí Total Commanderu můžeme kódovat/dekódovat dopisy v MIME zpracované pomocí base64, viz nabídku Soubory/Zakódovat soubor (MIME, UUE, XXE).

Nové typy zpráv

Hlavička označující typ zprávy a její parametry se nazývá Content-Type.

V dokumentu RFC 2046 bylo určeno sedm obecných typů zpráv, a to podle jejich obsahu: text, obraz, zvuk, aj. Obecné typy se dále dělí na podtypy, které určují konkrétní formát zprávy (např. text/plain, text/html, image/gif, aj.).

V klasických (neelektronických) dokumentech se běžně vyskytují kombinace různých typů zpráv: text s obrázky, text s hudbou, atp. Dokument proto zavádí typy složené, které jsou kombinací jednoduchých typů zpráv.

Jednoduché typy

Jednoduché typy jsou takové, kdy zpráva obsahuje v těle jen jeden typ dat (text, obraz, aj.). RFC 2046 rozeznává 5 jednoduchých typů zpráv:

• text - označení se užívá pro přímo čitelný text, který neobsahuje nečitelné formátovací příkazy a direktivy. Žádný zvláštní program není pro uspokojivé zobrazení textu nutný. Pro správné zobrazení potřebujeme parametr "charset" udávající použitou znakovou sadu textu v hlavičce Content-Type.

Významným podtypem je "text/plain" (jednoduchý text). Podtyp "text/enriched" může obsahovat jednoduché, ale přímo čitelné, formátovací příkazy.

• image - označuje nepohyblivé obrázky jako image/gif nebo image/jpeg.
• video - označuje pohyblivé obrázky, video/dat, např. video/mpeg.
• audio - označuje zvuková data, např. audio/basic.
• application - označuje binární data, u nichž nevíme, kterým programem je máme přečíst. Nebo také binární data se speciálním binárním formátem souboru. Příklady: application/postscript, application/octet-stream.

Poslední příklad (application/octet-stream) ukazuje na velmi obecný formát, jehož správná interpretace vyžaduje další určení. Data tohoto typu se obvykle ukládají na disk.

Při vymezování typů odkazuje RFC 2046 na nezbytnost existence hardwarových zařízení a softwarových nástrojů pro správné a zamýšlené zobrazení dat těchto typů.

Složené typy

Jestliže do těla jedné zprávy vložíme jiné zprávy, dostaneme složenou zprávu. Jednotlivé dílčí zprávy musí být odděleny mezí (boundary), což je speciální řetězec, který se nesmí vyskytovat v těle žádné vložené zprávy. Parametr "boundary" se uvádí v hlavičce Content-Type. V RFC 2046 byly zavedeny dva typy: vícedílné zprávy (multipart) a message.

Typ "multipart" a jeho podtypy

• multipart/mixed - podtyp těchto dílčích zpráv může být odlišný; dílčí zpráva musí mít své vlastní záhlaví. Dílčí zprávy jsou samostatné, avšak je třeba je brát v dané posloupnosti.
• multipart/alternative - podtyp dílčích zpráv je odlišný, ale obsah je stejný. Nejběžnějším příkladem je alternativní uvedení zprávy ve formátu "text/plain" a "text/html".
• multipart/digest - tento podtyp je syntakticky obdobný s podtypem "mixed". Jedná se o jakýsi přehled dílčích zpráv, které mohou pocházet od různých odesílatelů.
• multipart/paralell - tento podtyp je syntakticky obdobný s podtypem "mixed". Hlavní rozdíl je v tom, že na pořadí dílčích zpráv nezáleží. Jsou totiž zobrazovány různými zařízeními současně (např. text a zvuk).

Zprávy "multipart" musí být kódovány jako "7bit", "8bit" nebo "binary".

Typ "message" a jeho podtypy

• message/rfc822 - tělo zprávy obsahuje vloženou zprávu podle RFC 822 nebo dokonce MIME zprávu. Povinné kódování je "7bit", "8bit" nebo "binary".
• message/partial - dělí zprávu na sled dílčích zpráv kratší délky, které se po přenosu spojí do jedné. Povolené kódování je pouze "7bit". Dělení na kratší zprávy může být nutné, protože příjemce odmítá zprávy větší délky.

Rozšíření obsahu hlaviček dopisu a kódování ne US-ASCII znaků (RFC 2047)

Podle RFC 822 se obsah hlaviček dopisu zapisuje pomocí tisknutelných znaků US-ASCII. Cílem RFC 2047 bylo umožnit používání širšího souboru znaků v obsahu hlaviček a zachovat sedmibitovou kompatibilitu. Uživatelé, kteří mají odlišnou abecedu, mohou používat svou abecedu, ovšem v zakódovaném tvaru.

Byl definován obecný syntaktický vzorec pro zakódování obsahu hlavičky:

=?znaková_sada?kódování?zakódovaný_text?=

Znaková sada - označuje použitou tabulku znaků (např. ISO-8859-2).
Kódování - písmeno "Q" je použito pro Quoted printable, "B" pro Base64.
Zakódovaný text - je text kódovaný pomocí pravidel "Quoted printable" nebo "Base64". Je-li kódováno pomocí "Quoted printable", nahrazují se mezery znakem "_" nebo "=20".

Příklady

=?iso-8859-2?Q?Bo=F8il_Martin?= 

=?iso-8859-2?Q?Linda_Skolkov=E1?=

=?utf-8?b?w41QWQ==?=



From: =?iso-8859-2?Q?Bo=F8il_Martin?= <martin.boril@autocont.cz>

To: "pinkas" 

Změny v přenosu zpráv

Zavedení hierarchického systému doménových jmen (DNS) a rozšiřování osobních počítačů (bez trvalého připojení k Internetu) vyvolalo změnu ve způsobu odesílání a přijímání pošty. Dokument RFC 974 (Směrování pošty a doménový systém) z r. 1986 určuje nová pravidla pro odesílání a příjímání pošty.

Dříve bylo možné předpokládat vytvoření přímého spojení mezi odesílatelem a příjemcem na základě adresy příjemce. V novém systému musí odesilatel či spíše odesílající SMTP server nejdříve kontaktovat server DNS, který odpovídá doméně příjemce. Teprve tam zjistí, který poštovní server zodpovídá za příjem/odesílání zpráv pro danou doménu. A s ním se spojí. Tento server pak může obdrženou zprávu poslat dále na vnitřní poštovní server místní sítě.

Název poštovního serveru se může úplně lišit od názvu uvedeného v adrese příjemce. Extrémním případem je, když doménové jméno příjemce neoznačuje žádný počítač, ale jen jméno domény.

Směrování zpráv podle MX záznamů

Server DNS zodpovědný za určitou doménu (skupinu) počítačů slouží především k převodu doménových jmen počítačů na IP adresy a zpětnému převodu IP adres na doménová jména. Dílčí informace uchovává v záznamech o prostředku (Resource Record - RR). Rozlišují se různé typy záznamů RR. Např. záznamy typu A označují adresu, záznamy CNAME definují synonymní jméno počítače příslušné k základnímu jménu.

Záznamy typu MX určují název poštovního serveru spolu s předností v obsluze požadavků. Přednost je vyjádřena číselně: čím menší číslo, tím větší přednost. V příkladu je záložním poštovním serverem mx1.vse.cz a hlavním vse.vse.cz.

vse.vse.cz      MX preference = 100, mail exchanger = mx1.vse.cz

vse.vse.cz      MX preference = 50, mail exchanger = vse.vse.cz

Budeme-li navazovat SMTP komunikaci s gama.vse.cz, musíme kontaktovat poštovní server vse.vse.cz nebo mx1.vse.cz, protože v doménovém systému najdeme tyto MX záznamy:

gama.vse.cz     MX preference = 100, mail exchanger = mx1.vse.cz

gama.vse.cz     MX preference = 50, mail exchanger = vse.vse.cz

Adresa poštovní schránky opinkas@quick.cz je spojena s těmito poštovními servery:

- Name=quick.cz

Type=MX, Class=1, TTL=3600 (1 Hour), RDLENGTH=12

Preference=10, Mail Exchange=smtp-in.quick.cz

- Name=quick.cz

Type=MX, Class=1, TTL=3600 (1 Hour), RDLENGTH=11

Preference=20, Mail Exchange=backmx.iol.cz

Ve složitějších poštovních systémech s více vnitřními SMTP servery bývá určen jen jeden hlavní SMTP server, který odesílá a přijímá zprávy z Internetu. Adresa skutečného odesílajícího serveru bývá v hlavičce From: v záhlaví dopisu upravena na obecnější: místo ypinkas@veverka.vse.cz bude jen ypinkas@vse.cz.

Rozšíření protokolu SMTP na ESMTP

V dokumentu RFC 1869 z r. 1995 byl určen rámec pro rozšíření protokolu SMTP. Rozšíření zachovává zpětnou slučitelnost s protokolem SMTP podle RFC 821. Nový protokol se označuje zkratkou ESMTP. Byl zaveden nový příkaz EHLO a doplněny parametry příkazů MAIL FROM a RCPT TO.

Používání SMTP/ESMTP se rozhoduje pomocí příkazu EHLO. Klient se představí pomocí EHLO. Nezná-li SMTP server nový příkaz, odpoví kódem 500. Klient pokračuje příkazem HELO nebo spojení ukončí.

K: EHLO nb371h03.znet.vse.cz

S: 500 unknown ??? command "EHLO nb371h03.znet.vse.cz"

K: HELO

S: 250 Hello ([146.102.68.99])

Když server rozpozná EHLO, umí ESMTP a musí odpovědět seznamem rozšíření, která podporuje.

Příklad

S: naslouchání na portu TCP/25

K: otevření spojení 

S: 220 vse.cz ESMTP CommuniGate Pro 4.1.8

K: EHLO s105h00.vse.cz

S: 250-vse.cz is pleased to meet you

S: 250-HELP S: 250-PIPELINING

S: 250-ETRN

S: 250-DSN

S: 250-TURN

S: 250-ATRN

S: 250-SIZE 9437184

S: 250-AUTH=LOGIN

S: 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5

S: 250-8BITMIME

Prohlášení o velikosti zprávy (Message Size Declaration)

Prakticky významným rozšířením protokolu SMTP je rozšíření umožňující klientu SMTP a serveru SMTP informovat protějšek o maximální nebo skutečné velikosti přijímané nebo odesílané zprávy. Výhoda spočívá v domluvě obou stran ještě před vlastním odesláním zprávy a v úspoře přenosových kapacit při marném pokusu o přenos.

Přijímající server ukládá zprávy do vyrovnávací diskové paměti a z ní je předává dále uživatelům. Zprávy typu MIME bývají dlouhé, takže je nutno s vyrovnávací diskovou pamětí dobře hospodařit.

V příkladu komunikace podle ESMTP přijímající server zveřejnil maximální velikost zprávy, kterou může přijmout. Odesílající SMTP server sdělí příkazem MAIL FROM: odesilatel SIZE=xxxxxxxxxx odhadnutou velikost své zprávy.

Zpráva nemůže být větší než je uvedeno v prohlášení přijímajícího serveru. Je-li v normě, nemusí vždy přijímající server zprávu přijmout, protože dočasně nemá dostatek diskového prostoru pro její uložení.

Příklad využití parametru SIZE

. . .

MAIL FROM: pinkas <pinkas@vse.cz> SIZE=10000000

552 message exceeds the fixed maximum message size

nebo

552 5.3.4 Message size exceeds fixed limit

Kódování pro přenos 8BITMIME

Toto rozšíření je specifikováno v RFC 1652 z r. 1994. Jestliže se klient a server SMTP dohodnou na použití všech osmi bitů (místo tradičních sedmi), pak je možno zaslat a přijmout text kódovaný osmi bity.

Klient zašle příkaz EHLO. Když server odpoví zprávou "250-8BITMIME", může klient odeslat příkaz MAIL FROM, v němž za adresu příjemce přidá parametr BODY=8BITMIME.

Z dohody obou stran na 8BITMIME je zřejmé jen to, že přijímající server nebude nulovat bit v osmici bitů (ani ho ignorovat). Správné čtení dopisu vyžaduje znalost znakové sady použité při jeho napsání.

Budeme-li považovat 8 bitový kód ISO-8859-1 za univerzální, pak znakovou sadu uvádět nemusíme. Pro jiné sady však potřebujeme hlavní hlavičky MIME, které i při kódování 8BITMIME zaručí správné dekódování.

Na českých volných poštovních serverech se obvykle používá pro kódování textu pro přenos - "quoted-printable". Uvažují se totiž i situace, kdy je dopis poslán pomocí řetězce poštovních serverů, z nichž každý nemusí umět ESMTP s kódováním MIME.

Příklad uvádí použití parametru BODY=8BITMIME při odesílání a podobu získaného dopisu.

Příklad

S: naslouchání na portu TCP/25

K: otevření spojení

S: 220 vse.cz ESMTP CommuniGate Pro

K: EHLO nb371h03.znet.vse.cz

S: 250-vse.cz is pleased to meet you

. . .

S: 250-8BITMIME

S: 250 EHLO



K: MAIL FROM: pinkas <pinkas@vse.cz> BODY=8BITMIME

S: 250 pinkas@vse.cz sender accepted



K: RCPT TO: "Otakar Pinkas" <ypinkas@vse.cz>

S: 250 ypinkas@vse.cz will leave the Internet



K: DATA

S: 354 Enter mail, end with "." on a line by itself

K: From: pinkas@vse.cz

K: To: ypinkas@vse.cz

K: Date: Mar 26, 9:48

K: Subject: dopis rucne - BODY=8BITMIME - RFC 1652

K: 

K: Posílám dopis ručně - EHLO. BODY=8BITMIME. Pozor: neobsahuje hlavičku MIME.

K: .

S: 250 27289205 message accepted for delivery

K: QUIT

Dopis ESMTP/8BITMIME vybraný ze schránky:

Return-Path: <pinkas@vse.cz>

Received: from nb371h03.znet.vse.cz ([146.102.68.99] verified) by vse.cz (CommuniGate Pro SMTP 4.1.8) with ESMTP id 27289205 



for ypinkas@vse.cz; Mon, 25 Jun 2007 14:23:26 +0200

From: pinkas@vse.cz

To: ypinkas@vse.cz

Date: Mar 25, 9:48, 2007

Subject: dopis rucne - BODY=8BITMIME - RFC 1652

Message-ID: <auto-000027289205@vse.cz>



Posílám dopis ručně - EHLO. BODY=8BITMIME. Pozor: neobsahuje hlavičku MIME.

Protokol ESMTP zahrnuje ještě další možnosti zasílání a příjímání dopisů. Jednou z nich je ověřování totožnosti odesilatele pomocí příkazu AUTH a jeho parametrů: LOGIN, PLAIN, aj. Další je možnost zřetězeného zadávání příkazů, které se odešlou v jedné dávce, a nikoli v obvyklém dialogu klient/server – PIPELINING; tuto možnost rozebírat nebudeme.

Průměr: Select ratingŠpatnéUjdeDobréSkvěléVýborné!

Průměr: 3.4 (hlasů: 7)