zad_3_grupa

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 <1896.697170952@dbc.mtview.ca.us>

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
<1896.697170952@dbc.mtview.ca.us>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.
info@carbondesign.pl czy help@carbondesign.pl 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 <prz@acm.org>
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

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

    ktos@cos.pl

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

ala.lenart@gmail.com

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

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

49F5C3C7.5090007@gmail.com

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

ala.lenart@gmail.com

User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: ktos@cos.pl
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:

5guvut76@gmail.com

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

ala.lenart@gmail.com

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

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

49F5C42D.5090209@gmail.com

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

ala.lenart@gmail.com

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

5guvut76@gmail.com

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:

cokolwiek@thedukesoft.com

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

ala.lenart@gmail.com

Received: from ?10.4.0.25? (

pc24.zsk.p.lodz.pl

[212.51.220.24])

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

49F5C50C.5080402@gmail.com

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

ala.lenart@gmail.com

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

cokolwiek@thedukesoft.com

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.

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

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:

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)

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: