Wydajny filtr SMTP PRACA DYPLOMOWA INŻYNIERSKA. Katarzyna Ciechańska. dr inż. Grzegorz Blinowski

Transkrypt

1 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Rok akademicki 2008/2009 PRACA DYPLOMOWA INŻYNIERSKA Katarzyna Ciechańska Wydajny filtr SMTP Opiekun pracy: dr inż. Grzegorz Blinowski Ocena Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

2 Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 21 kwietnia 1985 r. Data rozpoczęcia studiów: 23 luty 2004 r. ŻYCIORYS Urodziłam się 21 kwietnia 1985r. w Warszawie. Po ukończeniu szkoły podstawowej nr 195 w Warszawie w roku 1999, kontynuowałam naukę w XIX Liceum Ogólnokształcącym im. Powstańców Warszawy w Warszawie. Uczęszczałam do klasy o profilu matematyczno - fizycznym z rozszerzonym językiem angielskim. W lutym 2004 r. rozpoczęłam studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W roku 2006 wybrałam specjalność Inżynieria Systemów Informatycznych podpis studenta Egzamin dyplomowy Złożyła egzamin dyplomowy w dn z wynikiem Ogólny wynik studiów Dodatkowe wnioski i uwagi Komisji

3 Streszczenie Przedmiotem niniejszej pracy jest przedstawienie projektu wydajnego narzędzia do filtrowania poczty elektronicznej, działającego jako aplikacyjne proxy SMTP (ang. Simple Mail Transfer Protocol). W pracy zawarto opis działania protokołu SMTP, ze szczególnym uwzględnieniem standardu MIME (ang. Multipurpose Internet Message Extensions). Ważną jej częścią jest rozdział poświęcony omówieniu struktury wiadomości . Przedstawiono koncepcję kontroli zawartości przesyłek elektronicznych oraz zaprezentowano stosowane obecnie metody takiej kontroli. Dokonano przeglądu dostępnego na rynku oprogramowania, realizującego funkcję content security. Integralną częścią pracy jest szkieletowy system filtrujący. Aplikacja umożliwia sprawdzenie wiadomości pod kątem zgodności z obowiązującymi standardami oraz klasyfikację do grupy przesyłek poprawnych, szkodliwych lub niepożądanych. Kluczowym modułem programu jest wydajny i stabilny parser wiadomości. Słowa kluczowe: , content security, SMTP, MIME, filtracja wiadomości, badanie zawartości, poczta elektroniczna, RFC, MTA, serwer pocztowy. THE EFFICIENT SMTP PROTOCOL FILTER Abstract This master thesis covers the concept of efficient electronic mail filtering tool, working as an SMTP (Simple Mail Transfer Protocol) protocol proxy. The dissertation contains description of SMTP protocol. MIME (Multipurpose Internet Message Extensions) extension was presented in detail. The chapter about message structure is one of the most important parts of the paper. Next the thesis investigates ways of controlling message content. It presents commonly used methods of content filtering and an overview of popular content filtering tools. Vital part of this work is a filtering application framework, which enables checking validity of messages acording to norms and standards. It s main functionality is to classify messages into groups of correct, harmful and unwanted messages. The efficient and stable parser is the key module of the application. Key words: , content security, SMTP, MIME, message filtering, content filtering, electronic mail, RFC, MTA, mail server.

4 Spis treści 1. Wstęp Wprowadzenie do tematyki filtrowania zawartości Cel pracy Zawartość merytoryczna i układ dokumentu Protokół SMTP Historia SMTP Projekt i implementacja filtru Architektura aplikacji Obsługa protokołu SMTP Obsługa sesji SMTP Komunikacja sieciowa Badanie zawartości wiadomości Reprezentacja wiadomości Parsowanie wiadomości Filtrowanie i klasyfikacja wiadomości Watch Dog Obsługa sytuacji nietypowych Problem wyczerpania się pamięci Brak połączenia z serwerem docelowym

5 1. Wstęp Początki poczty elektronicznej sięgają lat 60 ubiegłego wieku. Pierwsze jej implementacje pozwalały na przekazywanie wiadomości jedynie pomiędzy użytkownikami tej samej maszyny. W chwili obecnej usługa umożliwia przepływ informacji między nadawcami i odbiorcami na całym świecie. Stała się jedną z podstawowych, jeśli nie podstawową, formą komunikacji w dużych firmach i pomiędzy partnerami biznesowymi. Obok oczywistych korzyści, poczta elektroniczna niesie ze sobą zagrożenia. Szczególnie trudnym do zwalczenia problemem okazał się spam. Wg. Gartner Group [potrzebny odnośnik] przeciętny użytkownik Internetu spędza na segregowaniu i przeglądaniu wiadomości pocztowych około 15 minut dziennie, pracownik działu IT - 49 minut. Gdyby nie otrzymywali spamu, czas ten skróciłby się o blisko 30%. Spam nie tylko utrudnia korzystanie z poczty elektronicznej, ale także stwarza ryzyko zniszczenia lub uszkodzenia ważnych danych. Do masowo wysyłanych wiadomości często załączane jest złośliwe oprogramowanie. Ofiarą zakażenia wirusem, koniem trojańskim czy programem szpiegowskim nie musi paść tylko pojedyncza stacja robocza. Czasem nieopatrznie uruchomiony plik wykonywalny może poskutkować sparaliżowaniem sieci całej korporacji. Oprócz wymienionych, do wad spamu należą: ograniczanie przepustowości łącz, a niekiedy nawet ich blokowanie, oraz spowalnianie pracy niepotrzebnie przetwarzających spam serwerów pocztowych. Niechciane listy w skrzynce pocztowej to efekt braku kontroli nad treścią wiadomości przychodzących. Podobna trudność wiąże się z pocztą wychodzącą, która jest potencjalnym źródłem wycieku informacji. Stanowi to poważny problem, zwłaszcza dla dużych organizacji, dla których ważne jest zabezpieczenie przed kradzieżą własności intelektualnej oraz ochrona poufnych informacji, np. danych personalnych, stosowanych rozwiązań albo raportów dotyczących planowanych kierunków rozwoju. Łamanie polityki bezpieczeństwa firmy może mieć miejsce w dwóch przypadkach - gdy zastrzeżone informacje przedostają się poza obręb przedsiębiorstwa oraz gdy ma do nich wgląd nieuprawniony personel. Zdarza się także, że pracownicy, wykorzystując służbowe skrzynki pocztowe, dopuszczają się czynów karalnych, np. rozpowszechniając nielegalne oprogramowanie lub inne materiały, np. o treściach pornograficznych. Dlatego na rynku IT bardzo poszukiwane są rozwiązania uniemożliwiające przesyłanie niepożądanych treści.

6 ROZDZIAŁ 1. WSTĘP 1.1. Wprowadzenie do tematyki filtrowania zawartości Wymiana informacji za pomocą poczty elektronicznej opiera się na rozpowszechnionych od lat standardach. Szeroko stosowany jest prosty tekstowy protokół SMTP (ang. Simple Mail Transfer Protocol). Mimo, że jest stale uzupełniany o rozszerzenia (np. w pażdzierniku 2008 r. wprowadzono aktualizację specyfikacji standardu [potrzebny odnośnik] ), pozostaje mało odporny na ataki spamerów. Dzieje się tak, ponieważ jego twórcy nie przewidzieli problemów spamu czy wycieku informacji, a nie wszystkie serwery pocztowe obsługują odpowiednie rozszerzenia protokołu. Należy także zauważyć, że wiele z nich w ogóle nie reaguje na niezgodności ze standardem SMTP, jakich dopuszcza się klient w czasie komunikacji. Często ignorowane są rozbieżności w konstrukcji nagłówków koperty oraz nagłówków samych przesyłanych wiadomości. Ponieważ w chwili obecnej nie są znane dobre metody eliminujące ten problem na poziomie protokołu komunikacyjnego, należy szukać ich rozwiązania w oprogramowaniu działającym jako warstwa znajdująca się ponad takim protokołem. Funkcjonalność ta jest realizowana za pomocą aplikacji wyposażonych w funkcje filtrowania listów na podstawie badania ich zawartości, czyli tzw. content security. Oprogramowanie content security łączy w sobie analizę przebiegu sesji SMTP z kontrolą treści przesyłki pocztowej. Na podstawie obserwacji protokołu można sprawdzić tożsamość nadawców poczty, zidentyfikować wiadomości wysyłane do ukrytych lub nie znanych odbiorców, zapewnić zgodność jej przesyłania ze standardem SMTP itp.. Badanie treści polega na wyodrębnianiu z wiadomości poszczególnych części, które poddawane są następnie właściwej analizie. Wynikiem może być np. rozpoznanie błędów w strukturze wiadomości, skategoryzowanie wiadomości na podstawie analizy kontekstowej użytych słów lub wykrycie złośliwego oprogramowania. Wraz z narzędziami monitorującymi ruch wchodzący do i wychodzący z sieci lokalnej oraz z odpowiednio sformułowaną polityką bezpieczeństwa, oprogramowanie content security tworzy skuteczny firewall firmy Cel pracy Celem niniejszej pracy jest przedstawienie koncepcji wydajnego filtra protokołu SMTP, realizującego funkcje content security oraz zaimplementowanie szkieletowej aplikacji, spełniającej to wymaganie. Filtr ma umożliwiać zbadanie zawartości przesyłanych za pomocą wspomnianego protokołu wiadomości, klasyfikowanie ich oraz przeprowadzanie na nich określonych akcji, takich jak: poddanie kwarantannie, odrzucenie, przekierowanie do innego serwera. Realizowane oprogramowanie ma działać jako aplikacyjne proxy i przechwytywać ruch pocztowy pomiędzy klientem a serwerem. Typowe zastosowania programu obejmują filtrowanie wiadomości po stronie serwera pocztowego lub po stronie klienta protokołu SMTP. Projekt ma charakter otwarty. 2

7 ROZDZIAŁ 1. WSTĘP Ponieważ istnieje wiele rozbudowanych narzędzi do filtracji korespondencji elektronicznej, implementowana aplikacja powinna posiadać pewne szczególne cechy, wyróżniające ją spośród innych produktów. Działanie istniejących aplikacji sprowadza się do analizy samej treści listów. Tworzone oprogramowanie ma zostać wzbogacone względem nich o rozpoznawanie błędnie skonstruowanych pól nagłówkowych (tzn. takich, które stoją w sprzeczności ze specyfikacją zawartą w odpowiednich dokumentach RFC). Rozpoznawane będą także nagłówki koperty wiadomości, czyli filtracja będzie się odbywać już na poziomie protokołu SMTP. Ponieważ analiza metadanych jest szybka, może znacznie ułatwić wykrycie niepożądanych wiadomości. Stosowane dziś produkty są często wyposażone w dużą ilość przydatnych, dodatkowych funkcji, czasem kosztem jakości wykonywania się ich podstawowych zadań. Znane luki w działaniu takich programów dotyczą ich: niezawodności, szybkości działania, skalowalności. Budowany system ma być wolny od wymienionych wad. Wśród wymagań, stawianych projektowi znajdują się: niezawodność, dobra wydajność i jakość od strony programistycznej. Dostępne oprogramowanie content security, w którego działanie autor miał wgląd, jest w większości stworzone z użyciem języków interpretowanych, takich jak Perl, lub przy pomocy zaawansowanych platform programistycznych, jakimi są.net albo Java. Stosunkowo mało jest aplikacji napisanych w językach kompilowanych wysokiego poziomu, np. w C++. Obecnie istniejące implementacje nie są rozwiązaniami przejrzystymi lub nie w pełni wykorzystują możliwości języka. Tworzone rozwiązanie przyczyni się do wypełnienia tej luki. Ze względu na obiektowy charakter, będzie mogło być łatwo rozbudowane o dodatkową funkcjonalność Zawartość merytoryczna i układ dokumentu Aby stworzyć spójną wizję systemu odrzucającego niechcianą pocztę, zbadano słabe punkty w działaniu protokołu SMTP. W rozdziale pierwszym zaprezentowano jego historię i działanie ze szczególnym zwróceniem uwagi na jego wady. Wymieniono i krótko opisano rozszerzenia protokołu, będące odpowiedzią na problemy, jakie rozwinęły się wraz z rozpowszechnieniem się komunikacji z użyciem poczty elektronicznej. Ważnym elementem rozdziału jest część poświęcona opisowi rozszerzenia MIME, definiujacego standard tworzenia wiadomości elektronicznych. Ponadto aplikacja będzie monitorowała rozmowę za pośrednictwem protokołu SMTP. Celem rozdziału drugiego jest przedstawienie powszechnie stosowanych metod filtrowania zawartości. Zwrócono uwagę na takie aspekty jak: skuteczność, szybkość działania, zużycie zasobów. W rozdziale dokonano krótkiego przeglądu dostępnych narzędzi, które umożliwiają badanie treści przesyłek, z uwzględnieniem ich słabych punktów oraz preferowanych metod walki ze spamem i wyciekiem informacji. 3

8 Rozdział trzeci przedstawia założenia, przyjęte w stosunku do tworzonego oprogramowania. Spełnienie wymagań jest podstawowym celem projektu, gdyż powoduje, że budowane oprogramowanie będzie się wyróżniało spośród innych aplikacji tego typu. Rozdział uzupełniono o opis przyjętych konwencji konstruowania aplikacji, które stworzone zostały z myślą o tworzeniu czytelnego i łatwego w utrzymaniu kodu. Szczegółowy opis stworzonego rozwiązania oraz implementacji najważniejszych jego elementów zawarto w rozdziale czwartym. Do zrozumienia działania systemu wystarczy zapoznanie się z częścią dotyczącą architektury aplikacji. Dobry pogląd na sposób korzystania z programu daje załączona do rozdziału dokumentacja użytkownika, w której przedstawiono m.in. sposób instalacji programu, tak, aby współpracował z przykładowym serwerem pocztowym oraz wymagania systemowe i sprzętowe. Ostatni rozdział stanowi podsumowanie pracy. Dokonano w nim oceny działania aplikacji, bazując na wynikach szeregu testów. Określono stopień spełnienia postawionych systemowi wymagań. Porównano jakość i funkcjonalność oprogramowania z innymi istniejącymi rozwiązaniami oraz przedstawiono możliwości jego rozwijania.

9 2. Protokół SMTP SMTP (ang. Simple Mail Transfer Protocol) to prosty tekstowy protokół komunikacyjny, odpowiedzialny za dystrybucję poczty elektronicznej. Chociaż protokół został stworzony w drugiej połowie lat 70 dwudziestego wieku, jest używany obecnie w niewiele zmienionej formie. Zachowane zostały założenia, jakimi kierowano się podczas budowania standardu SMTP. Są nimi: stworzenie nadrzędnego poziomu komunikacji, znajdującego się ponad warstwą protokołów transportowych modelu ISO/OSI, takich jak TCP/IP, który ułatwiałby i ujednolicał przesyłanie poczty elektronicznej, uproszczenie procesu implementacji aplikacji komunikujących się; to założenie wymusiło prostotę protokołu, założenie, że nadawca listu nie ma powodu oszukiwać odbiorców. Dwa ostatnie założenia sprawiły, że protokół SMTP jest słabo odporny na nadużycia. Bez rozszerzeń nie gwarantuje nawet funkcji uwierzytelniania się klientów przed serwerami pocztowymi. Dlatego stał się najbardziej podatnym na ataki elementem w procesie przetwarzania wiadomości przez systemy pocztowe. Niniejszy rozdział jest wprowadzeniem w historię i zasadę działania protokołu SMTP. Opisano w nim znane wady protokołu SMTP oraz próby ich usuwania za pomocą rozszerzeń protokołu. Szczegółowo zaprezentowano standard MIME, który stworzono z myślą o eliminacji ograniczeń, jakie niesie ze sobą protokół SMTP. Znajomość protokołu MIME jest konieczna do poprawnego zbudowania narzędzia analizującego ciało wiadomości Historia SMTP Pomysł przesyłania listów w formie elektronicznej (electronic mail, czyli ) narodził się zanim jeszcze powstały sieci komputerowe. Pierwsze systemy elektronicznej poczty były zaimplementowane na tradycyjnych komputerach typu mainframe. 1 Były to komputery wielozadaniowe z podziałem czasu. Stacje te obsługiwały wielu użytkowników poprzez połączone terminale. Całą obsługą poczty elektronicznej zajmowało się oprogramowanie zainstalowane na komputerze mainframe. Każdy użytkownik posiadał na nim skrzynkę pocztową, będącą katalogiem. Dostarczanie 1 Należy zaznaczyć, że tamte komputery miały niewiele wspólnego z obecnie używanymi superkomputerami o architekturze mainframe. Nazwa mainframe została od nich zapożyczona ze względu na ich duże rozmiary.

10 ROZDZIAŁ 2. PROTOKÓŁ SMTP poczty polegało na przenoszeniu wiadomości z jednego folderu do drugiego. Wiadomości można było odczytać korzystając z programu klienckiego. Poczta elektroniczna rozumiana w sensie, w jakim funkcjonuje obecnie, pojawiła się wraz z Internetem. Internet był efektem ubocznym prac nad stworzeniem i rozwojem sieci ARPAnet. ARPAnet to pierwsza sieć komputerowa, stworzona z inicjatywy Agencji Departamentu Obrony Stanów Zjednoczonych Ameryki Północnej (ARPA). ARPA (ang. Advanced Research Projects Agency), której nazwę uzupełniono później o literę D (DARPA, Defense Advanced Research Projects Agency) została powołana do istnienia w późnych latach 50-tych XX wieku w celu wspierania rozwoju nowych technologii. Agencja powstała w odpowiedzi na potrzebę szybkiego rozwoju technologicznego wojska amerykańskiego w czasie Zimnej Wojny. Bezpośrednią przyczyną jej utworzenia była udana próba wystrzelenia na orbitę pierwszego sztucznego satelity Ziemi Sputnik I w roku Amerykanie, zaniepokojeni sukcesami ZSRR, podjęli dynamiczne kroki w celu usprawnienia obrony oraz osiągnięcia przewagi technologicznej wojska. ARPA zrzeszała badaczy z różnych środowisk naukowych i akademickich. Powstała potrzeba niezawodnej wymiany informacji i zasobów. Tak powstał pomysł zbudowania sieci ARPAnet, która miała posłużyć do umożliwienia dostępu do usług i programów, istniejących na komputerach, oddalonych od siebie geograficznie. Pierwsze koncepcje sieci polegały na stworzeniu systemu, w którym użytkownik mógłby logować się do zdalnego komputera, na którym pracowały aplikacje lub znajdowały się zasoby, jakich potrzebował. Planiści ARPAnetu mieli nadzieję, że współdzielenie zasobów pozwoli uniknąć wykonywania tej samej pracy przez różnych naukowców oraz że przyczyni się do zetknięcia się nowych pomysłów, co zaowocuje szybszym postępem. Sieć miała więc posłużyć dystrybucji zasobów technicznych. Nie myślano o użyciu jej w celach komunikacji interpersonalnej [przypis]. Pierwsze wzmianki na temat połączenia komputerów w sieć, za pomocą szerokopasmowych linii dostępowych, zawarł w pracy Man-computer symbiosis z 1960 roku [zrodlo] Joseph Carl Robnett Licklider, ówczesny wiceprezes firmy BBN (Bolt, Beranek and Newman, obecnie BBN Technologies). J.C.R Licklider był inicjatorem realizacji pomysłu sieci maszyn, oferującej prosty interfejs komunikacyjny. Pierwszą koncepcję zdecentralizowanej sieci pakietowej przedstawił w 1962r Paul Baran z firmy RAND (Research and Development, obecnie Rand Corporation). Prace nad siecią ruszyły w 1967 roku. Odbyło się wtedy pierwsze Sympozjum Systemów Operacyjnych ACM (ang. ACM Symposium on Operating Systems SOSP) [zrodlo sosp.org], na którym ujawniono pomysły realizacji rozległej sieci komputerowej o rozproszonym zarządzaniu. Na konferencji dyskutowano nad możliwością skonstruowania infrastruktury telekomunikacyjnej, która nie wymagałaby scentralizowanych węzłów komunikacyjnych. Węzły takie mogłyby być łatwym celem potencjalnych ataków. Alex McKenize zaproponował rozwiązanie polegające na przesyłaniu danych wraz z adresem hosta 6

11 ROZDZIAŁ 2. PROTOKÓŁ SMTP docelowego, które podróżując po sieci, same szukałyby swojego odbiorcy. Tak powstała koncepcja sieci z komutacją pakietów, która miała się później rozwinąć w protokół TCP/IP. Plany zbudowania sieci zaczęły się krystalizować w II połowie lat 70-tych XX wieku. W roku 1968 wydano oficjalny dokument, opisujący schemat budowy sieci 2. Rok później podpisano z firmą BBN kontrakt na budowę fizycznej sieci. Pierwsze na świecie połączenie sieciowe zrealizowano 29 października 1969r pomiędzy Uniwersytetem Kalifornijskim w Los Angeles i ośrodkiem badawczym Stanford Research Institute na Uniwersytecie Stanford w Nowym Yorku. Pierwsza na świecie sieć była gotowa jeszcze w tym samym roku, w którym rozpoczęto jej realizację. Składała się z czterech routerów (których rolę pełniły minikomputery IMP, (ang. Interface Message Processors) ), umieszczonych w lokalizacjach: 1. UCLA (ang. University of California, Los Angeles), Uniwersytet Kalifornijski 2. UCSB (ang. University of California, Santa Barbara), Uniwersytet Kalifornijski 3. SRI (ang. Stanford Research Institute), Uniwersytet w Stanford 4. Uniwersytet w Utah. W latach sieć obejmowała coraz większy obszar. Aby umożliwić wymianę wyników badań poszczególnych ośrodków naukowych, grupa NWG (ang. Network Working Group) opracowała format dokumentu RFC (ang. Request For Comments) [zrodlo rfc 3]. W początkach lat siedemdziesiątych XX wieku do dystrybucji dokumentów używano list fizycznych adresów hostów. Ich opis można znaleźć w RFC 95, RFC 155. To m.in. potrzeba sprawnego przesyłania biuletynów RFC zmobilizowała twórców TCP/IP do wytężonej pracy nad systemem rozprowadzania poczty elektronicznej. Pierwszym dokumentem opisującym transport był prawdopodobnie RFC 196, wydany w 1971r. Opisano w nim protokół Mail Box. Był to bardzo prymitywny protokół, przeznaczony do przesyłania dokumentów do zdalnych drukarek. Uaktualniano go kilkakrotnie, aż w połowie lat 70 opracowano bardziej uniwersalną metodę implementacji poczty elektronicznej, opartą na protokole FTP. Pierwszy sieciowy wysłano w 1971 roku. Jego twórca Ray Tomlison (inżynier w firmie BBN) przesłał go między dwoma komputerami, połączonymi siecią ARPAnet. List nie posiadał istotnej treści, której nie pamięta nawet sam twórca. Prawdopodobnie zawierała znaki qwertyuiop albo Testing [zródło]. Druga wiadomość elektroniczna w sieci była nieco ciekawsza. Tomlison rozesłał ją do kolegów ze swojego zespołu programistycznego. Ogłosił w niej, że poczta elektroniczna zaczęła istnieć w sieci oraz przekazał instrukcje, w jaki sposób adresować listy do użytkowników z innych hostów. Do oddzielenia nazwy odbiorcy od docelowego adresu hosta użył (małpa). 2 ARPA Program Plan No. 723 Resource sharing computer network, Lawrence G.Roberts 7

12 ROZDZIAŁ 2. PROTOKÓŁ SMTP Tomlison nazwał swój program sieciowy SNDMSG (ang. Send Message). Powstał on na bazie dwóch starszych programów: wersji SNDMSG do lokalnej dystrybucji poczty i aplikacji CPYNET (ang. Copy Network) do kopiowania plików w sieci. Lokalny SNDMSG został stworzony jako oprogramowanie dla środowiska TENEX, które było popularnym systemem operacyjnym z podziałem czasu, rozwijanym przez firmę BBN na komputery PDP-10. SNDMSG służył do wysyłania listów do odbiorców, których skrzynki znajdowały się na lokalnej maszynie. Był prostym edytorem tekstu, który przetwarzał nazwy odbiorców i tekst wiadomości, a następnie dopisywał te informacje do specjalnego pliku, będącego docelową skrzynką odbiorczą. Tomlison połączył funkcjonalność aplikacji z możliwościami programu CPYNET. Pozwoliło to na stworzenie usługi, która przetwarzała pocztę wysyłaną do zdalnych hostów w taki sam sposób, jak do użytkowników lokalnych. Sieciowy SNDMSG kopiował wiadomości z hosta lokalnego na zdalny i dopisywał je do skrzynki pocztowej odbiorcy. Równolegle do SNDMSG rozwijał się program READMAIL (ang. Read Mail). Służył do odczytywania wiadomości. Jedyną usługą, jaką oferował było wyświetlanie kolejnych wiadomości. READMAIL nie wydzielał z listów żadnych metainformacji i, w związku z tym, nie potrafił ich w żaden sposób posegregować. Z inicjatywy Lawrence a Robertsa i Steve a Crockera z organizacji IPTO został zmodyfikowany do postaci programu RD (ang. Read). RD poszerzył funkcjonalność programu READMAIL o umiejętność budowania listy wiadomości. Listy te można było indeksować wg tematu lub daty. Użytkownicy mogli od tej chwili porządkować swoje skrzynki pocztowe. Dopisano także funkcje do zapisywania wiadomości w pamięci trwałej oraz usuwania ich ze skrzynek. Barry Wessler dodał do RD możliwość usuwania tylko wybranych wiadomości. Nazwał swój program NRD. Jakiś czas później Marty Yonke zintegrował funkcjonalność programów SNDMSG i NRD w uniwersalny interfejs do wysyłania i odbierania poczty elektronicznej o nazwie WRD, który rozwinął się w program BANANARD. Pomysł Yonke a został poszerzony przez Johna Vittal a z BBN w ramach programu MSG o przekazywanie poczty (forwarding) oraz o tworzenie poprawnie skonstruowanych wiadomości - odpowiedzi. Równocześnie rozwijany był bardziej złożony program do obsługi poczty HERMES. Programy MSG i jego poprzednicy były powszechnie używane w sieci ARPAnet przed rokiem Istnienie tak wielu systemów pocztowych spowodowało podjęcie próby stworzenia standardów, ujednolicających implementację przesyłania i dostarczania poczty w ramach sieci. Początkowo praca ta sprowadzała się do zaadaptowania już istniejących protokołów transportowych, w tym FTP (ang. File Transfer Protocol). Do FTP dodano komendy MAIL i MLFL, służące do transmisji korespondencji . FTP potrafił wysłać oddzielną kopię wiadomości do różnych odbiorców. Używany był mniej więcej do roku 1980, kiedy ukazał się RFC 772, wyjaśniający działanie protokołu MTP (ang. Mail Transfer Protocol). MTP oparto na regułach zapożyczonych z protokołu zdalnego dostępu Telnet oraz z FTP. MTP definiował zbiór komend i procedur za pomocą 8

13 ROZDZIAŁ 2. PROTOKÓŁ SMTP których dwie maszyny, połączone siecią, mogły komunikować się za pomocą protokołu TCP/IP w celu przekazania sobie poczty. Komendy MTP były praktycznie niezmienionymi komendami FTP. Sformułowanie protokołu MTP jako opakowania dla protokołu FTP spowodowało, że MTP był z założenia ograniczony do możliwości FTP, a przez to trudno go było modyfikować lub rozwijać przez dodawanie usług, specyficznych dla poczty elektronicznej. Potrzebny był protokół, który uniezależniłby schemat wysyłania i odbierania listów od implementacji tego procesu. Standard taki powstał w październiku roku SMTP, zdefiniowany po raz pierwszy w RFC 788 przez Jonathan a B. Postel a, był krokiem milowym w rozwoju poczty elektronicznej. Podstawowe pomysły realizacji dystrybucji przesyłek pocztowych nie zmieniły się od tego czasu do dziś. Postel zawarł w nowym standardzie szczegółowe informacje precyzujące w jaki sposób poczta może być transportowana pomiędzy hostami SMTP bez potrzeby używania FTP ani innych technik transferu plików. W RFC 788 opisano metody przesyłania wiadomości rozumianej jako połączenie tekstowej treści i ustrukturyzowanego zbioru nagłówków, zdefiniowane w dokumencie RFC 733. Nazwa (ang. Simple Mail Transfer Protocol) sugeruje, że nowy protokół SMTP był mniej skomplikowany niż jego poprzednik MTP. Z pewnością oferował rozwiązania bardziej jasne i przejrzyste. Został zaprojektowany specjalnie w celu umożliwienia transportu poczty elektronicznej. Mimo, że istnieją w nim pewne zbieżności z FTP, był i jest protokołem niezależnym od konkretnych implementacji protokołów do przesyłania danych. Również sam sposób przesyłania korespondencji w sieci za jego pomocą jest stosunkowo nieskomplikowany, przynajmniej w porównaniu do niektórych protokołów. Protokół SMTP był szeroko używany od lat 80-tych XX wieku. Jednym z pierwszych systemów pocztowych, służących do przechowywania i przekazywania poczty (system typu store-and-forward), wykorzystujących SMTP był sendmail. Sendmail autorstwa Erica Allmana z Uniwersytetu Kalifornijskiego, Berkeley, powstał jako oprogramowanie dedykowane dla systemu Unix BSD, rozwijanego w Berkeley. Program wbudowano w i rozprowadzano wraz z systemem operacyjnym BSD Unix. W ten sposób sendmail przyczynił się do rozpowszechnienia SMTP. Protokół SMTP oraz strukturę modelowej wiadomości kilkakrotnie modyfikowano. W 1982 roku David H. Crocker uaktualnił RFC 733 do nowej wersji standardu RFC 822. Po raz pierwszy opisano w nim strukturę nazw domenowych. W tym samym roku Jonathan B. Postel sprecyzował działanie protokołu SMTP w nowym dokumencie RFC 821. W roku 1980 ARPA zdecydowała się oddzielić część wojskową sieci od środowisk akademickich, które nazwały siebie Internetem. Sieć Internet rozrastała się bardzo szybko. Protokół SMTP szybko stał się najpopularniejszym standardem wymiany korespondencji elektronicznej. Przez szereg lat używano go w niezmienionej postaci. Sytuacja zmieniła się w 1993 roku, kiedy wydano RFC Był to standard, definiujący proces tworzenia nowych serwisów, rozszerzających funkcjonalność SMTP. Aktualny taki standard opisano w RFC Rozszerzenia nie mogą powodować konfliktów 9

14 ze starymi wersjami protokołu. Wymaga się od nich zgodności wstecz. SMTP z rozszerzeniami zyskuje nazwę ESMTP (ang. Extended SMTP). Stworzenie możliwości dodawania rozszerzeń do SMTP zaowocowało spisaniem szeregu nowych dokumentów RFC, definiujących komendy ESMTP. W roku 1996 powstał standard MIME (ang. Multipurpose Internet Mail Extensions), w którym zaprezentowano sposób na przesyłanie przy pomocy SMTP wiadomości zakodowanych inaczej niż w standardowym zestawie znaków ASCII, co umożliwiło przesyłanie za pomocą poczty elektronicznej plików, multimediów i innego rodzaju załączników. Nowy standard SMTP zdefiniowano w 2001 roku w RFC Był on rozwinięciem poprzednich standardów, które okazały się niewystarczająco szczegółowe lub zawierały niepraktyczne rozwiązania. Aktualny standard SMTP wydano w październiku zeszłego roku w RFC W stosunku do RFC 2821 dokonano w nim poprawek edytorskich oraz uszczegółowiono sekcje opisowe. Obowiązującym standardem budowy wiadomości , czyli IMF (ang. Internet Message Format) jest RFC 5322, będący aktualizacją poprzedniego standardu RFC Poprawiono w nim błędy gramatyki, opisującej budowę listu elektronicznego. SMTP jest obecnie najczęściej stosowanym protokołem wymiany poczty. Profesor D. J. Bernstein, autor qmaila, stworzył protokół QMTP (ang. Quick Mail Transfer Protocol), który miał zastąpić SMTP. W QMTP usunięto niektóre z ograniczeń lub innego rodzaju problemów SMTP. Choć QMTP nie rozpowszechnił się ze względu na brak zgodności ze swoim poprzednikiem, jest wykorzystywany w praktyce np. przez serwery pocztowe Wirtualnej Polski.

15 3. Projekt i implementacja filtru System jest zaimplementowany w języku C++ jako oprogramowanie dla środowisk linuksowych. Działa jako wielowątkowe proxy aplikacyjne. Przechwytuje ruch pomiędzy klientem SMTP a serwerem SMTP. Po odebraniu wiadomości, poddaje ją analizie i w zależności od jej wyniku, przesyła dalej lub wstrzymuje. Komunikacja z klientami i serwerami SMTP oraz przetwarzanie wiadomości zostały zrealizowane jako oddzielne wątki. Poprawność działania wątków kontroluje nadzorca (ang. Watch Dog). Wątki potrafią komunikować się z nim za pomocą komunikatów. Projekt składa się z kilku warstw, realizujących oddzielne funkcje systemu. Kod źródłowy poszczególnych części umieszczono w osobnych katalogach jak przedstawiono w tabeli 3.1.Wszystkie komponenty są zawarte we wspólnej przestrzeni nazw kc_sf, żeby ich nazwy nie kolidowały z innymi bibliotekami. Szczegółowa dokumentacja programistyczna w formacie HTML została umieszczona na płycie CD-ROM, dołączonej do pracy Architektura aplikacji System składa się z komunikujących się, ale niezależnych modułów: 1. moduł przechwytujący wiadomości ( Receiver ), 2. parser ( Parser ), 3. filtr zawartości ( Filter ), 4. klasyfikator wiadomości, inicjujący wykonanie akcji na wiadomości ( Action Taker ), 5. moduł wysyłający wiadomość do innego hosta ( Sender ), 6. moduł zapisujący wiadomość na dysku ( Serializer ), 7. Watch Dog ( WD ), 8. moduł do zapisywania zdarzeń związanych z przetwarzaniem wiadomości ( Logger ), 9. todo moduł do wysyłania wiadomości, przy których nie system nie mógł uzyskać połączenia z serwerem docelowym lub takie połączenie zostało zerwane ( Resender ). Moduły parsera, filtru i klasyfikatora realizują właściwą funkcjonalność systemu. Moduł Resender oznaczony napisem todo jest planowany do dodania do kolejnej wersji systemu.

16 Tablica 3.1. Struktura katalogów projektu Katalog config filter logs mime parser smtp system utils Opis Klasy do odczytu i interpretacji pliku konfiguracyjnego. Filtr zawartości listu oraz klasy określające reguły, na podstawie których ustala on akcję do wykonania na wiadomości. Obsługa dziennika zdarzeń. Struktura MIME wiadomości. Skaner i parser wiadomości oraz pomocnicze klasy do reprezentacji struktur wydzielanych przez skaner z tekstu. Wielowątkowy serwer oraz klient SMTP oraz pomocnicze klasy udostępniające niskopoziomowy, obiektowy interfejs do komunikacji TCP/IP przy pomocy gniazd BSD. Klasa wątku kontrolującego działanie całego systemu (Watch Dog). Klasy i funkcje ogólnego zastosowania, często używane w innych częściach systemu. Klasy kontenerowe: słownik obiektów, reprezentowanych przez nazwę, wektor. Interfejs uniwersalnych operacji do przekształcania napisów: zmiana wielkości liter, porównywanie napisów bez uwzględniania wielkości znaków, odnajdywanie wzorca w tekście, zmiana strony kodowej napisu. Na nadchodzące wiadomości czeka Receiver. Po odebraniu przesyłki, umieszcza ją w wejściowej kolejce wiadomości i powiadamia o tym zdarzeniu za pomocą specjalnej komendy WD. WD przenosi wiadomość do własnej wewnętrznej kolejki oraz próbuje zainicjować jej przetwarzanie. Jeżeli liczba wątków w systemie przekroczyłaby dozwoloną ilość, WD nie robi nic. Zostanie pobudzony do działania, gdy któryś z wątków przetwarzających zakończy działanie albo jeśli otrzyma powiadomienie o nadejściu nowej wiadomości. Jeśli w systemie nie działa zbyt dużo wątków, WD tworzy nowy wątek do analizy zawartości listu. Badanie zawartości wykonywane jest w następującej kolejności: 1. moduł parsera: sprawdza wiadomość pod kątem poprawności, ewentualnie dokonuje drobnych poprawek w jej strukturze wydziela z wiadomości istotne dla dalszej analizy informacje powiadamia WD o wyniku pracy za pomocą specjalnej komendy 2. moduł filtra: sprawdza czy reguły filtru określone w pliku konfiguracyjnym są spełnione przez wiadomość ustala typ akcji, jaką należy wykonać na wiadomości powiadamia WD o wyniku pracy za pomocą specjalnej komendy 3. moduł podejmowania akcji ActionTaker: w zależności od wyniku działania filtru, próbuje wykonać określoną przez niego akcję: a.) jeśli wiadomość ma zostać przesłana dalej, przekazuje ją do modułu wysyłającego (Sender) z powiadomieniem WD 12

17 Rysunek 3.1. Podstawowe moduły systemu b.) jeśli wiadomość została oznaczona jako przeznaczona do usunięcia lub kwarantanny, przekazuje ją do modułu do serializacji (Sender) i powiadamia o tym WD 4.a moduł wysyłający Sender: próbuje wysłać wiadomość do adresata przesyła do WD informację o wyniku próby 4.b moduł zapisujący wiadomość na dysku Serializer: tworzy w określonych w konfiguracji katalogach na dysku pliki, do których zapisuje tekst wiadomości jeśli wiadomość trafiła do kwarantanny, tworzy skojarzony z nią plik, zawierający wydzielone przez parser informacje o strukturze wiadomości WD po odebraniu komunikatu od modułów przetwarzających wiadomość, odnajduje wiadomość w kolejce i oznacza ją odpowiednią flagą. Wiadomość nie jest usuwana, aż WD otrzyma informację, że przetwarzanie zostało ukończone (wiadomość wysłano lub zapisano na dysku) albo gdy moduł wysyłający powiadomi go, że nie może dostarczyć wiadomości. Jeśli tak się stanie, wiadomość jest zapisywana na dysku w wyznaczonym katalogu wiadomości niedoręczonych. 13

18 Podczas pracy systemu, jeśli nie konfigurowano inaczej, zdarzenia zachodzące w systemie mogą być zapisywane w określonych plikach w pamięci trwałej. Zajmuje się tym Logger singleton, kontrolujący dostęp do pliku lub plików zdarzeń. Logger rozróżnia kilka poziomów ważności zdarzeń: NOTHING, FATAL, ERROR, INFO, DETAIL i ALL Obsługa protokołu SMTP Obsługa sesji SMTP Aplikacja działa jak proxy pośredniczące w komunikacji między lokalnym nadawcą poczty a siecią zewnętrzną lub między nadawcami z Internetu przesyłającymi wiadomości do lokalnych serwerów bądź użytkowników. Wobec klienta, który połączył się z nią, staje się serwerem SMTP. Wobec serwera, z którym nawiązała połączenie, przyjmuje rolę klienta. Jako serwer SMTP potrafi poprawnie rozpoznawać żądania SMTP i niektóre komendy ESMTP oraz odpowiadać na nie w prawidłowy sposób. W przypadku napotkania nieznanej komendy lub polecenia o budowie niezgodnej z RFC 5321[odnosnik], zwróci odpowiedni kod błędu. Do obsługiwanych komend należą: HELO, EHLO, MAIL FROM, RCPT TO, DATA, NOOP, RSET, QUIT. Serwer SMTP przyjmuje wszystkie wiadomości. Zgodnie z dokumentami RFC[odnosnik], gwarantuje w ten sposób klientowi, że jest w stanie je dostarczyć. Decyzja o odrzuceniu lub przesłaniu przesyłki do docelowego serwera zostaje podjęta dopiero po przeanalizowaniu całej wiadomości. Dlatego nawet jeśli serwer podejmie decyzję o usunięciu wiadomości, klient nie będzie o tym wiedział. Rysunek 3.2. System jako proxy aplikacyjne Gdy odebrana wiadomość zostanie zaklasyfikowana jako przeznaczona do przesłania dalej, system nawiązuje połączenie z prawdziwym serwerem SMTP. Udając przed nim klienta, przesyła 14

19 mu wiadomość. Klient SMTP zna i potrafi zinterpretować odpowiedź na komendy: EHLO, HELO, MAIL FROM, RCPT TO, DATA, QUIT. Funkcję serwera SMTP pełni moduł Receiver. Podstawowe informacje o każdej przechwyconej wiadomości (takie jak: informacje z pól envelope, data otrzymania wiadomości) są zapamiętywane w logach systemu w pamięci trwałej. Otrzymana wiadomość jest zapisywana w pamięci RAM w kolejce wiadomości. Jeśli wiadomość jest poprawna, co zostanie sprawdzone na etapie obsługi wiadomości, będzie odnajdywany jej adresat (serwer SMTP) i wiadomość będzie przesyłana dalej. Zajmie się tym moduł Sender, pełniący funkcję klienta SMTP Komunikacja sieciowa Na najniższym poziomie, aplikacja komunikuje się za pomocą protokołu TCP/IP. Wykorzystuje w tym celu interfejs gniazd BSD, opakowany w klasy ServSocket i ClientSocket. Protokół SMTP jest realizowany przez klasy wyższego poziomu: Receiver i Sender. Realizacją funkcjonalności serwera SMTP zajmuje się klasa Receiver. Receiver nasłuchuje na połączenia od klientów na określonym w pliku konfiguracyjnym porcie, domyślnie 25. Każde połączenie realizowane jest w oddzielnym wątku. Implementacja nasłuchu i obsługi połączeń z klientami jest ukryta przed użytkownikami klasy. Zajmuje się nią specjalna klasa do komunikacji TCP/IP - ServSocket. Klasa Receiver udostępnia metody: listen() i stop(). Klient SMTP jest reprezentowany przez klasę Sender. Sender potrafi odnaleźć docelowy serwer SMTP i przesłać do niego wiadomość . W celu przetwarzania pakietów TCP/IP Sender korzysta z klasy ClientSocket. Interfejs klasy Sender to funkcje: connecttoserv(), isconnected(), sendmail( const Message &msg ), disconnect(). Klasy komunikacyjne ServSocket i ClientSocket udostępniają metody do wysyłania i odbierania pojedynczych linii zakończonych znakami CR LF. Szablonowa klasa ServSocket dostarcza implementację serwera komunikującego się z klientem za pomocą pakietów TCP/IP. Parametrem szablonu może być klasa zawierająca metodę handleclient(), wykonującą właściwą obsługę zapytań i żądań klienta. ClientSocket to klasa do komunikacji klienta z serwerem określonym poprzez nazwę domeny FQDN i numer portu, na jakim czeka na połączenia Badanie zawartości wiadomości Reprezentacja wiadomości Ponieważ filtracja wiadomości powinna wykonywać się szybko, przechwycone wiadomości nie są zapisywane w pamięci trwałej. System przechowuje ich treść w pamięci RAM aż do 15

20 czasu zaklasyfikowania ich do określonej grupy (wiadomości do usunięcia, wiadomości objętych kwarantanną lub poprawnych wiadomości do przesłania dalej) i wykonania na nich odpowiedniej akcji. Istnieją dwa rodzaje klas reprezentujących wiadomość: MailData oraz Entity. Prosta klasa MailData przechowuje treść listu oraz jej nadawcę i listę odbiorców. Jej zawartość jest wypełniana przez moduł odbierający Receiver na podstawie przesłanych od klienta informacji. Treść to łańcuch znaków, adresy mają postać obiektów klasy SingleAddress. Receiver umieszcza tę strukturę w kolejce wejściowej wiadomości. Stamtąd pobierana jest przez wątek nadzorcę (WD). Od tego momentu obiekt MailData związany z obsługiwaną wiadomością nie będzie zmieniany aż do zakończenia obsługi wiadomości. Dzięki temu, jeśli na którymś etapie przetwarzania wystąpi błąd, dane wejściowe nie zginą i proces ten będzie można powtórzyć lub przerwać i zapisać odebraną wiadomość w niezmienionej formie na dysku twardym. W trakcie badania treści wiadomości parser gromadzi informacje o jej konstrukcji. Na ich podstawie tworzona jest drzewiasta hierarchia obiektów. Obiekty te ściśle odwzorowują struktury z dokumentu RFC 2822 [odnośnik]. Zostały skonstruowane w taki sposób, aby ułatwić ich przeszukiwanie wg różnych kryteriów. Nadrzędną encję wiadomości reprezentuje klasa Entity. Jest to abstrakcyjna klasa bazowa dla konkretnych klas Singlepart i Multipart. Singlepart to wiadomość w rozumieniu RFC822 [odnośnik]. Wiadomość taka posiada zestaw nagłówków (nie tylko tych zdefiniowanych w starej wersji standardu) oraz ciało w postaci tekstu. Klasa Multipart została stworzona z myślą o wiadomościach posiadających załączniki. Można za jej pomocą opisać listy o zawartości będącej złożonym typem danych (multipart albo message). Nagłówki dzielą się na kilka podstawowych typów. DateHeader udostępnia interfejs do obsługi dat i czasu. AddressHeader i jego specjalizacje: SingleAddress, MultipleAddress i ComplexAddress przechowują kolejno pojedyncze adresy o budowie localpart@domain, listy adresów i listy, złożone z obu poprzednich typów. UnstructuredHeader to niestrukturyzowany nagłówek o tekstowej zawartości. ParametersHeader to listy parametrów opatrzone nazwą, dobre do reprezentacji nagłówków MIME takich jak Content-Type. Tekst ciała oraz nagłówki mogą być zakodowane. W takim przypadku zostają przy tworzeniu odkodowane. Służą do tego klasy Base64Coder i QPCoder. Odkodowane elementy są przetwarzane do postaci łańcucha znaków w formacie 32-bit Unicode Transformation Format (UCS-4) [odnośnik]. Dzięki takiej reorezentacji danych, program daje możliwość poprawnego wyszukiwania słów kluczowych dowolnego języka. Ponieważ język C++ nie posiada wsparcia dla unikodu, dla osiągnięcia tego efektu zastosowano szerokie znaki wchar_t. Szerokość znaku wchar_t jest zależna od kompilatora, dla gcc w systemach Unix i Linux wynosi 32 bity, zaś w Windows - 16 bitów. Dlatego program nie jest przenośny na inne platformy. 16

21 Rysunek 3.3. Struktura klas reprezentującyh elementy wiadomości Łącznikiem między klasami MailData i Entity jest klasa Message, będąca prostym opakowaniem na uchwyty do obiektów tych klas Parsowanie wiadomości Moduł parsera jest kluczową częścią systemu. Do jego zadań należą: 1. sprawdzenie czy wiadomość została skonstruowana zgodnie ze standardami RFC [odnosnik do mime], 2. wydzielenie z wiadomości informacji, na podstawie których zostanie ona odpowiednio sklasyfikowana. Opis działania Parser działa dwuetapowo. W fazie pierwszej pełni rolę skanera sprawdza czy list został zbudowany poprawnie pod względem syntaktycznym. Analiza polega na wydzieleniu z tekstu wejściowego leksemów, czyli znaków lub całych wyrazów, które są najmniejszymi jednostkami mającymi znaczenie w strukturze listu. Białe znaki są pomijane. Rozpoznawane tokeny są ścisłym odzwierciedleniem słów z dokumentu RFC 2822 [odnosnik], np. boundary to sekwencja znaków (w zapisie EBNF): - - {bchars}{0,69}{bcharsnospace}, gdzie bcharsnospace to znaki z zakresu {a-za-z0-9 ()+_,-./:=?}, a do bchars należą bcharsnospace i znak spacji lub tabulacji. Do głównych zadań skanera należą: sprawdzenie czy plik wejściowy nie zawiera niedozwolonych znaków, 17

22 pogrupowanie znaków w tokeny, identyfikacja typów tokenów. W fazie drugiej parser bada czy tokeny zostały użyte we właściwym kontekście, tzn, czy występują w miejscach, w których ma to sens. Wejściem dla analizy semantycznej jest strumień tokenów. W jej wyniku powstaje drzewo obiektów odpowiadających podstawowym elementom, z jakich składa się . Zadania parsera na tym etapie są więc następujące: sprawdzenie czy dane są poprawne składniowo, rozpoznanie struktury danych. Parser operuje na zbiorze tzw. reguł produkcji. Reguły produkcji to zestaw warunków, które służą do sprawdzenia, czy token spełnia określoną gramatykę. Każda gramatyka zawiera symbol startowy ( np. program ) oraz zbiór zasad, które pozwalają przepisać ten symbol na inne symbole. Symbole dzielą się na nieterminalne i terminalne. Symbole terminalne to najmniejsze jednostki semantyczne, czyli tokeny. Symbole nieterminalne mogą być dalej przepisywane na kolejne symbole, aż nie zostaną zapisane w postaci elementów terminalnych. Tworzony parser korzysta z gramatyki bezkontekstowej, opisującej strukturę wiadomości . Gramatyka bezkontekstowa reprezentuje najpowszechniej używaną klasę języków (wg podziału Chomskiego [odnośnik]). Rozpoznawaniem gramatyk bezkontekstowych zajmują się automaty ze stosem. Gramatyki bezkontekstowe mają reguły postaci: A α A należy do zbioru symboli nieterminalnych. Jego znaczenie nie zależy od kontekstu, w jakim występuje. α może być dowolnym (także pustym) ciągiem symboli terminalnych i nieterminalnych. Gramatyka, którą się posłużono w programie, jest zmodyfikowaną wersją gramatyki opisanej w dokumentacji RFC ( 2822, 2045, 2026, 2027 [odnosniki] ). Zmiany polegają na użyciu uproszczenia, że znaki białe (spacje, znaki tabulacji, znaki nowej linii i powrotu karetki) oraz komentarze są rozpoznawane wraz z elementami je poprzedzającymi, nie tak jak w dokumentach RFC (w większości przypadków) z elementami, które same poprzedzają. Token, które je reprezentuje znajduje się na ostatnim miejscu po prawej stronie wyrażenia tworzącego regułę produkcji. Rozpoznanie go przez parser decyduje o tym, że reguła zostanie zastosowana. Zmodyfikowana gramatyka oraz schematy blokowe dla niektórych elementów hierarchii wiadomości zamieszczono w dodatku [odnosnik]. Implementacja Do budowy parsera użyto darmowych programów: flex na licencji GNU i bison na licencji GPL. Programy te generują szybkie parsery tekstu wejściowego według określonych przez programistę reguł. Oferują implementację w języku C lub C++. 18

23 Flex (ang. Fast Lex) realizuje funkcję skanera, przekształcającego wejściowy strumień znaków na tokeny. Standardowo tworzy lekser w języku C, ale potrafi także produkować kod C++. Identyfikuje leksemy na podstawie reguł, określonych przez programistę w pliku o specjalnej konstrukcji (w implementowanym systemie jest to plik Scanner.l). Dzieli się on na trzy części, rozdzielone znakami %%: definicje %% reguły %% opcjonalny dodatkowy kod Reguły mają postać: warunek akcja. Warunek jest opisywany wyrażeniem regularnym. Akcja to kod źródłowy, wykonywany, gdy tekst wejściowy zostanie dopasowany do warunku. Przykładowy kod źródłowy dla flexa ma postać z wydruku 3.1. %{ # i n c l u d e B i s o n P a r s e r. h / / rozpoznawane t o k e n y %} / o p c j e s k a n e r a / %o p t i o n c++ / / i n t e r f e j s C++ ( b e z p i e c z n y d l a watkow ) %o p t i o n case i n s e n s i t i v e / / w i e l k o s c znakow n i e wazna / s t a n y w j a k i c h moze s i e znajdowac s k a n e r / %s START %s HEADERS %s DATE %x BODY / makra standardowych c z e s c i tokenow / ALPHA ( [ a za Z ] ) DIGIT ([0 9]) WSP ( [ \ t ] ) CRLF ( \ r \ n \ r \ n ) ANY (. ) %% / p r z y k l a d o w e r e g u l y / / warunek / <INITIAL, HEADERS,BODY>^( Date Resent Date ) / ( { WSP} { CRLF } : ) { / a k c j a / / / p r z e j s c i e do i n n e g o s t a n u skanera, po z a k o n c z e n i u o b s l u g i / / t e j a k c j i y y _ p u s h _ s t a t e ( DATE ) ; } %% / / s t w o r z e n i e nowego tokenu, k t o r y z o s t a n i e p r z e k a z a n y / / p a r s e r o w i b i s o n return setnewtoken ( y y l v a l, YYText ( ), yy : : B i s o n P a r s e r : : t o k e n : : H_DATE, H_DATE ) ; 19

24 / m i e j s c e na dodatkowy kod / Wydruk 3.1. Kod źródłowy pliku wejściowego dla programu flex Program flex generuje na podstawie tak skonstruowanego pliku reguł klasę yyflexlexer. Obiekt klasy yyflexlexer służy do produkcji tokenów. Udostępnia parserowi metodę zwracającą zidentyfikowany leksem. Działanie flex a sprowadza się do wywoływania w pętli metody do szukania tokenów, aż cały tekst wejściowy nie zostanie rozpoznany. Dopasowanie fragmentu tekstu wejściowego do wyrażenia regularnego odbywa się według zasad: jeśli istnieje kilka możliwych dopasowań do wzorca, wybierany jest najdłuższy wzorzec, jeśli istnieje kilka wzorców pasujących do najdłuższego możliwego leksemu, wybierany jest pierwszy z nich nieznane znaki są pomijane. Każdy token zna swoją treść, typ i nazwę typu. Jest odczytywany i interpretowany przez obiekt klasy, tworzonej przez bison a. Bison to wersja programu Yacc (ang. Yet Another Compiler-Compiler). Służy do badania składni tekstu wejściowego. Realizuje parser gramatyki bezkontekstowej LALR(1). Parser taki czyta tekst od lewej do prawej z podglądem 1 tokenu w przód. Decyzja o tym, do jakiej reguły się dopasować, jest podejmowana nie tylko w oparciu o aktualnie rozpoznany token, ale także o kolejny. Analiza ma charakter wstępujący w pierwszej kolejności dopasowywane są najmniejsze jednostki strukturalne, składające się z leksemów. Następnie z nich budowane są bardziej złożone symbole, aż do spełnienia początkowej reguły, określającej symbol początkowy gramatyki. Bison oczekuje na wejściu sekwencji tokenów. Gdy uda mu się dopasować ciąg tokenów do odpowiedniej reguły produkcji, wykonuje kod dołączony do reguły oraz redukuje się do symbolu z jej lewej strony. Następnie szuka reguły, złożonej z nowo utworzonego symbolu. Jeśli nie znajdzie żadnej produkcji, do której mógłby dopasować nowy token, sygnalizuje błąd ( z wyszczególnieniem, na jakiej pozycji w tekście znalazł się błędny token). Działanie parsera nie jest przerywane. Przykładowy plik przedstawiono na wydruku 3.2. %{ / p l i k i naglowkowe / # i n c l u d e F l e x S c a n n e r. h # i n c l u d e Logger. h # i n c l u d e.. / mime / E n t i t y. h %} / o p c j e p a r s e r a / 20