Wydajny filtr SMTP PRACA DYPLOMOWA INŻYNIERSKA. Katarzyna Ciechańska

Wielkość: px
Rozpocząć pokaz od strony:

Download "Wydajny filtr SMTP PRACA DYPLOMOWA INŻYNIERSKA. Katarzyna Ciechańska"

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. Egzamin dyplomowy podpis studenta 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 Wstęp 6 1. Wprowadzenie do tematyki filtrowania zawartości Cel pracy Zawartość merytoryczna i układ dokumentu Protokół SMTP Historia SMTP Komunikacja SMTP Architektura SMTP Komunikacja między serwerem i klientem SMTP Routing wiadomości Rozszerzenia protokołu Struktura wiadomości Standard MIME Content security Potrzeba filtrowania wiadomości Metody filtrowania zawartości Przegląd dostępnego oprogramowania, realizującego funkcję content security Założenia projektowe tworzonego systemu Wymagania funkcjonalne Wymagania niefunkcjonalne Ograniczenia zakresu realizacji zadania 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 i

5 SPIS TREŚCI 4.6 Dokumentacja użytkownika Instalacja programu Konfiguracja programu Plik dziennika zdarzeń Pliki wiadomości oczekujących na wysłanie Pliki wiadomości znajdujących się w kwarantannie Testy 60 Środowisko testowe Automatyczne testy modułowe Pomiary wydajności Podsumowanie 61 A Zebrana gramatyka, opisująca strukturę wiadomości 62 B Spis tablic, rysunków i wydruków 67 Spis wydruków Spis rysunków Spis tablic ii

6 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 6

7 WSTĘP 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. 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. 7

8 WSTĘP 2. 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. 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ść. 8

9 WSTĘP 3. 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. Ważnym elementem rozdziału jest część poświęcona opisowi struktury wiadomości. W dalszej częsci rozdziału 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. Przedstawiono rozszerzenie MIME, definiujace standard tworzenia wiadomości elektronicznych zawierająch załączniki. 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. 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

10 Rozdział 1 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-tych 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, zapewnienie niezawodnej transmisji wiadomości, uproszczenie procesu implementacji aplikacji komunikujących się, 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. 10

11 ROZDZIAŁ 1. PROTOKÓŁ SMTP 1.1 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 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. Istniała między nimi 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]. 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. 11

12 ROZDZIAŁ 1. PROTOKÓŁ SMTP 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 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 2 ARPA Program Plan No. 723 Resource sharing computer network, Lawrence G.Roberts 12

13 ROZDZIAŁ 1. PROTOKÓŁ SMTP 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. Jaka była naprawdę 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). 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 na komputery PDP-10 dla środowiska TENEX, które było popularnym systemem operacyjnym z podziałem czasu, rozwijanym przez firmę BBN. 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ł 13

14 ROZDZIAŁ 1. PROTOKÓŁ SMTP 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 odpowiedzi na nadesłaną wiadomość. 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ą których dwie maszyny, połączone siecią, mogły się komunikować 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 14

15 ROZDZIAŁ 1. PROTOKÓŁ SMTP 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-andforward), 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 stawał 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 usług, rozszerzających funkcjonalność SMTP. Aktualny taki standard opisano w RFC Rozszerzenia nie mogły powodować konfliktów ze starymi wersjami protokołu. Wymaga się od nich zgodności wstecz. SMTP z rozszerzeniami zyskało 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, 15

16 ROZDZIAŁ 1. PROTOKÓŁ SMTP co umożliwiło przesyłanie za pomocą poczty elektronicznej obrazkó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 jako 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 Istnieje ekpserymentalne rozszerzenie IMF do wersji zinternacjonalizowanej. Definiuje je RFC SMTP jest najczęściej stosowanym obecnie 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. 1.2 Komunikacja SMTP Architektura SMTP Jedną z najistotniejszych koncepcji, jaka powstała w procesie tworzenia systemów do dystrybucji poczty elektronicznej, jest wydzielenie dwóch rodzajów usług pocztowych. Jedną z nich jest przesyłanie wiadomości do i pomiędzy serwerami pocztowymi, drugą odbieranie wiadomości przez użytkowników końcowych. Używając porównania do standardowej poczty, inne systemy odpowiadają za rozprowadzanie poczty pomiędzy urzędami pocztowymi (do tego właśnie celu służy SMTP), a inne zajmują się dostarczaniem przesyłek do mieszkańców określonych dzielnic (listonosze to np. pop3 lub imap). Taki podział ma na celu umożliwienie przesłania wiadomości do odbiorców nie podłączonych do Internetu w chwili, gdy był wysyłany. Dzięki temu nadawca (użytkownik lub serwer) może wysłać wiadomość w dowolnym momencie, a odbiorca (użytkownik) odczytać wiadomości z opóźnieniem w stosunku do ich nadania. Do przesłania poczty nie trzeba zestawiać łącza nadawca odbiorca. Achitektura oparta na protokole SMTP wyróżnia kilka rodzajów węzłów komunikacyjnych do wymiany wiadomości. Najważniejsze ich rodzaje to: MUA, MTA i MDA. 16

17 ROZDZIAŁ 1. PROTOKÓŁ SMTP Rysunek 1.1: Schemat architektury SMTP. Nadawca wysyła do odbiorcy 1. MUA (ang. Mail User Agent) współpracuje z użytkownikiem lokalnym. Realizuje: wysłanie wiadomości; przekazuje je do MTA, odebranie wiadomości; dostarcza je do skrzynki lokalnej użytkownika. Przykładowe aplikacje MUA to klienty pocztowe: pine, elm, Outlook, Mozilla Thunderbird i inne. 2. MTA (ang. Mail Transfer Agent) to router wiadomości, odpowiedzialny za logikę transferu i. Do jego funkcji należą: 17

18 ROZDZIAŁ 1. PROTOKÓŁ SMTP przyjęcie wiadomości przesłanej do niego przez MUA lub inny MTA, przesłanie wiadomości do MTA, który zna jej odbiorcę lub wie, jak go odnaleźć, przesłanie wiadomości do MDA, który prześle ją do odpowiedniego MUA na żądanie klienta, za pomocą właściwej metody transportu. MTA określa się inaczej jako serwery pocztowe. qmail, postfix, Novell, Microsoft Exchange. Przykładowe MTA to: sendmail, exim, 3. MDA (ang. Mail Delivery Agent) przechowuje wiadomości do czasu, dopóki nie skontaktuje się z nim klient, który chce je odebrać. Jego zadania to: przyjęcie wiadomości od MTA przechowanie wiadomości, dostarczenie wiadomości do klienta, na jego żądanie. Przykłady MDA: procmail, spamassasin. W założeniu twórców poczty elektronicznej list miał być transportowany przez sieć w niezmienionej postaci. Serwerom MTA nie wolno modyfikować otrzymanych przesyłek. Z MTA wydzielono dodatkową, pośrednią warstwę komunikacji, która przejęła obowiązek odbierania wiadomości od użytkownika lokalnego MUA i dostarczania jej do serwera pocztowego MTA. Warstwa ta to MSA. Agent MSA umożliwia poprawienie wiadomości przed jej wprowadzeniem do sieci. Poprawki dotyczą np. uzupełnienia wiadomości o brakujący wymagany nagłówek Date. MSA może także zgłosić błąd dotyczący niepoprawnej konstrukcji a. Agent MTA, który musi zapewnić niezawodną transmisję, nie mógłby odrzucić wiadomości tylko na podstawie jej błędnej konstrukcji. Wsród wyżej wymienionych warstw protokół SMTP jest wykorzystywany do: przyjęcia poczty od użytkownika (MUA) i przesłania jej do innego serwera (MTA), przyjęcia poczty od jednego serwera (MTA) i przesłania jej do drugiego serwera (MTA). Za pomocą SMTP nie można pobierać wiadomości ze zdalnego serwera. 18

19 ROZDZIAŁ 1. PROTOKÓŁ SMTP Komunikacja między serwerem i klientem SMTP Protokół SMTP jest niezależny od protokołów warstwy sieciowej i transportowej. Do jego implementacji najczęściej stosowany jest protokół TCP/IP. Standardowym portem, na jakim odbywa się komunikacja, jest port 25. Protokół SMTP działa w oparciu o model architektury klient - serwer. Aby przesłać wiadomość, nadawca klient SMTP musi połączyć się z odbiorcą serwerem SMTP. Serwer SMTP powinien nieustannie nasłuchiwać na połączenia od klientów. Wymagane jest, aby potrafił obsługiwać wielu klientów naraz. Klient SMTP to jeden lub więcej procesów, które okresowo próbują przesłać na serwer wiadomości. Jeśli wiadomość nie może zostać wysłana natychmiast, powinna trafić, wraz z informacjami o nadawcy i odbiorcy, do kolejki wiadomości oczekujących na wysłanie. Kolejki takie powinny być cyklicznie przeglądane. Próby wysłania wiadomości oczekującej muszą być podejmowane, dopóki list nie zostanie dostarczony do serwera lub klient nie zrezygnuje. Ten drugi scenariusz następuje standardowo po 4 5 dniach. Klient powinien przechowywać listę hostów, z którymi nie może się połączyć oraz pamiętać przyczyny, dla jakich wysłanie przesyłki zakończyło się porażką. Klient może ustanawiać kilka równolegle działających sesji z serwerami. Jednak jeśli wysyła pojedynczą wiadomość do wielu adresatów, powinien ją kierować do pojedynczego serwera. Klient komunikuje się z serwerem za pośrednictwem ustalonych komend. Serwer przesyła mu w odpowiedzi napis złożony z trzycyfrowego kodu, opcjonalnego napisu wyjaśniającego kod oraz ewentualnych parametrów. Kod przesyłany wraz z odpowiedzią służy do powiadomienia oprogramowania klienckiego o reakcji serwera na żądanie klienta. Pierwsza cyfra informuje, czy odpowiedź jest pozytywna, negatywna lub czy serwer nie oczekuje na doprecyzowanie komendy. Druga cyfra to specyfikacja błędu. Trzecia przekazuje najbardziej szczegółowe informacje o rodzaju i znaczeniu błędu. Żądania i odpowiedzi mają ustaloną kolejność. Serwer musi odpowiedzieć na każde żądanie. Klient nie powinien wysyłać kolejnych komend, jeśli nie otrzymał informacji od serwera (wyjątkiem jest sytuacja, gdy serwer potrafi obsłużyć rozszerzenie protokołu: pipelining). Stroną inicjującą połączenie SMTP jest klient. Serwer w odpowiedzi przesyła klientowi wiadomość powitalną. Następnie klient żąda zainicjowania sesji poprzez wysłanie komendy EHLO (ang. Extended Helo), po której podaje pełną nazwę domeny klienta (FQDN). Każdy serwer powinien umieć obsłużyć polecenie EHLO. Starsze serwery mogą jednak nie rozumieć tej komendy. W takim przypadku klient powinien przywitać się za pomocą komendy HELO (ang. Hello). Po otrzymaniu 19

20 ROZDZIAŁ 1. PROTOKÓŁ SMTP zgody ( 250 OK ), klient może rozpocząć przesyłanie wiadomości. W pierwszej kolejności wysyła polecenie MAIL FROM:<adres>. Adres identyfikuje nadawcę wiadomości. Jeśli serwer nie jest gotowy, wysyła odpowiedź specyfikującą dlaczego działanie nie może zostać zrealizowane. Jeśli serwer działa poprawnie, odpowie 250 OK. Jest to znak dla klienta, że może powiadomić serwer o tym, kim są odbiorcy wiadomości. Korzysta w tym celu z żądania RCPT TO:<adres>. Jeśli wiadomość ma być rozesłana do wielu odbiorców, dla każdego z nich wysyłane jest oddzielne polecenie RCPT TO. Serwer musi potwierdzić gotowość do dalszej transmisji pozytywnym komunikatem. Jeśli przesłano z sukcesem dane wszystkich odbiorców wiadomości, klient wysyła komendę DATA. To znak dla serwera, że za chwilę otrzyma ciąg linii, reprezentujących treść wiadomości. Wiadomość składa się z 7-bitowych znaków ASCII. Jeśli zawiera załączniki, muszą zostać przekonwertowane do takiej postaci. Jeżeli klient otrzymał od serwera odpowiedź gotowości do przyjęcia listu (kod 354), rozpoczyna transmisję danych a. Dane muszą być zakończone znacznikiem end of line, tzn. sekwencją znaków <CR><LF><.><CR><LF>. Po zakończeniu procesu przesyłania treści listu, klient może zainicjować transmisję następnej wiadomości, zakończyć sesję lub zadawać serwerowi pytania. Komenda QUIT, potwierdzona odpowiedzią 221 Closing zamyka sesję. Implementacja SMTP musi obsługiwać co najmniej komendy: EHLO, MAIL, RCPT, DATA, RSET, VRFY, EXPN, HELP, NOOP, QUIT. Opis komend zamieszczono w tabeli Routing wiadomości Serwery pocztowe MTA mogą być serwerami docelowymi na drodze wiadomości lub przekazywać listy dalej innym serwerom. Dzielą się na kilka grup, w zależności od roli, jaką odgrywają w transporcie wiadomości. Przekaźniki pocztowe (ang. relay servers) odbierają wiadomości od klienta SMTP i przekazują je w niezmodyfikowanej postaci do innego serwera SMTP. Bramki SMTP (ang. gateway servers) odbierają wiadomości, dostarczane innym systemem transportu poczty niż ten którym prześlą je dalej, przy czym któryś z tych systemów to SMTP. Gdy serwer SMTP odbierze wiadomość od klienta, bierze odpowiedzialność za dostarczenie listu do odbiorcy. Serwer SMTP może być serwerem docelowym, który zna takiego użytkownika, lub serwerem pośrednim. Wiadomość może przejść przez wiele serwerów w drodze do docelowego MTA. Z reguły ich liczba nie przekracza jednak dwóch. Zapobieganie powstawaniu pętli na drodze wiadomości jest zrealizowane poprez routing wiadomości. Routing, czyli zasady przesyłania wiadomości, definiuje, co stanie się dalej z odebraną przez MTA przesyłką. 20

21 ROZDZIAŁ 1. PROTOKÓŁ SMTP Polecenie EHLO MAIL FROM:<adres> RCPT TO:<adres> DATA VRFY user EXPN list-name HELP NOOP QUIT Tablica 1.1: Polecenia SMTP Opis Za pomocą tego polecenia klient przedstawia się serwerowi informuje go, że potrafi obsługiwać rozszerzenia ESMTP. Prosi serwer o listę rozszerzeń, które są na nim dostępne. Rozpoczyna się nowa transakcja. Serwer powienien wyczyścić swoje wewnętrzne bufory. Klient powiadamia serwer kto jest nadawcą wiadomości. Klient identyfikuje odbiorcę wiadomości. Za chwilę rozpocznie się transmisja ciała wiadomości. Żądanie weryfikacji użytkownika. Obsługa tego polecenia powinna być zablokowana ze względu na ochronę prywatności danych. Żądanie rozwinięcia listy adresów owych. Obsługa tego polecenia powinna być zablokowana ze względu na ochronę prywatności danych. Prośba o wysłanie informacji pomocy. Podtrzymanie połączenia. Serwer powinien odpowiedzieć na tę komendę pozytywnie. Klient kończy połączenie. Zasadniczą rolę w routingu odgrywa system rozwiązywania nazw domen DNS (ang. Domain Name System) [odnosnik]. Istnieją dwa rekordy DNS, używane do rozpoznawania serwerów pocztowych: MX i A. Rekord MX RR (ang. Mail exchanger Resource Record) definiuje, kim jest odbierający MTA. Rekord A RR (ang. Address Resource Record) służy do mapowania w pełni kwalifikowanej nazwy domeny (FQDN, ang. Fully Qualified Domain Name) na adres IPv4. Aby powiązać domenę poczty z nazwą domeny serwera pocztowego, należy ustawić nazwę wskazywaną przez rekord MX domeny poczty na nazwę domeny serwera. Przy próbie odnalezienia adresu serwera, rekord MX wskaże nazwę serwera, która będzie potem mapowana na jego adres. Aby dało się to zrealizować, serwer SMTP musi mieć ustawiony rekord adresu na swój adres IP. Możliwa jest sytuacja, w której domena poczty nie ma ustawionego rekordu MX, a zamiast niego ustawiono rekord A. Wtedy za niejawny, domyślny serwer poczty ( implicit MX ) uznawany jest adres wskazywany przez jej rekord A. Dokumenty RFC 2821 i 5321 uznają ten adres (lub adresy jeśli odczytano listę) za adres IP serwera obsługującego domenę. Z perspektywy klienta SMTP, routing wygląda następująco. Po odczytaniu nazwy domeny odbiorcy listu, MTA, który realizuje teraz funkcję klienta SMTP, wysyła do DNS żądanie przemapowania nazwy domeny na adres fizyczny serwera pocztowego. Nazwa domeny musi być w pełni kwalifikowana. DNS próbuje znaleźć rekord MX powiązany z nazwą. Jeśli odnalazł rekord 21

22 ROZDZIAŁ 1. PROTOKÓŁ SMTP CNAME (ang. Canonical Name), przeszukuje DNS od nowa, tym razem biorąc jako parametr nazwę, będącą wartością rekordu CNAME. Jeśli okaże się, że MTA, który zadał pytanie, jest serwerem obsługującym odbiorcę wiadomości, wiadomość jest dostarczana do jego skrzynki pocztowej. Jeśli MTA nie jest serwerem docelowym, próbuje przesłać wiadomość dalej, do adresu, zwróconego przez DNS. Jeśli DNS zwrócił listę adresów, próbuje wysłać wiadomość do każdego adresu z listy. Adresy te są uporządkowane według priorytetów. Procedura routowania wiadomości jest w rzeczywistości bardziej złożona, ale opiera się na podobnym schemacie. Nie są dozwolone inne formy routingu. RFC 5321 uznaje wcześniej dozwolony trace-routing za przestarzały. 1.3 Rozszerzenia protokołu SMTP został stworzony, aby zapewnić wydajny i niezawodny transport wiadomości. Umożliwia przesyłanie wiadomości przy pomocy prostego interfejsu. Ma jednak zasadniczą wadę. Po wysłaniu listu, nadawca nie otrzymuje żadnej informacji na temat dostarczenia przesyłki. Standard 5321 przewiduje powiadomienie nadawcy o porażce, jeśli wystąpił błąd transmisji i wiadomość nie mogła być dostarczona. Do adresu, spod którego wysłano , jest w takim przypadku dostarczany specjalny list. Jednak standard nie definiuje żadnej konkretnej formy takich wiadomości i z reguły nie niosą one dość informacji, aby nadawca mógł poprawnie ustalić co spowodowało błąd. Standaryzacja powiadomień o błędach pojawiła się dopiero jako rozszerzenie protokołu. Od czasu powstania protokołu SMTP powstało wiele jego rozszerzeń, składających się na ESMTP (ang. Extended SMTP), czyli rozbudowany SMTP. Większość służyła ułatwieniu procesu przesyłania poczty elektronicznej. Część była odpowiedzią na braki protokołu. SMTP jest protokołem prawie trzydziestoletnim. Jego twórcy nie przewidzieli problemu spamu. Dlatego SMTP nie oferuje żadnych metod uwierzytelniania nadawcy listu. W efekcie łatwo znaleźć w Internecie serwery MTA przekazujące pocztę nadesłaną przez dowolnego klienta. Są to tzw. serwery open relay, które nie zabezpieczają się w żaden sposób przed nieautoryzowanym dostępem. Stają się łatwym celem dla spamerów. Wprawdzie problem open relay wynika z błędów konfiguracji MTA, które zwykle popełniają niedoświadczeni administratorzy, a które stosunkowo łatwo wyeliminować, nawet kilka dni pracy serwera w takim trybie może przynieść wiele szkód. W dodatku korespondencję elektroniczną łatwo sfałszować. Najprostszym sposobem na wysłanie 22

23 ROZDZIAŁ 1. PROTOKÓŁ SMTP Tablica 1.2: Polecenia ESMTP Polecenie Opis AUTH (ang. Authenticated SMTP) Mechanizmy uwierzytelnienia klienta SMTP. Klient uwierzytelnia się za pomocą loginu i hasła, zakodowanych za pomocą kodowania base64. DSN (ang. Delivery Status Notification) Powiadamianie o statusie doręczenia wiadomości. ETRN (ang. Extended Turn) Żądanie natychmiastowego przekazania przechowywanych listów do podłączającego się serwera. PIPELINING (ang. Command Pipelining) Wysyłanie i obsługę kilku żądań na raz. CHUNKING i komenda BDAT Przesyłanie ciała wiadomości partiami. STARTTLS (ang. Start Transport Bezpieczne przesyłanie danych przy pomocy Layer Security) metody TLS ang. Transport Layer Security). SIZE Określenie całkowitej wielkości wiadomości. 8BITMIME Wsparcie dla kodowania wiadomości na ośmiobitowych znakach. RESTART Wznowienie przesyłania wiadomości po zerwaniu sesji. niechcianej poczty jest przekazanie jej przez serwer open relay z podaniem nieprawidłowych adresów zwrotnych. Do wad SMTP należy także zaliczyć brak zabezpieczeń w czasie transmisji danych. Rozszerzenia ESMTP usuwają niektóre z tych braków. Najbardziej popularne krótko opisano w tabeli Struktura wiadomości Standardowy format przesyłki jest zdefiniowany w standardzie RFC 2822, uzupełnionym i zaktualizowanym przez RFC Wiadomości, przesyłane protokołem SMTP, składają się tak jak tradycyjne listy, z koperty i zawartości. Na kopertę składają się adres nadawcy i lista adresów odbiorców. Adres nadawcy jest przesyłany nie tylko po to, aby odbiorca znał autora listu. Pod ten adres serwery pośredniczące w transmisji przesyłki przesyłają informacje o błędach. Z informacji zawartych w kopercie wiadomości, korzystają wszystkie węzły architektury SMTP. Zawartość wiadomości jest zbudowana ze zbioru nagłówków i treści, oddzielonej od nich białą linią. Treść jest opcjonalna. Pola nagłówka są przeznaczone do interpretacji dla MUA. Wiadomość składa się z linii. Linia to ciąg znaków, zakończony sekwencją CR LF, czyli znakiem powrotu karetki (kod ASCII: 13) i znakiem nowej linii (kod ASCII: 10). Długość linii nie 23

24 ROZDZIAŁ 1. PROTOKÓŁ SMTP powinna przekraczać liczby 80 znaków, wliczając w to znaki CR LF. Linia nie może składać się z więcej niż 1000 znaków. Nagłówki dzielą się na ustrukturyzowane i nie. Oba rodzaje są zbudowane wg tego samego schematu: Po nazwie nagłówka występuje znak dwukropka, a bezpośrednio po nim tekst nagłówka. Ustrukturyzowane nagłówki należą do kilka podstawowych grup. Nagłówki typu adres są reprezentowane np. przez From, To, Cc. Adresy w nich zawarte są zbudowane z części lokalnej, identyfikującej skrzynkę pocztową użytkownika adresu, i domeny, w której użytkownik posiada skrzynkę. Części są rozdzielone (małpa). W dalszej części dokumentu adresy tego typu będą określane jako adresy pojedyncze. Nagłówki mogą przechowywać listy adresów pojedynczych. Do tej grupy pól można wliczyć także nagłówki do reprezentacji identyfikatora wiadomości lub list takich identyfikatorów. Identyfikator jest bowiem definiowany tak samo jak pojedynczy adres, przy czym w miejsce części lokalnej wstawiany jest unikalny tekst, wyróżniający list, zaś domeną jest domena, w jakiej znajduje się maszyna, która wygenerowała identyfikator. Jeśli nie zrobi tego MUA, zostaje opatrzony identyfikatorem przez pierwsze MTA, do jakiego zostanie skierowany. Identyfikatorem wiadomości najczęściej staje się data i czas przesłania jej przez MTA dalej. Reprezentantem nagłówków typu data jest Date. Data określona w polu Date nie musi pokrywać się z faktyczną datą napisania wiadomości. Jeśli program pocztowy kolejkuje wiadomości, będzie się ona różnić od daty wysłania listu. Nagłówki, specyfikujące trasę, jaką odbyła wiadomość, np. Received, mają własną specjalną konstrukcję. Zostanie opisana w dalszej części rozdziału. Ostatnią grupą nagłówków o określonej strukturze są nagłówki MIME, złożone z list parametrów, np. Content-Type. Parametr to nazwa i wartość. Nagłówki nie ustrukturyzowane są zbudowane z sekwencji znaków. Mają znaczenie informacyjne. Przykładem nagłówka bez struktury jest Subject. Można definiować własne nagłówki, których nazwa zaczyna się od sekwencji X-. Takie nagłówki będą traktowane przez systemy pocztowe jako nie ustrukturyzowane. Jedynymi nagłówkami, które muszą wystąpić w poprawnie zbudowanej wiadomości, są Date i From. W dodatku [odnosnik] zamieszczono obowiązującą gramatykę, opisującą strukturę wiadomości i jej nagłówków. Szczególnie istotne dla diagnozowania problemów w transporcie listów elektronicznych, są nagłówki trasy. Każdy MTA, przez który przejdzie w swojej drodze do odbiorcy wiadomość, dodaje na jej początku pojedynczy nagłówek Received. Pierwszy MTA, który otrzymał wiadomość, jest wymieniony w ostatnim nagłówku Received. Pole to określa kiedy odebrano wiadomość, 24

25 ROZDZIAŁ 1. PROTOKÓŁ SMTP kto ją odebrał (wymagana jest nazwa i IP hosta), od kogo została odebrana (jak poprzednio). Na podstawie tych informacji można określić, na którym etapie transportu, wystąpił błąd. Ostatni MTA, który odpowiada za dostarczenie przesyłki do odbiorcy, lub pełni rolę bramki do innego systemu transportu elektronicznego, dodatkowo dodaje do wiadomości nagłówek Return-Path. Zamieszcza w nim informacje, które otrzymał od klienta w poleceniu MAIL FROM, specyfikujące nadawcę wiadomości. Pole Return-Path określa do kogo ma zostać wysłana wiadomość z informacją o błędzie w razie napotkania problemu z dostarczeniem poczty. Utworzenie takiego listu zwrotnego określa się jako odbicie wiadomości do nadawcy. MTA, który odbił wiadomość, ustawia jej Return- Path na pustą wartość. Zapobiega w ten sposób tworzeniu się pętli wiadomości odbitych od już odbitych wiadomości. Dzięki informacjom o trasie można wykryć prymitywne próby sfałszowania listu. Mają one miejsce, gdy klient serwera wysyłającego wiadomość przedstawia się serwerowi odbierającemu nazwą, której DNS nie potrafi powiązać z jego adresem IP. Pierwotnie tekst nagłówków i treści mógł składać się wyłącznie ze znaków US ASCII zakodowanych na 7 bitach. Wraz z pojawieniem się rozszerzenia MIME (ang. Multipurpose Internet Mail Extensions), został wzbogacony o możliwość przesyłania danych binarnych oraz znaków diaktrycznych Standard MIME Standard MIME wprowadzono w 1996 roku. Jest on rozszerzeniem specyfikacji konstrukcji wiadomości z RFC Standard składa się z zestawu dokumentów RFC , uzupełnionego później o RFC 2112, 2183 i inne. Rozszerzenie MIME wprowadziło: możliwość przesyłania w korespondencji znaków kodowanych na więcej niż 7 bitach, w tym danych binarnych i znaków narodowych, definicję nowych pól nagłówkowych, zaczynających się ciągiem znaków Content- oraz nagłówek MIME-Version, określający, że wiadomość spełnia wymagania standardu, możliwość dodawania do listu załączników, w tym zagnieżdżonych wiadomości. MIME zniosło ograniczenia listu związane z używaniem w treści wyłącznie 7-bitowego kodowania ASCII. Zapis danych na 7 bitach był wystarczający w początkach istnienia poczty elektronicznej, 25

26 ROZDZIAŁ 1. PROTOKÓŁ SMTP Tablica 1.3: Typy encji MIME Kategoria typu Typ danych Podtyp danych Podstawowy text plain, html, enriched Podstawowy image jpeg, gif Podstawowy audio basic Podstawowy video mpeg Podstawowy application octet-stream, post-script Złożony multipart mixed, alternative, parallel, digest Złożony message rfc822, partial, external-body kiedy posługiwali się nią wyłącznie Amerykanie. Alfabet angielski oraz znaki kontrolne dało się bowiem zapisać w zakresie 128 znaków. Z chwilą, gdy Internet, razem z pocztą elektroniczną, objął inne państwa, pojawiła się potrzeba poprawnego przesyłania znaków diaktrycznych. Do ich zapisu używano większej ilości bitów 3, dlatego potrzebne było zdefiniowanie metod konwersji do 7-bitowego ASCII. MIME dostarczyło dwóch takich technik: quoted printable i base64. Quoted printable służy do kodowania wiadomości składających się przede wszystkim z tekstu ASCII. Pozostałe znaki są zapisywane jako sekwencje =xx, gdzie x to znaki w reprezentacji oktalnej. Base64 dokonuje przekodowania całego tekstu wejściowego. Konwertuje każde trzy kolejne znaki, złożone w sumie z 24 bitów po 8 bitów na znak, na cztery 6-cio bitowe liczby. Powstałe w ten sposób liczy są mapowane na znaki drukowalne z zakresu A-Za-z0-9+/. Oprócz wymienionych MIME definiuje trzy dodatkowe sposoby kodowania wiadomości: 7bit na oznaczenie standardowego kodowania US ASCII, 8bit dla danych zapisanych w bajtach i binary dla danych binarnych. Kolejną nowością, jaką zaproponowano w standardzie MIME było określenie typu zawartości listu. Wiadomość mogła odtąd zawierać w sobie złożone struktury, w tym inną wiadomość. W ten sposób został zdefiniowany jako hierarchia elementów. Podstawową jednostkę tej hierarchii nazwano encją. Encja to wiadomość w sensie RFC 822, złożona z nagłówków i ciała. Typ takich encji określono jako prosty. Encjami są również struktury, zawierające w sobie inne encje, czyli encje złożonego typu. Dzięki zastosowaniu typów do wiadomości można było dodać załączniki, w postaci plików przesyłanych razem z listem. W tabeli 1.3 przedstawiono podstawowe typy MIME. Każda encja posiada własny (być może domyślny) typ zawartości, opisywany przez specjalny nagłówek Content-Type. Pole Content-Type, oprócz informacji o zawartości encji, zawiera parametr specyfikujący napis, który będzie wydzielał z tekstu wiadomości części składowe encji. Napis ten nazwano boundary. Ciało encji zaczyna się tuż po pierwszym wystąpieniu w tekście sekwencji znaków z boundary, poprzedzonej dwoma znakami myślnika: -- boundary, a kończy sekwencją 3 Najdłuższymi znakami świata są litery alfabetu chińskiego. Do reprezentacji niektórych potrzeba aż 21 bitów. 26

27 ROZDZIAŁ 1. PROTOKÓŁ SMTP znaków -- boundary --. Jeśli encja składa się z kilku sekcji, rozdzielone są one liniami - - boundary. Standard MIME definiuje również inne typy nagłówków, m.in Content-Transfer-Encoding dla oznaczenia użytego kodowania. Wraz z późniejszymi rozszerzeniami takimi jak dodanie nagłówka Content-Disposition, pozwala na budowanie i poprawne rozpoznawanie przez systemy pocztowe bardzo skomplikowanych struktur wiadomości. Standard MIME nie określa żadnych metod zabezpieczenia przed fałszowaniem informacji zawartych w liście. Dla przykładu możliwa jest sytuacja, gdy typ encji jest sprzeczny z jej zawartością. Jeśli Content-Type określa typ załączonego do wiadomości niebezpiecznego pliku jako nieznany, użytkownik może przez przypadek zainstalować wirus. Dlatego stworzono nowy standard S/MIME (ang. Secure Multipurpose Internet Mail Extensions), który definiuje w jaki sposób zabezpieczać korespondencję przy użyciu metod kryptograficznych. Proponuje szyfrowanie wiadomości algorytmem RSA z użyciem klucza publicznego. W praktyce szyfrowanie poczty jest wykorzystywane tylko przez duże firmy. Trwają prace nad umożliwieniem pełnej internacjonalizacji treści przesyłek pocztowych. We wrześniu 2008 roku wydano RFC 5335, będący rozszerzeniem standardu RFC Rozszerzenie nosi nazwę UTF8SMTP. Dokument ma status eksperymentalny. Zezwala ono klientom serwerów, obsługujących UTF8SMTP, na przesyłanie tekstu nagłówków zakodowanego kodowaniem Unicode (ang. Universal Character Set), zamiast standardowego US ASCII. Wykorzystywany jest format UTF-8 (ang. 8-bit Unicode Transformation Format). 27

28 Rozdział 2 Content security 2.1 Potrzeba filtrowania wiadomości Nieścisłości lub luki w standardach SMTP i MIME są znane od kilku lat. Mimo powstawania nowych metod walki z nimi, problemem pozostaje zmieniający się sposób ich wykorzystywania przez hakerów i spamerów. Np. aktualnymi trendami w rozpowszechnianiu spamu są: ataki ukierunkowane na konkretną grupę odbiorców, informacje o których zbierane są przez analizę ich ruchu pocztowego, spam obrazkowy, coraz mniej popularny spam w załącznikach o rozszerzeniu pdf, spam w wiadomościach odbitych. 1 Spamerzy często wykorzystują wirusy do rozsyłania niepożądanych informacji. Z drugiej strony, spam jest używany do rozpowszechniania w sieci wirusów. Pomijając aspekt niebezpieczeństwa, jakie ze sobą niesie, przeglądanie niepożądanej poczty wiąże się ze stratą czasu, co, w przypadku pracowników firm, przekłada się na stratę pieniędzy. Niepożądanymi zjawiskami, które wiążą się ze spamem, są tzw. phishing i joe-job. Phishing (inaczej spoofing) polega na fałszowaniu danych nadawcy wiadomości. Można w ten sposób utajnić prawdziwą tożsamość hosta wysyłającego list lub podszyć się pod godną zaufania instytucję 1 Spamerzy zakładają konta na darmowych portalach pocztowych. Konfigurują ich autorespondery tak, aby w odpowiedzi na przychodzące wiadomości, rozsyłały spam. Następnie wysyłają do tych adresów sfałszowane listy. Nadawcy, pod których adresy podszyli się, podczas wysyłania listu, spamerzy, dostają wiadomość zwrotną zawierającą niechcianą treść. 28

29 ROZDZIAŁ 2. CONTENT SECURITY np. w celu wyłudzenia poufnych informacji. Najprostszą formą phishingu jest zmiana adresu w poleceniu MAIL FROM. Joe-job to wysyłanie listów z adresu sfałszowanego w taki sposób, aby spam obciążył niewinną osobę. Problemy spamu i phishingu zniknęłyby wraz z wprowadzeniem wiarygodnej metody uwierzytelniania nadawców. Podejmowano próby zdefiniowania takiej metody. Niestety żadna ze znanych autorowi, nie jest w pełni bezpieczna, a jeśli zapewnia wysoki poziom bezpieczeństwa, wymaga zmiany istniejącej infrastruktury systemów pocztowych. Najpopularniejsze metody uwierzytelniania nadawcy listu elektronicznego to: SPF, Sender ID, DomainKeys, TEOS, CSV, przy czym SPF ma zdecydowanie najwięcej zwolenników. Używana jest np. przez serwery SMTP domen interia.pl i gazeta.pl. SPF (ang. Sender Policy Framework, pierwotnie Sender Permitted Form) polega na sprawdzeniu, czy host, próbujący wysłać list, ma uprawnienia do wykorzystania adresu, jakim się posługuje. W tym celu MTA wysyła do DNS zapytanie, które serwery mogą korzystać z domeny, którą nadawca podał w kopercie wiadomości. Informacje te mogą być zapisane w rekordach TXT (Text) DNS-u, jeśli dana domena publikuje rekordy SPF. SPF, choć popierana przez wielu użytkowników poczty, ma zatwardziałych przeciwników. Podstawową wadą tej metody jest jej niezgodność ze standardem dystrybucji poczty (RFC 2821). Metoda SPF opiera się na błędnym założeniu, że będą z niej korzystać wszystkie komunikujące się strony. Ponadto wymaga, aby użytkownik poczty korzystał z serwera SMTP, należącego do jego dostawcy pocztowego. Dla przykładu: mimo, że SMTP zezwala na wysyłanie poczty przez nadawcę za pośrednictwem serwera w domenie gazeta.pl, obsługujący SPF serwer pocztowy, do którego trafi przesyłka, odrzuci ją, ponieważ adres, podany w kopercie, nie jest zarejestrowany w rejestrach SPF domeny gazeta.pl. Z opisanym problemem wiąże się uniemożliwienie przekierowywania poczty przed jej dostarczeniem. Naiwnym rozwiązaniem tej niedogodności jest SRS (ang. Sender Rewriting Scheme), który polega na przepisaniu adresu nadawcy w kopercie listu przez serwer przekierowujący. Nowy adres składa się ze starego adresu i adresu serwera przekierowującego. Wystarczy kilka przekierowań i liczba znaków w polu MAIL FROM wykracza poza dozwoloną liczbę sześćdziesięciu czterech. SPF może przysłużyć się do ograniczenia phishingu. Nie proponuje jednak żadnego rozwiązania problemu spamu. Ponadto dyskryminuje pocztę przychodzącą z niechronionych domen, narażając serwery na odrzucanie pożądanych przesyłek, co jest niezgodne z ideą SMTP. Mimo tak istotnych wad, SPF jest dość szeroko stosowane. Popularność zawdzięcza w dużym stopniu firmie Microsoft i jej projektowi Sender ID, opartemu na SPF. Sender ID rozbudowuje ideę SPF o sprawdzanie nagłówków samej wiadomości (From, Sender itd). 29

30 ROZDZIAŁ 2. CONTENT SECURITY Inną możliwość autoryzacji nadawcy proponuje Yahoo!. Opracowane prze nie rozwiązanie nosi nazwę DomainKeys i jest dość podobne do SPF. Tak samo jak SPF opiera się na usługach DNS. Wprowadza jednak dodatkowy poziom bezpieczeństwa, wymagając podpisywania wiadomości wychodzących z serwera pocztowego za pomocą kluczy asymetrycznych algorytmów kryptograficznych. Podpis umieszczany jest w specjalnym nagłówku: DomainKeys-Signature. Obsługa szyfrowania listów obciąża w dość dużym stopniu serwery pocztowe. CSV (ang. Certified Server Validation) to proste zabezpieczenie przed modyfikacjami wiadomości. Adres IP hosta łączącego się z serwerem MTA jest sprawdzany z nazwą domeny, podaną przez niego w poleceniu HELO lub EHLO. CSV korzysta w tym celu z informacji podawanych przez DNS. Warto w tym miejscu wspomnieć, że protokół DNS nie jest bezpiecznym protokołem. Stosunkowo łatwo sfałszować rekordy serwerów DNS. Oprócz wymienionych, istnieje jeszcze jeden sposób na zabezpieczenie wiadomości przed sfałszowaniem. Definiuje go projekt TEOS (ang. Trusted Open Standard). TEOS proponuje wprowadzenie kilku dodatkowych poziomów sprawdzania integralności przesyłki. Celowi temu miałoby służyć m.in. wprowadzenie specjalnych cyfrowych certyfikatów, razem z którymi przesyłana byłaby poczta, oraz uzupełnienie funkcji serwerów pocztowych o mechanizmy do badania jej poprawności. TEOS nie przyjął się, ponieważ wymaga zmian w infrastrukturze SMTP. Mimo podejmowania prób uzupełnienia protokołu SMTP o funkcje zapewniające bezpieczeństwo przesyłanej poczty, zjawisko spamu jest powszechne. Jedyną możliwością rozpoznawania niepożądanych przesyłek jest filtrowanie poczty. Ponieważ nie da się go wbudować w interfejs serwerów pocztowych, a żadne z możliwych rozszerzeń funkcjonalności MTA nie przyjęło się w skali całego Internetu, wiadomości muszą być klasyfikowane za pomocą specjalnie do tego przeznaczonego oprogramowania. Stosowane są różne metody identyfikowania wiadomości. Warto wspomnieć o czarnych listach nadawców spamu DNSBL, odrzucaniu wiadomości od nierozpoznanych hostów, czyli greylisting u oraz o systemie challenge - response (CR), który polega na wysyłaniu żądania potwierdzenia nadania listu do klienta, przesyłającego . Najlepsze wyniki osiągane są, gdy powyższe techniki połączy się z kontrolą treści korespondencji elektronicznej. Badanie zawartości wiadomości wraz z inspekcją jej nagłówków nosi nazwę content security. 30

31 ROZDZIAŁ 2. CONTENT SECURITY 2.2 Metody filtrowania zawartości Analiza treści listu elektronicznego polega na sprawdzeniu czy nie występują w nim prawidłowości, pozwalające zaklasyfikować go do pewnej z góry określonej grupy. Najczęściej wyróżnia się spam, wiadomości zawierające złośliwy kod, wirusy itp. oraz wiadomości prawidłowe. Pierwszą historycznie metodą, jaką stosowano do filtracji poczty, była prymitywna analiza językowa. Polegała ona na wyszukiwaniu w treści przesyłki konkretnych wyrażeń. Początkowo przeglądano wiadomość pod kątem występowania w nagłówkach znanych adresów nadawców niechcianej poczty oraz pojawiania się w jej treści fraz, ewidentnie oznaczających spam. Niedługo później pojawiły się filtry porównujące treść listu z przesyłkami, tworzonymi przez znanych spamerów. Powstawały bazy danych słów i wyrażeń kojarzonych ze spamem, na podstawie których pierwsze filtry dopasowywały wiadomości do wzorca spamu. Współczesną wersją tego sposobu jest filtrowanie przez znakowanie listu. Na każdej otrzymanej wiadomości wykonywane są pewne określone obliczenia. Ich wyniki porównuje się z bazą znanych wiadomości spam. Pod koniec lat 90-tych dwudziestego wieku zaczęto stosować filtrowanie heurystyczne. Kieruje się ono zbiorem reguł. Reguły określają na podstawie jakich cech rozpoznawać wiadomość jako spam oraz jakie cechy musi mieć wiadomość poprawna. Filtry heurystyczne wyszukują w wiadomości charakterystyczne wzorce. Możliwe jest budowanie zaawansowanych reguł, które dają większe możliwości podejmowania decyzji. Jednym z pierwszych programów, który zaimplementował filtr heurystyczny, był SpamAssasin. Innego rodzaju techniką są filtry adaptacyjne. Do identyfikowania spamu używa się sieci wywiadowczej, np. zbioru danych leksykalnych, opisujących jego cechy. Najbardziej zaawansowane filtry to filtry Bayesa. Umożliwiają rozpoznawanie typu wiadomości na podstawie wyszukiwania słów kluczowych. Są uznawane za najbardziej skuteczne. Filtr Bayesa opiera się na regułach prawdopodobieństwa. Wzór Bayesa ma postać: P ( T i X ) = P (T i)p ( X T i ) P (X) (2.1) Oznaczenia: P (T i ) - prawdopodobieństwo, że wiadomość jest spamem. P (T i X) - prawdopodobieństwo, że wiadomość jest spamem, pod warunkiem, że pojawia się w niej wyraz X. 31

32 ROZDZIAŁ 2. CONTENT SECURITY P (X T i ) - prawdopodobieństwo wystąpienia wyrazu X w spamie. P (X) - prawdopodobieństwo wystąpienia wyrazu X w wiadomości. Filtry Bayesa trzeba nauczyć rozpoznawania spamu. Nauka polega na podaniu im na wejściu kolekcji wiadomości poprawnych oraz listy wiadomości niepożądanych. Filtr wyznacza prawdopodobieństwo wystąpienia w wiadomości prawidłowej oraz prawdopodobieństwo wystąpienia w spamie każdego przetwarzanego wyrazu. Po nadejściu do tak przygotowanego filtru nowego listu, umie on obliczyć prawdopodobieństwo, że list należy do którejś z wymienionych grup. Skuteczność filtrów Bayesa sięga 99% dla wiadomości tekstowych. Spam zawarty w obrazkach można wykryć przy pomocy narzędzi OCR (ang. Optical Character Recognition). Do metod filtrowania zawartości należy także zaliczyć: blokowanie załączników określonych typów, blokowanie części wiadomości zakodowanych określonymi typami znaków (charset), filtrowanie tekstu zakodowanego przy pomocy html lub JavaScript, w którym może być ukryty złośliwy kod. Funkcjonalność aplikacji, implementujących content security nie sprowadza się wyłącznie do standardowych metod badania treści wiadomości. Oprogramowanie content security realizuje następujące funkcje: kontroluje, czy klient skonstruował wiadomość zgodnie ze standardem SMTP / MIME, umożliwia sprawdzenie, czy klient podał prawidłowe pola nagłówkowe koperty wiadomości, bada, czy nagłówki wiadomości zostały skonstruowane wg reguł określonych w odpowiednim dokumencie RFC, analizuje treść nagłówków wiadomości, treść samej wiadomości oraz jej załączników (stosując któreś z opisanych wyżej metod, np. wyszukując słowa kluczowe), kontroluje rozmiar wiadomości i jej załączników, rozpoznaje typy załączników, 32

33 ROZDZIAŁ 2. CONTENT SECURITY klasyfikuje wiadomości jako poprawne i niechciane, dokonuje odpowiednich akcji na wiadomościach, w zależności od grupy, do której zaklasyfikowano przesyłkę. 2.3 Przegląd dostępnego oprogramowania, realizującego funkcję content security Na rynku IT znajduje się wiele systemów filtrowania poczty elektronicznej. Dostępne są zarówno kompleksowe zestawy narzędzi do zabezpieczania oprogramowania w obrębie całych sieci lokalnych, jak i oprogramowanie dedykowane na pojedyncze komputery klienckie. Większość aplikacji wchodzi w skład płatnych pakietów. Spośród znanych lub ciekawych pod względem wykonania aplikacji, warto wymienić produkty: Clearswift MIMESweeper, Aladdin esafe Mail, Sophos Security And Control, SurfControl Mail Filter i SpamAssasin. Poniżej omówiono niektóre z nich. Clearswift MIMESweeper to część większego systemu zabezpieczeń, stworzonego do ochrony infrastruktury sieciowej całych przedsiębiorstw. Oprogramowanie można zainstalować na maszynie dedykowanej do tego celu, w strefie DMZ bez połączenia z internetem lub na serwerze SMTP. MIMESweeper oferuje funkcjonalność w zakresie: analizy ruchu SMTP, blokowania poczty z określonych hostów, ochrony antyspamowej, realizowanej przez połączenie wyszukiwania wzorców z filtrami Bayesa i listami RBL, skanowania antywirusowego załączników, blokowania lub usuwania załączników określonego typu, rozpoznawanego wg zawartości pliku, klasyfikowania wiadomości przychodzących i wychodzących i być może blokowania lub usuwania ich, archiwizacji wiadomości, przechodzących przez obsługiwaną sieć, innych zastosowań. 33

34 ROZDZIAŁ 2. CONTENT SECURITY Oprogramowanie firmy Clearswift zrealizowano w architekturze, złożonej z niezależnych warstw. Należą do nich moduły: monitorowania ruchu sieciowego, odbierania wiadomości, dostarczania listów odbiorcom, klasyfikowania przesyłki, śledzenia zdarzeń w systemie, obsługi konfiguracji, tworzenia raportów i audytów. MIMESweeper to oprogramowanie, realizujące założenia, na których wzorowano się przy tworzeniu autorskiego rozwiązania. Aladdin esafe Mail to kompleksowe oprogramowanie do zabezpieczania poczty elektronicznej przedsiębiorstwa. Podobnie jak MIMESweeper oferuje skuteczną ochronę przed spamem, wirusami, złośliwym kodem, spoofingiem oraz atakami hakerskimi na serwery. W dziedzinie badania zawartości przesyłki , Aladdin esafe Mail łączy metody filtrowania heurystycznego, znakowanie wiadomości i sprawdzanie sygnatur listów. Narzędzie oparto na silniku Dual-Engine Security, który potrafi uwierzytelniać nadawcę i klasyfikować przesyłane przez niego wiadomości w czasie rzeczywistym. SpamAssasin to darmowy program open-source do badania zawartości listu . Najczęściej konfiguruje się go do współpracy z silnikiem antywirusowym np. clamav. SpamAssasin jest jednym z najstarszych narzędzi filtrujących pocztę. Analiza wiadomości jest wynikiem połączenia metod wyszukiwania słów i fraz kluczowych, filtrowania Bayesa, sprawdzania zgodności adresów nadawców z czarnymi listami DNS oraz porównywania listu z bazami danych spamu. SpamAssasin nie potrafi usuwać ani przekierowywać spamu. Nie przekazuje przesyłki dalej. Służy wyłącznie do klasyfikowania wiadomości. Klasyfikacja ma postać nadania wiadomości punktów, które określają prawdopodobieństwo, z jakim wiadomość jest spamem. Interpretacja wyniku należy do zewnętrznych programów. 34

35 Rozdział 3 Założenia projektowe tworzonego systemu Stworzenie aplikacji, dorównującej funkcjonalnością opisanym w poprzednim rozdziale narzędziom wykracza poza ramy tej pracy. Każde z nich było rozwijane przez lata przez specjalistów. Projektowany system ma jednak wyróżniać się spośród dostępnego oprogramowania jakością i czystością rozwiązania. Dlatego postawione mu wymagania oraz przyjęte na początku procesu jego tworzenia założenia zostały sformułowane w taki sposób, aby umożliwić zaimplementowanie 3.1 Wymagania funkcjonalne 1. Rozpoznawanie struktury poleceń SMTP i odpowiednia reakcja na ich błędy. 2. Przechwytywanie wiadomości przekazywanych przez protokół SMTP. W systemie będzie się odbywało na poziomie protokołu SMTP (proxy aplikacyjne). 3. Wydzielanie z wiadomości nagłówków, właściwej treści i załączników i przechowywanie ich w wygodnej do przeglądania formie. Wymagana jest umiejętność dekodowania i kodowania części wiadomości. 4. Filtrowanie wiadomości. Będzie wykonywane na podstawie reguł zapisanych w postaci wyrażeń regularnych w pliku XML. Każda wiadomość będzie analizowana pod kątem każdej reguły i oceniana względem stopnia jej spełnienia. Suma z wystawionych ocen stworzy końcową ocenę wiadomości. 5. Klasyfikacja wiadomości. Wiadomości mogą trafić do grup: listów pożądanych, spamu, który powinien trafić do kwarantanny lub zagrożeń, przeznaczonych do usunięcia. 35

36 ROZDZIAŁ 3. ZAŁOŻENIA PROJEKTOWE TWORZONEGO SYSTEMU 6. Logowanie zdarzeń w celu wykrycia nieprawidłowości. 7. Przechowywanie wiadomości i innych danych w plikach. 3.2 Wymagania niefunkcjonalne 1. Stabilność i niezawodność System powinien zapewniać niezawodną pracę. Należy zrealizować obsługę wyjątków w celu reagowania na niespodziewane błędy. Wymagana jest poprawna reakcja na problem wyczerpania się pamięci. 2. Odporność na dane niezgodne z protokołem SMTP / MIME (określana przez pliki konfiguracyjne) System powinien być maksymalnie odporny na dane wejściowe, tzn. powinien przyjmować do analizy dowolne wiadomości. 3. Wydajność Podstawą wydajnej pracy będzie stabilny, szybki parser wiadomości. Aby zminimalizować konieczność powolnego dostępu do dysku twardego, wiadomości będą przechowywane w pamięci dopóki nie zakończy się proces ich przetwarzania. 4. Praca w środowisku linuksowym 5. Przejrzysta i jasna konstrukcja Zostanie zrealizowana poprzez podzielenie pracy na odrębne moduły, odpowiadające za konkretne zadania. 6. Czytelny, spójny, łatwy w utrzymaniu kod 3.3 Ograniczenia zakresu realizacji zadania System będzie obsługiwał protokół SMTP w formie podstawowej (nie ESMTP). Nie będą używane dodatkowe programy antywirusowe do badania załączników. Nie zostanie zaimplementowane filtrowanie Bayesa. Wymienione punkty, z których zrezygnowano przy tworzeniu obecnej wersji oprogramowania, zostaną dołączone do projektu, jeśli zostanie czas na ich realizację. 36

37 Rozdział 4 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 4.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. 4.1 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), 37

38 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU Katalog config filter logs mime parser smtp system utils Tablica 4.1: Struktura katalogów projektu 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. 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. 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: 38

39 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU Rysunek 4.1: Podstawowe moduły systemu 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ę: 39

40 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU a.) jeśli wiadomość ma zostać przesłana dalej, przekazuje ją do modułu wysyłającego (Sender) z powiadomieniem WD 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. 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. 4.2 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 40

41 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU 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 4.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 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 41

Bezpieczeństwo poczty elektronicznej

Bezpieczeństwo poczty elektronicznej Bezpieczeństwo poczty elektronicznej Mariusz Goch Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych 1 Plan prezentacji Bezpieczeństwo transportu wiadomości Problemy serwera pocztowego

Bardziej szczegółowo

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko TCP/IP Warstwa aplikacji mgr inż. Krzysztof Szałajko Modele odniesienia 7 Aplikacji 6 Prezentacji 5 Sesji 4 Transportowa 3 Sieciowa 2 Łącza danych 1 Fizyczna Aplikacji Transportowa Internetowa Dostępu

Bardziej szczegółowo

PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ

PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ Poczta elektroniczna służy do przesyłania komunikatów tekstowych, jak również dołączonych do nich informacji nietekstowych (obraz, dźwięk) pomiędzy użytkownikami

Bardziej szczegółowo

Instrukcja konfiguracji funkcji skanowania

Instrukcja konfiguracji funkcji skanowania Instrukcja konfiguracji funkcji skanowania WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_PL 2004. Wszystkie prawa zastrzeżone. Rozpowszechnianie bez zezwolenia przedstawionych materiałów i informacji

Bardziej szczegółowo

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują

Bardziej szczegółowo

Java wybrane technologie

Java wybrane technologie Java wybrane technologie spotkanie nr 2 JavaMail 1 Wprowadzenie JavaMail 1.4 (opiera się na JavaBean Activation Framework (JAF) 1.1) odbieranie, tworzenie i wysyłanie wiadomości elektronicznych dla twórców

Bardziej szczegółowo

Skrócony podręcznik dla partnerów

Skrócony podręcznik dla partnerów Skrócony podręcznik dla partnerów Zapraszamy Dziękujemy za wybranie usługi GFI MAX MailProtection (dawniej Katharion ). Firma GFI będąca liderem walki ze spamem dokłada wszelkich starań, aby zapewnić użytkownikom

Bardziej szczegółowo

Java Enterprise Edition spotkanie nr 1 (c.d.) JavaMail

Java Enterprise Edition spotkanie nr 1 (c.d.) JavaMail Java Enterprise Edition spotkanie nr 1 (c.d.) JavaMail 1 Wprowadzenie JavaMail 1.4 (opiera się na JavaBean Activation Framework (JAF) 1.1) odbieranie, tworzenie i wysyłanie wiadomości elektronicznych w

Bardziej szczegółowo

ZESZYTY ETI ZESPOŁU SZKÓŁ W TARNOBRZEGU Nr 1 Seria: Teleinformatyka 2012 POCZTA ELEKTRONICZNA PROTOKÓŁ SMTP PRZYKŁADY KOMUNIKACJI

ZESZYTY ETI ZESPOŁU SZKÓŁ W TARNOBRZEGU Nr 1 Seria: Teleinformatyka 2012 POCZTA ELEKTRONICZNA PROTOKÓŁ SMTP PRZYKŁADY KOMUNIKACJI ZESZYTY ETI ZESPOŁU SZKÓŁ W TARNOBRZEGU Nr 1 Seria: Teleinformatyka 2012 Mateusz Gaweł Zespół Szkół im. ks. S. Staszica w Tarnobrzegu POCZTA ELEKTRONICZNA PROTOKÓŁ SMTP PRZYKŁADY KOMUNIKACJI Streszczenie

Bardziej szczegółowo

Laboratorium 3.4.3: Usługi i protokoły e-mail

Laboratorium 3.4.3: Usługi i protokoły e-mail Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy Fa0/0 192.168.254.253 255.255.255.0 Nie dotyczy R2-Central

Bardziej szczegółowo

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Spis treści Konfiguracja Microsoft Outlook 2007... 3 Konfiguracja dla POP3... 7 Konfiguracja dla IMAP... 11 Sprawdzenie poprawności

Bardziej szczegółowo

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji Bezpieczeństwo sieci teleinformatycznych Laboratorium 5 Temat: Polityki bezpieczeństwa FortiGate. Spis treści 2. Cel ćwiczenia...

Bardziej szczegółowo

Sieci komputerowe. Wstęp

Sieci komputerowe. Wstęp Sieci komputerowe Wstęp Sieć komputerowa to grupa komputerów lub innych urządzeń połączonych ze sobą w celu wymiany danych lub współdzielenia różnych zasobów, na przykład: korzystania ze wspólnych urządzeń

Bardziej szczegółowo

Model sieci OSI, protokoły sieciowe, adresy IP

Model sieci OSI, protokoły sieciowe, adresy IP Model sieci OSI, protokoły sieciowe, adresy IP Podstawę działania internetu stanowi zestaw protokołów komunikacyjnych TCP/IP. Wiele z używanych obecnie protokołów zostało opartych na czterowarstwowym modelu

Bardziej szczegółowo

1. Model klient-serwer

1. Model klient-serwer 1. 1.1. Model komunikacji w sieci łącze komunikacyjne klient serwer Tradycyjny podziała zadań: Klient strona żądająca dostępu do danej usługi lub zasobu Serwer strona, która świadczy usługę lub udostępnia

Bardziej szczegółowo

System operacyjny UNIX Internet. mgr Michał Popławski, WFAiIS

System operacyjny UNIX Internet. mgr Michał Popławski, WFAiIS System operacyjny UNIX Internet Protokół TCP/IP Został stworzony w latach 70-tych XX wieku w DARPA w celu bezpiecznego przesyłania danych. Podstawowym jego założeniem jest rozdzielenie komunikacji sieciowej

Bardziej szczegółowo

SMTP co to takiego? SMTP Simple Mail Transfer Protocol (Protokół Prostego Przesyłania Poczty) RFC 2821

SMTP co to takiego? SMTP Simple Mail Transfer Protocol (Protokół Prostego Przesyłania Poczty) RFC 2821 SMTP co to takiego? SMTP Simple Mail Transfer Protocol (Protokół Prostego Przesyłania Poczty) RFC 2821 Protokół niezawodnego przesyłania wiadomości tekstowych (e-mail) za pomocą prostych komend tekstowych.

Bardziej szczegółowo

Budowa wiadomości SMTP. autorzy: Aleksandra Wichert Marcin Żurowski

Budowa wiadomości SMTP. autorzy: Aleksandra Wichert Marcin Żurowski Budowa wiadomości SMTP autorzy: Aleksandra Wichert Marcin Żurowski Plan wykładu Co to jest SMTP? Koperta Nagłówek Wiadomość Co to jest SMTP? Prosty protokół przesyłania poczty elektronicznej (Simple Mail

Bardziej szczegółowo

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych Wykład 2: Budowanie sieci lokalnych 1 Budowanie sieci lokalnych Technologie istotne z punktu widzenia konfiguracji i testowania poprawnego działania sieci lokalnej: Protokół ICMP i narzędzia go wykorzystujące

Bardziej szczegółowo

Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol)

Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol) Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol) W latach 1973-78 Agencja DARPA i Stanford University opracowały dwa wzajemnie uzupełniające się protokoły: połączeniowy TCP

Bardziej szczegółowo

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl Instrukcja do panelu administracyjnego do zarządzania kontem FTP WebAs www.poczta.greenlemon.pl Opracowanie: Agencja Mediów Interaktywnych GREEN LEMON Spis treści 1.Wstęp 2.Konfiguracja 3.Konto FTP 4.Domeny

Bardziej szczegółowo

SERWERY WIRTUALNE Stabilność, szybkość i bezpieczeństwo danych...

SERWERY WIRTUALNE Stabilność, szybkość i bezpieczeństwo danych... SERWERY WIRTUALNE Stabilność, szybkość i bezpieczeństwo danych... Oferujemy Państwu profesjonalny hosting już od około 0,17 zł netto/dziennie. Jeśli korzystają Państwo z dużych drogich serwerów i nie chcą

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

INSTRUKCJA OBSŁUGI DLA SIECI

INSTRUKCJA OBSŁUGI DLA SIECI INSTRUKCJA OBSŁUGI DLA SIECI Zapisywanie dziennika druku w lokalizacji sieciowej Wersja 0 POL Definicje dotyczące oznaczeń w tekście W tym Podręczniku użytkownika zastosowano następujące ikony: Uwagi informują

Bardziej szczegółowo

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny?

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny? Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA Dlaczego DNS jest tak ważny? DNS - System Nazw Domenowych to globalnie rozmieszczona usługa Internetowa. Zapewnia tłumaczenie nazw domen

Bardziej szczegółowo

Bezpieczeństwo poczty elektronicznej

Bezpieczeństwo poczty elektronicznej Bezpieczeństwo poczty elektronicznej Mariusz Goch Wydział Elektroniki i Technik Informacyjnych Politechnika Warszawska W aktualnych czasach bezpieczeństwo komunikacji stało się jednym z najistotniejszych

Bardziej szczegółowo

1 Technologie Informacyjne WYKŁAD I. Internet - podstawy

1 Technologie Informacyjne WYKŁAD I. Internet - podstawy 1 Technologie Informacyjne WYKŁAD I Internet - podstawy MAIL: a.dudek@pwr.edu.pl WWW: http://wgrit.ae.jgora.pl/ad KONSULTACJE: czwartki, piątki 8.00-9.00 sala 118 2 Internet to globalna, ogólnoświatowa

Bardziej szczegółowo

Krótka instrukcja instalacji

Krótka instrukcja instalacji Krótka instrukcja instalacji Spis treści Krok 1 Pobieranie plików instalacyjnych Krok 2 Ekran powitalny Krok 3 Umowa licencyjna Krok 4 Wybór miejsca instalacji Krok 5 Informacje rejestracyjne Krok 6 Rozpoczęcie

Bardziej szczegółowo

Manual konfiguracji konta dla fax2mail

Manual konfiguracji konta dla fax2mail Manual konfiguracji konta dla fax2mail Spis treści 1 AKTYWACJA KONTA FAX2MAIL... 3 2 KONFIGURACJA KONTA FAX2MAIL MS OUTLOOK 2003... 5 3 KONFIGURACJA KONTA FAX2MAIL MS OUTLOOK 2010... 11 4 KONFIGURACJA

Bardziej szczegółowo

9. System wykrywania i blokowania włamań ASQ (IPS)

9. System wykrywania i blokowania włamań ASQ (IPS) 9. System wykrywania i blokowania włamań ASQ (IPS) System Intrusion Prevention w urządzeniach NETASQ wykorzystuje unikalną, stworzoną w laboratoriach firmy NETASQ technologię wykrywania i blokowania ataków

Bardziej szczegółowo

Warstwy i funkcje modelu ISO/OSI

Warstwy i funkcje modelu ISO/OSI Warstwy i funkcje modelu ISO/OSI Organizacja ISO opracowała Model Referencyjny Połączonych Systemów Otwartych (model OSI RM - Open System Interconection Reference Model) w celu ułatwienia realizacji otwartych

Bardziej szczegółowo

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne Jarosław Kuchta Internetowe Usługi Informacyjne Komponenty IIS HTTP.SYS serwer HTTP zarządzanie połączeniami TCP/IP buforowanie odpowiedzi obsługa QoS (Quality of Service) obsługa plików dziennika IIS

Bardziej szczegółowo

Konfiguracja programu pocztowego dla kont w domenie spcsk.pl

Konfiguracja programu pocztowego dla kont w domenie spcsk.pl dla kont w domenie spcsk.pl 24 lutego 2012 Spis treści 1 Informacje ogólne 1 2 Konfiguracja programu Mozilla Thunderbird 2 3 Konfiguracja innych klientów poczty 10 4 Pytania i odpowiedzi 10 1 Informacje

Bardziej szczegółowo

Poniżej znajduje się instrukcja konfiguracji najpopularniejszych programów do obsługi poczty.

Poniżej znajduje się instrukcja konfiguracji najpopularniejszych programów do obsługi poczty. Uwagi ogólne System pocztowy NetMail wspiera protokoły pocztowe IMAP oraz SMTP (protokół POP3 został wyłączony). Umożliwia to współpracę z programami pocztowymi takimi jak Outlook Express, Mozilla Thunderbird

Bardziej szczegółowo

Instrukcja aktywacji tokena w usłudze BPTP

Instrukcja aktywacji tokena w usłudze BPTP Instrukcja aktywacji tokena w usłudze BPTP Użytkownicy usługi BPTP, którzy otrzymali przesyłki pocztowe zawierające token USB wraz z listem informującym o potrzebie aktywacji urządzenia powinni wykonać

Bardziej szczegółowo

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail. A. Kisiel,Protokoły DNS, SSH, HTTP, e-mail

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail. A. Kisiel,Protokoły DNS, SSH, HTTP, e-mail N, Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail 1 Domain Name Service Usługa Domain Name Service (DNS) Protokół UDP (port 53), klient-serwer Sformalizowana w postaci protokołu DNS Odpowiada

Bardziej szczegółowo

Konfiguracja konta pocztowego w Thunderbird

Konfiguracja konta pocztowego w Thunderbird Konfiguracja konta pocztowego w Thunderbird Sygnity SA 2013 Wszystkie prawa zastrzeżone. Znaki firmowe oraz towarowe użyte w opracowaniu są prawną własnością ich właścicieli. Autor dokumentacji: Magdalena

Bardziej szczegółowo

Sieci Komputerowe. Wykład 1: TCP/IP i adresowanie w sieci Internet

Sieci Komputerowe. Wykład 1: TCP/IP i adresowanie w sieci Internet Sieci Komputerowe Wykład 1: TCP/IP i adresowanie w sieci Internet prof. nzw dr hab. inż. Adam Kisiel kisiel@if.pw.edu.pl Pokój 114 lub 117d 1 Kilka ważnych dat 1966: Projekt ARPANET finansowany przez DOD

Bardziej szczegółowo

Jak zacząć korzystać w HostedExchange.pl ze swojej domeny np. @firma.pl

Jak zacząć korzystać w HostedExchange.pl ze swojej domeny np. @firma.pl str. 1 Jak zacząć korzystać w HostedExchange.pl ze swojej domeny np. @firma.pl W tym dokumencie znajdziesz: Krok 1 - Kup domenę u dowolnego dostawcy... 1 Krok 2 - Dodaj domenę do panelu zarządzania HostedExchange.pl...

Bardziej szczegółowo

Integracja Plan-de-CAMpagne z oprogramowaniem MS Outlook

Integracja Plan-de-CAMpagne z oprogramowaniem MS Outlook Integracja Plan-de-CAMpagne z oprogramowaniem MS Outlook Poczta elektroniczna została wynaleziona w 1965 roku jednak różniła się w znaczący sposób od znanej obecnie. Wiadomości przesyłano wtedy pomiędzy

Bardziej szczegółowo

SKRÓCONA INSTRUKCJA OBSŁUGI POCZTY ELEKTRONICZNEJ ZIMBRA WEBMAIL

SKRÓCONA INSTRUKCJA OBSŁUGI POCZTY ELEKTRONICZNEJ ZIMBRA WEBMAIL AKADEMIA MORSKA W SZCZECINIE ul. W ały Chrobrego 1-2 70-500 Szczecin telefon (+48 91) 480 93 3 6 fax (+48 91) 480 95 75 www.am.szczecin.pl e-mail:uci@am.szczecin.pl SKRÓCONA INSTRUKCJA OBSŁUGI POCZTY ELEKTRONICZNEJ

Bardziej szczegółowo

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe N, Wykład 4: Protokoły TCP/UDP i usługi sieciowe 1 Adres aplikacji: numer portu Protokoły w. łącza danych (np. Ethernet) oraz w. sieciowej (IP) pozwalają tylko na zaadresowanie komputera (interfejsu sieciowego),

Bardziej szczegółowo

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami Struktury sieciowe Struktury sieciowe Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne 15.1 15.2 System rozproszony Motywacja

Bardziej szczegółowo

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail 1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce

Bardziej szczegółowo

Program szkolenia KURS SPD i PD Administrator szkolnej pracowni internetowej Kurs MD1 Kurs MD2 Kurs MD3 (dla szkół ponadgimnazjalnych)

Program szkolenia KURS SPD i PD Administrator szkolnej pracowni internetowej Kurs MD1 Kurs MD2 Kurs MD3 (dla szkół ponadgimnazjalnych) Miejsce prowadzenia szkolenia Program szkolenia KURS SPD i PD Administrator pracowni internetowej Kurs MD1 Kurs MD2 Kurs MD3 (dla szkół ponadgimnazjalnych) Pracownie komputerowe znajdujące się w wyznaczonych

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

Programowanie współbieżne i rozproszone

Programowanie współbieżne i rozproszone Programowanie współbieżne i rozproszone WYKŁAD 6 dr inż. Komunikowanie się procesów Z użyciem pamięci współdzielonej. wykorzystywane przede wszystkim w programowaniu wielowątkowym. Za pomocą przesyłania

Bardziej szczegółowo

Mediatel 4B Sp. z o.o., ul. Bitwy Warszawskiej 1920 r. 7A, 02-366 Warszawa, www.mediatel.pl

Mediatel 4B Sp. z o.o., ul. Bitwy Warszawskiej 1920 r. 7A, 02-366 Warszawa, www.mediatel.pl W instrukcji znajdują się informacje dotyczące zakresu działania usługi efax oraz kilka wskazówek umożliwiających sprawne wykorzystywanie usługi wirtualnych faksów w codziennej pracy. Wysyłanie i odczytywanie

Bardziej szczegółowo

Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński

Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński Temat 8.9. Wykrywanie i usuwanie awarii w sieciach komputerowych. 1. Narzędzia

Bardziej szczegółowo

Zmiany wprowadzone w pakiecie. Projekt PSZ.eDOK

Zmiany wprowadzone w pakiecie. Projekt PSZ.eDOK Projekt Wersja 5.0 09 kwietnia 2013 Dokument wg wzorca PULS/SW/KOD/FR/10 Strona: 1 Spis treści 1. 3 Moduł administratora 1.1. Aktualizacja serwera PostgresSQL do wersji 9.2.1 3 1.2. Dodano usługę Single

Bardziej szczegółowo

Problemy z bezpieczeństwem w sieci lokalnej

Problemy z bezpieczeństwem w sieci lokalnej Problemy z bezpieczeństwem w sieci lokalnej możliwości podsłuchiwania/przechwytywania ruchu sieciowego pakiet dsniff demonstracja kilku narzędzi z pakietu dsniff metody przeciwdziałania Podsłuchiwanie

Bardziej szczegółowo

Technologie sieciowe

Technologie sieciowe Technologie sieciowe ITA-108 Wersja 1.2 Katowice, Lipiec 2009 Spis treści Wprowadzenie i Moduł I Wprowadzenie do sieci komputerowych I-1 Moduł II Omówienie i analiza TCP/IP II-1 Moduł III Zarządzanie adresacją

Bardziej szczegółowo

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

Wydajny filtr SMTP PRACA DYPLOMOWA INŻYNIERSKA. Katarzyna Ciechańska. dr inż. Grzegorz Blinowski 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

Bardziej szczegółowo

Stos TCP/IP. Warstwa aplikacji cz.2

Stos TCP/IP. Warstwa aplikacji cz.2 aplikacji transportowa Internetu Stos TCP/IP dostępu do sieci Warstwa aplikacji cz.2 Sieci komputerowe Wykład 6 FTP Protokół transmisji danych w sieciach TCP/IP (ang. File Transfer Protocol) Pobieranie

Bardziej szczegółowo

Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia

Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia Sieci komputerowe Wykład Nr 4 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia Sieci bezprzewodowe Sieci z bezprzewodowymi punktami dostępu bazują na falach radiowych. Punkt dostępu musi mieć

Bardziej szczegółowo

Pomoc dla http://host.nask.pl/ 31.12.2012 r.

Pomoc dla http://host.nask.pl/ 31.12.2012 r. Pomoc dla http://host.nask.pl/ 31.12.2012 r. Spis treści Kontakt... 2 Logowanie do konta pocztowego przez WWW... 3 Logowanie do panelu administracyjnego... 4 Konfiguracja klienta pocztowego... 7 Umieszczanie

Bardziej szczegółowo

1. Zakres modernizacji Active Directory

1. Zakres modernizacji Active Directory załącznik nr 1 do umowy 1. Zakres modernizacji Active Directory 1.1 Opracowanie szczegółowego projektu wdrożenia. Określenie fizycznych lokalizacji serwerów oraz liczby lokacji Active Directory Określenie

Bardziej szczegółowo

Podręcznik instalacji i konfiguracji aplikacji 7 Office Ship Control dla Microsoft Office 2007 i 2010. Siódemka S.A. Warszawa, dnia 06.02.20112r.

Podręcznik instalacji i konfiguracji aplikacji 7 Office Ship Control dla Microsoft Office 2007 i 2010. Siódemka S.A. Warszawa, dnia 06.02.20112r. Podręcznik instalacji i konfiguracji aplikacji 7 Office Ship Control dla Microsoft Office 2007 i 2010 Siódemka S.A. Warszawa, dnia 06.02.20112r. 1 Spis treści: 1. Przed instalacją aplikacji 7 Office Ship

Bardziej szczegółowo

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Załącznik Nr 1 Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Wersja 1.0 Na podstawie: Europejskiej Modelowej Umowy o EDI (w skrócie:

Bardziej szczegółowo

Produkty. ESET Produkty

Produkty. ESET Produkty Produkty ESET Produkty czerwiec 2006 COPYRIGHT ArkaNET KATOWICE CZERWIEC 2006 KOPIOWANIE I ROZPOWSZECHNIANIE ZABRONIONE ESET Produkty czerwiec 2006 Wersja dokumentu W dokumencie użyto obrazków zaczerpniętych

Bardziej szczegółowo

e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ

e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ www.e-awizo.pl BrainSoft sp. z o. o. ul. Bolesława Chrobrego 14/2 65-052 Zielona Góra tel.68 455 77 44 fax 68 455 77 40 e-mail: biuro@brainsoft.pl

Bardziej szczegółowo

156.17.4.13. Adres IP

156.17.4.13. Adres IP Adres IP 156.17.4.13. Adres komputera w sieci Internet. Każdy komputer przyłączony do sieci ma inny adres IP. Adres ten jest liczbą, która w postaci binarnej zajmuje 4 bajty, czyli 32 bity. W postaci dziesiętnej

Bardziej szczegółowo

Tworzenie i obsługa wirtualnego laboratorium komputerowego

Tworzenie i obsługa wirtualnego laboratorium komputerowego Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ochociński nr albumu: 236401 Praca magisterska na kierunku informatyka stosowana Tworzenie i obsługa wirtualnego

Bardziej szczegółowo

Praca w sieci równorzędnej

Praca w sieci równorzędnej Praca w sieci równorzędnej 1. Architektura sieci równorzędnej i klient-serwer Serwer - komputer, który udostępnia zasoby lub usługi. Klient komputer lub urządzenie korzystające z udostępnionych przez serwer

Bardziej szczegółowo

Zasady Wykorzystywania Plików Cookies

Zasady Wykorzystywania Plików Cookies Zasady Wykorzystywania Plików Cookies Definicje i objaśnienia używanych pojęć Ilekroć w niniejszym zbiorze Zasad wykorzystywania plików Cookies pojawia się któreś z poniższych określeń, należy rozumieć

Bardziej szczegółowo

Serwer faksowy Vidicode. kompletne rozwiązanie do komunikacji faksowej dla każdego przedsiębiorstwa

Serwer faksowy Vidicode. kompletne rozwiązanie do komunikacji faksowej dla każdego przedsiębiorstwa Serwer faksowy Vidicode kompletne rozwiązanie do komunikacji faksowej dla każdego przedsiębiorstwa Czym jest serwer faksowy Vidicode? Serwer faksowy Vidicode to urządzenie pozwalające na połączenie sieci

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

System komputerowy. Sprzęt. System komputerowy. Oprogramowanie

System komputerowy. Sprzęt. System komputerowy. Oprogramowanie System komputerowy System komputerowy (ang. computer system) to układ współdziałaniadwóch składowych: sprzętu komputerowegooraz oprogramowania, działających coraz częściej również w ramach sieci komputerowej.

Bardziej szczegółowo

Wykaz zmian w programie SysLoger

Wykaz zmian w programie SysLoger Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko

Bardziej szczegółowo

Jak wysyłany jest spam? Tomasz Nidecki

Jak wysyłany jest spam? Tomasz Nidecki Jak wysyłany jest spam? Tomasz Nidecki Artykuł opublikowany w numerze 2/2004 magazynu Hakin9 Wszelkie prawa zastrzeżone. Bezpłatne kopiowanie i rozpowszechnianie artykułu dozwolone pod warunkiem zachowania

Bardziej szczegółowo

witoldgrzelczak@mailplus.pl 3. Wymagania wstępne w zakresie wiedzy, umiejętności i kompetencji społecznych Wiedza

witoldgrzelczak@mailplus.pl 3. Wymagania wstępne w zakresie wiedzy, umiejętności i kompetencji społecznych Wiedza 1. Informacje ogólne Nazwa przedmiotu Technologie sieciowe - 1 Kod kursu ID3103/IZ4103 Liczba godzin Wykład Ćwiczenia Laboratorium Projekt Seminarium Studia stacjonarne 30 0 30 0 0 Studia niestacjonarne

Bardziej szczegółowo

Microsoft Exchange Server 2013

Microsoft Exchange Server 2013 William R. Stanek Vademecum Administratora Microsoft Exchange Server 2013 Konfiguracja i klienci systemu Przekład: Leszek Biolik APN Promise 2013 Spis treści Wstęp..........................................

Bardziej szczegółowo

2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego

2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego 2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego produktu. 23 czerwca 2014 Spis treści 3 Spis treści...5

Bardziej szczegółowo

Arkanet s.c. Produkty. Sophos Produkty

Arkanet s.c. Produkty. Sophos Produkty Produkty Sophos Produkty sierpień 2006 COPYRIGHT ArkaNET KATOWICE SIERPIEŃ 2006 KOPIOWANIE I ROZPOWSZECHNIANIE ZABRONIONE Sophos Produkty sierpień 2006 W dokumencie użyto obrazków zaczerpniętych z dokumentacji

Bardziej szczegółowo

Protokół sieciowy Protokół

Protokół sieciowy Protokół PROTOKOŁY SIECIOWE Protokół sieciowy Protokół jest to zbiór procedur oraz reguł rządzących komunikacją, między co najmniej dwoma urządzeniami sieciowymi. Istnieją różne protokoły, lecz nawiązujące w danym

Bardziej szczegółowo

ActiveXperts SMS Messaging Server

ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server to oprogramowanie typu framework dedykowane wysyłaniu, odbieraniu oraz przetwarzaniu wiadomości SMS i e-mail, a także tworzeniu własnych

Bardziej szczegółowo

WLAN bezpieczne sieci radiowe 01

WLAN bezpieczne sieci radiowe 01 WLAN bezpieczne sieci radiowe 01 ostatnim czasie ogromną popularność zdobywają sieci bezprzewodowe. Zapewniają dużą wygodę w dostępie użytkowników do zasobów W informatycznych. Jednak implementacja sieci

Bardziej szczegółowo

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.

Bardziej szczegółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.eu Mobilne Rozwiązania dla biznesu Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia

Bardziej szczegółowo

Akademia Techniczno-Humanistyczna w Bielsku-Białej

Akademia Techniczno-Humanistyczna w Bielsku-Białej Akademia Techniczno-Humanistyczna w Bielsku-Białej Wydział Budowy Maszyn i Informatyki Laboratorium z sieci komputerowych Ćwiczenie numer: 9 Temat ćwiczenia: Aplikacje klient-serwer. 1. Wstęp teoretyczny.

Bardziej szczegółowo

Adresy w sieciach komputerowych

Adresy w sieciach komputerowych Adresy w sieciach komputerowych 1. Siedmio warstwowy model ISO-OSI (ang. Open System Interconnection Reference Model) 7. Warstwa aplikacji 6. Warstwa prezentacji 5. Warstwa sesji 4. Warstwa transportowa

Bardziej szczegółowo

Zestaw ten opiera się na pakietach co oznacza, że dane podczas wysyłania są dzielone na niewielkie porcje. Wojciech Śleziak

Zestaw ten opiera się na pakietach co oznacza, że dane podczas wysyłania są dzielone na niewielkie porcje. Wojciech Śleziak Protokół TCP/IP Protokół TCP/IP (Transmission Control Protokol/Internet Protokol) to zestaw trzech protokołów: IP (Internet Protokol), TCP (Transmission Control Protokol), UDP (Universal Datagram Protokol).

Bardziej szczegółowo

Projektowanie bezpieczeństwa sieci i serwerów

Projektowanie bezpieczeństwa sieci i serwerów Projektowanie bezpieczeństwa sieci i serwerów Konfiguracja zabezpieczeń stacji roboczej 1. Strefy bezpieczeństwa przeglądarki Internet Explorer. W programie Internet Explorer można skonfigurować ustawienia

Bardziej szczegółowo

7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze

7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze Specyfikacja oprogramowania do Opis zarządzania przedmiotu i monitorowania zamówienia środowiska Załącznik nr informatycznego 1 do specyfikacji Lp. 1. a) 1. Oprogramowanie oprogramowania i do systemów

Bardziej szczegółowo

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR UWAGA Aby zapewnić niezawodną pracę urządzenia, przed przystąpieniem do jego obsługi

Bardziej szczegółowo

1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19

1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19 Spis treści 3 1. Wprowadzenie...9 2. Środowisko multimedialnych sieci IP... 11 2.1. Model odniesienia... 11 2.2. Ewolucja technologii sieciowych...12 2.3. Specyfika ruchowa systemów medialnych...13 2.4.

Bardziej szczegółowo

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ WYMAGANIA BEZPIECZEŃSTWA DLA SYSTEMÓW IT Wyciąg z Polityki Bezpieczeństwa Informacji dotyczący wymagań dla systemów informatycznych. 1 Załącznik Nr 3 do Część II SIWZ Wymagania

Bardziej szczegółowo

Instrukcja integratora - obsługa dużych plików w epuap2

Instrukcja integratora - obsługa dużych plików w epuap2 Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA

Bardziej szczegółowo

Sieci komputerowe Warstwa aplikacji

Sieci komputerowe Warstwa aplikacji Sieci komputerowe Warstwa aplikacji 2012-05-24 Sieci komputerowe Warstwa aplikacji dr inż. Maciej Piechowiak 1 Wprowadzenie warstwa zapewniająca interfejs pomiędzy aplikacjami używanymi do komunikacji,

Bardziej szczegółowo

Funkcjonalność ochrony antywirusowej w urządzeniach UTM oraz specjalizowanych rozwiązaniach zabezpieczeń AV

Funkcjonalność ochrony antywirusowej w urządzeniach UTM oraz specjalizowanych rozwiązaniach zabezpieczeń AV Funkcjonalność ochrony antywirusowej w urządzeniach UTM oraz specjalizowanych rozwiązaniach zabezpieczeń AV Produkty zabezpieczeń typu UTM (ang. unified threat management) to urządzenia, w których zawarte

Bardziej szczegółowo

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca Uwierzytelnianie w PHP 01 Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca stron internetowych, jest identyfikacja i uwierzytelnienie uprzywilejowanego użytkownika. Od zaprojektowania

Bardziej szczegółowo

SIP Studia Podyplomowe Ćwiczenie laboratoryjne Instrukcja

SIP Studia Podyplomowe Ćwiczenie laboratoryjne Instrukcja SIP Studia Podyplomowe Ćwiczenie laboratoryjne Instrukcja Instytut Telekomunikacji Wydział Elektroniki i Technik Informacyjnych Politechnika Warszawska, marzec 2015 Wprowadzenie Ćwiczenie jest wykonywane

Bardziej szczegółowo

Rozkład menu narzędzi

Rozkład menu narzędzi Tylko administrator systemu ma dostęp do wszystkich opcji Narzędzi. Ustawienia urządzenia Ogólne Oszczędzanie energii Inteligentny Uruchamiany pracą Planowany Data i godzina Strefa czasowa (różnica dla

Bardziej szczegółowo

Bezpieczeństwo w M875

Bezpieczeństwo w M875 Bezpieczeństwo w M875 1. Reguły zapory sieciowej Funkcje bezpieczeństwa modułu M875 zawierają Stateful Firewall. Jest to metoda filtrowania i sprawdzania pakietów, która polega na analizie nagłówków pakietów

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Praca w sieci z serwerem

Praca w sieci z serwerem 11 Praca w sieci z serwerem Systemy Windows zostały zaprojektowane do pracy zarówno w sieci równoprawnej, jak i w sieci z serwerem. Sieć klient-serwer oznacza podłączenie pojedynczego użytkownika z pojedynczej

Bardziej szczegółowo

Telnet. Telnet jest najstarszą i najbardziej elementarną usługą internetową.

Telnet. Telnet jest najstarszą i najbardziej elementarną usługą internetową. Telnet Telnet jest najstarszą i najbardziej elementarną usługą internetową. Telnet standard protokołu komunikacyjnego używanego w sieciach komputerowych do obsługi odległego terminala w architekturze klient-serwer.

Bardziej szczegółowo

LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl)

LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl) Wydział Elektroniki i Telekomunikacji POLITECHNIKA POZNAŃSKA fax: (+48 61) 665 25 72 ul. Piotrowo 3a, 60-965 Poznań tel: (+48 61) 665 22 93 LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl) Wireshark

Bardziej szczegółowo

System zarządzania i monitoringu

System zarządzania i monitoringu Załącznik nr 12 do Opisu przedmiotu zamówienia System zarządzania i monitoringu System zarządzania i monitoringu powinien być zbudowany z odrębnych, dedykowanych modułów oprogramowania, monitorujących:

Bardziej szczegółowo

Instrukcja instalacji Asystenta Hotline

Instrukcja instalacji Asystenta Hotline SoftVig Systemy Informatyczne Sp. z o.o. Instrukcja instalacji Asystenta Hotline Ver. 3.5 2012-06-19 2 Instrukcja obsługi programu Asystent Hotline Zawartość 1 INSTALACJA PROGRAMU 3 1.1 WARUNKI KONIECZNE

Bardziej szczegółowo