ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická

Bakalářská práce Jednotný elektronický podpis v e-mailu pro Microsoft SMTP server Jan Salajka

Vedoucí práce: Ing Daniel Staněk

Studijní program: Elektrotechnika a informatika strukturovaný Obor: Výpočetní technika Leden 2009

název práce Jednotný elektronický podpis v e-mailu pro Microsoft SMTP server. Unified e-mail signature for Microsoft SMTP server. katedra obhajoby Katedra počítačů obor Výpočetní technika (bakalářský) studijní program Bakalářský vedoucí Staněk Daniel Ing. Katedra počítačů (13136) externista, AUTOCONT CZ a.s. [email protected] oponent Ballner Radim Ing. externista, Iterity s.r.o. http://cs.felk.cvut.cz/webis/people/xballner.html [email protected] student Salajka Jan studuje – zadáno [email protected] literatura Dodá vedoucí práce pokyny Navrhněte řešení jednotného firemního podpisu, který je automaticky doplněn do každé odcházející poštovní zprávy pomocí Microsoft SMTP serveru (Microsoft Exchange 2003 na platformě Windows 2003 server). Firemní podpis má obsahovat stálý text a personifikované údaje o odesilateli získané z Active Directory (oddělení, telefon apod.). Navrhněte rozhraní pro konfiguraci a změnu elektronického podpisu. Proveďte analýzu vhodných programových nástrojů se zřetelem na jednotlivé dílčí vazby a chování systému. Navržené řešení ověřte pilotní implementací. zadavatel Autocont CZ a.s.

ii

PROHLÁŠENÍ

Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady v přiloženém seznamu. Nemám závažný důvod proti užití toho školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Duchově dne ……………………..

………………………… ii

PODĚKOVÁNÍ

Děkuji Ing. Danielu Staňkovi za vedení mé bakalářské práce a za podnětné návrhy, které ji obohatily. ………………………… iii

Název práce: Jednotný elektronický podpis v e-mailu pro Microsoft SMTP server. Autor:

Salajka Jan

Obor: Druh práce:

Výpočetní technika (bakalářský) Bakalářská práce

Vedoucí

Staněk Daniel Ing. Katedra počítačů (13136) externista, AUTOCONT CZ a.s.

Abstrakt:

Tato bakalářská práce se zabývá návrhem a implementací aplikace pro řešení jednotného firemního podpisu v odchozích emailech v prostředí operačního systému Microsoft Windows a Microsoft Exchange serveru. Navrhovaná aplikace doplňuje automaticky jednotný podpis do všech odchozích emailů s personifikovanými údaji odesílatele na základě konfigurace. Personifikované údaje jsou vyhledávány v Active directory dle emailové adresy odesílatele. Součástí práce je návrh uživatelského rozhraní pro konfiguraci systému.

Klíčová slova:

smtp, podpis, exchange, email

Title: Unified e-mail signature for Microsoft SMTP server. Author:

Salajka Jan

Abstract

This bachelor thesis deals with a design and implementation of the application for unified corporate signature solution in outgoing emails within the operation system Microsoft Windows and Microsoft Exchange server. The proposed application on the basis of configuration automatically complements the unified signature in all outgoing emails with personified data of a sender. The personified data are searched out in the Active directory according to the sender´s email address. A proposal of user interface for system configuration is also included in the thesis. smtp, signature, exchange, email

Key words:

iv

OBSAH

Seznam obrázků .......................................................................................................................................... 3 1 2

3

4

5

Úvod ...................................................................................................................................................... 4 1.1 Deklarace záměru ....................................................................................................................... 4 Analýza a návrh řešení ........................................................................................................................ 5 2.1 Návrh typu aplikace ................................................................................................................... 5 2.2 Vývojové prostředí a programovací jazyk ............................................................................. 5 2.3 Problémy a omezení návrhu .................................................................................................... 6 2.3.1 Problém duplicitního podepisování ............................................................................ 6 2.3.2 Kryptování emailu, případně elektronický podpis šifrovacím klíčem .................. 7 2.3.3 Formát emailu a kódování emailu ............................................................................... 7 2.4 Schéma navrhované aplikace ................................................................................................... 8 2.5 Úložiště konfigurace a konfigurační soubory ....................................................................... 8 2.6 NÁvrh Uživatelského rozhraní pro administraci a konfiguraci ........................................ 9 Realizace .............................................................................................................................................. 11 3.1 Popis implementovaných tříd ................................................................................................ 12 3.1.1 Class Sink ....................................................................................................................... 12 3.1.2 Class Sign ....................................................................................................................... 13 3.1.3 Class ADConnector ..................................................................................................... 14 3.1.4 Class RegConfig ............................................................................................................ 15 3.1.5 Class Log ........................................................................................................................ 16 3.2 Poznámky k překladu aplikace............................................................................................... 16 3.2.1 Vývojové prostředí a překlad aplikace ...................................................................... 16 3.2.2 Ladění aplikace .............................................................................................................. 17 Testování ............................................................................................................................................. 18 4.1 Konfigurace testovacího prostředí........................................................................................ 18 4.1.1 Instalace Microsoft Windows2003 serveru standard edition ............................... 18 4.1.2 Instalace Active directory a DNS služeb ................................................................. 18 4.1.3 Instalace IIS ................................................................................................................... 19 4.1.4 Instalace Microsoft Exchange 2003 serveru standard edition ............................. 19 4.1.5 Instalace a konfigurace Microsoft Outlook 2003 ................................................... 20 4.1.6 Konfigurace SMTP v testovacím prostředí ............................................................. 20 4.1.7 Instalace aplikace MailSign v testovacím prostředí ................................................ 21 4.2 Způsob, průběh a výsledky testování ................................................................................... 22 4.2.1 Finální testování ............................................................................................................ 22 4.2.2 Výsledky testu ............................................................................................................... 23 4.3 Srovnání s existujícími řešeními, pokud jsou známy ......................................................... 24 Aplikační dokumentace .................................................................................................................... 25 5.1 Instalace ..................................................................................................................................... 25 5.1.1 Systémové požadavky .................................................................................................. 25 5.1.2 Konfigurace SMTP ...................................................................................................... 25 5.1.3 Instalace aplikace .......................................................................................................... 25 5.1.4 Aktivace Event Sink ..................................................................................................... 26 5.1.5 Příklad dávkového souboru pro registraci a aktivování knihovny MailSign ..... 26 5.1.6 Příklad dávkového souboru pro deaktivování a odregistraci knihovny MailSign......................................................................................................................................... 27 1

6

5.2 parametry aplikace.................................................................................................................... 27 5.2.1 Popis parametrů ............................................................................................................ 27 5.2.2 Příklad REG souboru .................................................................................................. 29 5.3 Utilita Cryptpassword .............................................................................................................. 30 5.4 Vzory podpisů .......................................................................................................................... 30 5.4.1 Příklad vzoru podpisu ve formátu prostý text ........................................................ 31 5.4.2 Příklad vzoru podpisu ve formátu HTML .............................................................. 31 5.4.3 Příklad podepsané zprávy ........................................................................................... 31 5.4.4 Atributy Active directory(13) ..................................................................................... 33 5.5 Logování aplikace..................................................................................................................... 35 Závěr .................................................................................................................................................... 36 6.1 Zhodnocení splnění cílů BP................................................................................................... 36 6.2 Diskuse dalšího možného pokračování práce .................................................................... 36

Bibliografie .................................................................................................................................................... i Příloha A - Obsah přiložého CD ............................................................................................................. ii

2

SEZNAM OBRÁZKŮ

Číslo Strana Obrázek 1 konceptuální schéma aplikace............................................................................................... 8 Obrázek 2 uživatelské rozraní editace vzorů ....................................................................................... 10 Obrázek 3 Uživatelské rozraní editace parametrů .............................................................................. 10 Obrázek 4 Deklarace třídy Sink.............................................................................................................. 12 Obrázek 5 Deklarace třídy Sign.............................................................................................................. 13 Obrázek 6 Deklarace třídy ADConnector ........................................................................................... 14 Obrázek 7 Deklarace třídy RegConfig .................................................................................................. 15 Obrázek 8 Deklarace třídy Log .............................................................................................................. 16 Obrázek 9 Schéma SMTP konfigurace ................................................................................................. 21 Obrázek 10 Graf zatížení serveru při odesílání cca 1000 emailů bez použití aplikace MailSign 23 Obrázek 11 Graf zatížení serveru při odesílání cca 1000 emailů s použitím aplikace MailSign. 24 Obrázek 12 Původní zpráva ve formátu prostý text .......................................................................... 32 Obrázek 13 Podepsaná zpráva ve formátu prostý text ...................................................................... 32 Obrázek 14 podepsaná zpráva ve formátu HTML ............................................................................ 33

3

Úvod

1 Úvod Zadání bakalářské práce vychází z konkrétního požadavku mého zaměstnavatele společnosti Autocont CZ a.s, kde pracuji na pozici systémového specialisty pro serverové systémy Microsoft. Ze základní analýzy zadání a možných způsobu řešení problému vyplývá rozdělení projektu na dvě části. Jedna část obsahuje funkční program, který realizuje vlastní elektronický podpis odchozích emailů na základě konfiguračních souborů a komunikace s adresářovou službou Active directory. Tato funkční část bude ověřena v laboratorním prostředí testovacím provozem. Součástí je také popis struktury konfiguračních prvků, který bude poskytovat potřebné zadání pro druhou část. Tato je tvořena návrhem uživatelského rozhraní pro správu systému, které umožní administrátorům modifikovat konfiguraci a měnit tak vlastnosti a chování systému. Implementace uživatelského rozhraní není součástí této bakalářské práce a bude možné jí v budoucnu o tuto doplnit. Systém jednotného firemního podpisu je požadován pro konkrétní softwarovou platformu Microsoft Exchange serveru 2003 provozovaného na operačním systému Microsoft Windows 2003 server. Toto prostředí předurčuje návrh a umožňuje využít možností konkrétních systémových prostředků. Platforma také vymezuje rozsah práce, který se nemusí řešit v obecné rovině, ale zahrne pouze ty části, které jsou v tomto prostředí potřeba.

1.1

DEKLARACE ZÁMĚRU

Systém umožní automaticky vkládat předepsaný firemní podpis do emailů odeslaných uživateli pomocí Microsoft exchange serveru nezávisle na klientském prostředí. Tento podpis musí umět vkládat do elektronického podpisu kromě statického také text dynamický, který je modifikován na základě údajů uživatele z Active directory. Primární využití je určeno pro údaje typu telefonních čísel, názvu oddělení a podobně, které jsou v AD udržovány. Tyto údaje se budou nahrazovat automaticky na základě emailové adresy odesílatele, která je jednoznačným identifikátorem v adresářové službě Active directory.

4

Analýza a návrh řešení

2 Analýza a návrh řešení 2.1

NÁVRH TYPU APLIKACE

Při návrhu bylo potřeba udělat několik základních rozhodnutí. Základní otázkou bylo kam umístit vlastní výkonnou část systému. Podpis je možné doplnit přímo při vytváření emailu na straně emailového klienta. Tato varianta je poměrně náročná a to hned ze dvou důvodů. V prvé řadě je problém s vlastní distribucí konfigurace a výkonné klientské části systému. Druhým problémem je variabilita klientského prostředí. Proto, aby byl systém funkční, bychom museli určit pouze určité typy a verze podporovaných poštovních klientských aplikací. Pro každou takovou aplikaci bychom museli vyvinout a otestovat samostatnou část řešení. Druhá varianta je založena na doplňování podpisu do emailu na serverové straně, což je podstatně jednodušší na realizaci. To je dáno zejména snadnější údržbou serverové konfigurace a také je řešení tvořeno pouze jednou komponentou a administrátorským rozhraním. Zpracování odchozích emailů na straně serveru je možné realizovat několika způsoby. Vytvořením plnohodnotného SMTP serveru, který by sloužil jako takzvaný SMART HOST1. Na tento SMTP server by byl nasměrován veškerý odchozí emailový provoz stejným způsobem, jakým fungují různé antispamové a antivirové systémy nezávislé na platformě vlastního poštovního systému. Vzhledem k jasné specifikaci prostředí, pro které je produkt určen je možné využít vlastností a programového rozhraní Microsoft Exchange serveru a využít takzvané „jímky událostí“ (event sink), která umožňuje programově zachytit a případně modifikovat odchozí i příchozí emaily. Tato poslední varianta byla zvolena jako nejvhodnější a v dané situaci nejefektivnější pro vlastní realizaci projektu.

2.2

VÝVOJOVÉ PROSTŘEDÍ A PROGRAMOVACÍ JAZYK

Pro vývoj aplikací je v dnešní době na výběr velké množství vývojových nástrojů a programovacích jazyků. Dle návrhu projektu je možné jej realizovat pomocí skriptovacího prostředí operačního systému Microsoft Windows server v programovacím jazyku Visual basic script nebo Java script. Toto skriptovací prostředí umožňuje realizovat velké množství úloh, ale jeho hlavní zaměření je na realizaci jednoduchých, převážně administrativních úkonů v prostředí Microsoft Windows. Výsledný produkt bude zpracovávat veškerý odchozí emailový provoz, který bude generován Exchange serverem a uživateli. Dá se odhadnout, že pro malou organizaci (do 50 uživatelů) se bude množství emailů pohybovat v řádech stovek a tisíc denně. Pro řešení úlohy 1

smart host – je typ relay email serveru, který vystupuje jako prostředník a umožňuje směrovat emaily mezi serverem odesílatele a příjemce.

5

Analýza a návrh řešení takovéhoto rozsahu2 není skriptovací prostředí vhodné. Bylo použito pouze pro ověření možného napojení naší komponenty na Exchange server. Pro vlastní vývoj a finální aplikaci je vhodné použít vývojové prostředí, které je schopné vytvořit komponentovou aplikaci na bázi COM nebo COM+3 kterou jsme také schopni napojit na programové rozhraní Exchange serveru. V mém případě padla volba na vývojové prostředí Microsoft Visual studio 2008 a programovací jazyk C++4.

2.3

PROBLÉMY A OMEZENÍ NÁVRHU

Návrh systému automatického podpisu, který je zpracováván na straně serveru, bez vazby na poštovního klienta, který vytváří email, trpí několika typy problémů, na které je nutné se zaměřit a pokusit se je eliminovat nebo alespoň zmírnit jejich dopad. Jedním z nejproblematičtějších je duplicitní podepisování, případně zařazení podpisu do špatného místa emailu. 2.3.1

Problém duplicitního podepisování

K této situaci dochází zejména při odpovídání nebo při předávání emailu dalším adresátům. Tuto zprávu generuje poštovní klient na základě původní zprávy bez jednoznačného rozlišení nového a původního obsahu. Z pohledu komunikačního protokolu a vnitřní reprezentace zprávy je takto vytvořená zpráva opět novou plnohodnotnou zprávou. Zde dochází k výše uvedenému problému, jelikož server, který tuto zprávu doručuje, není schopen rozeznat již jednou podepsaný email a nemůže s určitostí zajistit, aby podpis nebyl do zprávy začleněn znovu duplicitně. Tento problém je možné částečně vyřešit rozeznáváním určitých formátovacích znaků ve zprávě a na základě těchto znaků se rozhodnout, jestli podpis ke zprávě připojit či nikoli. Jeden ze znaků jak poznat předávanou případně odpovědní zprávu je na základě předmětu zprávy, kde je většinou přidán prefix „Re:“ v případě odpovědi nebo „Fw:“ v případě předání zprávy. Toto nejjednodušší rozlišení je možné použít, a tyto typy zpráv nepodepisovat automatickým podpisem. Tím je možné zabránit hromadění podpisů při poštovní konverzaci mezi dvěma poštovními adresami. Problém jsme tímto však neodstranili úplně, jelikož používané prefixy v předmětu nejsou zakotveny v žádném standardu a jsou závislé pouze na poštovním klientu, který takovouto zprávu vytváří. V praxi se můžeme setkat s jinou modifikací prefixů, zejména v německy mluvících zemích. Například pro identifikaci odpovědi je použit prefix „Antwort:“. Pro zkvalitnění rozpoznávání takových to zpráv je možné tyto varianty začlenit do konfigurace aplikace. Toto řešení umožní administrátoru automatického podpisu nastavit případné odlišnosti na základě aktuálně používaných prefixů, případně doplnit některé zvláštní prefixy, které se běžně nevyskytují. 2

Zadání nespecifikuje výkonové požadavky ani množství zpracovaných emailů, takže předpokládáme střední zatížení.

3

COM, COM+ (component object model) je standardní rozhraní vyvinuté společnosti Microsoft v roce 1993, umožňující komunikaci mezi procesy a dynamické vytváření objektů v libovolném programovacím jazyku, který tuto technologii podporuje.

4

C++ je objektově orientovaný programovací jazyk, který vyvinul Bjarne Stroustrup a další v Bellových laboratořích AT&T rozšířením jazyka C

6

Analýza a návrh řešení Další možností je si při podpisu tvořit jakýsi otisk (hash), který začleníme do zprávy jako takové. Tento hash by byl vyhledáván při rozhodování, jestli zpráva již neobsahuje jeden automaticky vytvořený podpis. Při tomto řešení je největším problémem jak takový to hash začlenit do zprávy, aniž bychom nějakým způsobem ovlivnili vlastní obsah zprávy nebo formátování. Při základní analýze bylo rozhodnuto, že tento druh označení podpisu ve zprávě nebude realizován z důvodů technické náročnosti řešení a také možných problémů s antispamovými systémy. Tyto systémy jsou v poštovních cestách využívány a zajišťují ochranu proti nevyžádané poště (spamu), které provádějí rozsáhlé sady testů a heuristické analýzy pro rozeznání běžných zpráv od nevyžádané pošty a každý nestandardní nebo neobvyklý obsah v poštovní zprávě zvyšuje bodové ohodnocení, které může mít za následek zařazení běžných emailů podepsaných automatickým podpisem s hashem zařazení do spamu a zabránit tak běžnému doručení. 2.3.2

Kryptování emailu, případně elektronický podpis šifrovacím klíčem

Kryptování, nebo podpis emailu šifrovacím klíčem je také pro zpracování automatického podpisu na serverové straně problém, jelikož obě metody mají ochránit email před modifikací cizí osobou takzvaného „muže uprostřed“ (Man in the middle). Což se přesně snaží udělat aplikace pro automatický podpis. Z tohoto důvodu je nutné emaily chráněné šifrováním nebo podepsané šifrovacím klíčem identifikovat a nechat je nezměněny. Pokud by takováto zpráva měla být opatřena automatickým podpisem, musel by mít systém přístup k šifrovacím klíčům odesílatelů zpráv a při podepisování by zpráva musela být rozšifrována, přidán podpis a opět zašifrována patřičnými klíči. Toto řešení je velice omezující, jelikož by bylo závislé na komunikaci s PKI 5infrastrukturou a také na přístupu k tajným klíčům odesílatele, což by mohlo být v rozporu s bezpečnostní politikou organizací využívající tento systém. Z těchto důvodů není toto řešení do navrhovaného systému zapracováno a takovéto emaily budou procházet beze změn. 2.3.3

Formát emailu a kódování emailu

Formát emailové zprávy je doporučen v RFC 6822 a navazujících RFC, které definují potřebné vlastnosti jednotlivých částí zprávy. Pro zpracování emailů jsou používány COM rozhraní Microsoft Exchange serveru a operační systémy, které výrazně zjednodušují práci s emailem. Díky těmto rozhraním není potřeba zpracovávat kompletní implementaci podle výše uvedených RFC. K problému s kódováním znakové sady emailu může dojít v případě, že použitá znaková sada původního emailu neumožňuje používání speciálních znaků a podpis je naopak vyžaduje. V tuto chvíli bude znaková sada původního emailu změněna na rozšířenou dle konfigurace aplikace. Bude možné také tuto změnu potlačit a naopak přidávaný podpis bude překódován do standardní znakové sady USASCII.

5

PKI je Public Key Infrastructure je prostředí, které umožňuje ochranu informačních systémů, elektronických transakcí a komunikace. Zahrnuje veškerý software, technologie a služby, které umožňují využití šifrování s veřejným a privátním klíčem.

6

RFC je zkratka anglického výrazu request for comments (žádost o komentáře), která se používá pro označení řady standardů a dalších dokumentů popisujících Internetové protokoly, systémy apod

7

Analýza a návrh řešení 2.4

SCHÉMA NAVRHOVANÉ APLIKACE

Aplikace je rozdělena do dvou základních částí, které dohromady zajišťují potřebnou funkčnost celého systému. Výsledná aplikace je tvořena dynamicky linkovanou knihovnou 7 (DLL), která poskytuje předepsané rozhraní pro zpracování emailu při průchodu službou SMTP serveru. Dále systém obsahuje konfigurační soubory (vzory podpisů) a konfiguraci tvořenou administračním rozhraním (součástí této práce je pouze návrh uživatelského rozhraní pro administrační aplikaci).

Obrázek 1 konceptuální schéma aplikace

2.5

ÚLOŽIŠTĚ KONFIGURACE A KONFIGURAČNÍ SOUBORY

Návrh konfiguračního úložiště vychází ze standardního prostředí Microsoft Windows a potřeb aplikace. Konfigurace aplikace obsahuje dvě části rozdílné svou povahou, proto tuto situaci návrh respektuje a využívá dvě odlišné metody pro uložení jednotlivých částí konfigurace.

7

DLL funkční logický celek, který poskytuje služby pro programy. Většinou se jedná o sbírku procedur, funkcí a datových typů, či při objektově orientovaném přístupu o sadu tříd, uložených v jednom diskovém souboru. Knihovna poskytuje aplikační programátorské rozhraní (zvané API), které umožňuje programu volat funkce poskytované touto knihovnou.

8

Analýza a návrh řešení Pro uložení konfiguračních parametrů je použit systémový registr8, kde jsou jednotlivé parametry uloženy a čteny pomocí systémových volání operačního systému. Dále je zde využito možnosti kontroly změny konfigurace za běhu programu, aby nebylo nutné při každé změně konfigurace administrátorem restartovat služby poštovního systému a nebyla změna konfigurace vázána na množství administrativních úkonů případně odstávek systému. Tato kontrola se děje také pomocí registrace k odběru události o změně patřičného klíče v systémovém registru. V případě, že k takovéto změně dojde, aplikace si sama přečte novou konfiguraci a provede potřebné inicializace. Toto řešení je využito zejména pro jeho malou náročnost na zatížení systému oproti běžnému řešení, kde je konfigurace načítána pokaždé před jejím použitím. Druhou částí jsou vzory pro podpis ve dvou základních formátech. Pro tyto vzory jsou využity konfigurační soubory, které se při spuštění aplikace načtou do vnitřních struktur aplikace operační paměti. Tato je zejména kvůli rychlejšímu přístupu k informacím a nižší zátěži diskového subsystému poštovního serveru. Při inicializaci se také vytvoří seznam dynamických atributů, které představují doplňované informace z Active directrory. Tyto vzory je možné aktualizovat za běhu aplikace bez nutnosti restartu poštovního systému, k tomu je využito hlídání událostí v klíčích aplikace v systémovém registru. Pro správnou funkčnost je nutné, aby při změně vzoru podpisu došlo ke změněně některého z klíčů aplikace v systémovém registru. Toto musí zajistit konfigurační aplikace, která bude udržovat číslování verzí konfigurace a při změně vzoru upraví verzi souboru v registru. V případě provozu bez konfigurační aplikace musí tento krok provést administrátor a verzi konfigurace změnit v systémovém registru ručně.

2.6

NÁVRH UŽIVATELSKÉHO ROZHRANÍ PRO ADMINISTRACI A KONFIGURACI

Nástroj pro konfiguraci aplikace MailSign bude sloužit administrátorům pro změnu a nastavení všech modifikovatelných parametrů aplikace. Dále by měl umožňovat vytvářet a editovat vzory podpisů v obou používaných formátech. Na základě těchto požadavků byl vytvořen návrh grafického rozhraní, zpracovaný v Microsoft Office Visio 2007 uvedený v následujících screenshotech.Potom bude potřeba implementovat zápisy konfiguračních parametrů do systémového registru, registraci knihovny MailSign a registraci do jímky událostí.

8

Systémový registr

9

Analýza a návrh řešení

Obrázek 2 uživatelské rozraní editace vzorů

Obrázek 3 Uživatelské rozraní editace parametrů

10

Realizace

3 Realizace Funkčnost vytvářené aplikace byla rozdělena na 5 částí, kde každá zajišťuje specifické funkce. Základní částí je vlastní dll knihovna (MailSign), která aplikaci zapouzdřuje a poskytuje operačnímu systému dvě procedury na registraci a odregistraci knihovny dll. Také obsahuje rozhraní pro třídu Sink, která je použita při vlastní komunikaci s Exchange (SMTP) serverem. Tato používá knihovnu Active Template Library9, která je součástí vývojového prostředí Microsoft Visual Studio 2008 professional a výrazně zjednodušuje práci s COM objekty. Při komunikaci s Exchange serverem je ještě využívána sada objektů CDO10. Jelikož aplikace pouze doplňuje funkci poštovního sytému, byl při vývoji dáván důraz na ošetření chybových stavů, aby nedocházelo k pádům celého poštovního sytému. Aplikace se dá změnou konfigurace jednoduše testovat a také rychlým zásahem vypnout či pozastavit její činnost, tak aby emailový provoz nebyl ohrožen. Byla snaha co nejvíce ošetřit vnitřní chybové stavy tak, aby v případě vzniku kritické chyby, která by mohla způsobit pád systému (např. nefunkční konfigurace), je tato chyba pouze zapsána do logu a vlastní podepisovaný email je propuštěn beze změn. Aplikace je kompilována pro jedno vláknové zpracování s předpokladem, že v budoucí verzi bude plně doplněna o synchronizační mechanizmy a Exchange server mohl plně využít paralelní zpracování odchozích emailů. Některé části kódu již mají implementovány synchronizační mechanizmy pomocí kritických sekcí.

9

ATL - The Active Template Library je sada vzorů založena na C++ třídách vyvinuta společností Microsoft, která zjednodušuje programování Component Object Model (COM) objektů.

10

CDO - Collaboration Data Objects pro Microsoft® Windows® 2000 (Cdosys.dll) implementuje verzi 2.0 Collaboration Data Objects API specifikace, je to Component Object Model (COM) pro jednoduchý vývoj programů, které vytváření, nebo manipulují s emaily

11

Realizace 3.1

3.1.1

POPIS IMPLEMENTOVANÝCH TŘÍD

Class Sink

Obrázek 4 Deklarace třídy Sink

Třída Sink je klíčovou třídou při komunikaci se SMTP serverem. Jelikož implementuje předepsané rozhraní, obsahuje potřebné funkce, které toto rozhraní vyžaduje. Z pohledu vývoje aplikace jsou klíčové dvě funkce. Jednou z nich je Load, která je volána při zavedení knihovny do paměti. Tato funkce inicializuje všechny potřebné objekty. Hlavní funkcí třídy sink je implementace funkce OnArrival, která je volána dispečerem exchange serveru na základě registrace knihovny v jímce událostí. Při návrhu jsem volil mezi implementací již zmíněné funkce OnArrival a nebo funkce OnMessageSubmission. Obě mají v serveru Exchange 2003 stejný význam. Mnou vybraná má výhodu v možnosti širšího využití, jelikož je také využívána smtp serverem integrovaným přímo v operačním systému Windows XP, Windows 2000 a také v Exchange serveru 2000, takže aplikace je funkční i na těchto platformách a nevyžaduje přímo Exchange server 2003. Nicméně na základě zadání proběhlo ladění a testování na požadované platformě Exchange server 2003. Kompletní funkčnost aplikace bez otestování na ostatních platformách není možné garantovat. 12

Realizace Funkce OnArrival analyzuje email a dle konfiguračních parametrů jej doplní podpisem, který jí poskytuje třída sing. Pro kontrolu předmětu z důvodů duplicitních podpisů uvedených v části návrhu je využívána pomocná funkce TestSubjOk. 3.1.2

Class Sign

Obrázek 5 Deklarace třídy Sign

V této třídě je zahrnuta logika související se získáním podpisů na základě vzorů podpisu. Opět se dají funkce této třídy rozdělit do dvou kategorií. První část se stará o vytvoření všech potřebných objektů, načtení konfigurace a vzorů podpisu ve dvou, v tuto chvíli implementovaných, formátech (HTML, TXT). Z důvodů snížení provozní zátěže diskového subsystému se konfigurace včetně vzorů načte do paměti, kde zůstává po celou dobu života třídy. Před použitím podpisu se pouze testuje verze konfigurace a při její změně se provede reinicializace všech proměnných. Toto řešení umožňuje měnit chování aplikace za chodu a nevyžaduje při těchto změnách restarty příslušných služeb poštovního systému. Vzory podpisů jsou načteny jako dva oddělené spojové seznamy. Vzorový soubor je rozdělen na části oddělovačem atributů (zvojené %%), kde obsah je uložen v jednom spojovém seznamu a zástupné identifikátory v seznamu atributů. Do provozní části spadá funkce GetSign, která zajišťuje vytvoření personifikovaného podpisu na základě emailové adresy a dotazu do Active Directory, který vrací do třídy sink. Celý proces sestavování podpisu probíhá procházením obou spojových seznamů, přičemž jednotlivé zástupné identifikátory jsou nahrazovány dle získaných informací z Active Directory

13

Realizace 3.1.3

Class ADConnector

Obrázek 6 Deklarace třídy ADConnector

Pro komunikaci s Active Directory.se využívá třída ADConnector Obsahuje pouze konstruktor, destruktor, funkci pro získání vlastních informací z AD a pomocnou funkci pro ošetření chybových stavů. Funkce GetAttrSet obsahuje vstupně-výstupní parametr, třídu „map“ ze standard template library. Tato mapa obsahuje seznam jmen jednotlivých atributů, které je potřeba doplnit hodnotou na základě emailové adresy. Při zpracování se nejprve funkce připojí do AD, vytvoří si LDAP dotaz na základě seznamu požadovaných atributů a nechá dotaz vyhodnotit. Výsledek dotazu je zpracován a hodnoty atributů jsou přidány do mapy, která je vrácena, resp. její ukazatel, volající části.

14

Realizace 3.1.4

Class RegConfig

Obrázek 7 Deklarace třídy RegConfig

Třída RegConfig je využívána ve všech ostatních částech aplikace. Slouží jako vnitřní rozhraní pro získání konfigurace ze systémového registru. Kromě funkcí pro získání jednotlivých konfiguračních parametrů obsahuje také funkci pro kontrolu změny parametrů. 15

Realizace Tato funkce je důležitá pří změně konfigurace, aby aplikace byla schopná za běhu měnit své chování dle změn administrátora a nebyl vyžadován restart celého poštovního systému. Pro tuto kontrolu využívá zaregistrování události změny patřičného klíče systémového registru v operačním systému. Je testován pouze zaregistrovaný objekt a nemusí se cyklickými dotazy do systémového registru při každém čtení některého z parametrů zatěžovat celý systém. 3.1.5

Class Log

Obrázek 8 Deklarace třídy Log

Třída Log je pomocnou třídou a také se používá v celé aplikaci. Jejím jediným posláním je zápis událostí a chyb do systémového a souborového logu. Obsahuje jednu funkci a pro svou činnost vyžaduje instanci třídy RegConfig, pomocí které získává parametry logování (rozsah a umístění log souboru).

3.2

3.2.1

POZNÁMKY K PŘEKLADU APLIKACE

Vývojové prostředí a překlad aplikace

Jako vývojové prostředí bylo využíváno Microsoft Visual Studio 2008 Professional, které poskytuje všechny potřebné nástroje pro vývoj tohoto typu aplikace. Aplikace využívá několik třídy z Microsoft Foundation Class Library11, Active Template Library a .NET. Dále jsou využívané některé systémové volání operačního systému. Všechny tyto knihovny jsou dostupné v distribuci vývojového prostředí a Windows SDK12 verze 6A. Pro vytvoření ATL projektu v Microsoft Visual Studiu byly využity informace z webu Microsoft MSDN(1) Pro překlad knihovny MailSign byla zvolena znaková sada Unicode a také použití ATL se statickým linkováním a používání STL. Statické linkování knihoven je produkuje větší výslednou knihovnu MailSign, ale zajišťuje nezávislost na ostatních částech operačního systému.

11

MFC - Microsoft Foundation Class Library (také Microsoft Foundation Classes) je knihovna, která zabaluje část Windows API v C++ třídách, zahrnující funkcionalitu umožňující používat výchozí aplikační framework.

12

SDK - software development kit je typicky sada vývojových nástrojů, která umožňuje softwarovým inženýrům vytvářet aplikace, softwarové balíčky, softwarové frameworky, hardwarové platformy, počítačové systémy, herní konsole, operační systémy, nebo podobné platformy.

16

Realizace 3.2.2

Ladění aplikace

Ladění aplikace probíhalo na dálku pomocí Remote debuggeru, který je součástí vývojového prostředí Visual Studio 2008. Pro tento způsob je nutné na serveru, kde běží aplikace MailSign spustit Visual Studio Remote Debugging Monitor a nastavit režim ověřování. V mém testovacím prostředí jsem používal režim bez ověřování. Jelikož není aplikace MailSign samostatně spustitelná je nutné se při ladění kódu vzdáleně připojit na proces Internet Information Serveru, který se jmenuje inetinfo.exe. Po připojení k tomuto procesu je možné postupovat běžným způsobem. Po nastavení breakpointů v našem kódu a vyvolání události onArrival posláním emailu přes SMTP server.

17

Testování

4 Testování 4.1

KONFIGURACE TESTOVACÍHO PROSTŘEDÍ

Pro testování a vývoj bylo využito Virtuální prostředí společnosti VMware Workstation 6.0.5. Vlastní provoz však není na tomto prostředí závislý. Systém je možné provozovat jak ve fyzické tak v jiné virtualizační platformě, která umožňuje provoz operačního serveru Microsoft Windows 2003 server. 4.1.1

Instalace Microsoft Windows2003 serveru standard edition

Pro instalaci a provoz operačního systému Windows 2003 serveru je vyžadován hardware specifikovaný v následující tabulce. Tabulka 1 Systémové požadavky(2)

Hodnota

Mimimální

Doporučená

Rychlost procesoru

133 MHz

550 MHz

Velikost paměti RAM

128 MB

256 MB

Volné místo na disku

1,5 GB

10 GB

Požadavek

Pro testovací provoz a ladění aplikace byl virtuální server nakonfigurován tímto způsobem: 512 GB RAM 8 GB disk 1 procesor Intel Core 2 duo T9300, 2.5 GHz Operační systém byl instalován v anglické jazykové mutaci standardním způsobem. Během instalace bylo navíc zvoleno české národní prostředí, aby bylo možné otestovat správnost aplikace včetně českých znaků. Dále byl nainstalován servisní balíček service pack 2 a provedena kompletní aktualizace systému pomocí Windows update k 4.1.2009. 4.1.2

Instalace Active directory a DNS služeb

Pro provoz Exchange serveru je nutný řadič Active directory a DNS server. V našem případě jsou všechny tyto role na jednom serveru spolu s Exchange. Tato instalace byla provedena pomocí průvodce konfigurací serveru a přidáním patřičných rolí.(3) 18

Testování Název domény AD pro testování byl zvolen salajka.local. 4.1.3

Instalace IIS

Chod Exchange serveru dále vyžaduje některé z komponent Internet Information serveru. Pomocí průvodce konfigurací serveru byla doplněna role aplikačního serveru s těmito komponentami operačního systému(4): • .NET Framework • ASP.NET • Internet Information Services (IIS) • World Wide Web Publishing Service • Simple Mail Transfer Protocol (SMTP) service • Network News Transfer Protocol (NNTP) service 4.1.4

Instalace Microsoft Exchange 2003 serveru standard edition

Exchange server 2003 má také definovány minimální a doporučené požadavky na hardware, které jsou shrnuty v následující tabulce. Tabulka 2 Systémové požadavky(5)

Hodnota

Mimimální

Doporučená

Rychlost procesoru

133 MHz

550 MHz

Velikost paměti RAM

128 MB

512 MB

Volné místo na disku (závislé dle množství dat)

700 MB

2 GB

Požadavek

Instalace Exchange serveru 2003 se skládá z několika základních kroků: 1. Příprava „lesa“ Active directory pomocí programu setup.exe /forestprep z instalačního CD Exchange serveru(6) 2. Příprava domény Active directory pomocí programu setup.exe /domainprep z instalačního CD Exchange serveru(7) 3. Instalace vlastního exchange serveru a vytvoření nové Exchange organizace(8) 4. Instalace servisního balíčku Service pack 2(9) 5. Instalace dalších dostupných aktualizací pomocí služby Microsoft update

19

Testování 4.1.5

Instalace a konfigurace Microsoft Outlook 2003

Pro testování byla nainstalována a nakonfigurována aplikace Microsoft Outlook 2003, která je součástí Microsoft Exchange server 2003. Pro testovací účely byla zvolena česká jazyková mutace, aby se testovací prostředí nejvíce blížilo budoucímu nasazení. Opět byl nainstalován poslední dostupný servisní balíček Service pack 3 a další aktualizace vydané společností Microsoft k 4.1.2009. V poslední fázi byl nastaven profil outlooku tak, aby používal připravený exchange server a byla otestována komunikace s exchange serverem pomocí testovacích emailů. 4.1.6

Konfigurace SMTP v testovacím prostředí

Po instalaci Exchange serveru je vytvořen jeden základní virtuální SMTP server pomocí kterého Exchange komunikuje s ostatními poštovními systémy. Tento SMTP server je používán jak pro odchozí tak pro příchozí poštu. Pro základní funkci aplikace je možné použít tento jeden smtp server, který již vytvořila instalace Exchange serveru. Při testech aplikace bylo zjištěno, že přes událost onArrival neprochází všechny odesílané emaily. Emaily zaslané pomocí OWA 13(Outlook Web Acces interface) nejsou v jímce událostí zachyceny a emaily zaslané pomocí MAPI 14rozhraní nemohou být při události onArrival modifikovány. Toto zjištění bylo následně potvrzeno v dokumentech popsaných společností Microsoft(10). Na základě tohoto zjištění byl upraven původní návrh a pro odchozí emaily je vytvořen druhý SMTP server ve funkci tzv. SMART hosta. V původním návrhu aplikace byla tato varianta zmíněna z důvodů možného oddělení exchange serveru a serveru pro podepisování. Na základě výše uvedených zjištění je toto oddělení SMTP serverů pro správnou funkci aplikace nutné. Jelikož Microsoft Windows umožňuje provozovat více virtuálních SMTP serverů v jednom operačním systému, je využito této konfigurace, aniž by byla potřeba dalšího operačního systému.

13

OWA – Outlook Web Access, původně nazýván Exchange Web Connect (EWC), je a webová poštovní služba Microsoft Exchange Server 5.0 a novějších.

14

MAPI - Messaging Application Programming Interface (MAPI) je poštovní architektura a COM rozhraní založené na aplikačním programovém rozhraní pro Microsoft Windows

20

Testování

Obrázek 9 Schéma SMTP konfigurace

Tento druhý pomocný SMTP server je nakonfigurován pomocí Microsoft Exchange system manageru ve větvi Organization\Servers\Myserver\Protocols\SMTP, kde je přidán další virtuální SMTP server. Je potřeba změnit standardní TCP port 25 na jiný volný port (např. 26), povolíme relay pro sama sebe. V dalším kroku je nutné nastavit port pro odchozí provoz základního virtuálního smtp serveru na port 26 a také IP adresu smart hosta. Pro inicializaci všech provedených změn je nutné restartovat SMTP službu příkazem iisreset z příkazového řádku a otestovat konfiguraci zasláním testovacího emailu. 4.1.7

Instalace aplikace MailSign v testovacím prostředí

Instalace a konfigurace je popsána v kapitole 5 aplikační dokumentace s těmito konfiguračními parametry uvedenými ve formátu reg souboru: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont] [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont\MailSign] "Enabled"=dword:00000001 "LdapContainer"="DC=salajka,DC=local" "LdapUser"="[email protected]" "HtmlFileName"="C:\\mailsign\\sign.htm" "TextFileName"="C:\\mailsign\\sign.txt" "TestEmail"="[email protected]" "LdapSubTree"=dword:00000001

21

Testování "LogFile"="" "LdapPassword"=hex:c0,44,41,57,62,38,36,38,68,65,55,3e,73,7d,47,2e,6c,39,3c,68,\ 5c,40,33,79,6f,5e,6c,3a,4f,4f,58,28,69,4c,40,00 "EventLogLevel"=dword:00000001 "FileLogLevel"=dword:00000000 "Testing"=dword:00000000 "ConfigSerialNumb"=dword:00000008 "ConvCharSet"="iso-8859-2" "ConvertUSACIICharSet"=dword:00000001 "ExcudedSubject"="RE:;FW:" Pozn: Aplikace vyžaduje nainstalovaný .NET Framework 1.x. Tento framework je vyžadován již k instalaci Exchange server, takže není potřeba ho instalovat samostatně

4.2

ZPŮSOB, PRŮBĚH A VÝSLEDKY TESTOVÁNÍ

Základní testování probíhalo přímo při vývoji jednotlivých částí aplikace. Pro testování a ladění částí týkajících se konfiguračních parametrů a komunikace s active directory byla vytvořena jednoduchá pomocná aplikace AdReader, která umožňuje využít pro ladění většinu funkcí programu bez potřeby využívat Exchange server. Tímto se vývoj a ladění zjednodušilo a umožnilo zpracovávat projekt postupně ve dvou na sobě nezávislých částech. Jedna zabývající se vytvořením podpisu na základě vzorů a dotazů do Active directory a druhá týkající se implementace rozhraní komunikující s Exchange serverem. V závěru byly pak tyto části spojeny a testovány společně. Před finalizací práce bylo provedeno testování podepisování emailů různých typů formátů a kódování, aby se prověřila nezávislost na typu obsahu. Také bylo použito několik druhů podpisu využití zástupných znaků v různých částech podpisu včetně nesprávných identifikátorů a podobně. Na závěr byl udělán výkonový test se zaznamenáváním vytížení paměti a procesorů, který by měl prověřit zpracování větším objemu emailů a dopad aplikace na zatížení procesoru. Reálné testování proběhne před nasazením do ostrého provozu. Aplikace umožňuje přepnutí do testovacího režimu z důvodů kontroly vzorů podpisu a také pro kontrolu funkčnosti. Tímto způsobem je možné nechat si doručovat kopii emailů do testovací schránky a kontrolovat dopad na výslednou zprávu. V tomto režimu je dobré aktivovat jímku událostí pouze na část odchozích emailů pomocí omezující podmínky, kterou jímka událostí obsahuje. Tato podmínka sníží v testovacím provozu riziko, v případě poruchy či nefunkčnosti aplikace a jejího negativního dopadu na chod zavádějící organizace. 4.2.1

Finální testování

Pro tento účel bylo použito několik vzorových emailů, které byly použity jako základ pro generování do celkového počtu 1000. Tyto emaily byly odeslány pomocí SMTP serveru dvakrát, jednou bez aktivované aplikace MailSign, při zaznamenávání zátěže procesoru a paměti a diskové fronty. Podruhé byla při odesílání stejného množství emailů aktivována 22

Testování aplikace MailSign a opět byla zaznamenávána zátěž. Tento test je pouze orientační, jelikož neproběhl na vyhrazených hw strojích s konstantními parametry (byl proveden ve virtuálním prostředí), mohl být ovlivněn aktuální rychlostí připojení do internetu při odesílání emailů a také možným rozdílem požadavků hostujícího operačního systému a jeho běžících aplikací při jednotlivých testech. 4.2.2

Výsledky testu

V testu byla ověřena funkčnost aplikace při větším zatížení a také byly zaznamenány výkonové požadavky na vlastní proces podepisování emailů. Z analýzy následujících grafů se potvrdily předpoklady o vyšším zatížení procesoru oproti zpracování stejného objemu zpráv bez podepisování. Tato zátěž je vidět na začátku druhého grafu, kde se zvýšilo okamžité vytížení procesoru o zhruba 20%, a prodloužila se úvodní doba zpracování emailové fronty ze 45 sekund na 1 minutu 20 sekund15. Zbývající část grafu se v obou případech neodlišuje a je dána odesíláním již připravených zpráv ve frontě na cílový SMTP server. Na základě tohoto testu je možné konstatovat, že nasazením aplikace MailSign neomezíme celkový provoz poštovního serveru při běžném zatížení v malé a střední organizaci a je možné ho provozovat i v organizaci s větším poštovním provozem.

Obrázek 10 Graf zatížení serveru při odesílání cca 1000 emailů bez použití aplikace MailSign

15

Uvedené grafy neobsahují přesné časové měřítko, časové údaje byly zjištěny z grafického rozhraní Microsoft Management Console pro sledování výkonu.

23

Testování

Obrázek 11 Graf zatížení serveru při odesílání cca 1000 emailů s použitím aplikace MailSign

4.3

SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI, POKUD JSOU ZNÁMY

Na trhu byl nalezen komerční produkt Mail Signature Manager(11) společnosti Symprex sídlící v Londýně. Řešení této společnosti nabízí uživatelům a administrátorům komfortní komplexní řešení jednotných podpisů v emailech. Díky zpracování podpisu již v klientské emailové aplikaci nabízí vetší funkčnost, ale také náročnější údržbu celého systému. Pro distribuci vzorů podpisů je nutné zajistit pravidelné spouštění úlohy replikující konfiguraci na všech klientských počítačích, což je v dnešní době díky stále se zvětšujícím možnostem mobilních zařízení problematičtější. Protikladem takovému robustnímu řešení je implementace realizovaná v této bakalářské práci, které je jednoduchá na údržbu i kontrolu bez rizika množení problémů způsobovaných rozmanitostí náročnou údržbou koncových zařízení s poštovními klientskými aplikacemi. Vzhledem k jednoduchosti aplikace MailSign je možné předpokládat, že i náklady na následný support dané životním cyklem aplikace budou oproti řešení společnosti Symprex nižší a tím i případná cena řešení a podpory MailSign může být pro případné zákazníky nižší.

24

Aplikační dokumentace

5 Aplikační dokumentace Aplikace slouží pro doplňování podpisů a případných právních omezení do odchozích emailů pro Exchange server 2003. Doplňované informace mohou být dynamicky modifikovány na základě informací z Active directory dle emailové adresy odesílatele.

5.1

INSTALACE

Instalace aplikace spočívá ve třech krocích. Zápis konfiguračních parametrů do registru, registrace knihovny mailsign.dll a aktivace jímky událostí. Aplikace se instaluje na funkční SMTP server, který je používán pro odchozí emailovou komunikaci Exchange Serveru. 5.1.1

Systémové požadavky

Aplikace pro svůj běh vyžaduje knihovny .NET framework16 verze 1.x. Za předpokladu, že je na serveru nainstalován Exchange Server 2003 včetně OWA je již toto zajištěno. 5.1.2

Konfigurace SMTP

Pro správný chod aplikace je potřeba zajistit tok všech emailů přes jeden smtp server. Tohoto lze nejsnáze dosáhnout pomocí konfigurace tzv. smart hosta a nasměrovat na něj všechen odchozí provoz z Exchange serveru. Tato konfigurace má také výhodu v možnosti oddělení zátěže produkované vlastním podepisováním a provozu Exchange serveru. Pro organizaci s menším emailovým provozem je možné konfigurovat takovýto smtp server na stejném serveru, jen na jiném TCP portu. 5.1.3

Instalace aplikace

Pro aplikaci doporučuji vytvořit samostatný adresář např. C:\Program files\MailSign, do něj nakopírovat knihovnu mailsign.dll a podpůrné soubory. Pro soubory s předlohami podpisu a log soubor je vhodné vytvořit podadresář z důvodu oddělení uživatelských oprávnění. Import konfiguračních parametrů do registru pomocí systémové utility regedit. Tato je součástí operačního systému a nachází se v adresáři %SystemRoot%\system32\ (zpravidla C:\widows\system32\). Jako parametr se dává název souboru typu reg, kde jsou vypsány všechny konfigurační parametry aplikace. Tyto parametry je možné do systémového registru zadat ručně pomocí grafického rozhraní utility regedit. Všechny parametry jsou podrobně popsány v kapitole 5.1.2. Příklad zapsání parametrů do registru

16

Microsoft .NET Framework je softwarový framework který je dostupný s některými verzemi operačních systémů Microsoft Windows

25

Aplikační dokumentace %SystemRoot%\regedit.exe c:\mailsign\mailsign.reg

Zaregistrování aplikace (dll knihovna) v operačním systému se provede pomocí utility regsrv32.exe. Tato je součástí operačního systému a nachází se v adresáři %SystemRoot%\system32\ (zpravidla C:\widows\system32\). Jako parametr se dává název knihovny dll včetně cesty k ní. Registrace: %SystemRoot%\system32\regsrv32.exe c:\mailsign\mailsign.dll

Odregistrování (před odregistrováním je potřeba aplikaci deaktivovat – zrušit aktivaci jímky událostí): %SystemRoot%\system32\regsrv32.exe –u c:\mailsign\mailsign.dll

5.1.4

Aktivace Event Sink

Pro aktivaci jímky událostí a registraci odběru je využíván skript smtpreg.vbs společnosti Microsoft. Je k dispozici na www stránkách společnosti microsoft: http://msdn.microsoft.com/en-us/library/ms528023.aspx(12). Tento skript má několik parametrů, pro registraci je potřeba specifikovat id virtuálního SMTP serveru, dále typ události (v našem případě onArrival) dále textový název konkrétní registrace události a název události třídy sink v knihovně dll. Také je potřeba specifikovat podmínku, na které emaily se má tato událost aplikovat (pro naše využití je požadavek aplikovat podpis na všechny odchozí emaily). Tuto podmínku je možné změnit před nasazením do ostrého provozu na specifikaci pouze určitých testovacích zpráv, aby nedošlo při špatné konfiguraci k ohrožení provozu organizace. Aktivace: %SystemRoot%\system32\cscript.exe c:\mailsign\smtpreg.vbs /add 2 onarrival AC_MailSign mailsign.sink „mail from=*”

Deaktivace (po deaktivaci je vhodné provést restart SMTP služeb pro uvolnění systémových prostředků např. příkazem IISRESET): %SystemRoot%\system32\cscript.exe c:\mailsign\smtpreg.vbs /remove 2 OnArrival AC_MailSign

5.1.5

Příklad dávkového souboru pro registraci a aktivování knihovny MailSign

@echo off If "%1"=="/?" goto help If "%1"=="" goto help %SystemRoot%\regedit.exe /s %1\mailsign.reg %SystemRoot%\system32\regsvr32.exe -s %1\mailsign.dll %SystemRoot%\system32\cscript.exe %1\smtpreg.vbs /add %2 onarrival AC_MailSign mailsign.sink "mail from=*" goto end :help echo davka registruje knihovnu MailSign.dll a aktivuje jimku udalosti

26

Aplikační dokumentace echo pouziti: echo %0 'adresar s instalovanou aplikaci MailSign' 'cislo virtualniho SMTP serveru' :end

5.1.6

Příklad dávkového souboru pro deaktivování a odregistraci knihovny MailSign

@echo off If "%1"=="/?" goto help If "%1"=="" goto help %SystemRoot%\system32\cscript.exe %1\smtpreg.vbs /remove %2 OnArrival SignSink %SystemRoot%\system32\regsvr32.exe -s -u %1\mailsign.dll goto end :help echo davka registruje knihovnu MailSign.dll a aktivuje jimku udalosti echo pouziti: echo %0 'adresar s instalovanou aplikaci MailSign' 'cislo virtualniho SMTP serveru' :end

5.2

PARAMETRY APLIKACE

Pro správný chod aplikace je potřeba nastavit několik parametrů v systémovém registru. Parametry musejí být umístěny v klíči "HKLM\Software\Autocont\MailSign\". 5.2.1

Popis parametrů Všechny parametry v následující tabulce

Tabulka 3 Popis parametrů

Název klíče

Typ klíče

Výchozí Popis hodnota (je použita v případě, že klíč neexistuje)

"Testing"

REG_DWORD

0

Zakazuje/Povoluje zasílání kopie modifikovaného emailu pro testování vzorů podpisu.

"Enabled"

REG_DWORD

0

Zakazuje/Povoluje podepisování emailů.

"LdapSubTree"

REG_DWORD

1

Zakazuje/Povoluje prohledávání AD adresáře do hloubky.

27

(LDAP)

Aplikační dokumentace Název klíče

Typ klíče

Výchozí Popis hodnota (je použita v případě, že klíč neexistuje)

"LdapContainer"

REG_SZ

""

Název kontejneru v AD, kde bude probíhat hledání objektu, např. DC=autocont,DC=cz.

"LdapUser"

REG_SZ

""

Uživatelské jméno pro přístup do AD adresáře, např. [email protected].

"LdapPassword"

REG_BINARY

""

Heslo uživatele pro přístup do AD v kryptované podobě17.

"HtmlFileName"

REG_SZ

""

Jméno souboru se vzorem html podpisu včetně plné cesty18.

"TextFileName"

REG_SZ

""

Jméno souboru se vzorem textového podpisu včetně plné cesty.

"TestEmail"

REG_SZ

""

Emailová adresa uživatele pro testování na kterou je možné doručovat kopie podepsaných emailů. Adresa může být pouze jedna.

"LogFile"

REG_SZ

""

Jméno log souboru včetně plné cesty, kde systém zapisuje události a případné chyby aplikace.

"FileLogLevel"

REG_DWORD

0

Úroveň logování do souboru v rozmezí 0-6 (0 minimální, 6 detailní)19

17

Pro získání kryptovaného hesla slouží pomocná řádková utilita dodávaná spolu s aplikací

18

Soubory jsou kódovány ve znakové sadě nastavené v operačním systému.

19

Maximální logování může degradovat výkon poštovního serveru

28

Aplikační dokumentace Název klíče

Typ klíče

Výchozí Popis hodnota (je použita v případě, že klíč neexistuje)

"EventLogLevel"

REG_DWORD

0

Úroveň logování do aplikačního event logu operačního systému v rozmezí 0-6 (0 minimální, 6 detailní).

"ConvertUSACIICharSet"

REG_DWORD

0

Povolí v případě potřeby konverzi znakové sady podepisovaného emailu

"ConvCharSet"

REG_SZ

"iso-88592"

Znakové sada použitá v případě nutnosti konverze podepisovaného emailu20

""

Seznam prefixů předmětu emailů, které budou vyloučeny z podepisování oddělené středníkem (velká malá písmena nerozhodují). Např. „RE:;FW:”

0

Sériové číslo verze konfigurace. V případě změny této položky se provede aktualizace konfigurace v paměti (pro změnu konfigurace není třeba restart SMTP serveru)

"ExcudedSubject"

"ConfigSerialNumb"

5.2.2

REG_DWORD

Příklad REG souboru

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont] [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont\MailSign] "Enabled"=dword:00000001 "LdapContainer"="DC=autocont,DC=cz" "LdapSubTree"=dword:00000001 20

Nastává v případě, že podepisovaný email je formátován ve znakové sadě US ASCII a podpis vyžaduje znaky, které tato sada neobsahuje

29

Aplikační dokumentace "LdapUser"="[email protected]" "LdapPassword"=hex:4d,2d,41,6a,62,72,43,66,61,6f,6b,61,61,2b,48,31,77,3f,33,63,64,38,61,73, 66,62,79,79,5c,3b,72,5c,61,32,95,50 "HtmlFileName"="C:\\MailSign\\data\\sign.htm" "TextFileName"="C:\\MailSign\\data\\sign.txt" "Testing"=dword:00000000 "TestEmail"="[email protected]" "EventLogLevel"=dword:00000004 "LogFile"=" C:\\MailSign\\data\\mailsign.log" "FileLogLevel"=dword:00000004 "ConvertUSACIICharSet"=dword:00000001 "ConvCharSet"="iso-8859-2" "ExcudedSubject"="FW:;RE:" "ConfigSerialNumb"=dword:00000001

5.3

UTILITA CRYPTPASSWORD

Pro zvýšení bezpečnosti není uloženo heslo uživatele pro přístup do active directory v systémovém registru jako čitelný text. Pro vygenerování zakódovaného hesla se používá řádková utilita CryptPassword.exe jež je součástí celé aplikace. Jako parametr se vkládá reálné heslo (délka hesla je omezena na 24 znaků) a výstupem je série hexadecimálních číslic oddělených čárkou, které je potřeba uložit do registru. Pro zápis do registru je možné použít reg soubor, kde se heslo vyskytuje ve stejném formátu. Zvolená šifra je reverzibilní a slouží pouze k znesnadnění přečtení hesla běžným uživatelem. Z těchto důvodů je doporučeno vytvořit pro tyto účely dedikovaný účet s omezenými oprávněními, které umožní pouze prohledávání a čtení potřebných atributů z AD.

5.4

VZORY PODPISŮ

Aplikace zpracovává dva různé soubory vzorů podpisů, jeden pro emaily ve formátu prostého textu a druhý pro emaily formátu html. Emaily ve formátu rtf (rich text format) jsou implicitně přeformátovávány do formátu html. Pro dynamické nahrazení textu dle údajů v active directory se do vzoru podpisu umístí název atributu uzavřený do dvojitých %% (například. %%company%%). Při podepisování zprávy formátu HTML je vkládána do zprávy pouze část HTML kódu. Na toto omezení je potřeba pamatovat při vytváření podpisu, na druhou stranu toto řešení umožňuje používat pro editaci vzorů podpisu běžné HTML editory. Dále není možné používat vložené obrázky, které by měli být přímo součástí zprávy. Tyto obrázky nejsou do zprávy načítány. Pro kódování souborů vzorů podpisu je nutné využít znakové sady nastavené v operačním systému. Znaková sada uvedená v hlavičce HTML se nebere v potaz. 30

Aplikační dokumentace 5.4.1

Příklad vzoru podpisu ve formátu prostý text

%%title%% %%givenName%% %%sn%% Oddělení: %%department%% Telefon: %%telephoneNumber%% %%company%% %%co%%

5.4.2

Příklad vzoru podpisu ve formátu HTML

<meta http-equiv="Content-Language" content="cs" /> <meta http-equiv="Content-Type" content="text/html; charset=windows-1250" />

%%title%% %%givenName%% %%sn%%

Oddělení: %%department%%
Telefon: %%telephoneNumber%%
%%company%%
%%co%%


5.4.3

Příklad podepsané zprávy

V následujících screen shotech je vidět jakým způsobem ovlivňuje aplikace zaslanou zprávu a doplní podpis v obou používaných formátech.

31

Aplikační dokumentace

Obrázek 12 Původní zpráva ve formátu prostý text

Obrázek 13 Podepsaná zpráva ve formátu prostý text

32

Aplikační dokumentace

Obrázek 14 podepsaná zpráva ve formátu HTML

5.4.4

Atributy Active directory(13)

V následující tabulce je výběr atributů objektu uživatel z Active Directory, které je možné použít do vzorů podpisu. Tabulka 4 Používané atributy uživatele

Jméno atributu AD Additional-Information Address-Home Assistant Comment Company Country-Name Department Description Display-Name-Printable Division E-mail-Addresses Facsimile-Telephone-Number

Význam další informace adresa domů Asistent komentář společnost Země oddělení popis jméno Divize Email Fax

33

Zástupný text do souborů vzoru podpisu %%notes%% %%homePostalAddress%% %%assistant%% %%info%% %%company%% %%c%% %%department%% %%description%% %%displayNamePrintable%% %%division%% %%mail%% %%facsimileTelephoneNumber%%

Aplikační dokumentace Jméno atributu AD Given-Name Initials International-ISDN-Number Locality-Name Organizational-Unit-Name Organization-Name Personal-Title Phone-Fax-Other Phone-Home-Other

Phone-Home-Primary

Phone-Ip-Other Phone-Ip-Primary Phone-ISDN-Primary Phone-Mobile-Other

Phone-Mobile-Primary

Phone-Office-Other

Phone-Pager-Other Phone-Pager-Primary Physical-Delivery-Office-Name

Postal-Address Postal-Code

Post-Office-Box Registered-Address State-Or-Province-Name

Význam Křestní jméno Iniciály Mezinárodní isdn číslo Lokalita Organizační jednotka Organizace Další faxové číslo Další domácí telefonní číslo Domácí telefonní číslo Další Ip telefon Ip telefon isdn číslo Další mobilní telefonní číslo Mobilní telefonní číslo Pracovní telefonní číslo Další Pager Pager Doručovací jméno společnosti Poštovní adresa Poštovní směrovací číslo Postbox Registrovaná adresa stát/kraj

34

Zástupný text do souborů vzoru podpisu %%givenName%% %%initials%% %%internationalISDNNumber%% %%l%% %%ou%% %%o%% %%personalTitle%% %%otherFacsimileTelephoneNumber%% %%otherHomePhone%%

%%homePhone%%

%%otherIpPhone%% %%ipPhone%% %%primaryInternationalISDNNumber%% %%otherMobile%%

%%mobile%%

%%otherTelephone%%

%%otherPager%% %%pager%% %%physicalDeliveryOfficeName%%

%%postalAddress%% %%postalCode%%

%%postOfficeBox%% %%registeredAddress%% %%st%%

Aplikační dokumentace Jméno atributu AD Street-Address Surname Telephone-Number Teletex-Terminal-Identifier

Telex-Number Telex-Primary Text-Country Title

5.5

Význam Ulice Příjmení Telefonní číslo Dálnopisový terminálový identifikátor Dálnopisové číslo Dálnopis Země Titul

Zástupný text do souborů vzoru podpisu %%street%% %%sn%% %%telephoneNumber%% %%teletexTerminalIdentifier%%

%%telexNumber%% %%primaryTelexNumber%% %%co%% %%title%%

LOGOVÁNÍ APLIKACE

Aplikace využívá dva typy logování. Události a chyby je možné zapisovat do textového souboru a do Aplikačního Event logu. Logování do Event logu je aktivní trvale, zápisy do textového soubor pouze v případě, že je parametr LogFile nastaven. Podrobnost obou typů logování je možné nastavit samostatně v rozmezí 0-5, kde 0 je minimální (pouze kritické chyby) a 5 detailní (debug log). Doporučuji nastavit úroveň logování do eventlogu na úroveň 2 a textový soubor použít pro podrobnější logování v případě problémů nebo testovacího provozu aplikace (velké množství zápisů do logu může zbytečně zatěžovat systém).

35

Závěr

6 Závěr 6.1

ZHODNOCENÍ SPLNĚNÍ CÍLŮ BP

Implementace MailSign ověřila správnost návrhu a jeho použitelnost pro řešení tohoto problému. Vyvinutá aplikace splňuje požadavky dané zadáním. Na základě výkonového testu byla ověřena možnost nasadit tuto aplikaci i pro poštovní systémy střední velikosti jelikož se při používání aplikace zátěž výrazně nezvýšila. Při vývoji byl kladen důraz na jednoduchost řešení a jeho nezávislost na klientských poštovních aplikacích. Práce na tomto projektu mě výrazně obohatila o znalosti z potřebných oblastí, využívání COM technologií, programování DLL knihoven.

6.2

DISKUSE DALŠÍHO MOŽNÉHO POKRAČOVÁNÍ PRÁCE

Bakalářskou práci je možné doplnit o implementaci navrhovaného administračního uživatelského rozhraní. Dále je možné rozšířit funkčnost o možnost vkládání obrázků do vzoru podpisu HTML, které v aktuální verzi nelze použít. Vzhledem k nízkým výkonovým nárokům na vlastní poštovní systém je možné nasadit tuto aplikaci i ve větších poštovních systémech, kde by pravděpodobně nestačil pouze jeden vzor podpisu pro celou organizaci. Funkčnost je možné rozšířit o možnost vytváření různých vzorů podpisu, které budou aplikovány např. podle uživatelských skupin v Active Directory. Pro zvýšení výkonnosti aplikace by v budoucnu bylo vhodné doimplementovat a povolit více vláknové zpracování, které v současné verzi není možné, i když některé části programového kódu již obsahují synchronizační prvky pro více vláknové zpracování. Další možností je doplnit implementaci o vylepšení logovací části aplikace, zápisy do eventlogu nejsou implementovány pomocí registrace Aplikace v event logu a nepoužívá Event Message File, což neumožňuje využít plnou funkčnost práce s Windows Eventlogem.

36

BIBLIOGRAFIE

1. Create the ATL Project and Set Up SMTP Event Headers. Microsoft MSDN. [Online] 4. Srpen 2004. [Citace: 6. Leden 2009.] http://msdn.microsoft.com/enus/library/ms528038(EXCHG.10).aspx. 2. Windows 2003 R2 Systémové požadavky. Web Microsoft. [Online] [Citace: 5. Leden 2009.] http://www.microsoft.com/cze/windowsserver2003/evaluation/sysreqs/default.mspx. 3. Deploying the Windows Server 2003 Forest Root Domain. Microsoft Technet. [Online] 28. Březen 2003. [Citace: 5. Leden 2009.] http://technet.microsoft.com/enus/library/cc758611.aspx. 4. How to Install IIS Prerequisites for Exchange Server 2003 on Windows Server 2003. Microsoft technet. [Online] 18. červen 2006. [Citace: 5. Leden 2009.] http://technet.microsoft.com/en-us/library/bb124295(EXCHG.65).aspx. 5. System requairements for exchange 2003. Microsoft Technet. [Online] 20. Březen 2005. [Citace: 5. Leden 2009.] http://technet.microsoft.com/cs-cz/library/cc164322(enus).aspx. 6. How to Run Exchange Server 2003 ForestPrep. Microsoft Technet. [Online] 16. Květen 2005. [Citace: 5. Leden 2009.] http://technet.microsoft.com/enus/library/bb124110(EXCHG.65).aspx. 7. How to Run Exchange Server 2003 DomainPrep. Microsoft Technet. [Online] 27. Červen 2006. [Citace: 5. Leden 2009.] http://technet.microsoft.com/enus/library/aa997526(EXCHG.65).aspx. 8. How to Install Exchange Server 2003. Microsoft Technet. [Online] 10. Květen 2005. [Citace: 5. Leden 2009.] http://technet.microsoft.com/en-us/library/bb124186(EXCHG.65).aspx. 9. Exchange Server 2003 SP2 Overview. Microsoft Technet. [Online] 12. Prosinec 2007. [Citace: 4. Leden 2009.] http://technet.microsoft.com/en-us/library/cc164305.aspx. 10. You cannot modify MAPI messages that are trapped in an SMTP transport event sink. Microsoft support. [Online] 25. Říjen 2005. [Citace: 5. Leden 2009.] http://support.microsoft.com/kb/273233/. 11. Mail Signature Manager. Web Symprex. [Online] 2008. [Citace: 6. Leden 2009.] http://www.symprex.com/products/email-signature-disclaimer-manager/. 12. Smtpreg.vbs Event Management Script. Microsoft MSDN. [Online] 10. Listopad 2005. [Citace: 5. Leden 2009.] http://msdn.microsoft.com/en-us/library/ms528023.aspx. 13. Attributes (Windows). Microsoft MSDN. [Online] 12. Duben 2008. [Citace: 5. Leden 2009.] http://msdn.microsoft.com/en-us/library/ms675089(VS.85).aspx. 14. Kačmář, Dalibor. Programujeme v COM a COM+. Praha : Computer Press, 2000. 15. Protocol Event Sink Implementation Steps. Microsoft developper network library. [Online] Microsoft Corporation, 2008. [Citace: 26. 4 2008.] http://msdn2.microsoft.com/enus/library/ms528014(EXCHG.10).aspx. 16. Wikipedia oteřená encyklopedie Nadace Wikimedia. [Online] Nadace Wikimedia, 3. 05 2002. [Citace: 25. 06 2008.] http://cs.wikipedia.org.

i

PŘÍLOHA A - OBSAH PŘILOŽÉHO CD

\Bak_prace.pdf – text bakalářské práce \BP_MailSign.vs – zdrojové kódy včetně konfigurace pro vývojové prostředí Microsoft Visual Studio 2008 Professional \MailSign – soubory potřebné pro instalaci

ii