Usługa poczty

Ostatnio aktualizowano 15 kwietnia 2006 r.

Teoria:

* 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 wymusic przechowanie jej na serwerze ( jest to przykład dostępnych operacji inną może być możliwość usuwania poczty z 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ługe POP. Wersji protokołu było kilka w latach 80-tych używany był protokół POP2, obecnie stosuje się protokół POP3, który jest bierzącym standardem ( opisany w RFC 1939, oraz zarysie standardu STD 53 )
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.

Komendy w POP3 zawierają "niewrażliwe" na wielkość słowa kluczowe, za którymi podawanych jest od 1 do kilku paramnetrów. Wszystkie komendy zakończone są znakami CRLF (Carrige Return Line Feed). Słowa kluczowe oraz parametry podawane do komend "zawierają" drukowalne zanki ASCII, oddzielone są od siebie ( zarówno słowa kluczowe jak i parametry ) pojedyńczym znakiem spacji. Słowa kluczowe mają dlugość do 4 znaków, a każdy z argumentów może mieć do 40 znaków długości.

Odpowiedzi w POP3 zawierają znacznik statusu i słowa kluczowe po których występują często dodatkowe informacje. Wszystkie odpowiedzi zakończone są znakami CRLF. Odpowiedzi mogą mieć długość do 512 znaków wliczając w to znaki CRLF, obecnie stosowane są wyłącznie dwa znaczniki statusu pozystywny: "+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ę z 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 Tranzakcji ( TRANSACTION state ), w tym stanie klient wydaje komendy dotyczące zarządania 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ęcte przed rozpoczęciem stanu Tranzakcji poczym "żegna się". Zaraz po tym zamykane jest połączenie TCP.

Serwer musi na nie rozpoznaną lub nie zaimplementowaną komendę negatywnym znacznikiem statusu, podobnie jest w przypadku komendy wysłanej w trakcie niewłaściwego stanu sesji.

Stan Autoryzacji - gdy nastapił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 zidentyfikowac się i potwierdzić swoją "tożsamość" serwerowi POP3. Sposobami na uwierzytelnianie sa 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 przchodzi w stan Tranzakcji.

Stan Tranzakcji - 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 Tranzakcji:
* STAT - brak parametrów wywołania - po wysłaniu tej komendy serwer POP3 zwraca odpowiedź, zawierającą liczbę wiadomości oraz rozmiar zasobu wiadmości wyrażoną w oktetach. Format odpowiedzi może wyglądać nastepują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 wiadmości, nie może się odnosic do wiadmości oznaczonej jako usuniętej. Jeżeli podany został parametr, serwer POP3 zwraca tzw.: "scan listing" dotyczący wiadmości - linia zawierająca wiadmości dotyczące wybranej wiadmości. Jeżeli komenda została wydana bez parametru, serwer zwraca informacje dla każdej wiadmoś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 maildrop

* RETR msg - parametrem komendy jest ( wymagany ) numer wiadmości, numer ten nie może dotyczyć widomości oznaczonej jako usuniętej. Jeżeli serwer zwróci pozytywną odpowiedź, jest to odpowiedź wieloliniowa. Serwer wysyła klientowi żądaną wiadmość. W przypadku odpowiedzi negatywnej serwer wysyła odpowiedź o braku wiadmoś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 wiadmości, numer ten nie może dotyczyć widomości oznaczonej jako usuniętej. Serwer POP3 oznacza wiadmość jako usuniętą, nie usuwa jej jednak fizycznie dopóki sesja nie przejdzie w stan Aktualizacji. Jakie kolwiek próby odwoływania sie do wiadmoś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 paramterów wywołania, serwer POP3 nie wykonuje, żadnej operacji prócz wysłania pojedyńczej linii pozytywnej odpowiedzi +OK.

K: NOOP
S: +OK

* RSET - brak parametrów wywołania, Jeżeli na serwerze znajdują się wiadmości oznaczone jako usunięte, zostają one "odznaczone". Serwer POP zwraca odpowiedź +OK

K: RSET
S: +OK maildrop has 2 messages (320 octets)

Stan Aktualizacji ( Update State ) - wraz z wydaniem przez klienta komendy QUIT, sesja przechodzi w stan Aktualizacji, inczaej 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 wiadmości.

* QUIT - brak argumentów - serwer usuwa wszystkie wiadmoś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 (maildrop empty)
...
K: QUIT

Dodatkowe Komendy protokołu POP3

Komendy wymienione w sekcji opisującej stan Tranzakcji stanowią bazę komend określających minimalną implementację protokołu POP, która powinnna znaleźć sie 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 wiadmości który nie może się odnosić do wiadmości oznaczonej jako usuniętej, oraz dodatnia liczba określająca ilość linii. Komeda może być wydana wyłącznie w stanie Tranzakcji. Serwer POP3 wysyła określoną liczbę linii nagłówka wybranej wiadomości, jeżeli żądana ilość linii przekracza rozmair nagłówka serwer POP zwraca całą wiadmość.

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 wiadmości, nie może się odnosic do wiadmości oznaczonej jako usuniętej. Komeda może być wydana wyłącznie w stanie Tranzakcji. Jeżeli numer wiadmości został podany serwer POP zwraca tzw.: "unique-id listing" dla żądanej wiadmości. Jeżeli komenda została wydana bez parametru, serwer zwraca "unique-id listing" dla każdej wiadmości. "unique-id listing" wiadmości jest to łańcuch znaków określany przez serwer, zwierający od jednego do 70 znaków z przedziału od 0x21 do 0x7E, jednoznacznie identyfikujący wiadmość 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 maildrop

* USER name - parametr wymagany, jednoznacznie okresla "konto" na serwerze. Komenda moze być wyłącznie wydana w stanie Autoryzacji, po otrzymaniu poitania od serwera lub nie pomyślnej identyfikacji komendami USER i PASS. Po otrzymaniu poztywnej odpowiedzi od serwera klient może wydac albo komendę PASS podajac haslo 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 haslo na "konto" na serwerze POP3, komenda może być wydana jedynie po pozytywnej odpowiedzi na komende USER. Serwer moze zwrocic pozytywna odpowiedź, oznaczająca pozwolenie na zarzadzanie zasobami "konta", lub blędy oznaczające albo niepoprawne haslo lub brak możliwosci zarezerwowania zasobow dla konta.

K: USER mrose
S: +OK mrose is a real hoopy frood
K: PASS secret
S: -ERR maildrop already locked
 ...
K: USER mrose
S: +OK mrose is a real hoopy frood
K: PASS secret
S: +OK mrose's maildrop 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 sluzy 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. lient wydający komendę APOP musi podać nazwę urzytkownika ( 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 maildrop 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 - projekt protokołu SMTP oparty jest na następującym modelu komunikacji:

-------------------------------------------------------------

   
               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Sender- |Commands/Replies| Receiver-|
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
   

                Sender-SMTP                Receiver-SMTP
				
				
-------------------------------------------------------------

Schemat 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 komende RCTP identyfikujaca odbiorce wiadomosci. 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 tranzakcji ponieważ Sender-SMTP i Receiver-SMTP mogą "negocjować" kolejnych odbiorcow. Gdy uzgodnieni zostaną wszyscy odbiorcey 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 tranzakcja poczty. Dalej opisane są procedury przekazywania poczty, sprawdzania nazw skrzynek pocztowych, rozszerzania list pocztowych, otwierania i zamykania połączeń.

* MAIL - są 3 kroki podczas tranzakcji pocztowej, tranzakcja rozpoczynana jest komenda MAIL identyfikującą wysyłąjącego, poźniej seria komend RCPT identyfikujących odbiorce wiadmości, komenda DATA określająca początek danych zawierających wiadomość. I ostatecznie znacznik końca wiadmości potwierdzający całą tranzakcję pocztową.

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

Ta komenda mówi serwerowi, że nowa tranzakcja 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 zawierac listę host-ow do których zostana 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 zachwouje 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 tranzakcji pocztowej. Serwer powinien zwrócić wtedy odpowiedź 250 OK. Komenda DATA może zakończyć się niepowodzeniem jedynie gdy tranzakcja była niepełna ( np.: brak odbiorców dla listu ) lub gdy serwer nie ma wolnych zasobów. Poniżej znajduje się przykład tranzakcji pocztowej:

S: MAIL FROM:<andrey@Alpha.ARPA>
R: 250 OK

S: RCPT TO:<ra88@Beta.ARPA>
R: 250 OK

S: RCPT TO:<salvin@Beta.ARPA>
R: 550 No such user here

S: RCPT TO:<koojav@Beta.ARPA>
R: 250 OK

S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK

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 ja 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 host-cie, przekazuje odpowiedź klientowi z poprawnym wg. niego adresem lecz nie bierze dalej udziału w przekazywaniu poczty. Poniżej przykłady:

S: RCPT TO:<Postel@USC-ISI.ARPA>
R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>

lub

S: RCPT TO:<Paul@USC-ISIB.ARPA>
R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>

SMTP dostarcza dodatkową funkcjonalność jaką jest sprawdzania 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. Poniżej przykład z możliwymi odpowiedziami serwera:

S: VRFY Smith
R: 250 Fred Smith <Smith@USC-ISIF.ARPA>

lub

S: VRFY Smith
R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>

lub

S: VRFY Jones
R: 550 String does not match anything.

lub

S: VRFY Jones
R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
			
lub

S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.

EXPN - komenda pobiera jako argument nazwę mailing listy, serwer daje odpowiedź wieloliniowa zawierającą adresy skrzynek pocztowych należących do danej mailing listy. Poniżej przykład:

S: EXPN Example-People
R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-<joe@foo-unix.ARPA>
R: 250 <xyz@bar-unix.ARPA>

lub

S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.

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 tranzakcji 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 stestowa
250 poczta.o2.pl

- QUIT <CRLF>

Jak łatwo sie domyślic ta komenda zamyka połączenie i kończy tranzakcję 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 zbiór odpowiedzi serwera podzielonych "tematycznie", odpowiedzi te należą do minimalnej implementacji protokołu SMTP:

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

211 System status, or system help reply - odpowiedz na zapytanie o pomoc
214 Help message [Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user] - odpowiedz zawierajaca pomoc

220 <domain> Service ready - serwer gotowy na odbieranie komend
221 <domain> Service closing transmission channel - zamykanie kanalu transmisyjnego
421 <domain> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down] - usluga niedostepna, kanal transmisyjny zostanie zamkniety

250 Requested mail action okay, completed - zadana komenda zostala wykonana pomyslnie
251 User not local; will forward to <forward-path> - skrzynka nie znajduje sie na tym serwerze, serwer przekaze poczte
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] - skrzynka jest nie dostepna np.: z powodu braku zasobow
550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] - skrzynka niedostepna np.: z powodu braku autoryzacji
451 Requested action aborted: error in processing - blad podczas przetwarzania komendy
551 User not local; please try <forward-path> - skrzynka nie znajduje sie na serwerze, serwer podpowiada lokalizacje skrzynki
452 Requested action not taken: insufficient system storage - brak wolnych zasobow systemowych serwera
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] - adres ma niepoprawna skladnie
354 Start mail input; end with <CRLF>.<CRLF> - znacznik okreslajacy sposob zakańczania wiadomość
554 Transaction failed - tranzakcja pocztowa nie została wykonana pomyślnie


* 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 standardow ( wersji ) protokołu IMAP: IMAP2, IMAP3 oraz IMAP4rev1. Informacje, które znajduja sie poniżej generalnie odnosza się i sa zgodne z kazda wersją tego protokołu.

Połączenie IMAP składa się z akcji odpowiedzialnych za ustalenie połączenia mięzy 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 bierząco je analizuje. Klient musi podjąc 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 zarzą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 zamisat wysyłać zapytanie do serwera.

Każda wiadomość ma swoje atrybuty, atrybuty te mogą byc pobierane pojedyńczo 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 wartosc 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ścia 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 bierzą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 niedkończona i oznaczona jako szkic
\Recent
Wiadomość właśnie nadeszła, i zostaje poraz pierwszy wyświetlona w bierzącej sesji.

Atrybut wewnętrznej daty wiadomości ( Internal Date Message Attribute ) - jest to data i czas odzwierciedlający date 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 sktruktury 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ż nie które komendy wydawane przez klienta mogą być wydane tylko w jednym konkretnym stanie sesji IMAP. Rozróznia się:

* Stan braku autoryzacji ( Not Authenticated State ) - w tym stanie sesji klient musi podac dane autoryzujace jego dostep do zasobow 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 wybrac skrzynke na ktorej bedzie dzialac.

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

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

Poniżej diagram stanów sesji

                   +----------------------+
                   |połączenie nawiązane  |
                   +----------------------+
                              ||
                              \/
            +--------------------------------------+
            |        powitanie serwera             |
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      \/           ||            ||
            +-----------------+    ||            ||
            |Not Authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       \/           \/            ||
             ||     +----------------+           ||
             ||     | Authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       \/       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |Selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             \/       \/       \/                \/
            +--------------------------------------+
            |               Logout                 |
            +--------------------------------------+
                              ||
                              \/
                +-------------------------------+
                |obie strony zamknęły połączenie|
                +-------------------------------+
 

(1) połączenie bez wstępnej autoryzacji
(2) połączenie ze wstępna autoryzacją
(3) odrzucone połączenie
(4) pomyślne logowanie do serwera
(5) pomyślna komenda SELECT
(6) komenda CLOSE lub nieudana komenda SELECT
(7) komenda LOGOUT, wyłączenie się serwera lub zamknięcie połączenia

Komendy klienta IMAP:
* NOOP - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( zle wywolanie 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 ( zle wywolanie 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 ( zle wywolanie 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 wskazujacy sposob autoryzacji. Komenda może zwrócić odpowiedzi: OK ( pomyślna autentykacja ), NO ( nie udana autentykacja, brak podanego mechanizmu autentykacji ) lub BAD ( zle wywolanie 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 ( zle wywolanie lub nieodpowiednie argumenty ).

* SELECT - jako argument podawana jest nazwa skrzynki, na ktorej mają być wykonywane inne komendy. Serwer w odpowiedzi zwraca dane dotyczace skrzynki, ilosc istniejacych wiadomosci, ilosc nowych wiadomosci, ilosc nieprzeczytanych wiadomosci itd. wszystkie te informacje poprzedzone są znacznikiem "*", serwer zwraca tez odpowiedzi OK ( pomyślne wykonanie polecenia, przejscie w stan wyboru ), NO ( brak skrzynki o podanej nazwie ) lub BAD ( zle wywolanie lub nieodpowiednie argumenty ).

* EXAMINE - komedna ta dziła identycznie jak komenda SELECT, zwraca tez te same informacje jednak nie powoduje, żę 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 mozna stworzyc skrzynki o podanej nazwie ) lub BAD ( zle wywolanie 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 mozna usunać skrzynki o podanej nazwie ) lub BAD ( zle wywolanie 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 mozna zmienić nazwy skrzynki ) lub BAD ( zle wywolanie 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 ( zle wywolanie lub nieodpowiednie argumenty ).

* CHECK - brak argumentów wywołania, brak specyficznych odpowiedzi na ta komendę wynikiem są tylko odpowiedzi OK ( wykonanie komendy ) lub BAD ( zle wywolanie 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 ( zle wywolanie lub nieodpowiednie argumenty ). Komenda ta usuwa permanentnie wszystkie wiadomości które mają ustawioną flage /Deleted i powraca do stanu autetykacji ze stanu wyboru.

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

* SEARCH - wyszukuje wiadomosci spełniajace zadane kryteria. Jako odpowiedź zwraca wiadomosci oraz odpowiedz OK ( pozytywne wykonanie komendy ), NO ( brak wiadomosci spelniajacych kryteria ) lub BAD ( zle wywolanie lub nieodpowiednie argumenty )

* FETCH - pobiera dane zwiazane z wiadomoscia 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 dzisią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 siecia usenet
+ rec - Rekreacja
+ sci - Nauka
+ soc - Społeczeństwo
+ talk - Dyskusje ogólne
Inne popularne hierarchie to:
+ alt - hierarchi grup alternatywnych
+ bionet - Biologia
+ clari - Informacje na żywo z agencji Reuters
+ k12 - "Kindergarden through 12th grade"

W celu ograniczenia nie porozumień tradycyjnie dla wygody użytkowników wydziela się hierarchie związane z wykorzystywanym językiem. Poszczególne kraje mają własne hierarchie np.:

+ ch - Szwajcaria
+ fr - Francja
+ de - Neimcy
+ pl - Polska

Hierarchiczne uporządkowanie Usenet-u w istotny sposób ułatwia odnalezeienie w mnogości poruszanych tematów takiego, który zaspokoi najbardziej wyrafinowane potrzeby. Najprostszym przykładem może być 350 grup zawierajacych w nazwie słowo "unix". Do najaktywniejszych należą comp.unix.solaris i comp.unix.aix. Tego typu nazwy w jasny sposób okreslają podstawowa tematyke 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ć odzielone pojedyncza spacja, komedny 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 komenda musi być zakończona CRLF. Linia zawierająca komendę wraz z parametrami nie może przekroczyć 512 znaków.

Odpowiedzi serwera dzielimy tekstowe i linie statusu. Odpowiedzi tekstowe wystepuja jedynie po odpowiedziach zawierajacych status. Linia z odpowiedzia zawierajaca status zaczyna sie od 3 cyfr, które jednoznacznie okreslaja wynik operacji. Pierwsza cyfra oznacz sucec, porażkę lub to że operacja jest w toku
1xx - Informative message - odpowiedz zawierajaca informacje.
2xx - Command ok - odpowiedz oznaczajaca, ż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 czkea 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 wyswietla 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 liczbe wszystkich artykułów w grupie.
* HELP - serwer zwraca klientowi liste dostepnych komend jakie może wydać klient.
* IHAVE messageid - komedna informuje serwer, że klient posiada artykuł o podanym numerze, jeżeli serwer zarzyczy sobie pobrać artykuł wyśle klientowi szczegołowe instrukcje jak to ma zrobić.
* LAST - serwer w odpowiedzi na tą komendę zwraca numer bierzącego artykułu
* LIST - zwraca listę istniejących grup dyskusyjnych na serwerze.
* NEWGROUPS date time [GMT] - zwraca liste grup dyskusyjnych utworzonych od czasu podanego w parametrze date time
* NEWNEWS newsgroups date time [GMT] - zwraca liste numerow artykułów które zostały wysłane na grupę dyskusyjna od podanej daty.
* NEXT - zwraca następny artykuł, w stosunku do wskaźnika bierzą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 wysyla 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


* Skrzynki pocztowe, najczęściej używane parametry, adresy, aliasy <--- tutaj.

* 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 wiadmoś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ąrzą 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 wyglądających np tak:

M YP.?4)W0DI38Y0+E:JKK)50K:J2 *R$E*P0E'R5?!0^4CBH#+:PJU##Q*XP
MOST"2A7+SS,1EM-Q#]05GE$SKVD O J[5K!*8^*_R1"J4IIES>@/.VWRG=+A
M:>"I[+JK3_KCK/RYV#'J@C4G]B@0G#1%5A9OUPY2D!AH2I*%#: YT/'^28'&

Plik zawierający dźwięk został zmieniony w "międzyczasie" z formatu stosowanego na jednym komputerze na format stosowany na drugim.

Gdzie w tym wszystkim kodowanie wiadomości pocztowej? Popatrzmy na polskie litery, sytuacja obecnie jest taka, że istnieje ponad 20 sposobów ich kodowania. Każdy z systemów operacyjnych Windows, DOS, Linux, Unix czy Mac może kodować znaki w odmienny sposób nie dość tego nawet programy na tej samej maszynie mogą kodować znaki inaczej. Dzięki MIME, można z taką sytuacją poradzić sobie w dość prosty sposób. Otóż 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 w ogó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 (zwracam uwage: po from nie ma dwukropka)
- 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 dobiorcy 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 sa to listy adresów pocztowych służące do masowego rozsyłania wiadomosci do wszystkich użytkowników na ta liste zapisanych . Aby wyslac taka wiadomosc wysylamy jej tresc do servera udostepniającego taka usługe (przewaznie na adres bedacy identyfikatorem dajen grupy mailingowej) który dalej rozsyła wiadomosci do skrzynek urzytkowników subskrybujących dana liste.

* Komputery ktorych glównym zadaniem jest przetwarzanie poczty nazywane sa bramami pocztowymi. Są one najczesciej wykorzystywane w momencie kiedy lista adresatów, do których ma trafić kopia naszej wiadomości jest długa. W momencie wyslania takiej wiadomosci nasz klient nie probuje sam przekazywac wiadomosci tylko przesyła ja do bramy ktora to rozsyla wiadomości do adresatow.

* Aliasy sa to alternatywne identyfikatory tej samej skrzynki pocztowej np. info@carbondesign.pl czy help@carbondesign.pl moga wskazywac na ta sama skrzynke.

* 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) - Algorytm ten jest w USA opatentowany, a ponadto podlega restrykcjom eksportowym ITAR i nie może być używany w programach wywożonych z USA, dlatego poza USA stosuje się algorytm który opracował Stale Schumacher <staalesc@ifi.uio.no> Obie wersje są wzajemnie zgodne.

PGP nie szyfruje całego dokumentu (np. listu) z użyciem algorytmu RSA - ponieważ jest on dość powolny, trwałoby to bardzo długo. 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. Jaki jest stan prawny podpisów elektronicznych w Polsce:
W połowie sierpnia zaczyna praktycznie działać ustawa o podpisie elektronicznym. Podpisana 11 października 2001 przez prezydenta RP i opublikowana w Dzienniku Ustaw 15 listopada 2001 r. z mocy Art. 59 ust. 1 ustawa wchodzi w życie 9 miesięcy po opublikowaniu.
Ustawa mówi:

"Podpis elektroniczny - dane w postaci elektronicznej, które wraz z innymi danymi, do których zostały dołączone lub z którymi są logicznie powiązane, służą do identyfikacji osoby składającej podpis elektroniczny" (Art. 3 ust. 1), oraz:

"Bezpieczny podpis elektroniczny to podpis elektroniczny, który:
a) jest przyporządkowany wyłącznie do osoby składającej ten podpis,
b) jest sporządzany za pomocą podlegających wyłącznej kontroli osoby składającej podpis elektroniczny bezpiecznych urządzeń służących do składania podpisu elektronicznego i danych służących do składania podpisu elektronicznego,
c) jest powiązany z danymi, do których został dołączony, w taki sposób, że jakakolwiek późniejsza zmiana tych danych jest rozpoznawalna" (Art. 3 ust. 2).

* Netykieta - jest to zbiór zasad kultury obowiązującej wszystkich (sic!) w Internecie. Edukacyjny wortal, www.eduseek.pl, podaje następującą definicję: "Netykieta jest zbiorem niepisanych reguł dobrego zachowania użytkowników Internetu. Nie jest ona kontrolowana ani sankcjonowana przez żadne organizacje, ale stosowanie się do niej może ułatwić komunikację między użytkownikami sieci". Za pierwszy kompleksowy zbiór zasad korzystania z Internetu uchodzi opracowanie Arlene H. Rinaldi z Florida Atlantic University - we wstępie do swojej netykiety pisze, iż podstawowa dla użytkownika sieci jest jego świadomość z posiadania dostępu do światowych zasobów wiedzy w postaci serwisów, stron www, systemów i ludzi. Każdy użytkownik jest odpowiedzialny za swoje działania oraz czyny w sieci. Internet nie jest jednolitą siecią, lecz składa się z tysięcy sieci połączonych ze sobą. Sieci te różnią się od siebie, co oznacza, że niektóre działania, będące normalnymi procedurami postpowania w jednych sieciach czy systemach, w innych mogą być ograniczone lub wręcz zabronione, gdyż mogą one prowadzić do nadużycia.

* 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ę. Spam powstał w latach '80 wraz z rozwojem Internetu, obecnie jest już poważnym problemem komunikacyjnym i finansowym nie tylko Internetu, ale ogólnie społeczeństwa informacyjnego. Etymologia słowa spam jest zabawna i godna poświęcenia kilku minut bowiem słowo to pochodzi najprawdopodobniej ze skeczu Monty Pythona i oznaczało mielonkę (ang. SPAM - Shoulder Pork and hAM"/"SPiced hAM). W skeczu tym klient, gdy pyta się o menu restauracji, dowiaduje się, że w każdym daniu znajduje się trochę mielonki. Gdy klient chce zamówić coś bez mielonki, specjalna grupa zagłuszaczy w strojach wikingów, zaczyna śpiewać "SPAM, SPAM, lovely SPAM, wonderful SPAM", zagłuszając normalną rozmowę. Tłumaczenie słowa SPAM żartobliwie podaje się również jako wyrażenie Stupid Person AdvertiseMent.

* 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 serwerch pocztowych przychodzące wiadomości. Budzą jednak one wiele kontrowersji ponieważ nadgorliwi administratorzy często przez pomyłkę blokują możliwość wysyłania poczty nie wiennym internautom umieszczając ich adres na czarnej liście.


Bibliografia:
POP3
ftp://ftp.rfc-editor.org/in-notes/rfc1939.txt
ftp://ftp.rfc-editor.org/in-notes/std/std53.txt
SMTP
ftp://ftp.rfc-editor.org/in-notes/rfc3501.txt
ftp://ftp.rfc-editor.org/in-notes/rfc821.txt
http://nss.et.put.poznan.pl/study/projekty/sieci_komputerowe/protokoly_pocztowe/html/smtp.html
NNTP
ftp://ftp.rfc-editor.org/in-notes/rfc977.txt
PGP
ftp://ftp.rfc-editor.org/in-notes/rfc2015.txt
http://pl.wikipedia.org/wiki/PGP_%28program_kryptograficzny%29
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
http://galaxy.uci.agh.edu.pl/~szymon/artykuly/pgp_opis.html
MIME
http://pl.wikipedia.org/wiki/MIME
http://en.wikipedia.org/wiki/MIME
http://www.ogonki.agh.edu.pl/mime.html
http://www.immt.pwr.wroc.pl/tool/node67.html
SSL
http://www.securitynet.pl/html/ssl.php
http://www.gigaone.pl/certyfikaty-ssl/
http://home.elka.pw.edu.pl/~lwojcick/ssl/ssl.html
www.ipsec.pl/prez/prez/oss-2001/referat.pdf
Open PGP
ftp://ftp.rfc-editor.org/in-notes/rfc2440.txt
Bezpieczenstwo
http://galaxy.uci.agh.edu.pl/~szymon/artykuly/iwp.html
http://galaxy.uci.agh.edu.pl/~szymon/artykuly/kryptografia.html
Netykieta
http://www.netykieta.prv.pl/
http://www.pg.gda.pl/~agatek/netq.html
SPAM
http://pl.wikipedia.org/wiki/Spam
http://echelon.pl/pubs/spam-faq.html
http://nospam-pl.net/spam.php
Czarne listy
http://www.jachnicki.pl/257/id_art/818/
http://sunsite.icm.edu.pl/spam/
Podpis elektroniczny
http://podpis.onet.pl/
http://www.e-podpis.pl/
http://www.networld.pl/artykuly/23340.html



Praktyka:

1) Skonfigurować program Thunderbird do pracy z własnym kontem pocztowym na serwerze zsks.zsk.p.lodz.pl. Poniżej znajdują sie linki do zrutów z kernau kolejnych etapów konfiguracji klienta poczty Mozilli Thunderbird: 1, 2, 3, 4, 5, 6

2) Wysłać wiadomości pocztowe
a) na nieistniejący serwer pocztowy (nieprawidłowa nazwa DNS) tutaj
b) do nieistniejącego użytkownika na istniejącym serwerze pocztowym tutaj, komunikat klienta poczty: tutaj
c) do komputera, który istnieje, ale nie działa na nim serwer poczty. tutaj
W każdym z przypadków przeanalizować odpowiedzi "własnego" serwera poczty

3) Za pomocą programu windump i/lub ethereal przeanalizować zawartość nagłówków pakietów TCP przesyłanych między klientem a serwerem poczty. Do wykonania tego ćwiczenia użyliśmy programu Ethereal, poniżej znajdują się linki do plików z danymi jakie pobrał program. Protokół POP oraz protokół SMTP.

4) Wysłać i odebrać wiadomość łącząc się z serwerem poczty za pomocą dowolnego klienta protokołu telnet. Korzystanie z telentu nie jest zbyt rozsadnym rozwiazaniem dane bowiem przesyłane sa w postaci jawnej, chca sie zabezpieczyc w pewien sposob stworzylismy na potrzeby cwiczenia testowa skrzynke na serwisie www.o2.pl, jej adres to stestowa@o2.pl. Dla potrzeb protokołu SMTP wygenerowaliśmy hash hasla za pomoca kodu: printf 'stestowa/0stestowa/0tajne_haslo' | mimencode, polecenie to zwrocilo nam hash nastepujacej posatci: c3Rlc3Rvd2EAc3Rlc3Rvd2EAeXFmczM0 i z niego korzystalismy w dalszej komunikacji z serwerem SMTP.Tutaj znajduje sie przebieg komunikacji z serwerem podczas wysylania wiadomosci. Za pomocą telnetu połączyliśmy się także z serwerem POP tutaj jest zapis komunikacji.

5) Przesłać wiadomość zaszyfrowaną/podpisaną za pomocą PGP/certyfikatu SSL i przeanalizować podsłuch tej transmisji za pomocą programu ethereal. Z powodu braku narzę a pgp skorzystaliśmy z narzędzia o nazwie PGPfreeware 8.0 za jego pomocą wygenerowalismy klucz PGP i zaszyfrowalismy nim wiadomosc wyslana na inna skrzynkę pocztową. Ponizej znajduje sie klucz publiczny:
klucz, oryginał wiadomości, jej wersja zaszyfrowana oraz analiza programau ethereal

6) 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. Konfiguracja dla serwera grupy news.man.lodz.pl:
1, 2, 3, 4, 5, 6, 7 jednak próba wysłania wiadomości na którąś z dostępnych grup test kończyła się tym komunikatem o błędzie. Aby pokazać, iż wysyłanie do grup USENET-u jest możliwe skorzystaliśmy z serwera news.tpi.pl i z ich grupy pl.test. Obok znajdują sie zrzuty z ekranu przedstawiające wysyłaną wiadomość i ta samą wiadomość już na serwerze grupy: 1, 2, 3

Wiedza tylko wtedy jest wiedzą, kiedy zdobyta została wysiłkiem własnej myśli, a nie wyłącznie dzięki pamięci.

Poprawny XHTML 1.0! Poprawny styl CSS!hacker emblem open source emblem