Řešení e-mailového serveru a aplikace pro jeho správu

Obsah

  1. Úvod
  2. Elektronická pošta jako služba
  3. Návrh systému
  4. Implementace a použité technologie
  5. Distribuce a další vývoj programu
  6. Shrnutí výsledků
  7. Závěr

Úvod

Elektronická pošta je služba, která provází síť Internet od samého počátku, přičemž její historie sahá ještě dále. V současnosti je jedním z nejpopulárnějších způsobů asynchronní komunikace a využívá ji naprostá většina uživatelů sítě Internet. Již nepředstavuje pouhou možnost zasílat elektronické zprávy (e-maily), neboť se stala také nástrojem k identifikaci osob u rozličných internetových služeb, takže je vlastnění e-mailové schránky předpokladem k jejich užívání. V minulosti byly schránky pro elektronickou poštu zřizovány pouze institucemi, které si mohly dovolit provozovat příslušnou infrastrukturu. To se změnilo s příchodem služeb nabízejících schránky pro širokou veřejnost avšak pod jejich doménou, tedy například hotmail.com nebo seznam.cz. Od té doby až dodnes se jednotliví vlastníci domén, kteří nemají vybudovanou potřebnou infrastrukturu, musí spoléhat na poskytovatele hostingových služeb, jenž ale často nabízí buď omezené nebo nekvalitní nebo drahé řešení. Přitom překážkou k vytvoření příslušné infrastruktury nejsou finance, nýbrž čas, protože kvalitní softwarová řešení jsou k dispozici zdarma, ale jejich konfigurace je poměrně složitá a vyžaduje mnohé odborné znalosti.

Hlavním cílem této diplomové práce je zlepšení předešlé situace vytvořením nového software, který využije v současnosti volně dostupná řešení služby elektronické pošty a umožní jejich snadnou instalaci a konfiguraci, takže i běžný uživatel a vlastník domény bude moci jednoduše vytvořit vlastní infrastrukturu pro provoz elektronické pošty. Výsledný software samozřejmě budou moci využívat také menší poskytovatelé hostingových služeb nebo správci počítačové infrastruktury u malých až středně velkých podniků. Všichni případní uživatelé ušetří mnoho času, který by jinak strávili studiem dokumentací a návodů k nastavení jednotlivých prvků poštovního systému, neboť primárním požadavkem této práce je nejvyšší možná míra automatizace instalačního procesu a pohodlné a intuitivní konfigurační rozhraní obsahující podrobný popis nastavitelných vlastností systému zajišťujícího elektronickou poštu. Podobný cíl si kladou i některé již existující programy, například program iRedMail, avšak mnoho z nich je zcela nebo alespoň částečně zpoplatněno nebo používají z mého pohledu nevhodné technologie a komponenty. Dílčím cílem této diplomové práce je použít pro výsledný software pouze technologie vytvořené pomocí programovacího jazyka Ruby, a tím kromě nového přístupu k instalaci a konfiguraci systému nabídnout i technologickou alternativu k existujícím řešením. Určitá omezení jsou kladena také na výběr jednotlivých prvků poštovního systému. Mělo by se jednat o osvědčené a volně přístupné programy, které budou plnit své role v systému efektivně a nebudou představovat bezpečnostní hrozbu pro systém jako celek. Ve výsledku by měl vzniknout komplexní stabilní systém zajišťující službu elektronické pošty, jenž se jednoduše uvádí do provozu, a poté se pohodlně konfiguruje prostřednictvím webového rozhraní.

Aby bylo možno tímto způsobem definovaný software vytvořit, je v prvé řadě nezbytné být seznámen s principy fungování elektronické pošty. První část textu diplomové práce je tudíž zaměřena na teoretické poznání základních funkčních principů elektronické pošty, která je dále doplněna o popis řešení některých problémů, s nimiž se většina provozovatelů služby musí potýkat. Na to navazuje část s návrhem systému, kde jsou popsány jednotlivé stavební komponenty a jejich propojení. Tím je předchozí teorie uvedena v praxi. Následující kapitola pojednává o implementaci instalačních skriptů a konfigurační aplikace a o technologiích, které přitom byly použity. V poslední části jsou pak uvedeny způsoby, jakými má být aplikace distribuována a prezentována, což je velmi podstatné, protože bez alespoň minimální uživatelské základny hrozí, že by aplikace upadala a její existence ztrácela smysl. Tatáž kapitola popisuje žádoucí směr, jímž by se měl výsledný software vyvíjet v blízké, ale i vzdálené budoucnosti.

Elektronická pošta jako služba

Přestože se fundamentální principy fungování a používání elektronické pošty vyučují už i na středních školách a obecně jsou poměrně známé, je nutno je uvést pro definování základních pojmů a lepší pochopení dalších souvislostí. Nejprve zde bude popsán základní model e-mailové služby a cesta, kterou musí projít zpráva od odesílatele k příjemci. Poté bude tento model rozšířen o prvky, které jednu z nejstarších internetových služeb zmodernizují do podoby použitelné ve druhé dekádě 21. století, kdy již k bezproblémovému zajištění služby nestačí pouhé doručení elektronické zprávy.

Základní principy elektronické pošty

Prvotním cílem e-mailu je přenos textové zprávy z počítače na jiný počítač, respektive od uživatele k jinému uživateli. Zní to jednoduše, ale aby byla služba spolehlivá (tj. aby byl e-mail vždy správně doručen), je potřeba vyřešit několik dílčích problémů. Mezi první problémy, které návrháři služby řešili, jistě patřily tyto:

Doplněno o další funkce, které se dnes považují za samozřejmost, jako například libovolný počet příjemců zprávy nebo netextové přílohy, vzniká komplexní služba, jejíž implementace není vůbec triviální.

Pro bližší představu lze složitost e-mailové služby neexaktně vyjádřit třeba počtem dokumentů RFC, které se k této službě vztahují. Podle webové stránky, jež se snaží RFC dokumenty třídit [RFC By Category] jich je k elektronické poště vztaženo asi 530, z čehož 54 se zabývá protokolem SMTP, 19 je vyhrazeno pro POP, 63 pro IMAP, 118 pro MIME, 9 se zabývá bezpečností přenosu zpráv, 28 protokolem X.400. Zbytek, tedy asi 240 RFC dokumentů, se týká přidaných funkcích jako například DKIM nebo řeší problém nevyžádané pošty, ovšem to už mluvíme o technologiích, které se nedají považovat za základní.

Z hlediska architektury je elektronická pošta agentní systém. Fundamentálními prvky modelu jsou MTA (Mail Transfer Agent), MDA (Mail Delivery Agent) a MUA (Mail User Agent), což jsou softwaroví agenti, kteří na základě vzájemné komunikace vykonávají určité akce v prostředí počítačové sítě.

Mail Transfer Agent

MTA (Mail Transfer Agent, také Mail Transport Agent, Message Transfer Agent, Mail Relay) je program, který se stará o přenos zprávy z jednoho počítače na druhý. Používá přitom komunikační protokol SMTP postavený na architektuře klient-server. Každý MTA v sobě zahrnuje obě zmíněné části, takže dokáže poštu přijímat i odesílat. Zprávy přebírá od MUA nebo od jiného MTA v síti a po zpracování je předává buď dalšímu MTA nebo MDA.

RFC 6409 z MTA zvlášť vyčleňuje MSA (Mail Submission Agent) jako agenta přijímajícího na portu 587 zprávy autentizovaného uživatele. Vyjma ověření identity odesílatele to může mít teoreticky další výhody jako například možnost rozdělit pravidla pro příjem pošty a filtrování nevyžádané pošty [rfc6409]. V praxi bývají MSA a MTA implementovaní v jediném programu.

Mail Delivery Agent

MDA (Mail Delivery Agent, též Message Delivery Agent, ovšem také Local Delivery Agent) je program, který zprávy ukládá na definované úložiště, či jinými slovy doručuje zprávy do poštovní schránky uživatele. Zprávy přebírá zásadně od MTA, ovšem komunikuje také s MUA, kterému přes protokoly POP nebo IMAP poskytuje data uživatelovy schránky.

Mail User Agent

MUA (Mail User Agent nebo pouze User Agent) tvoří uživatelské rozhraní pro elektronickou poštu. Konceptuálně se tento prvek systému dá rozdělit na dva dílčí prvky, jimiž jsou MSA (Mail Submission Agent, který pomocí SMTP odesílá zprávy ke známému MTA, a MRA (Mail Retrieval Agent), který přes protokoly POP či IMAP přijímá data od svého MDA. MUA je to, co si většina lidí představí pod pojmem e-mail nebo pod souslovím poštovní klient.


Každá zpráva v rámci elektronické pošty musí minimálně jednou projít všemi výše zmíněnými prvky systému. Pokud chce uživatel elektronické pošty poslat zprávu jinému uživateli, použije svůj MUA, což bývá nejčastěji nějaký e-mailový klient. Po odeslání zpráva putuje nejprve k příslušnému MTA, který se podívá na adresu příjemce a pomocí služby DNS zvolí nejvhodnějšího MTA, kterému zprávu předá. V ideálním případě se hned jedná o MTA, jenž doručuje zprávy do domény, pod kterou spadá příjemce, a proto zprávu předá MDA, jinak tento druhý MTA opět hledá nejvhodnějšího MTA. MDA poté přesně identifikuje příjemce a zprávu uloží do jeho schránky. Příjemce si zprávu může přečíst poté, co prostřednictvím svého MUA požádá MDA o stažení nových zpráv ve schránce.

Zprávy jsou mezi jednotlivými agenty předávány buď pomocí meziprocesové komunikace nebo skrz komunikační protokoly navržené přímo pro tento účel. Obecně by se dalo říct, že existují dvě třídy komunikačních protokolů elektronické pošty, odesílací a přístupové. Základním (ale ne jediným) protokolem pro odesílání pošty je bezesporu SMTP (Simple Mail Transfer Protocol), jehož první definice byla v roce 1982 zapsána pomocí RFC 821. Většina poskytovatelů e-mailových služeb nabízí SMTP ve zmodernizované podobě jako jediný odesílací protokol. Pro přístup ke schránce však bývají (často souběžně) nabízeny protokoly dva: POP (Post Office Protocol) s definicí první verze v RFC 918 z roku 1984 a IMAP (Internet Message Access Protocol), který je definován až jako druhá verze v RFC 1064 z roku 1988. V současnosti se používá POP verze 3 (POP3) a IMAP verze 4 revize 1 (IMAP4rev1).

Pro lepší pochopení fungování elektronické pošty jsou zde blíže popsány nejen tři zmíněné protokoly, ale také protokol MIME (Multipurpose Internet Mail Extensions), který rozšiřuje formát přenášené zprávy tak, že je možno používat ve zprávě diakritiku a posílat binární soubory.

SMTP

SMTP je protokol aplikační vrstvy ISO/OSI, který zajišťuje přenos zpráv elektronické pošty od odesílatele do příjemcovi schránky. K tomuto účelu využívá spolehlivý transportní protokol TCP, v jehož rámci má rezervován číslo portu 25 (nebo 587 pro autentizovaný přístup). Systém elektronické pošty používá SMTP pro doručení zprávy od UA k jemu známému MTA a pro předávání zprávy mezi jednotlivými MTA v počítačové síti. K tomuto účelu je definováno několik jednoduchých textových povelů, za kterými následují určitá data, a několik stavových kódů, které slouží jako odpovědi na povely. SMTP tedy funguje na principu klient-server.

Do RFC 2821 z roku 2001, které nahrazuje původní RFC 821, byla přidána specifikace formátu zprávy. Ta se skládá z hlavičky a těla, přičemž tělo může obsahovat text a volitelně také libovolný počet příloh.

SMTP se dočkal několika vylepšení jako například možnost posílat zprávy obsahující 8-bitové znaky (původní SMTP používá pouze 7-bitovou znakovou sadu), šifrované spojení nebo tzv. chunking, což je možnost posílat zprávu po kouscích. Výčet většiny rozšíření je například na encyklopedické stránce [ESMTP]. Rozšířený SMTP se označuje jako ESMTP (Extended Simple Mail Transfer Protocol) a většina současných e-mailových serverů používá právě jej, avšak ne každý server implementuje či dovoluje používat všechna dostupná rozšíření. Klient dokáže rozlišit oba protokoly díky přidanému povelu EHLO (Extended Hello). Pouze ESMTP server reaguje na EHLO, přičemž nejčastější odpovědí je výpis všech implementovaných a povolených rozšíření. SMTP server vrací chybový kód, na což každý dobrý klient reaguje původním povelem HELO, zatímco špatný klient ukončí sezení povelem QUIT a zprávu neodešle.

POP

Post Office Protocol je původní a stále používaný protokol pro příjem pošty z e-mailové schránky do klientského programu. Jedná se o protokol aplikační vrstvy ISO/OSI pracující nad protokolem transportní vrstvy TCP, ve kterém se identifikuje číslem portu 110. Podobně jako SMTP i POP funguje na principu klient-server.

V současné době se používá téměř výhradně POP verze 3 neboli POP3, který se od svých předchůdců liší dokonce i konceptuálně. Původní POP3 měl ve specifikaci pouze autentizaci s nezabezpečeným heslem, avšak nyní existuje hned několik způsobů autentizace uživatele na POP3 serveru a spojení může probíhat i šifrovaně. POP3 se šifrovaným spojením se označuje jako POP3S a obvykle probíhá přes TCP port 995.

POP je velmi jednoduchý protokol a většinou funguje tak, že klient stáhne všechny dostupné zprávy k sobě a na serveru je vymaže. Nastavení však také dovoluje zprávy na serveru ponechat, stahovat pouze hlavičky zpráv a následně stáhnout jen zprávy podle požadavku klienta. Nevýhoda zmíněného nastavení se projeví u schránek s velkým množstvím e-mailů, kde se bude po síti přenášet poměrně velké množství dat. Nevýhodami protokolu jsou nemožnost třízení pošty do složek vytvořených na straně serveru a nutnost stahování celých zpráv včetně všech příloh.

IMAP

IMAP je druhý ze dvou v současnosti nejpoužívanějších protokolů pro příjem pošty. Stejně jako obou předchozích protokolů se jedná o aplikační klient-server protokol nad TCP využívající port 143 či při použití zabezpečeného přenosu dat port 993 (potom se jedná o protokol IMAPS).

Narozdíl od POP uchovává zprávy na serveru, stahuje vždy pouze nezbytně nutné informace a povoluje vytvářet složky na straně serveru. Pro práci s poštou je možno připojit současně více klientů, kteří mohou pracovat v off-line nebo v on-line režimu. On-line režim udržuje aktivní spojení klienta se serverem, který jednotlivě vykonává pouze jednoduché akce jako například výpis složky, zobrazení či smazání e-mailu, přesun zpráv do jiné složky nebo třeba filtraci zpráv podle kritéria. Zprávy jsou přenášeny výhradně ve formátu MIME, což umožňuje přenášet pouze jednotlivé části zpráv a tím celý přenos zrychlit.

Protokol se všemi těmito schopnostmi je ovšem složitý na implementaci, takže v ní lze snadno udělat chybu. Také může nastat problém s efektivitou některých operací (např. filtrováním zpráv,) které mohou u velkých schránek přespříliš zatěžovat server. Pravděpodobně i tyto důvody přispěly k tomu, že ještě před pár lety nebyl IMAP mezi poskytovateli e-mailové služby žádným standardem, ale spíše výjimkou.

MIME

Multipurpose Internet Mail Extensions tvoří velmi důležitou součást elektronické pošty především proto, že umožňuje psát zprávy i v jiných znakových sadách než je ASCII. Text e-mailu bez MIME totiž používá striktně sedmibitovou znakovou sadu, což například zabraňuje použití celé abecedy českého jazyka. Internetový standard MIME je popsán především v RFC 2045 a jak plyne z názvu, jeho hlavním principem je víceúčelovost. MIME formát elektronických zpráv rozšiřuje o

V oblasti elektronické pošty je stále více používána také speciální verze S/MIME (Secure/MIME), která zajišťuje kryptografické zabezpečení zpráv, hlavně integritu a nepopiratelnost původu pomocí elektronického podpisu [rfc5751].

Řešení problémů spojených s provozem služby

Asynchronní komunikace přes Internet založená na výše uvedených principech se poměrně rychle zabydlela u akademických institucí, komerčních subjektů a logicky i v nabídce hostingových služeb. Ovšem až s příchodem bezplatných e-mailových služeb ve druhé polovině 90. let 20. století se e-mail masivně rozšiřuje mezi uživatele internetu a počet odesílaných a přijímaných e-mailových zpráv rapidně zrychluje svůj růst až dodnes.

Avšak ne všechny e-maily jsou odesílány s čistým úmyslem. Lidé tuto službu zneužívají pro hromadné rozesílání nevyžádaných komerčních sdělení, tzv. UBE (Unsolicited Bulk Email) [UBE] nebo pro šíření škodlivých programů, např. počítačových červů. Vůbec se přitom nejedná o marginální problém. V současnosti se uvádí, že významná většina e-mailových zpráv procházejících Internetem je SPAM, jak se také nevyžádaná či škodlivá pošta označuje. Na omezení dopadů nevyžádané pošty je provozovateli e-mailových služeb vynakládáno velké množství finančních prostředků.

Závažným problémem je také podvrhování identity odesílatele, označované jako e-mail spoofing, které jde ruku v ruce s podvodným jednáním známým jako phishing (česky pojmenováno jako rhybaření). Pro všechny instituce poskytující e-mailové služby by měla být prevence těchto internetových podvodů samozřejmostí, jelikož pomáhá chránit identity uživatelů a také odhalit zdroje tohoto podvodného jednání.

Následující část diplomové práce naznačuje, jaká preventivní opatření by měl každý poskytovatel emailových služeb učinit, aby před uvedenými problémy více či méně úspěšně ochránil sebe i své uživatele. Protože některá opatření mohou řešit současně více problémů, je kapitola rozdělena na jednotlivá existující řešení, u nichž je pak zmíněno, na co jsou zaměřena.

SMTP autentizace

Takřka celou poslední dekádu 20. století byla většina SMTP serverů (MTA) tzv. open relay, což znamená, že přes ně mohl kdokoliv posílat e-maily [OpenRelay]. Dnes je open relay serverů minimum, protože jsou vyhledávány pro rozesílání nevyžádané pošty, takže se často dostávají na černé listiny (seznamy zapovězených serverů, viz dále) a také je na ně kladena velká výpočetní zátěž. Správně nastavený moderní poštovní server zpracovává jen poštu svých uživatelů a v případě, že se uživatelé mohou připojit k serveru odkudkoliv ze sítě Internet, musí (dle RFC 6409) poskytovatel zajistit nějaký autentizační mechanismus.

Za tímto účelem RFC 4954 standardizuje rozšíření AUTH protokolu SMTP (zkráceně SMTP-AUTH či ESMTPA), které do komunikace klienta se serverem přidává nový krok, při němž dochází k autentizaci klienta. Podporu tohoto rozšíření dává server najevo v prvé řadě tím, že pro komunikaci s MUA naslouchá na portu 587 namísto původního portu 25, který v tom případě slouží výhradně pro doručující MTA. Server sděluje podporu rozšíření AUTH (včetně výpisu podporovaných autentizačních mechanismů) i v odpovědi na klientův příkaz EHLO. Součástí autentizace obvykle bývá zahájení šifrované komunikace přes protokol TLS z důvodů ochrany uživatelova hesla, přičemž šifrované spojení je započato klientem buď ihned, nebo až v průběhu komunikace přes příkaz STARTTLS [tls]. Nutno však podotknout, že šifrovaná komunikace nevyplývá z definice rozšíření AUTH, nýbrž je implementovaná jako samostatné rozšíření protokolu SMTP.

Samotná autentizace probíhá přes vrstvu označovanou akronymem SASL (Simple Authentication and Security Layer, RFC 4422). Jedná se o systém pro ověřování a bezpečnost dat v protokolech aplikační vrstvy ISO/OSI, které před komunikací vytvářejí spojení (connection-oriented protocols). SASL funguje jako rozhraní mezi protokolem a rozšiřitelnou sadou použitelných autentizačních mechanismů, z nichž je možno vybrat ty, jež budou serverem podporovány a ze kterých klient bude moci volit pro ověřovací proces. V současné době je na výběr bezmála třicet autentizačních mechanismů [SASL Mechanisms], zahrnujíce napříkad

SMTP-AUTH se SASL není jediným řešením pro ověření práva použít server za účelem odeslání zprávy. Mezi další možnosti náleží použití elektronického podpisu, služby RADIUS nebo aplikace POP before SMTP. Autentizace odesílatele pošty je v každém případě velmi žádoucí, protože snižuje pravděpodobnost zneužití serveru pro odesílání SPAMu a případně umožňuje odhalit a zablokovat uživatele, který nevyžádanou poštu odesílá.

DKIM a SPF

DKIM (DomainKeys Identified Mail) a SPF (Sender Policy Framework) jsou mechanismy pro ochranu před podvrhováním adresy odesílatele.

V základním konceptu e-mailové služby nelze zabránit uvedení falešné adresy odesílajícího, což je bezpečnostní problém z hlediska autenticity a integrity e-mailů. V praxi je tato vlastnost zneužívána především při rozesílání nevyžádané pošty (např. z napadených PC), v rámci sociálního hackerství a marginálně také za účelem zesměšnění nějaké osoby. Za dostatečnou ochranu proti podvržení adresy odesílatele se považuje ověření, že zpráva byla odeslána z adresy (domény), kterou je odesílatel oprávněn používat. Právě DKIM a SPF toto ověření, každý svým vlastním způsobem, zajišťují, přičemž oba mechanismy k tomu využívají doplňující DNS záznam.

SPF (definováno v RFC 4408) přiřazuje každé doméně adresy SMPT serverů, které jako jediné mohou pro tuto doménu odesílat poštu. Jedná se o poměrně jednoduchý mechanismus, ovšem aby správně fungoval, musí jej podporovat obě strany, tedy odesílatel i příjemce. Příjemci ke kontrole stačí pouze hlavička zprávy a pár DNS dotazů. Za největší nevýhodu se považuje omezení odesílatele pouze na SMTP servery, jejichž adresy jsou uvedeny v DNS záznamu domény. To může znemožnit přeposílání e-mailů, protože je při něm zpráva odeslána z jiné adresy, než jaká je v DNS [spf].

DKIM (v RFC 4686, 4871, 5617 a dalších) pro ověření používá elektronický podpis, tedy asymetrickou kryptografii. Nejedná se však o podpis uživatele, nýbrž o podpis SMTP serveru, který svým soukromým klíčem podepíše jisté části obsahu zprávy spolu s doménou, ze které e-mail pochází. Příjemce poté může ověřit elektronický podpis pomocí veřejného klíče umístěného v DNS záznamu domény [dkim]. Jak příjemce naloží s neověřeným e-mailem již DKIM nedefinuje, avšak vlastník domény má možnost použít doplňující standard ADSP (Author Domain Signing Practices, RFC 5617) [adsp] a zveřejnit tak svou podpisovou politiku, podle které by se měl příjemce řídit. ADSP definuje tři podpisové politiky:

Podpisová politika discardable je účinná ochrana proti podvodným zprávám, čili phishingu, protože všechny servery podporující DKIM ihned zahodí každý nesprávně podepsaný e-mail. Pokud příjemce DKIM nepodporuje, tak jednoduše neprobíhá žádná kontrola elektronického podpisu a všechny e-maily jsou doručeny. Výhodou DKIM oproti SPF je, že zpráva se správným elektronickým podpisem může být odeslána z libovolného SMTP serveru, takže nic nebrání jejímu přeposlání a současném zachování ochrany.

Žádný ze dvou uvedených mechanismů z principu nepředstavuje ochranu před nevyžádanou poštou. Avšak oba umožňují ověřit pravost odesílatele, takže chrání před podvodnými zprávami a zneužitím domény pro nevyžádanou poštu.

Filtrování nevyžádané pošty

Nevyžádaná pošta je asi největší problém, se kterým se musí poskytovatelé e-mailové služby potýkat. Přestože v současné době existuje poměrně velké množství technik [Anti-spam techniques], jejichž cílem je odmítat nebo filtrovat nevyžádanou poštu, žádná jednotlivá z nich není úplným řešením problému, avšak dobrých výsledků lze dosáhnout jejich vhodně zvolenou kombinací. Jedná se v prvé řadě o techniky algoritmické kontroly chování, vlastností a reputace odesílajícího MTA, jako například striktní vyžadování správnosti protokolu, technika dočasného odmítnutí přijetí (greylisting) nebo použití dostupných černých a bílých listin ke zjištění, zda MTA má či nemá pověst původce nevyžádané pošty. Současně se provádí různé kontroly obsahu, například jednoduché hledání slov a frází nebo poměrně efektivní Bayesovo filtrování, které se učením přizpůsobuje potřebám uživatele [Better Bayesian Filtering].

Převážná část metod filtrování nevyžádané pošty má více než jednu implementaci. Mnoho z nich je volně dostupných včetně zdrojových kódů, avšak existují i komerční řešení, takže také v tomto ohledu má poskytovatel poštovní služby možnost výběru. Existují také filtry dostupné v podobě produktů typu SaaS (Software jako služba).

Zabezpečení proti počítačovým virům

Společně s nevyžádanou poštou mohou přicházet také virem infikované zprávy. Viry se ukrývají v binárních přílohách elektronických zpráv, kde čekají až je uživatel otevře, a tím spustí jejich zákeřný kód. Komplexní řešení problému je nedosažitelné podobně jako u nevyžádané pošty. V minulosti se vynakládalo velké množství finančních a technologických prostředků na kontrolu zpráv pomocí antivirových programů, avšak v současnosti se od toho přístupu pomalu ustupuje, neboť je velká pravděpodobnost, že infikovaná zpráva je současně nevyžádaná, a proto se více úsilí zaměřuje na filtrování nevyžádaných zpráv [NoAV]. Pravdou však zůstává, že i když poskytoval poštovního serveru nekontroluje obsah zpráv, stále by měl dbát na systémovou bezpečnost a provádět ve své infrastruktuře antivirové kontroly. Pokud by se poskytovatel služby rozhodl kontrolovat příchozí zprávy pomocí antivirového programu, má možnost jej zvolit z rozsáhlé nabídky komerčních produktů nebo z malé nabídky volně dostupných antivirových řešení, kde si dobrou pověst vybudoval program ClamAV.

V případě počítačových virů šířených pomocí elektronické pošty se samostatně mohou bránit i jednotliví uživatelé. Mají možnost nasadit na svých počítačích vlastní antivirový software, který je schopen kontrolovat jejich příchozí poštu, především by však měli dodržovat jistá preventivní opatření, například neotvírat přílohy od neznámých odesílatelů. Tato prevence ovšem vyžaduje dobrou informovanost uživatelů, na niž má nemalý a neoddiskutovatelný vliv také poskytovatel, který by měl informace uživatelům poskytnout.

Návrh systému

V tomto bodě by mělo být jasné, co všechno je součástí moderní služby zajišťující elektronickou poštu, takže dalším praktickým krokem je určit, jak službu uvést do provozuschopného stavu.

Současná doba poskytuje solidní nabídku dílčích komponent a řešení, které se dají poskládat v jeden komplexní e-mailový systém a které jsou často navíc volně k dispozici včetně zdrojových kódů. Jedná se o léty prověřené programy, které implementují agenty a protokoly zmíněné v předchozí kapitole či řeší tamtéž uvedené problémy. Představením vybraných programových komponent i jejich alternativami se po úvodním komentáři k systému jako celku zabývá první část této kapitoly. V dalších částech je pak pojednáno o způsobu, jakým jsou jednotlivé prvky v systému propojeny a jak jsou nastaveny, aby vzájemně spolupracovaly, a tím zajišťovaly nejlepší možnou službu. Nakonec je popsáno schéma, podle kterého bude systém přistupovat k nekorespondenční (tj. ne-dopisní) části persistentních dat.

Z celkového pohledu je produktem dynamický systém, u nějž se na nejvyšší úrovni dají rozlišit tři subsystémy. Těmito subsystémy jsou poštovní systém, prezentační systém a systém řízení báze dat. Na obrázku č. 3.1 jsou zmíněné subsystémy zobrazeny včetně vzájemného propojení systémů naznačeného pomocí šipek. Systém řízení báze dat je na obrázku označen jako PostgreSQL, což je název konkrétního programu, jenž bude funkce systému řízení báze dat provádět. PostgreSQL v systému slouží zaprvé jako prostředek pro sdílení informací mezi poštovním systémem a prezentačním systémem; zadruhé jako úložiště dat specifických pro jednotlivé komponenty systému, což je popsáno dále u každé relevantní komponenty. Poštovní systém a prezentační systém jsou pouhou návrhovou abstrakcí, jež vznikla při analýze a jejímž přínosem je snadnější modelování soustavy. Základními stavebními kameny těchto subsystémů, potažmo tedy systému jako celku, jsou programové komponenty, které obrázek č. 3.1 zobrazuje jako oválné útvary nesoucí název programu vykonávajícího v systému nějaké služby, např. Dovecot nebo Nginx. Zvláštní komponentou v systému je Aplikace, na obrázku je od ostatních komponent odlišená v podobě kvádru uvnitř prezentačního systému. Aplikace označuje naprogramovanou část produktu, který popisuje tato práce zejména v následujících kapitolách. Tato komponenta je navržena jako webová aplikace umožňující správci systému změnu konfigurace všech ostatních komponent buď přímo prostřednictvím vlastních rutin, nebo pomocí úprav sdílených dat uložených v databázi.

Prezentační systém Aplikace Nginx Awstats PostgreSQL E-mailový systém Postfix Dspam Postscreen Amawis Spamassassin Dovecot Mění konfiguraci
Obrázek 3.1: Grafické znázornění systému. Zdroj: autor

Také z hlediska interakce systému s uživatelem je výhodné použít model s poštovním systémem a prezentačním systémem, protože každý z nich komunikuje s okolím jiným způsobem. Poštovní systém s okolím interaguje pomocí agentů a protokolů uvedených v předchozí kapitole. O tuto různorodou a poměrně složitou komunikaci se starají programové komponenty Postfix a Dovecot. Zbylé komponenty poštovního systému, jmenovitě Postscreen, OpenDKIM (na obrázku nezobrazen), Dspam, Spamassassin a Amawis, se starají o ochranu systému před neautorizovaným či abusivním použitím. Prezentační systém má interakci systému s uživatelem jednodušší, jelikož používá pouze protokol HTTPS. Komunikaci obsluhuje komponenta Aplikace, která je podle současných trendů postavena podle architektury klient-server a umožňuje synchronní i asynchronní výměnu HTML a JSON dokumentů. Komponenty Nginx a Awstats jsou v prezentačním systému jen podpůrnými prostředky a interakci s uživatelem ovlivňují minimálně.

Interakci systému s uživatelem dobře vystihují jednotlivé případy užití. Obrázek č. 3.2 ukazuje velmi zjednodušený, avšak názorný diagram případů užití systému. Účastníci (či aktéři, podle anglického actors z terminologie UML) jakékoliv interakce se systémem jsou buď uživatelé služby nebo správcové služby. Uživateli služby se stávají nejen všichni lidé používající elektronickou poštu prostřednictvím zde navrženého poštovního systému, ale potencionálně také veškeré počítačové programy, které jsou schopné doručovat validní elektronické zprávy pomocí počítačové sítě. Fakt, že uživatelé služby mohou být počítačové programy, tvoří jeden z rozdílů mezi uživateli služby a správci služby, neboť správcem služby by měl být pouze člověk (což se může v budoucnu změnit). Další rozdíl spočívá v subsystému, který účastník používá. Zatímco uživatel služby používá výhradně poštovní systém, správce služby pracuje pouze se systémem prezentačním. Navíc platí, že kdykoliv správce služby použije poštovní systém stává se uživatelem služby, ovšem není možné, aby se libovolný uživatel služby stal správcem služby, protože není možné, aby byl správcem služby počítačový program.

Uživatel služby Správce služby Spravuje domény, schránky a přesměrování Mění konfiguraci serveru Spravuje uživatele a jejich pravomoci Používá SMTP, POP3, IMAP Používá webmail Prohlíží si logy a statistiky
Obrázek 3.2: Případy užití aplikace. Zdroj: autor

Na obrázku č. 3.2 je zvýrazněn případ užití pro uživatele služby Používá webmail, a to ze dvou důvodů. Prvním důvodem je nezahrnutí tohoto případu užití do implementace systému, přestože existují hotová řešení webmailu, tedy webového MUA. Žádné z nich není v této práci použito, neboť se nejedná o klíčovou funkci vzhledem k celkové funkčnosti systému. Druhým důvodem je, že se jedná o speciální případ užití, výjimku, kde by uživatelem služby neměl být počítačový program.

Dosud bylo v tomto úvodu málo řečeno o systému řízení báze dat, PostgreSQL, který byl představen jako třetí základní pilíř celé soustavy, což bylo z jistého pohledu návrháře výhodné. Tento subsystém se ale od obou abstraktních subsystémů v mnoha ohledech liší. Nejenže nikdy neinteraguje s okolím soustavy, nýbrž pouze s jednotlivými programovými komponentami uvnitř, ale především sám za programovou komponentu může být považován, protože má všechny její, dále v textu definované, vlastnosti. Díky tomu je popis PostgreSQL uveden vedle popisů ostatních komponent.

Komponenty systému

Základními konstrukčními prvky navrhovaného systému jsou programy vykonávající jisté systémové služby, přičemž v současné době platí, že pro jednu systémovou službu existuje několik různých programů, které službu mohou zajišťovat, a každý z těchto programů má určitá svá specifika, klady a zápory. V textu jsou takové programy označovány jako programové komponenty, případně jednoslovně jako komponenty. Při návrhu systému zajišťujícího elektronickou poštu je výběr správných programových komponent velmi důležitý, protože specifické vlastnosti každé z komponent se mohou projevit na vlastnostech výsledné soustavy, a také ne všechny programy jsou uzpůsobené pro vzájemnou spolupráci, přestože většina z nich komunikuje pomocí standardizovaných komunikačních protokolů. Hlavními kritérii pro výběr programových komponent zajišťujících z hlediska elektronické pošty obligatorní systémové služby jsou

Tato výběrová kritéria by ve výsledku měla zajistit, že použité programy budou v nejvyšší možné míře bezpečné, efektivní a stabilní, přičemž nebudou obsahovat malware nebo záviset na složitých softwarových strukturách, které by využívaly nepřiměřené množství systémových prostředků.

Téměř úplný výčet vybraných programových komponent již byl uveden na obrázku č. 3.1. Každý z těchto základních stavebních prvků navrhovaného systému elektronické pošty si ovšem zaslouží zvláštní pozornost a uvedení důvodů k zařazení do systému. U některých komponent bude také podrobněji vysvětlen princip jejich fungování, čímž bude rozšířeno pojednání o řešení problémů spojených s provozem služby elektronické pošty.

PostgreSQL

Díky svému specifickému zařazení v systému bude jako první popsána programová komponenta, která zajišťuje uložení persistentních systémových dat.

PostgreSQL je objektově-relační systém řízení báze dat (ORDBMS) aktivně vyvíjený komunitou lidí a firem pro platformu Unix/Linux. Produkt užívá stejnojmennou Open Source licenci podobnou licencím BSD nebo MIT [PostgreSQL: Licence], jež dovoluje libovolné a bezplatné využití, modifikaci či distribuci. S minimálními závislostmi nabízí PostgreSQL možnost vytvoření technologicky velmi pokročilého a výkonného databázového systému, který je plně kompatibilní se všemi interagujícími komponentami v navrhovaném systému elektronické pošty. Programové komponenty využívající PostgreSQL jsou

Systém řízení báze dat je v navrhovaném systému kriticky důležitá a velmi vytěžovaná komponenta, neboť je využita téměř při každém požadavku klienta na server. Programové komponenty Postfix a Dovecot, které jsou klíčové pro zajištění služby elektronické pošty, využívají pouze čtení dat, zatímco komponenty Dspam a aplikace pro správu systému data čtou i zapisují, ale mají jen fakultativní funkce, takže se bez vážných problémů dají vypnout. Důležitost předešlého poznatku se vyjasní v případě dlouhodobé velké vytíženosti serveru, kdy přestane stačit daná hardwarová kapacita. Řešením výkonnostního problému může být, namísto replikace celého poštovního systému, replikace dat, v čemž PostgreSQL vychází vstříc svou podporou synchronní i asynchronní replikace.

Alternativně lze použít program MySQL, z nějž se ovšem po akvizici firmou Oracle stal komerční produkt, či z MySQL odvozený a svobodný program MariaDB. Oba programy by měly být kompatibilní se všemi závislými komponentami.

Postfix

Následují komponenty poštovního subsystému.

Program Postfix v systému zajišťuje agenty MTA a MSA, takže je výkonným jádrem, které řídí přijímání a doručování elektronické pošty. Prostřednictvím různých komunikačních kanálů volá ostatní programové komponenty ke spolupráci na filtrování a ukládání uživatelské pošty, což je popsáno dále v textu. Postfix splňuje všechna výběrová kritéria a považuje se za rychlý a bezpečný. Informace o doménách, schránkách a přesměrování může získávat z mnoha typů datových úložišť, přičemž v navrhovaném systému je k tomuto účelu použito PostgreSQL.

Při výběru MTA byly dalšími volbami programy Sendmail a Exim. Zatímco Sendmail je poměrně zastaralý, Exim je velmi moderní a oblíbený. Konečné dilema Exim-Postfix rozhodla struktura konfiguračních souborů každého z programů, která je u Postfix subjektivně jednodušší.

Dovecot

Dovecot je poslední ze tří skutečně obligatorních komponent. Zbylé komponenty nejsou vitálně důležité pro zajištění základních služeb elektronické pošty.

Původním účelem programu byl bezpečný provoz serveru pro protokoly IMAP a POP3, avšak současné možnosti zahrnují také zprostředkování SASL pro MSA (Postfix), službu uživatelského filtrování zpráv (Sieve), službu kontroly velikosti schránek (Quota) a další. V poštovním systému je program implementací MDA, která může uživatelskou poštu ukládat pomocí vícero formátů: Maildir, mbox a dbox. Maildir nebo dbox jsou rozumné volby, přičemž dbox je o dost mladší, rychlý formát podporovaný pouze programem Dovecot, což by v zájmu lepší přenositelnosti dat mělo ospravedlnit výběr formátu Maildir pro navrhovaný systém [DovecotFormats].

Dovecot se všemi funkcemi, které systému nabízí, má jedinou přijatelnou náhradu, jíž je program Cyrus. Cyrus však nemá tak dobrou dokumentaci jako Dovecot a celkově se zdá, že Dovecot je populárnější.

Postscreen

Ne náhodou se název komponenty Postscreen podobá názvu Postfix, neboť se jedná o závislou komponentu, za kterou by bylo třeba najít náhradu, pokud by se místo programu Postfix použil např. Exim. Postscreen se pomocí sady testů snaží eliminovat připojení, která by mohla vést ke zneužití poštovní služby. Jedná se o připojení tzv. zombie počítačů, kde je spuštěn malware rozesílající nevyžádanou poštu (UBE). Testy nekontrolují obsah zpráv, nýbrž například to, zda klient nepředbíhá komunikaci za účelem zvýšení rychlosti rozesílání. Aby byla kontrola rychlejší, vede si Postscreen vnitřní bílou listinu pro klienty, kteří úspěšně prošli všemi testy. Výsledným efektem eliminace připojení ze zombie počítačů je minimalizace zátěže kladené na server, což dále implikuje rychlejší odbavení legitimních klientů.

Za tuto komponentu není známa žádná přímá náhrada, avšak existují programy, které mohou poskytovat podobnou službu. Podobným, ale diskutabilním [Disadvantages of Greylisting] přístupem k problému je tzv. greylisting, šedá listina. Ta funguje tak, že zprávu od neznámého klienta nejdříve odmítne, a poté čeká, zda se klient znovu pokusí o její doručení. Tento princip vychází z předpokladu, že se MUA na zombie počítači nepokusí o opětovné zaslání zprávy.

OpenDKIM

Komponenta OpenDKIM sice na obrázku č. 3.1 není zobrazena, ale je součástí poštovního subsystému, kde zprostředkovává službu, která u příchozích zpráv kontroluje správnost DKIM podpisu a odchozí zprávy podepisuje. Tato komponenta je distribuována jako softwarová aplikace pod revidovanou BSD licencí, nemá žádnou závislost na jiných programech a dokáže spolupracovat se všemi MTA, které podporují tzv. milter protocol.

Snad jedinou alternativou k tomuto programu by mohlo být využití konceptu DKIM Core, což není program, ale způsob použití méně komplexní varianty mechanismu DKIM.

Dspam

Dspam je adaptivní filtr nevyžádaných příchozích zpráv, který má mnoho žádoucích vlastností a splňuje všechna kladená kritéria. Pracuje na principu kontroly obsahu podle znalostí, které se sám učí ze starých údajů o filtrování, takže jeho efektivita roste s časem. Nevýhodou v tomto případě je, že krátce po spuštění má filtr efektivitu nízkou, a je potřeba, aby uživatelé dbali na označování nevyžádané pošty a tím pomáhali rozšiřovat bázi znalostí programu. Tvůrci udávají statistickou přesnost dobře naučeného systému více než 99,5\%, zatímco je využito minimum hardwarových prostředků. Dspam svá persistentní data může uchovávat buď pomocí vlastního typu úložiště nebo pomocí některého z podporovaných systémů řízení báze dat, což přímo vyzývá k použití programové komponenty PostgreSQL v navrhovaném systému. Z hlediska propojení na další komponenty v poštovním systému se jedná o velmi univerzální program, jenž by měl spolupracovat téměř s každým MTA i jako SMTP brána.

Za alternativní programy pro tuto komponentu se dají považovat téměř všechny antispamové aplikace. Dspam stejně jako jiné filtry nepoužívají jeden test, ale kombinace různých testů. Program Dspam byl za komponentu v navrženém systému zvolen, protože by měl mít velmi dobrou přesnost a neměl by vytvářet velkou výkonnostní zátěž.

Amavisd

V návrhu poštovního systému se nepočítá s žádným antivirovým programem, přesto může být žádoucí jej v určitých případech integrovat. Programová komponenta Amavisd může tvořit rozhraní mezi MTA (Postfix) a desítkami antivirových nebo antispamových programů. Díky svému volně šířenému zdrojovému kódu, systémové kompatibilitě a mnoha nabízeným možnostem boje proti nežádoucím e-mailům je Amavisd začleněn do navrhovaného systému jako volitelná programová komponenta, kterou se uživatel může rozhodnout deaktivovat. Nevýhodou tohoto programu jsou totiž vyšší nároky na výkon hardware.

Amavisd je jedinečný program usnadňující integraci velkého množství programů pro filtrování pošty a nejčastěji se používá v kooperaci s jinými programy, které ovšem většinou lze integrovat i bez něj.

Spamassassin

Dalším filtrem nevyžádané příchozí pošty v navrhovaném systému je Spamassassin. Do systému je integrován jako modul komponenty Amavisd. Provádí kontrolu obsahu zpráv pomocí různých technik, mezi něž patří hledání frází pomocí regulárních výrazů nebo Bayesovský filtr (podobně jako Dspam), avšak může provádět i kontrolu informací o odesílateli pomocí DNS. Každý test zprávy má různou váhu, přičemž váhy se sčítají a tvoří výsledné skóre, podle kterého se dále rozhoduje, zda bude či nebude zpráva označena jako nevyžádaná. Spamassassin má bohatou nabídku nastavení a umožňuje i uživatelsky specifické volby. Podobně jako v případě Amavisd může použití této komponenty příliš vytěžovat hardwarové prostředky.

Spamassassin se funkčně částečně překrývá s komponentou Dspam. Zde je ponechána možnost volby správci poštovního systému, aby se sám rozhodl, zda nechá aktivovanou kontrolu zpráv pomocí obou programů, nebo bude využívat pouze jeden či žádný z nich.

Nginx

Poslední dvě programové komponenty jsou prvky prezentačního subsystému a nijak se nepodílí na bezprostředním zajištění služby elektronické pošty.

Nginx je výkonný multiplatformní webový server a reverzní proxy server vydaný pod upravenou svobodnou licencí BSD, jehož cílem je obsluha maxima požadavků s minimálními nároky na operační paměť. V navrhovaném systému komponenta zajišťuje HTTP proxy pro webový server konfigurační aplikace určené správcům, avšak v budoucnu může být použita i pro aplikaci webové pošty nebo zpřístupnění jakéhokoli jiného obsahu přes protokol HTTP. Jednou z klíčových vlastností komponenty je možnost obsluhovat také protokoly zabezpečené pomocí SSL, čehož by měla konfigurační aplikace využívat.

Nejznámější alternativou je webový server Apache, který ale nedokáže zpracovat tolik souběžných připojení jako Nginx [Apache vs. Nginx]. Vedle velmi používaného Apache by byly kompatibilními náhradami také např. Cherokee nebo Lighttpd.

AWStats

Návrh prezentačního systému počítá také s přehledem statistik o činnosti poštovního serveru. AWStats k tomuto účelu analyzuje logovací soubory programové komponenty Postfix a výstup upraví do formy webové stránky zobrazující tabulky a grafy. Pro průběžnou aktualizaci statistik poté stačí průběžné spouštění analytického programu, např. jednou denně.

Tato komponenta není závislá na žádné jiné komponentě v navrhovaném systému, takže na jejím místě lze použít téměř jakýkoliv program, který provádí analýzu logovacích souborů poštovního serveru. Předností programu AWStats je poměrně velká rozšířenost a pokračující vývoj.

Propojení komponent v kooperaci

Jednotlivé komponenty navrhovaného systému by byly nepoužitelné, kdyby nebyly vzájemně provázány a nespolupracovaly na společném cíli, jímž je zajištění služby elektronické pošty a její konfigurace. Na tomto místě je potřeba najít optimální propojení programových komponent tak, aby systém bezchybně fungoval, a zároveň byly minimalizovány veškeré problémy spojené s provozem služby. Problémem ovšem je, že existuje poměrně mnoho kombinací propojení komponent, ze kterých může vzejít alespoň částečně fungující systém, přičemž ale vlastnosti takto vytvořených systémů se od sebe mohou radikálně lišit. Následující návrhové zásady by měly vést k vytvoření systému s žádoucími vlastnostmi:

Není tedy vhodné například, aby komponenta Dspam, která filtruje zprávy podle obsahu, vítala doručující MTA, přestože je takové zapojení možné. Systém by totiž mohl vynakládat mnoho prostředků na kontrolu zpráv, které by se ovšem vzápětí zahodily, protože by se zjistilo, že pochází ze zombie počítače. Nebo pokud by správce nechtěl využívat oba přítomné programy pro filtrování zpráv na základě obsahu, měl by mít možnost jeden z nich deaktivovat, což by však nebylo možné, kdyby na sobě tyto programy závisely.

Z hlediska použití systému jako celku se dají rozlišit minimálně tři případy užití. Jsou to

Pro každý z těchto případů užití platí, že v nich programové komponenty spolupracují jiným způsobem než ve zbylých dvou případech, a proto mezi některými z nich může existovat více různých propojení.

Odeslání elektronické zprávy uživatelem vyžaduje pouze jednoduchou spolupráci tří komponent: Postfix, Dovecot a OpenDKIM. V tomto případě ovšem Dovecot nezprostředkovává MDA, nýbrž zajišťuje ověření odesílatele zvoleným autentizačním mechanismem. Pro tento účel komponenty Postfix a Dovecot vzájemně komunikují přes rozhraní SASL. Odesílání zprávy přes zabezpečený protokol SMTP řídí Postfix, který programu Dovecot předá potřebné údaje, aby je porovnal s existujícími persistentními daty. Po předání výsledku autentizace komponenta Postfix buď znovu požaduje údaje k ověření odesílatelovy identity, nebo dokončuje odesílání zprávy ve spolupráci s OpenDKIM, který zprávu elektronicky podepisuje.

Příjem zprávy od jiného MTA a její doručení do schránky uživatele je poněkud složitější proces. Pokud by se vycházelo ze základního konceptu elektronické pošty, opět by stačilo použít pouze programy Postfix a Dovecot, avšak navrhovaný systém by měl umět řešit i problémy, které v současné době elektronickou poštu provází, a proto jsou v součinnost zapojeny i zbylé komponenty poštovního subsystému. Obrázek č. 3.3 se snaží zachytit cestu příchozí zprávy přes programové komponenty krok za krokem. V prvním kroku, ještě než je jakákoliv zpráva přijata, se provádí kontrola odesílatele programem Postscreen, jejíž cílem je odhalit zombie počítače, což pomáhá snižovat výpočetní zátěž. Postscreen svou činnost vykonává ještě předtím, než server odešle uvítací příkaz EHLO protokolu SMTP (přesněji ESMTP), a poté podle výsledku kontroly buď ukončí spojení, nebo otevřené spojení předá komponentě Postfix, jež dále řídí celý proces až po předání zprávy doručovacímu agentovi (MDA). Krok číslo dvě na obrázku značí místo zmíněného předání. Postfix následně kontroluje nakonfigurované restrikce, z nichž jedna má za cíl zjistit, zda odesílatel není evidovaný uživatel systému, což se provede stejným postupem jako u předchozího případu užití, tedy pomocí komponenty Dovecot. Pokud není odesílající MTA odmítnut, Postfix od něj převezme elektronickou zprávu a pokračuje čtvrtým krokem k ověření jeho autenticity pomocí technologie DKIM. OpenDKIM, implementace DKIM, do hlavičky zprávy vloží svá zjištění a zprávu vrátí zpět programu Postfix v pátém kroku, přičemž výsledek se nezohledňuje, pokud odesílatel DKIM nevyužívá nebo má nastavenou výchozí podepisovací politiku. (Pozn.: z důvodu lepší názornosti je na obrázku Postfix zobrazen dvakrát.) Následují kontroly obsahu zprávy, jejichž cílem je odhalit nevyžádanou nebo zavirovanou poštu. Podobně jako OpenDKIM, tak také Dspam a Amavisd převezmou celou zprávu, provedou své testy, vloží výsledky do hlavičky zprávy a takto upravenou ji vrátí zpět programu Postfix. Amavisd přitom svou činnost dále deleguje na program Spamassassin nebo případně na antivirový program, pokud je v systému přítomen (na obrázku označeno hvězdičkou). Poslední, desátý krok představuje předání zprávy od MTA k MDA, tedy její uložení do schránky příjemce. Ještě i zde existuje možnost odmítnutí příchozí zprávy, a to konkrétně v případě, že příjemce dosáhl limitu velikosti své schránky.

Postfix Dspam Postscreen Amawis Dovecot OpenDKIM Spamassassin Komunikace s odesílajícím MTA přes protokol SMTP Dovecot Postfix Antivir 1 2 3 4 5 6 7 8* 8 9 10
Obrázek 3.3: Cesta elektronické zprávy systémem. Zdroj: autor

Posledním ze tří zmíněných případů užití jsou prohlížení a úpravy systémové konfigurace správcem, což souvisí pouze s komponentami prezentačního subsystému, tedy konfigurační webovou aplikací, AWStats a Nginx. Návrh vychází z běžného schéma komunikace mezi klientem a webovým serverem, avšak je použit reverzní proxy server implementovaný programovou komponentou Nginx. Zdrojem hypertextového obsahu je především konfigurační webová aplikace, která kombinuje klasický přístup k tvorbě webových prezentací s interaktivitou tvořenou skriptováním na straně klienta a asynchronní výměnou dat ve formátu JSON (technologie AJAX). Do této aplikace jsou začleněny HTML výstupy komponenty AWStats, které se pravidelně automaticky aktualizují.

Systémová konfigurace

Pro bezproblémový chod systému je důležitá jeho správná konfigurace. Naopak nesprávné nastavení byť i jediné programové komponenty může vést k poruchám při doručování pošty, nestabilitě, nepřiměřenému využívání výpočetních prostředků nebo k celkové nefunkčnosti systému. Při počáteční konfiguraci komponent v průběhu instalace je vše nastaveno pro správný chod a poté má každý uživatel možnost upravit nastavení podle svých potřeb. Je tedy nutno nejen zajistit optimální a funkční počáteční konfiguraci, ale také minimalizovat riziko, že by uživatelské nastavení vedlo k dysfunkci systému. Nejlepším způsobem minimalizace rizik je přitom prevence, a ta v tomto případě může nabýt hned několika podob. Především by konfigurační rozhraní nemělo (a ani nebude) dovolovat nastavení velmi citlivých hodnot, jako jsou databázové dotazy poštovních agentů, čísla portů pro komunikaci uvnitř systému, některé restrikce pro příjem a odesílání pošty nebo vypínání a zapínání stěžejních systémových služeb. Pro tyto a několik dalších hodnot nebudou ve webové konfigurační aplikaci žádné ovládací prvky. Vždy se totiž jedná o konfigurační hodnoty, jež stačí nastavit pouze jednou při počáteční konfiguraci, a pak již není potřeba je jakkoliv měnit. Dalším způsobem prevence je, co nejpočetnější, použití ovládacích prvků uživatelského rozhraní, které mají předem omezený výběr platných hodnot. Tento způsob se uplatní především tam, kde má konfigurační hodnota binární charakter. Posledním způsobem je informovat uživatele o možných následcích jeho volby, což je nejméně bezpečný způsob minimalizace rizik špatné konfigurace.

Při počáteční konfiguraci je potřeba nastavit především vzájemné propojení jednotlivých programových komponent, název domény a hostitelského počítače a některá hesla. K zadání důležitých hesel je uživatel vyzván, avšak v některých případech, například pro připojení komponenty Dspam do databáze, jsou hesla vygenerována. Počáteční konfigurace se netýká pouze programových komponent, ale také operačního systému, kde se při instalaci vytváří nová skupina, do níž spadá systémový uživatel, pod kterým je spouštěna webová konfigurační aplikace. V dalších krocích instalace je nově vytvořené skupině nastaveno vlastnictví vybraných konfiguračních souborů, čímž je umožněna jejich editace bez nutnosti vlastnit privilegia kořenového uživatele. Této skupině je také přidána pravomoc zapínat a vypínat služby poštovního systému. Podobně i u databáze se musí vytvořit noví uživatelé a jejich omezení v přístupu k datům, přičemž mezi těmito dvěma úkony je nutno zároveň vytvořit relační schéma. Jednou z konfiguračních činností je i generování kryptografických klíčů pro komponenty Dovecot (zabezpečení protokolů POP a IMAP), OpenDKIM (zabezpečení identity odesílatele) a Nginx (zabezpečení HTTP). Další nastavení programových komponent je obsaženo v šablonách příslušných konfiguračních souborů. Omezení, které hodnoty lze upravit a které nelze, závisí na následném vytvoření či nevytvoření databázových záznamů v tabulce systémové konfigurace, jež je zdrojem dat uplatněných při tvorbě uživatelského rozhraní.

Schéma uložení persistentních dat

Jelikož má systém zajišťující službu elektronické pošty pracovat s persistentními daty pomocí objektově-relačního systému řízení báze dat, je velmi žádoucí nejdříve navrhnout schéma uložení dat. V oblasti softwarového inženýrství se k tomuto účelu používá metoda tzv. entity-relationship modelování, jejímž možným výstupem je konceptuální datové schéma zvané entity-relationship diagram, zkráceně ER diagram. Tato metoda umožňuje modelovat nejen podobu jednotlivých entit, ale také vztahy, které mezi nimi existují.

Na obrázku č. 3.4 lze spatřit ER diagram modelující navrhovanou část datového schématu. Nutno podotknout, že se jedná opravdu jen o část celého schématu, které je ve výsledku tvořeno více relacemi, než kolik jich je na obrázku vymodelovaných pomocí entit či jejich množin. Důvodem je skutečnost, že některé programové komponenty či knihovny použité v konfigurační webové aplikaci si do databáze přidávají vlastní relace pomocí vlastních schémat. Takto se chová například komponenta Dspam. Pro komponenty Postfix a Dovecot je naopak potřeba schéma navrhnout, přičemž neexistují žádné závazné konvence o pojmenování jednotlivých relací nebo jejich sloupců, neboť ke každému schématu se v konfiguračních souborech musí vytvořit i příslušné databázové dotazy pro výběr požadovaných informací. V navrženém schématu jsou relace, k nimž přistupují Postfix a Dovecot, označeny prefixem Virtual, což má spojitost s názvy odpovídajících konfiguračních direktiv komponenty Postfix. Tyto dvě programové komponenty využívají informace o doménách, schránkách (uživatelích) a o přesměrováních (aliasech).

Obrázek 3.4: Zjednodušený Entity-Relationship diagram. Zdroj: autor

Společným pojítkem všech množin entit na ER diagramu z obrázku č. 3.4 je to, že k jejich datům přistupuje konfigurační webová aplikace. V důsledku toho je jí umožněno ovlivňovat chod poštovního serveru, a to buď bezprostředně skrze úpravy relací označených prefixem Virtual, nebo zprostředkovaně pomocí rutin upravujících nastavení programových komponent na základě změn v relaci Server Configuration. Entita Admin User přitom modeluje správce systému, respektive jeho uživatelský účet a identitu, která se zaznamenává u provedených změn v konfiguraci systému. Správce systému může navíc získat speciální pravomoci, pokud má ve svém databázovém záznamu nastaven chráněný příznak super (v ER diagramu označeno pomocí znaku \#).

Vyjma entity představující systémovou konfiguraci jsou v modelu entity vzájemně vztažené, přičemž se jedná o jednoduché vztahy bez atributů, které by se daly popsat následovně:

Z hlediska reálného nasazení systému je výhodné, že jedna entita Admin User spravuje libovolnou množinu entit Virtual Domain i to, že jedna entita Virtual Domain může být spravována jakkoliv velkou množinou entit Admin User, protože to rozšiřuje možnosti kolektivní správy serveru, a zároveň nijak neznepříjemňuje administraci jediným správcem. Benefity lze nalézt také u dvou zbylých množin vztahů. Fakt, že množiny entit Virtual User a Virtual Alias náleží entitě Virtual Domain, zvyšuje uspořádanost v systému, což umenšuje náchylnost k neoprávněným zásahům a současně vytváří možnost spojovat relace, a tím i optimalizovat výběry dat z databáze (pozn.: cizí klíče nejsou ve zobrazeném ER diagramu modelovány, avšak existují, přičemž jejich názvy se odvozují od názvů příslušných relací).

Entita Server Configuration v modelu představuje jednu konfigurační položku programové komponenty v navrhovaném systému. Z toho plyne, že úplná množina těchto entit představuje kompletní systémovou konfiguraci, respektive její databázovou reprezentaci, která duplikuje reálné nastavení komponent uložené v konfiguračních souborech. Důvodem je unifikace jinak rozdílných způsobů uložení konfigurace jednotlivými komponentami, důsledkem pak jednoduší prezentace ve webové konfigurační aplikaci.

Implementace a použité technologie

Předmětem práce není pouze systém zajišťující službu elektronické pošty, nýbrž i prezentační systém, jenž poskytuje především rozhraní pro správu, a případně může být rozšířen o tzv. webmail, tedy klientskou poštovní aplikaci. Tato kapitola popisuje především implementaci prezentačního systému a prostředky, které ji pomohly realizovat. V prvé řadě je představen aplikační framework, který se zásadním způsobem podílí na výsledné podobě celého systému. Dále jsou zmíněny některé nástroje pro komplexní správu systémové konfigurace, protože tvoří výkonnou vrstvu mezi implementací uživatelského rozhraní a konfiguračními soubory jednotlivých programových komponent. Vybraný nástroj pro správu systémové konfigurace je následně podrobněji popsán společně s instalací systému, kde se tento nástroj ve velké míře uplatňuje. V závěrečné části této kapitoly je probrána webová konfigurační aplikace nejen jako celek, ale i z hlediska důležitých implementačních detailů. Po přečtení kapitoly by mělo být zřejmé, jaké technologie byly použity při implementaci webové konfigurační aplikace, co všechno je jejím prostřednictvím umožněno a kde jsou případně její slabá či silná místa.

Aplikační framework

Jelikož jedním z cílů práce je implementace webové konfigurační aplikace pomocí jiného jazyka než PHP, přičemž za implementační jazyk byl zvolen Ruby, je nabídka aplikačních frameworků omezena jen pro tento jazyk, a přesto je stále poměrně široká. Jazyk Ruby disponuje mnohými propracovanými frameworky, z nichž mezi nejznámější patří Sinatra a Ruby on Rails, které měly a snad stále mají významný vliv na směřování celého odvětví webových aplikačních frameworků [SinatraInspired] [RubyOnRailsRulesTheUniverse]. Právě Ruby on Rails (či zkráceně Rails) byl vybrán za aplikační framework pro zhotovení této práce.

Ruby on Rails je tzv. full-stack framework, což zjednodušeně řečeno znamená, že se snaží zahrnout veškerou funkčnost, kterou by programátor při vývoji webové aplikace mohl potřebovat. Jeho architektura vychází z návrhového vzoru Model-View-Controller, podle kterého se aplikace člení na tři nezávislé komponenty, Model pro datovou abstrakci, View definující uživatelské rozhraní a Controller jako prvek reagující na události a řídící činnost aplikace. Používá i další návrhové vzory, třeba Active Record pro zapouzdření přístupu k databázi a k datům. Koncept použitý v Ruby on Rails by měl vést k malému počtu naprogramovaných řádků, navíc s co nejmenší možnou mírou opakování. Jedná se o celosvětově oblíbený webový framework, se kterým má autor práce mnoho zkušeností, což také mělo vliv na výběr.

Přestože díky svým konceptům vybraný aplikační framework dokáže urychlit vývoj aplikace, má i své stinné stránky. Zkušenost potvrzuje, že aplikace, které ve velké míře nepoužívají ukládání do mezipaměti (cache), nezvládají vysokou zátěž. Tento problém je ovšem z hlediska webové konfigurační aplikace irelevantní, neboť aplikace je určena především správcům poštovních serverů, kterých bývá pouze několik. Ani relativní složitost a dlouhá doba učení, mnohdy udávané jako nevýhody [RubyOnRailsRulesTheUniverse], v tomto případě nejsou silnými argumenty proti použití k vývoji, protože, jak bylo řečeno, autor je s frameworkem hluboce seznámen.

Framework Ruby on Rails vychází vstříc modernímu přístupu k vývoji interaktivních webových aplikací, který aplikaci rozděluje na klientskou a serverovou část, přičemž obě části si mezi sebou vyměňují data v určitém formátu, například XML nebo JSON. Tento přístup a technologie, jež ho umožňují, jsou označovány akronymem AJAX. Aplikace používající AJAX jsou uživatelsky přívětivější, protože odstraňují potřebu překreslovat webovou stránku při každém dotazu na server, a zároveň dovolují přenést některé výpočty ze serveru na klientský počítač, a tím snížit zátěž kladenou na server. Na druhou stranu klientská část musí být napsána pomocí jazyka JavaScript nebo jiného jazyka, jehož kód lze do jazyka JavaScript převést. I při použití speciálních knihoven pro práci s DOM (Document Object Model) reprezentací webové stránky je obvykle klientská část poměrně rozsáhlá, takže také pro ni vznikají aplikační frameworky, jenž používají návrhové vzory nebo jiné podpůrné techniky programování, aby přinejmenším systematicky uspořádaly kód klientské části aplikace nebo implementovaly nejběžnější funkčnost.

Webová konfigurační aplikace pro implementaci klientské části používá framework CanJS, jehož tvůrci o něm prohlašují, že je rychlý, bezpečný z hlediska alokování paměti a flexibilní v tom smyslu, že umožňuje výběr knihovny pro práci s DOM. V konfigurační aplikaci pro práci s DOM CanJS používá knihovnu JQuery, která je výchozí součástí frameworku Ruby on Rails. Podobně jako Rails, i CanJS konceptuálně vychází z návrhového vzoru Model-View-Controller, avšak je spíše minimalistický, což zmenšuje množství kódu přenášeného na klientský počítač.

Oba aplikační frameworky jsou volně dostupné pod svobodnou licencí MIT.

Software pro správu systémové konfigurace

Úkolem webové konfigurační aplikace je provádění změn v nastavení jednotlivých programových komponent systému pomocí webového rozhraní. Jakkoliv to může znít jednoduše, opak je pravdou, neboť

Ve výsledku se tedy jedná o poměrně komplexní problém, který již ovšem má svá úspěšná řešení. Ta se označují jako tzv. Configuration Management Software (programy pro správu konfigurace) a populární jsou především dvě: Puppet a Chef. Mezi těmito dvěma se najdou vlastnosti společné, třeba architektura klient-server nebo použití jazyka Ruby, tak také vlastnosti rozdílné, např. deklarativní kontra imperativní způsob vyjádření pomocí DSL (Domain-specific language) [Puppet or Chef?]. Avšak tyto nástroje jsou určeny spíše k orchestraci mnoha počítačů v privátní síti, jejich použití ke správě pouze místního počítače je neobratné a navíc vyžadují instalaci podpůrných programů. Pro potřeby webové konfigurační aplikace se mnohem vhodněji jeví AutomateIt, volně dostupná (včetně zdrojových kódů) knihovna jazyka Ruby, která poskytuje rozhraní k řízení nastavení a údržby téměř všech Linux/Unix operačních systémů [AutomateIt Compatibility].

AutomateIt obsahuje kompletní a funkční sadu nástrojů pro správu operačního systému, které se velmi intuitivně používají a lze je jednoduše integrovat do jakékoli aplikace v jazyce Ruby, avšak knihovna již není vyvíjena. Ve své původní podobě AutomateIt nebyla kompatibilní s verzí jazyka Ruby 1.9, takže byla kosmeticky upravena pro potřeby webové konfigurační aplikace a její nová větev byla zveřejněna prostřednictvím webové služby GitHub [fanda/automateit]. Nově byla přidána také podpora instalace programů z tzv. backports repozitářů operačního systému Debian.

Knihovnu AutomateIt lze použít i samostatně. Práci může vykonávat v interaktivní konzoli nebo formou projektu, jenž má strukturu vygenerovaných a vzájemně propojených souborů, z nichž některé jsou datové, další tvoří šablony konfiguračních souborů a zbylé vypadají jako skripty jazyka Ruby a nazývají se recepty [AutomateIt Screenshots]. Programování receptů připomíná tvorbu skriptů pro shell operačního systému Unix. Stejně jako všechny programy pro správu konfigurace, také AutomateIt nejprve identifikuje operační systém a na základě zjištěných informací volí správné správce balíčkovacích systémů, správce služeb nebo jiné specifické programy. K dispozici jsou pokročilé metody pro editaci a šablonování konfiguračních souborů nebo pro správu uživatelů a síťových rozhraní. Webová konfigurační aplikace knihovnu AutomateIt integruje do svého modelu, ale nezávisle na tom je pro instalaci a počáteční konfiguraci využita i v podobě projektu.

Instalační recepty

Uvnitř souborového systému webové konfigurační aplikace je vytvořen AutomateIt projekt s názvem system, který zajišťuje instalaci a počáteční konfiguraci všech programových komponent systému. Tato část je jedním z pilířů celé práce, neboť jsou zde umístěna data a většina rutin, které umožňují instalaci funkčního poštovního serveru pouhým jedním příkazem (za předpokladu, že aplikace, o které pojednává tato práce, je již nainstalována), což je umožněno díky spojení a kooperaci projektu system s aplikací vytvořenou pomocí aplikačního frameworku Ruby on Rails.

Základními prvky instalačního procesu jsou explicitně seřazené skripty v jazyce Ruby, jenž jsou v rámci projektu knihovny AutomateIt nazývány recepty. Většina z instalačních receptů je zaměřena na instalaci a konfiguraci jediné programové komponenty, přičemž výjimkou jsou dva recepty. První výjimečný i první v celkovém pořadí je instalační recept doslova. Zajišťuje správnou posloupnost instalujících volání příslušných programů pro správu balíčků, instaluje potřebné knihovny jazyka Ruby a provádí určité modifikace systému, aby jej připravil pro bezproblémový běh všech aplikací. Druhou výjimku tvoří instalační recept, jenž je v celkovém pořadí naopak poslední a který, opět ve správném pořadí, startuje systémové služby tvořící výsledný poštovní server. Zbylé instalační recepty mají spíše konfigurační ráz, tj. vytváří konfigurační soubory na základě šablon a strukturovaně uložených výchozích hodnot, ale také například generují certifikáty umožňující šifrovanou komunikaci.

Jsou to právě šablony konfiguračních souborů ve formátu ERB a výchozí konfigurační hodnoty ve formátu YAML, které v AutomateIt projektu zesilují vyjadřovací schopnosti instalačních receptů. Díky nim je počáteční nastavení systému snadné a intuitivní, protože vývojář pracuje se soubory, které se velmi podobají výsledným konfiguračním souborům jednotlivých programových komponent. Způsob práce se šablonami v AutomateIt je navíc takřka identický se šablonováním používaným při vývoji webových aplikací pomocí frameworku Ruby on Rails, kde se také používá formát šablon ERB.

Pouze import databázového schématu není plně v režii knihovny AutomateIt. Ta sice vytváří databázové účty a definuje přístupová oprávnění, avšak relační schéma se zavádí prostřednictvím migračních tříd aplikačního frameworku [Migrations], které se nachází ve složce db/migrate adresářové struktury aplikace. Důvodů je hned několik. Migrace jsou především opět skripty jazyka Ruby, takže pro správný zápis databázového schématu není potřeba umět přesnou syntaxi jazyka PL/pgSQL, který je navíc určený jen pro PostgreSQL. Systém řízení báze dat PostgreSQL sice vychází z návrhu jako nezaměnitelná komponenta, avšak případná modifikace není neuskutečnitelná a migrační třídy ji svou nezávislostí velmi usnadňují. Ulehčují také provádění veškerých změn ve schématu již nasazené aplikace, neboť v sobě mají zabudovaný jednoduchý verzovací systém. V neposlední řadě, několik použitých knihoven vkládá své vlastní relace a i jejich schéma je vždy definováno formou migračních tříd.

Řízení průběhu instalačního procesu implementuje třída Installer, jež při své instanciaci načte informace o projektu system, a poté postupně volá jednotlivé instalační recepty nebo podle potřeby podpůrný program bundler, který spravuje aplikační závislosti. Samotné spuštění instalačního procesu zařizuje program Rake [Rake] volaný z kořenového adresáře webové konfigurační aplikace nebo spustitelný skript jazyka Ruby, který se po instalaci aplikace umístí mezi ostatní spustitelné programy operačního systému. Díky vlastnostem knihovny AutomateIt se každým opětovným spuštěním instalace nastaví výchozí konfigurační hodnoty.

Webová konfigurační aplikace

Po instalaci poštovního a prezentačního systému stačí spustit webový server a přes libovolný webový prohlížeč zobrazit konfigurační aplikaci. Zjednodušené případy použití této aplikace jsou k nalezení na obrázku č. 3.2 v předchozí kapitole a shodují se s jednotlivými položkami hlavní nabídky v grafickém uživatelském rozhraní aplikace, které je díky použití technologie AJAX interaktivní, takže na většinu uživatelských akcí reaguje okamžitě a bez překreslování celé HTML stránky. Nejedná se však o tzv. single-page webovou aplikaci [About Single Page Web Apps], poněvadž při iniciaci jednotlivých případů užití se HTML stránka přece jen překresluje. Důvodem je snaha o zjednodušení architektury klientské části aplikace, která je na základě tohoto přístupu tvořena vzájemně nezávislými řídícími objekty, potomky objektu can.Control z knihovny CanJS. Tyto řídící objekty manipulují s DOM a v paměti udržují kolekci objektů označovaných jako modely, což jsou opět potomci příslušných objektů knihovny CanJS. Prostřednictvím modelů dochází k validaci atributů na straně klienta, k filtraci určitých informací z kolekce objektů a především ke komunikaci klienta se serverem, přičemž se využívají principy architektury REST (Representational state transfer) [RESTful]. Kromě knihoven Jquery a CanJS, řídících objektů a modelů je součástí klientské aplikace také několik pomocných skriptů. Grafické uživatelské rozhraní je definováno, podobně jako u většiny moderních webových aplikací, pomocí HTML dokumentů a kaskádových stylů. Pro urychlení tvorby přívětivého uživatelského rozhraní byla použita kolekce nástrojů a ovládacích prvků Bootstrap, která je uvolněna pod licencí Apache 2.0, takže je volně přístupná a obecně použitelná.

Implementace klientské části aplikace je moderní a používá poměrně mladé technologie. Jedná se o nový způsob zápisu kaskádových stylů zvaný SASS, elegantní značkovací jazyk HAML a také CoffeeScript, což je syntaktické zjednodušení jazyka JavaScript. Společnou vlastností těchto jazyků je, že se před použitím na klientském počítači musí přeložit do příslušných tradičních jazyků. Dále, aby byl objem dat přenášených po síti mezi klientem a serverem co možná nejmenší, jsou jednotlivé soubory kaskádových stylů či soubory klientských skriptů spojovány do jediného souboru, jehož velikost je dále minimalizována odstraněním přebytečných mezer a kompresí. Tímto způsobem pospojované soubory se v aplikaci nachází v adresáři public/assets, originální vývojové soubory jsou umístěny v adresáři app/assets.

Serverová část aplikace dodržuje základní architektonické principy frameworku Ruby on Rails. Implementace štíhlých řídících tříd (Controllers), obsáhlých prvků modelu systému (Models) a DRY [Don't Repeat Yourself] pohledů (Views) lze najít v příslušných podadresářích adresáře app. Za zmínku stojí především prvky modelu systému, mezi nimiž jsou nejen objektové reprezentace databázových relací, ale také třídy správců systémové konfigurace a hierarchie tříd představujících rozhraní k nastavení jednotlivých programových komponent systému. Objektová reprezentace databázových relací vychází z ER diagramu na obrázku č. 3.4 a je vytvořena, včetně příslušných vazeb mezi objekty, pomocí návrhového vzoru Active Record, jenž je implementován v aplikačním frameworku. Součástí implementace jsou validátory atributů a specifické pomocné metody. Také sem lze zařadit třídu Property, která představuje základní a obecnou jednotku systémové konfigurace (vlastnost či možnost), z níž jsou odvozeny vlastnosti specifické pro každou programovou komponentu. Každá vlastnost systémové konfigurace je jednoznačně identifikována pomocí textového klíče a číselného označení komponenty, ke které vlastnost náleží, a obsahuje i atributy a metody sloužící k určení způsobu, jakým se pomocí knihovny AutomateIt daná informace aplikuje do konfigurace. Způsob zavádění změn v nastavení přitom není přímý, nýbrž se nejprve ukládá nová hodnota dané vlastnosti, a teprve po potvrzení uživatelem jsou hromadně provedeny veškeré změny a restartovány odpovídající systémové služby. Právě hromadné provedení změn je úkolem správců systémové konfigurace (třídy SystemManager a CertificateManager), kde jsou kromě akceptačních rutin implementovány také rutiny pro aktivaci či deaktivaci fakultativních systémových služeb (např. dspam nebo amavisd). Zde se opět uplatňuje knihovna AutomateIt.

V aplikaci je použito ještě několik dalších užitečných knihoven. Jejich úplný výpis se nachází v souboru Gemfile, který je podkladem pro aplikaci Bundler spravující aplikační závislosti a jejich aktualizace. Z hlediska funkčnosti jsou zajímavé knihovny Devise, Simple Form a Paper Trail. Devise a Simple Form jsou knihovny produkované společností Plataformatec pod svobodnou licencí MIT. První z nich představuje komplexní řešení autentizace ve webové aplikaci, druhou tvoří sada pomocných funkcí využitelných při psaní webových formulářů. Knihovna Paper Trail slouží k evidování změn v datech reprezentovaných skrz aplikační model a je použita ke sledování změn systémové konfigurace, takže lze zpětně dohledat, jaké nastavení bylo změněno a kdo změny provedl. V případě nutnosti Paper Trail dovoluje návrat do jakéhokoliv minulého stavu systému.

Díky použití aplikačního frameworku Ruby on Rails má aplikace několik velmi žádoucích vlastností. V prvé řadě automaticky loguje činnost systému, přičemž se dá nastavit, jak podrobné informace se budou zaznamenávat. Soubory s logy se dají najít v adresáři log a jsou rozděleny podle systémových prostředí. Systémová prostředí [Environments] jsou koncept umožňující jednoduché spouštění aplikace s účelově různým nastavením. Výchozí systémová prostředí v aplikaci postavené na Ruby on Rails jsou vývojové, produkční a testovací. Každé z těchto prostředí má vlastní databázi k níž přistupuje nebo například jinak využívá mezipamět (cache). Konfigurační soubory pro jednotlivá prostřední se společně se sdílenou aplikační konfigurací nachází v adresáři config. Ve stejném adresáři se nachází podadresář locales, kde jsou uloženy a podle jazyka rozděleny řetězce uživatelského rozhraní, jehož vícejazyčnost framework Ruby on Rails podporuje. Webová konfigurační aplikace tuto podporu samozřejmě využívá, přičemž uživatelské rozhraní lze nyní zobrazit v jazyce českém nebo anglickém. Poslední zde uvedenou žádoucí vlastností je možnost psaní testů. V tuto chvíli aplikace testy postrádá, avšak pro další vývoj je nezbytné jejich vytvoření, protože testy dělají aplikaci méně náchylnou na vývojové chyby.

Na závěr je nutno podotknout, že kapitola popisovala pouze nejpodstatnější knihovny a implementační detaily. Některé části, jako například řídící třídy nebo pohledy, byly v popisu vynechány, protože se jedná o jednoduché koncepty, o nichž případně pojednají přímo jejich zdrojové kódy. Jazyk Ruby má velkou výhodu v tom, že se velmi podobá jazyku anglickému, takže čtení zdrojových kódů není náročné ani pro člověka, který v jazyce Ruby nikdy neprogramoval.

Distribuce a další vývoj programu

Veškerý produkovaný software v jisté fázi svého vývoje přejde do místa, kde je nasazen do produkčního prostředí, a následně již buď jen udržován anebo dále vyvíjen. Nejinak je tomu i u automaticky instalovaného poštovního systému s webovou konfigurační aplikací, který je výsledkem této diplomové práce. Výsledkem, jehož zahozením by vznikla ztráta, protože by zůstal nepovšimnut a nevyužit množstvím programátorů či správců počítačové infrastruktury kdekoli ve světě. Avšak lidé se o výsledku této práce musí nejprve dozvědět, aby se jej případně rozhodli používat, proto je potřeba jej nabídnout, a současně s tím ho také dále vyvíjet a zlepšovat, neboť máloco stárne tak rychle jako software. Tato kapitola nejprve pojednává o způsobu, jakým je její výsledný produkt zveřejněn a prezentován, což zahrnuje též výběr správné licence a vytvoření dokumentačních materiálů. Následně jsou popsány chybějící či neúplné části systému a vypsány návrhy na rozšíření funkčnosti, což jsou základní předpoklady dalšího vývoje aplikace.

Jako autor jsem se rozhodl aplikaci nazvat Rmails, což by mělo odrážet skutečnost, že k vývoji byl použit jazyk Ruby a framework Ruby on Rails. Název vznikl přidáním písmene M do slova rails, přičemž vzniklý řetězec obsahuje podřetězec mail, tj. v americké angličtině pošta. Název je v následujícím textu používán pro označení programového výstupu této diplomové práce, jímž je aplikace vytvářející poštovní systém pomocí volně dostupných komponent a webová konfigurační aplikace k tomuto systému. Aplikace bude distribuována pod licencí MIT.

Zveřejnění a prezentace

Pro aplikace podobného typu jako Rmails, tedy napsané v jazyce Ruby, existuje mnoho způsobů, jak je zveřejnit a zpřístupnit k užívání. Nejznámějším a pravděpodobně nejpoužívanějším z možných způsobů zveřejnění je systém RubyGems, který nejenže zdarma poskytuje široce dostupné úložiště v síti Internet, ale také nabízí pohodlné rozhraní pro práci s jednotlivými programy, a to jak pro vývojáře tak také pro uživatele. Rubygems se často používá v kombinaci se službou pro hostování zdrojových kódů pomocí některého z verzovacích systémů (např. git nebo subversion). Příkladem takové služby je Github, jenž je v současnosti hostitelem řádově miliónů veřejných repozitářů používajících systém správy verzí git. Aplikace Rmails využívá obě služby, Rubygems i Github, takže by měla být zajištěna její globální dostupnost a zároveň podpořen komunitní vývoj.

Použití systému Rubygems spočívá v práci se správcem balíčků aplikací napsaných v jazyce Ruby zvaným gem [RubyGems Manuals], který je běžně dostupný v téměř všech operačních systémech. Jedná se o víceúčelový program pokrývající celý životní cyklus aplikací. Zveřejnění aplikace předchází vytvoření specifikačního skriptu s příponou gemspec, který obsahuje informace o aplikaci, mimo jiné popis, licenci a verzi, avšak také o autorech nebo o programových závislostech aplikace. Na základě tohoto skriptu se programem gem vytvoří binární balíček, který se následně nahraje na úložiště systému Rubygems, odkud je okamžitě připraven k distribuci koncovým uživatelům aplikace. Rubygems automaticky vytváří a spravuje webovou stránku zobrazující informace o aplikaci obsažené ve specifikačním skriptu. Případný uživatel si aplikaci může nainstalovat, aktualizovat nebo odinstalovat opět pomocí programu gem. Tato skutečnost je vzhledem k použitelnosti aplikace Rmails zásadní, poněvadž na operačních systémech, kde je systém Rubygems přítomen, lze vytvořit komplexní a nakonfigurovaný poštovní systém pomocí pouhých dvou příkazů. Jedním příkazem se nainstaluje aplikace Rmails a druhým příkazem Rmails nainstaluje a nakonfiguruje poštovní systém včetně webové konfigurační aplikace.

Aplikace Rmails může být distribuována také pomocí služby Github a programu git, jenž implementuje systém pro správu verzí a jeho uživatelské rozhraní. Github, podobně jako Rubygems, automaticky vytváří webovou stránku [RMails on GitHub], kde se zobrazuje adresářová struktura a zdrojové kódy aplikace doplněny o formátovaný soubor README, v němž jsou obsaženy specifické informace, důležité vlastnosti systému nebo instalační postup. Uživatel tedy může procházet zdrojové kódy online nebo si je zkopírovat do svého počítače a aplikaci používat přímo jejich prostřednictvím. Co je však podstatné, kdokoliv může zdrojové kódy upravit a požádat o začlenění změn do původního repozitáře. Díky tomu je aplikace vyvíjena a opravována komunitou svých uživatelů ku prospěchu všech. Veškeré provedené změny a komentáře k nim jsou evidovány prostřednictvím programu git, který navíc dokáže vytvářet různé vývojové větve, takže lze v návrhu aplikace tvořit obměny, například nahrazení nějaké programové komponenty jiným programem zajišťujícím podobnou činnost. Služba Github dále nabízí doprovodné funkce, kupříkladu wiki stránky (báze znalostí) nebo systém podpory řešení problémů (issue tracking system), které slouží jako podpůrné prostředky pro rozvoj komunity uživatelů.

Dosud posledním krokem k propagaci aplikace Rmails je vyhotovení vyhrazených webových stránek na doméně www.rmails.com. I zde jde o víc než o pouhou prezentaci aplikace, neboť ta má potenciál stát se internetovou službou nabízející e-mailové schránky pro soukromé domény. Vznikne tak tzv. start-up poskytující e-mailové řešení pro vlastníky domén. Avšak pro tento účel aplikace zatím není připravena, neboť je stále ve vývoji.

Pokračování ve vývoji aplikace

Implementace aplikace Rmails v době psaní této diplomové práce ještě není vhodná pro produkční nasazení, přestože k cílovému výsledku již mnoho nechybí. Prvotním cílem aplikace je zásadní zjednodušení instalace a konfigurace služeb elektronické pošty na operačních systémech Ubuntu, Debian, Fedora a CentOS, případně také na dalších. Dále je cílem vytvoření webové konfigurační aplikace v jazyce Ruby, která by obsluhovala nejen správu domén, ale také správu nastavení jednotlivých komponent poštovního systému a správu používaných certifikátů. Všech těchto cílů bylo dosaženo s výjimkou podpory instalace a konfigurace na operačních systémech Fedora a CentOS, kde je ovšem problém pouze názvy některých balíčků a konfiguračních souborů, takže není potřeba měnit nic zásadního.

Avšak počáteční konfigurace poštovního systému dosud není optimální, takže se objevují provozní problémy. Poštovní systém se postupně ladí, přičemž je snaha nalézt takovou počáteční konfiguraci, která by vyhovovala většině případů užití celé aplikace. Také u webové konfigurační aplikace se vyskytují chyby a nejsou implementovány některé akce správce, například odstranění poštovní schránky nebo přesměrování. Z hlediska funkčnosti se sice nejedná o kritický nedostatek, avšak při správě poštovní služby jsou podobné úkony potřeba, takže tyto nedostatky mají v budoucím vývoji prioritu.

Nejbližší vývoj by se měl soustředit především na implementaci aplikačních testů a na podporu operačních systémů Fedora a CentOS, případně dalších. Současně by bylo vhodné postupně přidávat další systémové vlastnosti, které jsou nastavitelné přes webové rozhraní. Pro rozšiřování konfigurovatelných systémových vlastností je vše připraveno, avšak u každé vlastnosti je potřeba zvážit, zda nějakým způsobem nekoliduje s jiným systémovým nastavením nebo zda je opravdu vhodné, aby správce měl možnost ji tak jednoduchým způsobem upravovat. Další změny by se měly týkat vylepšování uživatelského rozhraní, aby bylo intuitivnější a snad i více interaktivní. Prostor pro vylepšení uživatelského rozhraní se nachází především ve správě uživatelů (správců) webové konfigurační aplikace. Také celý proces instalace má potenciál ke zlepšení, například při reinstalaci (rekonfiguraci) systému by se mohla automaticky exportovat a importovat persistentní data uložená v databázi, takže by nemohlo dojít k jejich ztrátě. Poštovní systém by se dal vylepšit možností automatických odpovědí (např. v případě odjezdu na dovolenou).

Ve vzdálené budoucnosti by se systém mohl rozšířit o jednoduchou administraci webových, byť třeba pouze statických, stránek, o možnost hromadné korespondence nebo o integrovaný webmail, tj. webovou klientskou aplikaci. Pro uživatele aplikace Rmails, kteří by jako systém řízení báze dat raději používali například MySQL než současné PostgreSQL, by mohly vzniknout variace s alternativními systémy řízení báze dat. To však platí téměř o všech programových komponentách v systému. Podobné změny v každém případě vyžadují rozdvojení (fork) zdrojových kódů.

Shrnutí výsledků

Výsledkem této diplomové práce je v prvé řadě aplikace, která zásadním způsobem zjednodušuje instalaci a počáteční konfiguraci e-mailového serveru, k jehož následné konfiguraci dále poskytuje interaktivní webové rozhraní. Tento nový software, mnou pojmenovaný Rmails, je vytvořen pouze pomocí technologických prostředků vycházejících z jazyka Ruby a mezi své uživatele je distribuován především prostřednictvím internetové služby RubyGems. Díky službě RubyGems by na vybraných operačních systémech s jádrem Linux měla být instalace aplikace uskutečnitelná jediným příkazem, přičemž následným spuštěním aplikace se automaticky nainstalují všechny součásti nutné pro běh poštovního serveru a provede se jejich počáteční konfigurace, takže po instalaci je e-mailový server provozuschopný. Jinými slovy, díky aplikaci Rmails je možno nainstalovat a nakonfigurovat e-mailový server pomocí pouhých dvou příkazů v příkazovém řádku operačního systému.

Základem výsledného poštovního serveru jsou programy Postfix a Dovecot, které implementují fundamentální agenty (MTA a MDA) v systému nejpoužívanější asynchronní elektronické komunikace dneška. Poštovní server dále obsahuje několik způsobů ochrany před nevyžádanou poštou a implementaci jedné z možných ochran před zneužití identity odesílatele, OpenDKIM. Následnou konfiguraci systému zprostředkovává webová konfigurační aplikace postavená s pomocí aplikačního frameworku Ruby on Rails a knihovny AutomateIt. Díky programu AWStats jsou k dispozici také statistiky o provozu serveru.

Aplikace je uvolněna pod svobodnou licencí MIT, která komukoli dovoluje libovolné nakládání s licencovaným software včetně úpravy zdrojových kódů. Zdrojové kódy jsou zveřejněny prostřednictvím internetové služby Github, jež umožňuje každému uživateli přispívat k vývoji aplikace svými opravami nebo vylepšeními, takže se další vývoj aplikace může stát záležitostí komunity uživatelů.

Společně s aplikací Rmails postupně vzniká i stejnojmenná internetová služba se zaměřením na poskytování e-mailových schránek pro vlastníky domén.

Závěr

Cíle, který byl stanoven v zadání této diplomové práce, bylo dosaženo. Byla navržena a implementována aplikace pro instalaci a konfiguraci e-mailového serveru a pro jeho následnou správu. Aplikace se přitom nesnaží nahradit podobná existující řešení, která používají jiné technologie nebo jsou zpoplatněna, ale nabízí k nim volně dostupnou a jednoduše použitelnou alternativu. Dílo vznikalo běžným postupem známým z teorie softwarového inženýrství, tedy nejdříve byl vytvořen návrh a poté vznikala implementace. Vzhledem k tomu, že implementační fáze jen minimálně zpětně ovlivnila návrh, lze usoudit, že návrh byl proveden kvalitně. Další etapy vývoje, testování a prvního nasazení aplikace, dosud probíhají, takže zatím nelze mluvit o plné připravenosti k produkčnímu nasazení. Aplikace sice dosud nedostála svého předsevzetí plné funkčnosti na operačních systémech Fedora a CentOS, avšak v brzké době by měla být připravena i pro tyto operační systémy, a možná ještě pro některé další. Nyní je aplikace použitelná na operačních systémech Ubuntu od verze 12.04 a Debian Wheezy.

Text této práce vychází se zdrojů odborné literatury pouze sporadicky, protože se v ní objevuje velmi málo tematicky podobných prací. Důležitými zdroji poznání pro práci se staly RFC (Requests for Comments), což jsou doporučení k tvorbě internetových protokolů a služeb, z nich některá se dají považovat i za standardy. Mnoho informací o problematice, především pak co se týče filtrování nevyžádané pošty, nabízí internetová encyklopedie Wikipedie, kam sice mohou přispívat lidé neerudovaní, avšak u většiny příspěvků jsou bohaté reference a nahodilá kontrola některých údajů u jiných zdrojů vždy potvrdila jejich platnost. V textu je často odkazováno na stránky použitých aplikací nebo technologií, přičemž u všech příslušných citací je uvedena poznámka stránka produktu. Ve většině případů smyslem není uvedení zdroje informací, ale přímé odkázání čtenáře na prezentaci produktu, kde o něm může získat podrobnější informace, než jsou uvedeny v textu.

Celý projekt, tedy instalační a konfigurační aplikace a text diplomové práce, je tvořen s nadějí, že ušetří mnoho práce lidem, kteří jej v budoucnu využijí pro zřízení vlastního e-mailového serveru. I z tohoto důvodu bude vývoj aplikace dále pokračovat a na základě zpětné vazby reflektovat potřeby uživatelů tak, aby aplikace obstála v soutěži se svými alternativami.