eNet System
O nás Řešení Technologie Support Reference
Odkazy
Email

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

  • nešifrovaný

  • autorizovaný

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.

  • nešifrovaný

  • autorizovaný

Oproti POP3 umožňuje:

  • manipulaci s více mailboxy

  • stažení pouze hlavičky mailu

  • asynchronost

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.