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

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

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

---