Sprawozdanie z laboratorium

Wprowadzenie do sieci komputerowych

Grupa 5: Alicja Lenart nr indeksu:138827,
Piotr Pliszka nr indeksu:138839.

Treść :

Zagadnienia teoretyczne:

•

Protokoły POP3, IMAP, SMTP, komunikacja klient-serwer, podstawowe komendy i odpowiedzi.

•

Protokół NNTP (Usenet).

•

Skrzynki pocztowe, najczęściej używane parametry, adresy, aliasy.

•

Format przesyłki pocztowej, separator nagłówka i treści, nazwy i znaczenie podstawowych znaczników (pól)

nagłówka.

•

Załączniki, kodowanie, MIME

•

Transport wiadomości pocztowej, pocztowe listy dystrybucyjne, bramy pocztowe.

•

Bezpieczeństwo usług pocztowych, szyfrowanie połączeń, bezpieczne uwierzytelnianie, szyfrowanie

zawartości, użycie kluczy niesymetrycznych, PGP, certyfikaty SSL, podpis elektroniczny.

•

Netykieta, tzw. spam, tzw. czarne listy.

Zadania praktyczne:

•

Skonfigurować program Thunderbird do pracy z własnym kontem pocztowym na serwerze zsks.zsk.p.lodz.pl

lub na dowolnym innym serwerze.

•

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.).

•

Za pomocą programu windump i/lub ethereal przeanalizować zawartość nagłówków pakietów TCP

przesyłanych między klientem a serwerem poczty.

•

Wysłać i odebrać wiadomość łącząc się z serwerem poczty za pomocą dowolnego klienta protokołu telnet.

•

Przesłać wiadomość zaszyfrowaną/podpisaną za pomocą PGP/certyfikatu SSL i przeanalizować podsłuch tej

transmisji za pomocą programu ethereal.

•

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 .

Część teoretyczna

* POP - Post Office Protocol ( potocznie zwany protokołem pocztowym ) ma kilka
podstawowych zastosowań, najważniejszym jest zarządzanie komunikacją między klientem (
stacją roboczą z odpowiednim oprogramowaniem ) a serwerem ( pocztowym
przechowującym wiadomości ). POP pozwala na dynamiczny dostęp do przechowywanej na
serwerze poczty, operacje na przechowywanej na serwerze poczcie, standardowo poczta jest
zaraz po pobraniu jej przez użytkownika usuwana, można jednak wymusić przechowanie jej
na serwerze ( jest to przykład dostępnych operacji inną może być możliwość usuwania poczty
z serwera bez pobierania jej przez klienta ).

Podstawowe operacje - komunikacja klient-serwer

Na samym początku należy sobie powiedzieć, że używając stwierdzenia "klient" mamy na
myśli host-a korzystającego z usługi POP, a "serwer" jako host-a udostępniającego usługę
POP. Serwer udostępnia standardowo usługę POP3 nasłuchując na porcie TCP 110. Jeżeli
klient ma zamiar skorzystać z usługi łączy się z serwerem na wspomnianym porcie. Gdy
połączenie zostanie ustanowione serwer wysyła komunikat powitalny, później następuje
wymiana serii komend i odpowiedzi na nie, aż do zamknięcia lub zerwania połączenia.
Stosowane są wyłącznie dwa znaczniki statusu pozytywny: "+OK" oraz negatywny: "-ERR".
Serwer musi wysłać te znaczniki dużymi literami. Odpowiedzi na poszczególne komendy
mogą być i często są wieloliniowe. W takim przypadku każda linia z wieloliniowej
odpowiedzi zakańczana jest znakami CRLF. Gdy wszystkie linie odpowiedzi zostaną
wysłane, wysyłana jest końcowa linia składająca się ze znaków "." oraz znaku CRLF. Sesja
POP3 składa się z kilku stanów w trakcie swego czasu "życia". Raz gdy połączenie TCP,
zostanie nawiązane a serwer POP3 wyśle powitanie, sesja wchodzi w stan uwierzytelniania (
autoryzacji - AUTHORIZATION state ). Podczas tego stanu klient musi zidentyfikować się.
Gdy klientowi z powodzeniem uda się przejść autoryzację serwer przydziela odpowiednie
zasoby z nim związane i sesja przechodzi w stan Transakcji ( TRANSACTION state ), w tym
stanie klient wydaje komendy dotyczące zarządzania jego przestrzenią na serwerze. Wraz z
wydaniem przez klienta komendy QUIT sesja przechodzi w stan Aktualizacji ( Update ), w
tym stanie serwer zwalnia wszystkie zasoby zajęte przed rozpoczęciem stanu Transakcji
poczym "żegna się". Zaraz po tym zamykane jest połączenie TCP. Serwer musi na nie
rozpoznaną lub nie zaimplementowaną komendę odpowiedzieć negatywnym znacznikiem
statusu, podobnie jest w przypadku komendy wysłanej w trakcie niewłaściwego stanu sesji.
Stan Autoryzacji - gdy nastąpiło poprawne połączenie TCP, serwer wysyła jednoliniowe
pozytywne powitanie, przykładem może być:

S: +OK POP3 server ready
Sesja POP3 znajduje się wtedy w stanie Autoryzacji. Klient musi wtedy zidentyfikować się i
potwierdzić swoją "tożsamość" serwerowi POP3. Sposobami na uwierzytelnianie są
kombinacje komend USER i PASS lub komenda APOP, niezależnie od tego że istnieje kilka
sposobów autoryzacji, serwer POP3 musi implementować przynajmniej jedną. Gdy klient
poprawnie się zidentyfikuje serwer rezerwuje zasoby związane z poczta klienta i sesja
przechodzi w stan Transakcji.

Stan Transakcji - w trakcie tego stanu klient może wydawać wielokrotnie następujące
komendy, lub wydać komendę QUIT powodująca przejście sesji w stan Aktualizacji. Poniżej
lista komend dostępnych w stanie Transakcji:

* STAT - brak parametrów wywołania - po wysłaniu tej komendy serwer POP3 zwraca
odpowiedź, zawierającą liczbę wiadomości oraz rozmiar zasobu wiadomości wyrażoną w
oktetach. Format odpowiedzi może wyglądać następująco:
+OK nn mm
Poniżej przykład:
K: STAT
S: +OK 2 320
* LIST [msg] - w komendzie występuje opcjonalny parametr określający numer wiadomości,
nie może się odnosić do wiadomości oznaczonej jako usuniętej. Jeżeli podany został
parametr, serwer POP3 zwraca tzw.: "scan listing" dotyczący wiadomości - linia zawierająca
wiadomości dotyczące wybranej wiadomości. Jeżeli komenda została wydana bez parametru,
serwer zwraca informacje dla każdej wiadomości zawartej w zasobach. Format odpowiedzi
może wyglądać następująco:
+OK scan listing follows
-ERR no such message
K: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
...
K: LIST 2
S: +OK 2 200
...
K: LIST 3
S: -ERR no such message, only 2 messages in mail drop
* RETR msg - parametrem komendy jest ( wymagany ) numer wiadomości, numer ten nie
może dotyczyć wiadomości oznaczonej jako usuniętej. Jeżeli serwer zwróci pozytywną
odpowiedź, jest to odpowiedź wieloliniowa. Serwer wysyła klientowi żądaną wiadomość. W
przypadku odpowiedzi negatywnej serwer wysyła odpowiedź o braku wiadomości o żądanym
numerze. Format odpowiedzi może wyglądać następująco:
+OK message follows
-ERR no such message
K: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
* DELE msg - parametrem komendy jest ( wymagany ) numer wiadomości, numer ten nie
może dotyczyć wiadomości oznaczonej jako usuniętej. Serwer POP3 oznacza wiadomość
jako usuniętą, nie usuwa jej jednak fizycznie dopóki sesja nie przejdzie w stan Aktualizacji.
Jakiekolwiek próby odwoływania sie do wiadomości oznaczonej jako usunięta, spowodują
powstanie błędu. Format odpowiedzi może wyglądać następująco:
+OK message deleted
-ERR no such message
K: DELE 1
S: +OK message 1 deleted
...
K: DELE 2
S: -ERR message 2 already deleted

* NOOP - brak parametrów wywołania, serwer POP3 nie wykonuje, żadnej operacji prócz
wysłania pojedynczej linii pozytywnej odpowiedzi +OK.
K: NOOP
S: +OK
* RSET - brak parametrów wywołania, Jeżeli na serwerze znajdują się wiadomości
oznaczone jako usunięte, zostają one "odznaczone". Serwer POP zwraca odpowiedź +OK
K: RSET
S: +OK mail drop has 2 messages (320 octets)
Stan Aktualizacji ( Update State ) - wraz z wydaniem przez klienta komendy QUIT, sesja
przechodzi w stan Aktualizacji, inaczej niż jest to w przypadku wydania przez klienta
komendy QUIT w trakcie sesji Autoryzacji, gdzie sesja jest odrazu zakańczana i zakańczane
jest połączenie.
Gdy sesja zostanie zakończona z innego powodu niż komenda QUIT ze strony klienta, sesja
POP3 nie wchodzi w stan Aktualizacji, nie może skasować, żadnych zaznaczonych
wiadomości.

* QUIT - brak argumentów - serwer usuwa wszystkie wiadomości oznaczone jako usunięte.
Zwraca odpowiedź określającą powodzenie operacji po czym zamyka połączenie.
K: QUIT
S: +OK dewey POP3 server signing off (mail drop empty)
...
K: QUIT
Dodatkowe Komendy protokołu POP3

Komendy wymienione w sekcji opisującej stan Transakcji stanowią bazę komend
określających minimalną implementację protokołu POP, która powinna znaleźć się na
serwerze. Poniżej jest zestaw komend, które dają klientowi POP większa swobodę w
kontrolowaniu całego połączenia z serwerem.

* TOP msg n - w komendzie występują dwa wymagane parametry, numer wiadomości który
nie może się odnosić do wiadomości oznaczonej jako usuniętej, oraz dodatnia liczba
określająca ilość linii. Komeda może być wydana wyłącznie w stanie Transakcji. Serwer
POP3 wysyła określoną liczbę linii nagłówka wybranej wiadomości, jeżeli żądana ilość linii
przekracza rozmiar nagłówka serwer POP zwraca całą wiadomość.
C: TOP 1 10
S: +OK
S: the POP3 server sends the headers of the
message, a blank line, and the first 10 lines
of the body of the message
S: .
...
K: TOP 100 3
S: -ERR no such message
* UIDL [msg] - w komendzie występuje opcjonalny parametr określający numer
wiadomości, nie może się odnosić do wiadomości oznaczonej jako usuniętej. Komeda może
być wydana wyłącznie w stanie Transakcji. Jeżeli numer wiadomości został podany serwer
POP zwraca tzw.: "unique-id listing" dla żądanej wiadomości. Jeżeli komenda została wydana
bez parametru, serwer zwraca "unique-id listing" dla każdej wiadomości. "unique-id listing"
wiadomości jest to łańcuch znaków określany przez serwer, zawierający od jednego do 70

znaków z przedziału od 0x21 do 0x7E, jednoznacznie identyfikujący wiadomość w trakcie
sesji POP3.
K: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
...
K: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
...
K: UIDL 3
S: -ERR no such message, only 2 messages in mail drop
* USER name - parametr wymagany, jednoznacznie określa "konto" na serwerze. Komenda
może być wyłącznie wydana w stanie Autoryzacji, po otrzymaniu powitania od serwera lub
nie pomyślnej identyfikacji komendami USER i PASS. Po otrzymaniu pozytywnej
odpowiedzi od serwera klient może wydać albo komendę PASS podając hasło albo komendę
QUIT kończącą sesję oraz połączenie.
K: USER frated
S: -ERR sorry, no mailbox for frated here

...
K: USER mrose
S: +OK mrose is a real hoopy frood
* PASS string - parametr wymagany, zawiera hasło na "konto" na serwerze POP3, komenda
może być wydana jedynie po pozytywnej odpowiedzi na komendę USER. Serwer może
zwrócić pozytywna odpowiedź, oznaczająca pozwolenie na zarządzanie zasobami "konta",
lub błędy oznaczające albo niepoprawne hasło lub brak możliwości zarezerwowania zasobów
dla konta.
K: USER mrose
S: +OK mrose is a real hoopy frood
K: PASS secret
S: -ERR mail drop already locked
...
K: USER mrose
S: +OK mrose is a real hoopy frood
K: PASS secret
S: +OK mrose's mail drop has 2 messages (320 octets)
* APOP name digest - dwa parametry oba wymagane, łańcuch znaków name jednoznacznie
określający skrzynkę pocztową oraz łańcuch znaków digest zawierający zbiór MD5. Jedyną
restrykcją jest to, że komenda może być wydana jedynie w trakcie stanu autoryzacji, po
powitaniu ze strony serwera lub nie udanym logowaniu za pomocą komend USER i PASS.
Komenda APOP służy do wielokrotnego logowania na serwer POP3 w krótkich odstępach
czasu, wiele serwerów jest zabezpieczonych przed wielokrotnym logowanie za pomocą
komend USER i PASS, zliczają one dostęp do konta etc. klient wydający komendę APOP
musi podać nazwę użytkownika ( konta ) oraz hash MD5 obliczony z 'msg-id' oraz łańcucha
znanego jedynie serwerowi i klientowi. Komunikaty które może zwrócić serwer to komenda
zezwalająca na dalsze wydawanie poleceń ( przejście w stan autoryzacji +OK ) lub
zabronienie dostępu -ERR. Poniżej przykładowa komunikacja:
S: +OK POP3 server ready <[e-mail]>

K: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK mail drop has 1 message (369 octets)

W tym przykładzie współdzielony przez klienta i serwer łańcuch znaków to `tanstaaf'. Więc
algorytm MD5 jest zastosowany na łańcuchu znaków takiemu jak poniżej
<[e-mail]>tanstaaf
Algorytm dla takiego łańcucha produkuje następujący hash:
c4c9334bac560ecc979e58001b3e22fb

* SMTP - jest to skrót, który rozwijany jest w nazwę Simple Mail Transfer Protocol .

Schemat komunikacji działa tak: w wyniku zapytania wysłanego przez użytkownika sender-
SMTP ustanawia połączenie, dwustronny kanał transmisyjny z receiver-SMTP. Receiver-
SMTP może być miejscem docelowym dostarczenia poczty lub jedynie pośrednim węzłem w
komunikacji. Pomiędzy Sender-SMTP a Receiver-SMTP wymieniane są komendy oraz
odpowiedzi na te komendy. Wraz z otwarciem połączenia sender-SMTP wysyła komendę
MAIL jednoznacznie identyfikującą wysyłającego pocztę, jeżeli receiver-SMTP może
zaakceptować wysłane dane odsyła odpowiedź OK. Po odebraniu pozytywnej odpowiedzi
sender-SMTP wysyła komendę RCTP identyfikującą odbiorcę wiadomości. Jeżeli receiver-
SMTP może przyjąć żądanego odbiorcę, zwraca odpowiedź OK, jeżeli nie może przyjąć
odbiorcy odpowiada o takiej sytuacji jednak nie kończy transakcji ponieważ Sender-SMTP i
Receiver-SMTP mogą "negocjować" kolejnych odbiorców. Gdy uzgodnieni zostaną wszyscy
odbiorcy poczty, sender-SMTP wysyła dane które zawiera wiadomość, dane zakańczane są
specjalną sekwencją znaków.

* Procedury SMTP - na początku przedstawiona jest podstawowa procedura wysyłania
poczty nazywana także transakcją poczty. Dalej opisane są procedury przekazywania poczty,
sprawdzania nazw skrzynek pocztowych, rozszerzania list pocztowych, otwierania i
zamykania połączeń.

* MAIL - są 3 kroki podczas transakcji pocztowej, transakcja rozpoczynana jest komendą
MAIL identyfikującą wysyłającego, później seria komend RCPT identyfikujących odbiorcę
wiadomości, komenda DATA określająca początek danych zawierających wiadomość. I
ostatecznie znacznik końca wiadomości potwierdzający całą transakcję pocztową.

- MAIL <SP> FROM: <reverse-path> <CRLF>

Ta komenda mówi serwerowi, że nowa transakcja pocztowa została rozpoczęta, nakazuje na
zresetowanie tablic stanów i buforów. Podaje adres reverse-path który może być używany w
celu raportowania błędów. Jeżeli komenda zostanie zaakceptowana receiver-SMTP wyśle
odpowiedź 250 OK.

<reverse-path> zawierać może nie tylko adres skrzynki pocztowej, może zawierać listę hos-
tów do których zostaną wysłane informacje o błędach jednak pierwszym hostem musi być ten
wysyłający wiadomość. <SP> - pojedyncza spacja, <CRLF> - nowa linia

Kolejnym krokiem jest komenda RCPT:

- RCPT <SP> TO: <forward-path> <CRLF>

Ta komenda podaje jednego adresata, jeżeli zostanie zaakceptowana serwer zwróci
odpowiedź 250 OK i przechowa adres odbiorcy. Jeżeli adresat jest nieznany serwer zwróci
odpowiedz negatywna 550. Komenda może być powtórzona dowolną ilość razy.

Trzecim krokiem jest wysłanie komendy:

- DATA <CRLF>

Jeżeli komenda zostanie zaakceptowana serwer zwróci odpowiedź 354 i potraktuje kolejne
linie wysłane przez klienta jako dane zawierające wiadomość. Kiedy serwer otrzyma koniec
tekstu zachowuje go i wysyła odpowiedź pozytywna 250 OK. Skoro wszystkie dane zostały
wysłane kanałem transmisyjnym i został osiągnięty koniec wiadomości musi zostać
wznowiona w jakiś sposób wymiana komend i odpowiedzi między serwerem a klientem.
SMTP rozpoznaje koniec wiadomości poprzez odnalezienie pojedynczej linii zawierającej
jedynie kropkę ".". Protokół zabezpieczony jest przed tym iż użytkownik może wysłać w
pewnym miejscu swej wiadomości linię z pojedynczym tekstem, bowiem klient tuż przed
wysłaniem analizuje wysyłaną linię wiadomości i jeżeli znajduje się w niej kropka klient
dostawia drugą kropkę "..". Serwer podczas otrzymywania wiadomości usuwa nadmiarową
kropkę. Nadejście znaku "." oznacza zakończenie transakcji pocztowej. Serwer powinien
zwrócić wtedy odpowiedź 250 OK. Komenda DATA może zakończyć się niepowodzeniem
jedynie gdy transakcja była niepełna ( np.: brak odbiorców dla listu ) lub gdy serwer nie ma
wolnych zasobów. W przypadku gdy adres skrzynki zawarty w komendzie RCPT - w
<forward-path> jest niewłaściwy dla danego serwera a serwer ten wie gdzie dalej przekazać
wiadomość, przekazuje ją dalej i odpowiada klientowi na jeden z poniższych sposobów:

251 User not local; will forward to <forward-path>

Serwer odpowiada tak, jeżeli odnajdzie pomyłkę w adresie odbiorcy i wie jak ją poprawić,
przekazuje więc wiadomość pocztową i w odpowiedzi przekazuje poprawny wg. niego adres.
Serwer bierze odpowiedzialność za dostarczenie wiadomości.

551 User not local; please try <forward-path>

Odpowiedź ta oznacza, że serwer wie, że skrzynka pocztowa znajduje się na innym hoście,
przekazuje odpowiedź klientowi z poprawnym wg. niego adresem lecz nie bierze dalej
udziału w przekazywaniu poczty.

SMTP dostarcza dodatkową funkcjonalność jaką jest sprawdzanie nazwy użytkownika oraz
poszerzanie mailing listy. Jest to wykonywane za pomocą komendy VRFY oraz komendy
EXPN, które jako argumenty pobierają łańcuchy znaków.

VRFY - komenda pobiera łańcuch znaków oznaczający nazwę użytkownika, jeżeli
użytkownik ma konto na danym serwerze, serwer zwraca pozytywną odpowiedź 250
zawierającą pełną nazwę użytkownika wraz z jego adresem pocztowym.

Zestaw komend MAIL, RCPT oraz DATA należą do minimalnej implementacji protokołu
SMTP, ich obecność jest wymagana. Poniżej przedstawione są komendy protokołu SMTP
pozwalające wysyłać wiadomości nie tylko na skrzynkę pocztową ale i na terminal.

- SEND <SP> FROM:<reverse-path> <CRLF>

Komenda SEND wymusza dostarczenie danych zawierających wiadomość do terminalu
wybranego użytkownika. Jeżeli użytkownik nie jest aktywny lub nie przyjmuje wiadomości
terminalowych serwer zwraca odpowiedź 450.

- SOML <SP> FROM:<reverse-path> <CRLF>

Komenda SOML - jest to skrót od Send Or MaiL, wymusza dostarczenie danych
zawierających wiadomość do wybranego terminalu użytkownika, jeżeli użytkownik jest nie
aktywny lub nie przyjmuje wiadomości terminalowych, wiadomość ma być wysłana na
skrzynkę użytkownika.

- SAML <SP> FROM:<reverse-path> <CRLF>

Komenda SAML - jest to skrót to Send And MaiL, wymusza dostarczenie danych
zawierających wiadomość do wybranego terminalu użytkownika oraz do jego skrzynki
mailowej.

Istnieje jeszcze mały zbiór komend odpowiedzialny za otwieranie i zamykanie transakcji
pocztowej, są to: komendy HELO i QUIT.

- HELO <SP> <domain> <CRLF>

Jest to komenda pozwalająca zidentyfikować się hostowi serwerowi, dosłownie host
przedstawia się. W odpowiedzi serwer zwraca 250 oraz sam się przedstawia.
220 poczta.o2.pl ESMTP Wita
HELO testowa
250 poczta.o2.pl
- QUIT <CRLF>

Ta komenda zamyka połączenie i kończy transakcję pocztową
235 2.0.0 Authentication successful
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Serwer zwraca odpowiedzi na każdą komendę określające powodzenie danej operacji. Poniżej
niektóre odpowiedzi serwera .
500 Syntax error, command unrecognized [This may include errors such as command line too
long] - nierozpoznana komenda
501 Syntax error in parameters or arguments - blad w parametrach przekazywanych do
komendy
502 Command not implemented, command unrecognized - komenda nie zaimplementowana,
nie rozpoznana
503 Bad sequence of commands - zla kolejnosc komend
504 Command parameter not implemented - paramter przekazany do komendy nie znajduje
sie w specyfikcji implementacji komendy.

* IMAP - jest to protokół warstwy aplikacji, można powiedzieć, że jest w pewien sposób
spokrewniony z protokołem POP, tak samo jak on służy do pobierania i zarządzania pocztą
znajdującą się na serwerze, jest jednak znacznie bardziej rozbudowany niż POP daje także

więcej możliwości. Protokół IMAP realizowany jest na 143 porcie TCP. Obecnie można
spotkać kilka standardów ( wersji ) protokołu IMAP: IMAP2, IMAP3 oraz IMAP4rev1.
Informacje, które znajdują się poniżej generalnie odnoszą się i są zgodne z każdą wersją tego
protokołu.

Połączenie IMAP składa się z akcji odpowiedzialnych za ustalenie połączenia między
klientem a serwerem, pozdrowienia ( powitania ) ze strony serwera, oraz interakcji między
klientem a serwerem.

Seria komend i odpowiedzi wymienianych między serwerem a klientem ma postać linii
zakończonych znakiem CRLF. Serwer jest wyposażony w mechanizmy informowania klienta
o powodzeniu lub porażce. Jeżeli wiele komend jest wykonywanych jednocześnie, serwer w
odpowiedzi wysyła znacznik komendy jednoznacznie określający do jakiej operacji odnosi się
odpowiedź. Istnieją 3 możliwe odpowiedzi serwera: OK ( oznaczająca sukces ), NO (
oznaczająca porażkę ) oraz BAD ( oznaczająca błąd protokołu np.: nierozpoznana komenda
lub błąd składni komendy ). Każda błędna komenda wydana przez klienta powinna być
odrzucana przez serwer. Klient zaś czyta linie odpowiedzi serwera i na bieżąco je analizuje.
Klient musi podjąć odpowiednią akcję 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 które
nie zostały zażądane. Dane wysyłane przez serwer muszą być przechowywane dla
przypadków w których klient mógłby poszukać potrzebnych mu informacji w pobranych juz
danych zamiast wysyłać zapytanie do serwera.
Każda wiadomość ma swoje atrybuty, atrybuty te mogą być pobierane pojedynczo lub w
całości wraz z całym tekstem wiadomości.
Wiadomości mają także dwa bardzo specjalne atrybuty tzw.:
- Unique Identifier (UID) Message Attribute
- Message Sequence Number Message Attribute

* Unique Identifier (UID) - 64 bitowa wartość jednoznacznie określająca wiadomość, nie
może się zmienić w trakcie sesji oraz nie powinna sie zmienić pomiędzy sesjami.
* Message Sequence Number - relatywny numer wiadomości od wiadomości pierwszej do
wiadomości mającej numer zgodny z ilością wiadomości w skrzynce. Wiadomości ustawione
są rosnąco omawianymi tutaj numerami "sekwencyjnymi". Numery te mogą być zmieniane i
reorganizowane w trakcie sesji.

Flagi wiadomości - rozróżnia się dwa typy flag wiadomości stałe oraz istniejące tylko
podczas bieżącej sesji. Każda flaga zaczyna się od "\". Obecnie zdefiniowane flagi to:
\Seen
Wiadomość została przeczytana
\Answered
Na wiadomość została wysłana odpowiedź
\Flagged
Wiadomość jest oznaczona jako ważna/specjalna i wymaga uwagi
\Deleted
Wiadomość oznaczona jako skasowana do późniejszego usunięcia
\Draft
Wiadomość jest niedokończona i oznaczona jako szkic
\Recent
Wiadomość właśnie nadeszła, i zostaje po raz pierwszy wyświetlona w bieżącej sesji.

Atrybut wewnętrznej daty wiadomości ( Internal Date Message Attribute ) - jest to data i czas
odzwierciedlający datę kiedy wiadomość została otrzymana.
Atrybut rozmiaru wiadomości ( Size Message Attribute ) - liczba oktetów wiadomości.
Atrybut struktury koperty wiadomości ( Envelope Structure Message Attribute ) - jest to
przetworzona reprezentacja nagłówka wiadomości.
Atrybut struktury ciała wiadomości ( Body Structure Message Attribute ) - jest to
przetworzona reprezentacja ciała wiadomości ( w tym MIME ).

Protokół IMAP pracuje w kilku stanach podobnie jak POP. Oznacza to, iż niektóre komendy
wydawane przez klienta mogą być wydane tylko w jednym konkretnym stanie sesji IMAP.
Rozróżnia się:

* Stan braku autoryzacji ( Not Authenticated State ) - w tym stanie sesji klient musi podać
dane autoryzujące jego dostęp do zasobów serwera, sesja IMAP wchodzi w ten stan zaraz po
ustanowieniu połączenia i powitaniu, o ile połączenie nie zostało wcześniej autoryzowane
innymi sposobami.

* Stan autoryzacji ( Authenticated State ) - w tym stanie sesji klient ma już autoryzacje i
musi wybrać skrzynkę na której będzie działać.

* Stan wyboru ( Selected State ) - sesja przechodzi w ten stan jeżeli użytkownik pomyślnie
wybrał skrzynkę.

* Stan wylogowywania ( Logout State ) - stan sesji gdy zamykane jest połączenie między
klientem a serwerem.

Komendy klienta IMAP:
* NOOP - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ). 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ę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ). Komenda ta informuje serwer, że klient zakończył swoje
działanie, serwer musi wtedy wysłać mu w odpowiedzi BYE przed wysłaniem odpowiedzi
OK. Zaraz po tym zamykane jest połączenie. Komenda ta może być wydana w dowolnym
stanie sesji.

* STARTTLS - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ). Komenda ta mówi serwerowi aby rozpoczął negocjacje TLS z
serwerem, głównie chodzi o to by połączenie między klientem a serwerem było szyfrowane.

* AUTHENTICATE - jako argument podawany jest mechanizm wskazujący sposób
autoryzacji. Komenda może zwrócić odpowiedzi: OK ( pomyślna autentykacja ), NO ( nie
udana autentykacja, brak podanego mechanizmu autentykacji ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ).

* LOGIN - jako argumenty podawane są dwa łańcuchy: nazwa użytkownika oraz hasło. brak
specyficznych odpowiedzi na ta komendę wynikiem są tylko odpowiedzi OK ( wykonanie
komendy ), NO ( login i hasło zostało przyjęte) lub BAD ( złe wywołanie lub nieodpowiednie
argumenty ).

* SELECT - jako argument podawana jest nazwa skrzynki, na której mają być wykonywane
inne komendy. Serwer w odpowiedzi zwraca dane dotyczące skrzynki, ilość istniejących
wiadomości, ilość nowych wiadomości, ilość nie przeczytanych wiadomości itd. wszystkie te
informacje poprzedzone są znacznikiem "*", serwer zwraca tez odpowiedzi OK ( pomyślne
wykonanie polecenia, przejście w stan wyboru ), NO ( brak skrzynki o podanej nazwie ) lub
BAD ( złe wywołanie lub nieodpowiednie argumenty ).

* EXAMINE - komenda ta działa identycznie jak komenda SELECT, zwraca tez te same
informacje jednak nie powoduje, że wiadomości tracą flagę /Recent.

* CREATE - jako argument pobierana jest nazwa skrzynki, komenda ta bowiem tworzy
skrzynkę o podanej nazwie. Brak specyficznych odpowiedzi na ta komendę wynikiem są
tylko odpowiedzi OK ( wykonanie komendy ), NO ( nie można stworzyć skrzynki o podanej
nazwie ) lub BAD ( złe wywołanie lub nieodpowiednie argumenty ).

* DELETE - jako argument pobierana jest nazwa skrzynki, komenda ta bowiem usuwa
skrzynkę o podanej nazwie permanentnie. Brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ), NO ( nie można usunąć skrzynki
o podanej nazwie ) lub BAD ( złe wywołanie lub nieodpowiednie argumenty ).

* RENAME - jako argumenty pobiera starą nazwę skrzynki i nową nazwę skrzynki, komenda
ta zmienia nazwę istniejącej skrzynki. Brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ), NO ( nie można zmienić nazwy
skrzynki ) lub 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 odpowiedzi OK ( wykonanie komendy ), NO (
brak statusu dla skrzynki o podanej nazwie ) lub BAD ( złe wywołanie lub nieodpowiednie
argumenty ).

* CHECK - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ). Komenda ta jest ekwiwalentem NOOP.

* CLOSE - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę
wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( złe wywołanie lub
nieodpowiednie argumenty ). Komenda ta usuwa permanentnie wszystkie wiadomości które
mają ustawioną flage /Deleted i powraca do stanu autentykacji ze stanu wyboru.

* EXPUNGE - usuwa wszystkie wiadomości które oznaczone są flagą /Deleted.

* SEARCH - wyszukuje wiadomości spełniające zadane kryteria. Jako odpowiedź zwraca
wiadomości oraz odpowiedz OK ( pozytywne wykonanie komendy ), NO ( brak wiadomości
spełniających kryteria ) lub BAD ( złe wywołanie lub nieodpowiednie argumenty )

* FETCH - pobiera dane związane z wiadomością ze skrzynki.

* NNTP - jest to skrót od Network News Transfer Protocol, inaczej Sieciowy protokół
przesyłania wiadomości. Jest protokołem i usługa przeznaczoną do ogłaszania, przesyłania i
pozyskiwania wiadomości 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ą wszelkie tematy. Protokół NNTP
korzysta z portu TCP nr. 119. Dyskusje sieci USENET podzielone są na dziesiątki tysięcy
grup, które według swojej kategorii zorganizowane są w postaci hierarchicznej. Ściśle
określone zostały jednak hierarchie wysokiego poziomu "root". Noszą one nazwę "wielka
siódemka":

+ comp - Komputery
+ misc - Różne
+ news - Administracja siecią usenet
+ rec - Rekreacja
+ sci - Nauka
+ soc - Społeczeństwo
+ talk - Dyskusje ogólne
Inne popularne hierarchie to:
+ alt - hierarchia grup alternatywnych
+ bionet - Biologia
+ clari - Informacje na żywo z agencji Reuters
+ k12 - "Kindergarden through 12th grade"

W celu ograniczenia nieporozumień tradycyjnie dla wygody użytkowników wydziela się
hierarchie związane z wykorzystywanym językiem. Poszczególne kraje mają własne
hierarchie np.:
+ de - Niemcy
+ pl - Polska
Hierarchiczne uporządkowanie Usenet-u w istotny sposób ułatwia odnalezienie w mnogości
poruszanych tematów takiego, który zaspokoi najbardziej wyrafinowane potrzeby.
Najprostszym przykładem może być 350 grup zawierających w nazwie słowo "unix". Do
najaktywniejszych należą comp.unix.solaris i comp.unix.aix. Tego typu nazwy w jasny
sposób określają podstawowa tematykę dyskusji.
Serwer wiadomości jest tylko interfejsem pomiędzy programem klientem użytkownika a
bazami danych przechowującymi wiadomości.
Komendy wysyłane do serwera składają się ze słowa kluczowego oraz występujących po nim
opcjonalnych ( lub nie ) parametrów. Parametry musza być oddzielone pojedynczą spacją,
komendy i parametry nie są czułe na wielkość znaków, mogą być pomieszane ( występować
w nich mogą zarówno duże jak i małe litery ). Każda linia z komendą musi być zakończona
CRLF. Linia zawierająca komendę wraz z parametrami nie może przekroczyć 512 znaków.
Odpowiedzi serwera dzielimy na tekstowe i linie statusu. Odpowiedzi tekstowe występują
jedynie po odpowiedziach zawierających status. Linia z odpowiedzią zawierającą status
zaczyna sie od 3 cyfr, które jednoznacznie określają wynik operacji. Pierwsza cyfra oznacz
sucec, porażkę lub to, że operacja jest w toku
1xx - Informative message - odpowiedz zawierająca informacje.
2xx - Command ok - odpowiedz oznaczająca, że komenda została wykonana poprawnie.
3xx - Command ok so far, send the rest of it - część komendy która została wysłana do tej
pory jest w porządku, serwer czeka na resztę.

4xx - Command was correct, but couldn't be performed for some reason. - komenda miała
poprawną składnie ale nie mogła być wykonana z jakiegoś powodu.
5xx - Command unimplemented, or incorrect, or a serious program error occurred. - komedna
nie jest zaimplementowana.

Druga cyfra oznacza kategorie funkcji odpowiedzi:

x0x - Connection, setup, and miscellaneous messages - Połączenia, ustawienia lub różne
wiadomości
x1x - Newsgroup selection - Wybór grupy dyskusyjnej
x2x - Article selection - Wybór artykułu
x3x - Distribution functions - Funkcje dystrybucyjne
x4x - Posting - Wysyłanie wiadomości
x8x - Nonstandard (private implementation) extensions - niestandardowe rozszerzenia
x9x - Debugging output - Wyjście obsługi błędów

Komendy klienta NNTP:

* ARTICLE message-id - komenda wyświetla nagłówek, pustą linię, na końcu tekst ( ciało )
wiadomości.
* GROUP ggg - wymagany parametr ggg, zawiera nazwę grupy dyskusyjnej, która ma być
wybrana. Gdy komenda zostanie zrealizowana z powodzeniem serwer zwróci numer
pierwszego i ostatniego artykułu w grupie, i liczbę wszystkich artykułów w grupie.
* HELP - serwer zwraca klientowi listę dostępnych komend jakie może wydać klient.
* IHAVE messageid - komenda informuje serwer, że klient posiada artykuł o podanym
numerze, jeżeli serwer zażyczy sobie pobrać artykuł wyśle klientowi szczegółowe instrukcje
jak to ma zrobić.
* LAST - serwer w odpowiedzi na tą komendę zwraca numer bieżącego artykułu
* LIST - zwraca listę istniejących grup dyskusyjnych na serwerze.
* NEWGROUPS date time [GMT] - zwraca listę grup dyskusyjnych utworzonych od czasu
podanego w parametrze date time
* NEWNEWS newsgroups date time [GMT] - zwraca listę numerów artykułów które
zostały wysłane na grupę dyskusyjną od podanej daty.
* NEXT - zwraca następny artykuł, w stosunku do wskaźnika bieżącego artykułu.
* POST - jeżeli wysyłanie wiadomości jest możliwe, serwer wysyła odpowiedź 340, jeżeli
zabronione z pewnych powodów serwer wysyła odpowiedź 440. Koniec tekstu wiadomości
oznaczany jest linia z pojedynczą kropką "." występują tu te same zasady co w przypadku
protokołu SMTP i jego sposobów formatowania danych do wysłania.
* QUIT - komenda służy do oznaczenia, że połączenie między serwerem a klientem ma być
zakończone

* Załączniki są to pliki dodawane do wiadomości, pocztowej przesyłane wraz z tekstem
wiadomości do odbiorcy, kodowanie jest to sposób w jaki będą zapisywane znaki przesyłanej
wiadomości, np.:
- zachodnioeuropejskie (ISO-8859-1) - zawiera znaki języków Europy Zachodniej, np.
niemieckiego, francuskiego itp.,
- ś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.
Obie te rzeczy ściśle wiążą się z nagłówkami MIME.

* MIME - Multipurpose Internet Mail Extensions - co można przetłumaczyć na
"Wielozadaniowe rozszerzenie poczty w Internecie" - jest standardem pozwalającym
przesyłać w sieci Internet wszelkie dane (teksty, grafikę, zdjęcia, dźwięki, muzykę, programy)
za pomocą standardowych narzędzi, takich jak poczta, newsy czy WWW. Wbrew swojej
nazwie (Mail Extension, czyli rozszerzenie poczty), zastosowanie MIME nie ogranicza się
wyłącznie do plików przesyłanych pocztą. 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.

Dzięki MIME list zawierający zdjęcie i nagrany głos nadawcy może zostać wysłany z
komputera typu Macintosh, a następnie odebrany na komputerze Amiga, przy czym zarówno
nadawca listu jak i odbiorca w ogóle nie zauważą faktu, że np. dane zawierające obrazek
zostaną po drodze zamienione na ciąg literek .

Plik zawierający dźwięk został zmieniony w "międzyczasie" z formatu stosowanego na
jednym komputerze na format stosowany na drugim.
Wystarczy, żeby program wysyłający lub obierający dane do/z sieci Internet, potrafił sobie
przekodować odpowiednio polskie literki na standard MIME. Dzięki temu użytkownik
wogóle nie zauważa, że polskie literki są zapisane w inny sposób niż to jest stosowane zwykle
w jego komputerze.

Nagłówki oddzielone są od treści listu jedną linią pustą i określają:
- From - od kogo otrzymano list
- From: - adres nadawcy (tu jest dwukropek)
- Received: - punkty pośrednie (adresy węzłów przez które przesyła przeszła zanim trafiła do
celu)
- To: - adres odbiorcy listu
- Subject: - temat listu
- 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 list
- Cc: - adres, na który została wysłana kopia listu

Nagłówki pomocnicze:
- Mime-Version: 1.0 - który identyfikuje wszystkie takie przesyłki
- Content-Type: - rodzaj zawartości przesyłki,
- Content-Transfer-Encoding: - sposób jej kodowania,
- Content-Length: - długość przesyłki (nie zawsze występuje),
- Content-description: - opis zawartości przesyłki.

Wszystkie nagłówki dodawane są do przesyłek automatycznie przez program
przygotowywujący list i wszystkie programy uczestniczące w jego przesyłaniu

* Listy dystrybucyjne są to listy adresów pocztowych służące do masowego rozsyłania
wiadomości do wszystkich użytkowników na ta listę zapisanych . Aby wysłać taką
wiadomość wysyłamy jej treść do serwera udostępniającego taką usługę (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ę.

* Komputery których głównym zadaniem jest przetwarzanie poczty nazywane są bramami
pocztowymi. Są one najczęściej wykorzystywane w momencie kiedy lista adresatów, do
których ma trafić kopia naszej wiadomości jest długa. W momencie wysłania takiej
wiadomości nasz klient nie próbuje sam przekazywać wiadomości tylko przesyła ją do bramy
która to rozsyła wiadomości do adresatów.

* Aliasy są to alternatywne identyfikatory tej samej skrzynki pocztowej np.
[e-mail] czy [e-mail] mogą wskazywać na ta sama skrzynkę.

* Klucze niesymetryczne - Kryptografia niesymetryczna umożliwia generowanie
elektronicznych podpisów, gdy rola obu kluczy - prywatnego i publicznego zostanie
odwrócona i wiadomość zostanie 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 tym konkretnym
kluczem prywatnym.

* PGP ( Pretty Good Privacy - Całkiem Niezła Prywatność ) jest kryptosystemem ( tzn.
systemem szyfrująco-deszyfrującym ) autorstwa Phila Zimmermanna <[e-mail]>
wykorzystującym ideę klucza publicznego. Podstawowym zastosowaniem PGP jest
szyfrowanie poczty elektronicznej, transmitowanej przez kanały nie dające gwarancji
poufności ani integralności poczty. Przez poufność rozumiemy tu niemożność podglądania
zawartości listów przez osoby trzecie; przez integralność - niemożność wprowadzania przez
takie osoby modyfikacji do treści listu. Szyfr "tradycyjny" wymagał użycia tego samego
klucza do szyfrowania i odszyfrowywania. Klucz ten zatem musiał być wcześniej uzgodniony
przez porozumiewające się strony, i to z użyciem kanału bezpiecznego (zapewniającego
poufność i integralność) - 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). W metodzie klucza publicznego,
pojedynczy klucz zastąpiony jest parą kluczy: jeden z nich służy do zaszyfrowania listu, drugi
do odszyfrowania. Znajomość klucza szyfrowania nie wystarczy do deszyfracji listu, ani do
odtworzenia klucza deszyfrowania. Co za tym idzie, tylko klucz deszyfrowania musi pozostać
sekretem swego właściciela (i dlatego nazywany jest "kluczem prywatnym"). Klucz
szyfrowania może być udostępniony ogółowi - stąd termin "klucz publiczny". Dowolna
osoba, chcąca wysłać tajną wiadomość do właściciela tego klucza, używa klucza publicznego
w celu zaszyfrowania treści listu. List ten odszyfrować może tylko osoba będąca w
posiadaniu klucza prywatnego związanego z tym kluczem publicznym - w domyśle:
właściciel klucza. Zastosowany w PGP algorytm szyfrowania kluczem publicznym nosi
nazwę RSA (Rivest-Shamir-Adleman). PGP nie szyfruje całego dokumentu (np. listu) z
użyciem algorytmu RSA - ponieważ jest on dość powolny, trwałoby to bardzo długo. 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 ten bezpieczny kanał).

* SSL - skrót ten jest rozwijany w Secure Socket Layer - opracowany przez firmę Netscape
obecnie stał się praktycznie jednym ze standardów 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 otwartym tekstem ), łatwo jest takie dane przechwycić, gdy stosowany
jest SSL wszystkie informacje przesyłane między klientem a serwerem są zaszyfrowane. SSL
realizuje szyfrowanie, uwierzytelnienie serwera (ewentualnie użytkownika również) 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.
Certyfikat SSL - Na początku nawiązywania połączenia SSL klient i serwer wymieniają się
tzw.: certyfikatami. 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,
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,
zwane w skrócie CA (ang. Certyfing Authorities). Na całym świecie jest tylko kilka tego typu
instytucji i z założenia wszystkie są godne zaufania. Certyfikat rejestrowany jest na konkretną
nazwę domeny, np. www.firma.pl i zawiera dane o jego właścicielu. Istnieją również
certyfikaty typu wildcard, które można użyć na dowolną ilość poddomen (np. www.firma.pl,
sklep.firma.pl, poczta.firma.pl). Wszystkie wystawiane certyfikaty zapewniają 128-bitowe
szyfrowanie, które jest w tej chwili najczęściej stosowane m.in. przez instytucje finansowe.

* Podpis elektroniczny - epodpis - to 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. Podpisem elektronicznym możemy
sygnować pocztę e-mail lub inne dokumenty wirtualne. Dzięki posługiwaniu się podpisem
elektronicznym przesyłane dokumenty elektroniczne docierają do adresatów w stanie
nienaruszonym. Każda, nawet przypadkowa, zmiana w treści przesyłki jest sygnalizowana
przez komputer odbiorcy. 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.

* Netykieta - jest to zbiór zasad kultury obowiązującej wszystkich w Internecie. Każdy
użytkownik jest odpowiedzialny za swoje działania oraz czyny w sieci.

* SPAM - Spam, określany również 'UCE' unsolicited commercial email (niezamawiany
komercyjny email) lub 'UBE' unsolicited bulk email (niezamawiany wielokrotny email) - to
takie informacje lub przesyłki, których odbiorca sobie nie zażyczył ani wcześniej na nie się
nie zgodził. Najczęściej do niczego mu niepotrzebne, powodujące nieekonomiczne
wykorzystanie użytych do przesyłki zasobów, często wywołujące irytację


* Czarne listy - w przypadku SPAM-u są to ogólno dostępne listy SPAM-erów ( nadawców
wysyłających niechciane wiadomości ), za pomocą takowych list, można blokować na

serwerach pocztowych przychodzące wiadomości. Budzą jednak one wiele kontrowersji
ponieważ nadgorliwi administratorzy często przez pomyłkę blokują możliwość wysyłania
poczty internautom umieszczając ich adres na czarnej liście.

Część praktyczna

1. Konfiguracja programu Thunderbird. Poniżej przedstawiono wybrane zrzuty ekranu z
dokonanej konfiguracji.

2.Wysłanie wiadomości pocztowej:
a) na nieistniejący serwer.

Odpowiedź:

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

[e-mail]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We
recommend contacting the other email provider for further information about the cause of this
error. The error that the other server returned was: 550 550 user not found... podany
uzytkownik nie istnieje... (state 14).

----- Original message -----

Received: by 10.86.74.4 with SMTP id w4mr291075fga.11.1240843305552;
Mon, 27 Apr 2009 07:41:45 -0700 (PDT)
Return-Path: <

[e-mail]

>

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

by

mx.google.com

with ESMTPS id l12sm5679694fgb.16.2009.04.27.07.41.25

(version=TLSv1/SSLv3 cipher=RC4-MD5);
Mon, 27 Apr 2009 07:41:44 -0700 (PDT)
Message-ID: <

[e-mail]

>

Date: Mon, 27 Apr 2009 16:40:07 +0200
From: Ala <

[e-mail]

>

User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail]
Subject: p1
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit

podaj cegłę


----- End of message -----

Wniosek: Odstęp czasowy- 1 min 37 sek., ilość prób-1.

b) do nieistniejącego użytkownika na istniejącym serwerze pocztowym

Odpowiedź:
This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

[e-mail]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We
recommend contacting the other email provider for further information about the cause of this

error. The error that the other server returned was: 550 550-5.1.1 The email account that you
tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1

http://mail.google.com/support/bin/answer.py?answer=6596

24si4315884bwz.16

(state 14).

----- Original message -----

Received: by 10.86.91.3 with SMTP id o3mr3316548fgb.46.1240843386945;
Mon, 27 Apr 2009 07:43:06 -0700 (PDT)
Return-Path: <

[e-mail]

>

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

by

mx.google.com

with ESMTPS id d6sm5773792fga.2.2009.04.27.07.43.06

(version=TLSv1/SSLv3 cipher=RC4-MD5);
Mon, 27 Apr 2009 07:43:06 -0700 (PDT)
Message-ID: <

[e-mail]

>

Date: Mon, 27 Apr 2009 16:41:49 +0200
From: Ala <

[e-mail]

>

User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To:

[e-mail]

Subject: p2
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit

podaj cegłę


----- End of message -----

Wniosek: Odstęp czasowy- 1 min 17 sek., ilość prób-3.


c) do komputera, który istnieje, ale nie działa na nim serwer poczty

Odpowiedź:
This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

[e-mail]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We
recommend contacting the other email provider for further information about the cause of this
error. The error that the other server returned was: 550 550 5.7.1
<

[e-mail]

>... Relaying denied (state 14).

----- Original message -----

Received: by 10.103.222.1 with SMTP id z1mr3271877muq.51.1240843609743;
Mon, 27 Apr 2009 07:46:49 -0700 (PDT)
Return-Path: <

[e-mail]

>

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

by

mx.google.com

with ESMTPS id j6sm207348mue.1.2009.04.27.07.46.49

(version=TLSv1/SSLv3 cipher=RC4-MD5);
Mon, 27 Apr 2009 07:46:49 -0700 (PDT)
Message-ID: <

[e-mail]

>

Date: Mon, 27 Apr 2009 16:45:32 +0200
From: Ala <

[e-mail]

>

User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To:

[e-mail]

Subject: p3
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit

podaj cegłę


----- End of message -----

Wniosek: Odstęp czasowy- 1 min 17 sek., ilość prób-1.

3.

Analiza zawartości nagłówków pakietów TCP przesyłanych między klientem a serwerem
poczty z pomocą programu windump

Do wykonania ćwiczenia został wykorzystany program Wireshark. Wybrane fragmenty:

No. Time Source Destination Protocol Info

5 14.077984 81.190.45.40 209.85.135.111 TCP 3033 > 587 [SYN] Seq=0
Len=0 MSS=1460

Frame 5 (62 bytes on wire, 62 bytes captured)

Ethernet II, Src: Asiarock_44:0d:b9 (00:19:66:44:0d:b9), Dst: Cisco_01:7c:c7 (00:13:5f:01:7c:c7)

Internet Protocol, Src: 81.190.45.40 (81.190.45.40), Dst: 209.85.135.111 (209.85.135.111)

Transmission Control Protocol, Src Port: 3033 (3033), Dst Port: 587 (587), Seq: 0, Len: 0

No. Time Source Destination Protocol Info

7 14.133607 81.190.45.40 209.85.135.111 TCP 3033 > 587 [ACK] Seq=1
Ack=1 Win=65535 Len=0

Frame 7 (54 bytes on wire, 54 bytes captured)

Ethernet II, Src: Asiarock_44:0d:b9 (00:19:66:44:0d:b9), Dst: Cisco_01:7c:c7 (00:13:5f:01:7c:c7)

Internet Protocol, Src: 81.190.45.40 (81.190.45.40), Dst: 209.85.135.111 (209.85.135.111)

Transmission Control Protocol, Src Port: 3033 (3033), Dst Port: 587 (587), Seq: 1, Ack: 1, Len: 0

4.

4.

4.

4.

Wysłanie i odebranie wiadomości łącząc się z serwerem poczty za pomocą dowolnego klienta
protokołu telnet.

Wszystkie operacje były wykonywane w programie Putty.

Wysyłanie wiadomości:

Odbieranie wiadomości:

5.

5.

5.

5.

Przesłanie wiadomości zaszyfrowanej/podpisanej za pomocą PGP/certyfikatu SSL i
przeanalizowanie podsłuchu tej transmisji za pomocą programu ethereal.

No. Time Source Destination Protocol Info

9 14.182164 81.190.45.40 209.85.135.111 TCP 3033 > 465 [PSH, ACK]
Seq=1 Ack=43 Win=65493 Len=18

Frame 9 (72 bytes on wire, 72 bytes captured)

Ethernet II, Src: Asiarock_44:0d:b9 (00:19:66:44:0d:b9), Dst: Cisco_01:7c:c7
(00:13:5f:01:7c:c7)

Internet Protocol, Src: 81.190.45.40 (81.190.45.40), Dst: 209.85.135.111 (209.85.135.111)

Transmission Control Protocol, Src Port: 3033 (3033), Dst Port: 465 (465), Seq: 1, Ack: 43,
Len: 18

Data (18 bytes)

No. Time Source Destination Protocol Info

12 14.268378 81.190.45.40 209.85.135.111 TCP 3033 > 465 [PSH, ACK]
Seq=19 Ack=182 Win=65354 Len=10

Frame 12 (64 bytes on wire, 64 bytes captured)

Ethernet II, Src: Asiarock_44:0d:b9 (00:19:66:44:0d:b9), Dst: Cisco_01:7c:c7
(00:13:5f:01:7c:c7)

Internet Protocol, Src: 81.190.45.40 (81.190.45.40), Dst: 209.85.135.111 (209.85.135.111)

Transmission Control Protocol, Src Port: 3033 (3033), Dst Port: 465 (465), Seq: 19, Ack: 182,
Len: 10

Data (10 bytes)

6.

6.

6.

6.

Skonfigurowanie programu Thunderbird do pracy z systemem NNTP news.man.lodz.pl i
przetestowanie jego działania wysyłając wiadomość do grupy pl.test .

Wybrane zrzuty ekranu:

Prawidłowo skonfigurowano program Thunderbird lecz nie można było wysłać wiadomości
do grupy pl.test.