Celem zajęć jest zapoznanie się z podstawowymi cechami popularnych protokołów poczty elektronicznej, a także przedstawiona zostanie konfiguracja klienta poczty. W trakcie laboratorium przetestowane będą także niektóre implementacje protokołów pocztowych za pomocą Telnetu. Przed przystąpieniem do ćwiczeń opisanych w sekcjach 2 i 3 proszę uważnie przestudiować informacje zawarte w sekcji pierwszej opisującej protokoły.

1. Protokoły pocztowe

Istnieje kilka czynników przemawiających na korzyść obsługiwania poczty przeznaczonej do dostarczenia na komputery osobiste i stacje robocze w centralnym serwerze pocztowym po to, aby na każde żądanie był do niej dostęp:

• Są sytuacje, gdy twój lokalny computer nie działa, jest przeciążony lub sieć do której jest podłączony jest przeciążone lub o niewielkiej przepustowości. Z drugiej strony komputer wysyłający pocztę potrzebuje mniej zasobów jeżeli computer odbierający jest w pełni sprawny.

• Niektórzy ludzie używają więcej niż jednej stacji roboczej lub komputera PC do korzystania z poczty elektronicznej.

• Stacja robocza lub computer PC może nie dysponować dostatecznymi zasobami potrzebnymi do odebrania, przechowywania całej poczty, jaką możesz otrzymać.

• Twój adres email może być podobny do adresów innych użytkowników.

Najprostszym sposobem na implementację jest takie uruchomienie centralnego serwera pocztowego jak każdego innego systemu wieloużytkownikowego, czyli tak, aby użytkownicy mogli się do niego „zapisać”, aby móc korzystać z jego usług pocztowych. Potem stacje robocze i komputery PC użytkowników mogą w trakcie sesji terminala logować się do serwera pocztowego i czytać swoją pocztę. Wadą takiego rozwiązania jest konieczność nauczenia się przez użytkowników pecetów czy stacji roboczych odpowiednich procedur obsługi poczty serwera pocztowego.

1.1. Protokół SMTP (Simple Mail Transfer Protocol)

The "internet" mail protocol used to deliver mail between multi-user systems only supports mail transfer initiated by the sender (actually, it has a method to initiate reception, but the method didn't catch on and is not used). Other protocols have been devised to allow a workstation or PC to request transfer of mail, thus able to make use of a central server. These include the published protocols POP (probably not used anymore), POP2, POP3, IMAP2, IMAP3 (not used), IMAP4 and DMSP.

1.2. Protokoły z grupy -Post Office Protocol (POP, POP2, POP3)

Wszystkie trzy są podobne, ale mimo wszystko na tyle różniące się od siebie, żeby pozostać niekompatybilnymi. Są zaprojektowane głównie w celu identyfikacji użytkownika za pomocą nazwy użytkownika i hasła, w celu umożliwienia przesyłania poczty z serwera do stacji roboczych i do kasowania przesłanej poczty. Do wysyłania poczty generalnie służy protokół SMTP. Poszczególne wiadomości mogą być ściągane pojedynczo, ale przed ściągnięciem wiadomości możemy się o niej dowiedzieć jedynie tego, jakiej jest ona wielkości w bajtach. To może być cenna informacja dla pecetów z ograniczonym dostępem dyskowym.

POP3 ma różne rozszerzenia, takie jak na przykład Xtnd Mit, które zezwalają klientom na wysyłanie poczty za jego pomocą zamiast korzystania z SMTP. Innym rozszerzeniem jest APOP umożliwiające enkrypcję haseł przesyłanych w sieci w standardzie RSA MD5.

POP3 jest teraz najbardziej powszechnym protokołem z tej grupy, chociaż POP2 jest wciąż stosowany. POP3 jest wyposażony także w kilka opcjonalnych rozszerzeń, np: nie wysyłanie haseł, lub ułatwiające czytanie grup dyskusyjnych.

1.3. Grupa protokołów Internet Message Access Protocol (IMAP2, IMAP3, IMAP4)

IMAP to grupa protokołów podobna do rodziny POP, ale oferuje klientom dodatkowo możliwość przeszukiwania “po stringu” poczty nadal znajdującej się na serwerze. Ta możliwości została zaprojektowana, aby umożliwić użytkownikom pecetów czy stacji roboczych podejmowanie decyzji, które wiadomościo mają zostać ściągnięte. Z drugiej strony protokoły POP są zaprojektowane dla prostszego oprogramowania serwerowego.

IMAP2 jest trochę używany w przeciwieństwie do IMAP3, który nie jest szeroko implementowany z powodów niekompatybilności. IMAP4 jest stosunkowo świeżym rozszerzeniem wersji drugiej tego protokołu.

1.4. Protokół IMSP (Interactive Mail Support Protocol)

IMSP jest rozwijany jako protokół uzupełniający IMAP4 oferujący usługi związane z pocztą e-mail wychodzące poza zasięg IMAP4. Są to na przykład możliwość wyszukiwania i zapisywania się do grup dyskusyjnych, skrzynek pocztowych oraz wyszukiwania i korzystania z książek adresowych.

1.5. Protokół DMSP - Distributed Mail Service Protocol (aka PCMAIL)

Pecety i stacje robocze mogą korzystać z tego protokołu zarówno, aby wysyłać jak i odbierać pocztę. Myślą przewodnią tego systemu jest możliwość korzystania przez użytkownika z więcej niż jednej stacji roboczej, jednakże implementacja tego założenia nie jest idealna. Zakłada się, że pecety i stacje robocze przechowują informację o stanie poczty i katalog pocztowy, a w momencie podłączania się do serwera katalog jest uaktualniany.

1.6. MIME - Multipurpose Internet Mail Extensions

MIME to relatywnie nowy standard internetowy dla formatu wiadomości wieloczęściowych i zawierających dane niezgodne ze standardem ASCII. MIME nie jest samo w sobie protokołem pocztowym.

Dowolny klient mający możliwość importu lub exportu plików jest w stanie korzystać z MIME przy pomocy aplikacji służącej do tworzenia i/lub dekodowania wiadomości MIME. Niektóre klienty pocztowe mają wbudowane specjalne funkcje tego typu. Generalnie, protokoły pocztowe typu klient-serwer zajmują się jedynie całymi wiadomościami i mogą „odzyskiwać” wiadomości w formacie MIME tak samo jak każdą inną wiadomość. Dzieje się tak między innymi dlatego, że MIME zostało specjalnie zaprojektowane w taki sposób aby nie sprawiać kłopotu istniejącym systemom pocztowym. Co prawda, IMAP4 posiada pewne cechy zezwalające na “odzyskiwanie” pojedynczych części wiadomości kodowanych w formacie MIME. Poniższa tabela wskazuje czy dany pakiet wspiera MIME. Serwery z zaimplementowanymi protokołami, które nie wspierają żadnych specjalnych cech MIME są oznaczone przez n/d (nie dotyczy), ponieważ nie wymagają na użytkownikach żadnego dodatkowego działania w celu obsługi MIME. Wszystkie serwery IMAP4 także wspierają takie cechy, ale tabela wskazuje czy zawierają one wsparcie dla MIME explicite.

Rozwiązania nie opisane: protokoły komercyjne, udostępnianie plików, interfejsy API, X.400. X.400 jest to transfer wiadomości zdefiniowany do użytku pomiędzy dostawcami usług telekomunikacyjnych i klientami międzynarodowego konsorcjum standaryzującego ISO. To praktycznie przekłada się na format nagłówków internetowych SMTP i RFC822. Organizacja dostawców X.400 - “XAPIA” wypracowała interfejs API dla aplikacji X.400, tzw. CMC.

1.7. Inne rozwiązania poczty e-mail

Dostawcy mogą używać swoich własnych protokołów podobnych do tych opisanych powyżej.

Poczta elektroniczna w sieciach lokalnych LAN może być także zaimplementowana za pomocą udostępniania plików, tzn. za pomocą NFS (Network File System), aby umożliwić osobnym Unixowym stacjom roboczym dzielić tę samą przestrzeć pocztową w taki sposób, jak by poczta była przechowywana w jednym systemie. To działa bardzo dobrze, pod warunkiem, że aplikacje są tak napisane, że dokładnie zamykają pliki. Zaletą takiego rozwiązania jest możliwość korzystania z dowolnego sieciowego protokołu plików, czyli aplikacje pocztowe mogą być w pewnym sensie niezależne od protokołu plików. Przykładowo systemy Unixowe mogą używać zarówno AFS (Andrew File System) jak i NFS. Pegasus jest aplikacją na PC i Mac a korzysta z usług plików Novella. Dokładna specyfikacja działania klient-serwer zawiera opis protokołu usług plików jak i budowę katalogów serwerowych i zasad przechowywania poczty.

Innym popularnym rozwiązaniem komercyjnych dostawców jest wykorzystanie API. Klient porozumiewa się z serwerem przy użyciu API (Applications Programming Interface), tzn. zestawu definicji wywołań procedur bibliotecznych w celu wykorzystania gotowych (istniejących) procedur do wysyłania, otrzymywania i manipulowania pocztą. Klient może zostać zlokalizowany na zdalnym komputerze z serwera za pomocą dowolnej procedury zdalnego wywołania (RPC). To umożliwia także mieszane użycie mechanizmów RPC (remote procedure call), wykorzystanie podstawowych stosów protokołów i API, tzn. dostawca definiuje API, i może to być uruchomione „ponad” IPX or TCP/IP, w każdym przypadku ponad mechanizmem RPC stosu protokołów. Istnieje obecnie sporo środowisk API proponowanych przez rozmaitych dostawców oprogramowania, np.: MAPI (Microsoft); VIM (Lotus); AOCE (Apple); SMF (Novell). Te API stały się podstawą dla dużej liczby aplikacji umożliwiających obsługę poczty, np. edytory tekstu pozwalają na wysyłanie lub odbiór dokumentów przez e-mail używając do tego celu po prostu jednego z powyższych API, które umożliwiają komunikację z serwerami obsługującymi te sama API. Dokładna specyfikacja działania klient-serwer zawiera opis od stosu protokołów przez opis protokołu RPC aż po opis samego API.

Zauważmy, że pomimo tego, że podejście z API i zdalnymi wywołaniami procedur umożliwia implementację poczty e-mail bez wykorzystania protokołów opisanych wcześniej (np. IMAP, POP, itp…), to teoretycznie nie ma żadnego powodu dla którego tego typu API nie mogłyby być użyte w środowisku IMAP czy POP. Potrzebne oprogramowanie mogłoby stanowić “sterownik” lub warstwę pośrednią kierującą wywołania API do aplikacji obsługujących pocztę email i wykorzytującą POP, IMAP, czy cokolwiek innego w sieci LAN w celu dostania się do serwera. Zalety i wady takiego rozwiązania w porównaniu do wykorzystania RPC są nadal dyskutowane. Przykładem oprogramowania klienckiego z zaimplementowanym MAPI i wykorzystującego POP3 w celu dostępu do serwera jest Mail-IT produkcji UniPalm.

2. Testowanie implementacji protołów poprzez Telnet

W czasie laboratorium należy przetestować działanie poleceń protokołów za pomocą połączenia Telnetowego do serwera pocztowego. Przetestujemy głównie dwa najbardziej powszechne protokoły: POP3 (odbieranie poczty) i SMTP (wysyłanie poczty).

Usługi protokołów pocztowych pracują na wyznaczonych specjalnych portach zależnych od konfiguracji serwera, którą zawsze można sprawdzić w dokumentacji. Jednakże standardowo są to porty numer 25 dla SMTP i 110 dla POP3.

2.1. SMTP (RFC 821)

2.1.1. Polecenia SMTP

HELO

To polecenie używane jest do identyfikacji nadawcy-SMTP przez odbiorcę-SMTP. Pole argumentu zawiera nazwę hosta nadawcy SMTP. Odbiorca SMTP sam identyfikuje się nadawcy w wiadomości potwierdzającej nawiązanie połączenia jako odpowiedź na to polecenie. Polecenie to i odpowiedź OK potwierdzają, że zarówno nadawca SMTP jaki i odbiorca SMTP znajdują się w stanie początkowym, tzn. nie ma żadnej transakcji w toku i wszystkie tabele i bufery stanów są wyczyszczone.

MAIL FROM:

Powyższe polecenie służy do rozpoczęcia transakcji, w której poczta jest dostarczana do jednej lub większej liczby skrzynek pocztowych. Pole argumentu zawiera ścieżkę zwrotną. Ścieżka ta zaś zawiera opcjonalnie listę hostów i skrzynkę nadawcy. W przypadku, gdy lista hostów jest obecna to wskazuje ona „odwrotną” ścieżkę - oznacza to że poczta została przesłana przez każdego hosta z listy (pierwszy host na liście to ten przez którego ostatnio przeszła poczta). Lista ta jest wykorzystywana do jako ścieżka powrotna dla dostarczania notatek od nie-dostarczonej poczcie do nadawcy. Każdy host dodający swoją nazwę do listy musi używać tej nazwy jako znanej dla IPCE do którego przesyła pocztę, a nie do IPCE, od którego przyszła poczta (pod warunkiem, że są one różne). Czasami można się zetknąć z notatkami o błędach w dostarczaniu wiadomości, w których ścieżka zwrotna może być pusta.

RCPT TO:

Polecenie to jest wykorzystywane do identyfikacji indywidualnych odbiorców poczty, natomiast grupowi odbiorcy są definiowani poprzez wielokrotne użycie tego polecenia. Tym razem możemy mówić o ścieżce w kierunku odbiorcy. Ścieżka ta zawiera opcjonalnie listę hostowi wymaganą skrzynkę docelową. Jeżeli lista hostów jest obecna to stanowi ona ścieżkę źródłową i wskazuje, że poczta musi być przesyłana poprzez następnego hosta na liście. Jeżeli odbiorca SMTP nie ma zaimplementowanej funkcji przesyłania to może użyć tej samej odpowiedzi, której użyłby w przypadku nieznanego użytkownika lokalnego (550).

Po przesłaniu poczty host przesyłający musi usunąć siebie z początku listy hostó ścieżki źródłowej i umieścić swoją nazwę na początku ścieżki zwrotnej. W momencie, gdy poczta dociera do swego przeznaczenia (ścieżka źródłowa zawiera jedynie skrzynkę odbiorczą) odbiorca SMTP umieszcza ją w docelowej skrzynce pocztowej zgodnie z konwencjami pocztowymi jej hosta.

DATA

Odbiorca tego polecenia traktuje wiersze następujące po tym poleceniu jako dane pocztowe pochodzące od nadawcy. Powyższe polecenie sprawia, że dane pocztowe pochodzące niejako od tego polecenia zostają dołączone do bufora danych pocztowych. Takie dane pocztowe mogą zawierać jakiekolwiek znaki z zestawu 128 ASCII kodów znaków. Dane pocztowe są zakończone linią zawierającą jedynie spację, którą oznacza sekwencja: "<CRLF>.<CRLF>", co wskazuje na koniec danych.

Znacznik końca danych pocztowych wymusza na odbiorcy przejście do obróbki zachowanej informacji o transakcji pocztowej. Obrabiane są informacje z bufora ścieżki powrotnej, bufora ścieżki źródłowej i bufora danych pocztowych. Po zakończeniu wykonywania tego polecenia bufory te są czyszczone. Jeżeli obróbka powiedzie się to odbiorca musi wysłać odpowiedź: OK. W przeciwnym wypadku odbiorca wysyła odpowiedź niepowodzenia.

RSET

Polecenie to wywołuje przerwanie wykonywania bierzącej transakcji. Jakakolwiek przechowywana informacja na temat nadawcy, odbiorców czy danych pocztowych musi zostać odrzucona, a wszystkie bufory i tablice stanów wyczyszczone. Odbiorca musi odesłać odpowiedź OK.

SEND FROM:

Polecenie to jest wykorzystywane do zainicjowania transakcji pocztowej, w której dane pocztowe dostarczane są do jednego lub większej liczby terminali. Pole argumentu zawiera ścieżkę zwrotną. Wykonanie tego polecenie jest zakończone sukcesem jeżeli wiadomość zostanie dostarczona do terminala.

Ścieżka zwrotna zawiera opcjonalnie listę hostów i skrzynkę pocztową nadawcy. W przypadku, gdy lista hostów jest obecna to wskazuje ona „odwrotną” ścieżkę - oznacza to że poczta została przesłana przez każdego hosta z listy (pierwszy host na liście to ten przez którego ostatnio przeszła poczta). Lista ta jest wykorzystywana do jako ścieżka powrotna dla dostarczania notatek od nie-dostarczonej poczcie do nadawcy. Każdy host dodający swoją nazwę do listy musi używać tej nazwy jako znanej dla IPCE do którego przesyła pocztę, a nie do IPCE, od którego przyszła poczta (pod warunkiem, że są one różne).

SOML FROM:

Polecenie to jest używane do zainicjowania transakcji pocztowej, w której dane pocztowe są dostarczane do jednego lub większej liczby terminali lub skrzynek pocztowych. Dla każdego z odbiorców poczta jest dostarczana jest najpierw do terminala odbiorcy pod warunkiem, że terminal ten jest aktywny (i akceptuje wiadomości terminalowe), w innym przypadku do skrzynki pocztowej odbiorcy. Pole argumentu zawiera ścieżkę zwrotną. Wykonanie tego polecenie jest zakończone sukcesem, jeżeli wiadomość zostanie dostarczona do terminala lub do skrzynki pocztowej.

Ścieżka zwrotna zawiera opcjonalnie listę hostów i skrzynkę pocztową nadawcy. W przypadku, gdy lista hostów jest obecna to wskazuje ona „odwrotną” ścieżkę - oznacza to, że poczta została przesłana przez każdego hosta z listy (pierwszy host na liście to ten przez którego ostatnio przeszła poczta). Lista ta jest wykorzystywana do jako ścieżka powrotna dla dostarczania notatek od nie-dostarczonej poczcie do nadawcy. Każdy host dodający swoją nazwę do listy musi używać tej nazwy jako znanej dla IPCE, do którego przesyła pocztę, a nie do IPCE, od którego przyszła poczta (pod warunkiem, że są one różne).

SAML FROM:

Polecenie to jest używane do zainicjowania transakcji pocztowej, w której dane pocztowe są dostarczane do jednego lub większej liczby terminali lub skrzynek pocztowych. Dla każdego z odbiorców poczta jest dostarczana jest najpierw do terminala odbiorcy pod warunkiem, że terminal ten jest aktywny (i akceptuje wiadomości terminalowe), po czym do wszystkich skrzynek pocztowych wszystkich odbiorców. Pole argumentu zawiera ścieżkę zwrotną. Wykonanie tego polecenie jest zakończone sukcesem, jeżeli wiadomość zostanie dostarczona do skrzynki pocztowej.

Ścieżka zwrotna zawiera opcjonalnie listę hostów i skrzynkę pocztową nadawcy. W przypadku, gdy lista hostów jest obecna to wskazuje ona „odwrotną” ścieżkę - oznacza to, że poczta została przesłana przez każdego hosta z listy (pierwszy host na liście to ten przez którego ostatnio przeszła poczta). Lista ta jest wykorzystywana do jako ścieżka powrotna dla dostarczania notatek od nie-dostarczonej poczcie do nadawcy. Każdy host dodający swoją nazwę do listy musi używać tej nazwy jako znanej dla IPCE, do którego przesyła pocztę, a nie do IPCE, od którego przyszła poczta (pod warunkiem, że są one różne).

VRFY

Powyższe polecenie ma za zadanie weryfikacji, czy argument identyfikuje użytkownika - prosi o potwierdzenie odbiorcę. Jeżeli jest to nazwa użytkownika, to zwracana jest pełna nazwa użytkownika (o ile jest znana) i pełna specyfikacja skrzynki pocztowej.

EXPN

Powyższe polecenie ma za zadanie weryfikacji, czy argument identyfikuje listę mailingową, a jeżeli tak, to zwracane jest członkostwo takiej listy. W wielowierszowej odpowiedzi zwracane są pełne nazwy użytkowników (o ile są znane) i pełna specyfikacja skrzynek pocztowych.

HELP

Polecenie to powoduje, że odbiorca wysyła do nadawcy polecenia HELP pomocną informację. Polecenie to może przyjmować argument (tzn. dowolną nazwę polecenia) i zwraca w odpowiedzi bardziej szczegółową informację.

NOOP

Powyższe polecenie nie wpływa na żadne parametry ani na wcześniej wydane polecenia. Jedyną akcją jaką wywołuje jest spowodowanie odesłania przez odbiorcę odpowiedzi OK.

QUIT

To polecenie wymusza na odbiorcy odesłanie odpowiedzi OK, a potem zamknięcie kanału transmisji.

Odbiorca nie powinien zamknąć kanału transmisji dopóki nie otrzyma i nie odpowie na polecenie QUIT - nawet, jeżeli wystąpi jakiś błąd. Nadawca nie powinien zamykać kanału transmisji dopóki nie wyśle komendy QUIT i nie otrzyma na nią odpowiedzi - nawet jeżeli wystąpi błąd odpowiedzi na poprzednie polecenie. W przypadku zakończenia połączenie wcześniej odbiorca powinien zachować się tak, jakby zostało otrzymane polecenie RSET - odwołanie wszelkich trwających transakcji, ale nie wywieranie wpływu na wcześniej zakończone transakcje. Nadawca powinien zachować się tak jak w przypadku wystąpienia w trakcie wykonywania polecenia lub transakcji tymczasowego błędu (4xx).

TURN

To polecenie wymusza jedno z dwóch scenariuszy: (1) wysłanie odpowiedzi OK po czym przejęcie roli nadawcy SMTP, lub (2) wysłanie odpowiedzi odmowy i pozostania w roli odbiorcy SMTP.

Jeżeli program A pełni aktualnie rolę nadawcy SMTP i wydaje polecenie TURN i otrzymuje odpowiedź OK. (250) to staje się odbiorcą SMTP. Jest wtedy w stanie początkowym tak jak przy otwarciu kanału transmisji i wysyła zaproszenie gotowości usług 220.

Jeżeli program B pełni aktualnie rolę odbiorcy SMTP i otrzymuje polecenie TURN i wysyła odpowiedź OK (250) to staje się nadawcą SMTP. Jest wtedy w stanie początkowym tak jak przy otwarciu kanału transmisji i oczekuje na odebranie zaproszenia gotowości usług 220.

2.1.2. Odpowiedzi SMTP

211 Stan systemu (System status, or system help reply)

214 wiadomość pomocnicza (Help message)

220 Gotowość usług (Service ready)

221 Zamykanie kanału transmisji (Service closing transmission channel)

250 Zakończenie operacji z sukcesem (Requested mail action okay, completed)

251 Użytkownik nie jest lokalny, przekierowane do (User not local; will forward to )

354 Początek przyjmowania poczty (Start mail input; end with ).

421 Usługa nie dostępna, zamykanie kanału transmisji (Service not available, closing transmission channel)

450 Wymagana akcja nie podjęta, skrzynka pocztowa niedostępna (Requested mail action not taken: mailbox unavailable)

451 Wymagana akcja przerwana, lokalny błąd przetwarzania (Requested action aborted: local error in processing)

452 Wymagana akcja przerwana, niewystarczająca pojemność systemu (Requested action not taken: insufficient system storage)

500 Błąd sytaksu, polecenie nierozpoznane (Syntax error, command unrecognized)

501 Błąd sytaksu parametrów lub argumentów (Syntax error in parameters or arguments)

502 Polecenie nie zaimplementowane (Command not implemented)

503 Niewłaświwa kolejność poleceń (Bad sequence of commands)

504 Parametr polecenia nie zaimplementowany (Command parameter not implemented)

550 Wymagana akcja nie podjęta, skrzynka pocztowa niedostępna (Requested action not taken: mailbox unavailable)

551 Użytkownik nie jest lokalny, proszę próbować (User not local; please try)

552 Wymagana akcja przerwana, przekroczono alokowane zasoby (Requested mail action aborted: exceeded storage allocation)

553 Wymagana akcja nie podjęta, niedozwolona nazwa skrzynki pocztowej (Requested action not taken: mailbox name not allowed)

554 Transakcja nieudana (Transaction failed)

2.1.3. Przykładowa transakcja SMTP

S: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready

C: HELO USC-ISIF.ARPA

S: 250 BBN-UNIX.ARPA

C: MAIL FROM:<[e-mail]>

S: 250 OK

C: RCPT TO:<[e-mail]>

S: 250 OK

C: RCPT TO:<[e-mail]>

S: 550 No such user here

C: RCPT TO:<[e-mail]>

S: 250 OK

C: DATA

S: 354 Start mail input; end with <CRLF>.<CRLF>

C: terefere kuku...

C: ...itd. itp.

C: .

S: 250 OK

C: QUIT

S: 221 BBN-UNIX.ARPA Service closing transmission channel

2.2. POP 3 (RFC 1725)

2.2.1. Polecenia i odpowiedzi POP3

1. Minimalny (standardowy) zestaw poleceń:

a) Stosowane w stanie AUTHORIZACJI (autoryzation):

USER name

Argumenty: string identyfikujący skrzynkę pocztową (wymagane), ważne TYLKO dla serwera

Ograniczenia: może być wydane tylko w stanie (w trakcie) AUTHORIZACJI po zaproszeniu POP3 lub po nieudanej komendzie USER lub PASS

Dopuszczalne

odpowiedzi:

+OK nazwa jest ważną nazwą skrzynki pocztowej

-ERR nieznana nazwa skrzynki pocztowej

Przykłady:

C: USER kowal

S: +OK kowal is a real hoopy frood

...

C: USER nowakjan

S: -ERR sorry, no mailbox for nowakjan here

PASS string

Argumenty: odpowiednie hasło serwera/skrzynki pocztowej (wymagane)

Ograniczenia: może być wydane tylko w stanie (w trakcie) AUTHORIZACJI po udanym użyciu polecenia USER

Dopuszczalne

odpowiedzi:

+OK maildrop locked and ready

-ERR invalid password

-ERR unable to lock maildrop

Przykłady:

C: USER kowal

S: +OK kowal is a real hoopy frood

C: PASS tajemnica

S: +OK kowal's maildrop has 2 messages (320 octets)

...

C: USER kowal

S: +OK kowal is a real hoopy frood

C: PASS tajemnica

S: -ERR maildrop already locked

QUIT

Argumenty: brak

Ograniczenia: brak

Dopuszczalne

odpowiedzi:

+OK

Przykłady:

C: QUIT

S: +OK dewey POP3 server signing off

b) Stosowane w trakcie TRANSAKCJI (transaction state):

STAT

Argumenty: brak

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK nn mm

Przykłady:

C: STAT

S: +OK 2 320

LIST [msg]

Argumenty: numer wiadomości (opcjonalnie), jeżeli obecny nie może odnosić się do wiadomości oznaczonej jako usunięta

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK scan listing follows

-ERR no such message

Przykłady:

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

...

C: LIST 2

S: +OK 2 200

...

C: LIST 3

S: -ERR no such message, only 2 messages in maildrop

RETR msg

Argumenty: numer wiadomości (wymagane), nie może odnosić się do wiadomości oznaczonej jako usunięta

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK message follows

-ERR no such message

Przykłady:

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends the entire message here>

S: .

DELE msg

Argumenty: numer wiadomości (wymagane), nie może odnosić się do wiadomości oznaczonej jako usunięta

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK message deleted

-ERR no such message

Przykłady:

C: DELE 1

S: +OK message 1 deleted

...

C: DELE 2

S: -ERR message 2 already deleted

NOOP

Argumenty: brak

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK

Przykłady:

C: NOOP

S: +OK

RSET

Argumenty: brak

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK

Przykłady:

C: RSET

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

c) Stosowane w stanie UAKTUALNIANIA (update)

QUIT

Argumenty: brak

Ograniczenia: brak

Dopuszczalne

odpowiedzi:

+OK

Przykłady:

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

...

C: QUIT

S: +OK dewey POP3 server signing off (2 messages left)

...

2. Polecenia opcjonalne:

a) Stosowane w stanie AUTHORIZACJI (autoryzation)

APOP name digest

Argumenty: string identyfikujący skrzynkę pocztową i string MD5 (oba wymagane)

Ograniczenia: może być wydane tylko w stanie (w trakcie) AUTHORIZACJI po zaproszeniu POP3

Dopuszczalne

odpowiedzi:

+OK maildrop locked and ready

-ERR permission denied

Przykłady:

S: +OK POP3 server ready <[e-mail]>

C: APOP kowal c4c9334bac560ecc979e58001b3e22fb

S: +OK maildrop has 1 message (369 octets)

b) Stosowane w trakcie TRANSAKCJI (transaction state):

TOP msg n

Argumenty: numer wiadomości (wymagane) nie może odnosić się do wiadomości oznaczonej jako usunięta,musi być to numer nieujemny (wymagane)

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK top of message follows

-ERR no such message

Przykłady:

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

...

C: TOP 100 3

S: -ERR no such message

UIDL [msg]

Argumenty: numer wiadomości (opcjonalnie) - jeżeli obecny, nie może odnosić się do wiadomości oznaczonej jako usunięta.

Ograniczenia: może być wydane tylko w trakcie (w stanie) TRANSAKCJI

Dopuszczalne

odpowiedzi:

+OK unique-id listing follows

-ERR no such message

Przykłady:

C: UIDL

S: +OK

S: 1 whqtswO00WBw418f9t5JxYwZ

S: 2 QhdPYR:00WBw1Ph7x7

S: .

...

C: UIDL 2

S: +OK 2 QhdPYR:00WBw1Ph7x7

...

C: UIDL 3

S: -ERR no such message, only 2 messages in maildrop

3. Odpowiedzi POP3 :

+OK

-ERR

Zauważmy, że poza poleceniami STAT, LIST, i UIDL, odpowiedzi wysyłane przez serwer POP3 na jakiekolwiek polecenia to "+OK" and "-ERR". Jakikolwiek tekst pojawiający się po takiej odpowiedzi może być ignorowany przez klienta.

2.2.2. Przykładowa sesja POP3

S: <wait for connection on TCP port 110>

C: <open connection>

S: +OK POP3 server ready <[e-mail]>

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: +OK mrose's maildrop has 2 messages (320 octets)

C: STAT

S: +OK 2 320

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends message 1>

S: .

C: DELE 1

S: +OK message 1 deleted

C: RETR 2

S: +OK 200 octets

S: <the POP3 server sends message 2>

S: .

C: DELE 2

S: +OK message 2 deleted

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

C: <close connection>

S: <wait for next connection>

3. Konfiguracja klienta pocztowego

W tej sekcji opisane są procedury konfiguracji prostego klienta poczty elektronicznej - MS Outlook Express 6. Poniżej jest zamieszczona konfiguracja protokołów SMTP i POP3 dla konta pocztowego (source: http://www1.umn.edu/adcs/help/email/WinOutlook5.html#email):

1. Z menu Narzędzia wybierz opcję Konta…

2. W oknie dialogowym Konta internetowe kliknij przycisk Dodaj i wybierz opcję Poczta…

3. Wprowadź swoje nazwisko w takiej formie jakbyś chciał, aby pojawiało się w polu OD

4. Wciśnij Dalej.

5. Wpisz adres e-mail w formie <identyfikatorInternetowy>@umn.edu (np. [e-mail]).

6. Wciśnij Dalej.

7. Jako serwer poczty przychodzącej wybierz POP3.

8. Dla serwera poczty przychodzącej (POP3, IMAP, or HTTP) wpisz adres serwera pocztowego w formie <identyfikatorInternetowy>.email.umn.edu (np. uzytkownik1234.email.umn.edu).

9. Wpisz smtp.umn.edu w pole serwera poczty wychodzącej (SMTP).

10. Wciśnij Dalej.

11. Wpisz nazwę konta, czyli w tym przypadku identyfikator uniwersytecki (np. uzytkownik1234).

12. Wpisz swoje haslo.

13. Nie wybieraj opcji Logowanie przy użyciu bezpiecznego uwierzytelnienia hasla.

14. Wciśnij Dalej.

15. Wciśnij przycisk Zakończ.

16. W oknie dialogowym Konta internetowe klikniej zakładkę Poczta, następnie wybierz swoje konto poprzez podwójne kliknięcie na jego nazwie. W ten sposób wyświetli się okno dialogowe właściwości.

17. W oknie dialogowym Właściwości konta kliknij zakładkę Serwery.

18. Poniżej Serwer Poczty Wychodzącej zaznacz okienko Serwer wymaga uwierzytelnienia.

19. Click the Settings button.

20. W oknie dialogowym Serwer Poczty Wychodzącej, poniżej Informacji o Logowaniu, zaznacz opcję Użyj tych samych ustawień co mój serwer poczty przychodzącej i kliknij przycisk OK.

21. W oknie dialogowym Właściwości konta kliknij zakładkę Zaawansowane.

22. Poniżej Numerów portów serwera, obok Poczty wychodzącej (SMTP): wpisz 465 I zaznacz Ten serwer wymaga bezpiecznego połączenia (SSL). Kliknij przycisk OK.

SKiSO, lab. 5

studia dzienne magisterskie

źródło: http://www.eits.uga.edu/~ucns/lans/docs/lanmail.htm

14

---