Praca dyplomowa magisterska Marcin Goliszewski Protokół ...staff.elka.pw.edu.pl/~mgolisze/papers/XMXP_-_M...Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych

Politechnika WarszawskaWydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

Rok akademicki 2007/2008

Praca dyplomowa magisterska

Marcin Goliszewski

Protokół wymiany poczty elektronicznej –EXTENSIBLE MAIL EXCHANGE PROTOCOL

Opiekun pracy:dr inz. Grzegorz Blinowski

Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Podpis Przewodniczacego

Komisji Egzaminu Dyplomowego

Specjalnosc: Informatyka –Inzynieria systemów informatycznych

Data urodzenia: 29 pazdziernika 1984 r.

Data rozpoczecia studiów: 1 pazdziernika 2003 r.

Zyciorys

Nazywam sie Marcin Goliszewski. Urodziłem sie 29. pazdziernika 1984 roku w War-szawie. W 1999 r. ukonczyłem Szkołe Podstawowa nr 271 im. 11 Listopada w Warszawie.W 2003 r. ukonczyłem VI Liceum Ogólnokształcace im. Tadeusza Reytana w Warszawie iotrzymałem swiadectwo dojrzałosci. W pazdzierniku tego samego roku rozpoczałem naukena Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Niezaleznieod toku studiów angazuje sie w projekty zwiazane z obranym przeze mnie kierunkiem – wtym równiez w prace zawodowa w branzy informatycznej.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

podpis studenta

Egzamin dyplomowy

Złozył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Streszczenie

Praca ta prezentuje protokoły wykorzystywane w transporcie poczty elektronicznej (z naciskiemna SMTP jako najpopularniejszym z nich) oraz problemy z nimi zwiazane. Oprócz analizy istnie-jacych problemów oraz stosowanych obecnie rozwiazan, zaproponowana zostaje równiez metoda nawyeliminowanie niedogodnosci zwiazanych z przesyłaniem poczty elektronicznej: nowo zaprojekto-wany EXTENSIBLE MAIL EXCHANGE PROTOCOL. Przedstawione zostaje uzasadnienie stworze-nia nowego protokołu, jego załozenia, wyspecyfikowana zostaje jego postac, a takze prezentowana jestimplementacja proof-of-concept.

Słowa kluczowe: poczta elektroniczna, e-mail, SMTP, X.400, XMXP, adresowanie, wyznaczaniemarszruty wiadomosci.

Abstract

This thesis describes protocols used for e-mail transport (concentrating mainly on SMTP as themost popular one) and problems related to them. Apart from the analysis of existing problems andcurrently used solutions, a method to eliminate all the inconveniences related to e-mail transport isproposed: the newly designed EXTENSIBLE MAIL EXCHANGE PROTOCOL. A rationale for creatingthe new protocol is given, its basic assumptions are described, its form is specified and a proof-of-concept implementation is presented.

Key words: e-mail, SMTP, X.400, XMXP, addressing, message routing.

Spis tresci

Wprowadzenie ii

1. Historia poczty elektronicznej 1

2. Obecna sytuacja na rynku poczty elektronicznej 8

2.1. Stosowane protokoły wymiany poczty elektronicznej . . . . . . . . . . . . . . 9

2.2. Znane problemy zwiazane z transportem poczty elektronicznej . . . . . . . . 20

2.3. Sposoby rozwiazywania przedstawionych problemów . . . . . . . . . . . . . 26

3. EXTENSIBLE MAIL EXCHANGE PROTOCOL 33

3.1. Uzasadnienie opracowania XMXP . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2. Załozenia projektowe XMXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3. Opis protokołu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4. Implementacja proof-of-concept XMXP 54

4.1. Srodowisko implementacyjno-uruchomieniowe . . . . . . . . . . . . . . . . . 56

4.2. Zastosowane biblioteki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3. Opis uruchomieniowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4. Szczegóły implementacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5. Przeprowadzone testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5. Perspektywy rozwoju XMXP 84

Podsumowanie 87

A. Przykładowe pliki konfiguracyjne 90

Bibliografia 94

i

Wprowadzenie

Praca ta prezentuje róznorodne zagadnienia dotyczace transportu poczty elektronicznej,analizuje je, a takze przedstawia innowacyjne pomysły na modernizacje, które uwazam zakonieczne, aby zapewnic dalsza uzytecznosc poczty elektronicznej we współczesnych re-aliach. Główny nacisk połozony w niej został na problemy, które pojawiaja sie podczas wy-korzystywania protokołów transportu poczty elektronicznej w takiej formie, w jakiej oneobecnie istnieja. Problemy te zostaja przedstawione, a takze zostaje przeanalizowany ichwpływ na rynek usług zwiazanych z poczta elektroniczna. Ponadto przedstawiony zostajerówniez przeglad współczesnie stosowanych sposobów rozwiazywania, obchodzenia i uni-kania tych problemów. Wreszcie zaprezentowana zostaje propozycja nowatorskiego sposo-bu na całkowite sie ich wyzbycie – nowy protokół transportu poczty elektronicznej nazwanyEXTENSIBLE MAIL EXCHANGE PROTOCOL (w skrócie XMXP, czyt. emep).

W rozdziale 1. zaprezentowana zostaje pokrótce historia poczty elektronicznej. Opisanesa metody uzywane do jej transportu od powstania tego sposobu wymiany wiadomosci azpo dzien dzisiejszy. Wymienione zostaja najwazniejsze protokoły stworzone z mysla o trans-porcie poczty elektronicznej (takie, jak np. SMTP czy X.400) oraz przedstawiona zostaje rola,jaka odegrały w rozwoju poczty elektronicznej oraz jej wymiany w sieci Internet. Przywo-łane takze zostana główne standardy zwiazane z poczta elektroniczna oraz instytucje, któreodegrały najwazniejsza role w ich tworzeniu.

Rozdział 2. przedstawia obecna sytuacje na rynku wymiany poczty elektronicznej. Opi-sane zostaje wykorzystanie poczty elektronicznej obecnie, a takze narzedzia, które sa sto-sowane w tym procesie. Zaprezentowane zostaja równiez załozenia, na których oparte sawymienione w rozdziale 1. protokoły. Najwazniejsza czesc tego rozdziału stanowi analizaproblemów, które wiaza sie współczesnie z transportem poczty elektronicznej. Opisany zo-staje równiez ich wpływ na mozliwosci oraz zakres zastosowan poczty elektronicznej wewspółczesnej komunikacji elektronicznej. Przedstawione zostaja równiez stosowane obec-nie oraz postulowane rozwiazania tych problemów wraz z analiza sposobu, w jaki zmienia-ja one sytuacje na rynku poczty elektronicznej.

Nastepnie w rozdziale 3. zaproponowane zostaje nowe podejscie do rozwiazywa-nia problemów zwiazanych z transportem poczty elektronicznej – przedstawiony zostajeEXTENSIBLE MAIL EXCHANGE PROTOCOL. Podane jest uzasadnienie stworzenia nowegoprotokołu wymiany poczty elektronicznej oraz konsekwencje takiego wyboru dla istnieja-cego rynku. Nastepnie opisane zostaja załozenia projektowe, które przyswiecały tworzeniuXMXP, szczegółowe uzasadnienia dla nich, a takze sposób, w jaki wpisuja sie one w ist-niejace problemy poczty elektronicznej. Zaprezentowany zostaje równiez kształt protokołu,postac sesji wymiany wiadomosci itp.

ii

WPROWADZENIE

Praktyczna czesc tworzenia XMXP zostaje opisana w rozdziale 4., który stanowi opisimplementacji proof-of-concept XMXP. Znajduje sie w nim opis srodowiska, w którym ta im-plementacja powstawała, a takze srodowiska uruchomieniowego niezbednego do korzysta-nia z poszczególnych jej elementów. Wymienione zostaja tutaj takze biblioteki wykorzysta-ne podczas tworzenia tej aplikacji, wraz z opisem roli, jaka kazda z nich spełnia, a takzekrótka prezentacja mozliwosci jej dalszych zastosowan przy rozwoju niniejszej implemen-tacji XMXP. Podany zostaje równiez pełny opis uruchomieniowy dla obu składowych oma-wianej implementacji: serwera XMXP oraz klienta tego protokołu. Zaprezentowana zostajetakze programistyczna strona implementacji – podział na moduły funkcjonalne oraz opisnajwazniejszych klas składajacych sie na kazdy z nich. Przedstawione zostaja równiez testy,które zostały przeprowadzone przy pomocy tej implementacji XMXP wraz z ich wynikamioraz wnioskami, które podczas opisywanych testów zostały wyciagniete.

Istotna czescia niniejszej pracy jest rozdział 5., w którym znalezc mozna analize moz-liwych kierunków rozwoju dla EXTENSIBLE MAIL EXCHANGE PROTOCOL. Przedstawionezostaja w tym rozdziale zarówno mozliwosci rozszerzania XMXP o nowe funkcje, którepotencjalnie moga zwiekszac jego uzytecznosc, rozszerzac pole jego potencjalnych zastoso-wan, zwiekszac mozliwosci czy tez sprawic, iz przyjete załozenia funkcjonalne beda reali-zowane lepiej, bardziej optymalnie, bardziej uniwersalnie itp. Opisane zostaja w nim rów-niez kierunki dalszego testowania XMXP (oraz niniejszej jego implementacji), które mogadac obiecujace wyniki, szczególnie w powiazaniu z zaproponowanymi kierunkami dalsze-go rozwoju tego protokołu. Wskazane w tym rozdziale zostaja równiez konieczne kierunkirozwoju dla przedstawionej implementacji proof-of-concept XMXP, które moga tej implemen-tacji zapewnic bardziej optymalne działanie czy tez zwiekszyc pole jej zastosowan.

Ostatni rozdział pracy poswiecony jest podsumowaniu przedstawionych wczesniej kon-cepcji, zebraniu najwazniejszych mysli i głównych przedstawionych pomysłów dotycza-cych rozwiazania współczesnych problemów zwiazanych z transportem poczty elektronicz-nej poprzez zastapienie wykorzystywanych obecnie protokołów przez EXTENSIBLE MAIL

EXCHANGE PROTOCOL.

iii

Rozdział 1.

Historia poczty elektronicznej

Poczta elektroniczna jest jednym z wazniejszych narzedzi współczesnej komunikacji mie-dzy uzytkownikami komputerów, głównie miedzy korzystajacymi z sieci Internet oraz sieciwewnetrznych róznych firm, organizacji, instytucji. We współczesnym swiecie istnienie iuzywanie poczty elektronicznej jest tak naturalne, ze stała sie ona czescia codziennego zy-cia wielu ludzi. Niewiele osób zastanawia sie nad jej historia, gdyz nie sadza, ze moze onabyc do czegokolwiek przydatna. Jest to zupełnie naturalne z punktu widzenia tzw. „zwy-kłego uzytkownika”. Jednakze moim zdaniem, poznanie sposobu, w jaki przebiegał rozwójpoczty elektronicznej, a takze protokołów jej wymiany, jest bardzo istotny z punktu wi-dzenia oceny jej współczesnego stanu, oceny współczesnej sytuacji na swiatowym rynkupocztowym, a takze zastanowienia sie nad przyszłoscia tego rynku i kierunkami rozwojuprotokołów z nim zwiazanych.

Historia poczty elektronicznej rozpoczyna sie o wiele wczesniej, niz termin ten zostałstworzony. Pierwszym krokiem do wymiany wiadomosci miedzy uzytkownikami syste-mu komputerowego było powstanie systemów z podziałem czasu. Ich narodziny datujesie na poczatek lat 60. XX. wieku. Umozliwiły one wykonywanie wiecej niz jednego pro-gramu jednoczesnie. Mozliwosc ta pozwoliła na poczynienie kolejnego kroku w rozwojusystemów komputerowych – stworzenie systemu wielodostepnego, na którym wielu uzyt-kowników mogło pracowac jednoczesnie. Systemem, który odegrał istotna role w rozwo-ju komunikacji elektronicznej, był Compatible Time-Sharing System oddany do uzytku w1961 r. [1] w Massachusetts Institute of Technology. System ten został stworzony w oparciuo komputer typu mainframe 7094 firmy IBM z mysla o zdalnym dostepie uzytkowników zterminali podłaczanych za posrednictwem m.in. sieci telefonicznej. Jedna z głównych usługudostepnianych przez CTSS była mozliwosc zapisywania i odczytywania plików przecho-wywanych na dysku serwera. Uzytkownicy szybko zaczeli mozliwosc ta wykorzystywac wsposób odmienny niz załozyli sobie administratorzy serwera – oprócz współdzielenia pli-ków projektów, nad którymi wspólnie pracowali, zaczeli w katalogach grup projektowychzostawiac sobie wiadomosci. Były one prostymi plikami tekstowymi, w których wpisanabyła tresc wiadomosci. Prymitywne „adresowanie” zrealizowane zostało przez nadawanieplikom wiadomosci znaczacych nazw, np. TO TOM.

1

ROZDZIAŁ 1. HISTORIA POCZTY ELEKTRONICZNEJ

Obserwujac ten trend, administratorzy CTSS postanowili stworzyc narzedzie, które uła-twiałoby komunikacje miedzy uzytkownikami, a takze umozliwiłoby proste wysyłanie wia-domosci od administratorów do szerszej grupy uzytkowników. Na przełomie lat 1964/1965powstała notatka słuzbowa dotyczaca narzedzia MAIL, które miało powyzsze zadania re-alizowac. Poczatkowo były problemy ze znalezieniem osoby chetnej do implementacji za-proponowanego narzedzia, gdyz zespół rozwijajacy CTSS miał pewne watpliwosci co dojego uzytecznosci. Jednak w połowie 1965 r. implementacji podjeli sie Tom Van Vleck i No-el Morris. Stworzone przez nich narzedzie pozwalało dowolnemu uzytkownikowi CTSSwysłac wiadomosc do dowolnego innego uzytkownika, pod warunkiem znania symboluprojektu oraz numeru uzytkownika adresata. Istniała równiez mozliwosc wysłania wiado-mosci do wszystkich członków projektu, a takze administratorzy mieli mozliwosc wysłaniawiadomosci do wszystkich uzytkowników systemu. Wiadomosci wysłane komenda MAILdostarczane były w bardzo prosty sposób – dopisywane były do pliku MAIL BOX w katalo-gu domowym adresata, skad mógł on je odczytac przy pomocy edytora tekstowego.

Podobnych do istniejacego w MIT CTSS systemów lokalnej wymiany wiadomosci mie-dzy uzytkownikami jednego systemu powstało wiele. Jednym z nich był system oparty oprogram SNDMSG działajacy w systemie TENEX. TENEX powstał w 1970 r. w Digital Equip-ment Company i był przeznaczony dla komputera PDP-10. Zawierał on program SNDMSGo mozliwosciach praktycznie identycznych, jak mozliwosci programu MAIL z CTSS. W po-łowie 1971 r. Ray Tomlinson z DEC postanowił rozszerzyc mozliwosci programu SNDMSGo opcje wymiany wiadomosci miedzy zdalnymi systemami, co opisuje w [2]. Opracowałw tym celu protokół CPYNET – prosty protokół przesyłania plików miedzy zdalnymi sys-temami, który zastosowany mógł zostac równiez do zapisywania wiadomosci wysłanychprzy pomocy programu SNDMSG do skrzynek pocztowych uzytkowników na zdalnychkomputerach z systemem TENEX. Przy okazji opracowywania tego systemu wymiany wia-domosci, jego autor podjał jedna decyzje projektowa, której skutki do dnia dzisiejszego wi-doczne sa podczas codziennego korzystania z poczty elektronicznej: zadecydował, iz wia-domosci od lokalnych uzytkowników beda odrózniane od wiadomosci od zdalnych uzyt-kowników poprzez dodanie do nazwy nadawcy tych drugich znaku „@” i nazwy kompute-ra, z którego wiadomosc została wysłana. Ten format zapisu został nastepnie usankcjonowa-ny jako obowiazujacy w sieci ARPANET, a pózniej równiez Internet, przez rózne dokumen-ty standaryzujace (m.in. RFC 2822 [3]). Pierwsze wiadomosci zostały przesłane za pomocatego protokołu miedzy zdalnymi komputerami (fizycznie zlokalizowanymi tuz obok sie-bie, ale w sensie logicznym połaczonymi jedynie poprzez siec ARPANET) pod koniec roku1971 – poczatkowo były to typowo testowe ciagi znaków (prawdopodobnie QWERTYUIOPlub podobne, ale dzis nie sposób juz tego z cała pewnoscia stwierdzic). Pierwsza wiadomo-scia niosaca sensowna tresc było obwieszczenie powstania sieciowej poczty elektronicznejskierowane do uzytkowników systemu TENEX, wraz z krótka instrukcja obsługi nowychfunkcji programu SNDMSG. Niedługo potem, w połowie roku 1972, wersja systemu TENEXzawierajaca program SNDMSG posiadajacy mozliwosc przesyłania wiadomosci miedzy zdal-nymi komputerami, weszła do codziennego uzytku. Za ciekawostke mozna uznac fakt, izprace nad tym systemem wymiany poczty nie odbywały sie na zlecenie firmy DEC, a wreczprzeciwnie – poczatkowo Tomlinson pracował wrecz w tajemnicy przed swoimi zwierzch-nikami. Jedynym uzasadnieniem, które podaje on na rozpoczecie prac nad nowa wersjaSNDMSG, jest: „mostly because it seemed like a neat idea” („głównie dlatego, ze wydawało sie toniezłym pomysłem”).

2


Równoczesnie z wydaniem wersji systemu TENEX zawierajacej mozliwosc przesyła-nia poczty elektronicznej miedzy zdalnymi systemami, rozwiazanie stworzone przez RayaTomlinsona powielił Abhay Bhushan, wykładowca MIT, w stworzonym przez siebie FileTransfer Protocol dla sieci ARPANET. Miało to bardzo istotne znaczenie dla rozwoju komu-nikacji sieciowej, gdyz protokół ten stał sie pierwszym standaryzowanym (w RFC 354 [4])protokołem umozliwiajacym transport poczty elektronicznej. Okazał sie on wielkim sukce-sem. Jak wynika z raportu przedstawionego przez Bhushana w 1973 r., juz w niecały rok pojego opublikowaniu, wymiana poczty elektronicznej stanowiła około 75% całego ruchu wsieci ARPANET. Równiez w tym samym czasie poczta elektroniczna zaczeła byc uzywananie tylko dla rozrywki i prywatnej komunikacji uzytkowników sieci ARPANET, ale takzedla celów biznesowych. Pierwsza osoba, która ja z takim przeznaczeniem zaczeła wykorzy-stywac był ówczesny dyrektor ARPA, Steve Lukasik. Nalegał on, aby cała komunikacja znim wewnatrz ARPA, odbywała sie za pomoca poczty elektronicznej, a tym samym wpro-wadził ja jako stały srodek komunikacji wewnatrz ARPA, a nawet jako element kulturywewnetrznej tej organizacji.

W ten oto sposób, do 1975 r. liczba uzytkowników poczty elektronicznej w sieciARPANET osiagneła kilkaset osób. Warto zauwazyc, ze jednoczesnie zaczeło to powodo-wac ujawnianie kolejnych problemów zwiazanych z zaprojektowanym przez Van Vleckaprotokołem; odkrywane były kolejne jego słabosci. Jedna z nich, bardzo znaczaca i dokucz-liwa, był prosty, ale zupełnie nieodpowiedni dla duzych ilosci ruchu, protokół wyznaczaniamarszruty wiadomosci. Jim McQuillian rozpoczał zatem badania majace na celu znalezie-nie wszystkich słabych punktów uzywanego protokołu, a nastepnie opracowanie metod icheliminacji. Dodatkowym problemem okazała sie byc heterogenicznosc komputerów orazsystemów stosowanych w sieci ARPANET. Powodowała ona problemy z przetwarzaniemnagłówków wiadomosci, które w zaden sposób nie były standaryzowane, a co za tym idzie– wygladały róznie w wiadomosciach pochodzacych z róznych systemów. Powage sytuacjinajlepiej pokazuje fakt, iz nawet znak „@”, który juz wtedy miał zasadnicze znaczenie wpoczcie elektronicznej, nie był na wszystkich systemach interpretowany jednakowo – np. wsystemie Multics był to znak zarezerwowany dla systemu operacyjnego (tzw. kill-line cha-racter), a wiec uzycie go w poczcie elektronicznej było praktycznie wykluczone. Wszystkoto spowodowało, ze Bhushan doszedł do wniosku, iz w momencie, kiedy transport pocz-ty elektronicznej stał sie zbyt istotnym elementem aktywnosci w sieci ARPANET, aby bycjedynie „dodatkiem” do protokołu przesyłania plików, nalezało opracowac jeden, wspólnydla całej sieci, standard jej transportu. W zwiazku z tym stanał on na czele komitetu, któregocelem było opracowanie wspólnego standardu dla wszystkich systemów podłaczonych dosieci ARPANET. Niestety okazało sie to o wiele trudniejsze, niz by sie wydawało – w cia-gu pierwszych czterech lat prac (tj. miedzy 1973 r. a 1977 r.) powstały az cztery propozycjestandardów dotyczacych formatu wiadomosci elektronicznych oraz ich wymiany (RFC 561[5], RFC 680 [6], RFC 724 [7], RFC 733 [8]), z których zaden nie został szerzej zastosowanyw praktyce.

Warto zauwazyc, iz rozwój elektronicznej poczty sieciowej nie koncentrował sie jedyniena programie SNDMSG oraz jego nastepcach czy pomysłach z niego zaczerpnietych. Bardzoistotna gałezia tego procesu było stworzenie oraz wdrozenie systemu wymiany wiadomoscimiedzy maszynami pracujacymi pod kontrola systemu Unix. Mike Lesk, pracujac w AT&TBell Laboratories, stworzył pod koniec lat 70. XX. wieku protokół komunikacji nazwanyUnix-to-Unix CoPy. Został on nastepnie gruntownie przepisany oraz ulepszony przez Pete-ra Honeymana, Davida A. Nowitza i Briana E. Redmana, a nastepnie ponownie przez Iana

3


Lance Taylora. Ta ostatnia wersja, wydana na warunkach zgodnych General Public License,stała sie najbardziej stabilna i praktycznie jedyna uzywana wersja. Protokół UUCP pozwoliłna róznego rodzaju komunikacje miedzy komputerami pracujacymi pod kontrola systemuUnix, w tym równiez na wymiane wiadomosci poczty elektronicznej. Mimo, iz zarównowymieniane wiadomosci, jak i sam protokół transportowy, były proste, to posiadał on chy-ba najbardziej zaawansowane ówczesnie mozliwosci wyznaczania marszruty wiadomoscioraz przekazywania ich miedzy systemami. Odrebnosc rozwoju tego protokołu od wszyst-kich pozostałych jemu współczesnych jest wyraznie widoczna równiez w formacie adreso-wania uzywanym przez UUCP: do oddzielania nazwy uzytkownika od nazwy komputeradocelowego uzywany był znak „!”, a nie „@”. Ciekawa własciwoscia protokołu UUCP byłamozliwosc podania wiecej niz jednej nazwy systemu pocztowego, co było jednoznaczne zwyznaczeniem marszruty wiadomosci explicite. Jednakze mimo odrebnosci rozwoju, pro-tokół UUCP wywarł bardzo widoczny wpływ na współczesny kształt poczty elektronicznej– wystarczy chocby zauwazyc, ze notacja uzywajaca znaku „!” do wyznaczania marszru-ty wiadomosci moze byc uzywana do dnia dzisiejszego. Równiez oprogramowanie, którezostało stworzone do transportu wiadomosci poprzez UUCP, odegrało bardzo istotna rolena rynku poczty elektronicznej. W 1979 r., wraz z wydaniem systemu operacyjnego BSD4.0, przedstawiony został program delivermail autorstwa Erica Allmana, który obsługi-wał własnie protokół UUCP, choc nie tylko – jedna z wiekszych jego zalet była mozliwoscwspółpracy z wieloma róznymi protokołami transportowymi jednoczesnie. Rozwinieciemtego programu był sendmail, który został zaprezentowany wraz z systemem BSD 4.1c w1983 r. Wraz z rozwojem poczty elektronicznej, rozwijany był równiez sendmail, a jegowysoka sprawnosc działania spowodowała, iz z czasem stał sie on najbardziej popularnym,najpowszechniej uzywanym w sieci Internet oprogramowaniem słuzacym do transportupoczty elektronicznej.

Równolegle znaczenie poczty elektronicznej zaczeły dostrzegac firmy i organizacje niezwiazane z siecia ARPANET. Koncern IBM zaproponował system MESSENGER słuzacy dowymiany poczty elektronicznej, przeznaczony dla sektora prywatnego. Podobny systemprzestawiła równiez Computer Corporation of America nazywajac go COMET. Jednak naj-powazniejszym kandydatem na konkurenta dla sieci ARPANET stał sie nieoczekiwanieUnited States Postal Service. Co prawda srednia liczba dziesieciu tysiecy wysłanych wia-domosci przez kazdy z 98 systemów podłaczonych do sieci ARPANET w 1976 r. nie mozebyc porównywana z piecdziesiecioma miliardami przesyłek obsługiwanych przez USPS, aleokazuje sie, iz była to wystarczajaca wielkosc, aby zwrócic uwage amerykanskiego mono-polisty pocztowego. Został nawet sporzadzony specjalny raport w tej sprawie [9], z któregoUSPS wyciagnał wnioski, iz technologia przesciga tradycyjne usługi pocztowe. W 1979 r.prezydent USA, Jimmy Carter, zaproponował, aby równiez elektroniczna komunikacja sta-ła sie czescia monopolu USPS. Według jego pomysłu listy byłyby przesyłane elektronicznieod urzedu pocztowego nadawcy do urzedu pocztowego odbiorcy, a nastepnie doreczane wtradycyjnej, papierowej formie przez listonosza. Pomysł ten (dzis juz mozemy powiedziec,ze na szczescie) nie został zrealizowany, głównie za sprawa sprzeciwu United States JusticeDepartment oraz Federal Communications Commision. Dzieki wstawiennictwu tych orga-nizacji, poczta elektroniczna (zarówno jej rozwój, jak i organizacja wymiany wiadomosci)została pozostawiona wolnemu rynkowi.

Tendencje wykraczania poczty elektronicznej poza ramy sieci ARPANET dobrze ilustru-je fakt, iz ten sposób wymiany wiadomosci wzbudził zainteresowanie w organizacji ITU-T (International Telecommunication Union – Telecommunication Standardization Sector).

4


Opracowała ona, wspólnie z organizacja ISO, zestaw rekomendacji, w których zdefiniowa-ne zostały standardy, zgodnie z którymi miały byc przesyłane elektroniczne wiadomoscipocztowe. Rekomendacje te oznaczone zostały przez ITU-T symbolem X.400 i zatytułowa-ne „Data Communication Networks for Message Handling Systems” [10]. Pierwsza ich wersjazostała opublikowana juz w 1984 r. w tzw. Red Book. Od tamtego czasu, zaproponowanestandardy były wielokrotnie poprawiane oraz wzbogacane o nowe funkcje i mozliwosci –np. w wydanej w 1988 r. Blue Book czy tez w White Book z 1992 r. Protokół ten jednak nie za-błysnał na rynku poczty elektronicznej tak, jak inne opisywane przeze mnie. Jako standardISO/OSI został on opracowany przez najlepszych specjalistów z dziedziny telekomunika-cji i – jako taki – jest bardzo rozbudowany oraz posiada ogromne mozliwosci. Niestety towłasnie stało sie przyczyna jego zguby – ze wzgledu na to, iz jest to bardzo skomplikowanyprotokół, a wiekszosc z jego mozliwosci nie znajduje praktycznego zastosowania w zwy-czajnym transporcie wiadomosci, nie wszedł on do uzycia w codziennej wymianie pocztyelektronicznej miedzy uzytkownikami sieci komputerowych. Od samego powstania jedy-nymi podmiotami zainteresowanymi wdrazaniem oraz stosowaniem tego protokołu byłyarmia, wywiad oraz lotnictwo, w których dobrze wyspecyfikowany, kompletny, bezpiecznyi posiadajacy rozbudowane mozliwosci protokół był zdecydowanie preferowany nad pro-ste, choc o wiele szybsze i sprawniejsze w typowych zastosowaniach, protokoły powstajacew sieci ARPANET.

Jednym z bardziej istotnych przejawów rozwoju poczty elektronicznej poza sieciaARPANET były działania podjete w 1978 r. przez U.S. Army Materiel Command, majacena celu umozliwienie przesyłania poczty z systemów nie podłaczonych bezposrednio doARPANET, ale za to podłaczonych do linii telefonicznej. Aby sprostac temu zapotrzebowa-niu, Dave Crocker stworzył system przekazywania wiadomosci nazwany Multi-purposeMemo Distribution Facility, który realizował dokładnie przedstawione przez USAMC za-łozenia. Po prawie pół roku pracy, jego eksperymentalna wersje wdrozył na University ofDelaware, gdzie z powodzeniem obsługiwała rózne odległe osrodki USAMC. Wersja ta byładalej rozwijana przez wielu kolejnych pracowników DARPA, w tym m.in. Douga Kingsto-na, Craiga Partridge’a oraz Steve’a Kille’a. Wprowadzili oni do MMDF takie zmiany, jakwymiane oryginalnej warstwy transportowej (zaprojektowanej przez Eda Szurkowskiego)na TCP/IP, zaadaptowanie systemu do transportu poczty zgodnej ze standardem X.400, atakze wdrozenie go w sieci CSNET.

Dalszy rozwój poczty elektronicznej, a szczególnie dalsze zwiekszanie sie liczby przesy-łanych wiadomosci, powodowało intensyfikacje prac majacych na celu stworzenie nowego,bardziej uniwersalnego protokołu wymiany wiadomosci. Zostały one uwienczone powsta-niem Simple Mail Transfer Protocol – w swej pierwszej wersji opublikowanego w RFC 821[11] w 1982 r. Głównymi załozeniami projektowymi tego protokołu, wymienionymi w po-danym dokumencie standaryzujacym, były prostota, efektywnosc oraz niezawodnosc. Towłasnie one zagwarantowały sukces SMTP, który widoczny jest do dnia dzisiejszego. Dopowodzenia SMTP przyczyniła sie takze jego implementacja – w niedługim czasie po opu-blikowaniu specyfikacji, protokół ten obsługiwany był przez oprogramowanie sendmail,którego popularnosc juz ówczesnie zataczała coraz szersze kregi.

Jak twierdzi Dave Crocker w [12], bardzo istotna role we wzroscie popularnosci pocz-ty elektronicznej wsród uzytkowników sieci ARPANET odegrał rozwój nie tylko systemówjej wysyłania i transportu, ale równiez narzedzi słuzacych do odczytywania otrzymanychwiadomosci i ogólnie pojetego zarzadzania własna skrzynka pocztowa – aplikacji, które

5


dzis nazwalibysmy klientami pocztowymi. Poczatkowo, we wczesnych czasach komunika-cji miedzy uzytkownikami systemu CTSS, uzywany do tego celu był zwykły edytor teksto-wy. Łatwo mozna sobie wyobrazic ograniczenia wynikajace z takiego rozwiazania – znaneobecnie funkcje programów pocztowych po prostu nie istniały, a wiec czytanie otrzymanejkorespondencji było niewygodne, zmudne i czasochłonne. Pierwszym dedykowanym pro-gramem do czytania poczty elektronicznej był READMAIL, który powstał w systemie TENEXwraz z programem SNDMSG. Pozwalał on, co prawda, jedynie na proste, sekwencyjne prze-gladanie otrzymanych wiadomosci oraz usuwał je po jednokrotnym przeczytaniu, ale i takzostał uznany za ogromny postep w czynieniu obsługi poczty elektronicznej bardziej przy-jazna dla uzytkownika. Stał sie on równiez podstawa dla kolejnych aplikacji powstajacychz mysla o takim zastosowaniu. To własnie na nim wzorowany był program RD. Stworzył goLawrence Roberts, ówczesny dyrektor Information Processing Techniques Office, na prosbeSteve’a Lukasika. Moze sie wydawac, iz był to krok wstecz, gdyz ponownie poczta elektro-niczna miała byc odczytywana przy pomocy edytora tekstowego (RD nie był samodzielnymprogramem, a jedynie zestawem makr dla edytora TECO uzywanego w systemie TENEX),jednak tak naprawde wygoda obsługi wiadomosci elektronicznych została zdecydowaniepoprawiona – RDwprowadzał takie nieocenione mozliwosci, jak czytanie, zapisywanie orazusuwanie wiadomosci ze skrzynki pocztowej w dowolnej kolejnosci czy tez mozliwosc sor-towania wiadomosci według daty lub tematu. W ten sposób, po raz pierwszy od narodzinkomunikacji elektronicznej, uzytkownicy otrzymali mozliwosc w miare wygodnego zarza-dzania swoimi skrzynkami pocztowymi. Jednak, jak sie mozna domyslic, te funkcje nadalnie wszystkim uzytkownikom sieci ARPANET wystarczały, w zwiazku z czym program RDbył dalej rozwijany. W wyniku prac nad nim powstał NRD, a nastepnie WRD (zwany póz-niej BANANARD), który zintegrował w sobie równiez mozliwosci SNDMSG, a takze stał siesamodzielna (tzn. niezalezna od edytora TECO) aplikacja. Jednakze prawdziwym krokiemmilowym w rozwoju poczty elektronicznej, który przekonał wiele osób o jej uzytecznosci,było powstanie programu MSG, uznawanego za pierwszy w miare współczesny programpocztowy. W stosunku do tworzonych wczesniej aplikacji wyrózniał sie on kilkoma bardzoznaczacymi opcjami: konfigurowalnym interfejsem uzytkownika, mozliwoscia przesyłaniadalej otrzymanych wiadomosci, a takze opcja odpowiedzi na otrzymana wiadomosc. Szcze-gólnie ta ostatnia własciwosc okazała sie byc przełomowa – sprawiła ona, ze poczta elektro-niczna przestała słuzyc jedynie do wymiany odrebnych, w zaden sposób nie powiazanychze soba wiadomosci, a stała sie sposobem na konwersacje miedzy jej uzytkownikami. Towłasnie mozliwosc takiego jej zastosowania w duzej mierze zadecydowała o sukcesie, jakipoczta elektroniczna miała odniesc w przyszłosci. Zapowiedzia tego sukcesu stał sie fakt,iz juz w 1975 r. Steve Walker, pracownik DARPA, stworzył projekt majacy na celu przenie-sienie programu MSG na platforme systemu Unix. Projektem tym pokierował Dave Farber,wykładowca z University of California w Irvine, a udział w nim wzieli Dave Crocker, SteveTepper oraz Bill Crosby. Wynikiem ich prac stał sie MS – program o bardzo rozbudowanychmozliwosciach. Posiadał on wszystkie funkcje znane z MSG, a takze wprowadzał kilka in-nowacji, np. mozliwosc uzywania kilku róznych interfejsów uzytkownika (tekstowy, pseu-dograficzny znany z MSG itp.). Posiadał on tez znaczaca wade: był niesamowicie wolny. Wzwiazku z tym projekt w DARPA był kontynuowany – postanowiono przepisac MS tak, abylepiej wykorzystywał mozliwosci srodowiska systemu Unix (np. dokonano rozbicia mono-litycznego programu MS na wiele mniejszych narzedzi realizujacych poszczególne zadania).W ten sposób powstał program MH (od ang. Mail Handler), który stał sie standardem w ob-słudze poczty elektronicznej w systmie Unix.

6


Innym bardzo istotnym watkiem w historii rozwoju poczty elektronicznej, jest powsta-nie niechcianych wiadomosci, zwanych obecnie spamem. Pierwsza z takich wiadomoscimiała podłoze polityczno-społeczne. Została wysłana jeszcze przed powstaniem sieciowejpoczty elektronicznej – jako lokalna wiadomosc wysłana do wszystkich uzytkowników sys-temu CTSS w 1971 r. Jej tresc brzmiała:

THERE IS NO WAY TO PEACE. PEACE IS THE WAY.Ciekawostka jest fakt, iz mozliwosc takiego naduzycia została przewidziana przez auto-rów programu MAIL – posiadał on wbudowane odpowiednie zabezpieczenia, które miałynie dopuscic do masowego wysyłania wiadomosci do potencjalnie niezainteresowanych od-biorców. Autor pierwszego spamu wykorzystał fakt, iz nalezał do projektu administratorówsystemu CTSS, a wiec posiadał uprawnienia wieksze niz zwyczajni uzytkownicy. Pierwszaniechciana wiadomosc elektroniczna skierowana do zdalnego adresata powstała wiele latpózniej – pojawiła sie ona w sieci ARPANET dopiero w 1978 r., co opisane zostało w [13].Została ona wysłana przez handlowca Digital Equipment Company, Garyego Thuerka, dowszystkich uzytkowników sieci ARPANET na zachodnim wybrzezu USA. Jej tresc stano-wiła typowa reklama, jaka znamy ze współczesnych spamów – obwieszczała powstanienowego modelu komputera mainframe DEC-20. Problem niechcianych wiadomosci był odtego czasu szeroko dyskutowany. Powstał nawet odpowiedni dokument RFC 706 [14] trak-tujacy o tym problemie, a takze proponujacy pewne kroki zapobiegawcze, które mogłybyograniczyc rozpowszechnianie sie tego zjawiska w przyszłosci.

Zyski komercyjne z zastosowania poczty elektronicznej dostrzegli na szczescie nie tylkopierwsi spammerzy. Wraz ze zwiekszaniem sie zasiegu sieci Internet, zarówno jesli chodzi opokryte terytorium, jak i o liczbe podłaczonych do niej komputerów, zaczeły sie pojawiac fir-my uzywajace poczty elektronicznej do celów biznesowych. Pierwszym komercyjnym sys-temem poczty elektronicznej w sieci Internet stał sie MCI Mail, który został podłaczony w1988 r. przez Vintona Cerfa za posrednictwem Corporation for the National Research Initia-tive. Było to podłaczenie eksperymentalne, ale zakonczyło sie pełnym sukcesem, w zwiazkuz czym pociagneło za soba kolejne podobne przedsiewziecia, z których najistotniejszym by-ło podłaczenie systemu pocztowego Compuserve do sieci Internet poprzez Ohio State Uni-versity. Naturalnym rozwinieciem komercyjnego zastosowania poczty elektronicznej byłowyciagniecie zysków ze swiadczenia usług z nia zwiazanych. Pierwsza firma, która zaczełaswiadczyc takie usługi, była America Online, która swoim uzytkownikom komercyjne kon-ta pocztowe zaoferowała juz w 1993 r. Wydarzenie to jest uwazane za jeden z wazniejszychkroków w rozwoju nie tylko poczty elektronicznej, ale równiez sieci Internet jako całosci.

7

Rozdział 2.

Obecna sytuacja na rynku pocztyelektronicznej

Burzliwy rozwój poczty elektronicznej oraz jej rosnaca popularnosc maja swoje odzwiercie-dlenie w istniejacym dzisiaj rynku zwiazanym z wymiana wiadomosci w sieciach kompu-terowych. Poczta elektroniczna jest w chwili obecnej najpopularniejszym sposobem wymia-ny wiadomosci miedzy uzytkownikami komputerów, nawet pomimo rosnacego znaczeniausług typu Instant Messaging. Ani IM (usługa zwana w Polsce popularnie komunikatora-mi), ani inne formy komunikacji elektronicznej (IRC, czaty na stronach WWW, a nawet gru-py dyskusyjne Usenet) nie były w stanie nigdy przewyzszyc swoja popularnoscia pocztyelektronicznej. Moim zdaniem fenomen ten dobrze wyjasnia historia: poczta elektronicznapowstała chronologicznie jako pierwszy sposób elektronicznej wymiany wiadomosci, a coza tym idzie – miała najwiecej czasu, aby zdobyc popularnosc i uznanie wsród uzytkowni-ków. Jako metoda komunikacji, poczta elektroniczna jest współczesnie obecna w praktycz-nie kazdej sieci komputerowej: bardzo cenia ja uzytkownicy sieci korporacyjnych, małychsieci lokalnych, a przede wszystkim – sieci Internet. To własnie ta ostatnia siec, najwiek-sza globalna siec komputerowa, bedzie podstawa do moich dalszych rozwazan, gdyz to wniej nastepuje główny nurt rozwoju i ewolucji poczty elektronicznej, a takze w niej najlepiejwidoczne sa wszystkie zwiazane z tym mozliwosci, problemy czy zagrozenia.

Jak podaje Pew Internet & American Life Project w swoim raporcie z grudnia 2007 r.[15], około 92% uzytkowników sieci Internet w USA korzysta z usług zwiazanych z pocz-ta elektroniczna. Jest to pierwsza pozycja na liscie aktywnosci uzytkowników sieci Internet– wyprzedza ona nawet odsetek osób korzystajacych z wyszukiwarek internetowych. Wpodobnym raporcie dotyczacym codziennego korzystania z sieci Internet [16], poczta elek-troniczna równiez zajmuje pierwsza pozycje – korzystanie z niej podczas „typowego” dniadeklaruje 60% badanych osób. Uzytkowników poczty elektronicznej mozna podzielic nadwie grupy: uzytkowników korporacyjno-biznesowych oraz uzytkowników prywatnych.Mimo, iz niejednokrotnie sa to dokładnie te same osoby, ich sposób korzystania z usługpocztowych diametralnie rózni sie w zaleznosci od roli, w której wystepuja. Uzytkownicybiznesowi w wiekszosci wykorzystuja poczte elektroniczna zgodnie z jej pierwotnym prze-znaczeniem – do wymiany prostych, niezbyt długich wiadomosci tekstowych. Swiadczyo tym fakt, iz zgodnie z badaniami firmy Ferris Research [17] rozmiar przecietnego listu

8

ROZDZIAŁ 2. OBECNA SYTUACJA NA RYNKU POCZTY ELEKTRONICZNEJ

w słuzbowej skrzynce odbiorczej pracowników nie przekracza 10 kB. Wiadomosci z nie-wielkimi załacznikami (tzn. o rozmiarze miedzy 100 kB a 1 MB, w których załacznikami sagłównie dokumenty tekstowe czy arkusze kalkulacyjne) stanowia jedynie 10% wymienia-nej korespondencji, zas wieksze – jedynie 5%. Ciekawostka jest obserwacja, iz w tej ostatniejgrupie zdecydowanie przewazaja listy nie zwiazane z praca zawodowa – np. smieszne pre-zentacje czy zdjecia kotów. Nie dziwi to jednak, jesli przyjrzec sie sposobowi, w jaki te sameosoby wykorzystuja poczte elektroniczna po godzinach pracy. W prywatnym wykorzysta-niu poczty elektronicznej duzo wiekszy udział stanowia listy o znaczaco pokazniejszychrozmiarach. Przyczyna tego jest fakt, iz prywatne wykorzystanie poczty elektronicznej dlawielu osób jest zwiazane głównie z przesyłaniem tresci multimedialnych (np. zdjec, muzy-ki, a czasami nawet filmów), nie zas wymiana wiadomosci tekstowych. Oczywiscie dane tenie sa identyczne dla wszystkich uzytkowników sieci Internet – róznia sie one w zaleznosciod np. wieku czy doswiadczenia w korzystaniu z poczty elektronicznej konkretnej osoby.

Warto zauwazyc, iz we współczesnym swiecie, poczta elektroniczna nie stanowi jedynieciekawego rozwiazania z punktu widzenia technicznego, jak to miało miejsce w poczatko-wym okresie jej rozwoju, lecz moze byc postrzegana równiez jako zjawisko społeczne. Bedactak popularna metoda komunikacji miedzyludzkiej, odgrywa ona bardzo istotna role w zy-ciu wielu osób regularnie z niej korzystajacych. Dla niektórych jest ona narzedziem pracy,przy pomocy którego utrzymuja kontakty z kontrahentami i współpracownikami, zdoby-waja nowych klientów czy tez wymieniaja informacje pozwalajace rozwijac im prowadzonadziałalnosc. Inni korzystaja z poczty elektronicznej w celu utrzymywania prywatnych kon-taktów z bliskimi. Dzieki powszechnemu, ogólnoswiatowemu zasiegowi sieci Internet, azatem równiez poczty elektronicznej, wymiana elektronicznych listów dla wielu osób stałasie podstawowa metoda komunikacji, dzieki której budowane sa zwiazki miedzyludzkie,nawet tak wazne, jak przyjazn czy miłosc. Zaczeła ona pełnic taka role, jaka swego czasuspełniała poczta tradycyjna, posiadajac przy tym bardzo wazna zalete błyskawicznego do-reczenia.

W zwiazku z bardzo istotna rola, jaka odgrywa poczta elektroniczna we współczesnymswiecie, nalezy moim zdaniem nieco dokładniej przeanalizowac rynek zwiazany z jej trans-portem. Ponizej przedstawie najwazniejsze informacje dotyczace tego obszaru współcze-snych sieci komputerowych: po krótce opisze najpopularniejsze protokoły słuzace do wy-miany elektronicznych wiadomosci pocztowych, a takze omówie podstawowe problemy,którymi nekany jest omawiany rynek, wraz z najczesciej stosowanymi ich rozwiazaniami.Jako ze najistotniejsza czescia rynku transportu poczty elektronicznej jest jej przesyłanie wsieci Internet, to, jak juz wspomniałem powyzej, głównie tego pola dotyczyc beda moje roz-wazania (choc nie beda tylko do niego ograniczone).

2.1. Stosowane protokoły wymiany poczty elektronicznej

Współczesny rynek poczty elektronicznej jest praktycznie zmonopolizowany. Przytłaczaja-ca wiekszosc ruchu pocztowego realizowana jest za posrednictwem Simple Mail TransferProtocol. Protokół ten, od swego powstania ponad 25 lat temu, cieszy sie niesłabnaca po-pularnoscia, dzieki której w chwili obecnej praktycznie nie istnieje na rynku masowym dla

9


niego zadna konkurencja. Na rynkach niszowych, o szczególnych wymaganiach lub szcze-gólnych mozliwosciach srodowiskowych, wciaz jednak sa stosowane protokoły, które roz-wijały sie wczesniej niz SMTP lub równolegle z nim. Najwazniejsze z nich to X.400 orazUnix-to-Unix CoPy.

Ponizej postaram sie podac krótka charakterystyke kazdego z trzech wymienionych pro-tokołów, a takze przedstawic jego role i miejsce we współczesnym rynku poczty elektronicz-nej.

2.1.1. Simple Mail Transfer Protocol

Jak juz wspomniałem powyzej, SMTP stanowi obecnie dominujacy na rynku protokół trans-portu poczty elektronicznej w sieci Internet, a takze w przewazajacej wiekszosci sieci lokal-nych, korporacyjnych i innych. Powodów, dla których to własnie ten protokół stał sie takpopularny, jest wiele. Pierwszym godnym uwagi jest fakt, iz w chwili swego powstania byłon najbardziej elastycznym, dostepnym protokołem, a co za tym idzie – oferował najwiekszyzestaw mozliwosci zwiazanych z transportem poczty elektronicznej. Zaleta ta, połaczona zprostota protokołu, sprawiła, iz stał sie on szeroko implementowany. Serwery oraz klienciSMTP powstały w krótkim czasie dla bardzo wielu popularnych systemów operacyjnych,a w koncu – dla wszystkich znanych i uzywanych we współczesnych sieciach komputero-wych. Mnogosc dostepnego oprogramowania (zarówno serwerowego, jak i klienckiego), atakze jego znaczace zróznicowanie, spowodowały, iz praktycznie kazdy uzytkownik mozew chwili obecnej znalezc program, który bedzie bardzo dobrze spełniał jego wymagania.Dodatkowo przy tak szerokim gronie uzytkowników oraz osób zwiazanych z rozwojemoprogramowania przeznaczonego do obsługi SMTP, nawet najbardziej nietypowe potrzebymoga zostac zaspokojone bez wiekszego trudu. Tak duzy potencjał rozwojowy sprawił, izSMTP w bardzo skuteczny sposób wyparł z rynku wszelka konkurencje, która nie mogłasie tymi zaletami poszczycic. Sukces SMTP znalazł swe ukoronowanie, gdy w 2004 r. jegodominacja de facto w sieci Internet została oficjalnie uznania i stał sie on obowiazujacymstandardem transportu poczty elektronicznej na mocy RFC 3700 [18].

SMTP, jak sama jego nazwa wskazuje, jest prostym protokołem tekstowym. Jego załoze-nia projektowe uwzgledniały co prawda zaawansowane mozliwosci (np. skomplikowane,przynajmniej jak na poczatek lat 80. XX. wieku, wyznaczanie marszruty wiadomosci), alestawiały sobie za główny cel prostote protokołu. Załozenie to wynikało z potrzeby posiada-nia protokołu, który nie tylko spełniałby wymagania nakładane mu przez skomplikowanastrukture sieci Internet, ale równiez takiego, który dawałby implementatorom mozliwoscwdrozenia go w prosty, sprawny sposób. Jego autorzy juz podczas projektowania proto-kołu przewidzieli, ze jest to najlepszy sposób dla zapewnienia mu sukcesu, co pozwoliłomu nie podzielic losu wielu rozwiazan, które byc moze miały przewage funkcjonalna, aleswa postacia nie wzbudzały szczególnego zainteresowania osób mogacych je potencjalniewdrozyc.

SMTP zaprojektowany został w architekturze klient-serwer. Oznacza to, ze w celu prze-kazania wiadomosci, strona posiadajaca ja, inicjuje połaczenie ze strona docelowa, a na-stepnie dokonywana jest wymiana komend przewidzianych przez protokół. SMTP działaw schemacie zadanie – odpowiedz, a wiec przekazanie wiadomosci ma postac konwersacji,

10


w której obie strony biora aktywny udział. Taka konstrukcja pozwala na sygnalizowanieewentualnych błedów (czy to zwiazanych z obsługa protokołu czy tez lokalnych dla któ-rejs ze stron) na biezaco i daje drugiej stronie mozliwosc natychmiastowego reagowania nanie. Jak w wiekszosci znanych protokołów tekstowych, błedy sygnalizowane sa kodem od-powiedzi o ustalonym, standaryzowanym znaczeniu – umozliwia to przetwarzanie ich wsposób maszynowy. Jednak, aby dac człowiekowi mozliwosc interaktywnego korzystaniaz protokołu, a takze ułatwic mu poszukiwanie ewentualnych błedów, które moga wysta-pic podczas przekazywania wiadomosci, kody odpowiedzi moga byc (warto zauwazyc, izw wiekszosci implementacji korzystajacych z SMTP jest ta mozliwosc wykorzystywana)wzbogacone o czytelne dla człowieka wyjasnienie rodzaju błedu, który miał miejsce i ewen-tualnie tez jego przyczyny.

Jako protokół projektowany miedzy innymi z mysla o mozliwosci konstruowania skom-plikowanych marszrut wiadomosci, SMTP jest bardzo elastyczny w tej kwestii. Typowymschematem, który był pierwotnie planowany przez autorów protokołu, było przekazanieprzez nadawce wiadomosci do najblizszego (w sensie geograficznym oraz połaczen siecio-wych) serwera SMTP, który nastepnie dostarczał dana wiadomosc do serwera SMTP odbior-cy. Schemat taki bardzo dobrze sprawdzał sie na poczatku lat 80. XX. wieku, lecz współcze-snie, w zwiazku z mnozacymi sie zagrozeniami, które komplikuja działanie poczty elektro-nicznej w sieci Internet, bardziej popularne jest przekazywanie przez nadawce wiadomoscido serwera dostawcy usług pocztowych. Istnieja oczywiscie równiez inne schematy, wyko-rzystywane np. w sieciach korporacyjnych czy tez w sieciach niektórych dostawców usługinternetowych. Moga one odznaczac sie nawet duzym stopniem skomplikowania konstru-owanej marszruty wiadomosci – nierzadkie sa przypadki, w których wiadomosc przecho-dzi przez kilkanascie systemów przekazujacych. Ciekawa mozliwoscia jest fakt, iz nadawcamoze explicite wyznaczyc jej marszrute (lub czesc z niej) juz w chwili tworzenia wiadomo-sci. Stosowana jest w tym celu notacja przejeta z protokołu UUCP: ciag kolejnych adresówmaszyn przekazujacych wiadomosc, oddzielanych znakiem „!” poprzedza własciwy adresodbiorcy.

SMTP, jako protokół projektowany ponad 25 lat temu, z przyczyn oczywistych nie jestprzystosowany do zmian, które zachodziły w sieci Internet od czasu jego powstania az dodzis. Aby wiec mozna go było z powodzeniem stosowac we współczesnych czasach, po-wstało wiele rozszerzen tego protokołu, które wzbogacaja go o nowe mozliwosci, a takzepoprawiaja, zauwazone podczas praktycznego jego stosowania, niedoskonałosci. Rozsze-rzenia te powstawały na przestrzeni wielu lat, praktycznie od powstania samego SMTP. Wtym czasie stworzono ich bardzo znaczaca ilosc – jedne bardziej przydatne i udane, innemniej, a co za tym idzie, równiez mniej popularne. Po prawie 20 latach istnienia protokołu,w 2001 r., najwazniejsze z tych rozszerzen zostały zebrane w jednym dokumencie standary-zujacym (RFC 2821 [19]), który wprowadził nowa wersje protokołu, znana popularnie jakoExtended SMTP (choc oficjalna nazwa pozostała bez zmian).

Najwazniejszym, moim zdaniem, z zaprojektowanych rozszerzen SMTP jest SMTPAUTH. Polega ono na dodaniu do protokołu opcjonalnej autoryzacji, dzieki której strona od-biorcza moze weryfikowac tozsamosc strony nadawczej. Przełomowosc tego rozszerzeniawiaze sie z problemem wysyłania niechcianej poczty przez cudze serwery. Aby zapobiectakim praktykom, administratorzy oraz osoby zajmujace sie rozwojem SMTP wprowadzilimechanizm, dzieki któremu do danego serwera ma dostep tylko grupa osób z nim w pewiensposób zwiazanych, tj. jego uzytkownicy.

11


Uzytkownicy SMTP od bardzo dawna obawiali sie o prywatnosc prowadzonej przezsiebie korespondencji. Mieli do tego bardzo dobre podstawy – w protokole, w którym całakomunikacja przebiega jawnym tekstem, wystarczy proste jej podsłuchanie, aby tresc wia-domosci przestała byc tajemnica. Problem ten stał sie jeszcze powazniejszy i jeszcze bardziejzauwazalny w momencie, gdy wprowadzono autoryzacje, gdyz od tej pory uzytkownicymusieli obawiac sie nie tylko o przesyłane wiadomosci, ale równiez o dane autoryzacyj-ne (tzn. nazwe uzytkownika i hasło), które przeciez nie powinny dostac sie w rece osóbtrzecich. Rozszerzeniem SMTP, które ma za zadanie naprawic ta niedoskonałosc, jest za-stosowanie Transport Layer Security, najszerzej obecnie stosowanej i uznanej technologiiszyfrowania połaczen sieciowych, do bezpiecznego przesyłania danych, które zdefiniowa-ne zostało w RFC 3207 [20].

Warto zauwazyc, iz całosc ruchu w SMTP jest realizowana w formie komunikacji typupush, tzn. strona nadajaca inicjuje połaczenie w momencie dla siebie dogodnym. Stronaodbierajaca moze co prawda nie przyjac połaczenia w momencie, kiedy jest to dla niej zjakichs wzgledów „niewygodne” (np. zgłaszajac bład tymczasowy w sesji SMTP), jednakzenie ma ona zadnej kontroli nad tym, kiedy strona nadajaca ponowi próbe przekazaniawiadomosci, a nawet czy w ogóle ponowna próba bedzie miała miejsce. Od dłuzszego czasutaka forma komunikacji jest uwazana za znacznie ograniczajaca mozliwosci protokołu, wzwiazku z czym powstało jego rozszerzenie majace na celu zmniejszenie jej konsekwencji,znane jako ETRN i zdefiniowane w RFC 1985 [21]. Daje ono odbiorcy wiadomosci mozliwosczazadania od nadawcy doreczenia jej w danym momencie. Jednakze, jak całemu SMTP,równiez temu rozszerzeniu przyswiecała idea prostoty, w konsekwencji czego nie jest topełna implementacja komunikacji typu pull, a jedynie jej drobna namiastka.

Kolejnym istotnym ograniczeniem SMTP w jego pierwotnej formie była mozliwosc prze-syłania jedynie siedmiobitowych znaków z zestawu US-ASCII. Przyczyna nałozenia takie-go limitu jest dosc oczywista: w czasach, kiedy protokół ten był projektowany, cały rozwójpoczty elektronicznej skupiał sie w USA, gdzie siedmiobitowe znaki pokrywaja cały uzy-wany alfabet. Mimo, iz poczta elektroniczna (a w raz z nia takze SMTP) szybko dotarłarówniez w inne, nawet najbardziej odległe i najbardziej egzotyczne zakatki swiata, to jed-nak zestaw znaków siedmiobitowych bardzo długo pozostawał jedynym akceptowanym wSMTP. Uzytkownicy oraz autorzy programów korzystajacych z tego protokołu wymyslilibardzo wiele sposobów obejscia tego problemu – od najprostszego, jakim jest powstrzy-mywanie sie od uzywania narodowych znaków diaktrycznych (co jednak jest mozliwe je-dynie w niektórych jezykach, których alfabet jest nadzbiorem alfabetu łacinskiego), az potak zaawansowane i rozbudowane, jak standard MIME. Wiazały sie jednak z nimi kolejneograniczenia i niewygody – np. utrudnione czytanie i komponowanie wiadomosci czy tezzwiekszenie ich rozmiaru. Ostatecznym rozwiazaniem problemu stało sie dopiero wpro-wadzenie rozszerzenia zwanego 8BITMIME zdefiniowanego w dokumencie RFC 3030 [22].Pozwoliło ono transportowac w SMTP dowolne bajty danych, a co za tym idzie – nie tylkodowolne znaki diaktryczne, ale równiez pliki binarne w swej oryginalnej formie. W zwiaz-ku z ta ostatnia mozliwoscia, ten sam dokument RFC definiuje równiez ułatwienia, któremoga byc stosowane przy przesyłaniu duzej ilosci danych.

Jak juz wspomniałem powyzej, oprogramowanie obsługujace SMTP jest na dzien dzi-siejszy praktycznie wszechobecne. Zarówno oprogramowanie klienckie, jak i serwerowedostepne jest dla wszystkich sieciowych systemów operacyjnych. W sieci Internet, wsródprogramów pocztowych, aktualnie najwieksza popularnoscia poszczycic sie moga Mozilla

12


Thunderbird oraz Microsoft Outlook i Microsoft Outlook Express. Sa to przykłady prostychw obsłudze programów klienckich, działajacych pod kontrola najpopularniejszych wsróduzytkowników sieci Internet systemów operacyjnych – Microsoft Windows, GNU/Linuxoraz Mac OS X. Wielka popularnoscia ciesza sie współczesnie równiez klienty typu webmail,czyli aplikacje WWW słuzace do obsługi poczty elektronicznej poprzez dowolnego klien-ta protokołu HTTP. Przyczyna ich rosnacego udziału w rynku jest prostota uzytkowaniawiazaca sie z brakiem koniecznosci instalacji specjalistycznego oprogramowania w syste-mie operacyjnym, a takze niezaleznosc od platformy sprzetowo-programowej czy nawet oduzywanego aktualnie komputera. Jesli chodzi o oprogramowanie serwerowe, zdecydowa-nie najwieksza popularnoscia ciesza sie programy pracujace pod kontrola systemów unik-sowych. Według badan firmy Gecad Technologies [23], najwiekszy udział w rynku do dzisposiada historycznie pierwszy publicznie dostepny serwer SMTP – Sendmail. Wslad za nimpodazaja serwery o rosnacej popularnosci – Postfix, qmail oraz Exim. Wsród najpopularniej-szych serwerów SMTP znalezc mozna równiez oprogramowanie przeznaczone dla systemuMicrosoft Windows – jest to głównie Microsoft Mail oraz bardzo rozbudowany i zaawanso-wany system wymiany poczty elektronicznej Microsoft Exchange.

2.1.2. X.400

SMTP to typowy przykład protokołu stworzonego przez srodowisko badaczy we wcze-snych czasach powstawania globalnej sieci komputerowej. Zupełnie odmienne podejscie doprojektowanego protokołu przedstawione zostało w zestawie rekomendacji definiujacychrodzine protokołów X.400 [10]. Stanowia one wynik wspólnej pracy organizacji ITU-T orazISO, a zatem sa dziełem zespołu fachowców, którzy dazyli do zaprojektowania komplet-nego, rozbudowanego, dobrze przetestowanego systemu wymiany elektronicznych wiado-mosci pocztowych. Cel ten został osiagniety w pełni: powstała rodzina standardów, któradefiniuje praktycznie kazdy mozliwy aspekt zwiazany z poczta elektroniczna – od jej trans-portu, poprzez wyznaczanie marszruty wiadomosci, az po kształt samych wiadomosci i ichprzechowywanie. Tak szeroki zakres specyfikacji sprawił, iz jego autorzy mieli pełna swo-bode w definiowaniu wszelkich wymagan dla kazdego z elementów systemu przekazywa-nia wiadomosci, a co za tym idzie – mogli stworzyc kazdy z nich od podstaw. Dzieki temuzaprojektowane przez nich rozwiazania sa bardzo nowatorskie, jak na czasy, w których po-wstały. W ten sposób autorzy zagwarantowali sobie takze mozliwosc realizacji wszystkichzałozen postawionych przed X.400 w sposób teoretycznie optymalny, gdyz projektowanietego protokołu nie było obarczone wymaganiem zgodnosci z zadnym systemem istniejacymwczesniej.

Pierwszym i najbardziej podstawowym elementem systemu pocztowego definiowanymw ramach X.400, jest ogólna architektura tego systemu. Jest ona nieco odmienna od archi-tektury znanej z szeroko uzywanych współczesnie systemów pocztowych. Oprócz dobrzeznanych aplikacji słuzacych uzytkownikowi do korzystania z systemu pocztowego (tzw.User Agents) oraz systemów przekazujacych poczte na drodze od nadawcy do uzytkowni-ka (tzw. Mail Transfer Agents), zdefiniowane sa równiez dodatkowe elementy, nie zawszeobecne w systemie, których rola jest przechowywanie wiadomosci w imieniu odbiorcy (tzw.Message Stores). Dodatkowo cały system pocztowy (zwany Message Handling System)podzielony został na dwa „obszary” – wydzielona została z niego czesc odpowiedzialna

13


za przekazywanie wiadomosci miedzy MTA (zwana Mail Transfer System). Powodem ta-kiego kroku jest oddzielenie go od warstwy, z która ma bezposrednia stycznosc uzytkow-nik, dzieki czemu istnieje mozliwosc abstrakcyjnego traktowania MTS podczas rozwazandotyczacych zdarzen zewnetrznych w stosunku do niego. Wyróznienie tak wielu elemen-tów systemu pocztowego spowodowało koniecznosc zdefiniowania komunikacji na kaz-dym mozliwym styku miedzy nimi. Bardzo dobrym rozwiazaniem, moim zdaniem, jestzrezygnowanie z jednego uniwersalnego protokołu na rzecz dedykowanego rozwiazaniaprzeznaczonego dla kazdego z mozliwych rodzajów komunikacji miedzy składnikami sys-temu, dzieki czemu kazdy z tworzonych protokołów moze byc jak najlepiej dopasowanyi wyspecjalizowany do konkretnej roli, która ma pełnic. Wada takiego podejscia jest jed-nak znaczace skomplikowanie całego systemu pocztowego, a co za tym idzie – koniecznoscponiesienia o wiele wiekszych nakładów przy jego implementacji i wdrazaniu, gdyz w ty-powych zastosowaniach kazdy z elementów MHS musi posiadac mozliwosc komunikacjiw wiecej niz jednym protokole.

Kolejnym elementem wyspecyfikowanym w ramach zestawu rekomendacji X.400 jestabstrakcyjny interfejs Mail Transfer System, a takze sposób komunikacji i wymiany wiado-mosci miedzy MTA, czyli protokół w terminologii X.400 nazywany P1. W ramach proto-kołu P1 zdefiniowany został format wiadomosci uzywany w komunikacji MTA ↔ MTA.Wiadomosci te podzielone zostały na dwie główne czesci: tzw. koperte oraz tresc zasad-nicza. Koperta słuzy serwerom przekazujacym wiadomosc do wyznaczania oraz sledzeniamarszruty wiadomosci. Zawiera ona informacje takie, jak identyfikator wiadomosci, opistresci wiadomosci gwarantujacy jej integralnosc w całym procesie doreczenia, informacje onadawcy i odbiorcy, a takze informacje sterujace – pozwalajace kolejnym systemom prze-kazujacym dana wiadomosc w sieci stwierdzic kiedy nalezy zmienic forme wiadomosci,zrezygnowac z jej dalszego przekazywania, czy tez podjac inne działania. Zapisana w niejjest tez cała historia doreczenia danej wiadomosci, dzieki czemu mozliwe jest odtworze-nie jej marszruty, a takze akcji podejmowanych przez kazdy z systemów przekazujacych.Wszystkie te informacje przekazywane sa w formie tekstowej, czytelnej dla człowieka podwarunkiem znajomosci ich – dosc skomplikowanego – formatu. Czesc stanowiaca, z punktuwidzenia MTA, tresc wiadomosci moze wystepowac w dwóch postaciach. Pierwsza z nichjest faktyczna binarna tresc przesyłanej wiadomosci. Druga zas stanowi wiadomosc zgodnaz protokołem P2, który opisze ponizej. Oprócz formatu wymienianych wiadomosci, definio-wany jest równiez sposób ich bezpiecznej i pewnej wymiany – tzw. Message Transfer ServiceElement, który stanowi definicje zastosowania nizszych warstw modelu ISO/OSI (głównietransportowej) do wymiany wiadomosci w relacji MTA↔MTA.

Wspomniany powyzej protokół P2 definiuje format wiadomosci, który stosowany jestw najwazniejszym z punktu widzenia uzytkownika elemencie przesyłania poczty elektro-nicznej – komunikacji w relacji UA ↔ UA. Jako, ze taka własnie komunikacje w sensie lo-gicznym widzi uzytkownik, to wiadomosc w protokole P2 traktuje sie jako odpowiedniklistu w poczcie tradycyjnej. Równiez wiadomosc w formacie protokołu P2 podzielona jestna dwie czesci: czesc nagłówkowa oraz własciwe ciało wiadomosci. W pierwszej z nich zna-lezc mozna informacje o nadawcy i odbiorcy listu (co ciekawe i warte zauwazenia – nie sa toinformacje obowiazkowe i moga zostac pominiete w niektórych warunkach), identyfikatorwiadomosci, a takze opcjonalne elementy dodatkowe, takie, jak np. odnosniki do innychwiadomosci. Ciało wiadomosci moze byc jeszcze dalej podzielone – na czesci stanowiaceodrebne elementy przesyłanego listu. Kazda z tych czesci moze byc przesłana w innymformacie, których bardzo wiele dopuszczonych zostało przez autorów protokołu. Wsród

14


najwazniejszych i najbardziej popularnych wymienic nalezy wiadomosci w formacie tek-stowym, głosowym, formacie faksu czy obrazu TIFF, a takze wiadomosci zaszyfrowane.Tresc wiadomosci moze stanowic takze odniesienie do zewnetrznej zawartosci, dostepnejpoprzez dowolny inny protokół.

Wymiana wiadomosci bezposrednio w protokole P2 zachodzi niezwykle rzadko – jedy-nie w sytuacji, w której miedzy UA nadawcy i odbiorcy istnieje bezposrednie połaczenie.Jednak w wiekszosci przypadków UA nadawcy musi w celu wysłania wiadomosci prze-kazac ja do swojego najblizszego MTA, który wyznaczy jej odpowiednia marszrute i prze-kaze az do MTA odbiorcy, skad dopiero zostanie ona dostarczona do jego UA. Pojawia siew takim razie koniecznosc komunikacji w relacji UA ↔ MTA. Do jej realizacji stworzonyzostał protokół P3. Pełni on dwojaka funkcje: oprócz wymiany wiadomosci miedzy UA aMTA, pozwala on równiez uzytkownikowi (w pewnych wybranych przypadkach) na kon-trole wiadomosci, które wysłane zostały wczesniej – w tym równiez anulowanie ich, jezelidoreczenie do odbiorcy nie zostało jeszcze rozpoczete. Z protokołem P3 zwiazana jest rów-niez definicja tzw. Message Submission Service Element, Message Delivery Service Element orazMessage Administration Service Element, które okreslaja mozliwosci oraz funkcje komunikacjiw relacji UA↔MTA. Z ciekawszych mozliwosci w nich zdefiniowanych wymienic nalezytzw. sondy (ang. probes) – stanowiace skrót wiadomosci (tzn. w szczególnosci nie zawiera-jace jej ciała). Daja one UA mozliwosc sprawdzenia, czy wiadomosc, która planuje wysłacmoze zostac przez dany MTA doreczona. Słuza one równiez „sondowaniu”, czy UA odbior-cy zaakceptuje przekazywana do niego wiadomosc, a co za tym idzie – pozwalaja odrzucicja bez przesyłania nadmiernej ilosci danych.

Czestym przypadkiem jest jednak sytuacja, w której UA, znajdujacy sie na komputerzeosobistym uzytkownika systemu pocztowego, nie jest dostepny – na przykład kiedy kom-puter ten jest wyłaczony. W takim wypadku role odbierania i przechowywania wiadomosciw imieniu danego uzytkownika pełni wybrany przez niego MS. Stanowi on równiez swe-go rodzaju instancje zarzadzajaca poczta uzytkownika według zdefiniowanych przez niegokryteriów – o ile w komunikacji w relacji UA ↔ MTA istnieje koniecznosc podjecia próbydoreczenia kazdej wiadomosci, która MTA otrzyma, o tyle MS ma mozliwosc selektywne-go filtrowania i usuwania wiadomosci, które zostały przez uzytkownika zdefiniowane jakoniechciane. Pozwala to, w znaczacy sposób zmniejszyc ruch sieciowy, który UA musi ob-słuzyc. MS udostepnia równiez uzytkownikowi mozliwosc odebrania w danym momenciejedynie wiadomosci, którymi jest zainteresowany, a wiec pozwala mu zarzadzac poczta wsposób dla niego efektywny. Protokół P7 pozwala równiez na wysyłanie poczty przez uzyt-kownika, czyli przekazywanie wiadomosci w relacji UA → MS. Daje to mozliwosc prze-słania wiadomosci na przykład w sposób odroczony, tzn. rozpoczecia jej doreczenia w in-nym, z góry zdefiniowanym terminie. Dzieki udostepnieniu takiej komunikacji mozliwejest równiez uproszczenie marszruty przesyłania wiadomosci – w znakomitej wiekszosciprzypadków UA nie musi sie komunikowac z zadnym elementem systemu obsługi pocztyelektronicznej poza swoim MS. Do okreslenia poszczególnych rodzajów funkcji i mozliwo-sci wystepujacych w komunikacji w relacji UA↔MS przeznaczone zostały definicje zwaneMessage Submission Service Element, Message Retrieval Service Element oraz Message Admini-stration Service Element, które sa integralna czescia specyfikacji protokołu P7.

Warto zauwazyc, ze celem przekazywania wiadomosci od UA nadawcy do UA odbior-cy nie zawsze jest bezposrednie odczytanie jej przez uzytkownika. W protokole X.400 UA

15


czesto nie jest klientem poczty elektronicznej w rozumieniu, do którego przyzwyczajeni je-stesmy z codziennego jej uzytkowania. W wielu wypadkach UA jest oprogramowaniemlub sprzetem, którego zadaniem jest konwersja wiadomosci do zupełnie odmiennego for-matu, a nastepnie doreczenie jej w sposób nie majacy nic wspólnego z poczta elektroniczna.Typowym, bardzo popularnym zastosowaniem tej mozliwosci sa UA przekazujace dalejwiadomosci jako telex czy faks.

Pozornie rodzina protokołów X.400 nie jest popularna we współczesnym rynku usługzwiazanych z transportem poczty elektronicznej. Jest to jednak dosc mylne wrazenie, wy-nikajace z ograniczonych mozliwosci badania tych niszy rynkowych, dla których X.400 jestpodstawowym sposobem wymiany elektronicznych wiadomosci pocztowych. Chodzi tumianowicie o sieci wewnetrzne duzych organizacji – poteznych korporacji, wojska, lotnic-twa, marynarki itp. Rozbudowanie protokołów z rodziny X.400, a takze ich niezawodnosc iduze mozliwosci sprawiaja, ze to własnie w tych obszarach zyskały one duza popularnosci sa bardzo chetnie stosowane. W zwiazku z taka specyfika uzytkowników, równiez opro-gramowanie tworzone na potrzeby obsługi protokołów z rodziny X.400 jest bardzo specy-ficzne. Duza jego czesc stanowia specjalistyczne programy stworzone samodzielnie przezorganizacje je wykorzystujace, gdyz w ten sposób gwarantuja najlepsze dopasowanie do– czesto bardzo specyficznych – ich potrzeb. Istnieje jednak równiez rynek komercyjnychproduktów zwiazanych z protokołami z rodziny X.400. Przez lata rozwoju tych protoko-łów, implementacje ich dostarczało wiele firm o bardzo znaczacej pozycji na rynku pocztyelektronicznej, m.in. XandMail czy Isode. Jednak produktem o najbardziej uznanej pozycjina rynku, a jednoczesnie tworzonym przez producenta bardzo znanego na rynku oprogra-mowania komputerowego, jest pakiet Microsoft Exchange. Stanowi on bardzo interesujacerozwiazanie dla instytucji chcacych wdrozyc bezpieczna i pewna technologie transportupoczty elektronicznej ponoszac przy tym wzglednie niskie koszty, a takze utrzymujac moz-liwosc wymiany wiadomosci z systemami korzystajacymi z innych protokołów transpor-towych, np. z SMTP. Implementacja X.400 w Microsoft Exchange jest chetnie uzywana, oczym bardzo dobrze swiadczy fakt, iz od czasu wprowadzenia jej w 1995 r. az do dzis, jestona utrzymywana (a nawet rozwijana), jako jedna z istotnych i docenianych funkcji tegopakietu.

2.1.3. Unix-to-Unix CoPy

W odróznieniu od opisanych wczesniej STMP i X.400, protokół UUCP nie był projektowa-ny z mysla o transporcie poczty elektronicznej. Jego pierwotne przeznaczenie było bardziejogólne: miał on słuzyc do szeroko pojetego zdalnego wykonywania komend oraz przesy-łania plików miedzy komputerami działajacymi pod kontrola uniksowego systemu opera-cyjnego. Tworzony on był w czasach, kiedy siec Internet nie była jeszcze szeroko uzywana,wiec dostosowany jest do panujacych ówczesnie warunków – do pracy w systemach znaj-dujacych sie w mniejszych sieciach komputerowych (najczesciej na poziomie konkretnej or-ganizacji) połaczonych miedzy soba zazwyczaj poprzez linie telefoniczne. Nie jest to jednakjedyny sposób komunikacji obsługiwany przez UUCP – jedna z wiekszych jego zalet jestmozliwosc obsługi wielu róznych protokołów transportowych, w tym równiez TCP.

UUCP, jako protokół projektowany do współpracy z niezbyt stabilnymi i niepewnymiz natury łaczami telefonicznymi, posiada szerokie mozliwosci poprawiania niezawodnosci

16


przesyłania danych. Do najwazniejszych z nich naleza automatyczny wybór zapasowegosposobu przesłania danych w momencie, gdy podstawowy zawiedzie, czy tez automatycz-ne zestawianie połaczen z systemami, do których przesyłanie danych jest w danej chwiliniezbedne. Równiez format danych wymienianych w protokole w widoczny sposób zapro-jektowany jest do współpracy z łaczami telefonicznymi o niewielkiej predkosci. Ilosci infor-macji przesyłanych miedzy komunikujacymi sie systemami sa mozliwie jak najmniejsze, copierwotnie miało słuzyc uzyskaniu jak najwiekszej predkosci przesyłania danych, z czasemzas zaczeło byc postrzegane równiez jako czynnik zwiekszajacy niezawodnosc transmisji wprotokole UUCP.

Jako, ze protokół UUCP dawał mozliwosc przesyłania dowolnych plików, naturalnymjego zastosowaniem w pewnym momencie stało sie przekazywanie wiadomosci pocztyelektronicznej – takie jego zastosowanie zostało ustandaryzowane w RFC 976 [24]. Był tobardzo efektywny sposób komunikacji miedzy uzytkownikami systemów, które posiadałymozliwosc bezposredniego połaczenia. Problem pojawiał sie jednak w momencie, gdy niebyło znane bezposrednie połaczenie miedzy systemem nadawcy i odbiorcy. W takiej sy-tuacji pojawiała sie koniecznosc przekazania wiadomosci poprzez systemy posredniczace.Pierwsza wada zauwazalna przy takim przesyłaniu poczty była koniecznosc podania expli-cite marszruty wiadomosci, tzn. listy kolejnych systemów przekazujacych, które powinnaona odwiedzic na drodze do adresata. Drugim, nie mniej znaczacym mankamentem byłczas potrzebny, aby transportowana w ten sposób wiadomosc dotarła do celu. W latach 80.XX. wieku długosc listy systemów przekazujacych wiadomosc najczesciej osiagała 8-10 ad-resów. Jesli wziac pod uwage fakt, iz połaczenia miedzy systemami komunikujacymi sie zaposrednictwem linii telefonicznych, ze wzgledu na chec minimalizacji kosztów zestawianebyły tylko raz na dobe, łatwo policzyc, iz czas doreczenia takiej wiadomosci wynosił ponadtydzien – nie rzadko dłuzej niz czas doreczenia listu poczta tradycyjna. Były co prawda po-dejmowane próby, aby czas ten skracac poprzez „przepisywanie” marszruty wiadomosci(tzn. zamiane długich jej elementów na znane krótsze i szybsze połaczenia), jednak nigdynie udało sie w ten sposób osiagnac znaczacego przyspieszenia w transporcie poczty elek-tronicznej. Protokół UUCP, w ten sam sposób, uzywany był równiez w poczatkowej fazierozwoju sieciowych grup dyskusyjnych. Szybko jednak został zastapiony przez NetworkNews Transfer Protocol, oferujacy znacznie szersze mozliwosci i o wiele sprawniejszy spo-sób działania.

Protokół UUCP wprowadził kilka rozwiazan technicznych, które w pózniejszym okre-sie stały sie bardzo popularne w innych, zupełnie z nim nie powiazanych zastosowaniach.Jednym, o którym wspominałem juz wczesniej w niniejszej pracy, jest schemat adresowaniawiadomosci. W UUCP miał on postac „host!user”. Znak „!” został przejety przez twór-ców SMTP i obecnie jest w nim wykorzystywany do wyznaczania marszrut wiadomosciexplicite przez jej nadawce. Notacja ta jest stosowana równiez w protokole NNTP, w któ-rym słuzy ona do przedstawiania trasy, która wiadomosc przebyła w drodze od nadawcydo serwera, z którego pobrał ja odbiorca. Inna cecha UUCP, która przejeta została przez po-pularne współczesnie oprogramowanie, jest format pliku z opisem konwersacji, majacej nacelu przeprowadzenie uwierzytelnienia uzytkownika przy połaczeniu modemowym mie-dzy dwoma systemami komputerowymi – tzw. pliku chat. Jako, ze jest to format bardzoelastyczny i pozwalajacy wykonac wszystkie niezbedne czynnosci, które moga wystapic wtakim procesie, to do dzis jest wykorzystywany przez oprogramowanie przeznaczone dopodobnych celów – na przykład przez program expect.

17


Jedna z przyczyn, dla której siec systemów komputerowych połaczonych poprzez proto-kół UUCP nigdy nie zyskała naprawde szerokiej popularnosci i duzej liczby uzytkowników,jest zestawianie połaczen miedzy systemami poprzez łacza telefoniczne. Poza oczywisty-mi niedogodnosciami zwiazanymi z kosztami oraz niska predkoscia przesyłania danych wtakim rozwiazaniu, duzy problem stanowiło zebranie informacji o systemach, do którychdany wezeł sieci mógł zestawic połaczenie. Były one rozpowszechniane w formie statycznejlisty nazw systemów i ich numerów telefonów, co było rozwiazaniem bardzo niewygod-nym i nieefektywnym. W dalszym etapie rozwoju stworzono specjalne grupy dyskusyjnesłuzace do ich wymiany, a takze oprogramowanie wyznaczajace na ich podstawie optymal-ne sciezki miedzy systemami, jednakze nie zmniejszyło to w sposób znaczacy niewygodytakiego rozwiazania. Przełom przyniosło dopiero przeniesienie transmisji protokołu UUCPna protokół TCP oraz siec Internet.

W chwili obecnej protokół UUCP wykorzystywany jest jedynie w bardzo specyficznychniszach rynkowych, w których jego zalety sa zdecydowanie istotniejsze od licznych wad,które posiada. Pierwszym obszarem, w którym bardzo chetnie jest on stosowany jest ko-munikacja poprzez łacza telefoniczne o bardzo wysokim koszcie połaczenia – na przykładsatelitarne łacza dla cywilnej floty morskiej. W tym przypadku UUCP zapewnia stabilnai wzglednie tania metode przesyłania danych, w tym równiez transportu poczty elektro-nicznej – wykorzystuje sie tutaj jego prostote oraz optymalizacje pod katem łacz telefonicz-nych. Druga znaczaca nisza, w której UUCP znalazł zastosowanie sa korporacyjne łaczamiedzy oddziałami, dla których wymagana jest najwyzsza niezawodnosc z praktycznie sta-ła dostepnoscia. Korzysta sie przy implementacji takich połaczen z protokołu UUCP, dziekijego mozliwosciom wyboru alternatywnego sposobu połaczenia w przypadku, gdy podsta-wowy sposób zawodzi. Zazwyczaj stosowana kombinacja jest transport danych protokołuUUCP poprzez łacza TCP sieci Internet w wersji podstawowej z opcja przełaczenia sie naalternatywna komunikacje po łaczach telefonicznych.

2.1.4. Rozwiazania komercyjne

Powyzej przedstawione zostały rozwiazania stosowane na współczesnym rynku pocztyelektronicznej, które stanowia powszechnie uznane otwarte standardy i moga byc szerokoimplementowane i stosowane bez zadnych ograniczen. W celu uzupełnienia przedstawio-nej analizy nalezy równiez wspomniec o rozwiazaniach dostepnych jedynie w wybranychkomercyjnych produktach. Ponizej pokrótce zaprezentuje dwa najpopularniejsze z nich, sto-sowane współczesnie na rynku transportu poczty elektronicznej – wymieniany juz w ni-niejszej pracy Microsoft Exchange Server, a takze IBM Lotus Domino. Sa to pakiety, któ-rych pozycja na rynku i obszar zastosowan sa bardzo podobne. Jako rozbudowane zestawyoprogramowania o szerokich mozliwosciach, a takze jako produkty firmowane przez zna-ne i uznane firmy tworzace oprogramowanie, sa one wykorzystywane przez bardzo duzaliczbe organizacji na całym swiecie. Ze wzgledu na koszt wdrozenia kazdego z tych pro-duktów, zarówno zwiazany z cena ich zakupu, jak i z pózniejszymi kosztami ewentualnegowsparcia ze strony producenta, do ich uzytkowników naleza jedynie instytucje i firmy o bar-dziej rozbudowanej strukturze organizacyjnej, a wiec równiez duzej liczbie pracowników.Sprawia to, ze mimo, iz ciezko spotkac tego typu rozwiazania w systemach pocztowych, zktórych uzytkownicy sieci Internet na co dzien korzystaja w prywatnej komunikacji miedzy

18


soba, to jednak liczba osób wykorzystujacych produkty firmy IBM czy Microsoft jest bardzoznaczaca – sa to wrecz rozwiazania dominujace na rynku zastosowan korporacyjnych.

Microsoft Exchange Server

Oprogramowanie Exchange Server firmy Microsoft stworzone zostało w 1993 r. jako we-wnetrzny system wymiany wiadomosci wykorzystywany przez firme Microsoft. Poczat-kowo uzywane ono było jedynie dla potrzeb firmy i jej pracowników. Sprzedaz klientomzewnetrznym rozpoczeta została dopiero w 1996 r., kiedy to Microsoft Exchange Server 4.0zaczał byc oferowany jako nastepca oprogramowania Microsoft Mail 3.5. Produkt ten niejest jedynie serwerem poczty elektronicznej, a bardzo rozbudowanym systemem pracy gru-powej, który oprócz przesyłania wiadomosci umozliwia równiez współdzielenie miedzyuzytkownikami kalendarza, kontaktów czy zadan. Kazda z tych funkcji zawiera w sobiebardzo rozbudowane mozliwosci techniczne takie, jak róznorodne formaty przechowywa-nia danych, protokoły ich wymiany z systemami zewnetrznymi, a takze sposoby dostepudo nich przez uzytkowników.

Pod katem rozwiazan zwiazanych z transportem poczty elektronicznej, MicrosoftExchange Server równiez prezentuje duza elastycznosc. Jego modularna budowa zapew-nia mozliwosc wykorzystania praktycznie dowolnego protokołu, który zostanie zaimple-mentowany jako dodatek dla tego systemu. Standardowo producent oferuje współpraceze wszystkimi protokołami dostepnymi na rynku poczty elektronicznej takimi, jak STMP,X.400 czy tez protokół wykorzystywany przez IBM Lotus Domino. Warto jednak zauwazyc,iz sama wymiana wiadomosci wewnatrz systemu opartego o Microsoft Exchange Serverprzebiega bez uzycia zadnego z nich – oparta jest ona o wewnetrzne rozwiazania firmyMicrosoft, zwane Microsoft Mail i bazujace na protokole Server Message Block, znanymgłównie ze współdzielenia plików miedzy komputerami pracujacymi pod kontrola syste-mu Microsoft Windows.

IBM Lotus Domino

System IBM Lotus Domino jest, pod wzgledem ogólnej budowy, oprogramowaniem bardzopodobnym do Microsoft Exchange Server. Jest to równiez zestaw oprogramowania wspiera-jacego prace grupowa uzytkowników biznesowych. Oprócz wymiany wiadomosci elektro-nicznych, współdzielenia kalendarzy i kontaktów, oferuje równiez serwer aplikacyjny, którypozwala organizacjom wykorzystujacym te platforme na budowanie własnych rozwiazan znia zintegrowanych.

Jesli chodzi o rozwiazania specyficzne dla transportu poczty elektronicznej, to mozliwo-sci dostarczane przez producenta sa w przypadku produktu firmy IBM nieco ubozsze, nizto miało miejsce w Microsoft Exchange Server. Nie spotkamy tutaj bowiem wsparcia dlaprotokołów mniej popularnych, jak X.400 czy wewnetrzne protokoły konkurencyjnych ko-mercyjnych rozwiazan pocztowych. Dostepna jest za to, niezbedna wrecz na współczesnymrynku transportu poczty elektronicznej, obsługa SMTP, a takze wewnetrzny, specyficzny dlaplatformy IBM Lotus Domino, protokół wymiany wiadomosci.

19


2.2. Znane problemy zwiazane z transportem poczty elektronicz-nej

Współczesny rynek poczty elektronicznej, jak to zostało juz opisane wczesniej w niniejszejpracy, jest bardzo silnie rozwiniety. Konsekwencja tego faktu jest jego znaczace zróznico-wanie – poczta elektroniczna w dzisiejszym swiecie wykorzystywana jest przez osoby zewszelkich mozliwych srodowisk społecznych, zawodowych, osoby o róznych zaintereso-waniach, pogladach itp. Ze wzgledu na publiczna dostepnosc sieci Internet, a takze pocztyelektronicznej, uzytkowanie tych technologii jest niczym nieograniczone, a wiec mozliwepraktycznie dla kazdego. Taka róznorodnosc wsród uzytkowników jest jedna z najbardziejcenionych cech sieci Internet, gdyz stwarza ona wiele nowych sposobów komunikacji i kon-taktu miedzy ludzmi. Niestety, nie zawsze duza liczba i duze zróznicowanie uzytkownikówmoze byc uwazane za zalete. Powszechny dostep do poczty elektronicznej umozliwia bez-problemowe korzystanie z niej równiez osobom, które nie maja na celu jedynie komunikacjiz innymi jej uzytkownikami, a przynajmniej nie w powszechnie uznanym tego sformuło-wania znaczeniu. Podczas rozwoju poczty elektronicznej dało sie zaobserwowac tenden-cje, która zdaje sie byc naturalna i zauwazalna w wiekszosci dziedzin aktywnosci ludzkiej:czesc osób postanowiła skorzystac z mozliwosci, jakie wymiana elektronicznych wiadomo-sci pocztowych daje, dla własnych, egoistycznych celów, mniej lub bardziej celowo koszteminnych jej uzytkowników.

Czesciowo rosnaca liczbe problemów zauwazalnych przy korzystaniu z poczty elektro-nicznej wyjasnic mozna stale rosnaca liczba jej uzytkowników, a co za tym idzie – równieztych, którzy z poczty elektronicznej korzystaja w sposób nie do konca zgodny z zasadamipowszechnie uznanymi za obowiazujace w sieci Internet. Warto jednak zastanowic sie nadprzyczyna tego, ze w ogóle naduzycia na rynku poczty elektronicznej zaczeły sie pojawiac.Z pewnoscia po czesci było to spowodowane otwartoscia srodowiska osób zwiazanych ztworzeniem i rozwojem usług pocztowych w przeszłosci. Pierwotnie było to srodowiskogłównie akademickie oraz naukowe, które z natury odznacza sie wzajemnym zaufaniem.Cecha ta została szybko zauwazona przez osoby o zamiarach niezbyt godnych pochwałyi bardzo skrzetnie przez nich wykorzystana. Srodowisko co prawda potrafiło sie bardzoszybko przystosowac i otwartosc zamieniono na ochrone przed naduzyciami, jednak trendwykorzystywania poczty elektronicznej w sposób, którego pierwotnie nikt nie planował,pozostał i ma wielu przedstawicieli az po dzien dzisiejszy.

Inna przyczyna wykorzystywania poczty elektronicznej do nagannych celów jest mozli-wosc czerpania z niej komercyjnych, wymiernych korzysci. W momencie, kiedy dostrzezo-no mozliwosci wykorzystania poczty elektronicznej do celów zarobkowych (bezposredniolub posrednio), pojawiły sie osoby, które nie tylko postanowiły sie wzbogacic przy jej wyko-rzystaniu, ale równiez za wszelka cene zmaksymalizowac czerpane z niej zyski. Zachecałaich do tego zwłaszcza bezpłatnosc i powszechna dostepnosc tego medium komunikacji,czyli bardzo niskie koszty prowadzace do uzyskania zamierzonych korzysci. Rynek pocztyelektronicznej został zatem zaatakowany przez marketingowców i „specjalistów” od rekla-my, którzy gotowi byli zrobic wszystko, aby dotrzec do jak najszerszego grona odbiorców,włacznie z łamaniem podstawowych zasad w sieci Internet obowiazujacych. Nie zyskali onisympatii wsród pozostałych uzytkowników poczty elektronicznej ani wsród administrato-rów serwerów pocztowych i zaczeli byc obrazliwie nazywani „marketoidami”.

20


Do najwazniejszych problemów zwiazanych z transportem poczty elektronicznej wy-stepujacych na współczesnym rynku zaliczyc nalezy takie zjawiska, jak masowo wysyła-ne niechciane wiadomosci (tzw. spam) czy tez duze problemy z jednoznaczna identyfikacjanadawcy. W sposób bardziej szczegółowy zostana one opisane ponizej. Oprócz nich istnie-ja równiez inne niedogodnosci powiazane z transportem poczty elektronicznej. Sa one dlawiekszosci uzytkowników mniej zauwazalne, gdyz ich natura jest bardziej techniczna, awiec dotykaja one głównie administratorów serwerów pocztowych czy tez osoby zajmuja-ce sie rozwojem oprogramowania przeznaczonego do obsługi poczty elektronicznej. Mowatutaj o takich kwestiach, jak trudnosci w konstruowaniu i wyznaczaniu skomplikowanychmarszrut wiadomosci, mało rozbudowane adresowanie stosowane zgodnie ze standardemopisanym w RFC 2822 [25], przesyłanie załaczników jako integralnych czesci wiadomosciczy tez inne, mniej popularne. Zostana one, w róznym stopniu, poruszone w dalszych cze-sciach niniejszej pracy.

2.2.1. Spam

Spam to popularna nazwa na jeden z najbardziej powaznych problemów widocznychna rynku współczesnej poczty elektronicznej. Nie istnieje jednoznaczna definicja spamu– byc moze ze wzgledu na duzy stopien skompilowania tego zjawiska, czy tez moze zewzgledu na to, ze przez róznych uzytkowników poczty elektronicznej nie jest on odbieranyjednakowo. Dla potrzeb niniejszej pracy chciałbym zaproponowac nastepujaca definicjerobocza:

Spam — masowo rozsyłana korespondencja, której odbiorca nie zamawiał ani która nie jestskierowana do niego osobiscie

Jestem jednak swiadom, iz definicja ta nie jest pełna, ze nie wszystkie osoby zwiaza-ne z poczta elektroniczna beda w stanie sie z taka definicja zgodzic. Praktycznie jedynakwestia, w której wszyscy uzytkownicy poczty elektronicznej, definiujac spam, sa zgodni,jest fakt, iz nazywac w ten sposób nalezy wiadomosci, których odbiorca nie zyczył sobieotrzymac. Jednak juz w tym momencie nalezy zastanowic sie, czy ten element definicji jesttaki oczywisty, jak sie wydaje. Moja definicja zawiera dodatkowa klauzule, która stanowizabezpieczenie przed nazywaniem spamem wiadomosci, które sa wyraznie adresowanedo odbiorcy i zawieraja specyficzna dla niego tresc, jednakze z pewnych wzgledów nieprzypadły mu do gustu. Pierwszym aspektem podanej przeze mnie definicji, który mozebyc dyskusyjny, jest masowosc rozsyłanej korespondencji. Główna watpliwoscia, którapojawia sie w tym momencie, jest wyznaczenie wartosci granicznej, przy której rozsyłanapoczte uznaje sie za masowa. Oczywiscie nie istnieje uniwersalna wartosc progowa;decyzje o masowosci nalezy podejmowac odrebnie dla kazdego przypadku, co sprawia,iz jest to bardzo subiektywne kryterium. Inna kwestia, czesto podnoszona przy definio-waniu spamu, jest chec ograniczenia przez niektórych tej definicji tylko do wiadomoscio charakterze komercyjnym, czyli głównie róznego rodzaju reklam. Takie ograniczeniezostało wprowadzone w polskim prawodawstwie w Ustawie o Swiadczeniu Usług DrogaElektroniczna. Miała ona pierwotnie wprowadzic podstawy prawne do karania osóbrozsyłajacych spam, jednakze przewiduje jedynie kary (nota bene bardzo niskie) dla osóbrozsyłajacych Niezamówiona Informacje Handlowa, która, w oczywisty sposób, nie jesttym samym, co spam. Subiektywnosc, która jest widoczna podczas tworzenia definicji

21


spamu, przez niektórych właczana jest do tej definicji jako główny jej składnik. Twierdzaoni, iz spam to „kazda korespondencja, która odbiorca uzna za spam”. Moim zdaniem takadefinicja jest nieuprawniona, gdyz pozwala na wiele naduzyc, przed którymi w mojejdefinicji zabezpieczenie stanowi ostatnia jej czesc.

Poczatki spamu opisałem juz w niniejszej pracy, w rozdziale 1. poswieconym historiipoczty elektronicznej. Od czasu pierwszego spamu, który wysłany został w 1971 r., nasta-pił bardzo znaczacy rozwój nie tylko rynku poczty elektronicznej, ale równiez działalnosciosób zwiazanych z rozsyłaniem niechcianych wiadomosci [26]. W chwili obecnej niechcianewiadomosci stanowia przytłaczajaca wiekszosc ruchu pocztowego w sieci Internet. Poda-nie konkretnej statystyki dotyczacej odsetku wiadomosci uznawanych za spam jest dosyctrudne. Z danych dostepnych w róznych zródłach wynika, iz jest to od około 70% az doponad 95%. Przyczyna tak szerokiego przedziału miedzy podawanymi statystykami jest,moim zdaniem, problem z opracowaniem spójnej i z duzym prawdopodobienstwem po-prawnej metodyki słuzacej prowadzeniu badan nad skala zjawiska spamu. Według mnie,najbardziej wiarygodnymi danymi sa te, które zbierane sa przez same serwery pocztowe ztym zjawiskiem walczace. Jedno z ich zródeł, projekt Distributed Checksum Clearinghouse,podaje statystyki [27] zblizajace sie własnie do 70%. Wielkosc ta oznacza ok. 300 000 000 nie-chcianych wiadomosci, które kazdego dnia trafiaja do skrzynek pocztowych uzytkownikówsieci Internet. Dla statystycznego uzytkownika poczty elektronicznej oznacza to próbe do-reczenia do niego blisko czterystu wiadomosci, których otrzymania by on sobie nie zyczył.Liczba ta jest efektem rozpowszechnienia poczty elektronicznej we współczesnym swie-cie – podczas jej rozwoju, ilosc niechcianych wiadomosci rosła praktycznie liniowo wrazze wzrostem ogólnego ruchu pocztowego. Współczesnie obserwuje sie swego rodzaju na-sycenie rynku spamu – mimo dalszego wzrostu ogólnej liczby przesyłanych wiadomoscipoczty elektronicznej, wolumin spamu od pewnego czasu pozostaje na – w przyblizeniu –stałym poziomie. Jezeli taka tendencja utrzyma sie, to byc moze mozna traktowac ja jakozapowiedz zmniejszenia znaczenia problemu spamu w przyszłosci. Istotnym problemem, zktórym borykaja sie osoby badajace zjawisko niechcianej poczty elektronicznej, jest fakt je-go wykrywalnosci. Wszelkie statystyki moga byc tworzone tylko pod warunkiem istnieniaskutecznych metod pozwalajacych wykrywac spam, to znaczy, skutecznie odrózniac go odpozostałej czesci ruchu pocztowego. W chwili obecnej jednak nie istnieja metody skutecznew 100%, choc skutecznosc wykorzystywanych metod jest bardzo wysoka. Srednio serwe-ry pocztowe potrafia wykryc ponad 90% niechcianych wiadomosci pocztowych, a istniejanawet metody (chocby opisane w [26]) zwiekszajace ten odsetek az do poziomu 99.85%.

Mimo tak ogromnej liczby wysyłanych niechcianych wiadomosci, liczba osób taka wy-syłka sie zajmujacych nie jest tak duza, jak by sie mozna spodziewac. Zdecydowana wiek-szosc z tych wiadomosci rozsyłana jest przez mniej niz 200 osób (tzw. spammerów). Nieoznacza to bynajmniej, ze liczba komputerów rozsyłajacych spam jest tak niska. Kazda ztych osób dysponuje ogromna liczba maszyn, które moze kontrolowac w celu wysyłaniawiadomosci – sa to tzw. botnety, czyli farmy komputerów-zombie, nad którymi ich prawo-wici uzytkownicy stracili kontrole w wyniku zarazenia złosliwym oprogramowaniem. Takisposób wysyłki sprawia, iz walka ze spamem jest bardzo trudna, gdyz bardzo czesto, prak-tycznie na biezaco, zmienia sie jego zródło. Jedyne, co pozostaje stałe, to lista krajów przo-dujacych w wysyłce niechcianych wiadomosci. Oczywiscie, mozna na niej znalezc panstwao najbardziej rozpowszechnionym dostepie do poczty elektronicznej, jak USA, ale równiezpanstwa, w których brak jest zainteresowania ze strony władz sciganiem naruszen zasadkorzystania z sieci Internet, takie, jak Rosja, Chiny czy Brazylia. Na tej niechlubnej liscie

22


wysokie miejsce zajmuje równiez Polska, która moze „pochwalic sie” najdłuzej działajacymbotnetem w historii sieci Internet.

Interesujacym problemem moze byc zagadnienie zdobywania przez osoby rozsyłajaceniechciane wiadomosci adresów swoich „ofiar”. Poczatkowo stanowiło to nielada wyzwa-nie, gdyz pozyskanie prawdziwego, uzywanego adresu poczty elektronicznej nie było pro-ste. Jednakze problemowosc tego zagadnienia nie zniecheciła spammerów, a wrecz prze-ciwnie – jedynie zacheciła ich do stworzenia mnogosci technik problem ten rozwiazujacych.Najpopularniejsza z nich jest tworzenie systemów automatycznie przegladajacych losowestrony WWW i zbierajacych adresy na nich wystepujace – tzw. harvesterów. Dzieki rozwo-jowi róznych dziedzin informatyki, współczesnie oprogramowanie tego typu tworzone jestw sposób bardzo efektywny i pozwala uzyskac duza skutecznosc i szybkosc działania. Zczasem pole działania harvesterów zostało znacznie rozszerzone – w chwili obecnej nieprzegladaja one jedynie stron WWW, ale takze Usenet, bazy danych WHOIS itp. Innymsposobem jest generowanie losowych adresów pocztowych, a nastepnie weryfikacja ich po-prawnosci w praktyce. Generowane sa one w bardzo zróznicowany sposób: na podstawiesłowników, całkowicie losowo, na podstawie pewnych danych dostepnych w sieci Inter-net itp. Istotna cecha wspólna tych metod jest fakt, iz losowaniu podlega jedynie nazwauzytkownika – czesc domenowa jest najczesciej zdobywana inna metoda, na przykład przypomocy harvesterów.

Wazna kwestia dotyczaca rozsyłania niechcianej poczty elektronicznej jest zagadnienieopłacalnosci tego procederu. Wiele osób zadaje sobie pytanie jakie szczególne cechy posia-da własnie ten sposób dotarcia do odbiorcy, które sprawiaja, ze jest on tak znaczaco bardziejpopularny niz na przykład niechciana korespondencja w poczcie tradycyjnej czy tez nie-chciane wiadomosci wysyłane droga faksowa. Otóz kluczowa kwestia sa tutaj koszty pono-szone przez nadawce wiadomosci, które w dobie powszechnego, taniego dostepu do sieciInternet oraz wobec bardzo szerokiej dostepnosci oprogramowania do zarzadzania pocz-ta elektroniczna, sa bardzo znikome. Tym bardziej obnizaja je techniki wykorzystywane wrozsyłaniu spamu takie, jak nadawanie wiadomosci za pomoca botnetów czy zdobywanieadresów za pomoca harvesterów, które zostały juz opisane powyzej.

Współczesnie rozsyłanie niechcianej korespondencji jest procederem bardzo nieprzy-chylnie ocenianym przez zdecydowana wiekszosc uzytkowników sieci Internet. Mimo to,aktywnosc osób parajacych sie tym zajeciem nie ustaje. Dlaczego tak sie dzieje? Otóz pa-radoksalnie, mimo niepochlebnej opinii o spammerach, wielu uzytkowników poczty elek-tronicznej okazuje sie byc podatnymi na zostanie „ofiara” spamu, czyli na przykład na ku-pienie reklamowanych w nim produktów. Sprawia to, ze opłacalnosc rozsyłania spamu jestnadal wysoka. Co wiecej, chec czerpania z niego zysków dotyczy nie tylko samych osóbrozsyłajacych niechciane wiadomosci. Równiez niektóre firmy swiadczace usługi interne-towe, w sposób posredni zarabiaja na tym procederze poprzez wspieranie spammerów –sprzedajac im konta pocztowe słuzace do rozsyłania spamu, umieszczajac witryny WWWreklamowane w rozsyłanej przez nich korespondencji na swoich serwerach itp. Działalnosctaka nazywamy bullet-proof hosting, gdyz w przeciwienstwie do klientów wiekszosci pozo-stałych dostawców usług internetowych, osoby bedace klientami opisywanych tu firm, niemusza sie obawiac utraty konta w skutek złamania zasad panujacych w sieci Internet.

Niechciane wiadomosci pocztowe rozsyłane w sieci Internet mozna podzielic na kilkarodzajów, ze wzgledu na rodzaj tresci, które zawieraja. Jak juz wspomniałem wczesniej,

23


pierwsza niechciana, masowo rozesłana wiadomosc miała charakter społeczno-polityczny.Współczesnie jednak szacuje sie, ze tego typu spam stanowi ponizej 3% całkowitej licz-by rozsyłanych niechcianych wiadomosci. Dominuja zas wiadomosci typowo komercyjne– reklamy konkretnych produktów czy usług (głównie finansowych) szacuje sie razem naokoło 45% całego woluminu spamu przesyłanego w sieci Internet. Co ciekawe, uzytkowni-cy twierdza, ze to nie tego rodzaju wiadomosci najbardziej irytuja ich w momencie, kiedydostaja sie do ich skrzynek odbiorczych. Najmniej tolerowany typ spamu stanowia wiado-mosci zawierajace tresci erotyczne, a czesciej wrecz pornograficzne – moze sie to wydawaco tyle zrozumiałe, ze do reklamy, nawet bardzo nachalnej, ludzie w zyciu codziennym przy-zwyczajani sa od bardzo dawna.

2.2.2. Identyfikacja nadawcy wiadomosci

Innym, nie mniej powaznym, choc o wiele rzadziej zauwazanym problemem, który obec-ny jest na współczesnym rynku usług zwiazanych z poczta elektroniczna, jest zagadnieniemozliwosci identyfikacji nadawcy wiadomosci. Chodzi tutaj o identyfikacje osoby, firmyczy tez instytucji, która wysłała dana wiadomosc, na przykład w celu ułatwienia weryfi-kacji autentycznosci informacji w niej zawartych. Brak takiej identyfikacji powoduje wieleproblemów przy korzystaniu z poczty elektronicznej. Najbardziej istotne z nich postaramsie zaprezentowac ponizej.

Pierwszym, bardzo istotnym zagrozeniem, przed którym postawiony zostaje uzytkow-nik poczty elektronicznej w sytuacji, w której nie jest w stanie zweryfikowac tozsamoscinadawcy wiadomosci, jest mozliwosc oszustwa – sfałszowania informacji adresowych ipodpisu wiadomosci tak, aby wygladała ona na nadana przez kogos innego. W małej ska-li proceder taki moze byc niegrozny, a z niektórych punktów widzenia nawet zabawny –sytuacja taka ma miejsce na przykład wtedy, gdy podszywanie sie pod innego nadawcewykorzystywane jest przez nastolatków „tak dla zartu”. Niestety nie jest to jedyna grupakorzystajaca z takich mozliwosci. Najwiecej fałszerstw informacji adresowych zawartych wwiadomosciach poczty elektronicznej słuzy oszustwom majacym konsekwencje finansowe.Chodzi tu przede wszystkim o wyłudzenia róznego rodzaju danych identyfikacyjnych, po-zwalajace nastepnie przestepcom na uzyskanie dostepu na przykład do konta bankowegoczy karty płatniczej ofiary. Proceder taki nazywany jest phishing. Istnieja takze inne rodzajewyłudzen zwiazanych z podszywaniem sie pod osoby trzecie – wiekszosc z nich tworzonajest w oparciu o schemat polegajacy na obiecaniu odbiorcy duzych zysków (na przykładwysokiej wygranej czy dobrze płatnej pracy) pod warunkiem zainwestowania pewnej kwo-ty na poczatku. Co prawda do tworzenia tego typu oszustw nie jest konieczne fałszowanietozsamosci nadawcy wiadomosci, jednakze taki zabieg potrafi zdecydowanie zwiekszyc po-zorna wiarygodnosc listu, a co za tym idzie – równiez jego skutecznosc. Warto zauwazyc,iz problem ten bezposrednio łaczy sie z problemem rozsyłania niechcianej korespondencji.Po pierwsze korespondencja majaca na celu wyłudzenie pieniedzy nie moze byc uznanaza pozadana, a po drugie techniki rozsyłania takich wiadomosci sa identyczne, jak technikirozsyłania spamu.

Innym zastosowaniem, które zostało znalezione dla mozliwosci sfałszowania danychsugerujacych tozsamosc nadawcy wiadomosci, sa działania nieuczciwej konkurencji mie-dzy firmami. Równiez one wykorzystuja techniki stworzone i rozwijane przez spammerów,

24


jednak w dosc odmienny sposób. Mianowicie firma, która chce zaszkodzic swojej konkuren-cji, rozsyła (czy tez czesciej – zleca rozesłanie) duza liczbe niechcianych wiadomosci, któreidentyfikowane sa danymi firmy konkurencyjnej, a najczesciej równiez wprost reklamuja jejprodukty. Przy takiej wysyłce najczesciej dba sie o to, aby wiadomosci te dotarły główniedo aktualnych klientów naszej konkurencji, a takze do srodowisk zagorzałych przeciwni-ków spamu. Wykorzystana tutaj zostaje powszechna niechec do spammerów, która pozwa-la oczernic konkurencje, a co za tym idzie – byc moze niewielkim kosztem przejac czesc jejzysków.

Brak mozliwosci weryfikacji tozsamosci nadawcy wiadomosci wykorzystany zostałprzez twórców wirusów, robaków i innego typu złosliwego oprogramowania. Czesc z tegotypu programów do rozprzestrzeniania sie wykorzystuje poczte elektroniczna. Aby łatwiejprzekonac uzytkowników do uruchomienia i zainstalowania danego oprogramowania wsystemie operacyjnym, wiadomosci zawierajace to oprogramowanie tworzone sa tak, abywygladały, jak pochodzace od krewnych badz znajomych ofiary. W ten sposób ich autorzyzapewniaja sobie bardzo wysoka skutecznosc, a co za tym idzie – szybkosc rozpowszech-niania. Jesli zauwazyc, ze celem zainstalowania złosliwego oprogramowania na kompute-rze docelowym jest dalsze wykorzystanie go jako na przykład czesci botnetu rozsyłajacegospam, to mozna łatwo wyciagnac wniosek, iz jest to kolejny sposób na wykorzystanie pro-blemów z weryfikacja tozsamosci nadawcy wiadomosci do uzyskania wymiernych korzyscifinansowych. Dodatkowo jednym z typów złosliwego oprogramowania, które moze w tensposób zostac zainstalowane w systemie ofiary, sa narzedzia umozliwiajace zdalny dostepdo jej komputera. Takze dzieki nim mozna uzyskac róznego rodzaju dane pozwalajace na-stepnie skuteczniej fałszowac jej tozsamosc – zarówno w procederze rozsyłania elektronicz-nych wiadomosci pocztowych ze sfałszowanymi danymi nadawcy, jak równiez (co stanowio wiele powazniejsze zagrozenie) na przykład w kontaktach z bankami, innymi instytucja-mi finansowymi itp.

Jednakze fałszowanie danych nadawcy wiadomosci moze stanowic dla ofiar takiej dzia-łalnosci zagrozenie nie tylko z finansowego punktu widzenia. Proceder tak zwanej „kradzie-zy tozsamosci” moze miec równiez ogromne znaczenie w sensie społecznym. Nie stanowibowiem problemu stworzenie wiadomosci o zmienionych danych nadawcy, której tresc be-dzie nastepnie wykorzystana w celu zdyskredytowania w pewien sposób osoby, pod któranadawca sie podszywa. Nie prowadzi go to co prawda do uzyskania korzysci materialnych,jednak moze zapewnic mu zyski na polu na przykład towarzyskim, które niejednokrotniemoga byc o wiele cenniejsze.

Pozostałe problemy zwiazane z poczta elektroniczna

Przedstawione powyzej zagadnienia nie sa oczywiscie jedynymi problemami, z którymi bo-ryka sie współczesny rynek poczty elektronicznej. W mojej ocenie sa to jednak zagrozenianajwazniejsze z punktu widzenia uzytkownika usług pocztowych, osoby, która wykorzy-stuje je w codziennym zyciu – czy to zawodowym, czy tez prywatnym. Istnieje jednak wieledalszych problemów, które obserwuje sie w zwiazku z transportem poczty elektronicznejwe współczesnych sieciach komputerowych. Jednakze wiekszosc z nich dotyka głównieosób zajmujacych sie strona administracyjna, organizacyjna czy tez rozwojem oprogramo-wania słuzacego do obsługi poczty elektronicznej. Niektóre z nich zostana w wiekszych

25


szczegółach omówione w dalszej czesci niniejszej pracy. W tym miejscu chciałbym jedyniezasygnalizowac ich istnienie. Najbardziej zauwazalnymi wsród tych problemów sa kłopotyz wyznaczaniem marszruty wiadomosci, a takze, co jest z poprzednim powiazane, efek-tywnym ich adresowaniem. Równie problematyczny jest fakt praktycznego braku obsługizałaczników w protokole SMTP – musza one byc w chwili obecnej przesyłane jako integral-ne czesci wiadomosci, co nie jest rozwiazaniem wygodnym, ani tym bardziej – funkcjonal-nym. Istnieja równiez inne, pomniejsze problemy, których przyczyna sa cechy współczesne-go rynku usług pocztowych i wykorzystywanych na nim protokołów, jednakze sa one albolokalne dla pewnych srodowisk, albo wystepuja jedynie w specyficznych sytuacjach i, jakotakie, nie beda przedmiotem rozwazan w niniejszej pracy.

2.3. Sposoby rozwiazywania przedstawionych problemów

Liczba zagrozen i problemów wystepujacych na rynku poczty elektronicznej stale rosnie.Istniejace zagrozenia staja sie z czasem coraz bardziej problematyczne, gdyz zjawiska z ni-mi zwiazane ulegaja ciagłemu nasilaniu sie. Nie oznacza to jednak, ze uzytkownicy pocztyelektronicznej, a takze administratorzy usług pocztowych czy osoby w inny sposób zwiaza-ne z jej rozwojem, skazane sa na bierna obserwacje degradacji jakosci i wygody korzystaniaz mozliwosci omawianego rynku. Podejmowane sa bardzo aktywne i zakrojone na szerokaskale działania majace na celu minimalizacje konsekwencji, które wynikaja z problemówzwiazanych z transportem i wymiana poczty elektronicznej we współczesnych sieciachkomputerowych, a co za tym idzie – utrzymania pełnej uzytecznosci usług pocztowych,która oferowały one od powstania pierwszych systemów wymiany poczty elektronicznej.Koncentruja sie one wokół dwóch najbardziej istotnych zagadnien przedstawionych powy-zej: problemu masowo rozsyłanych niechcianych wiadomosci oraz zagrozen zwiazanychz brakiem mozliwosci jednoznacznej identyfikacji nadawcy wiadomosci. Ponizej postaramsie omówic najbardziej popularne z metod stosowanych w ramach obrony rynku pocztyelektronicznej przed skutkami tych dwóch zjawisk. Przedstawie stosowane sposoby, a tak-ze zaprezentuje ich znaczenie i skutecznosc w walce z omawianymi problemami oraz oceneich wpływu na kształt dzisiejszego rynku zwiazanego z poczta elektroniczna.

2.3.1. Minimalizacja problemu niepozadanej korespondencji

Polem najbardziej aktywnych działan wsród osób dazacych do zachowania uzyteczno-sci poczty elektronicznej jest walka z masowo rozsyłanymi niechcianymi wiadomosciami.Praktycznie wszystkie działania na tym polu skupiaja sie wokół jednego, najbardziej pod-stawowego zagadnienia: automatycznego odrózniania spamu od pozadanych wiadomosci.Zadanie to realizuja współczesnie bardzo zaawansowane i bardzo rozbudowane systemyklasyfikujace wiadomosci w sposób w pełni automatyczny. Dzieki nim mozliwe jest nato-miast tworzenie filtrów, których zadaniem jest ochrona uzytkowników koncowych przedniechcianymi wiadomosciami pocztowymi. Filtry takie sa obecnie bardzo popularne – róz-ne ich wersje i konfiguracje umieszczane sa na zdecydowanej wiekszosci serwerów poczty

26


elektronicznej, a takze w wielu klientach usług pocztowych uzywanych przez uzytkowni-ków koncowych. To własnie róznego rodzaju metodom klasyfikacji wiadomosci poswieco-na bedzie głównie niniejsza czesc mojej pracy.

Filtrowanie na podstawie danych nadawcy wiadomosci

Najprostszym, a takze historycznie pierwszym, wielokrotnie opisywanym [28], podejsciemdo klasyfikacji wiadomosci było odróznianie pozadanych wiadomosci od tych niepozada-nych na podstawie list nadawców, którzy znani sa z rozsyłania spamu. Adresy, które do-dawane były do tego typu list w poczatkowej fazie ich powstawania były adresami pocz-towymi nadawców. W niedługim jednak czasie osoby rozsyłajace niechciana koresponden-cje nauczyły sie omijac tego typu zabezpieczenia poprzez losowe generowanie adresów, zktórymi wysyłane były tworzone przez nich wiadomosci. W poczatkowym okresie losowa-na była nazwa uzytkownika, a czesc domenowa pozostawała niezmienna. Szybko jednakdoprowadziło to do sytuacji, w której na listach zablokowanych nadawców pojawiac za-czeły sie całe domeny. W obliczu takiej zmiany równiez spammerzy musieli udoskonalicstosowane przez siebie techniki – losowaniu zaczeły podlegac równiez czesci domenoweadresów pocztowych. Poczatkowo losowanie to zawezone było do kilku-kilkunastu domen,które były w posiadaniu nadawcy wiadomosci, jednakze z czasem zostało rozszerzone rów-niez o nieistniejace domeny, których nazwy powstawały w całkowicie losowy sposób. Takirozwój sytuacji doprowadził administratorów do koniecznosci podjecia bardziej drastycz-nych metod walki z osobami rozsyłajacymi spam. Rozpoczeto blokowanie całych serwerów,z których niechciane wiadomosci byy wysyłane poprzez zablokowanie połaczen przycho-dzacych z ich adresu IP. Pierwsze zastosowania tej techniki wywołały wielkie oburzenie wsrodowisku administratorów serwerów poczty elektronicznej – niesprawiedliwe wydawa-ło sie „karanie” wszystkich uzytkowników danego serwera za nieprawidłowe zachowaniejednego z nich. Jednakze w pózniejszym okresie stało sie to praktyka w pełni akceptowana.Mozna podac dwa proste argumenty, zgodnie z którymi taka „odpowiedzialnosc zbioro-wa” de facto ma pozytywne skutki dla wszystkich, z uzytkownikami i administratoramizablokowanego serwera włacznie. Po pierwsze, wiekszosc blokowanych adresów IP tak na-prawde nie nalezy do komputerów bedacych faktycznymi serwerami poczty elektronicznej– najczesciej naleza one do komputerów typu zombie, które sa czescia botnetów, z którychw normalnych warunkach nie powinna byc bezposrednio rozsyłana korespondencja, a wieczablokowanie takiej maszyny nie szkodzi nikomu. Po drugie, jezeli jednak dany adres IPfaktycznie nalezy do serwera poczty elektronicznej, to oznacza to, iz jednym z uzytkowni-ków serwera jest spammer. Zatem zablokowanie takiego serwera powinno byc przez jegoadministratorów potraktowane jako ostrzezenie, informacja o tym, ze cos niepozadanegodzieje sie w ich systemie, co umkneło ich uwadze, a wiec równiez jako mozliwosc usunie-cia problematycznego uzytkownika, czyli w efekcie poprawienia jakosci usług swiadczo-nych na rzecz pozostałych osób korzystajacych z tego serwera. Takie podejscie srodowiskaosób walczacych z zalewem niechcianej korespondencji spowodowało bardzo szybko eska-lacje zjawiska blokowania adresów IP – zaczeto blokowac całe ich zakresy, a nawet podsiecinalezace do konkretnych dostawców usług internetowych. Uznano bowiem, ze w ten spo-sób mozna walczyc z botnetami – poprzez zwracanie uwagi dostawców na niepozadanaaktywnosc, która ma miejsce w ich sieciach, a tym samym zmuszanie ich do podjecia kro-ków majacych na celu ukrócenie tego procederu. O ile blokowanie pojedynczych nadawców

27


czy pojedynczych adresów maszyn bedacych zródłami niechcianych wiadomosci było po-wszechnie akceptowalne, o tyle rozszerzanie blokad na całe podsieci nawet obecnie, przytak ogromnym nasileniu sie zjawiska spamu, jest mocno dyskusyjne. Stosowanie zbiorowejodpowiedzialnosci zakrojonej na tak szeroka skale sprawia, ze równiez zupełnie niewinneosoby moga ucierpiec – na przykład w momencie, gdy ich serwer usług pocztowych znaj-dzie sie przez przypadek w tej samej sieci, co zródło spamu. Mimo to, wielu administrato-rów decyduje sie na wykorzystywanie tak agresywnych metod – pozwalaja one znaczacozmniejszyc liczbe niechcianych wiadomosci, która dociera do uzytkowników koncowych,co czesto jest celem o wiele istotniejszym niz niezablokowanie jednego czy kilku mniejszychserwerów pocztowych.

W poczatkowej fazie rozwoju niechcianej korespondencji listy zablokowanych nadaw-ców tworzone były w sposób statyczny – administrator kazdego serwera pocztowego budo-wał własna liste i zarzadzał nia. Szybko jednak zauwazono, iz w ten sposób kazdy z admi-nistratorów musi wykonac prace, która byc moze inni wykonali juz wczesniej. Niemozliwerówniez było, przy takim rozwiazaniu, zatrzymanie korespondencji pochodzacej ze zródła,z którego dany serwer nie otrzymywał niechcianych wiadomosci wczesniej. Aby wyelimi-nowac te wady i niedogodnosci postanowiono wymieniac listy tworzone przez kazdegoz administratorów miedzy róznymi serwerami. Do takiej wymiany uzywano na poczatkustron WWW czy tez grup dyskusyjnych sieci Usenet. Jednak wraz z coraz bardziej gwałtow-nym wzrostem liczby komputerów rozsyłajacych niechciane wiadomosci, a co za tym idzie– równiez liczby wpisów na listach zablokowanych nadawców, coraz bardziej niezbednezaczeło byc stworzenie w pełni automatycznego systemu, który pozwalałby administrato-rom na wdrozenie blokowania niechcianych wiadomosci bez podejmowania wysiłku zwia-zanego z ciagła aktualizacja statycznych list. Odpowiedzia na takie potrzeby okazało siebyc stworzenie mechanizmu zwanego DNS Blacklist. Załozeniem przyswiecajacym jegoautorom była chec stworzenia technologii, która umozliwiłaby powstanie niewielkiej licz-by centralnych serwerów przechowujacych listy znanych zródeł niechcianej koresponden-cji, które to serwery mogłyby byc nastepnie odpytywane przez systemy transportu pocztyelektronicznej z całego swiata. Jedna z najwazniejszych ich cech miała byc mozliwosc od-pytywania serwerów DNSBL w czasie rzeczywistym, czyli w momencie, w którym podej-mowana jest decyzja czy dana wiadomosc pocztowa nalezy przyjac, czy odrzucic. Wobectakich załozen, oczywistym stało sie wymaganie, aby cały ruch sieciowy, który przez ko-rzystanie z DNSBL jest generowany, był jak najmniejszy, a takze, aby komunikacja miedzysystemem pocztowym a serwerem DNSBL przebiegała jak najsprawniej. Aby spełnic te wy-magania, zastosowano protokół Domain Name System, który własnie do obsługi bardzoduzej liczby zapytan w krótkim czasie został zaprojektowany. W chwili obecnej systemyDNSBL sa pierwszym i podstawowym sposobem filtrowania niechcianych wiadomosci nazdecydowanej wiekszosci serwerów pocztowych. Istnieje wiele serwerów DNSBL – kazdyzawierajacy innego rodzaju adresy, dodawane zgodnie z lokalna polityka danego serwi-su. Najpopularniejsze usługi tego typu oferuja informacje dotyczace adresów IP nadawcówwiadomosci. Istnieja jednak równiez listy zawierajace czesci domenowe adresów poczto-wych nadawców, a nawet adresy stron WWW, które moga byc reklamowane w spamie.Mimo ogromnej popularnosci, a takze bardzo dobrej skutecznosci, mechanizm DNSBL po-siada równiez ogromna wade: uzytkownicy serwisów oferujacych DNSBL musza obdarzyczaufaniem twórców takich list, a co za tym idzie – musza w pełni akceptowac stosowanaprzez nich polityke, a takze sa całkowicie zdani na ich nieomylnosc. Równiez centralizacjaserwerów DNSBL stanowi znaczaca wade tej usługi. Powoduje ona, iz serwery te narazone

28


sa na ataki ze strony osób zawodowo zajmujacych sie rozsyłaniem niechcianych wiadomo-sci, a wiec ich własciciele nie sa tak naprawde w stanie zagwarantowac ciagłosci swiadczo-nych usług.

Klasyfikacja oparta o tresc wiadomosci

Zupełnie odmiennym podejsciem do wykrywania niechcianych wiadomosci jest ich klasyfi-kacja na podstawie tresci samej wiadomosci [26]. Zaobserwowano, iz znakomita wiekszoscspamu rozsyłanego w sieci Internet zawiera bardzo podobna tresc. Stanowia ja reklamy róz-nego rodzaju serwisów pornograficznych, srodków i usług medycznych, usług finansowychitp. Bez wzgledu jednak na temat, forma samych wiadomosci równiez w wiekszosci przy-padków jest bardzo podobna – staraja sie one zwrócic uwage odbiorcy na reklamowane pro-dukty, a takze nakłonic do ich zakupu. Dodatkowo z obserwacji „normalnych” wiadomosciwymienianych przez uzytkowników poczty elektronicznej wynika, iz forma, która przybie-raja wiadomosci niechciane jest w wiekszosci przypadków dosc znaczaco rózna od tej, któraprzybiera zwykła korespondencja. W zwiazku z powyzszym narzucajaca sie metoda wykry-wania spamu jest klasyfikacja na podstawie tresci wiadomosci. Pierwszym podejsciem dotego problemu było, podobnie jak w przypadku filtrowania na podstawie adresu nadawcy,tworzenie statycznych list cech wiadomosci (złozonych ze słów kluczowych, wyrazen regu-larnych itp.), które zawiera niechciana korespondencja, zas które nie powinny sie znalezc winnych listach. Oczywiscie nadawcy niechcianych wiadomosci szybko nauczyli sie te tech-nike omijac – współczesnie spam, oprócz typowych dla niego cech, zawiera równiez bardzowiele elementów, które maja upodabniac go do pozostałej czesci korespondencji. Stosowanesa w tym celu na przykład fragmenty tresci znanych ksiazek (jak Biblia czy „Moby Dick”)lub stron WWW, zniekształcenia w najpopularniejszych słowach kluczowych (na przykład„V!@gr@” zamiast „Viagra”) czy inne tego typu metody. Aby dostosowac filtrowanie do tegotypu praktyk, a takze aby poprawic skutecznosc stosowanych statycznych list cech spamu,zaczeto na ich podstawie tworzyc bardziej skomplikowane klasyfikatory tresci. Poczatko-wo korzystały one jedynie z najprostszych osiagniec w dziedzinie rozpoznawania wzorców,jednakze wraz ze wzrostem stopnia skomplikowania metod, stosowanych przez nadawcówniechcianych wiadomosci w celu ominiecia filtrów, równiez algorytmy klasyfikacyjne sta-wały sie coraz bardziej wyrafinowane [29]. Współczesnie najszerzej uzywana metoda jestzastosowanie podejscia Bayesa. Daje ono mozliwosc dostosowywania (przyuczania) syste-mu rozpoznajacego niechciane wiadomosci podczas jego pracy, a wiec umozliwia adapto-wanie sie tego systemu do zmieniajacych sie niechcianych wiadomosci, a takze do ciaglepojawiajacych sie ich nowych rodzajów. W niektórych systemach filtrujacych zastosowanieznajduja równiez mechanizmy oparte o sieci neuronowe. Sa one jednak mniej popularne,ze wzgledu na wieksza ilosc obliczen, które ich zastosowanie generuje, a co za tym idzie –duze obciazenie i zajecie zasobów systemu, w którym sa wdrazane.

Duza skutecznosc oraz mozliwosc biezacej adaptacji do zmieniajacych sie charaktery-styk otrzymywanych niechcianych wiadomosci w przypadku systemów filtrowania na pod-stawie tresci wiadomosci okupiona jest ich niska wydajnoscia. Zazwyczaj sklasyfikowanie

29


otrzymanej korespondencji zajmuje znaczaca ilosc czasu, a takze zuzywa istotna czesc zaso-bów serwera pocztowego, na którym jest ono przeprowadzane. Aby uniknac tych wad, sto-suje sie podejscie polegajace na szeregowym łaczeniu metod filtrowania wiadomosci. Klasy-fikacji na podstawie tresci moga w nim podlegac jedynie te listy, które nie zostały zaklasyfi-kowane jako niechciane na podstawie informacji z dostepnych systemów DNSBL. Wprowa-dzane sa równiez metody pozwalajace znacznie zmniejszyc konieczna do wykonania iloscobliczen podczas filtrowania na podstawie tresci. Powstaja usługi korzystajace w tym celu zmasowosci spamu: z tresci niechcianych wiadomosci wyliczana jest suma kontrolna, któranastepnie umieszczana jest na centralnym serwerze i na jej podstawie inni uzytkownicy da-nego serwisu moga filtrowac wiadomosci w swoich systemach pocztowych. Podejscie takiestanowi kompromis miedzy szybkoscia i niskim obciazeniem serwerów, a takze łacz siecio-wych, znanym z serwisów DNSBL, a jakoscia klasyfikacji zapewniana przez filtry oparte natresci wiadomosci.

Metody heurystyczne

W celu zmniejszenia liczby niechcianych wiadomosci docierajacych do uzytkowników, sto-sowane sa równiez róznego rodzaju metody heurystyczne. Najpopularniejsza tego typutechnika jest tzw. greylisting. Metoda ta oparta jest na obserwacji zachowania oprogramo-wania słuzacego spammerom do rozsyłania ich korespondencji. Otóz okazuje sie, iz jest tooprogramowanie nastawione na wysłanie jak najwiekszej liczby listów w jak najkrótszymczasie. Cel ten osiagany jest za wszelka cene, miedzy innymi poprzez łamanie róznych cze-sci standardu definiujacego SMTP. Jednym z wazniejszych braków tego oprogramowaniajest nieumiejetnosc powtarzania próby doreczenia wiadomosci w momencie, gdy pierw-sze doreczenie zakonczyło sie błedem tymczasowym. Zgodnie ze standardem definiuja-cym SMTP, w takich okolicznosciach nadawca po pewnym czasie powinien ponowic pró-be. Oprogramowanie uzywane do masowego rozsyłania niechcianej korespondencji jednaktego nie robi, gdyz jest to uznawane za strate czasu, który wykorzystac mozna na dorecze-nie wielu innych kopii tego samego listu do innych adresatów. W zwiazku z tym, pomysłgreylistingu polega na odrzucaniu z definicji kazdej pierwszej próby doreczenia wiadomo-sci. Skutecznosc takiej techniki jest zdumiewajaca – potrafi wyeliminowac zdecydowanawiekszosc spamu, powodujac jedynie niewielkie opóznienia (rzedu kilkunastu minut w ty-powych warunkach) w doreczaniu pozostałej czesci korespondencji. Jednak nie wszedziemoze ona byc stosowana – po pierwsze dlatego, ze czasem opóznienia w doreczaniu pocz-ty nie sa akceptowalne dla jej uzytkowników, po drugie ze wzgledu na istnienie oprogra-mowania serwerów poczty elektronicznej, które, podobnie jak programy wykorzystywaneprzez nadawców niechcianych wiadomosci, nie spełnia standardów i nie ponawia próbydoreczenia tymczasowo odrzuconych wiadomosci.

Współczesnie praktycznie kazdy serwer poczty elektronicznej, w celu prawidłowegodziałania i unikniecia zalania niechcianymi wiadomosciami, musi stosowac jedna lub kil-ka z opisanych powyzej technik. Zazwyczaj stosowane sa systemy grupujace wszystkie tetechniki hierarchicznie tak, aby uzyskac jak najwieksza skutecznosc przy jednoczesnie jaknajmniejszym obciazeniu zasobów systemowych serwera, a takze jego łacz komunikacyj-nych. O zaawansowaniu takich technik moze swiadczyc fakt, iz w wiekszosci komercyj-nych usług pocztowych ich odpowiednie zestawienie pozwala zablokowac doreczenie do

30


odbiorcy około 90% z nich, zas w najlepszych obecnych na współczesnym rynku – nawet,jak juz wspomniane zostało wczesniej, 99.85%.


Opisane powyzej techniki filtrowania wiadomosci niejednokrotnie stosowane sa równiez wcelu zmniejszenia skutków braku mozliwosci identyfikacji nadawcy wiadomosci. Nie od-nosza sie one co prawda do sedna problemu, jednakze wiadomosci wysyłane przez osobyzajmujace sie phishingiem czesto równiez moga zostac automatycznie wykryte, a tym sa-mym ich adresat moze zostac ochroniony przed potencjalnym niebezpieczenstwem. Skalezjawisk zwiazanych z podszywaniem sie pod inne osoby zmniejszac moze równiez samoograniczanie procederu rozsyłania niechcianych wiadomosci, gdyz, jak juz wspomniałemwe wczesniejszej czesci niniejszej pracy, osoby zajmujace sie obydwoma omawianymi ro-dzajami naduzyc wykorzystuja praktycznie identyczne techniki.

Jednakze powyzsze metody sa tylko obchodzeniem sedna problemu. Prawdziwe jegorozwiazania skupiaja sie na stworzeniu metody, dzieki której nadawca mógłby w wiarygod-ny sposób poswiadczyc swoja tozsamosc przed odbiorca. W tym celu tworzone sa róznegorodzaju techniki zwiazane z podpisywaniem wiadomosci wysyłanych poczta elektronicz-na. Do najprostszych, obecnych w poczcie elektronicznej od samego jej powstania, nalezapodpisy umieszczane przez nadawców w tworzonych przez siebie wiadomosciach. Nie-stety, jak doskonale wiadomo, sa one kompletnie bezuzyteczne w kontekscie identyfikacjirzeczywistego nadawcy danej wiadomosci, poniewaz ich sfałszowanie jest równie banalne,co w przypadku pozostałej czesci tresci wiadomosci. Druga, równie prosta i niestety równienieskuteczna metoda, jest uzywanie pola nagłówkowego From: wiadomosci. Fałszerstwona tym elemencie wiadomosci jest równie proste, co na jej tresci, jednak bardzo wielu uzyt-kowników poczty elektronicznej ufa mu w bardzo duzym stopniu. Moim zdaniem ten brakswiadomosci moze byc jedna z wazniejszych przyczyn, dla których phishing odnosi wewspółczesnym swiecie tak duze sukcesy.

Jedynie uzytkownicy posiadajacy wieksza wiedze na temat poczty elektronicznej, spo-sobu jej transportu, a takze zagrozen z nia zwiazanych we współczesnych realiach, stosujametody, które tak naprawde sa w stanie poprawic zaufanie do danych dotyczacych nadaw-cy, zawartych w otrzymywanych wiadomosciach. Chodzi tu o szeroko pojete podpisy kryp-tograficzne dołaczane do wiadomosci. Mozna wsród nich wyróznic dwie najpopularniejszetechniki. Pierwsza sa podpisy w standardzie OpenPGP – zdefiniowanej w RFC 4880 [30]otwartej wersji technologii Pretty Good Privacy. Jest to schemat kryptografii asymetrycz-nej, w której uzytkownicy sami sobie wystawiaja klucze. Skad w takiej sytuacji zaufanie dopodpisu otrzymanego wraz z wiadomoscia? Otóz wynika ono z nieformalnego zwyczajuzwiazanego z technologia OpenPGP – z budowania sieci typu Web of Trust. Ich idea jestwzajemne podpisywanie swoich kluczy publicznych przez osoby majace do siebie zaufanie(na przykład przez osoby znajace sie z kontaktów niezwiazanych z elektroniczna wymia-na wiadomosci). Budowana w ten sposób WoT stanowi nastepnie podstawe do weryfikacjipodpisu: uznawany jest on za godny zaufania, jezeli klucz uzyty do jego wygenerowaniajest zaufany, czyli podpisany przez osobe, do której mozliwe jest wytyczenie sciezki poła-czen tworzonych przez relacje wzajemnego podpisywania kluczy. Zasadnicza wada tego

31


rozwiazania jest jego ograniczone pole zastosowania – wymagane jest, aby nadawca i od-biorca znalezli sie w tej samej strukturze WoT, a wiec byli w pewnym sensie zwiazani z tymsamym srodowiskiem. Moze to byc trudne do wykonania, na przykład, w sytuacji komu-nikacji miedzy instytucjami zaufania publicznego czy tez bankami a ich klientami. Rozwia-zaniem eliminujacym ten mankament jest zastosowanie systemu kryptograficznego oparte-go o Public Key Infrastructure. W takim modelu stosuje sie do podpisywania wiadomosciklucze, które poswiadczone sa przez tzw. zaufana trzecia strone, czyli instytucje, która nietylko gwarantuje ich autentycznosc, ale równiez reczy za tozsamosc ich własciciela. Insty-tucja ta zwana jest centrum certyfikacji. Zastosowanie systemu PKI na rynku poczty elek-tronicznej opiera sie w chwili obecnej o standard Secure MIME, który pozwala wykorzy-stywac tworzone w ten sposób klucze i certyfikaty do podpisu elektronicznych wiadomoscipocztowych, a nastepnie ich weryfikacji. Moim zdaniem S/MIME jest obecnie najbardziejzaawansowanym i najbezpieczniejszym sposobem uwierzytelniania nadawcy wiadomoscielektronicznych. Niestety jego zastosowanie nie jest zbyt powszechne. Przyczyn takiego sta-nu rzeczy upatrywac mozna w niezbyt rozpowszechnionym wsparciu dla tego standarduw klientach pocztowych, a takze w kosztach, jakie sa zwiazane z uzyskaniem certyfikatu odzaufanego centrum certyfikacji.

32

Rozdział 3.

EXTENSIBLE MAIL EXCHANGEPROTOCOL

Wiekszosc osób zwiazanych z poczta elektroniczna czy to jako jej uzytkownicy, czy jako ad-ministratorzy serwerów dostarczajacych usług pocztowych, czy tez jako osoby rozwijajaceoprogramowanie słuzace do obsługi i transportu wiadomosci poczty elektronicznej, repre-zentuje wspólny poglad, iz problemy nekajace współczesny rynek usług pocztowych zde-cydowanie degraduja jego jakosc i komfort wykorzystywania mozliwosci, które on oferuje.Osoby te sa równiez zgodne w pogladzie, iz nalezy eskalacje tych problemów za wszelkacene hamowac. To własnie zahamowanie rozwoju zjawisk problemowych maja na celu dzia-łania opisane w czesci 2.3. niniejszej pracy. Warto jednak zastanowic sie, dlaczego walka zezjawiskami niepozadanymi w poczcie elektronicznej nie oznacza dazenia do ich eliminacji,a tym samym do przywracania dawnej swietnosci i pełnej uzytecznosci sieciowych syste-mów transportu wiadomosci.

W niniejsza pracy chciałbym zaproponowac zupełnie odmienne podejscie do zagadnie-nia walki z zagrozeniami współczesnego rynku usług poczty elektronicznej. Wobec brakumozliwosci przeprowadzenia ewolucyjnej zmiany uzywanych protokołów tak, aby w sku-teczny sposób podjac próbe wyeliminowania wystepujacych problemów, moim zdaniem,odpowiednim krokiem byłoby wykonanie zmiany rewolucyjnej. Jej sednem powinno bycopracowanie nowego protokołu transportu poczty elektronicznej, który, przy odpowied-nich załozeniach projektowych, byłby w stanie zminimalizowac wystepowanie niepozada-nych zjawisk, które w chwili obecnej nekaja rynek elektronicznych usług pocztowych. Jestto rozwiazanie zupełnie innowacyjne, w stosunku do stosowanych obecnie, nie tylko przezodmiennosc stosowanych rozwiazan technicznych, ale takze przez zupełnie inne podejsciedo postepowania przy opracowywaniu rozwiazywania problemu. Po pierwsze, jest to po-stepowanie ukierunkowane na zminimalizowanie (czy tez, w przypadku idealnym, całko-wite usuniecie) wystepowania jego przyczyn, a nie skutków. Po drugie, działanie to nie jestskrepowane koniecznoscia dostosowania sie do istniejacych rozwiazan technicznych, a coza tym idzie – odznacza sie wieksza swoboda i wiekszymi mozliwosciami przy jego projek-towaniu, a wiec potencjalnie moze byc o wiele skuteczniejsze.

33

ROZDZIAŁ 3. EXTENSIBLE MAIL EXCHANGE PROTOCOL

W dalszej czesci swojej pracy omówie moja propozycje przeprowadzenia rewolucyjnejreformy rynku elektronicznych usług pocztowych. Najwazniejsza czescia wspomnianej re-formy, która stanowic bedzie główny obiekt zainteresowania niniejszej pracy, jest propono-wany przeze mnie protokół EXTENSIBLE MAIL EXCHANGE PROTOCOL, który przedstawiezarówno od strony koncepcyjnej, jak i konkretnych rozwiazan technicznych.

3.1. Uzasadnienie opracowania XMXP

Zasadnicza przeszkoda w usunieciu problemów zwiazanych współczesnie z transportempoczty elektronicznej jest, moim zdaniem, koniecznosc zachowania zgodnosci działajacychw obecnych czasach systemów pocztowych z protokołami i standardami projektowanymiwiele lat temu. Warto zauwazyc, iz niejednokrotnie powstawały one w zupełnie innej rze-czywistosci. Na przykład standard definiujacy SMTP (czyli RFC 821 [11]) powstał 25 lattemu, w bardzo wczesnych poczatkach rozwoju sieci Internet, a nawet sieci komputero-wych w ogóle. Na przestrzeni czasu, który upłynał od tamtej pory, zaszło bardzo wiele zna-czacych zmian w sposobie i zasadach funkcjonowania globalnej sieci komputerowej, któ-re sprawiły, ze obecnie SMTP nie jest w stanie skutecznie i efektywnie funkcjonowac. Coprawda mnogosc rozszerzen, która została dla niego stworzona, ma zapewnic mu uzywal-nosc we współczesnych realiach, jednakze nie sa one w stanie naprawic wad, które leza wnajbardziej podstawowych elementach konstrukcji protokołu. Moim zdaniem, najbardziejefektywna metoda rozwiazania zwiazanych z tym problemów jest zerwanie z wymaganiemzgodnosci wstecznej. Daje to swobode w tworzeniu nowych rozwiazan, dostosowanych dowspółczesnych realiów.

Przystosowywanie projektowanych w przeszłosci protokołów do aktualnie panujacychuwarunkowan techniczno-rynkowych jest obecnie bardzo powszechne. Dokonuje sie tegoza pomoca róznego rodzaju poprawek, uaktualniania standardów definiujacych uzywaneod dawna protokoły, tworzenia dodatków i nakładek na nie i poprzez inne, podobne tech-niki. Moim zdaniem, mimo całej jego popularnosci, nie jest to podejscie własciwe. Prowadziono do ograniczen, które nie powinny wystepowac juz na etapie projektowania nowegorozwiazania technicznego. Nie dosc, iz konieczne jest zachowanie pełnej zgodnosci z ist-niejacym do tej pory stanem rozwoju sieci komputerowych, a takze wykorzystywanym wnich oprogramowaniem, to jeszcze nalezy brac pod uwage wpływ, jaki bedzie miało na nietworzone rozwiazanie. Wpływ ten niejednokrotnie jest bardzo znaczacy – wiele tworzonychrozszerzen zdecydowanie zmniejsza komfort (czy to uzytkowy czy implementacyjny) wy-korzystywania protokołu, dla którego zostało ono zaprojektowane, a wiec de facto, napra-wiajac jeden problem, wprowadza kolejne. Mozna domniemywac, iz protokoły transportupoczty elektronicznej, których rozwój własnie w ten sposób przebiega, w pewnym momen-cie stana sie zbyt odległe od swych poczatkowych załozen, a co za tym idzie – bedzie jetrudno wykorzystywac zgodnie z pierwotnym przeznaczeniem. W zwiazku z tym, moimzdaniem, rozszerzanie protokołów, które do tego nie były zaprojektowane, nie powinno bycstosowana metoda ich aktualizacji, gdyz nie zawsze musi prowadzic do zwiekszenia kom-fortu korzystania z usług pocztowych. Wrecz przeciwnie – najprawdopodobniej z czasemsam fakt tworzenia „usprawnien” dla pewnych protokołów moze zaczac powodowac de-gradacje ich uzytecznosci, mimo jak najlepszych checi osób dazacych do ich rozbudowy.Aby zatem uniknac tego typu problemów, proponuje odejscie od dotychczas popularnej

34


strategii „łatania dziur” na rzecz zaprojektowania mechanizmu transportu poczty elektro-nicznej od poczatku, co powinno dac o wiele lepsze wyniki w zwalczaniu problemów wy-stepujacych współczesnie na rynku elektronicznych usług pocztowych.

Projektowanie protokołu transportu poczty elektronicznej od podstaw w chwili obecnejdaje równiez mozliwosc lepszej oceny trudnosci, z którymi bedzie on zmuszony sie bory-kac w trakcie wdrozenia czy przyszłego uzytkowania. W momencie projektowania SMTP,czyli 25 lat temu, poczta elektroniczna była jeszcze zjawiskiem bardzo mało popularnymi kierunek jej rozwoju był trudny do przewidzenia, gdyz nie istniały jeszcze w tej kwestiizadne doswiadczenia. Było to zadanie tym trudniejsze, iz nawet ówczesne przewidywaniadotyczace przyszłego kształtu sieci komputerowych, czy tez rynku IT w ogóle, nie okazałysie byc w pełni trafne. W chwili obecnej jestesmy bogatsi w wieloletnie doswiadczenia, awiec tworzenie nowych rozwiazan technicznych opiera sie w dzisiejszym swiecie na zupeł-nie innych podstawach. Mozliwe jest dzis uwzglednienie charakterystyki, kierunku, a takzetempa przemian, które na rynku poczty elektronicznej dadza sie zaobserwowac, które dajamozliwosc przewidzenia, chocby w przyblizeniu, jego ewolucji w niedalekiej przyszłosci.Majac taka wiedze, mamy jednoczesnie mozliwosci zaprojektowania usługi, która w zde-cydowanie lepszy sposób bedzie dostosowana do potrzeb jej uzytkowników – nie tylkowspółczesnie, ale takze w przyszłosci.

W okresie, w którym tworzono SMTP, a takze protokoły jemu podobne, mozliwosci za-równo sprzetu komputerowego, jak i sieci telekomunikacyjnych, były zupełnie nieporów-nywalne z obecnymi. W zwiazku z tym, rozwiazania tworzone 25 lat temu ograniczanebyły w znaczacy sposób mozliwosciami technicznymi. Nalezało sie zatem liczyc z tym, zeprojektowane standardy beda na tyle rozbudowane i zaawansowane, na ile pozwalał bie-zacy stan rozwoju technicznego. Jako, ze był on dosc ubogi, tworzono rozwiazania niezbytskomplikowane, pełne uproszczen. Ówczesnie, nie wydawał sie byc to znaczacy problem,jednak dzisiaj prostota, a co za tym idzie – ograniczone mozliwosci uzywanych protoko-łów, stanowia, na rynku poczty elektronicznej, podstawe zagrozen i problemów, z którymispotykamy sie na co dzien. Stworzenie nowego protokołu we współczesnych realiach dajeo wiele wieksze mozliwosci takze w tej kwestii. Biorac pod uwage tempo rozwoju rynkuIT, mozna przyjac, iz ograniczenia zwiazane z mozliwosciami sprzetu komputerowego, atakze sieciowego, sa bardzo niewielkie, (praktycznie marginalne). Załozenie takie powinnowraz z dalszym, postepujacym rozwojem rynku IT, byc coraz bardziej prawdziwe, co ozna-cza, iz jest ono bardzo przyszłosciowe. Daje ono o wiele wieksza swobode w tworzeniuzałozen i opracowywaniu rozwiazan technicznych, niz ta, która dysponowały osoby two-rzace SMTP. Szersze pole działania dostepne juz na samym poczatku tworzenia nowychrozwiazan, a zatem szerszy wachlarz mozliwosci do rozwazenia przy ich tworzeniu, dajamozliwosc zaprojektowania protokołu chociaz w pewnym stopniu niezaleznego od zmian,które zachodza, a takze w przyszłosci zachodzic beda, na rynku poczty elektronicznej.

Przedstawione powyzej argumenty prowadza do wniosku, iz projektowanie protoko-łu transportu poczty elektronicznej w chwili obecnej, a wiec w momencie jej ogromnegorozkwitu, a takze w momencie rozkwitu technologii zwiazanych z komputerami i sieciamikomputerowymi, zwieksza szanse na stworzenie protokołu, który bedzie spełniał wyma-gania rynku elektronicznych usług pocztowych, niz to było 25 lat temu. Moim zdaniem,nalezy w zwiazku z tym podjac próbe realizacji tego zadania, mimo, iz z pewnoscia przezwiele osób nie zostanie to uznane za własciwy kierunek rozwoju transportu poczty elektro-nicznej. Jednakze w srodowisku osób najblizej zwiazanych z rozwiazywaniem problemów

35


współczesnej poczty elektronicznej – administratorów serwerów usług pocztowych – oddłuzszego czasu pojawiaja sie dazenia do gruntownej ich reformy. Niniejsza prace moznazatem traktowac jako próbe zaproponowania naukowego podejscia do rozwiazania tegoproblemu poprzez analize negatywnych zjawisk, które wiaza sie w sposób nieodłaczny ztransportem poczty elektronicznej, a nastepnie zaproponowanie ich wyeliminowania meto-da wprowadzenia nowego protokołu transportu poczty elektronicznej, opartego na zupeł-nie innych załozeniach i podstawach niz wykorzystywane dotychczas.

3.2. Załozenia projektowe XMXP

Podczas tworzenia załozen projektowych dla EXTENSIBLE MAIL EXCHANGE PROTOCOL

wzietych zostało pod uwage bardzo wiele czynników, które potencjalnie moga miec wpływna ich koncowy kształt. Najwazniejszym aspektem rozwazanym podczas projektowaniaXMXP była chec unikniecia błedów, które w historii transportu poczty elektronicznej zostałyjuz popełnione – czy to przy tworzeniu lub eksploatacji SMTP czy podczas projektowaniainnych protokołów. Stad własnie wynika przeprowadzenie przegladu historycznego roz-woju poczty elektronicznej, a takze analizy rynku usług współczesnie z nia powiazanych,które zostały zaprezentowane we wczesniejszych rozdziałach niniejszej pracy. Istotnym za-łozeniem projektowym, które stanowi jednoczesnie główna przyczyne powstania XMXP,jest chec wyeliminowania niepozadanych zjawisk zwiazanych w chwili obecnej z transpor-tem poczty elektronicznej, likwidacja ich przyczyn, a takze utrudnienie powstawania po-dobnych problemów w przyszłosci.

Projektowaniu proponowanego przeze mnie protokołu przyswiecała miedzy innymiidea najpełniejszego mozliwego wykorzystania zdobyczy technicznych, które pojawiły siew ciagu wielu lat rozwoju rynku IT, a takze informatyki jako dziedziny nauki. Duzy naciskzostał jednakze połozony na przedstawienie załozen projektowych dla protokołu transpor-tu poczty elektronicznej, który byłby zaprojektowany na odpowiednim poziomie ogólnosci.Zastosowanie wysokiego poziomu abstrakcji sprawia, iz konkretne rozwiazania implemen-tacyjne, mimo ich przedstawienia i szerokiego omówienia w niniejszej pracy, nie staja siewiazace dla osób chcacych rozwijac XMXP w przyszłosci, a co za tym idzie – pozostajemozliwosc jego dostosowywania do zmieniajacych sie uwarunkowan technologicznych ispołecznych zwiazanych z rozwojem rynku poczty elektronicznej.

Najwazniejsze cechy, którymi odznaczac powinien sie projektowany protokół to:

• mozliwosc jego swobodnego rozszerzania,

• przeniesienie kosztów wysłania wiadomosci na jej nadawce,

• mozliwosc identyfikacji nadawcy kazdej wiadomosci w sposób pewny i bezpieczny,

• wieksza elastycznosc w kształtowaniu ruchu sieciowego generowanego przez obsługepoczty elektronicznej.

Kazda z wymienionych powyzej cech zostanie w szczegółach opisana w dalszej czescininiejszego rozdziału.

36


3.2.1. Rozszerzalnosc

Podstawowym, moim zdaniem, błedem, który popełniali autorzy protokołów takich, jakSMTP czy X.400, jest projektowanie ich w sposób, który miał dawac ich dziełom jak naj-lepsze przystosowanie do warunków panujacych w danej chwili na rynku elektronicznychusług pocztowych. Nie przewidzieli oni, czy tez moze nie brali w ogóle pod uwage, dyna-mizmu, którym odznacza sie rozwój poczty elektronicznej. W zwiazku z tym, zaprojekto-wane przez nich rozwiazania nie były odporne na najtrudniejsza z prób, jakie przyszło imprzejsc – na próbe czasu. Jak juz wspomniane zostało wczesniej, tworzone sa rózne dodatki,rozszerzenia czy usprawnienia chocby dla SMTP, jednakze ich istnienie nie zostało przewi-dziane w samej specyfikacji protokołu. Wiaze sie z tym problem ograniczonych mozliwosciintegracji nowo tworzonych rozwiazan z zasadniczym rdzeniem protokołu, a takze zgod-nosci ich z istniejacym wczesniej oprogramowaniem czy tez mozliwosci tworzenia nowegooprogramowania obsługujacego protokół wraz z róznymi zestawami rozszerzen.

Jak sama nazwa EXTENSIBLE MAIL EXCHANGE PROTOCOL wskazuje, najbardziej pod-stawowym załozeniem proponowanego przeze mnie protokołu jest własnie nieobecnaw stosowanych dotychczas rozwiazaniach rozszerzalnosc. Zrealizowana zostanie ona nadwóch poziomach abstrakcji: na poziomie ogólnym, czyli zwiazanym z załozeniami XMXP,a takze na poziomie konkretnych proponowanych przeze mnie rozwiazan technicznych.

Rozszerzalnosc XMXP na wysokim poziomie abstrakcji rozumiec nalezy poprzez odpo-wiednie podejscie do definiowanych przeze mnie elementów tego protokołu. Najistotniej-sza ich czescia, stanowiaca o nowatorskosci XMXP, a jednoczesnie definiujaca ten proto-kół, sa niniejsze załozenia projektowe. Stanowia one niejako szkielet, na którym budowanenastepnie beda szczegółowe rozwiazania techniczne składajace sie na sposób komunikacjimiedzy elementami systemu wykorzystujacego XMXP, a wiec na protokół jako taki. Jednak-ze bardzo mocno podkreslic nalezy, iz to nie rozwiazania techniczne czy stosowane techno-logie sa najistotniejsze. Z mojego punktu widzenia, równie duze znaczenie maja załozeniakoncepcyjne, gdyz w ramach rozszerzalnosci chciałbym zaproponowac mozliwosc zmie-niania lub dodefiniowywania poszczególnych praktyczno-implementacyjnych szczegółów.Proponowany przeze mnie protokół ma byc w jak najwiekszym stopniu otwarty na doko-nywanie w nim zmian, poprawek i ulepszen w przyszłosci, na ewolucje, która powinnaprzebiegac wraz z ewolucja rynku poczty elektronicznej, a takze sieci komputerowych wogólnosci. Dzieki temu mozna miec nadzieje, iz XMXP uniknie podstawowego problemu,który wiaze sie z SMTP – „starzenia sie” tego protokołu i coraz gorszego jego dopasowaniado panujacych na rynku poczty elektronicznej realiów.

Równie duza elastycznosc powinna cechowac wszelkie rozwiazania techniczne, którezostana dla XMXP zaproponowane. Aby mozliwe było to do uzyskania w stosunkowonieskomplikowany sposób, proponowany przeze mnie protokół oparty został o eXtensibleMarkup Language [31]. Jezyk ten został zastosowany jako format wiadomosci wymienia-nych w XMXP miedzy poszczególnymi stacjami, a takze jako format komunikacji miedzyaplikacjami implementujacymi proponowany protokół. XML jako jezyk zaprojektowany zmysla o mozliwosci rozszerzania tworzonych w nim dokumentów w przyszłosci, bardzodobrze spełnia wymagania projektowe stawiane w ramach opracowywania XMXP. Wielez mozliwosci XML w sposób zdecydowany ułatwia implementacje zadan, które XMXP ma

37


realizowac. Najwazniejsza z nich sa przestrzenie nazw XML. Moga byc one bardzo zgrab-nie wykorzystane w celu realizacji rozszerzalnosci protokołu. Specyfikacja wersji podsta-wowej protokołu wykorzystuje wiele róznych przestrzeni nazw – odrebna dla kazdego zjej elementów. W zwiazku z tym mozliwa jest w prosty sposób wymiana jednego z nich nainny, zdefiniowany w odrebnej przestrzeni nazw. Mozliwe równiez jest tworzenie dodatko-wych elementów, które wykorzystane maja zostac w ramach komunikacji w XMXP, a takzeopracowywanie nowych wersji komponentów juz istniejacych – wystarczy je umiescic wodrebnej przestrzeni nazw. Nalezy zauwazyc zasadnicza róznice miedzy rozszerzalnosciazdefiniowana w ten sposób, a tworzeniem rozszerzen metodami, jakie sa obecnie stosowa-ne podczas dopasowywania SMTP do panujacych aktualnie na rynku poczty elektronicznejwarunków. Otóz zaproponowany przeze mnie sposób przede wszystkim uwzglednia istnie-nie rozszerzen od samego powstania protokołu. Ich autorzy dostaja pełna swobode dzia-łania, gdyz nie sa zwiazani koniecznoscia aktualizacji specyfikacji bazowej wersji XMXPw momencie tworzenia swoich rozszerzen. Równiez autorzy aplikacji implementujacychproponowany przeze mnie protokół moga tworzyc je w sposób o wiele bardziej efektyw-ny – mozliwe bedzie zaimplementowanie jedynie wybranych elementów jego specyfikacji,czy tez wybranych rozszerzen poprzez prosty wybór przestrzeni nazw, które sa przez danaimplementacje obsługiwane. Równiez w przypadku aktualizacji jednego (lub kilku) z ele-mentów protokołu, wysiłek, który osoby rozwijajace aplikacje wykorzystujace XMXP bedamusiały w takie działanie włozyc, bedzie zmniejszony dzieki mozliwosci wymiany jedy-nie niektórych ich czesci (tych, które bezposrednio dotycza zaktualizowanych elementówprotokołu), a nie koniecznosci zaprojektowania całej aplikacji zupełnie od poczatku.

Mimo, iz w niniejszej pracy proponuje wykorzystanie XML jako jezyka bazowego dlawszystkich komunikatów oraz wiadomosci wymienianych w XMXP, bardzo wazne jest,aby miec na uwadze, iz nawet ten element protokołu byc moze w przyszłosci bedzie wy-magał wymiany w zwiazku ze zmianami zachodzacymi na rynku elektronicznych usługpocztowych. Jezeli tak sie stanie, to moim zdaniem wymiana taka powinna byc mozliwabez naruszania innych cech protokołu, innych jego załozen projektowych, które opisane zo-stana ponizej.

3.2.2. Przeniesienie kosztów wysłania wiadomosci na nadawce

Bardzo istotnym problemem, szeroko opisanym w czesci 2.2.1. niniejszej pracy, sa masoworozsyłane niechciane wiadomosci pocztowe. Jak juz wspomniano wczesniej, ich nadawcyponosza bardzo niewielkie koszty zwiazane z wysyłaniem tego typu wiadomosci. Fakt tensprawia, iz proceder rozsyłania spamu kwitnie, jako bardzo opłacalny dla osób go upra-wiajacych. Kluczowym czynnikiem wpływajacym na jego opłacalnosc jest fakt, iz w stoso-wanych obecnie protokołach transportu poczty elektronicznej koszt przesłania wiadomoscilezy praktycznie całkowicie po stronie jej odbiorcy. Nie jest to sytuacja normalna, chocby je-sli porównac ja z usługami tradycyjnej poczty, gdzie za wysłanie listu płaci jego nadawca. Wprzypadku elektronicznych wiadomosci nadawca praktycznie nie jest obciazany zadnymikosztami – po jego stronie lezy jedynie zapewnienie łacza sieciowego od komputera nada-jacego wiadomosc. Odbiorca zas ponosi o wiele wieksze koszty – oprócz łacza sieciowegomusi on poswiecic znaczaca czesc swoich zasobów systemowych na sprawdzenie czy danawiadomosc nie jest przypadkiem spamem, a nastepnie w celu doreczenia jej do adresata.

38


Niezwykle waznym krokiem do wykonania podczas tworzenia nowego protokołutransportu poczty elektronicznej, a wiec w momencie przeprowadzania gruntownej refor-my rynku elektronicznych usług pocztowych, jest przeniesienie kosztów wysłania wiado-mosci na jej nadawce. Moim zdaniem, doprowadzenie do sytuacji, w której osoba wysyłaja-ca dany list elektroniczny bedzie w pewien sposób płacic za jego transport, pozwoli zblizyc,pod wzgledem ponoszonych kosztów, rynek poczty elektronicznej do rynku poczty trady-cyjnej. Jak dobrze wiemy, liczba rozsyłanych niechcianych wiadomosci, które trafiaja do na-szej tradycyjnej skrzynki pocztowej, jest nieporównywalnie mniejsza od liczby tych, któreotrzymujemy droga elektroniczna. Jezeli z wysłaniem spamu elektronicznego wiazałyby siewieksze koszty, moim zdaniem, jego nadawcy nie zajmowaliby sie ta działalnoscia na aztak wielka skale. W idealnym przypadku byc moze niechciana korespondencja zostałabyzredukowana do minimum, a reklamy rozsyłane poczta elektroniczna ograniczałyby sie dopłatnych akcji reklamowych, na przykład nadawanych przez dostawców darmowych ser-wisów oferujacych skrzynki poczty elektronicznej, podobnie jak ma to miejsce w przypadkupoczty tradycyjnej.

Konkretnych rozwiazan technicznych ukierunkowanych na obciazenie nadawcy wiado-mosci kosztami jej transportu mozna zaproponowac bardzo wiele. W ramach zapewnianiaelastycznosci projektowanego protokołu, podane zostana jedynie przykładowe mozliwosci,które moga byc uznane za polecane dla rynku poczty elektronicznej we współczesnym jegokształcie. Pamietac jednakze nalezy, iz w przyszłosci konieczne moze byc opracowanie ko-lejnych metod, bardziej dopasowanych do zmienionych warunków transportu poczty elek-tronicznej.

Wsród rozwiazan obecnie wydajacych sie odpowiednimi do osiagniecia omawianegocelu, moim zdaniem, w pierwszej kolejnosci nalezy wymienic pomysł zastosowania tzw.„zagadek algorytmicznych”. Polega on na uwarunkowaniu przyjecia wiadomosci od jejnadawcy rozwiazaniem pewnego problemu, którego znalezienie wymaga wykonania po-kaznej ilosci obliczen. W ten sposób nadawca wiadomosci „płaci” za jej wysłanie poprzezwykorzystanie zasobów systemowych komputera, z którego wiadomosc jest wysyłana.Warto zauwazyc, iz rozwiazanie to jest bardzo dobrze skalowalne. Mozliwe jest stosowa-nie „zagadek” o róznym stopniu trudnosci w zaleznosci od tozsamosci nadawcy, odbiorcy,wielkosci nadawanej przesyłki czy innych czynników, a co za tym idzie – dostosowywaniesystemu transportu poczty elektronicznej do charakterystyki ruchu, który obsługuje, a takzedo konkretnych wymagan jego uzytkowników. Równiez skalowalnosc tego typu rozwiaza-nia w czasie jest bardzo duza – wraz z rozwojem branzy komputerowej coraz łatwiej bedzierozwiazac zagadki stosowane współczesnie, wiec dzieki rozszerzalnosci protokołu natural-nym powinna byc wymiana ich na inne, bardziej skomplikowane i wymagajace wiecej mocyobliczeniowej ze strony komputera nadawcy.

Nalezy jednak pamietac, iz nie wszyscy uzytkownicy poczty elektronicznej dysponuja (idysponowac beda) komputerami o wystarczajaco rozbudowanych zasobach systemowych,aby rozwiazywanie problemów algorytmicznych przebiegało w akceptowalnym czasie. Wzwiazku z tym zaproponowac nalezy równiez inne, alternatywne rozwiazania. Najbardziejpopularnym powszechnie jest wykorzystanie uwagi uzytkownika systemu komputerowe-go, co mozna równiez uznac za swego rodzaju koszt zwiazany z wysłaniem wiadomosci.Mozna wykorzystac do tego celu technologie znana jako Completely Automated PublicTuring test to tell Computers and Humans Apart [32]. Polega ona na wykonaniu prostejimplementacji testu Turinga, który ma na celu odróznienie czy w danej akcji wykonywanej

39


przez system komputerowy bierze udział człowiek czy tez nie. Najpopularniejsze imple-mentacje tej metody polegaja na poproszeniu uzytkownika o wpisanie w formie tekstowejciagu znaków, który przekazany mu został w formie trudnej do przetworzenia w sposób au-tomatyczny – na przykład jako specjalnie przygotowany obraz lub jako przekaz dzwiekowy.Sposób ten wykorzystuje niedostatki współczesnych technologii rozpoznawania znakówczy tez przetwarzania mowy, wiec z czasem, wraz z rozwojem tych dziedzin informatyki,jego stosowanie moze przestac byc mozliwe. W zwiazku z tym bardzo wazna jest mozli-wosc zastapienia go przez inna metode obciazenia kosztami nadawcy wiadomosci. Mogado tego celu zostac wykorzystane na przykład systemy mikropłatnosci. W chwili obecnejmoim zdaniem ich wykorzystanie na szeroka skale nie jest jeszcze mozliwe ze wzgledu nazbyt mała popularnosc tego typu rozwiazan wsród uzytkowników sieci Internet. Z czasemjednak nalezy sie spodziewac wzrostu ich popularnosci, a co za tym idzie – wzrostu liczbyusług z nich korzystajacych, a wiec równiez mozliwosci stosowania tego typu rozwiazanjako jednego ze sposobów obciazania nadawcy wiadomosci kosztami jej transportu w siecisystemów wykorzystujacych XMXP.


Innym problemem, który nieodłacznie wiaze sie ze współczesnym rynkiem poczty elek-tronicznej, a który został dokładniej opisany w czesci 2.2.2. niniejszej pracy, jest mozliwoscstwierdzenia tozsamosci nadawcy wiadomosci. Rozwiazanie go jest o wiele bardziej skom-plikowane, niz w przypadku obciazenia nadawcy kosztami transportu wysłanego przezniego listu elektronicznego, gdyz nie mozna w tym przypadku znalezc prostej analogii choc-by do rynku tradycyjnych usług pocztowych. Konieczne jest wprowadzenie rozwiazania,które bedzie brac pod uwage specyfike rynku poczty elektronicznej i jednoczesnie zapew-niac wiarygodnosc porównywalna do metod uwierzytelniania stosowanych w relacjach niezwiazanych z komunikacja elektroniczna – chocby poprzez okazanie dowodu osobistego.Tylko w sytuacji, w której stwierdzenie tozsamosci nadawcy w sposób elektroniczny be-dzie równie bezpieczne i wiarygodne, co poprzez osobiste zweryfikowanie jego tozsamosci,mozna liczyc na zlikwidowanie opisanych wczesniej problemów.

Sposobem uwierzytelniania nadawcy wiadomosci stosowanym w XMXP ma byc we-ryfikacja jego tozsamozci na podstawie zintegrowanego z wiadomoscia cyfrowego podpi-su kryptograficznego. Podpis taki byłby wymagany dla kazdej wiadomosci przesyłanej wproponowanym przeze mnie protokole – wiadomosci niezawierajace go nie mogłyby bycuznane za poprawne w rozumieniu XMXP, a wiec nie mogłyby zostac wysłane. Widac tutajzasadnicza zmiane w stosunku do obecnie stosowanych protokołów transportu poczty elek-tronicznej, gdzie podpisywanie elektroniczne wiadomosci jest całkowicie opcjonalne, a wiecprzez wiekszosc uzytkowników zupełnie niewykorzystywane. Proponowana technologia,która wykorzystana ma zostac do podpisywania wiadomosci transportowanych przez sys-temy wykorzystujace XMXP jest XML Digital Signature [33] – powszechnie uznany stan-dard pozwalajacy na tworzenie podpisów dokumentów XML. Zapewnia on nie tylko moz-liwosc podpisania wiadomosci, a nastepnie weryfikacji takiego podpisu, ale równiez spo-sób przekazania certyfikatu zwiazanego z kluczem publicznym uzytym przy generowaniupodpisu, a co za tym idzie – mozliwosc zweryfikowania tozsamosci nadawcy wiadomosci.

40


W celu uzyskania opisanego powyzej stopnia wiarygodnosci podczas weryfikacji toz-samosci nadawcy wiadomosci, proponuje zwiazanie z EXTENSIBLE MAIL EXCHANGE

PROTOCOL infrastruktury typu PKI. Jej zadaniem byłoby zarzadzanie certyfikatami, któ-re nastepnie byłyby uzywane przez uzytkowników poczty elektronicznej do podpisywa-nia wiadomosci przez nich wysyłanych. Kluczowym zadaniem urzedów certyfikacji, którebyłyby elementem takiej infrastruktury, byłaby osobista weryfikacja tozsamosci osoby apli-kujacej o otrzymanie certyfikatu. Sposób wykonania takiej weryfikacji nalezy pozostawicdo doprecyzowania na etapie tworzenia omawianej PKI, gdyz, prawdopodobnie, powinienbyc on rózny i specyficzny dla kazdego kraju, w którym powstawałyby urzedy certyfikacji.Wspólnym ich elementem powinien byc, moim zdaniem, fakt zlokalizowania przy insty-tucji zaufania publicznego, która byłaby w stanie potwierdzic tozsamosc osoby, dla którejdany certyfikat byłby wystawiany. Takimi instytucjami mogłyby byc na przykład urzedysamorzadowe czy tez lokalne oddziały Computer Security Incident Response/ComputerEmergency Response Team. Tworzona PKI powinna ponadto miec charakter hierarchicz-ny, aby zaden z urzedów certyfikacji nie był przeciazony, a takze, aby zapewnic wieksza jejniezawodnosc i odpornosc na ewentualne próby kompromitacji.

Mozliwosc jednoznacznego i pewnego zidentyfikowania nadawcy wiadomosci jest rów-niez jednym ze sposobów na zmniejszenie liczby naduzyc wystepujacych na rynku pocztyelektronicznej. Moim zdaniem, koniecznosc podpisywania kazdej wysyłanej wiadomosci wsposób pozwalajacy dokładnie okreslic jej nadawce stanowiłaby bardzo skuteczny czynnikzniechecajacy do naduzyc. Równiez polityka wydawania certyfikatów, która okreslona po-winna zostac na szczeblu centralnym, czyli przez wystawce głównego certyfikatu uzywa-nego do podpisywania certyfikatów poszczególnych urzedów certyfikacji, moze stanowicswego rodzaju zabezpieczenie przed naruszaniem uznanych zasad korzystania z elektro-nicznych usług pocztowych, jesli zawarte w niej zostana sankcje grozace za naduzywaniesystemów wykorzystujacych XMXP. Wsród nich znalezc powinna sie równiez najwyzszamozliwa kara, czyli wycofanie certyfikatu, a co za tym idzie – brak mozliwosci dalszegokorzystania z poczty elektronicznej w proponowanym jej kształcie. Nalezy jednak wyrazniezaznaczyc, iz stworzona polityka powinna byc czytelna, jasna i bardzo dobrze przemysla-na, gdyz w przeciwnym razie jej istnienie zamiast naduzyciom zapobiegac, moze jedyniezwiekszyc liczbe elementów transportu poczty elektronicznej na nie podatnych.

3.2.4. Kształtowanie ruchu sieciowego

Zagadnieniem, które równiez rozwazane było podczas projektowania XMXP jest kształto-wanie ruchu sieciowego generowanego w wyniku komunikacji w tym protokole. W specy-fikacjach dotychczas wykorzystywanych protokołów transportu poczty elektronicznej byłoono konsekwentnie pomijane lub traktowane „po macoszemu”. Zupełnie odmienne podej-scie zastosowane zostało podczas tworzenia proponowanego przeze mnie protokołu. Du-zy nacisk połozony został na stworzenie efektywnych i elastycznych metod wyznaczaniamarszruty wiadomosci, dzieki czemu mozliwe jest kształtowanie generowanego ruchu sie-ciowego w sposób bardzo wydajny. Jednoczesnie równiez w tym aspekcie bardzo istotnacecha XMXP ma byc jego rozszerzalnosc – wszelkie zaproponowane ponizej rozwiazaniastanowia jedna z mozliwosci wykorzystania tworzonego protokołu, nie zas schemat sys-temu pocztowego, który bez zadnych modyfikacji musi byc stosowany przy kazdym jegowdrozeniu.

41


Protokoły tworzone w latach 80. XX. wieku nie uwzgledniały metod wyznaczania mar-szruty wiadomosci, gdyz na ówczesnym rynku poczty elektronicznej problem ten był bar-dzo nieskomplikowany. Współczesnie jednak, wraz ze wzrostem ilosci ruchu wymieniane-go w ramach poczty elektronicznej, równiez wyznaczanie trasy, która wiadomosc ma prze-byc na drodze od nadawcy do odbiorcy, przestało byc banalne. Problem ten, choc niewi-doczny dla koncowych uzytkowników, jest jednym z wiekszych zmartwien osób zajmuja-cych sie poczta elektroniczna od strony administracyjnej. Pokusic sie mozna nawet o po-równanie współczesnego rynku usług pocztowych pod wzgledem skomplikowania tras,które wystepujace na nim wiadomosci przebywaja, do tras pakietów danych w sieciachkomputerowych w ogólnosci. W zwiazku z tym, moim zdaniem koniecznym rozwiazaniemjest wprowadzenie – jako czesci XMXP – protokołu wyznaczania marszruty wiadomosci wsposób automatyczny. Proponuje wykorzystanie jako podstawowej, zawartej w specyfikacjibazowej wersji protokołu, adaptacji metody wyznaczania marszruty wiadomosci, która zpowodzeniem stosowana jest od długiego czasu w sieciach IP – Border Gateway Protocol[34]. Proponowane przeze mnie rozwiazanie nie jest dosłownym przeniesieniem BGP nagrunt poczty elektronicznej, jednakze wykorzystane zostały w opisanym ponizej protokolejego podstawowe załozenia funkcjonalne.

Protokół wyznaczania marszrut wiadomosci proponowany dla XMXP opiera sie nastworzeniu usystematyzowanego, podzielonego hierarchicznie systemu pocztowego. Je-go podstawowym elementem sa serwery przekazujace poczte elektroniczna, zwane MailServers. Ze wzgledu na pełniona role mozna je podzielic na dwa rodzaje: serwery we-wnetrzne (Internal Mail Servers) oraz brzegowe (Border Mail Servers). Rola serwerówwewnetrznych jest przekazywanie wiadomosci wewnatrz danej sieci, organizacji, instytucjiczy tez firmy, a takze doreczanie ich do skrzynek pocztowych uzytkowników koncowychznajdujacych sie na terenie danej jednostki organizacyjnej. Serwery brzegowe zas odpowie-dzialne sa za wymiane wiadomosci miedzy odrebnymi, autonomicznymi systemami pocz-towymi, zwanymi Autonomous Mail System. Miedzy poszczególnymi serwerami poczto-wymi, oprócz wymiany ruchu zwiazanego z przekazywaniem wiadomosci, zachodzi rów-niez komunikacja majaca na celu wymiane informacji dotyczacych adresów obsługiwanychprzez kazdy z nich. Taka komunikacja miedzy serwerami brzegowymi ma na celu rozpropa-gowanie w sieci informacji o adresatach dostepnych w danym AMS, natomiast w wypadkukomunikacji miedzy serwerami wewnetrznymi, słuzy do ustalenia serwera pocztowego,który jest w stanie doreczyc list do skrzynki pocztowej danego adresata. Nalezy zauwa-zyc, iz w tak skonstruowanym systemie moga zostac nałozone pewne ograniczenia, którespowoduja zminimalizowanie generowanego przez serwery pocztowe ruchu, ale jednocze-snie nie spowoduja spadku jego funkcjonalnosci. Po pierwsze, serwery wewnetrzne danejjednostki organizacyjnej powinny informacje o obsługiwanych adresach wymieniac jedyniemiedzy soba oraz z serwerami brzegowymi znajdujacymi sie w tym samym AMS. Wymianainformacji miedzy AMS zachodzic zas powinna jedynie na drodze komunikacji miedzy ser-werami brzegowymi. Osiagnac w ten sposób mozna pełna propagacje obsługiwanych ad-resów w sieci wykorzystujacej XMXP, jednoczesnie zapewniajac minimalna mozliwa iloscgenerowanego w tym celu ruchu sieciowego. Dalszym usprawnieniem, dotyczacym komu-nikacji wewnatrz danego AMS, jest mozliwosc wprowadzenia serwera pełniacego role tzw.replikatora sciezek (Mail Routes Replicator). Jego zadaniem byłoby zbieranie danych o ob-sługiwanych adresach docelowych przez poszczególne IMS, a nastepnie przekazywanie ichdo pozostałych serwerów wewnatrz danej organizacji. W ten sposób nawet wewnatrz jednejorganizacji ruch generowany przez wymiane informacji miedzy serwerami wykorzystuja-cymi XMXP moze byc ograniczany. W tak skonstruowanym systemie bardzo proste jest

42


wyznaczenie marszruty dla wiadomosci, która ma zostac przekazana dalej. System nadaja-cy wiadomosc sprawdza, czy jego tablica sciezek zawiera wpis odpowiadajacy adresatowiwiadomosci. Jezeli zostanie on znaleziony, to wiadomosc jest przekazywana do odpowied-niego serwera pocztowego, w przeciwnym zas wypadku – do najblizszego serwera brzego-wego, którego tablica sciezek powinna zawierac o wiele wiecej wpisów. Stosowanie takiejmetody zapewnia znalezienie dla danej wiadomosci odpowiedniej marszruty, która gwa-rantuje jej doreczenie do adresata, o ile tylko ona istnieje. Dodatkowo mozliwa jest równiezjej optymalizacja, jezeli tablice tras serwerów pocztowych zostana odpowiednio rozszerzo-ne.

Problemem bezposrednio powiazanym z wyznaczaniem marszrut wiadomosci jest ichadresowanie. W chwili obecnej na rynku poczty elektronicznej istnieje kilka róznych sche-matów adresowania, jednakze kazdy jest specyficzny dla protokołu, z którym jest zwiazany.Nie jest aktualnie mozliwe stosowanie wiecej niz jednego sposobu adresowania wiadomosciw ramach korzystania z jednego protokołu ich transportu. Oba najpopularniejsze schematyadresowania, tzn. zdefiniowany w RFC 2822 [25] uzywany z SMTP, a takze zdefiniowany wramach protokołu X.400 [10], ciesza sie szerokim gronem wielbicieli i uzytkowników, któ-rzy doceniaja ich zalety. Jednakze, moim zdaniem, udostepnienie uzytkownikom tylko jed-nego sposobu, którego zawsze musza uzywac do adresowania przesyłek pocztowych, jestwprowadzaniem niepotrzebnego ograniczenia do specyfikacji protokołu transportu pocz-ty elektronicznej. W zwiazku z tym, w ramach XMXP wprowadzona została mozliwoscdowolnego definiowania schematów adresowania poprzez tworzenie rozszerzen dla proto-kołu w formie, która zaprezentowana zostanie w dalszej czesci niniejszej pracy. Schematyte moga miec dowolna postac, a takze przenosic dowolne informacje, które przez ich auto-rów zostana uznane za przydatne przy adresowaniu przesyłki. Jedyne wymagania, któremoga zostac na nie nałozone, powiazane moga byc ze stosowanym protokołem wyzna-czania marszrut wiadomosci. Opisany powyzej protokół oparty o autonomiczne systemypocztowe nakłada na schemat adresowania wymaganie, aby zapisywany w nim adres byłmozliwy do podzielenia na czesc zwiazana z konkretna osoba adresata (tzw. „lewa”) orazz systemem pocztowym, w którym uzytkownik ten posiada konto (tzw. „prawa”). Z tegopowodu, domyslny, zwiazany z XMXP schemat tworzenia adresów pocztowych jest pro-stym odzwierciedleniem adresów uzywanych współczesnie w SMTP, jednakze posiadaja-cym bardziej rozbudowana hierarchizacje. W szczegółach zostanie on opisany w czesci 3.3.niniejszej pracy.

3.3. Opis protokołu

Jak juz wspomniane zostało we wczesniejszej czesci niniejszej pracy, proponowana postacEXTENSIBLE MAIL EXCHANGE PROTOCOL oparta została o XML. W zwiazku z tym, opisprotokołu, który podany zostanie ponizej, bedzie w duzej mierze polagał na przedstawie-niu zasad tworzenia dokumentów w tym jezyku, które stanowic maja sesje komunikacyjnanawiazana przy uzyciu XMXP. Formalna specyfikacja odpowiednich elementów tych do-kumentów w formie specyfikacji w jezyku XML Schema dostepna jest wraz z kodami zró-dłowymi stanowiacymi czesc niniejszej pracy. Ponizszy opis bedzie zas słuzyc ogólnemuprzedstawieniu mozliwosci XMXP, a takze zastosowanych w nim rozwiazan technicznych.

43


Oprócz opisu słownego, przedstawione zostana równiez schematy sesji wymiany informa-cji w opisywanym protokole, aby ułatwic zrozumienie przedstawianych propozycji, a takzezademonstrowac ich praktyczny przebieg.

Jak wiadomo, głównym zadaniem protokołu transportu poczty elektronicznej jest prze-kazanie wiadomosci od nadawcy do jej odbiorcy. Mozna nawet ujac kwestie te szerzej –jego zadaniem jest przekazanie wiadomosci od wezła sieci, który chce ja wysłac do we-zła, który został wyznaczony jako docelowy na danym etapie jej transportu. Stosowany wtakiej sytuacji jest mechanizm połaczenia inicjowanego przez nadawce, który znany jest zuzywanych współczesnie protokołów transportu poczty elektronicznej. Struktura wymie-nianych w tym przypadku w XMXP informacji moze zostac podzielona na dwie czesci:czesc kopertowa oraz czesc stanowiaca własciwa tresc wiadomosci. Podział ten wynika zcheci zapewnienia mozliwosci reakcji ze strony systemu odbierajacego na przesyłana wia-domosc natychmiast po przekazaniu mu podstawowych danych jej dotyczacych. Kopertawiadomosci w proponowanym przeze mnie formacie zawiera jedynie dane najbardziej nie-zbedne do identyfikacji przekazywanych informacji, a takze jej klasyfikacji pod wzgledemewentualnych warunków doreczenia. W zwiazku z tym znajduja sie w niej:

• adres nadawcy wiadomosci,

• adres odbiorcy wiadomosci,

• identyfikator wiadomosci – w proponowanym przeze mnie formacie wiadomosci po-winien byc on „prawie unikalny”, tzn. nalezy zapewnic mozliwie dobrze jego unikal-nosc, jednakze przy stosunkowo rzadkich powtórzeniach, nie sa one traktowane jakocecha kwalifikujaca dany identyfikator jako nieuzywalny w XMXP,

• podpis koperty wiadomosci w zaproponowanym powyzej formacie XML DSig wrazz certyfikatem odpowiednim dla klucza uzytego w celu jego wygenerowania, abymozliwa była weryfikacja tozsamosci nadawcy wiadomosci.

Na podstawie tak nadanej koperty wiadomosci system odbiorczy moze podjac decyzje, czydana wiadomosc zostanie zaakceptowana, a jesli tak, to na jakich warunkach – na przy-kład jaki koszt powinien poniesc nadawca w zwiazku z jej przesłaniem. Czesc wiadomosciprzenoszaca jej własciwa tresc, oprócz elementów analogicznych do tych zawartych w jejkopercie, moze przenosic dodatkowo nastepujace informacje:

• temat wiadomosci,

• streszczenie lub podsumowanie wiadomosci,

• dodatkowe informacje nagłówkowe,

• własciwe ciało wiadomosci bedace dowolnym ciagiem dowolnych znaków,

• informacje o załacznikach zwiazanych z dana wiadomoscia, podana jako lista ichidentyfikatorów.

44


Bardzo wazna cecha zarówno ciała wiadomosci, jak i informacji nagłówkowych, jest moz-liwosc wykorzystania dowolnych znaków, nie ograniczonych zadnym ich zestawem (oczy-wiscie poza zadeklarowanym podczas tworzenia dokumentu XML), a co za tym idzie –bezproblemowe przenoszenie informacji o znakach diaktrycznych dowolnego jezyka czytez danych binarnych.

Na kazda z czesci nadawanej wiadomosci odbiorca musi zareagowac wysyłajac odpo-wiedz. Ma ona na celu poinformowanie strony nadajacej o przebiegu transmisji, a takze odecyzji strony odbierajacej co do dalszego jej kształtu – czy moze byc ona kontynuowana bezprzeszkód, czy wymagana jest konkretna reakcja ze strony odbiorcy, czy tez czy transmisjamusi zostac zakonczona ze wzgledu na wystapienie błedu. W skład odpowiedzi wchodzanastepujace informacje:

• rodzaj odpowiedzi: sukces, ostrzezenie lub bład; jest on de facto wnioskowany z kon-kretnego rodzaju elementu przenoszacego odpowiedz,

• kod odpowiedzi umozliwiajacy jej przetwarzanie w sposób automatyczny przez sys-tem komputerowy, składajacy sie z trzech czesci: kodu modułu, który dana odpo-wiedz wygenerował, a takze głównego i drugorzednego kodu odpowiedzi informuja-cych o konkretnym rodzaju zdarzenia, które zaszło,

• słowny opis przesyłanej odpowiedzi majacy na celu ułatwienie człowiekowi jej inter-pretacji.

Specyficznym rodzajem odpowiedzi na przesłana wiadomosc, czy tez jej koperte, jest zaza-danie od nadawcy „opłacenia” kosztów jej transportu, a wiec przesłanie zadania (zwanegozagadka) do rozwiazania przez system pocztowy nadawcy. Jej konkretna postac zalezna jestod rodzaju opłaty zastosowanej w danym przypadku. Bez wzgledu na rodzaj przesłanejzagadki, odbiorca wiadomosci oczekuje odpowiedzi na nia (konkretny jej format równiezzalezy od rodzaju zastosowanej zagadki) i w razie jej nieotrzymania lub otrzymania niepo-prawnej – odrzuca nadawana wiadomosc. W niektórych przypadkach, zamiast odpowiedziczy zagadki, strona odbierajaca połaczenie moze na otrzymane dane zareagowac w innysposób, który opisany zostanie ponizej.

Aby zachowac poprawnosc w sensie jezyka XML, a takze umozliwic przetwarzanie da-nych przesyłanych w ramach EXTENSIBLE MAIL EXCHANGE PROTOCOL w prosty, automa-tyczny sposób przy pomocy najpopularniejszych przeznaczonych do tego technologii ta-kich, jak SAX, opisywane powyzej elementy zagniezdzone sa w elementach nadrzednych,zwanych elementami sesyjnymi. W procesie wymiany wiadomosci w tradycyjnym schema-cie nadawca→ odbiorca wystepuja trzy najwazniejsze elementy sesyjne:

• element bedacy nadrzednym dla danych wysyłanych przez nadawce wiadomosci,

• element nadrzedny dla odpowiedzi nadawanych przez jej odbiorce,

• specjalizowany element nadrzedny dla rozwiazan zagadek, które nadawca wiadomo-sci przesyła do odbiorców.

45


Ostatnie dwa rodzaje elementów sesyjnych sa wspólne dla wszystkich rodzajów komunika-cji, które wyróznic mozna w XMXP – zarówno dla przedstawionej powyzej standardowejwymiany wiadomosci, jak i dla pozostałych typów sesji wystepujacych w XMXP, które opi-sane zostana ponizej. Element zawierajacy w sobie sesje przekazywania odpowiedzi roz-poczynany jest w momencie, gdy pierwsza z odpowiedzi ma zostac wysłana przez strone,która odebrała połaczenie. Jego zamkniecie nastepuje zas w momencie, gdy któras ze stronpostanawia zakonczyc komunikacje. Podobnie obsługiwany jest element sesyjny zwiazanyz przesyłaniem rozwiazan zagadek, z tym, ze konczony jest on natychmiast po przekazaniuodpowiedniego rozwiazania, a wiec jego czas zycia jest znacznie krótszy niz całej sesji ko-munikacyjnej, a co za tym idzie – moze wystepowac w danej sesji wielokrotnie. Obydwa teelementy stworzone zostały, aby przenosic dokładnie okreslona informacje – odpowiednioelementy odpowiedzi lub elementy rozwiazan zagadek (i zadna inna tresc wewnatrz nichnie jest dozwolona). O wiele bardziej skomplikowany jest element sesyjny bedacy nadrzed-nym dla danych wysyłanych przez strone inicjujaca połaczenie. W omawianym przypadkujest to element przekazywania wiadomosci, który zawiera w sobie jej koperte oraz własci-wa jej tresc, których format został opisany powyzej. Warto zauwazyc, iz mozliwosci jednegoelementu sesyjnego nie sa ograniczone do przenoszenia jednej wiadomosci – strona nadaja-ca moze przesłac dowolnie wiele kopert i wiadomosci, w dowolnej kolejnosci pod warun-kiem, ze własciwa tresc danej wiadomosci bedzie wystepowac po odpowiadajacej jej koper-cie. Dodatkowo wewnatrz elementu sesyjnego przekazywania wiadomosci zagniezdzonymoze zostac inny element sesyjny – przekazywania załaczników – jezeli strona odbierajacawiadomosc zazada natychmiastowego ich doreczenia. Najprostszy schemat wykorzystaniatego typu sesji XMXP dla jednej wiadomosci został przedstawiony na rys. 3.1. Rozszerzeniego na wiele wiadomosci polega na wielokrotnym powtórzeniu czynnosci od (1) do (3), atakze od (3) do (5). Jezeli wraz z wiadomoscia przekazywane sa załaczniki, to punkt (5)z rys. 3.1. jest równoczesnie punktem (1) z rys. 3.2. W przypadku niepowodzenia komuni-kacji, któras z przesyłanych odpowiedzi zawiera kod błedu i sesja jest zrywana. Generalniezawartosc oraz znaczenie tego typu elementu nadrzednego jest rózna w zaleznosci od ro-dzaju komunikacji, który w danej chwili zachodzi miedzy jej uczestnikami, a wiec bedzieszczegółowo opisana w dalszej czesci niniejszego rozdziału.

Jest oczywiste, iz przekazanie tresci wiadomosci nie jest jedyna rola transportu pocztyelektronicznej. Mimo, iz z punktu widzenia wiekszosci jej uzytkowników, jest to zadanienajwazniejsze, to nie mniej istotnym jest przekazywanie załaczników, które niejednokrotniez wysyłanymi wiadomosciami sa zwiazane. W XMXP oba te zadania zostały od siebie od-dzielone. Jak juz wspomniano powyzej, nierozerwalna czescia wiadomosci jest jedynie listazałaczników (a dokładnie – ich identyfikatorów), które jej towarzysza. Własciwe załaczniki,czyli ich tresc, czy tez zawartosc, sa w proponowanym protokole zupełnie samodzielnymiobiektami i – jako takie – moga byc transportowane niezaleznie. Załaczniki opisywane sa wramach XMXP jako samodzielne elementy XML, których zawartosc stanowia:

• adres nadawcy wiadomosci (a co za tym idzie – równiez załacznika), z która danyzałacznik jest zwiazany,


• identyfikator załacznika tworzony w sposób analogiczny do identyfikatora wiadomo-sci,

• tytuł lub nazwa załacznika,

46


Rys. 3.1. — Schemat sesji przekazania wiadomosci w podstawowym jej przebiegu

• krótki opis zawartosci załacznika,

• własciwa zawartosc załacznika, która moze byc złozona z dowolnych bajtów danych,a wiec nie sa nakładane zadne ograniczenia na rodzaj przesyłanych załaczników,

• podpis załacznika tworzony w sposób analogiczny, jak dla podpisu obu czesci wiado-mosci.

Elementem nadrzednym, do którego zawsze naleza przesyłane załaczniki, jest element se-syjny przeznaczony do ich transportu. Moze on wystepowac zarówno jako samodzielnyelement, jak i zagniezdzony wewnatrz sesji przesyłania wiadomosci, jezeli załaczniki saprzesyłane jednoczesnie z nia. W skład tego elementu wchodzic moga jedynie elementystanowiace załaczniki, przy czym – podobnie jak ma to miejsce w przypadku sesji trans-portu wiadomosci – ich liczba nie jest w zaden sposób ograniczona. Przebieg podstawowejwersji tej sesji dla przesyłania jednego załacznika został zilustrowany na rys. 3.2.

Jak juz wielokrotnie zostało zaznaczone powyzej, prosty schemat przekazywania wiado-mosci od nadawcy do jej odbiorcy poprzez zapoczatkowanie komunikacji przez nadawce,który we współczesnej elektronicznej komunikacji pocztowej jest schematem najpopular-niejszym, nie jest jedyna mozliwoscia udostepniana przez EXTENSIBLE MAIL EXCHANGE

PROTOCOL. Mozliwe jest równiez, aby to adresat wiadomosci zazadał jej doreczenia przeznadawce w momencie, który jest dla niego dogodny. Stworzone zostały w tym celu dwa po-jecia: powiadomienie o oczekujacej wiadomosci oraz zadanie doreczenia wiadomosci. Po-wiadomienie jest wysyłane przez system nadajacy wiadomosc do jej odbiorcy w momencie,

47


Rys. 3.2. — Schemat sesji przekazania załaczników w podstawowym jej przebiegu

gdy z jakichs wzgledów (zwiazanych z systemem nadawczym lub odbiorczym) nie powin-na ona byc doreczona od razu. Ma ono forme specjalnego elementu sesyjnego, który za-wiera koperty wiadomosci (tu równiez nie sa nakładane zadne ograniczenia na ich liczbe),które czekaja na nadanie. System odbierajacy takie powiadomienie nastepnie, w ramachoddzielnego, równiez specjalizowanego elementu sesyjnego, zazadac powinien doreczeniadanych, które dla niego sa przechowywane w systemie nadawcy. Zadanie takie ma postacoddzielnego elementu XML, który zawiera nastepujace informacje wyodrebnione z kopertywiadomosci przekazanej wczesniej jako powiadomienie:

• adres nadawcy wiadomosci,


• identyfikator wiadomosci.

System, do którego dane zadanie jest skierowane, reaguje na jego otrzymanie rozpoczeciemsesji przekazywania wiadomosci zawierajacej odpowiednie koperty wiadomosci, a takze ichtresci. Analogiczny sposób doreczenia mozliwy jest w przypadku załaczników i w ramachXMXP zostały dla niego przewidziane analogiczne elementy XML. Jedyna róznica jest brakelementu stanowiacego powiadomienie odbiorcy o oczekujacym na niego załaczniku, gdyzte role spełnia lista załaczników przekazywana wraz z wiadomoscia – przesłanie samegozałacznika bez zwiazanej z nim wiadomosci nie jest mozliwe w proponowanym obecniekształcie protokołu, gdyz nie wydaje sie to byc działaniem sensownym w ramach transportupoczty elektronicznej. Schemat sesji dostarczania wiadomosci lub załaczników na zadanieprzedstawiony został na rys. 3.3. Jak mozna na nim zauwazyc, miedzy punktami (3) a(4) nie ma zdefiniowanego konkretnego czasu, co oznacza, ze odbiorca wiadomosci macałkowita dowolnosc w kwestii doboru dogodnego dla niego terminu jej doreczenia.

Oprócz protokołu wymiany wiadomosci, w ramach EXTENSIBLE MAIL EXCHANGE

PROTOCOL zdefiniowany został równiez sposób ich adresowania. Ze wzgledu na wyko-rzystanie XML, równiez adresy stanowia elementy tego jezyka. Aby uwzglednic specyfi-ke zaproponowanego protokołu wyznaczania marszruty wiadomosci, opisywana w tym

48


Rys. 3.3. — Schemat sesji przekazania wiadomosci lub załaczników w wersji dostarczenia nazadanie

miejscu specyfikacja proponuje, zgodnie z opisem w czesci 3.2. niniejszej pracy, podział ele-mentu przechowujacego adres na dwa elementy podrzedne: zawierajacy jego lewa czescoraz zawierajacy czesc prawa. Dodatkowo kazda z nich moze zawierac dowolna liczbe ele-mentów składowych, ułozonych w strukture hierarchiczna: kazdemu z nich nadany zostajeatrybut oznaczajacy stopien zajmowanej pozycji w tej strukturze – im jest ona nizsza, tymblizej szczytu dana czesc składowa sie znajduje. Schemat taki, jako bardzo ogólny, jest do-bra podstawa dla przyszłych rozszerzen (w formie schematów adresowania tworzonychw oddzielnych przestrzeniach nazw XML) i dospecyfikowania go w ramach implementacjiprzeznaczonych do konkretnych zastosowan, choc moze byc równiez wykorzystywany, wprzedstawionym kształcie, w rzeczywistych systemach komunikacyjnych.

Nierozerwalnie zwiazanym z adresowaniem, a takze wyznaczaniem marszruty wiado-mosci problemem jest wymiana adresów miedzy poszczególnymi systemami wykorzystu-jacymi XMXP. Przekazywanie adresów obsługiwanych przez poszczególne systemy pocz-towe, których struktura została opisana w rozdziale 3.2. niniejszej pracy, polega na przesy-łaniu specjalnie w tym celu opracowanych elementów XML, zwanych grupami adresów. Saone podobne do elementów stanowiacych adresy XMXP, z ta róznica, iz czesc lewa orazmniej znaczace (tzn. o wyzszych pozycjach) elementy czesci prawej – moga zostac pomi-niete. Daje to mozliwosc zapisania w zwiezły sposób duzej liczby adresów, które do danejgrupy maja nalezec – sa nimi wszystkie adresy, które zawieraja takie same elementy, jak ele-menty znajdujace sie w grupie adresowej, a takze ewentualne elementy dodatkowe. Grupaadresów przenosi takze informacje o schemacie adresowania (tzn. jego przestrzeni nazwXML), którego dotyczy, a takze o odległosci (tzn. liczbie maszyn przekazujacych wiadomo-sci), jaka musi pokonac wiadomosc, aby dotrzec do odbiorcy nalezacego do danej grupy,

49


Rys. 3.4. — Schemat sesji wymiany adresów w wersji dostarczenia na zadanie

jesli zostanie wysłana z systemu, który dana grupe adresowa nadał. Wymiana grup, podob-nie jak pozostałe rodzaje komunikacji miedzy systemami pocztowymi wykorzystujacymiXMXP, polega na przesyłaniu ich w ramach nadrzednego elementu sesyjnego. Przenosi onnastepujace informacje:

• dowolna liczbe grup adresowych,

• adres (IP, domenowy lub inny, który w przypadku danej komunikacji jest odpowied-nim sposobem adresowania systemów komputerowych), pod którym dostepny jestsystem pocztowy obsługujacy przesyłane grupy adresowe,

• dodatkowe informacje niezbedne, aby skontaktowac sie z tym systemem pocztowym,na przykład numer portu w przypadku TCP.

Podobnie jak pozostałe rodzaje wymiany informacji miedzy systemami pocztowymi pracu-jacymi w proponowanym przeze mnie protokole, tak i wymiana obsługiwanych przez niegrup adresowych zachodzic moze w dwóch trybach: inicjowanym przez system wysyłajacyobsługiwane przez siebie grupy adresowe, a takze na zadanie systemu, który ma byc ichadresatem. W pierwszym przypadku polega ona na prostym wysłaniu elementu sesji wy-miany adresów. Natomiast przy wykorzystaniu drugiego trybu, jest on wysyłany dopieropo otrzymaniu elementu zawierajacego zadanie takiej wymiany. Aby umozliwic efektywnawymiane duzej liczby grup adresowych, drugi sposób jest polecany ze wzgledu na mozli-wosci odpowiedniego stworzenia zadania: zawierac ono moze date stanowiaca dolna gra-nice dla czasu ostatniej modyfikacji grup adresowcyh w tablicy marszrut wiadomosci, któredla systemu odbierajacego sa interesujace. Oprócz niej, zadanie wymiany adresów zawiera

50


takze adres (i ewentualnie numer portu) systemu, do którego ma zostac skierowana odpo-wiedz. Daje to mozliwosc, bardzo polecana w celu zrównowazenia obciazenia systemówpocztowych, wysłania zadanych informacji w chwili dogodnej dla systemu nadawczego.Taka sytuacja została przedstawiona na rys. 3.4. Warto zauwazyc, iz sesje wymiany adre-sów w wersji inicjowanej przez strone nadajaca stanowia punkty (4) — (6) tego rysunku.

Przykładowa wiadomosc XMXP

Przedstawiony opis EXTENSIBLE MAIL EXCHANGE PROTOCOL stanowi teoretyczna specy-fikacje pozadanych jego cech, a takze metod zastosowanych w celu ich osiagniecia. Problemjednakze stanowic moze wyobrazenie sobie praktycznego wygladu komunikacji przebiega-jacej w ramach zaproponowanego protokołu. Aby ułatwic czytelnikowi to zadanie, ponizejzaprezentuje przykładowa wiadomosc przesyłana w omawianym protokole, a takze pobiez-nie omówie najistotniejsze jej elementy. Jako ilustracje opisu teoretycznego wybrałem samawiadomosc, gdyz zawarta jest w niej wiekszosc zaproponowanych wczesniej rozwiazan, ajednoczesnie stanowi ona przykład na tyle prosty, aby nie wymagał bardzo skomplikowanejanalizy.

1 <envelope id=" envelope " xmlns=" h t t p : //www. xmxp . net/spec/envelope /0.0 "><from xmlns=" h t t p : //www. xmxp . net/spec/t r a d i t i o n a l A d d r e s s /0.0 ">

< l e f t p o s i t i o n =" 0 "> g o l i s h </ l e f t >< r i g h t p o s i t i o n =" 0 ">net</ r i g h t >

5 < r i g h t p o s i t i o n =" 1 ">xmxp</ r i g h t ></from><to xmlns=" h t t p : //www. xmxp . net/spec/t r a d i t i o n a l A d d r e s s /0.0 ">

< l e f t p o s i t i o n =" 0 "> t e s t </ l e f t >< r i g h t p o s i t i o n =" 0 ">com</ r i g h t >

10 < r i g h t p o s i t i o n =" 1 ">example</ r i g h t ></to><ID xmlns=" h t t p : //www. xmxp . net/spec/message /0.0 ">

msg:−773956234965297404.1212483775387/ gol ish@niente . eu . org</ID>

15 <Signature xmlns=" h t t p : //www. w3 . org /2000/09/ xmldsig # "><SignedInfo>

<CanonicalizationMethodAlgorithm=

" h t t p : //www. w3 . org/TR/2001/REC−xml−c14n−20010315#WithComments "/>20 <SignatureMethod

Algorithm=" h t t p : //www. w3 . org /2000/09/ xmldsig # rsa−sha1 "/><Reference Id=" XMXPenvelope "

Type=" h t t p : //www. xmxp . net/spec/envelope /0.0 " URI=" # envelope "><Transforms>

25 <TransformAlgorithm=

" h t t p : //www. w3 . org /2000/09/ xmldsig #enveloped−s ignature "/></Transforms><DigestMethod

30 Algorithm=" h t t p : //www. w3 . org /2000/09/ xmldsig # sha1 "/><DigestValue> . . . </DigestValue>

</Reference></SignedInfo><SignatureValue> . . . </SignatureValue>

51


35 <KeyInfo><X509Data>

<X509SubjectName> . . . </X509SubjectName>< X 5 0 9 C e r t i f i c a t e > . . . </ X 5 0 9 C e r t i f i c a t e >

</X509Data>40 </KeyInfo>

</Signature></envelope>

<message id=" message " xmlns=" h t t p : //www. xmxp . net/spec/message /0.0 ">45 <from xmlns=" h t t p : //www. xmxp . net/spec/t r a d i t i o n a l A d d r e s s /0.0 ">

< l e f t p o s i t i o n =" 0 "> g o l i s h </ l e f t >< r i g h t p o s i t i o n =" 0 ">net</ r i g h t >< r i g h t p o s i t i o n =" 1 ">xmxp</ r i g h t >

</from>50 <to xmlns=" h t t p : //www. xmxp . net/spec/t r a d i t i o n a l A d d r e s s /0.0 ">

< l e f t p o s i t i o n =" 0 "> t e s t </ l e f t >< r i g h t p o s i t i o n =" 0 ">com</ r i g h t >< r i g h t p o s i t i o n =" 1 ">example</ r i g h t >

</to>55 <ID>

msg:−773956234965297404.1212483775387/ gol ish@niente . eu . org</ID>< s u b j e c t >Test message</ s u b j e c t ><summary/>

60 <headers/><body/><Signature xmlns=" h t t p : //www. w3 . org /2000/09/ xmldsig # ">

<SignedInfo><CanonicalizationMethod

65 Algorithm=" h t t p : //www. w3 . org/TR/2001/REC−xml−c14n−20010315#WithComments "/>

<SignatureMethodAlgorithm=" h t t p : //www. w3 . org /2000/09/ xmldsig # rsa−sha1 "/>

<Reference Id="XMXPmessage"70 Type=" h t t p : //www. xmxp . net/spec/message /0.0 " URI=" #message ">

<Transforms><Transform

Algorithm=" h t t p : //www. w3 . org /2000/09/ xmldsig #enveloped−s ignature "/>

75 </Transforms><DigestMethod

Algorithm=" h t t p : //www. w3 . org /2000/09/ xmldsig # sha1 "/><DigestValue> . . . </DigestValue>

</Reference>80 </SignedInfo>

<SignatureValue> . . . </SignatureValue><KeyInfo>

<X509Data><X509SubjectName> . . . </X509SubjectName>

85 < X 5 0 9 C e r t i f i c a t e > . . . </ X 5 0 9 C e r t i f i c a t e ></X509Data>

</KeyInfo></Signature>

</message>

Listing 3.1. — Przykładowa wiadomosc przesyłana w ramach XMXP

52


Przedstawiony powyzej dokument XML mozna, w sensie logicznym, podzielic na dwieczesci: koperte wiadomosci (linie 1 — 42) oraz sama tresc wiadomosci (linie 44 — 89).Najistotniejszymi elementami, które warto w przedstawionym przykładzie wyróznic, sa:

• postac adresów wykorzystywanych w zaproponowanym przeze mnie protokole –widoczne sa one w liniach 2 — 6 (adres nadawcy wiadomosci) oraz 7 — 11 (adresodbiorcy wiadomosci) w przypadku czesci kopertowej, a takze w liniach 45 — 49 i50 — 54 w przypadku własciwej tresci wiadomosci,

• kryptograficzny podpis zarówno koperty wiadomosci, jak i jej czesci przenoszacejtresc, widoczne odpowiednio w liniach 15 — 41 i 62 — 88; dla czytelnosci usunietezostały konkretne wartosci elementów kryptograficznych, jednakze pozostawiono ichnazwy, aby mozliwe było zorientowanie sie w zakresie przenoszonych informacji,

• przestrzenie nazw XML, w których umieszczone sa poszczególne elementy przedsta-wionego dokumentu – widoczne w całym przykładzie.

53

Rozdział 4.

Implementacja proof-of-concept XMXP

W rozdziale 3. niniejszej pracy przedstawione zostały podstawowe załozenia koncepcyjnetworzonego EXTENSIBLE MAIL EXCHANGE PROTOCOL, a takze opisana została jego propo-nowana postac. Jednakze, moim zdaniem, samo teoretyczne opracowanie protokołu trans-portu poczty elektronicznej nie jest wystarczajace, gdyz nie mówi absolutnie nic na temat je-go praktycznej uzytecznosci w rzeczywistych warunkach. W celu przeprowadzenia testówtego typu, jako czesc niniejszej pracy stworzona została implementacja typu proof-of-conceptXMXP, której opis bedzie przedmiotem dalszych moich rozwazan.

Jako ze celem stworzonej implementacji nie jest zbudowanie systemu transportu pocztyelektronicznej przeznaczonego do codziennego uzytku, czy to w zastosowaniach srodowi-ska biznesowego, czy nawet przy ograniczonych wymaganiach, jak na przykład przesyłaniewiadomosci w ramach sieci lokalnej, posiada ona pewne uproszczenia w stosunku do roz-wiazan zaproponowanych poprzednio. Przyczyna ich wprowadzenia była chec wyposrod-kowania pomiedzy stopniem skomplikowania tworzonej implementacji a jej funkcjonalno-scia. Oczywistym jest, iz w najlepszy sposób warunki wymiany wiadomosci pocztowychprzy uzyciu XMXP mozna byłoby zaobserwowac przy uzyciu implementacji realizujacejwszystkie mozliwosci proponowanego protokołu. Upraszczajac jednakze implementacje ipomijajac przy jej tworzeniu bardziej skomplikowane elementy protokołu, zyskac moznalepszy wglad w podstawy jego działania, a zatem przeprowadzic bardziej wnikliwe testyz nimi zwiazane. Równiez wyniki tych testów powinny byc bardziej miarodajne, jezeli opodstawowe aspekty działania tworzonego protokołu chodzi, gdyz mniejsze jest prawdo-podobienstwo, aby bardziej skomplikowane fragmenty implementacji zakłócały działaniejej podstawowych czesci.

Podstawowymi mozliwosciami XMXP zrealizowanymi w ramach opisywanej imple-mentacji sa elementy najwazniejsze dla wymiany poczty elektronicznej w ramach tego pro-tokołu. Naleza do nich:

54

ROZDZIAŁ 4. IMPLEMENTACJA proof-of-concept XMXP

• przesyłanie wiadomosci oraz załaczników do nich, tzn. ich transport i doreczanie doskrzynki pocztowej adresata przy uzyciu oprogramowania serwerowego, a takze wy-syłanie przy uzyciu oprogramowania klienckiego; zrealizowany został tryb przesyła-nia typu push jako podstawowa metoda dla transportu poczty elektronicznej na współ-czesnym rynku z nia zwiazanym,

• mozliwosc transportu załaczników do wiadomosci oddzielnie od nich samych, a takzeniezalezne ich doreczanie do skrzynek pocztowych uzytkowników,

• przekazywanie wiadomosci miedzy poszczególnymi systemami pocztowymi pozwa-lajace tworzyc skomplikowane ich marszruty,

• wymiana informacji o obsługiwanych adresach i ich grupach miedzy poszczególnymisystemami transportujacymi poczte elektroniczna, a co za tym idzie – wyznaczanie naich podstawie marszruty dla kazdej obsługiwanej wiadomosci,

• obsługa (tj. tworzenie oraz weryfikacja) podpisów kryptograficznych dla wiadomosci,a takze analiza certyfikatów zwiazanych z kluczem uzytym do tworzenia danegopodpisu w celu weryfikacji tozsamosci nadawcy i podjecia decyzji o przyjeciu lub niedanej wiadomosci,

• obciazanie nadawcy wiadomosci kosztami jej transportu poprzez wymaganie rozwia-zania „zagadki algorytmicznej” o znaczacym stopniu skomplikowania.

Pominiete podczas implementacji zostały zas wszystkie składniki XMXP zwiazane z dore-czaniem wiadomosci na zadanie jej odbiorcy, a wiec powiadomienia o oczekujacych wiado-mosciach i załacznikach w systemie pocztowym nadawcy, a takze mozliwosc zazadania ichdoreczenia przez adresata. Powodem rezygnacji akurat z tych mozliwosci był fakt, iz sa onenajmniej krytyczne dla działania całego protokołu, a takze stanowia najmniej innowacyjnez proponowanych rozwiazan. W zwiazku z powyzszym, a takze w swietle argumentów zatym, aby stworzyc implementacje nie zawierajaca nadmiernych komplikacji, podjałem de-cyzje, aby mozliwosci te zostały zaimplementowane w ciagu dalszego rozwoju EXTENSIBLE

MAIL EXCHANGE PROTOCOL, który wykracza poza ramy niniejszej pracy.

Mozliwosci oprogramowania stworzonego w ramach niniejszej pracy pozwalaja na zbu-dowanie w pełni funkcjonalnego (choc, jak juz zostało zauwazone – nie wykorzystujacegowszystkich mozliwosci proponowanego protokołu) systemu wymiany wiadomosci pocztyelektronicznej z wykorzystaniem XMXP. Znajduje sie, w zwiazku z tym, w jego ramachzarówno rozbudowana czesc serwerowa, jak i prosta aplikacja kliencka. Pierwsza z nichpozwala nie tylko na wymiane wiadomosci z innymi aplikacjami wykorzystujacymi tensam protokół, ale równiez na przekazywanie ich do systemów pocztowych obsługujacychSMTP, a takze na doreczanie listów do skrzynek pocztowych ich odbiorców. W ten sposóbmozliwa jest dosyc prosta integracja proponowanego przeze mnie rozwiazania ze srodo-wiskiem istniejacych i z powodzeniem wykorzystywanych obecnie systemów transportupoczty elektronicznej. Czesc kliencka zas jest prostym interfejsem linii komend pozwala-jacym na wysłanie wiadomosci pocztowej, wykorzystujac XMXP. Jej obsługa mozliwa jestzarówno w sposób interaktywny, jak i wsadowy, dzieki czemu moze ona zostac wykorzy-stana w wielu róznych zastosowaniach.

Zgodnie z przedstawionymi w rozdziale 3. załozeniami, XMXP daje mozliwosc stosowa-nia róznorodnych schematów adresowania wiadomosci. Jednakze tworzenie specyficznych

55


ich rodzajów wymaga znajomosci konkretnych warunków, w których proponowany przezemnie protokół ma zostac wdrozony. Konieczna równiez w tym celu jest dogłebna analizauwarunkowan zwiazanych z tym srodowiskiem, takich, jak: struktura organizacyjna uzyt-kowników poczty elektronicznej, typowe schematy przekazywania wiadomosci miedzy ni-mi itp. Jako ze niniejsza implementacja XMXP ma, z załozenia, stanowic uniwersalne narze-dzie pozwalajace na demonstracje mozliwosci proponowanego protokołu, postanowiłemwyposazyc ja w implementacje jedynie najbardziej standardowego schematu adresowania,omówionego juz wczesniej w niniejszej pracy – tzw. „tradycyjnego” adresowania bedacegobezposrednim odzwierciedleniem adresów pocztowych stosowanych w SMTP, zdefiniowa-nych przez RFC 2822 [25].

Niniejszy rozdział mojej pracy poswiecony zostanie opisowi technicznych rozwiazan za-stosowanych podczas tworzenia implementacji proof-of-concept XMXP, sposobowi jej reali-zacji, uzytkowego korzystania z niej, a takze analizie wyników testów, które przy jej pomocyzostały przeprowadzone.

4.1. Srodowisko implementacyjno-uruchomieniowe

Jednym z załozen przyjetych podczas tworzenia opisywanej implementacji XMXP był celzrealizowania jej w sposób pozwalajacy na mozliwie jak najwieksze uproszczenie powstaja-cego kodu zródłowego. Aby ten cel osiagnac, zastosowane zostało podejscie minimalizacjinakładów, których włozenie było konieczne w powstanie omawianych aplikacji. Srodkiemdo osiagniecia tego celu stało sie wykorzystanie jezyka programowania wysokiego pozio-mu, ułatwiajacego w sposób znaczacy rozwiazywanie podstawowych problemów pojawia-jacych sie podczas tworzenia tego typu oprogramowania, a takze gwarantujacego dostepdo duzej liczby bibliotek programistycznych pozwalajacych na szybka implementacje naj-czesciej wykonywanych w ramach XMXP zadan.

Wybranym przeze mnie jezykiem implementacji jest jezyk JAVA, gdyz doskonale spełniaon wszelkie przedstawione powyzej wymagania. Dodatkowo, jest to jezyk bardzo popular-ny współczesnie wsród programistów, dzieki czemu dostepna jest dla niego bardzo bogataliteratura obsługujaca praktycznie wszystkie mozliwe jego aspekty, od podstaw [35] az ponajbardziej zaawansowane zagadnienia z nim zwiazane. Jest to jezyk wspierajacy bardzopopularny współczesnie paradygmat programowania zorientowanego obiektowo – moimzdaniem, jeden z najnowoczesniejszych wykorzystywanych obecnie do tworzenia oprogra-mowania. Gwarantuje on wysoka skalowalnosc realizowanych rozwiazan, a takze, co jest zpoprzednia cecha zwiazane, ich modularnosc i mozliwosc realizacji programu w sposób jaknajlepiej modelujacy zdania, które ma on wykonywac.

Szczególnie istotnymi aspektami jezyka, a takze jego biblioteki standardowej, stanowia-cymi jedno z wazniejszych kryteriów wyboru podczas podejmowania decyzji dotyczacychsrodowiska implementacyjnego dla XMXP, sa jego mozliwosci rozpatrywane pod katemtworzenia aplikacji współbieznych, a takze wsparcie dla programowania usług sieciowych.Oba te zagadnienia w jezyku JAVA sa bardzo dobrze opracowane, a wachlarz dostepnychmozliwosci z nimi zwiazanych – bardzo szeroki. Jezeli chodzi o programowanie współbiez-ne, to w ramach srodowiska jezyka JAVA dostepne sa róznorodne narzedzia [36] wspierajace

56


te technike – od tak podstawowych, jak watki czy proste mechanizmy synchronizacyjne, azpo bardziej zaawansowane, dostepne od wersji 5.0 jezyka, jak kolekcje specjalizowane dowykorzystania w srodowisku wielowatkowym. Oprócz współbieznosci, jezyk JAVA wypo-sazony jest równiez w inne mechanizmy znaczaco wspomagajace tworzenie aplikacji maja-cych pracowac jako usługi sieciowe [37]. Nalezy wsród nich wymienic takie mozliwosci, jakbardzo łatwa w uzyciu obsługa gniazd sieciowych, a takze mozliwosc realizacji komunika-cji na wysokim poziomie abstrakcji, która została znaczaco rozbudowana od wersji 6 jezykaJAVA.

W zwiazku z powyzszymi cechami, jako srodowisko implementacyjno-uruchomieniowe dla niniejszej implementacji proof-of-concept EXTENSIBLE MAIL

EXCHANGE PROTOCOL wybrana została JAVA SE 6. Wybór najnowszej wersji jezykabył oczywisty z punktu widzenia najlepszego wsparcia dla wymaganych zastosowan, atakze z punktu widzenia niezawodnosci, gdyz poprawione w nim zostały liczne błedy po-przednich wersji tego srodowiska. Równiez jego dostepnosc była zaleta, która miała istotneznaczenie podczas podejmowania decyzji o wersji jezyka, która ma zostac uzyta – oficjalnewydanie JAVA 6 firmy Sun Microsystems jest dostepne na najwieksza liczbe platform,zarówno sprzetowych, jak i programowych, w historii tego srodowiska. Dostepnosc jesttez, po czesci, przyczyna oparcia implementacji XMXP o wersje standardowa jezyka JAVA.Jego wersja enterprise, mimo bardziej rozbudowanych mozliwosci, ma równiez wiekszeoraz bardziej specyficzne wymagania dotyczace srodowiska sprzetowo-programowegowymaganego do jej uruchomienia. W zwiazku z tym wybór padł na wersje SE, aby umoz-liwic bezproblemowe uruchomienie tworzonych aplikacji na bardzo szerokim wachlarzudostepnego sprzetu bez koniecznosci instalacji duzej ilosci dodatkowego oprogramowania.W konsekwencji sprawiło to, iz testowanie stworzonej implementacji uległo znacznemuuproszczeniu. Dodatkowa zaleta tej własnie wersji jest brak koniecznosci realizowaniaprojektu oprogramowania zgodnie z załozeniami jakiegokolwiek szkieletu, jak to mamiejsce w przypadku wersji EE. Daje to moim zdaniem lepsza kontrole nad tworzonaaplikacja, a co za tym idzie – mozliwosc dokładniejszego zrealizowania postawionych jejcelów. Oczywiscie cena, która nalezy za to zapłacic, jest koniecznosc implementacji nie-których mozliwosci, które w srodowisku enterprise sa standardowo dostepne, jednakze wprzypadku niniejszej implementacji XMXP mankament ten był praktycznie niezauwazalny.

Kolejna zaleta jezyka JAVA jest duza dostepnosc dedykowanych dla niego srodowiskprogramistycznych typu Integrated Development Enviroment. Omawiana implementacjaXMXP została stworzona przy uzyciu jednego z najlepszych i najbardziej zaawansowanychnarzedzi tego typu – dostepnego na licencji typu Free Software srodowiska Eclipse [38].Posiada ono wszystkie mozliwosci zwiazane ze wspieraniem procesu tworzenia i rozwi-jania oprogramowania, jakich mozna wymagac od współczesnego IDE. Integruje w sobiezaawansowany edytor kodu zródłowego, ułatwienia do korzystania z kompilatorów i de-bugerów, narzedzia testujace, zarzadzajace wersjami kodu zródłowego oraz wiele innych.Bardzo istotna jego zaleta jest mozliwosc rozszerzania funkcjonalnosci tego srodowiska po-przez mechanizm wtyczek – dostepna ich liczba jest bardzo imponujaca i pozwala praktycz-nie kazde zadanie zwiazane z codzienna praca programisty zrealizowac (a czesto równiezzautomatyzowac) przy pomocy Eclipse.

Wspomniana juz wczesniej łatwa przenaszalnosc programów stworzonych w JAVA SEjest ogólna cecha aplikacji realizowanych w tym jezyku. Powodem tego jest fakt, iz kod

57


zródłowy jezyka JAVA nie jest kompilowany do natywnego kodu wykonywalnego, specy-ficznego dla danej platformy sprzetowo-programowej, ale do tzw. byte-code, który nastepniepodlega interpretacji srodowiska uruchomieniowego i ewentualnie kompilacji do formy na-tywnej w momencie uruchomienia (tzw. Just-in-Time compiling). Jest to jedna z przyczynogromnej popularnosci jezyka JAVA w ostatnim czasie, gdyz pozwala programistom uru-chamiac tworzone przez siebie aplikacje w wielu róznych heterogenicznych srodowiskachprzy minimalnym wkładzie pracy zwiazanym z ich uniwersalnoscia i niezaleznoscia odplatformy, na której były tworzone, gdyz cechy te sa gwarantowane przez sam jezyk i jegosrodowisko uruchomieniowe. Argument ten równiez miał duze znaczenie podczas wybo-ru jezyka JAVA jako podstawy, na której miała zostac oparta implementacja proof-of-conceptXMXP, gdyz wpisuje sie on w ogólna filozofie stosowana podczas jego projektowania mó-wiaca o uniwersalnosci i rozszerzalnosci rozwiazan z nim zwiazanych.

4.2. Zastosowane biblioteki

Jak juz zostało w niniejszej pracy wspomniane, podczas tworzenia implementacji proof-of-concept EXTENSIBLE MAIL EXCHANGE PROTOCOL stosowane było bardzo popularne współ-czesnie podejscie do programowania – polegajace na wykorzystywaniu dostepnych po-wszechnie komponentów do realizacji zamierzonych celów. Słuzace temu celowi bibliotekiprogramistyczne dostepne sa, w tej czy innej formie, praktycznie dla kazdego nowoczesne-go jezyka programowania wysokiego poziomu. Jednak szczególne cechy jezyków wspie-rajacych programowanie zorientowane obiektowo, pokrótce wymienione juz w poprzed-nim punkcie, sprawiaja, iz liczba dostepnych dla nich bibliotek jest wrecz ogromna. Wartozauwazyc, ze pod tym wzgledem jezyk JAVA znajduje sie w scisłej czołówce – nie tylko do-stepne sa dla niego biblioteki realizujace wszystkie najczesciej spotykane w programowaniuzadania, ale takze dla wielu z zadan specyficznych, niszowych równiez istnieja gotowe im-plementacje. Ich liczba jest tak wielka, ze niejednokrotnie programista staje przed koniecz-noscia wyboru tej sposród bibliotek rozwiazujacych dany problem, która najlepiej spełniajego wymagania czy tez po prostu najbardziej przypada mu do gustu.

W przypadku jezyka JAVA sytuacja zwiazana z zastosowaniem bibliotek jest o tyle szcze-gólna, ze znakomita czesc niezbednych w przypadku implementacji XMXP mozliwosci do-stepna jest bezposrednio w standardowej bibliotece jezyka. To własnie ona była jako pierw-sza rozpatrywana podczas wyboru odpowiedniego rozwiazania danego problemu. Dopierow dalszej kolejnosci brane były pod uwage rozwiazania zewnetrzne, stworzone przez nie-zalezne organizacje czy tez osoby.

Do najwazniejszych elementów implementacji proof-of-concept XMXP zrealizowanych zapomoca rozwiazan biblioteki standardowej jezyka JAVA nalezy zaliczyc:

• Przetwarzanie dokumentów jezyka XML — jako ze cały ruch sieciowy wymienianymiedzy komunikujacymi sie stronami w XMXP zawarty jest w dokumentach XML,to ich efektywne i łatwe w realizacji przetwarzanie było kluczowym problemem dorozwiazania podczas tworzenia niniejszej implementacji tego protokołu. Narzedziem,które do osiagniecia tego celu zostało wykorzystane, jest dostarczana wraz ze srodo-wiskiem uruchomieniowym jezyka JAVA implementacja JAVA API for XML Processing

58


[39]. Udostepnia ona bardzo uniwersalne narzedzia słuzace do tworzenia oraz prze-twarzania dokumentów w jezyku XML – zarówno przy podejsciu strumieniowym,jak i poprzez reprezentacje ich jako obiektów w programie. Stosowane w tej biblio-tece metody dostepu do danych zawartych w dokumentach XML korzystaja z najno-woczesniejszych i najpopularniejszych rozwiazan dostepnych współczesnie na rynku,takich, jak Document Object Model czy Simple API for XML, bardzo zgrabnie integru-jac je ze srodowiskiem jezyka Java.

• Przetwarzanie podpisów cyfrowych w standardzie XML DSig — jest to zadanie po-srednio powiazane z samym przetwarzaniem dokumentów XML, wiec do jego ce-lu została wykorzystana bardzo dobrze zintegrowana z JAXP biblioteka JAVA XMLSignature API, która stanowi jedna z wazniejszych nowosci w wersji szóstej tego sro-dowiska. Pozwala ona w prosty i efektywny sposób zrealizowac wszystkie najwaz-niejsze zadania, które czekaja na programiste podczas tworzenia aplikacji wykorzy-stujacej XML DSig, takie, jak tworzenie podpisów wiadomosci, ich weryfikacja czytez analiza pod katem zawartosci poszczególnych jego czesci (na przykład w celuwyodrebnienia z podpisu certyfikatu odpowiadajacego kluczowi publicznemu, któryzostał wykorzystany do jego stworzenia). Powiazane z ta biblioteka jest drugie roz-wiazanie standardowo zawarte w srodowisku uruchomieniowym jezyka JAVA – JAVA

Cryptography Architecture [40]. Jest to zestaw narzedzi ułatwiajacych obsługe rózne-go rodzaju zagadnien kryptograficznych takich, jak na przykład zarzadzanie kluczamiczy certyfikatami, wyliczanie skrótów kryptograficznych itp. W niniejszej implemen-tacji XMXP został on miedzy innymi wykorzystany do obsługi kluczy i certyfikatówzwiazanych z podpisami kryptograficznymi poszczególnych elementów wiadomosci,a takze podczas tworzenia i rozwiazywania „zagadek algorytmicznych”.

• Wiele typowych zadan programistycznych, pojawiajacych sie podczas tworzenia takduzego i skomplikowanego projektu, jakim niewatpliwie jest niniejsza implementa-cja proof-of-concept XMXP – miedzy innymi obsługa skomplikowanych struktur da-nych (list, tablic asocjacyjnych itp.), komunikacja poprzez siec, a takze przy pomocystandardowego wejscia/wyjscia, jak równiez poprzez wykorzystanie plików, obsługawatków itp.

Oprócz bardzo rozbudowanej biblioteki standardowej, jezyk JAVA, jak juz wspomnia-łem, poszczycic sie moze bardzo duza liczba zewnetrznych bibliotek. W niniejszej imple-mentacji XMXP wykorzystane zostało kilka z nich – wiekszosc dostepnych publicznie wsieci Internet, ale równiez jedna, której jestem współautorem, a która nie jest dostepna dlaszerszej publicznosci. Biblioteki te odegrały istotna role uzupełnienia, a w jednym przy-padku rozszerzenia, mozliwosci klas dostepnych standardowo wraz ze srodowiskiem uru-chomieniowym jezyka JAVA, dzieki czemu jeszcze szerszy wachlarz typowych problemówmógł zostac rozwiazany w sposób łatwy i efektywny.

Biblioteki zewnetrzne, które znalazły zastosowanie podczas tworzenia implementacjiproof-of-concept XMXP to:

• JavaMail — jest to biblioteka autorstwa firmy Sun Microsystems stanowiaca czescstandardowej biblioteki dostarczanej wraz ze srodowiskiem uruchomieniowym wwersji enterprise jezyka JAVA, zas dla pozostałych jego edycji dostepna jest ona jako

59


zewnetrzna biblioteka do pobrania ze strony WWW firmy. Zgromadzone w jej ra-mach klasy pozwalaja programiscie zrealizowac obsługe poczty elektronicznej w naj-popularniejszych obecnie protokołach takich, jak SMTP, POP3 czy IMAP. Umozliwiaona równiez przetwarzanie i tworzenie samych wiadomosci pocztowych, wykorzy-stujac wszystkie mozliwosci formatu MIME, a wiec miedzy innymi obsługe rózno-rodnych kodowan znaków w tekscie, wiadomosci wieloczesciowe czy tez dołaczaniezałaczników. Zawarte w tej bibliotece sa równiez klasy dajace dostep do najnowszychi najpopularniejszych rozszerzen wymienionych protokołów – np. Delivery StatusNotifications dla SMTP. W niniejszej implementacji XMXP biblioteka ta jest stosowanadwojako. Po pierwsze wykorzystana jest w procesie konwersji wiadomosci w formacieXMXP (tzn. w postaci dokumentów XML) na „klasyczne” wiadomosci poczty elektro-nicznej w formacie zgodnym ze standardem MIME. Drugim zas jej zastosowaniemjest implementacja jednej z wazniejszych mozliwosci stworzonego serwera XMXP –transportu poczty miedzy siecia systemów komunikujacych sie za pomoca XMXP asystemami wykorzystujacymi SMTP.

• Log4J — jest to biblioteka bedaca czescia projektu Logging Services, prowadzonegoprzez fundacje Apache. Podobnie jak pozostałe biblioteki skupione w tym projekcie,ma ona za zadanie dostarczyc programistom gotowego rozwiazania do tworzenia pli-ków dziennika zdarzen dla aplikacji. Rozwiazania zawarte w tej bibliotece odznaczajasie wysoka niezawodnoscia, bardzo dobra szybkoscia działania, a takze ogromna ela-stycznoscia i to własnie te argumenty sprawiły, iz została ona zastosowana zamiast do-stepnej standardowo wraz ze srodowiskiem uruchomieniowym jezyka JAVA bibliotekiJAVA Logging API. Biblioteka Log4J wykorzystywana jest do zapisywania w usyste-matyzowany sposób dzienników zdarzen, które zachodza podczas działania aplikacjistworzonych w ramach omawianej implementacji XMXP, a wiec pozwala sledzic ichdziałanie i obserwowac proces realizacji wykonywanych przez nie zadan.

• Apache Commons Collections — jest to pierwsza z wykorzystywanych w implemen-tacji proof-of-concept XMXP bibliotek, które powstały w ramach projektu Java Com-mons, prowadzonego przez fundacje Apache. Jest to projekt nadrzedny dla wielutworzonych pod opieka fundacji Apache bibliotek programistycznych jezyka JAVA ima on na celu zgromadzenie ich w ramach wspólnego repozytorium uniwersalnychkomponentów, które moga byc stosowane w wielu róznych aplikacjach realizowanychprzy uzyciu tego jezyka. Główna zasada kierujaca tym projektem jest dazenie do two-rzenia bibliotek charakteryzujacych sie wspólnymi interfejsami, podobna logika dzia-łania, a takze wysoka jakoscia kodu zródłowego. Omawiana tu biblioteka rozszerzaliste dostepnych w standardowej bibliotece jezyka JAVA struktur danych o dodatko-we, bardziej zaawansowane kolekcje, takie, jak na przykład dwukierunkowa tablicaasocjacyjna, rózne rodzaje zbiorów czy list.

• Apache Commons IO — biblioteka ta jest zbiorem narzedzi ułatwiajacych obsługestandardowych strumieni wejscia/wyjscia jezyka JAVA. Pozwala ona na efektywnai łatwa realizacje czesto spotykanych zadan zwiazanych z ich obsługa, które nie sazaimplementowane w ramach biblioteki standardowej – na przykład ciagłego kopio-wania danych ze strumienia wejsciowego do wyjsciowego, porównywania zawartoscistrumieni czy tez ich filtrowania. Dzieki abstrakcji operacji na strumieniach w jezykuJAVA, klasy i metody z biblioteki Commons IO mozna wykorzystywac bez wzgledu

60


na rodzaj uzywanych operacji wejscia/wyjscia – zarówno dla operacji na plikach, stru-mieniach danych pochodzacych z sieci, jak i na przykład przy komunikacji z urucho-mionym przez aplikacje procesem zewnetrznym, do czego własnie zostały one wyko-rzystane w niniejszej implementacji XMXP.

• Apache Commons Daemon — biblioteka ta została poczatkowo stworzona na po-trzeby serwera aplikacyjnego Apache Tomcat, lecz z czasem jej rozwój został przejetyprzez projekt Apache Commons. Jest to zestaw narzedzi ułatwiajacych uruchamianieaplikacji jezyka JAVA w sposób podobny do programów typu daemon, popularnychw srodowisku systemów uniksowych. Daje on mozliwosc stworzenia usługi systemo-wej, która uruchamiana bedzie w sposób specyficzny dla danego systemu, czy to podkontrola systemu uniksowego, czy tez systemu Microsoft Windows. Warto przy tymzauwazyc, iz nakład pracy wymagany ze strony programisty tworzacego aplikacje jestminimalny i sprowadza sie do zaimplementowania kilku prostych metod – cała resztazagadnien rozwiazywana jest przez dostarczone wraz z biblioteka oprogramowanie.W niniejszej implementacji XMXP opisane mozliwosci sa wykorzystywane do kontro-li uruchamiania i działania głównego procesu jej serwerowej czesci.

• Bouncy Castle — jest to alternatywna implementacja dla opisanego wczesniej JCA roz-prowadzanego standardowo wraz ze srodowiskiem uruchomieniowym jezyka JAVA.Jej zaletami w stosunku do implementacji dostarczanej przez firme Sun Microsystemssa zdecydowanie wieksze mozliwosci – wieksza liczba obsługiwanych formatów orazalgorytmów kryptograficznych, a takze dodatkowe funkcje pozwalajace na realiza-cje zadan nie uwzglednionych w standardowej implementacji JCA, na przykład nazarzadzanie kluczami i certyfikatami przechowywanymi w zewnetrznych plikach. Womawianej implementacji XMXP biblioteka jest wykorzystywana wszedzie tam, gdziemozliwosci standardowego JCA okazuja sie nie byc wystarczajace, a wiec obie te im-plementacje uzywane sa naprzemiennie.

• JArgs — jest to prosta biblioteka pozwalajaca na szybkie i efektywne przetwarzanieopcji linii komend wykorzystywanych przez wiele programów do przyjmowania po-lecen od uzytkownika. Powodem wyboru akurat tej biblioteki sposród bardzo wieluo podobnych mozliwosciach, jest jej prostota – zarówno pod wzgledem wykorzysta-nia jej w tworzonej implementacji, jak i jesli chodzi o kod zródłowy samej biblioteki,co znaczaco i w sposób pozytywny wpływa na sprawnosc jej działania. Bibliotekata zastosowana została w czesci klienckiej implementacji proof-of-concept XMXP, abyumozliwic wykorzystywanie powstałej aplikacji w sposób wsadowy.

• Niente Application Utilities — jest to biblioteka stworzona jako wspólne przedsie-wziecie Sławomira Chyłka (mailto:[email protected]) i moje. Nie jest onapublicznie dostepna ze wzgledu na ograniczony obszar jej zastosowan (została jednakdołaczona wraz z kodem zródłowym stanowiacym integralna czesc niniejszej pracy).Strukture tej biblioteki mozna podzielic na dwie zasadnicze czesci. Pierwsza z nichstanowi biblioteka obsługujaca odczytywanie i zapisywanie konfiguracji programów.Cechami, które wyrózniaja ja sposród wielu podobnych sa zaawansowane mozliwoscisprawdzania poprawnosci wczytywanych danych, a takze przypisywania im warto-sci domyslnych oraz mozliwosc okreslania formatu struktur danych zawierajacychparametry konfiguracyjne (a jednoczesnie plików konfiguracyjnych) w sposób dekla-ratywny – przy uzyciu jezyka XML Schema. Równie cenna mozliwoscia jest bezpo-srednie odwzorowywanie obiektów konfiguracyjnych w jezyku JAVA na dokumenty

61


XML w formie plików znajdujacych sie na dysku komputera, co jest wykonywaneprzy pomocy biblioteki Apache XML Beans, tworzonej w ramach Apache XML Pro-ject. Druga czesia Niente Application Utilities jest zestaw klas zawierajacych pomocni-cze struktury danych, których uzycie okazało sie niezbedne (lub po prostu wygodne)w ramach projektów tworzonych przez jej autorów. Podczas tworzenia niniejszej im-plementacji XMXP wykorzystywane były znajdujace sie w niej klasy reprezentujacen-tki uporzadkowane.

Wielkie znaczenie zastosowania bibliotek programistycznych w tak rozbudowanym iskomplikowanym projekcie, jakim jest implementacja proof-of-concept EXTENSIBLE MAIL

EXCHANGE PROTOCOL jest oczywiste. Jednak bardzo dobra jego ilustracja jest ilosc koduzródłowego, która w ramach tej implementacji powstała – jest to około 13.5 tysiaca linii.Mozna sobie wyobrazic, ze stworzenie tego rozmiaru aplikacji przy jednoczesnej koniecz-nosci zrealizowania samodzielnie i od podstaw wszystkich opcji dostepnych w zastoso-wanych bibliotekach byłoby praktycznie niewykonalne w porównywalnym czasie i przyporównywalnej jakosci tworzonych rozwiazan.

4.3. Opis uruchomieniowy

W niniejszej czesci mojej pracy postaram sie zaprezentowac sposób wykorzystania stworzo-nych aplikacji w celu samodzielnego uruchomienia systemu wymiany poczty wykorzystu-jacego EXTENSIBLE MAIL EXCHANGE PROTOCOL. Przedstawie kroki niezbedne do stwo-rzenia wersji uruchomieniowej systemu pod warunkiem posiadania kodu zródłowego, atakze opisze najwazniejsze zagadnienia zwiazane z jego uzytkowaniem, takie, jak zakres imetody interakcji z omawianymi aplikacjami. Zaprezentowany opis bedzie traktował oma-wiana implementacje proof-of-concept XMXP jako tzw. black box, tzn. nie bedzie wymaganaod uzytkownika zadna wiedza dotyczaca sposobu, w jaki została ona zrealizowana.

Aby mozliwe było uruchomienie elementów systemu składajacych sie na niniejsza im-plementacje XMXP, srodowisko, w którym podejmowana jest taka próba spełniac musipewne okreslone wymagania. Pierwszym z nich jest instalacja standardowej edycji sro-dowiska uruchomieniowego jezyka JAVA w wersji 6 lub pózniejszej. Aplikacje wchodza-ce w skład opisywanej implementacji XMXP nie beda współpracowac z inna jego wersja, zewzgledu na wykorzystanie najnowszych mozliwosci tego srodowiska, które po czesci zosta-ły opisane wczesniej w niniejszym rozdziale. Drugim, równie oczywistym, wymaganiem,jest koniecznosc posiadania zainstalowanych w systemie bibliotek programistycznych, któ-re wymienione zostały powyzej. Aby uniknac niezgodnosci wynikajacych z zastosowaniaodmiennych wersji bibliotek niz uzywane podczas rozwoju omawianych aplikacji, zalecasie wykorzystywanie ich kopii dostarczonych wraz z kodem zródłowym stanowiacym in-tegralna czesc niniejszej pracy.

Dodatkowe wymagania pojawiaja sie w momencie, gdy uzytkownik bedzie miał za za-danie skompilowanie kodu zródłowego opisywanego systemu. Mozliwe sa dwa sposobyjego realizacji. Pierwszym, o wiele prostszym i z tego powodu polecanym, jest uzycie bar-dzo popularnego w srodowisku programistów wykorzystujacych jezyk JAVA systemu bu-dowania aplikacji Ant autorstwa fundacji Apache. Wraz z kodem zródłowym dostarczany

62


jest plik sterujacy build.xml przeznaczony dla tego systemu, wiec przeprowadzenie pro-cesu budowy wersji uruchomieniowej aplikacji sprowadza sie do uruchomienia narzedziabudujacego poleceniem:

$ ant

Druga mozliwoscia, polecana dla osób zamierzajacych analizowac lub poprawiac kod zró-dłowy aplikacji składajacych sie na niniejsza implementacje XMXP, jest wykorzystanie sro-dowiska programistycznego Eclipse, które zostało opisane wczesniej w niniejszej pracy.Wraz z kodem zródłowym dostarczane sa odpowiednie pliki konfiguracyjne, które pozwa-laja w prosty sposób zaimportowac go jako projekt we wspomnianym IDE. Oczywistym jestfakt, iz w kazdym z omówionych przypadków nalezy zadbac, aby odpowiedni dla danegonarzedzia plik konfiguracyjny (tj. build.xml w przypadku systemu Ant i .classpathw przypadku srodowiska Eclipse) zawierał odpowiednio zdefiniowane sciezki do plikówwykorzystywanych bibliotek, a takze nalezy posiadac srodowisko programistyczne jezykaJAVA, a nie jedynie uruchomieniowe, które jest wystarczajace przy samym uzywaniu wersjibinarnych dostarczonego systemu.

Zastosowanie srodowiska JAVA do stworzenia implementacji proof-of-concept XMXP teo-retycznie daje mozliwosc wykorzystania jej na komputerze działajacym pod kontrola jedne-go z wielu systemów operacyjnych, dla których jest ono dostepne. Jednakze ze wzgledu nawykorzystanie biblioteki Apache Commons Daemon, lista ta musiała zostac ograniczona dosystemów uniksowych. Co prawda, teoretycznie istnieje mozliwosc uruchomienia aplikacjija wykorzystujacych równiez pod kontrola systemu Microsoft Windows, jednakze instruk-cje dotyczace tego procesu podane przez autorów sa dosc enigmatyczne, a samo działanietakich programów niezbyt dobrze przetestowane, wiec w procesie tworzenia omawianejimplementacji XMXP postanowiłem zrezygnowac z jej wykorzystania. Ograniczenie to niedotyczy oczywiscie czesci klienckiej stworzonego oprogramowania, gdyz przy jej tworze-niu wykorzystanie wspomnianej biblioteki nie było zasadne.

W celu ułatwienia uzytkownikom korzystania ze stworzonych aplikacji, dostarczanewraz z nimi sa skrypty uniksowej powłoki sh znacznie upraszczajace ich wywoływanie.„Ukrywaja” one przed uzytkownikiem koniecznosc zdefiniowania odpowiednich opcji uru-chomieniowych wirtualnej maszyny jezyka JAVA, takich, jak na przykład skomplikowanalista sciezek przeszukiwania klas czy nazw klas słuzacych do uruchomienia danej aplikacji.Nalezy jednak pamietac, aby przed pierwszym ich uzyciem wyedytowac kazdy z nich wcelu sprawdzenia i ewentualnego skorygowania w sposób odpowiedni dla danego systemusciezek w nich zaszytych.

4.3.1. Aplikacja serwerowa

Aplikacja realizujaca mozliwosci serwera poczty elektronicznej transportowanej z wykorzy-staniem XMXP, mimo swych dosc rozbudowanych mozliwosci, jest stosunkowo prosta wobsłudze. Wspomniany juz wyzej skrypt uruchomieniowy pozwala na wystartowanie jejjedna, prosta komenda. Ma ona postac:

63


$ xmxp-server.sh {start|stop}

Omawiany skrypt przyjmuje jeden parametr linii komend oznaczajacy rodzaj akcji, któryma zostac wykonany: uruchomienie serwera XMXP lub tez jego zatrzymanie – w przypad-ku, gdy działa on juz w systemie. Realizacja tych zadan odbywa sie przy uzyciu narzedziajsvc, które stanowi integralny składnik biblioteki Apache Commons Daemon. Słuzy onodo kontroli procesów systemowych (zwanych usługami), które przy uzyciu tej biblioteki satworzone. Pozwala na uruchamianie, zatrzymywanie, a takze sprawdzanie stanu działaniakazdej z usług, dzieki czemu uzytkownik ma nad nimi pełna kontrole. Narzedzie to realizu-je równiez przekierowanie do plików strumieni wejscia i wyjscia uruchamianych procesów,dzieki czemu mozliwe jest w kazdej chwili obejrzenie ich zawartosci, w tym równiez histo-rycznej.

Interakcja uzytkownika z aplikacja serwera XMXP w trakcie jej działania nie jest wyma-gana, a co za tym idzie – nie jest równiez mozliwa. Cała jej obsługa skupia sie na dwóch naj-wazniejszych czynnosciach: stworzeniu odpowiedniego do wymagan uzytkownika plikukonfiguracyjnego oraz sledzenia i analizy komunikatów znajdujacych sie w plikach dzien-nika. Oba te elementy zostana w szczegółach opisane w dalszej czesci niniejszej pracy. Istot-ne jest, aby uzytkownik przed uruchomieniem aplikacji serwerowej XMXP zapoznał sie zpostacia obydwu tych plików i dokonał przynajmniej minimalnych zmian w konfiguracji,aby dostosowac działanie wdrazanego oprogramowania do srodowiska, w którym ma onopracowac. Do najbardziej newralgicznych opcji konfiguracyjnych naleza:

• adres IP, pod którym widoczny jest dany system w sieci, w której ma on pracowac,

• lista grup adresów docelowych obsługiwanych przez dany system pocztowy,

• lista przyporzadkowujaca konkretnym z tych adresów odpowiadajace im nazwy uzyt-kowników lokalnego systemu,

• lista innych znanych systemów obsługi poczty elektronicznej wraz z przypisanymi imgrupami adresów, które kazdy z nich obsługuje.

Pozostałe klucze konfiguracji moga pozostac niezmienione (tzn. w postaci, w której dostep-ne sa w przykładowym pliku konfiguracyjnym dostepnym w dodatku A.), jezeli wymaganyjest jedynie podstawowy zakres działania aplikacji. Wszystkie pozostałe opcje konfigura-cyjne słuza wykorzystaniu bardziej zaawansowanych mozliwosci, które omawiany systemudostepnia lub tez lepszemu jego dostosowaniu do uwarunkowan srodowiska, w którymma on pracowac.

Oprócz wymagan opisanych juz w niniejszym rozdziale, system, w którym uruchomio-na ma zostac aplikacja serwera XMXP powinien spełniac pewne dodatkowe kryteria, wy-nikajace ze specyfiki zastosowanych w nim rozwiazan. Ich szczegółowa postac zalezy odpolityki bezpieczenstwa realizowanej przez administratorów danego systemu, jednakze juzw tym momencie warto zauwazyc, iz niezbedne jest posiadanie uprawnien superuzytkow-nika w systemie docelowym, gdyz jest to wymagane miedzy innymi przez program jsvc.Oczywistym faktem jest zatem, iz posiadajac tego typu uprawnienia, realizacja dalszych

64


wymagan, takich jak dostep do komunikacji sieciowej na odpowiednim porcie czy tez moz-liwosc skorzystania z pewnych narzedzi systemowych, nie powinna nastreczac uzytkowni-kowi wiekszych problemów.

4.3.2. Aplikacja kliencka

Drugim elementem wchodzacym w skład systemu transportu poczty elektronicznej, zre-alizowanego w ramach implementacji proof-of-concept XMXP, jest aplikacja kliencka. W od-róznieniu od czesci serwerowej omawianej implementacji, jest to aplikacja stosunkowo pro-sta, zarówno pod wzgledem nakładów pracy włozonych w jej stworzenie, jak i mozliwo-sci przez nia udostepnianych uzytkownikowi. Pozwala ona na wysyłanie wiadomosci przyuzyciu XMXP w sposób łatwy, efektywny, a dzieki dostepnemu dwojakiemu interfejsowiuzytkownika – wsadowemu oraz interaktywnemu – równiez wygodny i adekwatny dladanego zastosowania. Oba z wymienionych trybów pracy w sposób bardziej szczegółowyzostana opisane ponizej.

Jako, ze niniejsza implementacja XMXP stanowi jedynie proof-of-concept zwiazany z za-proponowanym protokołem, a nie jest przeznaczona do codziennego zastosowania przezuzytkowników koncowych, wprowadzone zostały pewne ograniczenia funkcjonalne, maja-ce na celu jej uproszczenie zwiazane z decyzjami projektowo-implementacyjnymi, które zo-stały omówione we wczesniejszej czesci niniejszego rozdziału. Najwazniejszym z nich jestrezygnacja z obsługi załaczników do wiadomosci. Mimo, iz w przypadku czesci serwerowejmozliwosc przekazywania oraz doreczania załaczników została zaimplementowana, apli-kacja kliencka analogicznych opcji nie posiada ze wzgledu na koniecznosc zainwestowaniaduzych nakładów pracy w stworzenie w pełni uniwersalnego i rozbudowanego sposobutworzenia elementów XML reprezentujacych dowolne załaczniki.

Sposób interakcji oraz uzytkowania omawianej aplikacji zalezny jest od wybranego try-bu pracy. Jednakze w kazdym z nich zdefiniowanie podstawowych opcji działania progra-mu mozliwe jest poprzez wykorzystanie pliku konfiguracyjnego. Bardziej szczegółowy jegoopis podany zostanie w czesci 4.4.3. niniejszej pracy. Nalezy jednak pamietac, iz wartoscizapisane w pliku konfiguracyjnym sa jedynie wartosciami domyslnymi i istnieje mozliwoscich nadpisania podczas działania aplikacji. Konkretne, niezbedne do podjecia w tym celu,kroki zalezne sa od wybranego trybu pracy.

Wsadowy tryb pracy

Wsadowy tryb pracy aplikacji klienckiej zawartej w niniejszej implementacji XMXP pozwa-la na wygodne wykorzystanie jej w zastosowaniach skryptowych, a takze na proste wysy-łanie wiadomosci z linii komend. Był on wzorowany na standardowo dostepnym w wiek-szosci systemów uniksowych programie sendmail i moze zostac uzyty w podobnych doniego rozwiazaniach. Działanie programu w tym trybie jest bardzo proste: ogranicza sie doprzetworzenia argumentów linii komend i wykonania zadanych akcji (tzn. wysłania odpo-wiedniej wiadomosci), po czym program jest konczony.

65


Jak w wiekszosci programów działajacych w trybie wsadowym, tak i w przypadku apli-kacji klienckiej XMXP, argumenty linii komend stanowia najwazniejszy sposób interakcji zprogramem. Wywołanie skryptu słuzacego do uruchomienia omawianej aplikacji ma naste-pujaca postac:

$ CLIClient.sh [argumenty]

Widoczne w wywołaniu argumenty pozwalaja na okreslenie wszystkich parametrów nie-zbednych do poprawnego stworzenia i wysłania wiadomosci. Daja one równiez mozliwoscnadpisania wartosci wczytanych z pliku konfiguracyjnego. Obsługiwane przez omawianaaplikacje opcje to:

• --from (lub krócej: -f) — okresla adres nadawcy wiadomosci,

• --to (lub krócej: -t) — okresla adres odbiorcy wiadomosci,

• --subject (lub krócej: -s) — okresla temat tworzonej wiadomosci,

• --headers (lub krócej: -h) — okresla dodatkowe informacje nagłówkowe, które majasie znalezc w tworzonej wiadomosci,

• --summary (lub krócej: -u) — okresla streszczenie tworzonej wiadomosci,

• --body-file-name (lub krócej: -b) — wskazuje plik, którego zawartosc ma zostacprzesłana w ramach ciała wiadomosci,

• --destination-host (lub krócej: -d) — okresla adres serwera XMXP, który mazostac wykorzystany podczas wysyłania wiadomosci,

• --destination-port (lub krócej: -p) — okresla numer portu, na którym nasłuchu-je serwer w systemie docelowym,

• --signing-key-file-name (lub krócej: -k) — wskazuje plik, z którego odczytanypowinien zostac klucz prywatny, który ma zostac uzyty do podpisania poszczegól-nych czesci tworzonej wiadomosci,

• --signing-certificate-file-name (lub krócej: -c) — wskazuje plik, z któregoodczytany powinien zostac certyfikat powiazany z ustalonym kluczem prywatnym.

Nie jest wymagane podanie wszystkich z wymienionych powyzej argumentów. W przy-padku ustalenia niektórych parametrów działania programu poprzez wykorzystanie plikukonfiguracyjnego, w oczywisty sposób analogiczne opcje linii komend mozna pominac. Niejest konieczne równiez wykorzystywanie parametrów, które dotycza opcjonalnych elemen-tów wiadomosci XMXP, tzn. --headers oraz --summary. Mozna takze pominac numerportu docelowego serwera XMXP – w takiej sytuacji zostanie wykorzystana wartosc do-myslna, zdefiniowana na etapie tworzenia niniejszej implementacji. Podanie dowolnej in-nej, nie wymienionej powyzej opcji spowoduje wyswietlenie krótkiego opisu wywołaniaaplikacji w trybie wsadowym wraz z lista obsługiwanych argumentów.

66


Interaktywny tryb pracy

Interaktywny tryb pracy omawianej aplikacji pozwala uzytkownikowi na jej uzycie w spo-sób dajacy lepsza kontrole nad procesem tworzenia oraz wysyłania wiadomosci. Pozwalaon uzytkownikowi na biezace sledzenie wykonywanych operacji, a takze okreslanie po-szczególnych parametrów tworzonej wiadomosci stopniowo, niezaleznie od siebie. W tymtrybie mozliwe jest równiez bezposrednie wprowadzenie z klawiatury tresci listu, któryma zostac wysłany, zamiast wskazywania pliku, w którym jest ona zawarta. Tryb ten dajerówniez mozliwosc wysłania niewielkim nakładem pracy wielu podobnych wiadomosci,rózniacych sie na przykład jedynie adresem odbiorcy czy tez dodatkowymi informacjaminagłówkowymi.

Uzycie aplikacji klienckiej, stworzonej w ramach niniejszej implementacji XMXP, w try-bie interaktywnym mozliwe jest poprzez uruchomienie wspomnianego wczesniej skryptuCLIClient.sh bez podania argumentów. Jej obsługa polega na wykorzystaniu interak-tywnego menu dajacego mozliwosc okreslenia wszystkich parametrów, które mozliwe sado zdefiniowania jako argumenty linii komend w trybie wsadowym. Równiez w tym trybienie ma koniecznosci definiowania kazdego z parametrów, gdyz, jak juz wspomniane zostałopoprzednio, czesc z nich jest całkowicie opcjonalna, a czesc moze zostac odczytana z plikukonfiguracyjnego.

4.4. Szczegóły implementacji

Implementacja typu proof-of-concept pewnej idei czy pomysłu zazwyczaj nie jest kierowanado koncowych uzytkowników. Powodem tego jest fakt, iz w zdecydowanej wiekszosci przy-padków, nie powinna byc ona wykorzystywana w codziennych zastosowaniach ze wzgleduna pewne cechy projektowe czy tez poczynione uproszczenia, które odrózniaja ja od im-plementacji projektowanych jako uzytkowe. Rola implementacji proof-of-concept jest raczejwykazanie w testach, ze proponowana koncepcja jest poprawna czy tez uzyteczna, a tak-ze zademonstrowanie technik, które moga zostac wykorzystane podczas jej praktycznegowdrozenia.

W poprzednich czesciach mojej pracy zostały zaprezentowane załozenia teoretyczneEXTENSIBLE MAIL EXCHANGE PROTOCOL, a takze opis uzytkowy stworzonej implemen-tacji, co daje czytelnikowi podstawy do przeprowadzenia testów działania zaproponowa-nego protokołu. Natomiast w niniejszej czesci zostana przedstawione konkretne rozwia-zania techniczne i programistyczne, na których opiera sie stworzona implementacja. Majaone na celu wprowadzenie czytelnika w powstały w jej ramach kod zródłowy, tym samymumozliwiajac mu ocene wpływu proponowanych rozwiazan na wielkosc nakładów pracyniezbednych do implementacji funkcjonalnego systemu transportu poczty elektronicznej,a takze dac mu podstawowa wiedze niezbedna do jego rozszerzania czy tez tworzenia nabazie niniejszej implementacji XMXP własnych rozwiazan.

67


4.4.1. Podział na moduły

Kod zródłowy omawianej implementacji XMXP mozna podzielic na kilka najwazniejszychmodułów. Niektóre z nich sa od siebie niezalezne pod wzgledem funkcjonalnym, zas in-ne wrecz przeciwnie – intensywnie wykorzystuja mozliwosci dostarczane przez pozostałe.Kazdy moduł oddzielony jest od pozostałych nie tylko pod wzgledem logicznym i uzytko-wym, ale równiez w sensie kodu zródłowego, dzieki temu, ze umieszczony jest w oddziel-nym pakiecie w sensie jezyka JAVA. W wiekszosci przypadków jeden moduł wykorzystujedokładnie jeden pakiet, lecz nie jest to reguła. W niektórych przypadkach zaleznosci miedzypakietami nie ograniczaja sie do relacji uzycia wzajemnego przez moduły – niektóre z mo-dułów sa podrzedne w stosunku do innych, tzn. sa wykorzystywane jedynie przez swojemoduły nadrzedne, a czasem sa wrecz niezbedne do ich działania. Taka zaleznosc zostaławyrazona poprzez stworzenie odpowiedniej hierarchii pakietów.

Wsród modułów składajacych sie na implementacje proof-of-concept XMXP mozna wy-róznic:

• biblioteke klas narzedziowych słuzacych do realizacji podstawowych zadan zwia-zanych z obsługa protokołu XMXP — umieszczona została ona w pakiecienet.xmxp.lib,

• moduł realizujacy zadania zwiazane z odbieraniem połaczen oraz wiadomosci przy-chodzacych w ramach komunikacji wykorzystujacej XMXP — umieszczony on zostałw pakiecie net.xmxp.receiver,

• moduł realizujacy zadania symetryczne do poprzednio wymienionego, tzn. zwiazanez nadawaniem wiadomosci oraz pozostałych komunikatów wystepujacych w ramachXMXP — umieszczony on został w pakiecie net.xmxp.sender,

• aplikacje kliencka obsługiwana z linii komend pozwalajaca uzytkownikowi wy-słac wiadomosc z wykorzystaniem XMXP — umieszczona ona została w pakiecienet.xmxp.client.cli,

• aplikacje serwerowa realizujaca zadania zwiazane z transportem wiadomosci miedzyposzczególnymi systemami pocztowymi, a takze ich doreczanie do odbiorców konco-wych — umieszczona ona została w pakiecie net.xmxp.server.

Struktura oraz sposób implementacji najwazniejszych z wyzej wymienionych modułówzostana opisane w dalszej czesci niniejszego rozdziału. Brak opisu modułów odbierajacychi nadajacych komunikaty oraz wiadomosci XMXP wiaze sie z ich rola w stworzonym sys-temie. Nie realizuja one praktycznie zadnej logiki aplikacyjnej, a jedynie stanowia swegorodzaju „łaczniki” miedzy czesciami aplikacyjnymi a bibliotekami programistycznymi (wtym równiez biblioteka stworzona w ramach niniejszej implementacji XMXP) udostepnia-jacymi niezbedne dla nich narzedzia.

Zaleznosci miedzy wymienionymi modułami mozna graficznie przedstawic w sposóbwidoczny na rys. 4.1. Jak mozna na nim zauwazyc, biblioteka klas narzedziowych jest ele-mentem wykorzystywanym przez wszystkie pozostałe moduły, a co za tym idzie – newral-gicznym dla działania całego systemu. Pozostałe komponenty reprezentuja wyzsze stopnie

68


abstrakcji tworzonego oprogramowania, a wiec istnieje mniej elementów od nich zaleznych.Jest oczywiste, ze zaleznosci przedstawione na schemacie sa zaleznosciami jednostronnymi,tzn. wystepuje jedynie relacja uzycia elementu podrzednego przez nadrzedny, a nigdy od-wrotnie oraz nie istnieja zaleznosci miedzy modułami na tym samym poziomie abstrakcji.Dzieje sie tak, gdyz moduły – zaprojektowane, aby realizowac okreslone funkcje – wypełnia-ja je w pełni, bez potrzeby angazowania w ten proces czesci aplikacji z nim nie zwiazanych.

Rys. 4.1. — Schemat zaleznosci miedzy modułami implementacji proof-of-concept XMXP

4.4.2. Opis najwazniejszych klas

Z punktu widzenia programisty, który chciałby zajac sie rozwojem stworzonej w ramachniniejszej pracy implementacji EXTENSIBLE MAIL EXCHANGE PROTOCOL, bardzo istotnajest znajomosc podziału zadan miedzy poszczególne klasy składajace sie na implementacjewymienionych wczesniej modułów. Zagadnienie to jest wazne równiez w celu lepszego zro-zumienia zasady ich działania, a takze zakresu i sposobu interakcji miedzy poszczególnymiklasami.

W ponizszym opisie wymienione zostana najwazniejsze z klas składajacych sie na oma-wiana implementacje XMXP, a takze zostanie przedstawiona rola, która spełniaja w stwo-rzonym systemie. Pokrótce zaprezentowane równiez zostana zaleznosci miedzy niektóry-mi z nich, aby umozliwic czytelnikowi dokładniejsze zrozumienie ich znaczenia dla całoscininiejszej implementacji. Jednakze w celu poznania szczegółów zwiazanych czy to z inter-fejsem danej klasy czy tez jej implementacja, wykorzystac nalezy kod zródłowy stanowiacyintegralna czesc niniejszej pracy, gdyz jego szczegółowa analiza nie jest celem przedstawio-nego opisu.

69


Biblioteka klas narzedziowych

Jak juz zostało wspomniane we wczesniejszej czesci niniejszego rozdziału, najbardziej new-ralgiczna czescia stworzonej implementacji proof-of-concept XMXP jest biblioteka klas reali-zujacych wszystkie podstawowe mozliwosci proponowanego przeze mnie protokołu. Sta-nowi ona blisko połowe kodu zródłowego, który powstał podczas tworzenia niniejszej pra-cy i pochłoneła zdecydowana wiekszosc zwiazanych z jej tworzeniem wysiłków. Wchodziw jej skład 51 klas, co stanowi ponad 70% wszystkich uzytych do stworzenia omawianejimplementacji XMXP. Wszystkie nalezace do tego modułu klasy zgromadzone zostały wpakiecie net.xmxp.lib i jemu podrzednych. Wsród najwazniejszych ich elementów nale-zy wymienic:

• Klasy bezposrednio dostepne w pakiecie net.xmxp.lib — sa to klasy narzedzio-we ogólnego przeznaczenia, które realizuja zadania w dosc luzny sposób zwiazanez transportem wiadomosci wykorzystujacym XMXP, ale jednoczesnie niezbedne doprawidłowego jego działania lub efektywnej realizacji pozostałych aspektów niniej-szej implementacji. Mozliwosci przez nie udostepniane to:

– klasa SignatureProcessor — klasa odpowiedzialna za przetwarzanie podpi-sów kryptograficznych XML DSig poszczególnych czesci wiadomosci, a takze ichanalize pod katem poprawnosci oraz wyodrebnianie z nich certyfikatów zwiaza-nych z kluczem publicznym, który do stworzenia danego podpisu został uzyty,

– klasa StringMessageDigest — klasa opakowujaca standardowe narzedziaudostepniane przez biblioteke JCA pozwalajaca generowac kryptograficzne skró-ty wiadomosci w sposób ułatwiajacy ich reprezentacje w postaci tekstowej, co jestniezbedne podczas tworzenia „zagadek algorytmicznych”,

– klasa XMLUtils — klasa opakowujaca standardowe narzedzia udostepnianeprzez biblioteke JAXP pozwalajaca na realizacje podstawowych zadan zwiaza-nych z tworzeniem dokumentów XML w sposób spójny w ramach całej oma-wianej implementacji XMXP, a takze na ujednolicona i ukryta przez wyzszymiwarstwami abstrakcji obsługe ewentualnych błedów, które w tym procesie mogasie pojawiac,

– klasa XMXP2MIME — klasa odpowiedzialna za konwertowanie danych (wiado-mosci, załaczników oraz adresów) miedzy formatami wykorzystywanymi w ra-mach XMXP, a starszymi, uzywanymi w wiadomosciach zgodnych ze standar-dem MIME.

• Pakiet net.xmxp.lib.messaging — znalezc w tym pakiecie mozna klasy słuzacedo reprezentowania w aplikacji wykorzystujacej XMXP kazdy z elementów wiado-mosci oraz konwersacji miedzy komunikujacymi sie stronami, które opisane zostaływ czesci 3.3. niniejszej pracy. Klasy znajdujace sie bezposrednio w tym pakiecie, ta-kie, jak Attachment, Envelope czy Message słuza do reprezentowania konkret-nych czesci wiadomosci XMXP jako obiektów w programie. Udostepniaja one mozli-wosc konstruowania odpowiednich elementów, dostepu do ich składowych, a takze

70


generowania dokumentów XML (lub ich fragmentów) zawierajacych ich reprezenta-cje zgodna z wymaganiami protokołu. W ramach tego dokonywane sa wszystkie nie-zbedne operacje takie, jak na przykład stworzenie kryptograficznego podpisu wiado-mosci XML DSig. Do realizacji tych zadan wykorzystuja one odpowiednie klasy na-rzedziowe omówione wczesniej, jak na przykład XMLUtils. Wszystkie z wymienio-nych klas posiadaja wspólny interfejs programistyczny, który wyspecyfikowany zostałw interfejsie MessageElement. Klasami pomocniczymi dla wymienionych powyzej,pozwalajacymi na zwiekszenie wygody obsługi pewnych elementów wiadomosci, saAttachmentID oraz MessageID.

W tym samym pakiecie został równiez umieszczony interfejs obsługujacyproste składniki sesji, jak na przykład przesyłanie odpowiedzi czy tez zaga-dek i ich rozwiazan – SessionElement. Znajdujaca sie równiez w pakiecienet.xmxp.lib.messaging klasa Reply implementuje własnie ten interfejs ipozwala na reprezentowanie obiektów bedacych odpowiedziami na zdarzeniazachodzace podczas komunikacji wykorzystujacej XMXP. Korzysta ona z klasy po-mocniczej ReplyCodes zawierajacej stałe numeryczne zdefiniowanych w niniejszejimplementacji kodów odpowiedzi, a takze z wyliczenia ReplyType pozwalaja-cego symbolicznie okreslac w aplikacjach rodzaj odpowiedzi, który dany obiektreprezentuje oraz zachowywac przy tym pełne bezpieczenstwo typów.

W omawianym pakiecie wystepuja, oprócz juz wymienionych, równiez dalsze klasyzawierajace stałe symboliczne usprawniajace wykorzystywanie najczesciej stosowa-nych podczas tworzenia implementacji XMXP wielkosci. Klasa Constants zawieratakie pola, jak numer portu wykorzystywanego do komunikacji (przyjeto port 9743jako wolny w sensie przypisan organizacji IANA w momencie powstawania niniejszejpracy) czy format daty niezbedny do zgodnosci z typem wbudowanym jezyka XMLSchema. W klasie Namespaces wyszczególnione zas zostały przestrzenie nazw XML,które obsługiwane sa przez niniejsza implementacje XMXP. Rola drugiej z tych klasjest o tyle istotna, ze mozna ja traktowac jak swego rodzaju zobowiazanie ze stronyimplementacji co do listy obsługiwanych przez nia mozliwosci sposród oferowanychprzez XMXP oraz róznorodne rozszerzenia, a takze wersji kazdej z nich.

• Pakiet net.xmxp.lib.messaging.sessions — zgodnie z opisem protokołuprzedstawionym w czesci 3.3. niniejszej pracy, kazdy z elementów komunikacji wramach XMXP przesyłany jest w opakowujacym go elemencie sesyjnym. W niniej-szej implementacji przeznaczono dla kazdego z nich odpowiednia klase w pakiecienet.xmxp.lib.messaging.sessions, której nazwa odpowiada nazwie obsługi-wanego elementu sesyjnego. Kazda z nich udostepnia mozliwosci rozpoczecia odpo-wiedniego rodzaju sesji, przesłania wszystkich komunikatów z nia zwiazanych, a na-stepnie jej zakonczenia. Zadania te moga byc jednakze realizowane dwojako w zalez-nosci od konkretnego rodzaju sesji. W przypadkach mniej skomplikowanych, takich,jak reprezentowany przez klase AddressExchangeRequest, dostepne sa konstruk-tory tworzace obiekt modelujacy sesje o odpowiednich parametrach oraz jedna meto-da przesyłajaca wszystkie dane z nia zwiazane. W przypadkach bardziej skompliko-wanych, jak na przykład w ReplySession czy RiddleSolutionSession, mozli-we jest niezalezne, w pełni kontrolowane przez programiste, rozpoczecie i zakoncze-nie sesji, a takze przesyłanie danych w jej ramach. Czesto jednak uzyteczna moze bycmozliwosc zbierania danych w sposób przyrostowy poprzez dodawanie ich do pew-nej listy, a nastepnie równiez przyrostowe ich wysyłanie, na przykład w oczekiwaniu

71


na odpowiedz po kazdej ich czesci – tego typu podejscie prezentuja miedzy innymiklasy AttachmentRequest czy MessageNotification. Najbardziej skompliko-wany sposób realizacji omawianego zadania jest wymagany, gdy zródła danych sesyj-nych moga byc dwojakiego rodzaju: albo w postaci stworzonych wczesniej obiektówklas z pakietu net.xmxp.lib.messaging, albo w formie reprezentacji w postaciDOM dokumentów XML odebranych z sieci, które maja zostac przekazane dalej. Pro-blem tego typu ma miejsce na przykład w przypadku klas AttachmentSession orazMessageSession – jego rozwiazaniem jest dostarczenie przeciazonych wersji odpo-wiednich metod.

• Pakiet net.xmxp.lib.messaging.address — jako ze jedna z istotnych moz-liwosci rozszerzania proponowanego przeze mnie protokołu jest mozliwosc two-rzenia nowych schematów adresowania, postanowiłem ja zaakcentowac równiezpodczas tworzenia niniejszej implementacji XMXP poprzez wydzielenie oddzielne-go pakietu, w którym mozna umieszczac klasy przeznaczone do obsługi adresówXMXP. Najwazniejsza jego czesc stanowia interfejsy Address oraz AddressPart,które specyfikuja wymagania nakładane odpowiednio na klasy reprezentujace ad-res oraz poszczególne jego czesci. Oprócz metod narzedziowych, warto zauwa-zyc metode Address.getNamespace(), która pozwala na rozróznianie schema-tów adresowania uzywanych w danej implementacji. Pakiet ten dostarcza rów-niez domyslnych dla niniejszej implementacji schematów adresowania reprezentu-jacych adresy zgodne z RFC 2822 [25] w formie klas TraditionalAddress orazTraditionalAddressPart.

• Pakiet net.xmxp.lib.messaging.riddles — jedna z wazniejszych decyzji, któ-ra została podjeta podczas tworzenia niniejszej implementacji XMXP, był wy-bór konkretnego sposobu przenoszenia kosztów transportu wiadomosci poczto-wej na jej nadawce. Podejrzewam, iz przyszli implementatorzy równiez przedpodobnym problemem stana i ze moze w rezultacie powstac wiele rózno-rodnych jego rozwiazan. W celu ich zgromadzenia wydzielony został pakietnet.xmxp.lib.messaging.riddles. Znalezc w nim mozna interfejsy Riddleoraz RiddleSolution, które zawieraja specyfikacje wymagan nakładanych na kla-sy reprezentujace odpowiednio: „zagadki” wykorzystywane w danej implementacjiXMXP oraz ich rozwiazania. Dostepna jest równiez klasa narzedziowa realizujacawzorzec projektowy factory ułatwiajaca tworzenie zagadek o okreslonych parame-trach.

Omawiany pakiet zawiera takze klasy HashRiddle oraz HashRiddleSolution do-starczajace domyslna realizacje „zagadek”, uzywana w ramach niniejszej implemen-tacji proof-of-concept XMXP. Wykorzystywana jest w niej bezkolizyjnosc oraz jednokie-runkowosc kryptograficznych funkcji skrótu. Podczas generowania zagadki losowanyjest ciag znaków z zestawu US-ASCII o zadanej długosci, a nastepnie wyliczany jest,przy uzyciu funkcji MD5 lub SHA-1, jego skrót, który jest przekazywany nadawcywiadomosci wraz z pierwsza połowa wylosowanego ciagu znaków oraz informacjao jego długosci i zastosowanym algorytmie. Zadaniem nadawcy jest znalezienie, me-toda przeszukiwania systematycznego, pełnego ciagu znaków, który odpowiada da-nemu skrótowi oraz rozpoczyna sie podanymi znakami. Problem ten został wybranyjako łaczacy w sobie cechy prostoty implementacyjnej, przesyłania małej ilosci danychmiedzy komunikujacymi sie stronami oraz, jednoczesnie, wymagajacy duzej liczby

72


obliczen w celu jego rozwiazania, a wiec gwarantujacy wysoki koszt przesłania wia-domosci.

• Pakiet net.xmxp.lib.exceptions — grupuje on wszelkie klasy wyjatków, któ-re sa uzywane przez omawiana biblioteke w celu sygnalizowania sytuacji błednychoraz niecodziennych. Wyjatki te maja dwojakie zastosowanie: sa uzywane zarównowewnetrznie przez klasy z pakietów net.xmxp.lib.*, jak i do zgłaszania sytuacjiwyjatkowych na zewnatrz, tzn. do pozostałych modułów składajacych sie na niniejszaimplementacje XMXP.

Aplikacja serwerowa

Druga pod wzgledem skomplikowania czescia składowa niniejszej implementacji XMXPjest aplikacja serwerowa wchodzaca w jej skład. Mimo zaimplementowania najbardziejpodstawowych operacji zwiazanych z obsługa proponowanego przeze mnie protokołu wramach opisanej wczesniej biblioteki klas narzedziowych, logika aplikacyjna realizowanaprzez aplikacje serwerowa nadal pozostaje dosc skomplikowana. Klasy umieszczone we-wnatrz pakietu net.xmxp.server musza zadbac, aby poprawnie zostały zrealizowanewszystkie zadania przypisywane serwerowi transportujacemu wiadomosci pocztowe przywykorzystaniu XMXP, a takze, aby ich przebieg był zgodny z opisem protokołu przedsta-wionym w czesci 3.3. niniejszej pracy. Najwazniejsze klasy w omawianym pakiecie to:

• Klasa net.xmxp.server.Server — jest to klasa nadrzedna dla wszystkich zadanrealizowanych w ramach aplikacji serwera XMXP. Jej metody nadzoruja proces uru-chamiania oraz wyłaczania omawianej aplikacji, a takze wykonywanie jej podstawo-wych zadan w czasie pracy, takich, jak na przykład odbierania połaczen od klientów.W zakres podejmowanych przez nia działan wchodzi równiez nadzorowanie uru-chomienia odpowiednich watków podrzednych oraz przekazanie im odpowiednichopcji konfiguracyjnych, a takze zapewnienie ich poprawnego zakonczenia w momen-cie konczenia działania całej aplikacji. Z punktu widzenia kodu zródłowego, w klasietej przechowywane sa równiez obiekty reprezentujace wszystkie dane konfiguracyj-ne, a takze aktualny stan aplikacji zwiazany z zapamietywaniem niektórych informa-cji dotyczacych odebranych wiadomosci, potrzebnych na przykład w celu wykrywa-nia róznych anomalii niezgodnych z protokołem, jak próba przesłania własciwej tresciwiadomosci przed jej czescia kopertowa. Powodem gromadzenia takich danych w kla-sie głównej aplikacji serwerowej jest umozliwienie wszystkim watkom pracujacym wjej ramach dostepu do nich i mozliwosci swobodnego z nich korzystania.

• Klasa net.xmxp.server.ServingThread — jest to klasa obsługujaca pojedynczywatek komunikacji przeprowadzanej przez serwer XMXP, czyli realizujaca wiekszosclogiki aplikacyjnej zwiazanej z jego zadaniami. Odpowiedzialna jest ona za bezposred-nia współprace aplikacji serwerowej (a wiec pozostałych klas na nia sie składajacych)z klasami z pakietów net.xmxp.sender oraz net.xmxp.receiver, a co za tymidzie – posrednio za przetwarzanie otrzymanych z sieci danych i zapewnienie ade-kwatnych reakcji na nie.

• Pakiet net.xmxp.server.router — zawarte w nim klasy odpowiadaja za realiza-cje zadan zwiazanych z wyznaczaniem marszrut wiadomosci transportowanych w

73


ramach XMXP oraz wymiane informacji o obsługiwanych adresach pomiedzy po-szczególnymi systemami pocztowymi. Znajdujace sie w tym pakiecie klasy mozna,w sensie logicznym, podzielic na dwie grupy. Do pierwszej z nich zaliczyc nalezy in-terfejs Router, który definiuje wymagania do spełnienia dla konkretnych implemen-tacji klas zajmujacych sie obsługa wyznaczania marszrut wiadomosci. Druga czescstanowi konkretna implementacja protokołu przeznaczonego do tego celu, który opi-sany został w czesci 3.2. niniejszej pracy. W jej skład wchodza klasy AMSRouter orazAMSRoutingInformationGatheringThread. Pierwsza z nich słuzy wyznaczaniumarszrut dla konkretnych wiadomosci, które przetwarzane sa przez dany systempocztowy. Zadaniem drugiej jest zas okresowe inicjowanie wymiany informacji o ob-sługiwanych adresach z innymi znanymi systemami pocztowymi.

• Pakiet net.xmxp.server.deliverer — grupuje on klasy zwiazane z szeroko po-jetym doreczaniem do adresata wiadomosci otrzymanej przez aplikacje serwerowaXMXP od zewnetrznego systemu pocztowego. Najwazniejsza role wsród nich pełniklasa DeliveryHelper, która jest jedyna bezposrednio wykorzystywana w pozosta-łych czesciach omawianej aplikacji. To ona, na podstawie danych konfiguracyjnychotrzymanych od klasy net.xmxp.server.Server, a takze na podstawie analizyprzekazanej jej wiadomosci, podejmuje decyzje o dalszym sposobie doreczania wia-domosci, a co za tym idzie – równiez o konkretnej klasie, której obiekt powinien roz-patrywana wiadomosc otrzymac. Obsługiwane przez niniejsza implementacje XMXPsposoby doreczania wiadomosci reprezentowane sa przez nastepujace klasy:

– RemoteXMXPDeliverer — jest to klasa realizujaca przekazanie danej wiado-mosci do zdalnego systemu pocztowego wykorzystujacego EXTENSIBLE MAIL

EXCHANGE PROTOCOL. Wykonywana jest próba jej doreczenia zgodna z aktual-na tablica marszrut wiadomosci, a w przypadku jej niepowodzenia – wiadomoscprzekazywana jest do obiektu klasy QueuedDeliverer w celu pózniejszego jejdoreczenia.

– LocalMIMEDeliverer — klasa ta odpowiada za doreczanie wiadomosci dolokalnych skrzynek pocztowych. Proces ten jest realizowany przy załozeniu, izaplikacja serwera XMXP pracuje we wzglednie standardowym srodowisku sys-temu uniksowego, a co za tym idzie – ze dostepny jest w systemie programprocmail (jego konkretna lokalizacja jest odczytywana z pliku konfiguracyjne-go). Klasa ta wykonuje (wykorzystujac omówiona wczesniej klase XMXP2MIMEwchodzaca w skład biblioteki klas narzedziowych do obsługi XMXP) konwer-sje wiadomosci do formatu MIME, a nastepnie jest ona doreczana do skrzynkiodbiorczej jej adresata.

– RemoteSMTPDeliverer — jest to klasa realizujaca dostarczanie wiadomosciodebranej przez aplikacje serwera XMXP do systemu pocztowego adresata przywykorzystaniu SMTP. Koniecznosc przekazania wiadomosci do systemu poczto-wego wykorzystujacego ten własnie protokół jest rozpoznawana na podstawiezawartego w niej adresu odbiorcy – jezeli trzy ostatnie elementy w „prawej” cze-sci adresu sa zgodne z smtp-gateway.xmxp.net, to oznacza to, iz pozostałaczesc adresu nalezy przetłumaczyc jako adres pocztowy zwiazany z SMTP.W celu dostarczenia wiadomosci do zdalnego serwera wykorzystujacego SMTP,omawiana klasa nie implementuje samodzielnie transportu poczty elektronicznejprzy wykorzystaniu tego protokołu. Polega ona na technice zwanej „smart host”,czyli wykorzystaniu zewnetrznego serwera obsługujacego SMTP jako systemu

74


odpowiedzialnego za doreczenie wiadomosci. Omawiana klasa dokonuje zatemjedynie przekazania wiadomosci do odpowiedniego serwera SMTP, wykorzystu-jac w tym celu mechanizmy udostepniane przez biblioteke JavaMail.Klasa ta implementuje swego rodzaju buforowanie — otrzymana wiadomosc niejest doreczana w momencie jej otrzymania, a dopiero, gdy otrzymane zostanarówniez wszystkie zwiazane z nia załaczniki. Z taka strategia zwiazana jest ko-niecznosc przechowywania oczekujacych na doreczenie wiadomosci w sposóbzapewniajacy ich zachowanie po wyłaczeniu aplikacji. Do realizacji tego zadaniawykorzystane zostały standardowe mechanizmy serializacji jezyka JAVA.

– QueuedDeliverer — klasa ta jest odpowiedzialna za odroczone doreczanie i –jako taka – samodzielnie nie realizuje procesu doreczania wiadomosci w scisłymsensie. Jej zadaniem jest udostepnianie usługi kolejkowania na rzecz pozostałychklas z omawianego pakietu. Realizowane przez nia operacje polegaja na doda-niu otrzymanej wiadomosci do kolejki, a nastepnie cyklicznym ponawianiu próbjej doreczenia w okreslonych odstepach czasu. Odstepy te definiowane sa jakorosnace wykładniczo, zas liczba prób doreczenia dla danej wiadomosci jest ogra-niczona z góry – oba te parametry sa stałymi odczytywanymi z pliku konfigura-cyjnego.

• Pakiet net.xmxp.server.launcher — zawiera on klasy pomocnicze, wymaganeprzy korzystaniu z biblioteki Apache Commons Daemon, które kontroluja procesuruchamiania oraz wyłaczania aplikacji serwerowej XMXP.

Aplikacja kliencka

Jest to najprostszy z omawianych modułów, gdyz jego implementacja sprowadza sie dojednej klasy – net.xmxp.client.cli.CLIClient. Zawarte sa w niej wszystkie metodyniezbedne do obsługi zarówno trybu interaktywnego, jak i wsadowego pracy tej aplikacji.Moze sie wydawac, iz jest to bład projektowy, gdyz umieszczono czesci programu realizu-jace dwie koncepcyjnie rózne funkcje w jednej klasie. Nic jednak bardziej mylnego. Zgodniez załozeniem projektowym, tryb wsadowy pracy klienta XMXP jest jedynie szczególnymsposobem wydania polecen trybu interaktywnego, a wiec uzasadnione jest, aby realizowa-ne one były przy uzyciu wspólnych fragmentów kodu zródłowego, zgromadzonych wewspólnej klasie.

Metody zawarte w klasie CLIClient mozna, w sensie logicznym, podzielic na kilkagrup:

• metody słuzace do obsługi pliku konfiguracyjnego, menu trybu interaktywnego lubprzetwarzania komend trybu wsadowego — sa to czysto narzedziowe funkcje reali-zujace zmiane stanu programu oraz aktualizacje odpowiednich pól klasy w zaleznosciod akcji wykonywanych przez uzytkownika lub polecen umieszczonych w konfigura-cji; w niektórych przypadkach dokonuja one równiez weryfikacji poprawnosci wpro-wadzonych danych lub podejmuja inne akcje, jak na przykład wysłanie wiadomosciczy tez zakonczenie aplikacji,

75


• metody słuzace do aktualizacji pól klasy, które wymagaja skomplikowanego przetwa-rzania wstepnego – jest to grupa metod wspólnych dla obu trybów pracy omawianejaplikacji, wykorzystywanych na przykład do pobierania danych z zewnetrznych pli-ków i ich przetwarzania,

• metoda CLIClient.sendMessage() realizujaca kluczowe zadanie stawiane przedklientem protokołu XMXP, czyli własciwe przesłanie wiadomosci.

Podczas realizacji wszystkich z wymienionych powyzej zadan, aplikacja kliencka intensyw-nie wykorzystuje omówiona wczesniej biblioteke klas narzedziowych, a takze biblioteki ze-wnetrzne.

4.4.3. Wykorzystywane pliki konfiguracyjne

Bardzo waznym sposobem interakcji uzytkownika z aplikacjami wchodzacymi w skład im-plementacji proof-of-concept EXTENSIBLE MAIL EXCHANGE PROTOCOL jest stworzenie pli-ków konfiguracyjnych oraz ich pózniejsza edycja. Dzieki nim mozliwe jest okreslenie pod-stawowych parametrów pracy kazdej z aplikacji, które niezbedne sa do poprawnej pracystworzonego oprogramowania w srodowisku, w którym przebiega jego wdrozenie. Plikikonfiguracyjne daja równiez mozliwosc zmiany najwazniejszych wartosci wpływajacychna sposób realizacji zadan powierzonych kazdej z aplikacji. Dzieki temu, w prosty spo-sób mozliwe jest testowanie zaleznosci miedzy poszczególnymi parametrami zwiazanymiz tworzonym systemem transportu poczty elektronicznej.

Jak juz wspomniałem w niniejszej pracy, obsługa plików konfiguracyjnych aplikacjiwchodzacych w skład niniejszej implementacji XMXP realizowana jest za pomoca bibliotekiNiente Application Utils, bazujacej na Apache XML Beans. W zwiazku z tym, pliki konfigu-racyjne maja postac dosc rozbudowanych dokumentów XML odwzorowujacych pózniejszyukład struktur danych przechowujacych konfiguracje w samej aplikacji. Jednakze jednocze-snie, pliki w tym formacie charakteryzuja sie duza czytelnoscia i prostota obsługi z punktuwidzenia uzytkownika. Szczegółowa ich postac dostepna jest w formie przykładowych pli-ków konfiguracyjnych umieszczonych w dodatku A. Ponizej zas zaprezentowane zostajajedynie najwazniejsze parametry, które przy pomocy tych plików mozna zmieniac, a takzeich wpływ na zachowanie wykorzystywanej aplikacji.

Aplikacja serwerowa

Zgodnie z tym, co zostało podane w czesci 4.3.1. niniejszej pracy, edycja pliku konfigura-cyjnego stanowi główny (i praktycznie jedyny) sposób interakcji uzytkownika z aplikacjaserwerowa wchodzaca w skład omawianej implementacji XMXP. Wiaze sie z tym koniecz-nosc duzego rozbudowania pliku konfiguracyjnego przeznaczonego do okreslania parame-trów działania tej aplikacji. Nie oznacza to jednak, iz jest to konfiguracja skomplikowana –wiekszosc parametrów powinna byc prosta do okreslenia dla administratorów systemówpocztowych. Dodatkowo, dla wielu z kluczy konfiguracyjnych zostały okreslone domysl-ne wartosci, które sprawiaja, iz nie musza sie one pojawic w omawianym pliku – sa one

76


zdefiniowane w klasie net.xmxp.server.ServerConfigInitializer. Sam plik kon-figuracyjny powinien miec nazwe server.config.xml i zostac umieszczony w katalogu,z poziomu którego bedzie przebiegało uruchomienie aplikacji.

Wsród najbardziej istotnych opcji dostepnych w pliku konfiguracyjnym przeznaczonymdla aplikacji serwerowej XMXP wymienic nalezy:

• parametry sieciowe zwiazane z praca wdrazanego systemu pocztowego, takie, jak ad-res IP pod którym jest on dostepny czy tez numer portu, na którym aplikacja serwero-wa oczekuje na połaczenia przychodzace,

• sciezka do programu procmail wykorzystywanego podczas doreczania wiadomoscido lokalnych odbiorców,

• parametry zwiazane z wymiana informacji o obsługiwanych grupach adresów poczto-wych miedzy poszczególnymi systemami, takie, jak minimalny odstep czasu (podanyw minutach) miedzy kolejnymi odpytaniami tego samego zewnetrznego systemu czyczestosc podejmowania prób wymiany tych informacji z innymi systemami (podanaw sekundach),

• dane niezbedne do wykorzystania techniki „smart host” w celu doreczania wiadomoscido systemów wykorzystujacych SMTP, takie, jak adres serwera docelowego czy daneuwierzytelniajace niezbedne w celu nawiazania połaczenia z nim,

• wielkosci pozwalajace dostosowac prace systemu odroczonego doreczania wiado-mosci do uwarunkowan panujacych w srodowisku, w którym aplikacja serwerowaXMXP ma pracowac, na przykład maksymalna liczba prób doreczenia jednej wiado-mosci czy tez czynnik regulujacy szybkosc narastania czasu miedzy kolejnymi próba-mi,

• nazwy plików przechowujacych kolejki wiadomosci tworzone w ramach działan re-alizowanych przez klasy QueuedDeliverer oraz RemoteSMTPDeliverer,

• informacje pozwalajace kontrolowac odbieranie wiadomosci od poszczególnychnadawców, jak na przykład lista zablokowanych nadawców podana poprzez wymie-nienie numerów seryjnych ich certyfikatów czy domyslny koszt generowanych „za-gadek algorytmicznych”,

• listy uzytkowników obsługiwanych przez dany system pocztowy, przez inne znanesystemy, a takze informacja o zwiazku miedzy adresami pocztowymi poszczególnychuzytkowników a nazwami ich kont w lokalnym systemie.

Aplikacja kliencka

W stosunku do opisanego poprzednio pliku konfiguracyjnego aplikacji serwerowej stwo-rzonej w ramach implementacji proof-of-concept XMXP, konfiguracja aplikacji klienckiej jesto wiele prostsza. Powody tego faktu sa dwojakie. Po pierwsze, podczas pracy z aplikacjakliencka, uzytkownik ma o wiele wiecej mozliwosci interakcji z nia – czy to przez opcje

77


podawane w linii komend, czy tez poprzez prace w trybie interaktywnym. Drugim powo-dem, równie oczywistym, jest znaczaco mniejszy stopien skomplikowania tej aplikacji, a coza tym idzie – mniejsza liczba parametrów, których zmiana jest mozliwa. Analogicznie dosytuacji, która ma miejsce w przypadku aplikacji serwerowej, plik konfiguracyjny aplikacjiklienckiej powinien zostac nazwany client.config.xml.

Jak juz zostało wspomniane w czesci 4.3.2. mojej pracy, wartosci parametrów podane wpliku konfiguracyjnym, w przypadku aplikacji klienckiej XMXP stanowia jedynie wartoscidomyslne, których zmiana jest mozliwa przy pomocy interakcji z programem w czasie jegodziałania. Mozliwe jest okreslenie nastepujacych wartosci:

• adresu serwera, który ma byc uzywany podczas wysyłania wiadomosci,

• połozenia w systemie plików zawierajacych klucz prywatny oraz zwiazany z nim cer-tyfikat, które maja zostac wykorzystane podczas generowania podpisów poszczegól-nych elementów wiadomosci XMXP,

• adresu nadawcy, którym maja byc podpisywane wysyłane wiadomosci; powinien onzostac podany w formie adresu zgodnego z RFC 2822 [25] – konwersja na formatwykorzystywany w XMXP zostanie wykonana automatycznie.

Podobnie jak ma to miejsce w przypadku pliku konfiguracyjnego aplikacji serwerowej,równiez przykładowy plik konfiguracyjny przeznaczony dla aplikacji klienckiej stworzonejw ramach omawianej implementacji XMXP jest dostepny w dodatku A..

4.4.4. Tworzone pliki dziennika

Jednym z najbardziej istotnych zródeł informacji dotyczacych przebiegu wykonania apli-kacji powstałych w ramach omawianej implementacji XMXP sa tworzone przez nie plikidziennika. O ile w przypadku aplikacji klienckiej niektóre z informacji dostepne sa rów-niez podczas jej interaktywnej pracy, o tyle w przypadku czesci serwerowej, ze wzgleduna charakterystyke jej sposobu działania, pliki dziennika sa jedynym zródłem informacjidotyczacych zdarzen zachodzacych podczas jej pracy.

Ze wzgledu na zastosowany mechanizm tworzenia i obsługi plików dziennika, mozliwajest swobodna konfiguracja ich zawartosci. Wykorzystywana biblioteka Apache Log4J po-zwala uzytkownikowi na samodzielne zdefiniowanie rodzajów tworzonych plików dzien-nika, ich formatów, obsługi przepełnienia oraz wielu innych aspektów z ich wykorzystywa-niem zwiazanych. Nie jest w tym celu konieczna zadna ingerencja w kod zródłowy aplikacjigenerujacych wpisy pojawiajace sie w plikach dziennika – wszystkie zmiany moga zostacwykonane deklaratywnie, poprzez edycje odpowiedniego pliku konfiguracyjnego, którymw przypadku niniejszej implementacji XMXP jest plik logging.properties umieszczo-ny w katalogu, z którego przebiega uruchomienie aplikacji. W zwiazku z istnieniem tegotypu mozliwosci, opis przedstawiony w niniejszej czesci mojej pracy bedzie poswieconyzawartosci plików dziennika podczas wykorzystywania domyslnego pliku konfiguracyjne-go biblioteki Apache Log4J, który dostarczany jest wraz z kodem zródłowym stanowiacymintegralna czesc niniejszej pracy.

78


Charakterystyka podziału zapisywanych informacji pomiedzy poszczególne plikidziennika jest zwiazana ze specyfika zastosowania implementacji typu proof-of-conceptXMXP. Celem zapisywania informacji o działaniach poszczególnych aplikacji oraz ich wyni-kach jest w przypadku tego rodzaju oprogramowania, głównie analiza przebiegu wymianyinformacji w ramach projektowanego przeze mnie protokołu. W zwiazku z tym podjałemdecyzje o podziale zapisywanych komunikatów miedzy poszczególne pliki nie ze wzgleduna aplikacje, z której praca sie one wiaza, a ze wzgledu na rodzaj informacji, które zostały wdanym pliku zgromadzone. Kategorie, które zostały wydzielone, sa nastepujace:

• komunikaty zwiazane z rozpoczynaniem, konczeniem, a takze przebiegiem sesji wy-miany informacji w ramach XMXP, pojawiajace sie na skutek wykonywania swo-ich zadan przez klasy zebrane w pakiecie net.xmxp.lib.messaging.sessions– gromadzone sa one w pliku sessions.log,

• informacje specyficzne dla najbardziej niskopoziomowych funkcji zwiazanych z ob-sługa wiadomosci przesyłanych przy wykorzystaniu XMXP oraz sesjami ich trans-portu, generowane przez klasy zawarte w pakiecie net.xmxp.lib, które nie zostałypoprzednio wyszczególnione – sa one umieszczane w pliku library.log,

• informacje dotyczace warstwy transportowej XMXP, czyli komunikacji zachodzacejmiedzy systemami połaczonymi przy uzyciu tego protokołu, generowane przez klasyz pakietów net.xmxp.sender oraz net.xmxp.receiver – zapisywane sa one wpliku transport.log,

• komunikaty zwiazane z doreczaniem wiadomosci do ich koncowych odbiorców orazprzekazywaniem dalej do zdalnych systemów, czy to wykorzystujacych XMXP czytez SMTP – gromadzone sa one w pliku deliverer.log,

• informacje dotyczace wyznaczania marszrut dla poszczególnych wiadomosci, a tak-ze wymiany miedzy systemami pocztowymi informacji o obsługiwanych adresach –umieszczane sa one w pliku router.log,

• pozostałe komunikaty zwiazane z praca aplikacji serwerowej i klienckiej, wchodza-cych w skład niniejszej implementacji XMXP – zapisywane sa one odpowiednio wplikach server.log oraz CLIClient.log.

Zaproponowany, w ramach dostarczonego pliku konfiguracyjnego dla biblioteki Apa-che Log4J, format tworzonych plików dziennika zawiera wszystkie informacje, które mogabyc pomocne zarówno podczas analizy zdarzen zachodzacych w trakcie normalnej wymia-ny wiadomosci wykorzystujacej XMXP, jak i podczas poszukiwania ewentualnych błedów– czy to w stworzonych plikach konfiguracyjnych czy tez w samej implementacji. Opróczsamych komunikatów, zawarty jest równiez czas wystapienia zdarzenia, które spowodo-wało wygenerowanie danego komunikatu, a takze klasa, w której ono wystapiło. Sprawiato, iz generowane pliki dziennika sa bardzo uniwersalne – moga dostarczyc interesujacychinformacji zarówno administratorom systemu pocztowego wykorzystujacego XMXP, jak iprogramistom zajmujacym sie rozwojem niniejszej implementacji opisywanego protokołu.

79


4.5. Przeprowadzone testy

Zgodnie z idea przyswiecajaca tworzeniu implementacji proof-of-concept EXTENSIBLE MAIL

EXCHANGE PROTOCOL, jednym z najwazniejszych jej zadan jest mozliwosc przeprowadze-nia testów działania zaproponowanego protokołu. Rola tych testów w procesie opracowy-wania zarówno omawianej implementacji XMXP, jak i samego protokołu, jest kluczowa.Testy te, przede wszystkim, pozwalaja ocenic powodzenie podjetego przeze mnie przedsie-wziecia. Ponizej przedstawiony zostanie krótki raport z przeprowadzonych testów, którezostały podczas tworzenia niniejszej pracy wykonane. Zaprezentuje poszczególne rodza-je prób, którym omawiana implementacja XMXP została poddana, opisze ich przebieg, atakze przedstawie wyniki testów, opatrzone komentarzem dotyczacym ich znaczenia dlatworzonego protokołu.

Testy, które zrealizowane zostały przy uzyciu niniejszej implementacji XMXP moznapodzielic na dwie grupy. Do pierwszej z nich nalezy zaliczyc testowanie zwiazane bez-posrednio z powstałym w ramach mojej pracy kodem zródłowym stworzonych aplikacji.Celem tego typu prób było poszukiwanie błedów typu programistycznego, które spowodo-wac mogły czy to niepoprawne działanie pewnych czesci implementacji czy tez ich praceniezgodna z załozeniami opracowywanego protokołu. Drugim zas rodzajem realizowanychtestów, wykonywanych dopiero w momencie, gdy tworzone aplikacje były – w procesie ichrozwoju – na etapie pozwalajacym na swobodne ich wykorzystywanie, była analiza prze-biegu róznorodnych sesji majacych miejsce w ramach XMXP, poprawnosci ich wykonania,a takze róznych parametrów (na przykład wydajnosciowych) z nimi zwiazanych.

Pierwszym rodzajem testów, którym poddawany był tworzony w ramach niniejszej pra-cy kod zródłowy, były testy jednostkowe [41]. Jest to metoda majaca na celu weryfikacjepoprawnosci działania aplikacji poprzez sprawdzenie czy poszczególne jej moduły (czy tez„jednostki”, od których pochodzi nazwa opisywanego sposobu testowania) wykonuja po-wierzone im zadania zgodnie z oczekiwaniami. „Jednostka” w tym wypadku nazywa sienajmniejsza czesc, która wyróznic mozna w tworzonym programie, a która w samodzielnysposób jest w stanie wykonac okreslone czynnosci, weryfikowalne pod wzgledem popraw-nosci. W przypadku omawianej implementacji XMXP, jednostkami poddawanymi testombyły najczesciej pojedyncze klasy wystepujace w kodzie zródłowym, a niekiedy nawet ichsamodzielne metody. Metoda ta posiada bardzo wiele zalet. Jedna z wazniejszych jest moz-liwosc dosc łatwego i szybkiego okreslenia miejsca wystapienia danego błedu, dzieki te-stowaniu jedynie niewielkiego fragmentu programu. Jest to szczególnie istotne w przypad-ku duzych i skomplikowanych systemów, za jaki uznana moze byc implementacja proof-of-concept XMXP. Ze sprawdzaniem małych i stosunkowo prostych podprogramów wykonu-jacych jedynie podstawowe operacje zwiazana jest wzgledna prostota samych testów. Dajeona mozliwosc szybkiego i efektywnego ich tworzenia oraz przeprowadzania, dzieki cze-mu programista moze uznac je za sposób na poprawienie jakosci tworzonych aplikacji, anie za zbedny ciezar opózniajacy powstawanie zasadniczej czesci jego pracy. Niski stopienskomplikowania procedur testujacych pozwala na, praktycznie niezauwazalne dla osobytworzacej kod zródłowy, automatyczne uruchamianie ich w trakcie całego procesu powsta-wania oprogramowania, a wiec biezaca kontrole poprawnosci realizowanych przez danemoduły działan.

80


Opisana metoda, dzieki bardzo dobremu wsparciu dla niej w ramach wykorzystywane-go IDE, stosowana była podczas całego procesu tworzenia aplikacji wchodzacych w składniniejszej implementacji XMXP. Dzieki temu błedy mogły byc wychwytywane w niedłu-gim czasie po ich popełnieniu, co znaczaco przyspieszyło etap uruchomieniowy nowo-powstałego oprogramowania. Wynikiem przeprowadzonych na tym etapie testów było wy-krycie oraz usuniecie zdecydowanej wiekszosci błedów programistycznych, a takze duzegoodsetku pomyłek dokonanych w sposobie realizacji zadan aplikacji okreslonych przez pro-ponowany przeze mnie protokół.

Drugim etapem przeprowadzanego testowania, nadal dotyczacym kodu zródłowegostworzonych aplikacji, były testy integracyjne poszczególnych modułów. Jednakze ten ro-dzaj prób wykonywany był na wyzszym poziomie abstrakcji niz opisany poprzednio. Reali-zowane były one na etapie integrowania poszczególnych klas wchodzacych w skład oma-wianej implementacji XMXP w aplikacje realizujace okreslona logike działania. Testy teprzeprowadzane były wieloetapowo, aby zachowac w jak najwiekszym stopniu zalety po-przedniego etapu testowania, głównie zwiazane z mozliwoscia szybkiego zlokalizowaniaprzyczyny kazdego z wystepujacych błedów. Jest oczywiste,ze na tym etapie zostało ujaw-nionych mniej błedów niz poprzednio, jednakze były one bardziej subtelne, a tym samymtrudniejsze do wykrycia i naprawienia.

Na tym etapie bardzo istotna role odegrała analiza plików dziennika. Dzieki mozliwoscielastycznych zmian ich zawartosci, wykonalna była ciagła obserwacja najbardziej istotnychinformacji, które do nich trafiały, przy jednoczesnym odfiltrowaniu danych mniej znacza-cych dla analizowanego problemu. Pliki te stanowiły główne zródło informacji dotyczacychprzebiegu działania tworzonych aplikacji oraz błedów pojawiajacych sie podczas tego pro-cesu. To wpisy w nich sie pojawiajace stanowiły wyznacznik postepów procesu testowania,a takze pozwoliły na podjecie decyzji o zakonczeniu omawianego etapu w momencie, gdytworzone aplikacje pracowały zgodnie z oczekiwaniami we wszystkich scenariuszach testo-wych.

Istotnym załozeniem przyjetym podczas wykonywania testów, w ramach obu przedsta-wionych technik jest chec udowodnienia, iz stworzone aplikacje (czy tez pewne ich czescialbo samodzielne moduły) nie wykonuja poprawnie zadan, które sa przed nimi stawiane –czy to ogólnie, czy tez w pewnych szczególnych przypadkach. W zwiazku z tym, opraco-wane scenariusze testowe zostały dosc specyficznie dobrane. Jedynie około 50% z nich wy-konywało próby zwiazane ze sprawdzeniem zachowania okreslonego fragmentu aplikacjiw typowych jego zastosowaniach. Druga czesc stanowiły testy analizujace jego odpornoscna nietypowe oraz błedne warunki. Dopiero pozytywny wynik w obu tych przypadkachpozwalał na wysnucie wniosku, iz dany moduł lub aplikacja spełnia wymagania dotyczacesprawdzanego przypadku testowego.

Wszystkie omawiane procedury testujace przeprowadzane były wielokrotnie. Dla cze-sci z nich – zwiazanej z testowaniem jednostkowym – działo sie to automatycznie wrazze zmianami w kodzie zródłowym, dzieki udogodnieniom zawartym w Eclipse. Pozosta-łe natomiast ponawiane były półautomatycznie lub recznie. Ten sposób przeprowadzaniatestów zapewniał na kazdym etapie tworzenia implementacji proof-of-concept XMXP swe-go rodzaju testowanie regresyjne dajace mozliwosc wykrycia błedów pojawiajacych sie wmiare rozwoju opracowywanych aplikacji powodujacych błedne działanie modułów, któreuprzednio zostały juz pozytywnie przetestowane. Tego typu próby sa najbardziej istotne

81


w procesie rozwoju oprogramowania, który jest bardzo czasochłonny. Taka własnie sytu-acja miała miejsce w trakcie opracowywania omawianej implementacji XMXP, w zwiazkuz czym testy regresyjne odegrały w procesie jej rozwoju bardzo wazna role, gdyz pozwoliłyujawnic liczne pojawiajace sie podczas jego trwania regresje.

Po pozytywnym zakonczeniu opisanego pierwszego etapu testowania stworzonej im-plementacji XMXP, mozliwe było rozpoczecie testów systemowych, stanowiacych dru-ga czesc omawianego procesu. W zwiazku z wczesniejszym sprawdzeniem poprawnoscidziałania opracowanych aplikacji, etap ten polegał głównie na analizie działania same-go EXTENSIBLE MAIL EXCHANGE PROTOCOL oraz ocenie poszczególnych jego aspektów.Równiez w tym wypadku przeprowadzane próby były wieloetapowe i za kazdym razemobejmowały jedynie niewielki wycinek jego mozliwosci, co miało na celu bardziej wnikli-wa analize badanego zagadnienia. Nalezy dodac, iz niejednokrotnie niektóre moduły skła-dajace sie na implementacje proof-of-concept XMXP były w pewien sposób „wyłaczane” naczas okreslonego rodzaju testów – czy to poprzez zadanie im odpowiednich, zupełnie nie-realnych, parametrów w pliku konfiguracyjnym, czy tez niekiedy za pomoca bezposredniejingerencji w ich kod zródłowy. Działanie to miało na celu wyeksponowanie tych aspektówproponowanego protokołu, które lezały w centrum zainteresowan danego testu i uzyskaniew ten sposób bardziej klarownego obrazu warunków jego działania.

Pierwszym, najprostszym i najbardziej oczywistym testem, który został wykonany, byłamozliwosc przesłania wiadomosci stworzonej przy uzyciu aplikacji klienckiej do urucho-mionej na tym samym komputerze czesci serwerowej niniejszej implementacji XMXP. Na-stepnie dokonano próby przekazania wiadomosci w nieco bardziej skomplikowany sposób,w którym aplikacja serwerowa musiała podjac próbe przekazania wiadomosci do zdalnegosystemu pocztowego. W dalszych testach zwiekszana była liczba maszyn przekazujacychpojedyncza wiadomosc od nadawcy do adresata, a co za tym idzie – znaczaco skompliko-wana została jej marszruta. Wiadomosci były przekazywane poprawnie we wszystkich pró-bach, co pokazuje uzytecznosc zaproponowanego nie tylko protokołu w sensie mozliwosciprzekazywania wiadomosci, ale takze pod wzgledem opracowanej wraz z nim metody wy-znaczania marszrut wiadomosci.

Po wykazaniu uzytecznosci XMXP w podstawowym zakresie, mozliwe było przysta-pienie do bardziej wnikliwego badania poszczególnych jego elementów. Poprzednio wy-mienione testy przekazywania wiadomosci poprzez kilka systemów pocztowych wykony-wane były przy statycznej konfiguracji marszrut wiadomosci, wykonanej przy uzyciu pli-ków konfiguracyjnych aplikacji serwerowych działajacych w kazdym z nich. Naturalnymrozszerzeniem tego testu było wiec usuniecie statycznych wpisów i próba uzyskania ich wsposób automatyczny. W plikach konfiguracyjnych pozostawione zostały jedynie wpisy po-zwalajace skomunikowac sie ze soba systemom pocztowym, które miały „sasiadowac” zesoba w marszrucie, która zastosowana została w poprzednim tescie. Zgodnie z oczekiwa-niami, utworzony został odpowiedni ciag systemów pocztowych, który zapewnił poprawnedostarczenie wiadomosci od nadawcy do odbiorcy. Warto równiez zauwazyc, iz zgodnie zopisanymi w czesci 3.2. niniejszej pracy załozeniami, stworzona poczatkowo marszruta zo-stała szybko zoptymalizowana do znaczaco krótszej, czyli o wiele bardziej efektywnej podwzgledem ilosci generowanego w sieci ruchu.

To własnie pomiary ilosciowe zwiazane z ruchem sieciowym generowanym w wynikukomunikacji wykorzystujacej XMXP były kolejnym badanym przeze mnie zagadnieniem.

82


Jak mozna sie spodziewac, wykorzystanie dokumentów XML jako formatu wiadomoscipowoduje, iz ilosc danych, które komunikujace sie strony musza wymienic w celu prze-kazania wiadomosci, jest zdecydowanie wieksza niz w przypadku protokołów pocztowychdostepnych współczesnie na rynku. Juz samo porównanie rozmiaru koperty wiadomosci zjej odpowiednikiem w SMTP pokazuje skale problemu: w SMTP jest to zazwyczaj niewieleponad 100 bajtów, zas w XMXP osiaga ona wielkosc do 2 kilobajtów. Własciwa tresc wiado-mosci jest, w oczywisty sposób, jeszcze wieksza i, w zaleznosci od jej zawartosci, osiaga roz-miar od kilku do kilkunastu kilobajtów. Nalezy dodac, iz w przypadku opracowywanegoprzeze mnie protokołu istnieje równiez komunikacja dodatkowa, nie zwiazana bezposred-nio z wymiana listów jako takich, a dotyczaca na przykład zbierania informacji o grupachadresów obsługiwanych przez zdalne systemy pocztowe. Wszystkie te cechy sprawiaja, izXMXP moze zostac uznany za bardzo nieoszczedny pod wzgledem wykorzystywania pa-sma łacz sieciowych korzystajacych z niego. Jednakze, moim zdaniem, współczesnie niestanowi to znaczacego problemu. W zwiazku z rosnacymi w ogromnym tempie przepusto-wosciami połaczen sieciowych, kilkukrotny wzrost ilosci ruchu wytwarzanego przez syste-my transportu poczty elektronicznej nie stanowiłby duzego ich obciazenia. Nalezy jednakprzewidywac, iz pozostałe zalety XMXP spowoduja, iz taki wzrost nie wystapi, gdyz zo-stanie zrównowazony przez minimalizacje ruchu zwiazanego z niepozadanymi zjawiskamiwspółczesnie w poczcie elektronicznej wystepujacymi.

Wpływ na systemy pocztowe, a takze na wykorzystanie poczty elektronicznej przez jejkoncowych uzytkowników, ma równiez fakt zastosowania w proponowanym przeze mnieprotokole metod powodujacych przenoszenie kosztów wysłania wiadomosci na jej nadaw-ce. W tym celu przeprowadzone zostały testy zwiazane z zastosowaniem zagadek algoryt-micznych. Metoda ta powodowała, nawet przy dosc niewielkim stopniu skomplikowania,znaczacy wzrost obciazenia systemu wysyłajacego dana wiadomosc. Swiadczy to o popraw-nosci wyboru tej metody, jako podstawowej dla stworzonej implementacji XMXP. Pozwalarówniez pokładac w zagadkach algorytmicznych nadzieje na przyszłosc, gdyz powinny onestanowic rozwiazanie dobrze skalowalne na komputery o znaczaco wiekszej mocy oblicze-niowej.

Pomyslnie testy zostały zakonczone równiez w przypadku poddawania próbom po-zostałych mechanizmów opracowanych w ramach implementacji proof-of-concept XMXP.Wszystkie opisane we wczesniejszych czesciach niniejszej pracy mozliwosci, jak uwierzy-telnianie nadawcy, podejmowana na tej podstawie decyzja o doreczeniu lub nie kazdejz otrzymanych wiadomosci, hierarchiczny schemat adresowania ułatwiajacy wyznaczaniemarszrut przekazywanych wiadomosci, okazały sie – w trakcie przeprowadzanych testów– spełniac role, która została im przypisana. W zwiazku z tym uznac mozna, iz cały procestestowania zarówno EXTENSIBLE MAIL EXCHANGE PROTOCOL, jak i niniejszej jego imple-mentacji zakonczony został sukcesem. Wykazane zostało (co prawda w nieformalny spo-sób), iz opracowane rozwiazania sprawdzaja sie w praktyce i – jako takie – moga zostaczastosowane w srodowiskach rzeczywistych systemów pocztowych.

83

Rozdział 5.

Perspektywy rozwoju XMXP

Z przedstawionego w niniejszej pracy opisu zaproponowanego przeze mnie protokołutransportu poczty elektronicznej wyraznie wynika, iz mozliwe jest zaprojektowanie sposo-bu wymiany wiadomosci pocztowych bardziej odpornego na wystepujace współczesnie naomawianym rynku zagrozenia, niz protokoły obecnie wykorzystywane. Oczywistym fak-tem jest, iz w obecnej formie zaproponowany przeze mnie EXTENSIBLE MAIL EXCHANGE

PROTOCOL nie moze stac sie podstawa codziennej wymiany wiadomosci miedzy uzytkow-nikami sieci Internet czy nawet sieci lokalnych. Powodów takiego stanu rzeczy jest kilka,lecz wszystkie one wiaza sie z niedostatecznym przetestowaniem oraz wyspecyfikowaniemprzedstawionego protokołu. Chciałbym w zwiazku z tym zaproponowac w tym miejscunajwazniejsze mozliwe kierunki dalszego rozwoju XMXP – zarówno jesli chodzi o protokółjako taki, jak i z punktu widzenia stworzonej w ramach niniejszej pracy jego implementacji.

Pierwszym bardzo zauwazalnym niedostatkiem zaprezentowanego opisu XMXP jestbrak jego formalnej specyfikacji. Podany został ogólny opis załozen lezacych u jego podstaw,a takze proponowanej jego formy, lecz brak jest usystematyzowanego zebrania wszystkichcech proponowanego protokołu. Stworzenie sformalizowanej specyfikacji protokołu jest otyle istotne, iz stanowi swego rodzaju próbe spójnosci przedstawianych rozwiazan. Dziekitemu mozliwe jest odkrycie pewnych zaleznosci miedzy poszczególnymi elementami two-rzonego systemu wymiany wiadomosci elektronicznych, a wiec równiez istnieje mozliwoscpoprawy ewentualnych niespójnosci miedzy nimi znalezionych. Formalna specyfikacja po-zwoliłaby takze na zaprezentowanie wyników mojej pracy szerszemu audytorium, a wiecna uzyskanie opinii osób zwiazanych w sposób bezposredni z rynkiem poczty elektronicz-nej, na temat przedstawionych przeze mnie pomysłów.

Oprócz specyfikacji formalnej, niezbedne równiez wydaje sie przeprowadzenie sforma-lizowanych i usystematyzowanych testów omawianych w niniejszej pracy rozwiazan. Po-przez uzycie do opisu zaproponowanego XMXP pewnego dobrze zdefiniowanego sposo-bu specyfikacji protokołów, mozliwe byłoby poddanie go róznego rodzaju dalszym testom,abstrahujacym od stworzonej implementacji proof-of-concept. W ten sposób uzyskac moznaeliminacje z procesu testowania cech specyficznych dla powstałego oprogramowania, zaspołozyc wiekszy nacisk na własciwosci protokołu jako takiego. W takim podejsciu mozliwe

84

ROZDZIAŁ 5. PERSPEKTYWY ROZWOJU XMXP

byłoby nie tylko symulacyjne testowanie poszczególnych elementów omawianych rozwia-zan, a takze ich współpracy ze soba, ale równiez matematyczne (logiczne) udowodnieniepoprawnosci (lub nie) pewnych przyjetych załozen. Tego typu testowanie daje o wiele wiek-sza pewnosc dotyczaca uzyskiwanych wyników, a dzieki temu zwieksza zaufanie do przed-stawionego protokołu – zarówno wsród osób podejmujacych decyzje o jego ewentualnymwdrozeniu, jak i wsród koncowych jego uzytkowników.

Jednakze testy formalne nie moga stanowic głównego filaru, na którym oparty byłbyproces wykazywania uzytecznosci opracowanych w ramach niniejszej pracy podejsc doproblemów zwiazanych ze współczesnym rynkiem poczty elektronicznej. Znane sa w histo-rii informatyki (i nie tylko) liczne przypadki stworzonych rozwiazan, które mimo swej for-malnej poprawnosci i udowodnionych licznych zalet, nigdy nie stały sie popularne wsródszerszej rzeszy uzytkowników. Zazwyczaj powodem takiego stanu rzeczy, jest fakt, iz by-ły one tworzone w oderwaniu od rzeczywistych warunków kształtujacych potrzeby osób,dla których miały byc przeznaczone. Nalezy zatem dazyc do unikniecia podobnych pro-blemów w przypadku XMXP. Ich rozwiazaniem powinno byc przeprowadzenie próbnegowdrozenia zaproponowanego protokołu. Opisane w czesci 4.5. testy omawianego protoko-łu, a takze stworzonej jego implementacji, nie dotyczyły szerszego grona osób – wiekszoscz nich przeprowadzona została przeze mnie samodzielnie, w ramach tworzenia niniejszejpracy. Zatem w perspektywie dalszego rozwoju omawianego protokołu, bardzo istotne by-łoby umozliwienie wybranej grupie osób przetestowania go w warunkach rzeczywistego,codziennego wykorzystania poczty elektronicznej, a nastepnie zebranie ich uwag i opiniioraz uwzglednienie ich w procesie rozwijania i ulepszania XMXP.

Przeprowadzenie testów zwiazanych z wdrozeniem zaproponowanego przeze mnieprotokołu wiaze sie z koniecznoscia stworzenia jego pełnej implementacji. Przedstawio-na jej wersja proof-of-concept, jak juz zostało to omówione w rozdziale 4. niniejszej pra-cy, zawiera liczne uproszczenia, a takze została celowo pozbawiona pewnych mozliwosci.Stworzenie wersji uzytkowej, zawierajacej wszystkie z zaproponowanych rozwiazan, dało-by przede wszystkim mozliwosc przeprowadzenia dalszych testów dotyczacych tych cechXMXP, które do tej pory nie mogły zostac poddane próbom praktycznym. Ponadto naleza-łoby rozwazyc wprowadzenie pewnych ulepszen dotyczacych samej implementacji. Nalezywsród nich wymienic stworzenie graficznego klienta pozwalajacego na bardziej wygodnekorzystanie z omawianego protokołu przez jego koncowych uzytkowników, róznego ro-dzaju optymalizacje kodu zródłowego, lepsza integracje z obecnie istniejacymi systemamipoczty elektronicznej (na przykład mozliwosc przesyłania wiadomosci od nadawców wy-korzystujacych SMTP do odbiorców korzystajacych z XMXP) itp.

Jak juz zostało wczesniej wielokrotnie w mojej pracy podkreslone, wszystkie omówio-ne rozwiazania dotyczace stworzonego protokołu, sa jedynie przykładowymi mozliwoscia-mi odpowiedzi na najwazniejsze problemy zwiazane ze współczesnym rynkiem transportupoczty elektronicznej. Moim zdaniem, konieczne jest w zwiazku z tym przeprowadzeniebadan nad alternatywnymi dla nich propozycjami. Dobrym przykładem moze byc sposóbwyznaczania marszrut wiadomosci oraz ich przekazywania miedzy systemami pocztowy-mi. Podejscie zaproponowane przeze mnie, jako wzorowane na rozwiazaniu stosowanym wsieciach IP, jest przeznaczone dla obsługi ruchu w sposób wysoce wydajny. Niejednokrotniejednakze nie to jest głównym wymaganiem uzytkowników poczty elektronicznej. Koniecz-ne zatem byłoby opracowanie innych metod podejscia do tego problemu – na przykład

85

ROZDZIAŁ 5. PERSPEKTYWY ROZWOJU XMXP

gwarantujacych wysoka niezawodnosc czy tez łaczacych obie wymienione cechy. Analo-giczna sytuacja ma miejsce w przypadku schematów adresowania czy tez metod obciazanianadawcy wiadomosci kosztami jej transportu. Na wszystkich tych polach konieczne było-by wykonanie zakrojonych na szeroka skale badan dotyczacych mozliwosci technicznychzwiazanych z kazdym z poruszonych problemów, opracowanych zarówno w ramach pracnaukowych, jak i inzynierskich rozwiazan dotyczacych kazdego z nich, a takze wymaganprzedstawianych przez koncowych uzytkowników systemów poczty elektronicznej.

Dokładna analiza własciwosci EXTENSIBLE MAIL EXCHANGE PROTOCOL wskazuje, izbardzo waznym kierunkiem przyszłego jego rozwoju mogłoby byc poszukiwanie zastoso-wan, w których byłby on w stanie dobrze spełniac stawiane przed nim wymagania, a którenie były przedmiotem moich rozwazan w ramach niniejszej pracy. Jednym z najbardziejoczywistych jest mozliwosc wykorzystania opracowanego protokołu do transportu elektro-nicznej wiadomosci pocztowej od jej nadawcy, nie tylko do skrzynki pocztowej odbiorcyumieszczonej na serwerze, ale nawet dalej – do klienta pocztowego pracujacego na jegolokalnym komputerze. Szczególnie istotnymi cechami XMXP pozwalajacymi na zastosowa-nie go w tego typu sytuacji, sa mozliwosci zwiazane z doreczaniem wiadomosci na zadaniesystemu odbiorczego, a takze z powiadamianiem go o oczekujacych listach do niego ad-resowanych. Prawdopodobnie podobnych zastosowan znalezc mozna wiele – koniecznajest dokładna analiza rynku usług pocztowych pod tym wzgledem, która pomoze okreslicpotencjalne obszary, w których opracowany przeze mnie protokół mógłby zostac wykorzy-stany.

Z pewnoscia, oprócz przedstawionych powyzej, istnieja równiez dalsze kierunki roz-woju EXTENSIBLE MAIL EXCHANGE PROTOCOL. Jako ze do jego najbardziej fundamental-nych załozen projektowych nalezy rozszerzalnosc oraz elastycznosc, to z pewnoscia moz-liwe jest opracowanie wielu bardzo interesujacych rozwiazan na jego bazie – czy to jakozestawu sugestii dotyczacych sposobów minimalizacji problemów wiazacych sie współcze-snie z transportem poczty elektronicznej, czy tez jako protokołu przesyłania wiadomoscijako takiego. Ich odkryciu, z pewnoscia, mogłaby sie przysłuzyc publikacja wyników uzy-skanych w ramach niniejszej pracy, wraz z wymieniona juz wczesniej formalna specyfikacjastworzonego protokołu. Równiez udostepnienie stworzonej implementacji proof-of-conceptXMXP na licencji spełniajacej załozenia Free Software jest, moim zdaniem, krokiem w kierun-ku umozliwienia dalszego jej rozwoju. Według mnie, jest to jeden z najbardziej podstawo-wych elementów dazenia do spopularyzowania rozwiazan przedstawionych w niniejszejpracy. Jestem bowiem zdania, iz bez wzgledu na liczbe pomysłów i jakosc proponowanychkierunków ewolucji rynku poczty elektronicznej, jeden człowiek nie jest w stanie stworzycprotokołu, który mógłby na nim odniesc znaczacy sukces. Jednakze wzbudzenie zaintereso-wania propozycjami, które padły w mojej pracy, moze spowodowac w srodowisku z pocztaelektroniczna zwiazanym dyskusje prowadzaca nie tylko do wskazania perspektyw istnie-nia w nim XMXP, ale równiez przyszłego charakteru wymiany elektronicznych wiadomoscijako całosci.

86

Podsumowanie

Celem niniejszej pracy było wskazanie i analiza najwazniejszych problemów wystepuja-cych na współczesnym rynku usług zwiazanych z poczta elektroniczna. Zaprezentowanyzostał wpływ na wymiane wiadomosci takich zjawisk, jak spam czy problemy z identyfi-kacja nadawcy. Przedstawione zostały równiez trudnosci, z którymi borykac sie zmusze-ni sa administratorzy systemów pocztowych, takie, jak praktyczny brak automatycznegowyznaczania marszruty transportowanych wiadomosci. Z analizy kazdego z tych zjawiskwyciagnac mozna wspólny wniosek o ich zasadniczym, negatywnym wpływie nie tylko nastopien skomplikowania procesów zachodzacych na rynku transportu poczty elektronicz-nej, ale takze na wygode korzystania z niej koncowych jej uzytkowników.

Jako odpowiedzi na wymienione problemy, podane zostały (po wczesniejszym przeana-lizowaniu) stosowane współczesnie metody minimalizacji ich skutków. Omówiona zostałaich skutecznosc oraz rola, jaka pełnia w transporcie poczty elektronicznej takim, jakim jeston współczesnie. Jednakze nalezy podkreslic fakt, iz praktycznie zadna z zaprezentowa-nych technik nie prowadzi do systemowego rozwiazania omówionych trudnosci. Wszyst-kie one stanowia jedynie czesciowe łagodzenie wpływu wystepujacych niedogodnosci nawykorzystanie usług pocztowych przez ich koncowego uzytkownika. Dodatkowo istotnejest, iz wprowadzanie kolejnych tego typu zmian w stosowanych obecnie metodach trans-portu poczty elektronicznej nie jest rzecza łatwa. Istnieje wiele trudnosci zwiazanych z ichwdrazaniem w srodowisku zdominowanym przez protokoły trudno rozszerzalne, jak naprzykład SMTP, powodujacych nie tylko utrudnienia podczas implementacji i projektowa-nia zmian ich dotyczacych, ale równiez zniechecajacych potencjalnych autorów odpowied-nich modyfikacji do ich tworzenia.

Przedstawiona w niniejszej pracy propozycja rozwiazania omawianych problemów sta-nowi zobrazowanie systemowego podejscia do nich – moim zdaniem najwłasciwszego wsytuacji, która obecnie na rynku poczty elektronicznej wystepuje. Jestem swiadom, iz stwo-rzenie nowego protokołu transportu poczty elektronicznej jest decyzja bardzo niepopular-na. Z tego powodu, a takze przez chec zachowania pełnej zgodnosci wstecznej i dokony-wania jak najmniejszych zmian w stosowanych rozwiazaniach, do tej pory wprowadzanebyły jedynie kolejne poprawki i rozszerzenia do metod wykorzystywanych współczesnie.Takie podejscie wynika z konserwatywnosci wielu srodowisk zwiazanych z poczta elektro-niczna, czy tez szerzej – z siecia Internet w ogólnosci. Jednak zdecydowanie widoczne jest,iz drobne zmiany ewolucyjne nie pozwoliły na zredukowanie liczby problemów wystepu-jacych podczas codziennego korzystania z usług pocztowych. Mozna pokusic sie nawet ostwierdzenie, iz nie zwiekszyły one w znaczacy sposób wygody korzystania z tych usług,

87

PODSUMOWANIE

z punktu widzenia ich koncowych uzytkowników. Wobec takich doswiadczen, moim zda-niem, najwłasciwszym podejsciem jest rozwiazanie w pewien sposób rewolucyjne, a jed-noczesnie systemowe – zaprojektowanie rozwiazan nie obarczonych ciezarem wymaganiazgodnosci wstecznej, a wiec mogacych w sposób bardziej swobodny, i jednoczesnie bardziejskuteczny, podchodzic do napotykanych problemów.

EXTENSIBLE MAIL EXCHANGE PROTOCOL nalezy rozwazac w kategoriach zbioru pro-pozycji rozwiazan dla poszczególnych niedogodnosci zwiazanych z transportem pocztyelektronicznej na współczesnym rynku z nia zwiazanym. Główna rola niniejszej pracy byłoprzedstawienie wachlarza mozliwych koncepcji, które moga zostac zastosowane w momen-cie, gdy projektant systemu pocztowego otrzyma wieksza swobode, niz daje mu zamyka-nie sie w ramach scisle wytyczonych przez współczesnie popularne protokoły transportuwiadomosci. Stworzenie protokołu, który łaczy w sobie zaprezentowane rozwiazania w pe-wien okreslony sposób, miało na celu głównie wykazanie ich praktycznej stosowalnosci,mozliwosci oparcia na nich rzeczywistego systemu pocztowego,a takze zbudowanie swe-go rodzaju platformy dla przeprowadzanych testów i prób zwiazanych z proponowanymitechnikami.

Jednakze mozliwe jest rozpatrywanie podanych rozwiazan takze w oderwaniu odXMXP. W takiej sytuacji stanowia one podstawe do ogólnych rozwazan o zasadniczymkształcie współczesnego rynku zwiazanego z poczta elektroniczna oraz o głównych moz-liwych kierunkach jego rozwoju w blizszej lub dalszej przyszłosci. W oczywisty sposób,moim celem nie było stworzenie idealnego rozwiazania, które stanowiłoby uniwersalne re-medium na wszystkie problemy zwiazane z transportem poczty elektronicznej, gdyz zdajesobie sprawe, iz jest to praktycznie niewykonalne. Chciałem jedynie zwrócic uwage czytel-nika na skale istniejacych problemów, na niska skutecznosc stosowanych obecnie metod icheliminacji oraz pokazac, moim zdaniem, bardziej prawidłowy sposób ich rozwiazywania.

Niniejsza praca stanowic moze dobry punkt wyjscia do dalszych badan w zakresie oma-wianej problematyki, gdzie najistotniejsza role powinny odgrywac zagadnienia zwiazanez rozwojem XMXP, które omówione zostały w rozdziale 5. lub im pokrewne. Jednakzemozliwe jest równiez podjecie innego ich kierunku, w niezbyt scisły sposób powiazanegoz opracowanym przeze mnie protokołem – na przykład dotyczacego integracji opracowa-nych rozwiazan w ramach istniejacych systemów wymiany poczty elektronicznej czy tezewolucji tych systemów we wskazanych w niniejszej pracy kierunkach. Niemniej jednak,moim kierunkiem dalszej analizy przedstawionych problemów bedzie własnie zapropono-wany protokół, gdyz stanowi on przykład systemowego i bardzo analitycznego podejscia,którego w chwili obecnej na rynku usług zwiazanych z poczta elektroniczna niewatpliwiebardzo brakuje.

Mam nadzieje wzbudzic w społecznosci osób zwiazanych z omawianym rynkiem zain-teresowanie poruszonymi przeze mnie problemami, a takze sprowokowac zywa dyskusjedotyczaca sposobów ich rozwiazywania. Chciałbym, aby przedstawiane rozwiazania niebyły tworzone przeze mnie samodzielnie, a stanowiły wynik opracowan szerszej grupy ba-daczy, a co za tym idzie – unifikowały wiele róznych spojrzen na analizowana sytuacje.Moim zdaniem, w procesie opracowywania zakrojonych na tak szeroka skale zmian w spo-sobie działania usługi wykorzystywanej przez szeroka rzesze uzytkowników, bardzo istot-ne jest zaangazowanie wiekszej liczby osób, byc moze reprezentujacych rózne srodowiska,a wiec równiez rózne poglady. Daje to mozliwosc wspólnego wypracowania rozwiazania,

88

PODSUMOWANIE

które spełniałoby wymagania reprezentujace róznorodne podejscia do poczty elektronicz-nej, a wiec najbardziej uniwersalnego, a co za tym idzie – równiez prawdopodobnie takie-go, które w pózniejszym okresie mogłoby zdobyc najszersze grono uzytkowników. Pracew wiekszym zespole badawczo-rozwojowym pozwalaja równiez miec nadzieje na zwiek-szenie szans przeprowadzenia rzeczywistych wdrozen opracowywanych rozwiazan, co po-winno byc, według mnie, jednym z najbardziej zasadniczych celów tego typu działan.

89

Dodatek A.

Przykładowe pliki konfiguracyjne

Plik konfiguracyjny aplikacji serwerowej

1 <?xml version=" 1 . 0 " encoding="UTF−8" ?>< c o n : c o n f i g u r a t i o n f lavour=" Niente " version=" 1 . 0 "xmlns:con=" h t t p : //niente . eu . org/Config "xmlns :xs i=" h t t p : //www. w3 . org /2001/XMLSchema−i n s t a n c e ">

5 <con:key name=" ExternalAddress "><fa :Externa lAddress

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">1 7 2 . 2 4 . 0 . 5

</fa :Externa lAddress>10 </con:key>

<con:key name=" L i s t e n i n g P o r t ">< f a : L i s t e n i n g P o r t

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">15 9743

</ f a : L i s t e n i n g P o r t ></con:key>

<con:key name=" ProcmailPath ">20 <fa :Procmai lPath

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">/usr/bin/procmail

</fa :Procmai lPath></con:key>

25

<con:key name=" RoutingInformationQueryingSleepTime "><fa:RoutingInformationQueryingSleepTime

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">600

30 </fa:RoutingInformationQueryingSleepTime></con:key>

<con:key name=" RoutingInformationHostQueryInterval "><fa :Rout ingInformat ionHostQueryInterval

35 xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">30

</fa :Rout ingInformat ionHostQueryInterval>

90

DODATEK A. PRZYKŁADOWE PLIKI KONFIGURACYJNE

</con:key>

40 <con:key name=" SMTPSmarthost "><fa:SMTPSmarthost

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">smtp−gateway . xmxp . net

</fa:SMTPSmarthost>45 </con:key>

<con:key name=" SMTPSmarthostPort "><fa:SMTPSmarthostPort


</fa:SMTPSmarthostPort></con:key>

<con:key name=" SMTPSmarthostLogin ">55 <fa:SMTPSmarthostLogin

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">smarthost

</fa:SMTPSmarthostLogin></con:key>

60

<con:key name=" SMTPSmarthostPassword "><fa:SMTPSmarthostPassword

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">s e c r e t

65 </fa:SMTPSmarthostPassword></con:key>

<con:key name=" QueuedDeliveryInit ia lSleepTime "><fa :QueuedDel iveryIn i t ia lS leepTime


</fa :QueuedDel iveryIn i t ia lS leepTime></con:key>

75 <con:key name=" QueuedDeliverySleepTimeIncreasingFactor "><fa :QueuedDel iverySleepTimeIncreasingFactor

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">2

</fa :QueuedDel iverySleepTimeIncreasingFactor>80 </con:key>

<con:key name=" QueuedDeliveryMaximumDeliveryAttempts "><fa:QueuedDeliveryMaximumDeliveryAttempts


</fa:QueuedDeliveryMaximumDeliveryAttempts></con:key>

<con:key name=" QueuedDelivererSpoolFileName ">90 <fa:QueuedDelivererSpoolFileName

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">QueuedDeliverer . spool

</fa:QueuedDelivererSpoolFileName></con:key>

95

<con:key name=" SMTPDelivererSpoolFileName "><fa:SMTPDelivererSpoolFileName

91


xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">SMTPDeliverer . spool

100 </fa:SMTPDelivererSpoolFileName></con:key>

<con:key name=" DefaultRiddleCost "><f a : D e f a u l t R i d d l e C o s t


</f a : D e f a u l t R i d d l e C o s t></con:key>

110 <con:key name=" B a n n e d C e r t i f i c a t e s ">< f a : B a n n e d C e r t i f i c a t e s

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">< f a : C e r t i f i c a t e S e r i a l N u m b e r >

16016382685415076882115 </ f a : C e r t i f i c a t e S e r i a l N u m b e r >

</ f a : B a n n e d C e r t i f i c a t e s ></con:key>

120 <con:key name=" ServedAddresses "><fa:ServedAddresses

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig "><fa:AddressGroup>

< f a : R i g h t P a r t f a : p o s i t i o n =" 0 ">net</ f a : R i g h t P a r t >125 < f a : R i g h t P a r t f a : p o s i t i o n =" 1 "> t e s t </ f a : R i g h t P a r t >

</fa:AddressGroup></fa:ServedAddresses>

</con:key>

130 <con:key name=" OtherServersServedAddresses "><fa :OtherServersServedAddresses

xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">< f a : S e r v e r f a : a d d r e s s =" 1 7 2 . 2 4 . 0 . 1 " f a : p o r t =" 9743 ">

<fa:AddressGroup>135 < f a : R i g h t P a r t f a : p o s i t i o n =" 0 ">net</ f a : R i g h t P a r t >

< f a : R i g h t P a r t f a : p o s i t i o n =" 1 ">xmxp</ f a : R i g h t P a r t ></fa:AddressGroup>

<fa:AddressGroup>< f a : R i g h t P a r t f a : p o s i t i o n =" 0 ">org</ f a : R i g h t P a r t >

140 < f a : R i g h t P a r t f a : p o s i t i o n =" 1 ">eu</ f a : R i g h t P a r t >< f a : R i g h t P a r t f a : p o s i t i o n =" 2 ">niente</ f a : R i g h t P a r t >

</fa:AddressGroup></ f a : S e r v e r >

</fa :OtherServersServedAddresses>145 </con:key>

<con:key name=" LocalUsers ">< f a : L o c a l U s e r s xmlns : fa=" h t t p : //www. xmxp . net/server/conf ig ">

< f a : R e c e i p i e n t f a : l e f t A d d r e s s P a r t =" g o l i s h " f a : u s e r =" g o l i s h " />150 < f a : R e c e i p i e n t f a : l e f t A d d r e s s P a r t =" t e s t " f a : u s e r =" g o l i s h " />

</ f a : L o c a l U s e r s ></con:key>

</ c o n : c o n f i g u r a t i o n >

Listing A.1. — Przykładowy plik konfiguracyjny serwera XMXP

92


Plik konfiguracyjny aplikacji klienckiej

1 <?xml version=" 1 . 0 " encoding="UTF−8" ?>< c o n : c o n f i g u r a t i o n f lavour=" Niente " version=" 1 . 0 "xmlns:con=" h t t p : //niente . eu . org/Config "xmlns :xs i=" h t t p : //www. w3 . org /2001/XMLSchema−i n s t a n c e ">

5 <con:key name=" DefaultServerAddress "><fa :Defaul tServerAddress

xmlns : fa=" h t t p : //www. xmxp . net/ c l i e n t /conf ig ">1 2 7 . 0 . 0 . 1

</fa :Defaul tServerAddress>10 </con:key>

<con:key name=" Defaul tS igningKeyFi le ">< f a : D e f a u l t S i g n i n g K e y F i l e

xmlns : fa=" h t t p : //www. xmxp . net/ c l i e n t /conf ig ">15 p r i v a t e . key

</ f a : D e f a u l t S i g n i n g K e y F i l e ></con:key>

<con:key name=" D e f a u l t S i g n i n g C e r t i f i c a t e F i l e ">20 < f a : D e f a u l t S i g n i n g C e r t i f i c a t e F i l e

xmlns : fa=" h t t p : //www. xmxp . net/ c l i e n t /conf ig ">p r i v a t e . c r t

</ f a : D e f a u l t S i g n i n g C e r t i f i c a t e F i l e ></con:key>

25

<con:key name=" DefaultFromAddress "><fa:DefaultFromAddress

xmlns : fa=" h t t p : //www. xmxp . net/ c l i e n t /conf ig ">golish@xmxp . net

30 </fa:DefaultFromAddress></con:key>

</ c o n : c o n f i g u r a t i o n >

Listing A.2. — Przykładowy plik konfiguracyjny klienta XMXP

93

Bibliografia

[1] Tom Van Vleck. The History of Electronic Mail. http://www.multicians.org/thvv/mail-history.html.

[2] Ray Tomlinson. The First Network Email. http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html.

[3] RFC 822: Standard for the Format of ARPA Internet Text Messages. 1982.

[4] RFC 354: The File Transfer Protocol. 1972.

[5] RFC 561: Standardizing Network Mail Headers. 1973.

[6] RFC 680: Message Transmission Protocol. 1975.

[7] RFC 724: Proposed Official Standard for the Format of ARPA Network Messages. 1977.

[8] RFC 733: Standard for the Format of ARPA Network Text Messages. 1977.

[9] NTIS. Implications of Electronic Mail and Message Systems for the U.S. Postal Service. 1982.

[10] ITU-T Reccomendation X.400/F.400 (ISO/IEC 10021) Data Communication Networks forMessage Handling Systems. 1999.

[11] RFC 821: Simple Mail Transfer Protocol. 1982.

[12] Dave Crocker. Email History. http://www.livinginternet.com/e/ei.htm.

[13] Brad Templeton. Reflections on the 25th Anniversary of Spam. http://www.templetons.com/brad/spam/spam25.html.

[14] RFC 706: On the Junk Mail Problem. 1975.

[15] Pew Internet & American Life Project. Internet Activities – Latest Trends. http://www.pewinternet.org/trends/Internet_Activities_2.15.08.htm, Luty 2008.

[16] Pew Internet & American Life Project. Daily Internet Activities – Latest Trends.http://www.pewinternet.org/trends/Daily_Internet_Activities_2.15.08.htm, Luty 2008.

[17] Ferris Research. Industry Email Usage Statistics. http://www.ferris.com/research-library/industry-statistics/, 2005.

[18] RFC 3700: Internet Official Protocol Standards. 2004.

94

BIBLIOGRAFIA

[19] RFC 2821: Simple Mail Transfer Protocol. 2001.

[20] RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. 2002.

[21] RFC 1985: SMTP Service Extension for Remote Message Queue Starting. 1996.

[22] RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages.1996.

[23] Gecad Technologies. Mail Radar Statistics. http://www.mailradar.com/mailstat/.

[24] RFC 976: UUCP Mail Interchange Format Standard. 1986.

[25] RFC 2822: Internet Message Format. 2001.

[26] Jonathan A. Zdziarski. Ending Spam. Bayesian Content Filtering and the Art of StatisticalLanguage Classification. No Starch Press, 2005.

[27] Distributed Checksum Clearinghouse. Distributed Checksum Clearinghouse Graphs.http://www.dcc-servers.net/dcc/graphs/?resol=5y&BIG=1.

[28] Guido Schryen. Anti-Spam Measures: Analysis and Design. Springer, 2007.

[29] James Carpintera and Ray Hunt. Tightening the net: A review of current and nextgeneration spam filtering tools. Computers & Security, 25(8):566–578, Listopad 2006.

[30] RFC 4880: OpenPGP Message Format. 2007.

[31] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, and JohnCowan. Extensible Markup Language (XML) 1.1 (Second Edition). 2006.

[32] Luis Von Ahn, Manuel Blum, and John Langford. CAPTCHA: Using hard AI problemsfor security. 2003.

[33] Kitty Niles Donald E. Eastlake III. Secure XML: The New Syntax for Signatures andEncryption. Addison Wesley Professional, 2002.

[34] Iljitsch van Beijnum. BGP. Building Reliable Networks with the Border Gateway Protocol.O’Reilly, 2002.

[35] Bruce Eckel. Thinking in Java, 4th edition. Prentice Hall, 2006.

[36] Joshua Bloch Joseph Bowbeer David Holmes Doug Lea Brian Goetz, Tim Peierls. JavaConcurrency in Practice. Addison Wesley Professional, 2006.

[37] Elliotte Rusty Harold. Java Network Programming, 2nd Edition. O’Reilly, 2000.

[38] David Carlson. Eclipse Distilled. Addison Wesley Professional, 2005.

[39] Elliotte Rusty Harold. Processing XML with JavaTM: A Guide to SAX, DOM, JDOM, JAXP,and TrAX. Addison Wesley Professional, 2002.

[40] Jonathan Knudsen. Java Cryptography. O’Reilly, 1998.

[41] Paul Hamill. Unit Test Frameworks. O’Reilly, 2006.

95

Documents

Praca dyplomowa magisterska Marcin Goliszewski Protokół ...staff.elka.pw.edu.pl/~mgolisze/papers/XMXP_-_M...Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych