Laboratorium podstaw sieci komputerowych Zadanie 3

150875 Grzegorz Graczyk numer indeksu imi i nazwisko 151021 Paweł Tarasiuk numer indeksu imi i nazwisko Data 2010-03-03 Kierunek Informatyka Rok akademicki 2009/10 Semestr 4 Grupa dziekańska 2 Grupa laboratoryjna 15 Laboratorium podstaw sieci komputerowych Zadanie 3

Część teoretyczna Protokoły POP3, IMAP, SMTP, komunikacja klient-serwer, podstawowe komendy i odpowiedzi. Protokół POP3 (Post Office Protocol v3) powstał z myślą o użytkownikach, którzy mają ograniczony dostęp do Internetu, tylko co pewien czas. Jeżeli ktoś łączy się z siecią tylko na chwilę, to poczta nie może dotrzeć do niego protokołem SMTP - gdyż użytkownik musiałby być wówczas dostępny w momencie wysyłania wiadomości. Aby uniknąć takich problemów, w sieci istnieją specjalne serwery, które przez SMTP odbierają przychodzącą pocztę i ustawiają ją w kolejce, aby następnie za pomocą protokołu POP3 przekazać wiadomości do użytkownika. Protokół POP3 nie jest jednak idealny. Najistotniejsze jego ograniczenia to: Połączenie trwa tylko podczas pobierania poczty przez użytkownika i nie może ono pozostać uśpione. Wiadomości z jednej skrzynki wiadomości może pobierać tylko jeden użytkownik naraz. Każdy list musi być pobierany razem z załącznikami i nie jest możliwe selektywne wybieranie ani pomijanie jego części istnieje w tej kwestii jedynie komenda top, która jest bardzo ograniczona, gdyż pozwala jedynie określić przesyłaną liczbę linii od początku wiadomości. Wszystkie odbierane listy trafiają do jednej skrzynki (nie może być ich więcej niż jedna). Serwer POP3 nie udostępnia możliwości przeszukiwania znajdujących się w kolejce listów. Protokół POP3 jest protokołem tekstowym, czyli w odróżnieniu od protokołów binarnych, przesyłane dane są są czytelne dla człowieka. Komunikacja odbywa się za pomocą czteroliterowych komend, po których następują argumenty o długościach od 0 do 40 znaków. Komendy USER Wprowadzanie nazwy użytkownika. PASS Wprowadzanie hasła. LIST Odczyt listy wiadomości w kolejce. RETR Pobranie wybranej wiadomości DELE Usunięcie wybranej wiadomości. QUIT Zakończenie połączenia. STAT Odczyt statystyk. NOOP Utrzymanie aktywności połączenia bez wykonywania akcji. RSET Cofnięcie usunięć. Odpowiedzi serwera rozpoczynają się od +OK lub -ERR, co oznacza odpowiednio wykonanie polecenia zakończone powodzeniem bądź błąd. Protokół IMAP (Internet Message Access Protocol) jest protokołem warstwy aplikacji, który tak samo jak POP służy do zarządzania pocztą znajdującą się na serwerze oraz zarządzania PSK: Grzegorz Graczyk i Paweł Tarasiuk 2 / 15

nią, lecz jest znacznie bardziej rozbudowany niż POP i daje bardziej zaawansowane możliwości. Protokół IMAP domyślnie realizowany jest na 143 porcie TCP. Obecnie można spotkać kilka standardów różnych wersji protokołu IMAP: IMAP2, IMAP3 oraz IMAP4rev1. Połączenie IMAP składa się z akcji odpowiedzialnych za ustalenie połączenia między klientem a serwerem, przesłania powitania ze strony serwera, oraz interakcji między klientem a serwerem. Seria komend i odpowiedzi wymienianych między serwerem a klientem ma postać linii tekstu zakończonych znakiem CRLF. Serwer jest wyposażony w mechanizmy informowania klienta o powodzeniu lub porażce wykonania poszczególnych poleceń. Jeżeli wiele komend jest wykonywanych jednocześnie, serwer w odpowiedzi wysyła znacznik komendy, który jednoznacznie określa do jakiej operacji odnosi się odpowiedź. Istnieją 3 możliwe odpowiedzi serwera: OK (sukces), NO (porażka) oraz BAD (błąd protokołu, czyli niezrozumienie polecenia związane z błędem składni, często oznaczającym zastosowanie złej wersji protokołu). Każda błędna komenda wydana przez klienta jest odrzucana przez serwer. Klient zaś otrzymuje linie odpowiedzi pochodzące od serwera i na bieżąco je analizuje. Klient musi podjąć odpowiednie działania w zależności od tego, czy pierwszym znacznikiem wysłanym w odpowiedzi przez serwer był znak * czy +. Klient musi być przygotowany na odebranie każdej odpowiedzi ze strony serwera przez cały czas, włączając w to dane o które wcale nie wysyłano żądania. Aby zminimalizować zużycie połączenia i obciążenie serwerów, dane wysyłane przez serwer muszą być spamiętywane przez klienta, aby możliwe było wyszukanie potrzebnych informacji w pobranych już danych zamiast wysyłania kolejnych zapytań do serwera. Podstawowe komendy protokołu IMAP, wspólne dla wielu wersji protokołu, to: NOOP Brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę - wynikiem są tylko odpowiedzi OK (zrozumiano, nic się nie stało) lub BAD (złe wywołanie lub istnienie argumentów, których ma być 0). Komenda ta nie robi nic, może być wydana w dowolnym stanie sesji. LOGOUT Brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę (OK lub BAD). Za pomocą tej komendy klient informuje serwer o zakończeniu swoich działań - serwer musi wtedy wysłać mu w odpowiedzi BYE (pożegnać się kulturalnie i sympatycznie) przed wysłaniem odpowiedzi OK. Natychmiast po tym następuje zamknięcie połączenia. Komenda ta może zostać wydana w dowolnym stanie sesji. STARTTLS Kolejna komenda pozbawiona argumentów oraz specyficznych odpowiedzi (wynikiem jest OK lub BAD). Komenda ta powoduje rozpoczęcie negocjacji TLS przez serwer z klientem - oczywiście celem korzystania z TLS jest szyfrowanie połączenia oraz potwierdzenie autentyczności serwera. AUTHENTICATE Jako argument podawana jest nazwa mechanizmu autoryzacji, który ma zostać wykorzystany. Komenda może zwrócić odpowiedzi: OK (pomyślna autentykacja), NO (serwer nie obsługuje mechanizmu autentykacji o podanej nazwie) lub BAD (złe wywołanie lub nieodpowiednie argumenty, np. liczniejsze niż jeden). LOGIN Argumentami tej komendy są dwa łańcuchy: nazwa użytkownika oraz hasło. Odpowiedzi na tą komendę są tylko standardowe: OK (wykonanie komendy), NO (logowanie się nie udało - złe hasło bądź nieistniejący login) lub BAD (nieprawidłowe wywołanie lub nieodpowiednie argumenty). SELECT Jako argument podawana jest nazwa skrzynki, na której mają być wykonywane dalsze komendy. Serwer w odpowiedzi zwraca dane dotyczące skrzynki m. in. liczbę znajdujących się w niej wiadomości, liczbę nowych wiadomości oraz liczbę nieprzeczytanych PSK: Grzegorz Graczyk i Paweł Tarasiuk 3 / 15

wiadomości. Wszystkie te informacje poprzedzone są znacznikiem *. Standardowo, serwer zwraca też odpowiedzi OK (pomyślne wykonanie polecenia, dalsza praca na wskazanej skrzynce), NO (brak skrzynki o podanej nazwie) lub BAD (błąd składni). EXAMINE Komenda różniąca się od SELECT jedynie tym, że po jej wykonaniu wiadomości nie tracą flagi /Recent. CREATE Jako argument podawana jest nazwa skrzynki, która ma zostać utworzona jako nowa. Możliwe odpowiedzi są typowe: OK (udane wykonanie komendy), NO (nie można stworzyć skrzynki o podanej nazwie, np. ze względu na konflikt nazw z istniejącą skrzynką) albo BAD (nieprawidłowa składnia). DELETE Jedynym argumentem jest nazwa skrzynki, która ma zostać permanentnie usunięta. Nie ma żadnych specyficznych odpowiedzi na ta komendę - możliwymi wynikami są: OK (wykonanie komendy), NO (nie można usunąć skrzynki o podanej nazwie) lub BAD (złe wywołanie lub nieodpowiednie argumenty komendy). RENAME Argumentami są nazwa istniejącej skrzynki, oraz nowa nazwa, którą ma otrzymać ta skrzynka po wykonaniu komendy. Odpowiedzi na tą komendę są typowe - wynikami są tylko odpowiedzi OK (wykonanie komendy), NO (nie można zmienić nazwy skrzynki) albo BAD (złe wywołanie lub nieodpowiednie argumenty). STATUS Komenda służy do uzyskiwania informacji o statusie wybranej skrzynki. Jako odpowiedź serwer zwraca status skrzynki oraz standardowe odpowiedzi: OK (wykonanie komendy, podanie statusu), NO (brak statusu dla skrzynki o podanej nazwie) lub BAD (złe wywołanie lub nieodpowiednie argumenty). CHECK Brak argumentów, odpowiedzi tylko w postaci OK bądź BAD. Jest to synonim NOOP, sprawdza po prostu, czy serwer odpowie cokolwiek. CLOSE Brak argumentów ani specyficznych odpowiedzi. Komenda ta usuwa permanentnie wszystkie wiadomości które mają ustawioną flagę /Deleted i powraca do stanu autetykacji ze stanu wyboru (przestaje obowiązywać SELECT ). EXPUNGE Bez argumentów; komenda natychmiast usuwa wszystkie wiadomości które oznaczone są flagą /Deleted. SEARCH wyszukuje w skrzynce wiadomości spełniające zadane jako argument kryteria. Jako odpowiedź serwer zwraca wiadomości oraz odpowiedz OK (pozytywne wykonanie komendy), NO (brak wiadomości spełniających kryteria) albo BAD (błąd składni). FETCH pobiera dane związane ze wskazaną jako argument wiadomością ze skrzynki. Ponadto, każda wiadomość na serwerze IMAP posiada flagi i atrybuty, które stanowią dodatkowe informacje na temat jej stanu. Flagi można rozróżnić jako stałe bądź istniejące tylko podczas pojedynczej sesji. Każda flaga zaczyna się od znaku \. Najistotniejsze flagi i atrybuty to: \Seen Wiadomość została przeczytana. \Answered Wysłano już odpowiedź na tą wiadomość. \Flagged Wiadomość oznaczona warta szczególnej uwagi. PSK: Grzegorz Graczyk i Paweł Tarasiuk 4 / 15

\Deleted Wiadomość skasowana - jej faktyczne usunięcie zostanie wykonane przy poleceniu EXPUNGE bądź CLOSE. \Draft Szkic wiadomości wymagający dokończenia. \Recent Świeża wiadomość, wyświetlona po raz pierwszy w danej sesji; w skrzynce do której trafiła nie wykonywano nawet SELECT (za to możliwe, że jakaś aplikacja kliencka podglądała zawartość skrzynki za pomocą EXAMINE). Atrybut wewnętrznej daty wiadomości (Internal Date Message Attribute) Data i czas odebrania wiadomości przez serwer IMAP. Atrybut rozmiaru wiadomości (Size Message Attribute) Rozmiar wiadomości wyrażony w bajtach. Atrybut struktury koperty wiadomości (Envelope Structure Message Attribute) Przetworzona reprezentacja nagłówka wiadomości. Atrybut struktury ciała wiadomości ( Body Structure Message Attribute ) Przetworzona reprezentacja ciała wiadomości (w tym MIME). Protokół SMTP (Simple Mail Transfer Protocol) jest protokołem tekstowym, w którym określa się co najmniej jednego odbiorcę wiadomości (w większości przypadków weryfikowane jest jego istnienie), a następnie przekazuje treść wiadomości. Demon SMTP działa najczęściej na porcie 25 (TCP). Działanie SMTP można opisać za pomocą następującego schematu: w wyniku zapytania wysłanego przez nadawcę, ustanowione zostaje połączenie, będące dwustronnym kanałem transmisyjnym z odbiorcą. Odbiorca może być miejscem docelowym dostarczenia poczty lub jedynie pośrednim węzłem w komunikacji. Pomiędzy nadawcą a odbiorcą wymieniane są komendy oraz odpowiedzi na nie. Wraz z otwarciem połączenia, nadawca wysyła komendę MAIL, która jednoznacznie identyfikuje wysyłającego pocztę. Jeżeli odbiorca może zaakceptować wysłane dane odsyła odpowiedź OK. Po odebraniu pozytywnej odpowiedzi nadawca wysyła polecenie RCTP, identyfikujące adresata wiadomości. Jeżeli odbiorca może przyjąć żądanego adresata (czyli: jest odpowiednim serwerem bądź węzłem pośredniczącym), zwraca odpowiedź OK, jeżeli natomiast nie może przyjąć danego adresata, przesyła informację o problemie, aczkolwiek nie kończy transakcji, gdyż nadawca i odbiorca mogą negocjować kolejnych adresatów wiadomości. Gdy uzgodnieni zostaną wszyscy adresaci poczty, nadawca wysyła dane które zawiera wiadomość, dane zakańczane są specjalną sekwencją znaków. Jednym z ograniczeń pierwotnego SMTP jest brak mechanizmu weryfikacji nadawcy, co ułatwia rozpowszechnianie niepożądanych treści poprzez pocztę elektroniczną (wirusy, spam). Aby temu zaradzić stworzono, rozszerzenie SMTP AUTH, które jednak stanowi jedynie częściowe rozwiązanie problemu gdyż ogranicza wykorzystanie serwera wymagającego autoryzacji do zwielokrotniania poczty. Nadal nie istnieje metoda, dzięki której odbiorca autoryzowałby nadawcę nadawca może symulować komunikaty wysyłane zazwyczaj przez serwer i wysłać dowolny komunikat do dowolnego odbiorcy. Także protokół SMTP także oparty jest o tekstowe komendy, w czym najistotniejsze to: HELO serwer Otwarcie transakcji z podanym serwerem. MAIL From: Początek tworzenia nowej wiadomości - ustalenie nadawcy. PSK: Grzegorz Graczyk i Paweł Tarasiuk 5 / 15

RCPT To: Ustalenie adresata wiadomości. DATA Treść wiadomości. RSET Rezygnacja z tworzonej wiadomości. NOOP Polecenie puste. QUIT Zakończenie transakcji. VRFY Weryfikacja użytkownika na danym serwerze. Protokół NNTP (Usenet). Protokół NNTP (Network News Transfer Protocol, związany z sieciami Usenet) to inaczej sieciowy protokół przesyłania wiadomości. Jest to protokół oraz usługa przeznaczone do ogłaszania, przesyłania i pozyskiwania wiadomości w ramach grup dyskusyjnych sieci Usenet. Sieć tą można przyrównać do elektronicznej tablicy ogłoszeniowej o rozmiarach dostosowanych do Internetu, zbudowanej z grup dyskusyjnych (czyli forów) na których omawiane są różnorodne tematy. Protokół NNTP korzysta z portu 119 (TCP). Komendy protokołu NNTP są następujące: ARTICLE message id Komenda wyświetla nagłówek, po nim - pustą linię oddzielającą, aż wreszcie - tekst wiadomości o podanym identyfikatorze. GROUP ggg Wybiera grupę dyskusyjną o nazwie ggg. Jeżeli komenda zostaje zrealizowana z powodzeniem, serwer zwraca numer pierwszego oraz ostatniego artykułu w grupie dyskusyjnej, a także o liczbę wszystkich artykułów w grupie. HELP Prośba o listę dostępnych komend, obsługiwanych przez serwer. IHAVE message id Komenda informuje serwer, że klient posiada artykuł o podanym numerze. Jeżeli serwer będzie musiał pobrać artykuł, wyśle klientowi szczegółowe instrukcje jak to ma zrobić. LAST Pytanie o numer ostatniego artykułu w bieżącej grupie. LIST Pytanie o listę istniejących grup dyskusyjnych na danym serwerze. NEWGROUPS date time [GMT] Prośba o listę grup dyskusyjnych utworzonych po wyspecyfikowanym w argumentach czasie. NEWNEWS newsgroups date time [GMT] Prośba o listę identyfikatorów wiadomości utworzonych po wyspecyfikowanym w argumentach czasie. NEXT Pytanie o ID kolejnego artykułu, w odniesieniu do wskaźnika na ostatnio czytany artykuł. POST Wysyłanie wiadomości. Jeżeli jest ono możliwe, serwer wysyła odpowiedź 340, jeżeli nie - 440. Koniec tekstu wiadomości jest oznaczony poprzez linię zawierającą pojedynczy znak.. Zasady formatowania danych są takie same jak w przypadku SMTP. QUIT Prośba o zakończenie połączenia z serwerem. PSK: Grzegorz Graczyk i Paweł Tarasiuk 6 / 15

Dyskusje sieci USENET podzielone są na dziesiątki tysięcy grup, które według swojej kategorii zorganizowane są w postaci hierarchicznej. Adresy grup budowane są w odwrotnej kolejności niż adresy domen (od ogółu do szczegółu). Ściśle określone zostały jednak hierarchie wysokiego poziomu root. Hierarchie wysokiego poziomu to: comp Komputery. misc Różne. news Administracja siecią Usenet. rec Rekreacja. sci Nauka. soc Społeczeństwo. talk Dyskusje ogólne. Inne popularne kategorie to np. alt i free grupy liberalne, w których każdy może założyć własną dyskusję. Istnieją także grupy krajowe, o nazwach takich samych jak przyporządkowane odpowiednim krajom domeny TLD. Pełna nazwa grupy jest połączeniem informacji o kategoriach, np. pl.sci.lesnictwo albo pl.comp.os.linux.programowanie. Skrzynki pocztowe, najczęściej używane parametry, adresy, aliasy. Adres skrzynki pocztowej składa się z nazwy skrzynki na danym serwerze, znaku separatora @, oraz nazwy samego serwera. Nazwa serwera może być np. adresem IP zapisanym jako cztery liczby dziesiętne przedzielone kropkami, lecz zazwyczaj (Ze względu na wygodę oraz możliwą zmienność adresów IP) w postaci nazwy domeny, która jest powiązana z pewnym serwerem poczty za pomocą rekordu MX w systemie DNS. W przypadku braku rekordu MX, możliwe jest ustalanie adresu serwera na podstawie rekordów A oraz AAAA, lecz w przypadku dużych serwerów stanowiłoby złą praktykę. Aliasy to po prostu alternatywne identyfikatory tej samej skrzynki pocztowej np. rzecznikprasowy@przykladowafirma.pl oraz panisprzataczka@przykladowafirma.pl mogą wskazywać na tą samą skrzynkę. Format przesyłki pocztowej, separator nagłówka i treści, nazwy i znaczenie podstawowych znaczników (pól) nagłówka. Wiadomość zaczyna się od nagłówka, który sam w sobie nie zawiera pustych linii. Po nagłówku następuje pusta linia będąca separatorem - oznacza ona, że skończył się nagłówek, a po niej następuje ciało wiadomości. Nagłówek zawiera następujące informacje: From Od kogo otrzymano list (po tym akurat From nie ma dwukropka). From: Adres nadawcy (tutaj dla odmiany jest dwukropek). Received: Punkty pośrednie (adresy węzłów przez które dana wiadomość była przesyłana zanim trafiła do danego odbiorcy). PSK: Grzegorz Graczyk i Paweł Tarasiuk 7 / 15

To: Adres skrzynki adresata wiadomości. Subject: Temat wiadomości (wysyłanie wiadomości bez tematu jest sprzeczne z netykietą). Date: Data nadania przesyłki. Message ID: Numer identyfikacyjny przesyłki (każda przesyłka powinna mieć unikalny numer identyfikacyjny). Reply To: Adres, na który należy przesłać odpowiedź na daną wiadomość. Cc: Adres, na który została wysłana kopia listu. Wykorzystywane są także następujące nagłówki pomocnicze: Mime Version: 1.0 Dotyczy wszystkich przesyłek. Content Type: Rodzaj zawartości przesyłki. Content Transfer Encoding: Zastosowany sposób kodowania znaków. Content Length: Długość przesyłki. Content Description: Opis zawartości przesyłki. Nagłówki dodawane są do przesyłek automatycznie przez program przygotowujący list, a następnie są uzupełniane przez wszystkie programy uczestniczące w jego przesyłaniu. Załączniki, kodowanie, MIME Załączniki to po prostu pliki dodawane do wiadomości pocztowej przesyłane, wraz z tekstem wiadomości do odbiorcy. Natomiast kodowanie znaków to sposób, w jaki zapisane są znaki w przesyłanej wiadomości. Często spotykane kodowania to: zachodnioeuropejskie (ISO 8859 1) Zawiera znaki języków Europy Zachodniej, np. niemieckiego i francuskiego. środkowoeuropejskie (ISO 8859 2) Zawiera znaki języków Europy Środkowej i Wschodniej, w tym języka polskiego. Unicode (UTF 8) Zawiera znaki wszystkich języków na świecie, kosztem tego, że niektóre znaki ważą więcej niż jeden bajt. MIME (Multipurpose Internet Mail Extensions) można przetłumaczyć na wielofunkcyjne rozszerzenie poczty w Internecie jest to standard pozwalający przesyłać w sieci Internet dane wielu różnych typów (teksty, dokumenty sformatowane, grafikę, zdjęcia, dźwięki, muzykę, filmy, skompresowane archiwa z plikami) za pomocą standardowych narzędzi, takich jak poczta, grupy dyskusyjne bądź strony WWW. Wbrew swojej nazwie, ściśle związanej z pocztą, zastosowanie MIME znacznie wykracza poza przesyłanie plików pocztą elektroniczną. Wszystkie opisane w poprzedniej sekcji sprawozdania nagłówki pomocnicze odnoszą się właśnie do informacji o typach MIME. Standard ten rozwinął się na tyle, że wprowadzono go także do innych systemów przesyłania danych i obecnie jest to niekwestionowany standard we wszystkich usługach Internetu, których podstawowym zadaniem jest przesyłanie tekstu. PSK: Grzegorz Graczyk i Paweł Tarasiuk 8 / 15

Standardowo dane przesyłane w sieci w formie tekstowej pozwalają korzystać z 7-bitowych znaków ASCII - dzięki MIME możliwa jest konwersja danych 8-bitowych do postaci tekstu (oczywiście - kosztem zwiększenia rozmiaru), a następnie - odczytanie ich z powrotem. Podanie odpowiedniego typu MIME pozwala ponadto stwierdzić, w jakim formacie zostały zapisane dane. Opisanie odpowiedniego typu MIME jest także konieczne w wypadku, gdy ciało wiadomości jest wysyłane w wielu częściach. Transport wiadomości pocztowej, pocztowe listy dystrybucyjne, bramy pocztowe. Listy dystrybucyjne to po prostu listy adresów pocztowych służące do masowego rozsyłania wiadomości do wszystkich użytkowników zapisanych na daną listę. Aby wysłać taka wiadomość, wysyłamy jej treść do serwera udostępniającego taką usługę (czyli przeważnie na adres będący identyfikatorem danej grupy mailingowej), który dalej rozsyła wiadomości do skrzynek użytkowników subskrybujących dana listę. Bramy pocztowe natomiast są komputerami, których głównym zadaniem jest przetwarzanie poczty. Są one najczęściej wykorzystywane w sytuacji gdy lista adresatów, do których ma trafić kopia naszej wiadomości jest szczególnie długa. W momencie wysyłania takiej wiadomości nasz klient nie próbuje samodzielnie przekazywać wiadomości, lecz przesyła ją do bramy, która powoli rozsyła wiadomości do kolejnych adresatów. Bezpieczeństwo usług pocztowych, szyfrowanie połączeń, bezpieczne uwierzytelnianie, szyfrowanie zawartości, użycie kluczy niesymetrycznych, PGP, certyfikaty SSL, podpis elektroniczny. W celu zapewnienie funkcjonalności które mają zostać omówione w niniejszej sekcji, wykorzystywana jest kryptografia z użyciem kluczy niesymetrycznych. Kryptografia niesymetryczna oznacza generowanie par elektronicznych podpisów prywatnego i publicznego. W celu uzyskania uwierzytelnienia nadawcy (potwierdzenia jego tożsamości), rola kluczy zostaje odwrócona i wiadomość zostaje zakodowana przy użyciu klucza prywatnego. Adresat, dysponując kluczem publicznym nadawcy, może ją rozszyfrować i mieć pewność, że wiadomość pochodzi od tej właśnie osoby gdyż, tylko ona dysponuje pozwalającym to osiągnąć kluczem prywatnym. Szeroko rozpowszechnionym jest kryptosystemem (tzn. systemem szyfrującym oraz deszyfrującym) jest PGP (Pretty Good Privacy jak nazwa wskazuje, jest ono całkiem niezłe) autorstwa Phila Zimmermanna. System ten wykorzystuje ideę kryptografii niesymetrycznej oraz kluczy publicznych. Podstawowym zastosowaniem PGP jest szyfrowanie poczty elektronicznej, transmitowanej przez kanały nie dające same z siebie gwarancji poufności ani integralności poczty. Przez poufność rozumiana jest niemożliwość podglądania zawartości listów przez osoby trzecie. Integralność natomiast oznacza niemożność wprowadzania przez osoby trzecie żadnych modyfikacji do treści listu. Kryptografia niesymetryczna bardzo usprawnia możliwości szyfrowania. Szyfr tradycyjny wymagał użycia tego samego klucza do szyfrowania i odszyfrowywania. Problemem było to, że klucz ten zanim został użyty, musiał być wcześniej uzgodniony przez porozumiewające się strony, i to z użyciem kanału bezpiecznego (zapewniającego poufność i integralność) gdyż w przeciwnym razie istniałoby ryzyko przechwycenia klucza przez osoby trzecie, co dałoby tym osobom możliwość zarówno odczytywania szyfrowanych komunikatów, jak i ich podrabiania (fałszowania). Przy kryptografii niesymetrycznej tworzymy natomiast pary kluczy: jeden z nich służy do zaszyfrowania listu, drugi do odszyfrowania. Znajomość klucza szyfrowania nie wystarczy PSK: Grzegorz Graczyk i Paweł Tarasiuk 9 / 15

do oczytania listu, ani do odtworzenia klucza pozwalającego go odczytać (teoretycznie możliwe powinny być tylko ataki brutalne, których czas wykonania na istniejącym sprzęcie komputerowym powinien wynosić co najmniej stulecia). Zatem klucz służący do odczytywania wiadomości musi pozostać sekretem swego właściciela (stąd nazwa klucz prywatny ). Klucz do szyfrowania powinien natomiast być udostępniony ogółowi dlatego nazwany jest kluczem publicznym każdy kto go zna może wysyłać wiadomości czytelne jedynie dla nadawcy, których treść można poznać tylko za pomocą klucza prywatnego. W zaszyfrowaną wiadomość nie da się też ingerować - bez znajomości klucza prywatnego, próba wprowadzenia w niej zmian zamieni ją tylko w śmieci (czyli do adresata trafi treść oryginalna, albo żadna). Zastosowany w PGP algorytm szyfrowania kluczem publicznym to RSA (od nazwisk twórców - Rivest Shamir Adleman). Algorytm ten jest w USA opatentowany, a ponadto podlega restrykcjom eksportowym ITAR i nie może być używany w programach wywożonych z USA. Jednakże, poza USA legalnie stosuje się algorytm który opracował Stale Schumacher, tworząc niezależną od firmy RSA implementację. Obie wersje są wzajemnie zgodne. PGP nie szyfruje całego dokumentu (np. listu) z użyciem algorytmu RSA ponieważ jest on dość powolny, trwałoby to bardzo długo (Szczególnie w czasach, gdy go wynaleziono i moce obliczeniowe komputerów były słabsze niż obecnie). Zamiast tego, PGP szyfruje z użyciem RSA pewną wygenerowaną losowo liczbę 128 bitową, która następnie jest używana jako klucz szyfrowania właściwego dokumentu (np. listu) tradycyjnym algorytmem IDEA. Przy deszyfracji, PGP odszyfrowuje klucz IDEA z użyciem prywatnego klucza RSA odbiorcy, a następnie kluczem IDEA odszyfrowuje list. W zasadzie zatem PGP jest połączeniem tradycyjnego kryptosystemu bazującego na kluczu przekazanym kanałem bezpiecznym (innym dla każdej wiadomości), i kryptosystemu opartego o metodę klucza publicznego, (który zapewnia bezpieczny kanał). SSL (Secure Socket Layer) to opracowany przez firmę Netscape sposób przesyłania danych, który obecnie stał się standardem w sieci Internet. Głównym powodem stworzenia SSL był fakt, iż dane przesyłane między klientem i serwerem, przesyłane są w sposób jawny, czyli po prostu, łatwym do przechwycenia i przeczytania tekstem. Natomiast gdy stosowany jest SSL, wszystkie informacje przesyłane między klientem a serwerem są zaszyfrowane. Warstwa SSL realizuje szyfrowanie, uwierzytelnienie serwera (ewentualnie również użytkownika) i zapewnienie integralności oraz poufności przesyłanych informacji. W momencie nawiązania połączenia z serwerem następuje ustalenie algorytmów oraz kluczy szyfrujących, stosowanych następnie przy przekazywaniu danych między klientem a serwerem. Na początku nawiązywania połączenia SSL klient i serwer wymieniają się tzw.: certyfikatami SSL. Certyfikat jest odpowiednikiem dokumentu tożsamości dla serwera oraz dla klienta. Certyfikat zawiera następujące składniki: 1. Nazwę właściciela certyfikatu. 2. Nazwę wydawcy certyfikatu (jest do tego upoważnionych kilka organizacji na świecie). 3. Publiczny klucz właściciela dla algorytm asymetrycznego. 4. Cyfrowy podpis wystawcy certyfikatu (np. Verisign). 5. Okres ważności. 6. Numer seryjny (tzw. fingerprint). Wystawianiem i obsługą certyfikatów SSL zajmują się niezależne instytucje certyfikujące, nazywane w skrócie CA (Certyfing Authorities). Na całym świecie jest tylko kilka tego typu instytucji i z założenia wszystkie są godne zaufania. PSK: Grzegorz Graczyk i Paweł Tarasiuk 10 / 15

Certyfikat rejestrowany jest tylko na konkretną nazwę domeny, np. www.przykladowafirma.pl i zawiera dane o jego właścicielu. Istnieją również certyfikaty typu wildcard, które można użyć na dowolną ilość subdomen (np. www.przykladowafirma.pl, sklep.przykladowafirma.pl, poczta.przykladowafirma.pl). Wszystkie wystawiane certyfikaty zapewniają co najmniej 128 bitowe szyfrowanie, które jest w tej chwili najczęściej stosowane m.in. przez instytucje finansowe. Smutnym zjawiskiem jest częsta ignorancja administratorów popularnych serwerów wobec upływających okresów ważności certyfikatów - wyrobienie sobie nowego certyfikatu kosztuje, lecz jest konieczne, aby uniknąć ryzyka podrobienia certyfikatu metodą brutalną (które jest możliwe, jest po prostu kwestią czasu - bezpieczeństwo opiera się tylko na tym, że jest to czas bardzo długi). Np. serwer SVN wykorzystywany m. in. przez studentów Politechniki Łódzkiej - https://serce.ics.p.lodz.pl/ - posiada certyfikat, który wygasł w październiku. Szyfrowanie wiadomości za pomocą własnego klucza prywatnego pozwala potwierdzić tożsamość nadawcy. Szczególnym tego przypadkiem jest podpis elektroniczny epodpis czyli dane w postaci elektronicznej, które w połączeniu z innymi danymi, do których zostały dołączone lub z którymi są logicznie powiązane, służą do identyfikacji osoby składającej podpis elektroniczny. Podpisem elektronicznym możemy oznaczać pocztę e mail lub inne dokumenty cyfrowe. Ponadto, dzięki posługiwaniu się podpisem elektronicznym przesyłane dokumenty elektroniczne docierają do adresatów w stanie nienaruszonym (podpis stanowi połączenie danych kontrolnych z naszym kluczem prywatnym). Każda, nawet przypadkowa, zmiana w treści przesyłki jest dzięki temu sygnalizowana przez komputer odbiorcy. W połowie sierpnia 2002 zaczęła działać ustawa o podpisie elektronicznym. Podpisana 11 października 2001 przez prezydenta RP i opublikowana w Dzienniku Ustaw 15 listopada 2001 r. z mocy Art. 59 ust. 1, ustawa ma następujące brzmienie: "Podpis elektroniczny -- dane w postaci elektronicznej, które wraz z innymi danymi, do których zostały dołączone lub z którymi są logicznie powiązane, służą do identyfikacji osoby składającej podpis elektroniczny" (Art. 3 ust. 1) Oraz: "Bezpieczny podpis elektroniczny to podpis elektroniczny, który: a) jest przyporządkowany wyłącznie do osoby składającej ten podpis, b) jest sporządzany za pomocą podlegających wyłącznej kontroli osoby składającej podpis elektroniczny bezpiecznych urządzeń służących do składania podpisu elektronicznego i danych służących do składania podpisu elektronicznego, c) jest powiązany z danymi, do których został dołączony, w taki sposób, że jakakolwiek późniejsza zmiana tych danych jest rozpoznawalna" (Art. 3 ust. 2). Czy jednak mój komputer z możliwością generowania liczb pseudolosowych przez procesor stanowi bezpieczne urządzenie pod moją kontrolą, za pomocą którego mógłbym sobie sporządzić podpis elektroniczny? Mogę stworzyć na własny użytek parę kluczy PGP/GPG, które, odpowiednio użyte, pozwolą spełnić warunki ustawy. Jednakże, wiele firm oferuje odpłatne tworzenie takich podpisów, oraz podpis stworzony przez taką firmę (można polemizować, czy bezpieczniejszy) będzie uznawany przez wszystkie urzędy, w przeciwieństwie do podpisu domowej roboty. Uzależnienie od kliku dostawców oprogramowania do składania e-podpisu powoduje natomiast wykluczenie technologiczne niektórych użytkowników - gdyż oprogramowanie przygotowywane przez tych dostawców tworzone jest na ograniczoną (praktycznie do jednej) liczbę platform. PSK: Grzegorz Graczyk i Paweł Tarasiuk 11 / 15

Netykieta, tzw. spam, tzw. czarne listy. Netykieta to savoir-vivre obowiązujący w sieci Internet. Za słownikiem języka polskiego sjp.pl, netykieta to zbiór zasad przyzwoitego zachowania w Internecie, swoista etykieta obowiązująca w sieci. Za pierwszy kompleksowy zbiór zasad korzystania z Internetu uchodzi opracowanie Arlene H. Rinaldi z Florida Atlantic University we wstępie do swojej netykiety pisze ona, iż podstawowa dla użytkownika sieci jest jego świadomość posiadania dostępu do światowych zasobów wiedzy w postaci serwisów, stron www, systemów i ludzi. Każdy użytkownik jest odpowiedzialny za swoje działania oraz czyny w sieci. Internet nie jest jednolitą siecią, lecz składa się z tysięcy sieci połączonych ze sobą. Sieci te różnią się od siebie, co oznacza, że niektóre działania, będące normalnymi procedurami postępowania w jednych sieciach czy systemach, w innych mogą być ograniczone lub wręcz zabronione, gdyż mogą one prowadzić do nadużycia. Spam (często błędnie pisany wielkimi literami, jako SPAM - pomimo że napis składający się z wielkich liter jest zastrzeżonym znakiem towarowym), określany również UCE (Unsolicited Commercial Email - niezamawiane komercyjne wiadomości) lub UBE (Unsolicited Bulk Email - niezamawiane masowe wiadomości) to takie informacje lub przesyłki, których odbiorca sobie nie zażyczył ani wcześniej na nie się nie zgodził. Najczęściej wiadomości te są do niczego niepotrzebne, i wywołują głównie irytację. Jednakże, śladowe ilości adresatów reagują na reklamy otrzymane jako spam. Przy bardzo małych kosztach rozsyłania poczty elektronicznej, spam często okazuje się zatem opłacalną formą reklamy. Mimo że przy okazji mnóstwo ludzi zdenerwuje. Spam powstał w latach 80 i przybywało go wraz z rozwojem Internetu, a obecnie jest już poważnym problemem komunikacyjnym i finansowym nie tylko Internetu, ale ogólnie społeczeństwa informacyjnego. Etymologia słowa spam jest zabawna i godna poświęcenia kilku zdań niniejszego sprawozdania bowiem słowo to pochodzi najprawdopodobniej ze skeczu Monty Pythona i oznaczało mielonkę (ang. spam Shoulder Pork and ham / SPiced ham). W skeczu tym klient, gdy pyta się o menu restauracji, dowiaduje się, że w każdym daniu znajduje się trochę mielonki. Gdy klient chce zamówić coś bez mielonki, specjalna grupa zagłuszaczy w strojach wikingów, zaczyna śpiewać Spam, spam, lovely spam, wonderful spam, zagłuszając normalną rozmowę. Tłumaczenie słowa spam żartobliwie podaje się również jako wyrażenie Stupid Person AdvertiseMent (gdyż istotnie, osoby reagujące na tego typu reklamy stanowią zachętę dla reklamujących się w ten nieuczciwy sposób usługodawców, a w rezultacie - źródło zdenerwowania praktycznie wszystkich użytkowników Internetu). Czarne listy pozwalają ograniczyć nieuczciwe praktyki stosowane wielokrotnie przez tych samych sprawców. W przypadku spamu są to ogólnodostępne listy spamerów (nadawców niechcianych wiadomości). Za pomocą takowych list, można blokować na serwerach pocztowych przychodzące wiadomości. Budzą one jednak wiele kontrowersji, gdyż nadgorliwi administratorzy często przez pomyłkę blokują możliwość wysyłania poczty niewinnym internautom, umieszczając ich adresy na czarnej liście. Zadania praktyczne Skonfigurować program Thunderbird do pracy z własnym kontem pocztowym na serwerze stud.ics.p.lodz.pl lub na dowolnym innym serwerze. Konfiguracja konta mailowego w programie Thunderbird (w wersji 3.0.1) wymaga jedynie podania maila oraz hasła. Program sam odnajduje adres serwerów smtp oraz imap (mail.stud.ics.p.lodz.pl) ostrzegając jednocześnie o niepoprawnym certyfikacie tego pierwszego. Ustawienie POP3 jako protokołu poczty przychodzącej jest możliwe jedynie przy tworzeniu konta. Nie jest wymagana żadna dodatkowa konfiguracja, choć warto poświęcić chwilę na zastanowienie się nad ustawieniami dotyczącymi na przykład kasowania wiadomości z serwera. PSK: Grzegorz Graczyk i Paweł Tarasiuk 12 / 15

Wysłać wiadomości pocztowe a) na nieistniejący serwer pocztowy (nieprawidłowa nazwa DNS), b) do nieistniejącego użytkownika na istniejącym serwerze pocztowym, c) do komputera, który istnieje, ale nie działa na nim serwer poczty. W każdym z przypadków przeanalizować odpowiedzi własnego serwera poczty (ilość prób, odstępy czasowe itp.). We wszystkich 3 przypadkach informacje o błędach pojawiają się jako odebrane maile. Wynika to z kolejkowania maili przeznaczonych do wysłania - nie są wysyłane natychmiast, więc informacja o błędzie nie może przyjść natychmiast. W przypadku A informacja o błędzie pojawia się z pewnym opóźnieniem - wynikającym prawdopodobnie z kilku prób z małymi odstępami czasu. W przypadku B informacja o błędzie pojawia się niemal natychmiast - po 1 próbie połączenie zostanie nawiązane i odpowiedź serwera docelowego zostanie uznana za ostateczną. W przypadku C informacja o błędzie pojawia się z dużym opóźnieniem - w przeciwieństwie do nieistniejącego hosta problemy z nieodpowiadającymi serwerami są dość częste. Odpowiednie odstępy czasowe i ilości prób mogą się różnić w zależności od serwera - podobnie nie każdy serwer opisując błąd udzieli o tych danych informacji. Za pomocą programu windump i/lub ethereal przeanalizować zawartość nagłówków pakietów TCP przesyłanych między klientem a serwerem poczty. W nagłówkach odbieranych maili zawarte są informacje dotyczące między innymi trasy maila nim dotarł do celu, data wysłania. Przykładowe zrzuty są zawarte w późniejszej części sprawozdania. Wysłać i odebrać wiadomość łącząc się z serwerem poczty za pomocą dowolnego klienta protokołu telnet. grzesiu@saturn : $ t e l n e t stud. i c s. p. l o d z. p l 587 Trying 2 1 2. 5 1. 2 2 0. 2 3 1... Connected to stud. i c s. p. l o d z. p l. Escape c h a r a c t e r i s ˆ ]. 220 stud. i c s. p. l o d z. p l ESMTP P o s t f i x e h l o s e r v e r 250 stud. i c s. p. l o d z. p l 250 PIPELINING 250 SIZE 33554432 250 ETRN 250 STARTTLS 250 AUTH LOGIN PLAIN 250 ENHANCEDSTATUSCODES 250 8BITMIME 250 DSN auth l o g i n 334 VXNlcm5hbWU6 ( l o g i n w base64 ) 334 UGFzc3dvcmQ6 ( h a s l o w base64 ) 235 2. 7. 0 A u t h e n t i c a t i o n s u c c e s s f u l mail from : <grzesiu@stud. i c s. p. l o d z. pl> 250 2. 1. 0 Ok r c p t to : <grzesiug44@gmail. com> 250 2. 1. 5 Ok data 354 End data with <CR><LF>.<CR><LF> From : g r z e s i u @ g r z e s i u. i s a geek. net To : grzesiug44@ gmail. com Tresc wiadomosci. 250 2. 0. 0 Ok : queued as 15B4D64E28 PSK: Grzegorz Graczyk i Paweł Tarasiuk 13 / 15

q u i t 221 2. 0. 0 Bye Connection c l o s e d by f o r e i g n host. grzesiu@saturn : $ t e l n e t stud. i c s. p. l o d z. p l 110 Trying 2 1 2. 5 1. 2 2 0. 2 3 1... Connected to stud. i c s. p. l o d z. p l. Escape c h a r a c t e r i s ˆ ]. +OK POP3 stud 2007 e. 1 0 4PLD s e r v e r ready u s e r l o g i n +OK User name accepted, password p l e a s e pass h a s l o +OK Mailbox open, 193 messages s t a t +OK 193 5349080 r e t r 1 +OK 2296 o c t e t s Return Path : <edu@ics. p. l o d z. pl> X O r i g i n a l To : g rzesiu@stud. i c s. p. l o d z. p l Delivered To : g rzesiu@stud. i c s. p. l o d z. p l Received : from l o c a l h o s t ( stud. i c s. p. l o d z. p l [ 1 2 7. 0. 0. 1 ] ) by stud. i c s. p. l o d z. p l ( P o s t f i x ) with ESMTP i d 86F5C651DE for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 4 2 +0100 (CET) X Virus Scanned : amavisd new at i c s. p. l o d z. p l Received : from stud. i c s. p. l o d z. p l ( [ 1 2 7. 0. 0. 1 ] ) by l o c a l h o s t ( stud. i c s. p. l o d z. p l [ 1 2 7. 0. 0. 1 ] ) ( amavisd new, port 10024) with ESMTP i d q7aglgnoe9yc for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 4 1 +0100 (CET) Received : from i c s. p. l o d z. p l ( i c s. p. l o d z. p l [ 2 1 2. 5 1. 2 2 0. 2 3 0 ] ) by stud. i c s. p. l o d z. p l ( P o s t f i x ) with ESMTP i d 9E1CD651DB for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 4 1 +0100 (CET) Received : from l o c a l h o s t ( i c s. p. l o d z. p l [ 1 2 7. 0. 0. 1 ] ) by i c s. p. l o d z. p l ( P o s t f i x ) with ESMTP i d B2E24E859F for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 3 9 +0100 (CET) X Virus Scanned : amavisd new at i c s. p. l o d z. p l Received : from i c s. p. l o d z. p l ( [ 1 2 7. 0. 0. 1 ] ) by l o c a l h o s t ( i c s. p. l o d z. p l [ 1 2 7. 0. 0. 1 ] ) ( amavisd new, port 10024) with ESMTP i d hhalmanqcmut for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 3 9 +0100 (CET) Received : from edu1. i c s. p. l o d z. p l ( edu1. i c s. p. l o d z. p l [ 2 1 2. 5 1. 2 2 0. 2 5 0 ] ) by i c s. p. l o d z. p l ( P o s t f i x ) with ESMTP i d 05BE0E804D for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 3 8 +0100 (CET) Received : from edu. i c s. p. l o d z. p l ( l o c a l h o s t [ 1 2 7. 0. 0. 1 ] ) by edu1. i c s. p. l o d z. p l ( P o s t f i x ) with ESMTP i d F19D428008C for <grzesiu@stud. i c s. p. l o d z. pl >; Sat, 24 Jan 2009 0 0 : 2 5 : 3 6 +0100 (CET) Date : Sat, 24 Jan 2009 0 0 : 2 5 : 3 6 +0100 Message ID : <7cd48c05222853a3156bc875d0e7daf5@edu. i c s. p. l o d z. pl> X P r i o r i t y : 3 X Mailer : PHPMailer [ v e r s i o n Moodle 2 0 0 7 1 0 1 5 3 2. 0 8 ] MIME Version : 1. 0 Content Transfer Encoding : 8 b i t Content Type : t e x t / p l a i n ; c h a r s e t= UTF 8 Status : RO ( t r e s c ). q u i t +OK Sayonara Connection c l o s e d by f o r e i g n host. Przesłać wiadomość zaszyfrowaną/podpisaną za pomocą PGP/certyfikatu SSL i przeanalizować podsłuch tej transmisji za pomocą programu ethereal. W wypadku konta skonfigurowanego na połączenie bez szyfrowania z podsłuchania transmisji uzyskujemy serię pakietów identycznych jak przy wysyłaniu za pomocą programu telnet. Prowadzi to do wniosku iż szyfrowanie wiadomości w programie thunderbird odbywa się w sposób całkowicie niezależny od protokołu. Message ID : <4BCE1574.7050701 @stud. i c s. p. l o d z. pl> Date : Tue, 20 Apr 2010 2 2 : 5 8 : 2 8 +0200 PSK: Grzegorz Graczyk i Paweł Tarasiuk 14 / 15

From : g r z e s i u <grzesiu@stud. i c s. p. l o d z. pl> User Agent : M o z i l l a / 5. 0 ( X11 ; U; Linux i 6 8 6 ; p l ; rv : 1. 9. 1. 7 ) Gecko /20100111 Thunderbird / 3. 0. 1 MIME Version : 1. 0 To : grzesiug44@ gmail. com S u b j e c t : Temat X Enigmail Version : 1. 0. 1 Content Type : t e x t / p l a i n ; c h a r s e t=utf 8 Content Transfer Encoding : quoted p r i n t a b l e BEGIN PGP MESSAGE Charset : UTF 8 Version : GnuPG v1. 4. 9 (GNU/ Linux ) Comment : Using GnuPG with M o z i l l a http : / / e n i g m a i l. mozdev. org / hm4dozsmcpsxgguqav4gj7eeive22lbeva0qpsv7xwdlbct9nrzgvzn+oha0z9it pobetrzhgrflddiisygnsjwmdbxva6lpu1q6jrvfuyzz2utzmm/wff/lz2ppwagp USzda0SXu5z9yzIdFn8C /3 pyggaecreqp9eazbjtnu54fw8tbnjtkwr4ysfjx3x5 0MLunyAF0Tjvu7zHeZtoWnUrVF3QfA7J6NiYP0Ti1+XkprV7ZUPbyUGiSe700s80 urozgjwx5mokl1synuzxdytoa/5h9nkcydkgeal+mqks3cy75nd9nbxxclkiojzg Nx9YF4t2k1fEbHDlMqptGg5zBuzSokXzbpkuN30R1Tg7WXgru9fsl8LT3YdQOX+g hchvdjsdfpylgliljrit8r3libz+riszr47yf3dpav0dga16yrymcbc36db5v9ji sptm7ytzs7qhm2cussihlnt91o9sig46kq4eis2znqk755trn795g2dxeugxeoc1 urohcuhrzozbwbdfvl0e4rjqmx8csjlbyo/xckbwwmdskgehuowtp/u1klhkdttd hvqannb9cu6qzvxjr32quur3gjja92his5s1amsynaoooe8ycqk37amsvfw0p3qr J33sth6ijaUTc7d+LdugcvWknaEvQmPKsvJI5uHFMokDP6+6ToaX1d9VeVaqwlUm NDl6cd1Qv3Snx6/ BOX6JJ0YeXpefGjlif1oeFjSjQoGfsk5P =3DnXET END PGP MESSAGE Skonfigurować program Thunderbird do pracy z systemem NNTP news.man.lodz.pl i przetestować jego działanie wysyłając wiadomość do grupy pl.test. Praca z grupą dyskusyjną w programie thunderbird jest niemal identyczna jak w wypadku kont mailowych. Dodawanie serwera odbywa się za pomocą kreatora. Następnie dodajemy subskrypcję odpowiedniej grupy(lodz.test) i wysyłamy maila kierując go na odpowiednią listę dyskusyjną. Bibliografia 1. Karol Krysiak, Sieci komputerowe. Kompendium., Wydanie II, Helion 2005. 2. Peter Norton, W sercu PC, Helion 2003. 3. Różne hasła z angielskiej oraz polskiej Wikipedii. PSK: Grzegorz Graczyk i Paweł Tarasiuk 15 / 15