SYSTEM FÖR LAGRING AV E-POST

Transkript

1 Examensarbete 10 poäng C-nivå SYSTEM FÖR LAGRING AV E-POST Reg.kod: Oru-Te-EXD083-D103/07 Magnus Bilock Dataingenjörsprogrammet 120 p Örebro vårterminen 2007 Examinator: Thomas Padron-McCarthy MAIL STORAGE SYSTEM Örebro universitet Institutionen för teknik Örebro Örebro University Department of Technology SE Örebro, Sweden

2 Sammanfattning Detta är en rapport över utveckling av Mail Storage System (MSS) som utvecklades hos Proplate IT i Örebro. Målet med MSS var ett system som ska kunna kopiera och lagra e-post som skickas från och till en Microsoft Exchange-server. Vilka e-brev som ska sparas bestäms genom att avsändarens och mottagarnas e-postadresser matchas mot en lista med e-postadresser. Systemet konstruerades med prestanda i åtanke, eftersom systemet annars kan påverka hela e-postservern negativt. Resultatet blev ett fullt fungerande system som använder SMTP-händelser för att notifieras när ett nytt e- postmeddelande skickas från eller till Exchange-servern. Tester av prestanda hos MSS visade att systemet fungerar tillfredsställande för servrar med få/medelstort antal e-postkonton. För servrar med ett väldigt stort antal e-postkonton bör MSS inte användas, då det skulle kunna fördröja levererandet av e-brev. Abstract This report is a documentation of the developing of Mail Storage System (MSS), which was made at Proplate IT in Örebro. The goal of developing MSS was a system to copy and store s sent to and from a Microsoft Exchange server. Which s to store is decided by comparing the sender and receivers addresses against a list of addresses. MSS was designed with performance in mind, because a slow performing system can affect the whole server in a negative way. The resulting system is a fully functioning system which uses SMTP events to be notified when a new arrives to the server or when a new is being sent from the server. Performance tests of MSS showed that the system works satisfying on servers with a few/medium number of users. Servers with a large number of accounts should not apply MSS, since it could delay the delivering of s. 1

3 Förord Jag vill speciellt tacka Mikael Bilock på Proplate IT för idén till projektet, Mattias Olgerfelt på Proplate IT för handledning hos Proplate och bollande av idéer, övriga medarbetare på andra våningen i NetCity för trevligt sällskap och gott fredagsfika, samt Jack Pencz för handledning från Örebro universitet. Örebro den 26 augusti 2007 Magnus Bilock 2

4 Innehållsförteckning 1 TERMINOLOGI INLEDNING BAKGRUND VARFÖR BEHÖVS MSS? MÅLSÄTTNING VAD SÄGER LAGEN? TEKNIKER OCH VERKTYG MICROSOFT EXCHANGE UTVECKLINGSMILJÖ PROGRAMMERINGSSPRÅK TELNET OCH SMTP GENOMFÖRANDE INSTALLATION Proplates nätverksstruktur FÖRUNDERSÖKNING CDO WebDAV.Net for Exchange Publika mappar i Exchange Exchange databashändelser SMTP händelsehanterare Windowstjänst Webbtjänst Slutsats av förundersökningen UTVECKLING AV MSS MSS SMTP-händelsehanterare MSS windowstjänst MSS Databas MSS Webbtjänst Körexempel SLUTSATS OCH DISKUSSION REFERENSER

5 1 TERMINOLOGI E-brev och e-post Det råder en viss förvirring om vad man på svenska ska kalla korrespondens genom brev över Internet. Vanligast är e-brev, e-post, mejl eller mail. I detta dokument kommer jag följa Svenska datatermgruppens rekommendation och använda e-post för tekniken, och e-brev för själva meddelandet. [1] API Ett Application Progamming Interface (API) är ett källkodsgränssnitt som leverantören av ett system kan tillhandahålla för att förenkla utveckling av system mot leverantörens produkt. Består oftast av ett antal kodbibliotek med färdiga anropningsbara metoder. SMTP Simple Mail Transfer Protocol (SMTP) är det vanligaste kommunikationsprotokollet för att skicka e- post. SDK Ett Software Developing Kit (SDK) är vanligtvis en samling utvecklingsverktyg och användarinstruktioner för att förenkla utveckling mot ett visst system. Det kan vara allt från några anropningsbara metoder till avancerad hårdvara som används för att kommunicera med ett system. Commit (I samband med databaser) Commit är ett svåröversatt ord som inom databasteknik används för att tala om att en databastransaktion har utförts eller godkänts. Det är endast efter commit som man kan vara helt säker på att en transaktion verkligen har skett. Wrapper Ett annat svåröversatt ord är wrapper, som bland annat inom datateknik används för att beskriva ett gränssnitt runt en metod som inte är kompatibelt med det programmeringsspråk som används. Genom att skriva en wrapper runt den metoden, kan man få den att fungera i ett annat språk än den ursprungligen utvecklades för. Array Array kan översättas till svenskans samling, men brukar i programmeringssammanhang aldrig översättas. En array är en datastruktur som samlar data av samma datatyp under ett gemensamt namn. De olika elementen går sedan att komma åt genom indexering. SQL SQL står för Structured Query Language och är det vanligaste språket som används för att kommunicera med relationsdatabaser. 1

6 2 Inledning Detta dokument beskriver arbetet och resultaten från utvecklingen av e-postlagringstjänsten Mail Storage System, hädanefter benämnt MSS, som utvecklades hos Proplate IT i Örebro. 2.1 Bakgrund Användandet av e-post som korrespondens har ökat lavinartat sedan Internet började slå igenom ordentligt i hem och företag på 90-talet. Hos företag som levererar en produkt eller tjänst, sker ofta en stor del av korrespondensen mellan kund och leverantör genom e-post. Uppdragsbeskrivningar, leveransbeställningar och förfrågningar om förändringar av utvecklingsarbete är exempel på korrespondens som ofta sker med hjälp av e-post mellan kund och leverantör. 2.2 Varför behövs MSS? Vad händer om en person med ansvar för ett eller flera projekt slutar hos ett av företagen i kedjan? Förmodligen kommer en ny person att tillsättas, vilket kan leda till att det går åt flera veckors arbete för den nya personen att sätta sig in i vad kunden har önskat och vad som har gjorts hittills. Samtal kommer att upptas mellan parterna, och kunden kommer säkerligen hänvisa till tidigare e-brev. Viktiga e-brev har en förmåga att försvinna i den stora mängd av e-post som kommer in varje dag, och det är lätt att radera ett e-brev som kanske inte verkar viktigt att spara i det skedet. Därför skulle det såklart underlätta för ett företag om alla viktiga e-brev som har kommit in och gått ut till kunden kan lagras på en extern plats utanför den server som tar emot och skickar e-post. Det är här som MSS kommer in i bilden. 2

7 2.3 Målsättning Målet med MSS som produkt är att utveckla ett system som ska kunna lagra e-brev som har skickats mellan kund och leverantör. MSS ska fungera som en agent som avlyssnar trafik in och ut ur en e- postserver. Se figur 2.1. För att kunna skilja på vilka e-brev som har gått ut till en kund eller leverantör och de som har skickats privat, jämförs avsändare och mottagare mot en lista med e-postadresser. Om avsändaren eller någon av mottagarna finns med i listan, så lagras e-brevet i sin helhet i en databas. Även så kallade attachments, d.v.s. medskickade filer, och e-post till fler än en mottagare ska kunna lagras. MSS ska kunna användas som ett fristående system, men även tillsammans med t.ex. ett större affärssystem där kontaktpersoner redan finns lagrade. Målgruppen för MSS är små/medelstora företag där en stor del av korrespondenser med kunder eller leverantörer sker genom e-post, och där det är viktigt att korrespondensen kan lagras för framtida bruk. Målen med MSS ur utvecklingssynpunkt är att utveckla ett system där de olika komponenterna är löst kopplade till varandra. Det ska vara så enkelt som möjligt att byta databas, byta lagringsserver eller att utveckla ytterligare en komponent till MSS. Det ska dessutom vara så bekvämt som möjligt att vidareutveckla MSS för att fungera mot någon annan e-postserver eller flera olika e-postservrar. Figur 2.1 Konceptskiss för MSS. MSS avlyssnar trafiken mellan Internet och servern. 3

8 2.4 Vad säger lagen? Vad säger lagen om att kopiera e-brev som kommer till en e-postserver och lagra dem på annan plats? För att reda ut det hela så kontaktade jag Datainspektionen, beskrev tanken med MSS och bad om vägledning. Jag fick då följande svar från Datainspektionens jurist Jens Västberg: Ett e-postmeddelande är en personuppgift enligt definitionen i personuppgiftslagen (3 PuL) varför denna lag är tillämplig på behandling av e-postmeddelanden (5 1 st. PuL) Som huvudregel skall den personuppgiftsansvarige alltid självmant lämna information till den registrerade om behandlingen av uppgifterna (23 24 PuL). Han avslutar med ett personligt utlåtande: Det förefaller mycket tveksamt om denna behandling är tillåten utan de registrerades samtycke. Att genomföra behandlingen utan de registrerades vetskap är inte tillåtet. Lagen säger med andra ord att det inte är okej att lagra e-post externt om inte avsändaren och mottagaren har vetskap eller eventuellt gett sitt samtycke till att så ska ske. Detta är relativt enkelt att uppnå med MSS, eftersom de berörda e-postadresserna måste finnas lagrade, och det är då lätt att automatiskt skicka ett e-brev till de e-postadresser som ska läggas till i listan, och be om samtycke. 4

9 3 Tekniker och verktyg Eftersom Proplate IT arbetar nästan uteslutande i Windows och.net-miljö, så kom jag tillsammans med min handledare överens om att MSS skulle utvecklas i C#. Som testserver installerades en Windows Server 2003 med Microsoft Exchange 2003 som e-postserver. Eftersom servern installerades lokalt, enligt beskrivningen i avsnitt 4.1, så användes TELNET för att simulera att e-post kom utifrån. 3.1 Microsoft Exchange 2003 Microsoft Exchange 2003 är en plattform för samverkan mellan olika tekniker för att förenkla kommunikation mellan människor. Det är ett serverprogram, och används främst som e-postserver. Det finns även funktioner som kalender, kontakthantering och inbyggd webbåtkomst. Eftersom Exchange är ett serverprogram, så krävs det någon form av klient för att kommunicera med Exchange. Den vanligaste klienten i Windowsmiljö är Microsoft Outlook, som är speciellt konstruerad för att utnyttja alla funktioner i Exchange. Exchange 2003 har även inbyggd webbåtkomst, så det går att komma åt sitt e-postkonto genom att använda en vanlig webbläsare. All data som sparas på Exchangeservern lagras i en databas som programmet är uppbyggt kring. Microsoft Exchange används främst av företag som byggt sin arkitektur kring Microsofts produkter, eftersom alla versioner av Exchange från och med Exchange 2000 är konstruerade för att använda Windows Server Active Directory som katalogstruktur och användarkontroller. Det i sin tur innebär att Windows 2000 eller nyare måste användas som grund, eftersom det var där som Active Directory först implementerades. Ett Active Directory kan kort beskrivas som en katalogtjänst som används för att lagra information om nätverksresurser över en domän. [2] En användare i en domän får sitt användarnamn, rättigheter och eventuellt e-postadress tilldelad av en administratör, och på så sätt kan man kontrollera vilka resurser som är åtkomliga av en viss användargrupp. Exchange är även starkt integrerat mot Microsoft Internet Information Service (IIS), eftersom Exchange använder de virtuella servrarna som IIS tillhandahåller för att kommunicera med andra servrar. Microsoft Exchange släpptes som beta för första gången 1995 och har sedan dess kommit ut i flera olika förbättrade versioner. En milstolpe i utvecklingen var Exchange 5.5 som var den första versionen att stödja Internetsupport, tidigare versioner fungerar endast i interna nätverk. [3] 3.2 Utvecklingsmiljö Som utvecklingsmiljö användes Microsoft Visual Studio Visual Studio 2005 är Microsofts stora utvecklingsmiljö som har stöd för flera olika språk och tekniker. Det går bland annat att utveckla fönsterapplikationer, windowstjänster, webbsidor och webbtjänster med hjälp av Visual Studio. Visual Studio 2005 stöder flera olika programmeringsspråk, som alla kompileras till samma maskinkod. Några av de språk som Visual Studio 2005 stödjer är C, C++, C#, Visual Basic och Visual Basic.NET. För att kunna köra ett program utvecklat i Visual Studio 2005 med de senaste kodbiblioteken, krävs att måldatorn har.net framework 2.0 installerat. Databasen konstruerades och administrerades i Microsoft SQL Server 2005, som är Microsofts stora relationsdatabashanterare. Den använder en variant av SQL-92-standarden, med namnet Transact- SQL, som innehåller en del förbättrade funktioner för bland annat utveckling av lagrade procedurer. 5

10 3.3 Programmeringsspråk Som programmeringsspråk valdes C#, som Visual Studio 2005 stödjer. C# utannonserades av Microsoft år 2000 tillsammans med.net-plattformen, och har sedan dess vuxit mer och mer. C# är objektorienterad och kan användas för att utveckla både Windowsapplikationer och webbapplikationer, då i kombination med ASP.NET. Fördelarna med C# är bland annat att det är enklare att utveckla program i än till exempel C++, eftersom man slipper bry sig om lågnivåproblem som minneshantering och pekare om man inte absolut vill. Det finns även garbage collector och mängder av färdiga programmeringsbibliotek som ytterligare förenklar för utvecklaren. Största nackdelen med C#.NET är att det bara är tänkt att ha stöd för utveckling mot Windows, vilket innebär att andra operativsystem inte kan köra program som är utvecklade i C#.NET. Det pågår dock utveckling av verktyg för att kunna köra program utvecklade i C#.NET på andra operativsystem, till exempel Linux, Unix och MacOS. [6] 3.4 TELNET och SMTP För att kunna simulera en verklig arbetsmiljö användes TELNET för att skicka e-post genom testservern. TELNET är ett nätverksprotokoll som finns tillgängligt för de allra flesta operativsystem, och kan användas för att kommunicera med en server över ett lokalt nät eller över Internet. TELNET är textbaserat och användes i det här projektet för att kontakta Exchange-servern och skicka e-post med SMTP-kommandon. Figur 3.1 visar exempel på ett e-brev som skickas med hjälp av TELNET. Först kopplar man upp mot den server som ska kontaktas och anger port för kommunikationen. Exchange arbetar med port 25. Därför använder jag den porten för kommunikation när jag kopplar upp mig med TELNET. När kommunikationen är upprättat, kan man börja skicka SMTP-kommandon. En serie av SMTP-kommandon börjar alltid med ett artigt HELO 1, eller den nyare formen EHLO, som lite finurligt står för Extended HELO. Servern ska då, som brukligt när man blir tilltalad, svara med en egen hälsningsfras. När den formaliteten är avklarad, anger man avsändare av e-brevet med mail from: användarnamn@domän.ext. Det går bara att ange en avsändare. En eller flera mottagare av e- brevet ska sedan anges med rcpt to: användarnamn@domän.ext. När det är avklarat, anger man det data man ska skicka genom att skriva kommandot data. Där skriver man vad själva e-brevet ska innehålla, och avslutar genom att trycka Enter, följt av en punkt och sedan Enter igen. E-brevet skickas då förhoppningsvis till alla de mottagare man har angett. 1 HELO betyder egentligen HELLO, men SMTP-kommandon består generellt av fyra bokstäver 6

11 Figur 3.1 Exempel på användning av TELNET för att skicka e-post. 4 Genomförande Examensarbetet delades in i tre delar. Först skulle Windows Server 2003 och Microsoft Exchange 2003 installeras, och eftersom jag inte tidigare har arbetat med vare sig Windows Server eller Exchange, så var jag tvungen att bekanta mig med miljön. Andra delen var en förundersökning för att hitta information om vad som är möjligt att göra med Exchange, och vad som är omöjligt. Går det ens att utföra det som är tanken med MSS? Hur kan MSS realiseras? Vad passar bäst för utvecklingen av MSS? Vad finns det för tekniker för att programmeringsmässigt arbeta med Microsoft Exchange? Vilka hjälpbibliotek och API: er finns det? Till sist så användes den kunskap jag fått av förundersökningen för att utveckla en färdig produkt. 4.1 Installation För att ha en server att arbeta mot och testa mina lösningar mot, installerades Windows Server 2003 och Microsoft Exchange 2003 på en dator hos Proplate. Proplate hade redan en existerande domän och ett fungerande Active directory, så servern konfigurerades för att använda samma domän. Domänen som användes heter bsab.s1, därför fick e-postlådorna på min server Om servern skulle konfigureras för att fungera som en publik server mot Internet, så går det att lägga till flera domänadresser utan att ändra windowsdomän. När installation var klar och användare hade skapats, testades e-postlådorna genom att jag kopplade upp mot servern och skickade e-post med hjälp av TELNET. 7

12 4.1.1 Proplates nätverksstruktur Proplate IT i Örebro har två ip-adresser in till kontoret. En används av de anställda för att surfa och den andra är upptagen av en server. Det innebar att min testserver under utvecklingen installerades internt, och kunde alltså inte nås utanför kontoret. Nätverkstrukturen visas i figur 4.1. En klientdator användes för att testa och utveckla mot servern. När utvecklingsarbetet var färdigt fick jag dock möjlighet att testa systemet mot Internet för att kunna testa prestanda, se avsnitt Figur 4.1 Proplates nätverksstruktur 8

13 4.2 Förundersökning Målet med förundersökningen var att finna information om de tekniker som finns för att kommunicera med Exchange programmeringsmässigt. När man väl vet vilka tekniker som finns, är det enklare att göra en mer exakt skiss över hur systemet kan fungera och se ut. Förundersökningen inledes med febrilt sökande efter information om vilka möjligheter det finns att utveckla program i C#.Net, som ska samarbeta med Exchange. Det fanns relativt gott om information att hitta i böcker, på Internet och Exchanges egen manual för utvecklare, Exchange SDK. Dock var det mycket fackspråk och förkortningar som det tog ett tag att reda ut. En teknik som absolut måste finnas med, är en metod att bli notifierad när nya e-brev har kommit in till servern. Det skulle gå att göra ett system som går igenom alla e-postlådor på servern med ett visst tidsintervall, men då skulle användarna kunnat ha hunnit radera sina e-brev mellan körningsintervallen. I avsnitt redogörs för de olika teknikerna jag hittade för att arbeta mot Exchange och vilka fördelar och nackdelar varje teknik innebär. I avsnitt redogörs för windowstjänst och webbtjänst. Slutsatsen av förundersökningen presenteras i avsnitt CDO CDO är förkortningen för Collaboration Data Objects som är ett programmeringsbibliotek utvecklat av Microsoft för att förenkla programmering mot bland annat Exchange och utbyte av data med Exchange. CDO släpptes först tillsammans med Exchange 5.5. Anledningen var att utvecklare hade efterfrågat ett bibliotek som stöder alla de funktioner som Exchange erbjuder, så som åtkomst av kalender, publika mappar och användarprofiler. Tidigare skedde all utveckling mot Exchange med Active Messaging-biblioteket, som främst kan användas får att komma åt och skicka e-post. CDO har primärt två användningsområden. Det första är för utvecklare som vill utveckla en e-postklient för att hämta och utbyta information med servern. Till exempel så har CDO används för att utveckla den webbklient som används av Exchange. [4] Det andra användningsområdet är för serverutvecklare som vill kunna komma åt och ändra innehållet i objekt som kommer in eller tas bort ur Exchange databasen. Exempel på detta kan vara e-post som har kommer in eller kalendernoteringar som registrerats. CDO biblioteket finns tillgängligt för de flesta av de moderna objektorienterade programmeringsspråken, så som C#, C++ och Java. Den senaste versionen av Exchange som har släppts, Exchange 2007, tillhandahåller webbtjänster för åtkomst av transportköer och e-post. Detta innebär att CDO har spelat ut sin roll ur utvecklingssynpunkt för nyare system. Exchange 2007 stödjer fortfarande CDO, men rekommendationen är att använda webbtjänsterna om ett system utvecklas specifikt mot Exchange Det är dock bättre att utveckla med hjälp av CDO om man vill att systemet ska vara bakåtkompatibelt med tidigare versioner av Exchange, ner till version 5.5. [5] En nackdel med CDO är att det utvecklade programmet som använder CDO för att kommunicera med en Exchange-server, måste vara installerat på samma dator som servern för att kommunikationen ska fungera. 9

14 4.2.2 WebDAV.Net for Exchange WebDAV är en förkortning av Web-based Distributed Authoring and Versioning, och är ett protokoll som utökar http med funktioner för att skicka kommandon för att öppna, ändra, söka eller ta bort filer. WebDAV.Net for Exchange är i sin tur ett API för C#, utvecklat av Independentsoft, som använder WebDAV för att låta användaren söka, skapa, hämta och sända data till eller från en Exchange-server. Genom att använda WebDAV for Exchange så behöver man som utvecklare inte bry sig om hur man bygger upp sina anrop med WebDAV-protokollet. Man slipper med andra ord uppfinna hjulet igen, utan kan enkelt och smidigt arbeta i C# med färdiga metoder. Fördelen med att använda WebDAV.Net for Exchange istället för CDO är att WebDAV är webb-baserat, och det går således att konstruera program som kan jobba mot Exchange utan att programmen behöver ligga på samma server Publika mappar i Exchange 2003 En publik mapp kan skapas på en Exchange-server för att göra information tillgänglig för flera av användarna i ett Active Directory. Mappen kan användas för att lagra meddelanden, filer, kalendrar eller kontaktlistor, och åtkomst styrs genom att sätta rättigheter med hjälp av de användargrupper som finns i ett Active Directory. När en användare har tilldelats rättighet till en publik mapp, så har den användaren åtkomst till allt som finns i den. Det går att skapa flera olika publika mappar med olika åtkomstinställningar Exchange databashändelser Databasen i Microsoft Exchange 2003 tillhandahåller tjänster för att registrera händelsehanterare. En händelsehanterare kan beskrivas som ett program som fångar upp och startar när vissa händelser sker. Det är sedan upp till programmeraren att bestämma vad som ska ske när en viss händelse sker. Man kan likna det vid en larmcentral som ett tjuvlarm är kopplat till. När larmet går då notifieras larmcentralen, och det är sedan upp till personalen att kontrollera om det var ett brandlarm eller tjuvlarm och efter det vidta lämpliga åtgärder. På liknande sätt så kan man koppla en metod till Exchange, som körs varje gång en viss händelse sker i databasen. I fallet med Exchange finns det flera olika händelser man kan monitorera. De kan delas in i tre kategorier: asynkrona, synkrona och systemhändelser. Systemhändelserna utlöses bara när Exchange startar eller stänger ner, och är därför inte intressanta i detta sammanhang Asynkrona händelser Exchange 2003 stödjer två typer av asynkrona händelser, OnSave och OnDelete. OnSave utlöses när någonting har sparas i databasen, exempelvis ett e-brev. OnDelete utlöses i sin tur när någonting har tagits bort. De asynkrona händelserna utlöses efter att en transaktion har blivit commitad i Exchangedatabasen. Ändringen har alltså redan blivit gjord, och det går därför inte att påverka objektet innan det sparas eller tas bort, utan kan mest användas för att meddela användaren när ett e- brev har sparats eller tagits bort. Den stora fördelen med asynkrona händelser är att händelsehanteraren kan arbeta med flera asynkrona händelser i taget, och servern blir inte låst vid att bara kunna hantera en sak. Nackdelarna med asynkrona händelser är att man aldrig kan vara säker på i vilken ordning som de olika händelserna kommer utlösas, och det går dessutom bara att registrera en asynkron händelsehanterare på enskilda e-postlådor, inte för att avlyssna all trafik som går in till servern eller ut från servern. 10

15 Synkrona händelser Det finns två typer av synkrona händelser som stöds av Exchanges databas: OnSyncSave och OnSyncDelete. De skiljer sig ganska markant från de asynkrona händelserna med liknande namn. De synkrona händelserna utlöses innan data sparas i Exchange-databasen, istället för efter att data har sparats. Detta innebär att det är praktiskt att använda synkrona händelser i program som ska kunna stoppa e-brev från att sparas, som till exempel ett spamfilter. Det är även en bra teknik att använda om man vill lägga till en viss text i varje e-brev som skickas, eller om man väl ändra någonting i rubriken. En fördel gentemot asynkrona händelser är att synkrona händelser alltid utlöses i den ordning de sker i Exchange-databasen. Nackdelen med en synkron lösning är att händelsestyrningen blir låst på det objekt som har utlöst händelsen och det kan påverka prestanda på servern mycket negativt. Om man som utvecklare är slarvig och skriver kod som tar lång tid att köra, så kan man låsa servern flera sekunder varje gång som e-post kommer in till servern. Händelsehanterare som lyssnar efter synkrona händelser kan, till skillnad från händelsehanterare som lyssnar efter asynkrona händelser, registreras både på enskilda e-postlådor och över hela Exchange-databasen. Dock går det bara att registrera händelsehanterare för inkommande e-post, inte för utgående SMTP händelsehanterare Inbyggt i Microsoft Internet Information Services (IIS) finns en SMTP-tjänst. Exchange använder den tjänsten för att kunna kommunicera över SMTP, så därför kan man förutom Exchanges inbyggda databashändelser även utnyttja de händelser som IIS erbjuder. SMTP tjänsten erbjuder två typer av händelsetyper: protokollhändelser och transporthändelser. Protokollhändelser utlöses av SMTPkommunikationen mellan klient och server genom att lyssna efter de kommandon som ingår i protokollet. De utlöses alltså av ett visst protokollkommando ur SMTP-protokollet, exempelvis mail from:. Transporthändelserna sker när e-post går genom transportsystemet i SMTP tjänsten, oavsett om det är inkommande eller utgående e-post. Ursprungligen var de händelser som utlöses av SMTP endast tillgängliga genom att man skrev en COM-applikation i Microsoft Visual C++. Dessa är krångliga och svåra att skriva, så Microsoft har även utvecklat en CDO-wrapper till händelsen OnArrival. CDO_OnArrival är en CDOimplementation av transporthändelsen OnArrival, och innebär att man kan utveckla en händelsehanterare i.net-miljö för denna. OnArrival-händelsen utlöses varje gång som SMTPprotokollet används av IIS, det vill säga varje gång som e-post skickas ut eller in till en Exchangeserver. Hanteringen av OnArrival-händelser sker synkront, vilket innebär samma fördelar och nackdelar som för Exchange-databasens synkrona händelser. De stora och viktiga skillnaderna är att en OnArrival händelse bara utlöses av e-post, de går att registrera över hela databasen, det utlöses både av inkommande och utgående e-brev samt att händelsehanteraren går att utveckla i C#. När händelsen har utlösts, då har programmeraren tillgång till det e-brev som har utlöst händelsen i form av ett CDO.Imessage-gränssnitt. IMessage innehåller allt om e-brevet som är av intresse för programmeraren. Avsändare, mottagare, rubrik, textinnehåll, bifogade filer och datum är några av de användbara attribut som finns tillgängliga. 11

16 4.2.6 Windowstjänst En windowstjänst är ett program som körs i bakgrunden av Windows, utan ett synligt gränssnitt mot användaren. Man kan välja att starta windowstjänsten manuellt efter att Windows har startats, eller automatiskt i samband med att Windows startar. Tjänsten körs sedan så länge som Windows är igång, eller tills användaren väljer att avbryta tjänsten. Utvecklingen av en windowstjänst görs ofta och enklast i Visual Studio med valfritt språk, eftersom Visual Studio har många hjälpmedel för att skapa och köra en windowstjänst. En windowstjänst passar utmärkt till ett program som inte kräver någon respons eller inmatning från användaren. Figur 4.2 Windows verktyg för att hantera windowstjänster Webbtjänst En webbtjänst är ett program som fungerar som gränssnitt mellan en applikation och ett nätverk, i vanliga fall Internet. Webbtjänsten använder sig av HTML och XML för att kommunicera, och eftersom det är ett plattformsoberoende protokoll, så är webbtjänster en mycket flexibel metod att utbyta data. Språket som används kallas Web Services Description Language (WSDL) och är uppbyggt av XML-taggar. Det är relativt svårt och krångligt att skriva en webbtjänst för hand, eftersom alla kommandon skickas som taggar. Det finns därför flera olika hjälpmedel för att utveckla webbtjänster, bland annat så tillhandahåller Visual Studio 2005 färdiga mallar för utveckling av webbtjänster. Fördelarna med att använda webbtjänster är att de är plattformsoberoende och ett enkelt sätt att komma åt sin applikation från Internet. 12

17 4.2.8 Slutsats av förundersökningen För mitt system, där varje ingående och utgående e-postmeddelande ska lagras, är det bäst att utveckla en SMTP-händelsehanterare för att notifieras när e-post kommer in eller ut, eftersom den går att applicera både på ingående och utgående e-post. CDO wrappern runt OnArrival-händelsen möjliggör utveckling av händelsehanteraren i det språk jag vill använda, i detta fall C#. Eftersom hanteringen av OnArrival sker synkront, är det viktigt att jag utvecklar händelsehanteraren med hänsyn till prestanda och gör ordentliga tester så att prestanda på servern inte blir lidande. När händelsen har utlösts är det smidigast att använda WebDAV for Exchange för att lagra e-brevet i en publik mapp, som går att nå genom att specificera en användarinloggning som har tillgång till den mappen. När e-breven väl är sparade i den publika mappen, då kommer en windowstjänst att gå igenom alla e-brev enligt ett konfigurerbart tidsintervall och matcha avsändaren och mottagarna till varje e-brev mot en lista med e- post adresser. Om en eller flera e-postadresser matchar, så adderas hela e-brevet till en array, som skickas till en webbtjänst för vidare behandling. Webbtjänsten bidrar till att göra systemet mer abstrakt och förenklar utveckling av ytterligare funktionalitet till MSS. Webbtjänsten har hand om all kommunikation med en databas, som används för att spara all e-post som skickas från windowstjänsten. 13