První e-mail byl odeslán na podzim roku
1971, přesné datum není známo. Mužem, který se postaral o vznik tohoto fenoménu,
byl Ray Tomlinson, počítačový technik. Pracoval pro společnost Bolt Beranek and
Newman (BBN), kterou si najalo ministerstvo obrany Spojených Států v roce 1968,
aby pro ně vypracovala ARPANET, předchůdce dnešního Internetu. Pro tento APRANET
vypracoval Tomlinson cosi jako systémem pro výměnu zpráv (SNDMSG). Ten sloužil
pro pracovníky k zanechávání vzkazů, ale pouze na lokálním počítači. Tyto zprávy
nebylo možné vyměňovat mezi různými počítači. V onom roce 1971, kdy usedl k
počítači, aby si “pohrával” s SNDMSG, pracoval na CYPNETu, experimentálním
protokolu pro přenos souborů mezi spojenými počítači. Tomlinsona napadlo
“spojit” oba programy a použít je pro zasílání zpráv mezi počítači na síti. Aby
odlišil lokální zasílání do poštovních schránek síťového, zvolil použití
“zavináče” @, který vložil mezi jméno odesilatele (přihlašovací jméno do
systému) hostitelský počítač. Tomlinson nejprve vyzkoušel svůj nápad mezi 2
počítači ve své pracovně, které byly spojeny sítí. První e-mail pravděpodobně
byl typu "QWERTYIOP" nebo podobný "nesmysl". Když si ověřil, že vše funguje,
začal zasílat zprávy i svým přátelům na ARPANETu. E-mail se rychle šířil,
nicméně trvalo ještě 5 let, než jej programátoři upravili do obecně použitelné
podoby. První komerční e-mailové spojení je pak datováno až v roce 1989, kdy MCI
Mail zprostředkoval spojení mezi Corporation for the National Research
Initiative a univerzitou v Ohiu. V roce 1993 pak začaly America Online a Delphi
připojovat své e-mailové systémy na Internet a položily tak základy k masivnímu
rozšíření e-mailu mezi běžnými uživateli.
Málokdo ví, že protokol pro přenos
elektronické pošty byl zabudován prakticky od začátku v rodině protokolů TCP/IP.
Byl to SMTP (Simple Mail Transfer Protocol), který umožňoval předávání zpráv na
základě přenosových protokolů TCI/IP v čistě textové formě (sedmibitové ASCII (American
Standard Code for Information Interchange).
Původní SMTP umožňoval přenos sedmibitových
ASCII znaků. To odpovídalo tehdejším nárokům na jeho tvůrce - jak ze strany
uživatelů, kterým čistý text bohatě stačil, tak ze strany správcům tehdejšího
ARPANETu, jehož přenosové linky měly jisté limity...
Tak jak se ale možnosti "Sítě" rozrůstaly a
její přenosové rychlosti zvyšovaly, i uživatelé začali přemýšlet, o nečem
"navíc", a dostali nápad, že by k textové zprávě taky rádi občas něco připojili
- vysvětlující obrázek, náčrtek grafu, technický nákres, atp. Také je důležité
zmínit, že "Síť" začali používat neamerické, resp. neanglické ústavy, což s
sebou neslo problémy s lokálními abecedami a jejich kompatibilitou (nebo spíše
nekompatibilitou) se sedmibitovou sadou ASCII...
První, co se vyřešilo, byla právě podpora
lokálních znakových sad. Od toho byl už jenom krůček k tomu, aby bylo možno do
zpráv vkládat i netextové soubory. Řešení bylo nasnadě: všechno, co není čistý
ASCII, se prostě nějakým způsobem do této podoby převede, přenese a pak se zase
hezky převede do podoby původní. O tom, že to zas tak těžké není, svědčí i to,
že těch způsobů bylo vymyšleno hned několik - a tak bylo třeba se dohodnout na
tom, který z nich se bude používat...
A tak vznikl MIME (Multipurpose Inernet
Mail Extensions). Slovo "Extensions" dává tušit, že tento standard nijak
nezasahuje do původního SMTP, ale je pouze jeho nadstavbou, tím "něčím navíc".
Samotný mechanismus přenosu zprávy je nadále zajišťován pomocí SMTP a TCP/IP.
Nebo přesněji pomocí SMTP a jakýchkoli jiných přenosových (transportních)
protokolů.
Jelikož SMTP vznikl v době, kdy pécéčka
ještě vlastně nebyla. Tehdy se používaly sálové počítače a terminály k nim se
připojující. Proto vlastně poštovní "server" i poštovní "klient" běželi na
stejném počítači a informace mezi sebou si vyměňovali pomocí "komunikačních"
souborů ve sdílených adresářích.
Po nástupu osobních počítačů proto bylo
nutné vymyslet architekturu klient/server. A tak se na scéně objevil POP (Post
Office Protocol), který vyhrál pomyslnou bitvu mezi nově vzniknuvšími protokoly.
Nutno podotknout, že SMTP zůstal - ale bylo ho možno použít pouze pro směr
klient -> server, nikoliv opačně. A o to právě šlo. Nakonec se tedy prosadil
zmíněný POP, který je dnes ve verzi 3, tj. známý POP3.
Vraťme se nyní k MIME. Jak bylo řečeno,
tento standard definuje způsob, jakým lze k tělu poštovní zprávy připojit
jakýkoliv soubor. Ale nejenom to - pomocí MIME lze odeslat i zprávu, jejíž tělo
je v jiném formátu než čisté ASCII. Tato "schopnost" MIME, mimo jiné, může za
to, že si můžeme psát "hezky česky" a nikoliv "seredne cesky".
Problémem však zůstává, že MIME - protože
je to jenom "něco navíc" - je součástí klienta, nikoliv serveru. Tím je řečeno
vše - ne všichni poštovní klienti MIME podporují a umějí ho používat - proto se
může stát (a dost často se to stává), že místo "hezkého českého" textu dojde jen
"hezký eský"...
Dalším pojmem, který doprovází vývoj (teď
už dosti pozdní) e-mailu, je LDAP (Lightweight Directory Access Protocol). Je to
protokol rodiny TCP/IP, který má v podstatě "za úkol" zprostředkovávat uživateli
databázi e-mailových adres. Dnes je již tento protokol podporován prakticky
všemi poštovními klienty, takže uživatel to s tím hledáním má náramně
jednoduché.
Protokol SMTP
Protokol SMTP (simple mail transfer protocol) je protokol popisující
mechanismus předávání emailu. Svému masovému rozšíření je vděčen především díky
své jednoduchosti. Protokol je textový a rozlišuje v základě pouze několik
direktiv. Stinnou stránkou je to, že aby byl jeho provoz bezpečný, potřebuje
program který protokol realizuje, poměrně přísnou konfiguraci, aby se např.
zabránilo (alespoň na domovské úrovni) rozesílání anonymních emailů.
-
neřeší správnost údajů
-
nijak autorizovaný
-
nešifrovaný
V příkladu použijeme SMTP serveru portálu
Seznam, účtu s názvem learn.email@seznam.cz
telnet smtp.seznam.cz 25
220 Welcome ESMTP Sendmail 8.8.5/8.8.8; ESMTP /server odpoví
helo
250 Welcome ESMTP Sendmail 8.8.5/8.8.8; /server odpoví
mail from: learn.email@seznam.cz
250 ok /server odpoví
rcpt to: bill@gates.net
250 ok /server odpovíí
data
354 go ahead /server odpoví
Dear Bill,
Thank you for Win XP!
. /řádků může být samozřejmě více, konec těla oznámíme
serveru tak, že vložíme tečku samostatně na řádek
250 ok 1048949306 qp 55356 /server odpoví
quit
221 Welcome ESMTP Sendmail 8.8.5/8.8.8; /server odpoví a
spojení skončilo
Protokol POP3
POP3 (post office protocol; RFC 1225) je jedním z
prootkolů, které slouží k “opačnému” postupu zacházení s emailem, tedy nikoliv k
odesílání ale k vyzvednutí.
Rovněž i ten je textový, takže si můžeme vymodelovat
situaci stažení emailu. Každý řádek odezvy POP protokolu začíná klíčovými znaky
“+OK” nebo “-ERR”. Ten první signalizuje, že operace byla provedena korektně,
ten druhý hlásí chybu.
telnet pop3.seznam.cz 110
+OK Hello, this is Seznam POP3 server /server odpoví
user learn.email@seznam.cz
+OK Enter your password please /server odpoví
pass heslo
+OK 1 3110 /server odpoví – máte 1 zpávu
list /požádáme server o podrobnější informace o přijatých zprávách
+OK 1 3110
. /máme 1 zprávu o velikosti
retr 1 /přečteme si první zprávu; server zobrazí kompletní email:
+OK Message follows (3110 bytes).
Return-Path: <learn.email@seznam.cz>
Delivered-To: alias-email-learn.email@seznam.cz
Received: (qmail 2220 invoked by uid 0); 29 Mar 2003 14:43:54 -0000
Received: from [62.84.140.173] by email.seznam.cz with HTTP;
Sat, 29 Mar 2003 15:43:50 +0100 (CET)
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Date: Sat, 29 Mar 2003 15:43:50 +0100 (CET)
From: =?iso-8859-2?Q?learn=20email?= <learn.email@seznam.cz>
Reply-To: =?iso-8859-2?Q?learn=20email?= <learn.email@seznam.cz>
Subject:
Mime-Version: 1.0
Message-Id: <140516.262522-27188-623527632-1048949030@seznam.cz>
To: learn.email@seznam.cz
tento email byl odeslan vlastnimu odesilateli...
-typicky priklad hospodarneho
zachazeni.
. /z tohoto balíku je vidět prakticky vše, dokonce mnoho informací, které
těžko využijeme. Například vidíme email odesílatele, kterými SMTP servery email
prošel, datové a časové razítko, dokonce je vidět, že email byl odeslán z
webového rozhraní služby email.seznam.cz a jako poslední informace je zobrazen
vlastní text emailu.
suit / ukončíme relaci
+OK Closing connection, see you later /server se s námi hezky rozloučí
Protokol IMAP
IMAP (Internet Mail Access Protocol; RFC:2192), stejně jako pop3 slouží k
manipulaci s maily na vzdáleném serveru.
Oproti POP3 umožňuje:
Poznámka k zadávání hesla: způsob zadání hesla, který jsme
zvolili, není nejšťastnější. Telnetová spojení totiž bývají nešifrována, a dají
se snadno odposlouchávat. Také heslo je odesíláno v otevřeném tvaru.
Pojmy a obecné fungování emailu
MTA (Mail Transfer Agent) - program zajištující doručení zprávy k příjemci.
Též nazýván mail server (qmail, postfix, ...)
MUA (Mail User Agent) - program ve kterém (nejčastějí) uživatel vytváří vlastní
zprávu (mutt, pine, ...)
MSP (Message Submission Program) - program starající se o odeslání zprávy.
Obvykle integrován do MTA
MDA (Mail Delivery Agent) - program pro doručováni. Obvykle přebírá zprávy od
lokálního MTA, třídí je do schránek, přeposílá, atd..Typický zástupce je
Procmail
relay - smtp server, který od určité skupiny lidí/počítačů/... přijímá mail pro
kohokoli a následně se ho sám snaží doručit.
open relay - smtp server, ktery od kohokoli přijme mail pro kohokoli.
doménový koš - jakýsi relaying pošty pro nějakou doménu.
MX záznam - (Mail eXchanger) DNS záznam odkazující na smtp server pro doménu.
Základní model doručování zprávy
Neomi chce sdělit Isacovi své poslední studijní úspěchy. Spustí tedy
svůj oblíbeny MUA, v jejím případě mutt. Jediné co Noemi musí/měla_by zadat je
adresa Isaca, předmět zprávy a pochopitelně zprávu samotnou. MUA doplní všechny
ostatní vyžadované hlavičky a zprávu předá dál svému oblíbenému MTA. Tím pro něj
starost o doručení končí. MTA, například exim, doplní hlavičku o nějaké další
údaje a také vytvoří obálku kterou se řídí další směřovaní pošty. Pomocí MX
záznamu v DNS si MTA zjistí stroj odpovědný za příjem pošty pro danou doménu a
pokusí se mu zprávu předat. Pokud uspěje, tak končí starosti i pro něj. V
opačném případě vyhledá v DNS stroj s vyšším preferenčním číslem pro danou
doménu a opět se mu pokusí zprávu předat. Spojení nemusí být vždy přímé, ale
zprávu si může vzájemně předávat více MTA. Z popsaného systému je zřejmé, že
otázka doručovaní je v podstatě problém nalezení cesty v grafu. Aby se zabránilo
vzniku cyklů, existuje pravidlo, dle kterého MTA předává zprávu jen MTA s
preferenčním číslem nižším, než má on sám. V případě kdy pro cílovou doménu
neexistuje MX záznam, MTA se zjistí IP adresu této a pokusí se email doručit
přímo na tento stroj. Není to ale rozhodně preferovaný postup. Na cílovém stroji
se zpráva předá MDA(napr. Procmail), který se postará o zařazení do správné
složky, odkud si ji Isac vybere svým oblíbeným MUA, kterým je elm. Popř. by si
ji mohl stáhnout na svůj laptop pomocí jednoho z protokolů pop3/imap.
+-----------+ +--------+
+-------+ pise |odesilajici| vola |zdrojovy|
| Neomi |----->| MUA |----->| MTA
|:>::
+-------+ |(mutt) |
|(exim) | :: na odesilajicim
+-----------+ +--------+ :: pocitaci
::
................................................................
SMTP
::
::::::::::::::::::::::::::::<:::::::::::::::::::
::
:: +---------+ +-----+
+-------+
:: | cilovy | vola | | doruci do |Isacova|
::::>| MTA |----->| MDA |==========>|chranka| na
prijimajicim
|(qmail) | |
| |(elm) |
pocitaci
+---------+ +-----+
+-------+
z obrázku je zřetelná nezávislost emailu na konkrétní implementaci jednotlivých
nástrojů
Fungování emailu je technicky relativně
jednoduché. Obecně existují nějaké mailové schránky na nějakých mailových
serverech. V nejjednodušším případě v sobě emailová adresa obsahuje název
schránky a serveru s touto schránkou. V ideálním případě nejsou věci jako
relaying, nebo doménový koš zapotřebí. MTA dostane lokálně od MUA zprávu a kam
ji doručit. Řekněme mail pro novak@mail.cz. MTA se připojí na mail.cz:25, kde
poslouchá vzdálený MTA a smtp protokolem pošle mail. V případě, že schránka
novak na serveru mail.cz existuje, pro odesílatele je hotovo. Uživatel novak se
pak třeba pres ssh přihlásí na mail.cz, pustí MUA a ten řekne lokálnímu MTA o
jeho maily, nebo se připojí pomocí pop3 a opět řekne MTA na mail.cz o svoje
maily. První komplikace nastává, když schránka novak na mail.cz neexistuje. V
tom případě může posílání mailu selhat už při SMTP spojení. Obecně však nemusí
(např. qmail). V tom případě MTA na mail.cz posílá mail o nemožnosti doručeni na
Return-Path adresu, uvedenou v hlavičce.
MX záznamy - ve zmíněném příkladu
předpokládáme, že mail.cz je skutečne mailserver. Může ale nastat situace, kdy
není a MTA na to tedy nemůže spoléhat. Nejdříve se tedy musí zeptat na MX záznam
pro danou doménu (např. university.edu) a ten ho odkáže na smtp server(y) pro
danou doménu. Záznamy jsou tvaru mx1.university.edu, obecně jich může byt více a
číslo 1 určuje preferenci serveru (nižší číslo -> vyšší preference). Může se
vyskytovat více stejných mx záznamů.
Relaying - Relaying se týká pouze odesílání
mailu. To často neprobíhá přímo, jako v uvedeném příkladu, ale přes nějaký další
mailserver. Například v nějakém LAN prostředí, nebo pokud uživatel svoje maily
posílá pres svého ISP.
|