150875
numer indeksu
Grzegorz Graczyk
imi i nazwisko
151021
numer indeksu
Paweł Tarasiuk
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 ko- mendy 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 pozo- stać 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 wybiera- nie 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ą czterolitero- wych 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 wy- konanie 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
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 wykonywa- nych 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 ser- wera 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 komen- dę (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 sym- patycznie) 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 autentyka- cja), 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. Od- powiedzi 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ę znaj- dujących się w niej wiadomości, liczbę nowych wiadomości oraz liczbę nieprzeczytanych
wiadomości. Wszystkie te informacje poprzedzone są znacznikiem ”*”. Standardowo, ser- wer 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 wiado- moś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 otrzy- mać 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 perma- nentnie 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ą do- datkowe 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.
• \Deleted – Wiadomość skasowana - jej faktyczne usunięcie zostanie wykonane przy pole- ceniu 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) – Prze- tworzona 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 trans- misyjnym z odbiorcą. Odbiorca może być miejscem docelowym dostarczenia poczty lub jedy- nie 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 wia- domoś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ła- twia 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 nadaw- cę – 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.
• 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ła- szania, 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 zrealizo- wana 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ą poje- dynczy znak ”.”. Zasady formatowania danych są takie same jak w przypadku SMTP.
• QUIT – Prośba o zakończenie połączenia z serwerem.
Dyskusje sieci USENET podzielone są na dziesiątki tysięcy grup, które według swojej katego- rii 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 odpowied- nim 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. rzecznik- prasowy@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 na- głó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).
• To: – Adres skrzynki adresata wiadomości.
• Subject: – Temat wiadomości (wysyłanie wiadomości bez tematu jest sprzeczne z netykie- tą).
• 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. nie- mieckiego i francuskiego.
• środkowoeuropejskie (ISO–8859–2) – Zawiera znaki języków Europy Środkowej i Wschod- niej, 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 prze- syłania danych i obecnie jest to niekwestionowany standard we wszystkich usługach Internetu, których podstawowym zadaniem jest przesyłanie tekstu.
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 da- ne. 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 pocz- towe.
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żytkow- nikó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 uwierzy- telnianie, szyfrowanie zawartości, użycie kluczy niesymetrycznych, PGP, cer- tyfikaty SSL, podpis elektroniczny.
W celu zapewnienie funkcjonalności które mają zostać omówione w niniejszej sekcji, wyko- rzystywana jest kryptografia z użyciem kluczy niesymetrycznych. Kryptografia niesymetryczna oznacza generowanie par elektronicznych podpisów – prywatnego i publicznego. W celu uzyska- nia 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 deszyfru- ją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 pu- blicznych. Podstawowym zastosowaniem PGP jest szyfrowanie poczty elektronicznej, transmito- wanej 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. Inte- gralność 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 przeciw- nym 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łszowa- nia). Przy kryptografii niesymetrycznej tworzymy natomiast pary kluczy: jeden z nich służy do zaszyfrowania listu, drugi do odszyfrowania. Znajomość klucza szyfrowania nie wystarczy
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 komputero- wym 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ór- có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ą wygenerowa- ną 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 odszyfro- wuje 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 zapewnie- nie 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.: certyfika- tami 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.
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, pocz- ta.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. Smut- nym zjawiskiem jest częsta ignorancja administratorów popularnych serwerów wobec upływa- ją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 bar- dzo 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 elektro- niczny. 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, odpo- wiednio 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 bezpieczniej- szy) 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.
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 obo- wiązująca w sieci”. Za pierwszy kompleksowy zbiór zasad korzystania z Internetu uchodzi opra- cowanie 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 świato- wych 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ła- da 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 Ema- il - 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 nicze- go 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ę tro- chę 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 re- klamują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 nie- chcianych wiadomości). Za pomocą takowych list, można blokować na serwerach pocztowych przychodzące wiadomości. Budzą one jednak wiele kontrowersji, gdyż nadgorliwi administrato- rzy często przez pomyłkę blokują możliwość wysyłania poczty niewinnym internautom, umiesz- czają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 jedy- nie podania maila oraz hasła. Program sam odnajduje adres serwerów smtp oraz imap (ma- il.stud.ics.p.lodz.pl) ostrzegając jednocześnie o niepoprawnym certyfikacie tego pierwszego. Usta- wienie 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.
Wysłać wiadomości pocztowe a) na nieistniejący serwer pocztowy (nieprawi- dł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 pocz- ty. 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. Wy- nika 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ść na- głó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 sprawoz- dania.
Wysłać i odebrać wiadomość łącząc się z serwerem poczty za pomocą dowol- nego klienta protokołu telnet.
g r z e s i u @ S a t u r n : ˜ $ t e l n e t s t u d . i c s . p . l o d z . p l 587 T r y i n g 2 1 2 . 5 1 . 2 2 0 . 2 3 1 . . .
Connected t o s t u d . i c s . p . l o d z . p l . Esc ape c h a r a c t e r i s ’ ˆ ] ’ .
220 s t u d . 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− s t u d . i c s . p . l o d z . p l 250−PIPELINING
250−SIZE 3 3 5 5 4 4 3 2 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 b a s e 6 4 ) 334 UGFzc3dvcmQ6 ( h a s l o w b a s e 6 4 )
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 m a i l from : <g r z e s i u @ s t u d . i c s . p . l o d z . p l >
250 2 . 1 . 0 Ok
r c p t t o : <g r z e s i u g 4 4 @ g m a i l . com>
250 2 . 1 . 5 Ok d a t a
354 End d a t a w i t h <CR><LF>.<CR><LF>
From : g r z e s i u @ g r z e s i u . i s −a−g e e k . n e t To : g r z e s i u g 4 4 @ g m a i l . com
T r e s c w i a d o m o s c i .
250 2 . 0 . 0 Ok : queued a s 15B4D64E28
q u i t
221 2 . 0 . 0 Bye
C o n n e c t i o n c l o s e d by f o r e i g n h o s t .
g r z e s i u @ S a t u r n : ˜ $ t e l n e t s t u d . i c s . p . l o d z . p l 110 T r y i n g 2 1 2 . 5 1 . 2 2 0 . 2 3 1 . . .
Connected t o s t u d . i c s . p . l o d z . p l . Esc ape c h a r a c t e r i s ’ ˆ ] ’ .
+OK POP3 s t u d 2007 e . 1 0 4PLD s e r v e r r e a d y u s e r l o g i n
+OK U s e r name a c c e p t e d , p a s s w o r d p l e a s e p a s s h a s l o
+OK Mailbox open , 193 m e s s a g e s s t a t
+OK 193 5 3 4 9 0 8 0 r e t r 1
+OK 2296 o c t e t s
Return−Path : <e d u @ i c s . p . l o d z . p l >
X−O r i g i n a l −To : g r z e s i u @ s t u d . i c s . p . l o d z . p l D e l i v e r e d −To : g r z e s i u @ s t u d . i c s . p . l o d z . p l
R e c e i v e d : from l o c a l h o s t ( s t u d . i c s . p . l o d z . p l [ 1 2 7 . 0 . 0 . 1 ] )
by s t u d . i c s . p . l o d z . p l ( P o s t f i x ) w i t h ESMTP i d 86F5C651DE
f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >; Sat , 24 Jan 2009 0 0 : 2 5 : 4 2 +0100 (CET) X−V i r u s −Scanned : amavisd−new a t i c s . p . l o d z . p l
R e c e i v e d : from s t u d . 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 ( s t u d . i c s . p . l o d z . p l [ 1 2 7 . 0 . 0 . 1 ] ) ( amavisd−new , p o r t 1 0 0 2 4 ) w i t h ESMTP i d q7AGLGNoe9yC f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >;
Sat , 24 Jan 2009 0 0 : 2 5 : 4 1 +0100 (CET)
R e c e i v e d : 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 s t u d . i c s . p . l o d z . p l ( P o s t f i x ) w i t h ESMTP i d 9E1CD651DB
f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >; Sat , 24 Jan 2009 0 0 : 2 5 : 4 1 +0100 (CET) R e c e i v e d : 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 ) w i t h ESMTP i d B2E24E859F
f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >; Sat , 24 Jan 2009 0 0 : 2 5 : 3 9 +0100 (CET) X−V i r u s −Scanned : amavisd−new a t i c s . p . l o d z . p l
R e c e i v e d : 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 , p o r t 1 0 0 2 4 ) w i t h ESMTP i d hhALMAnqCMuT f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >;
Sat , 24 Jan 2009 0 0 : 2 5 : 3 9 +0100 (CET)
R e c e i v e d : 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 ) w i t h ESMTP i d 05BE0E804D
f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >; Sat , 24 Jan 2009 0 0 : 2 5 : 3 8 +0100 (CET) R e c e i v e d : 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 ) w i t h ESMTP i d F19D428008C
f o r <g r z e s i u @ s t u d . i c s . p . l o d z . p l >; 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 : <7c d 4 8 c 0 5 2 2 2 8 5 3 a 3 1 5 6 b c 8 7 5 d 0 e 7 d a f 5 @ e d u . i c s . p . l o d z . p l >
X−P r i o r i t y : 3
X−M a i l e r : PHPMailer [ v e r s i o n Moodle 2 0 0 7 1 0 1 5 3 2 . 0 8 ] MIME−V e r s i o n : 1 . 0
Content−T r a n s f e r −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”
S t a t u s : RO
( t r e s c ) . q u i t
+OK S a y o n a r a
C o n n e c t i o n c l o s e d by f o r e i g n h o s t .
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. Pro- wadzi 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 . 7 0 5 0 7 0 1 @stud . i c s . p . l o d z . p l >
Date : Tue , 20 Apr 2010 2 2 : 5 8 : 2 8 +0200
From : g r z e s i u <g r z e s i u @ s t u d . i c s . p . l o d z . p l >
User−Agent : M o z i l l a / 5 . 0 ( X11 ; U ; Linux i 6 8 6 ; p l ; r v : 1 . 9 . 1 . 7 ) Gecko / 2 0 1 0 0 1 1 1 T h u n d e r b i r d / 3 . 0 . 1 MIME−V e r s i o n : 1 . 0
To : g r z e s i u g 4 4 @ g m a i l . com S u b j e c t : Temat
X−E n i g m a i l −V e r s i o n : 1 . 0 . 1
Content−Type : t e x t / p l a i n ; c h a r s e t=UTF−8 Content−T r a n s f e r −Encoding : quoted−p r i n t a b l e
−−−−−BEGIN PGP MESSAGE−−−−−
C h a r s e t : UTF−8
V e r s i o n : GnuPG v1 . 4 . 9 (GNU/ Linux )
Comment : U s i n g GnuPG w i t h M o z i l l a − h t t p : / / e n i g m a i l . mozdev . o r g /
hM4DOzSMCPSXGgUQAv4gJ7eEIVe22lbevA0qPsv7xWdlBcT9nrzgVZn+oHa0z9iT pObeTRzhGRfLdDiISYgNsJWMDbxva6LpU1q6JrvFuyZZ2UTZmM/wfF/Lz2PPwaGP USzda0SXu5z9yzIdFn8C /3 pYgGAECreqp9eaZbJtNu54fw8tBnjTkwr4ysFjX3x5 0MLunyAF0Tjvu7zHeZtoWnUrVF3QfA7J6NiYP0Ti1+XkprV7ZUPbyUGiSe700s80 uRozgjWX5MoKl1SyNUzXdYTOA/5h9NkcYDKGEAL+MqKS3CY75ND9nBxXCLkiojZg Nx9YF4t2k1fEbHDlMqptGg5zBuzSokXzbpkuN30R1Tg7WXgru9fsl8LT3YdQOX+g hCHvdJSDfpyLgLiLJrIT8r3liBz+RIsZr47yF3dpAv0dgA16yrYmcBC36dB5v9jI spTm7ytzs7QHM2CUSSIhLnT91O9sig46kQ4EIs2ZnQk755Trn795g2dXEUgxEoC1 uRohCuhRZOzBwBdfVL0E4RjQmX8CSjLbYo/xcKbWwmDSkgEhuowTp/u1KLhKDTtd hvQAnNB9CU6qZVXjr32QuUr3GjJA92HIS5S1AmSYNAOoOE8yCQK37AMsVfw0P3Qr J 3 3 s t h 6 i j a U T c 7 d+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 wypad- ku 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.
