STANDARDY I SYSTEMY OTWARTE POP3 (Post Office Protocol – RFC 1939)

1. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Protokół POP3 jest przeznaczony do wygodnej realizacji dynamicznego dostępu do skrzynki pocztowej obsługiwanej przez „host” serwera poczty, tzn. umożliwienia klienckiej stacji roboczej podejmowania przechowywanej tam poczty. W zasadzie ogranicza się on do podejmowania poczty z serwera i następnie jej usuwania. Bardziej uniwersalnych i wyrafinowanych usług dostarcza protokół IMAP. Podstawowa zasada działania Inicjacja protokołu polega na nasłuchiwaniu przez serwer (S) usługi POP3 na porcie 110 (TCP). Gdy klient (C) chce skorzystać z usługi, wtedy ustanawia połączenie TCP z serwerem. Po wysłaniu przez serwer pozdrowienia klient i serwer wymieniają polecenia i odpowiedzi do czasu zamknięcia lub porzucenia połączenia.

2. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Polecenia w POP3 składają się ze słów kluczowych , po których mogą wystąpić argumenty polecenia. Wszystkie polecenia są kończone sekwencją <CRLF>. Słowa kluczowe i argumenty redagowane są ze znaków ASCII i przedzielone pojedynczymi spacjami. Słowa kluczowe mają długość 3 lub 4 znaków. Długość argumentów jest ograniczona do 40 znaków. Odpowiedzi w POP3 rozpoczynają się ze wskaźnika statusu (+OK lub –ERR, zawsze duże litery), po którym może wystąpić dodatkowa informacja. Wszystkie odpowiedzi są kończone sekwencją <CRLF>. Długość odpowiedzi jest ograniczona do 512 znaków. Odpowiedzi na niektóre polecenia mogą składać się z wielu linii. Wtedy końcowa linia zawiera znak końca (oktet „.” = 046) i <CRLF>.

3. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) • Każda sesja protokołu POP3 może się składać z trzech kolejnych faz (stanów): • AUTORYZACJI (AUTHORIZATION) – po otwarciu połączenia TCP serwer wysyła „pozdrowienie”, zaś klient musi się zidentyfikować w stosunku do serwera. Po pomyślnej identyfikacji serwer „pozyskuje” zasoby zdeponowane w skrzynce pocztowej klienta i następuje przejście do stanu TRANSAKCJI. • TRANSAKCJI (TRANSACTION) – klient za pomocą wydawanych kolejno poleceń inicjuje określone działania serwera. Poleceniem QUIT powoduje przejście do stanu UAKTUALNIANIA. • UAKTUALNIANIA (UPDATE) – serwer POP3 zwalnia zasoby pozyskane podczas fazy TRANSAKCJI i „żegna się” z klientem. Połączenie TCP zostaje zamknięte.

4. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) • Dodatkowe wymagania protokolarne: • Serwer MUSIudzielić odpowiedzi na nierozpoznane, niezaimplementowane, nieprawidłowe składniowo polecenie klienta lub w przypadku niewłaściwej polecenie dla bieżącego stanu sesji komunikacyjnej przez wysłanie wskaźnika negatywnego statusu. • Nie ma ogólnej zasady, która pozwoliłaby klientowi stwierdzić, czy negatywna odpowiedź serwera wynika z niezaimplementowanej obsługi polecenia opcjonalnego, czy też z faktu, że serwer nie chce „obsłużyć” klienta. • Serwer MOŻEmieć zaimplementowane mechanizmy kontroli czasu przerwy między kolejnymi poleceniami klienta (autologout timer). Jeżeli je ma, to odpowiedni czas reakcji MUSIwynosić co najmniej 10 minut. Jeżeli czas ten upłynie w stanie TRANSAKCJI, to sesja nie osiąga stanu UAKTUALNIENIA i SERWER musi zamknąć połączenie TCP bez usuwania jakichkolwiek wiadomości lub wysyłania odpowiedzi do klienta.

5. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Stan AUTORYZACJI Po otwarciu połączenia TCP przez klienta POP3 serwer POP3 wysyła jedynie linię „powitania”, np.: S: +OK POP3 server ready Sesja „wkracza” w stan AUTORYZACJI. Identyfikacja klienta względem serwera może być zrealizowana przez łączne działanie poleceń USER i PASS albo opcjonalnego polecenia APOP. Bardziej „wyrafinowane” mechanizmy uwierzytelniania klienta, wykorzystujące np. protokół Kerberos lub funkcję skrótu MD5 określono definiując dodatkowe polecenie AUTH w dokumencie RFC 1734. Serwer POP3 musi zapewniać obsługę co najmniej jednego z tych mechanizmów potwierdzania tożsamości klienta.

6. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) UwierzytelnianieUSER i PASS Najpierw klient wydaje polecenie USER, którego argumentem jest nazwa skrzynki pocztowej o znaczeniu istotnym wyłącznie dla serwera. Jeżeli serwer odpowie -ERR, to klient ponownie próbuje się uwierzytelnić, lub kończy sesję poleceniem QUIT. Jeżeli serwer odpowie +OK, to klient kontynuuje uwierzytelnianie poleceniem PASS, lub kończy sesję poleceniem QUIT. Polecenie PASS, którego argumentem jest hasło (ciąg znaków) powoduje, że serwer zestawia nazwę i hasło, i na tej podstawie decyduje o udostępnieniu zasobów skrzynki pocztowej. Przykład 1: C: USER batman S: -ERR sorry, nor mailbox for batman here C: QUIT S: +OK dewey POP3 server signing off

7. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Przykład 2: C: USER batman S: +OK batman is a real mailbox user C: PASS secret S: -ERR mailbox already locked C: QUIT S: +OK dewey POP3 server signing off Przykład 3: C: USER batman S: +OK batman is a real mailbox user C: PASS secret S: +OK batman’s mailbox has 3 messages (320 octets) (i przejście w stan TRANSAKCJI)

8. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) • Uwierzytelnianie APOP • Argumentami polecenia APOP są: nazwa skrzynki pocztowej (ta sama, co wykorzystywana w poleceniu USER) oraz wartość funkcji skrótu MD5 obliczona dla łańcucha tekstowego utworzonego przez konkatenację: • „znacznika czasu” utworzonego przez unikalną sekwencję związaną z czasem, numerem procesu, itp. oraz nazwę domeny (w nawiasach <>), przekazywanego podczas „powitania” przez serwer POP3; • nazwy skrzynki pocztowej. • Przykład: • (powitanie i przekazanie „znacznika czasu”) • S: +OK POP3 server ready • <1896.697170952@dbc.mtview.ca.us> • (uwierzytelnianie) • C: APOP mrose c4c9334bac560ecc979e58001b3e22fb • S: +OK maildrop has 1 message (369 octets)

9. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) UWAGA: c4c9334bac560ecc979e58001b3e22fb to wartość funkcji skrótu MD5 dla łańcucha: <1896.697170952@dbc.mtview.ca.us>tanstaaf , gdzie tanstaaf spełnia rolę sekretu znanego serwerowi i klientowi mrose. Po pomyślnej „autoryzacji” serwer POP3 „pozyskuje” zasoby zdeponowane w skrzynce pocztowej i blokuje je w celu uniemożliwienia jakichkolwiek modyfikacji przed osiągnięciem stanu UAKTUALNIENIA. Jeżeli z różnych powodów serwer udzieli odpowiedzi negatywnej, lecz nie zamknie połączenia, to klient może zakończyć sesję wydając polecenie QUIT lub próbować ponownie wydać nowe polecenie wiodące do potwierdzenia tożsamości. Jeżeli serwer POP3 otworzy „skrzynkę pocztową”, to wówczas przypisuje każdej wiadomości numer kolejny i jej rozmiar w oktetach (w notacji dziesiętnej).

10. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Stan TRANSAKCJI W tym stanie sesji klient wydaje kolejne polecenia i otrzymuje kolejne odpowiedzi od serwera. Poleceniem QUIT„przeprowadza” sesję do stanu uaktualnienia. Polecenie STAT - polecenie bezargumentowe zwracające co najmniej informację o liczbie wiadomości (nie oznaczonych jako usuniętych) przechowywanych w skrzynce pocztowej i ich łącznym rozmiarze w oktetach. Przykład: C: STAT S: +OK 3 320 (w skrzynce są 3 wiadomości o łącznej długości 320 oktetów)

11. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Polecenie LIST Polecenie zwracające listę informacji o wiadomościach (nie oznaczonych jako usuniętych) przechowywanych w skrzynce pocztowej i ich rozmiarze, bądź przy podanym jako argument numerze wiadomości, informację o rozmiarze tej konkretnej wiadomości. Przykład 1: C: LIST S: +OK 3 messages (320 octets) S: 1 100 S: 2 80 S: 3 140 S: . Przykład 2: Przykład 3: C: LIST 3 C: LIST 4 S: +OK 3 140 S: -ERR no such message, only 3 messages in maildrop

12. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Polecenie RETR Polecenie, którego argumentem jest numer (nie oznaczonej jako usuniętej) wiadomości. Jeżeli wiadomość o takim numerze znajduje się w skrzynce, to zostanie odesłana klientowi (w pakietach po 512 znaków z <CRLF> włącznie. Przykład: C: RETR 2 S: +OK 80 octets S: <40 first octets> S: <40 last octets> S: . Polecenie NOOP Bezargumentowe polecenie, wykorzystywane np. do „podtrzymania” sesji w stanie TRANSAKCJI. Przykład: C: NOOP S: +OK

13. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Polecenie DELE Polecenie, którego argumentem jest numer (nie oznaczonej jako usuniętej) wiadomości. Jeżeli wiadomość o takim numerze znajduje się w skrzynce, to zostanie oznaczona przez serwer POP3 jako usunięta. Do czasu UAKTUALNIENIA wiadomość o tym numerze jest niedostępna dla innych poleceń. Na próby odwołania się do niej uzyskuje się odpowiedź sygnalizującą błąd. Przykład 1: C: DELE 1 S: +OK message 1 deleted Przykład 2: C: DELE 3 S: -ERR message 3 already deleted

14. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Polecenie RSET Polecenie bezargumentowe „kasujące” rezultaty wydanych dotychczas poleceń DELE i przywracające dostęp do oznaczonych jako usunięte wiadomości. Przykład: C: RSET S: +OK maildrop has 3 messages (320 octets) Opcjonalne polecenia UIDL i TOP (zalecane, ale nie konieczne) Polecenie UIDL wydane bez argumentów zwraca listę wiadomości w formie zestawienia ich numerów i unikalnych identyfikatorów – wartości funkcji skrótu (o długości do 70 znaków ASCII), zaś z argumentem będącym numerem wiadomości – numer tej wiadomości wraz z tym unikalnym identyfikatorem (podobnie jak polecenie LIST). Polecenie TOP, którego argumentami są numer wiadomości i liczba linii, powoduje przesłanie do klienta nagłówka wiadomości, jednego wiersza pustego i tylu pierwszych linii, ile określono w drugim z argumentów.

15. STANDARDY I SYSTEMY OTWARTEPOP3 (Post Office Protocol – RFC 1939) Stan UAKTUALNIENIA Stan osiągany po wydaniu przez klienta polecenia QUIT w stanie TRANSAKCJI. Wiadomości oznaczone jako usunięte są trwale usuwane ze skrzynki pocztowej. Przykład 1: C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) Przykład 2: C:QUIT S:+OK dewey POP3 server signing off (2 messages left)

16. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) • Protokół IMAP4 umożliwia klientowi dostęp do wiadomości pocztowych na serwerze oraz manipulowanie nimi. Protokół ten obejmuje operacje: • tworzenia, usuwania i zmiany nazwy skrzynki pocztowej, • sprawdzanie nowych wiadomości i ich trwałe usuwanie, • ustawianie i zerowanie odpowiednich flag, • interpretację („parsing”) formatów RFC822 i MIME, • wyszukiwanie i selektywne pobieranie atrybutów wiadomości, tekstów i ich części. • IMAP4 nie służy do nadawania wiadomości pozostaje to w gestii protokołów przekazywania poczty, takich jak np. SMTP. • IMAP4 przeznaczony jest do współpracy z jednym serwerem (kwestię współpracy z wieloma serwerami IMAP4 dyskutuje się przy okazji IMSP – Internet Multi-Server Protocol).

17. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) • Wiadomości na serwerze są dostępne przez ich kolejne numery lub tzw. unikalne identyfikatory. • Protokół po zestawieniu połączenia i przesłaniu przez serwer „pozdrowienia” polega na kolejnych „interakcjach” klienta (C) i serwera (S): • poleceniach klienta, • danych serwera, • odpowiedziach serwera o rezultacie zakończenia obsługi polecenia klienta. • Wszystkie „interakcje” są przesyłane w formie linii zakończonych sekwencją <CRLF>, przy czym ich odczyt polega na odczycie linii lub odczycie sekwencji oktetów o znanej długości, za którymi następuje linia. • Polecenie klienta rozpoczyna operację. Każde polecenie klienta poprzedzone jest tzw. znacznikiem („tag”), różnym dla każdego polecenia. Znacznik jest zazwyczaj krótkim łańcuchem alfanumerycznym (np. A001, A002, itd.).

18. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) • Istnieją dwa przypadki, gdy linia wysłana przez klienta nie jest kompletnym poleceniem: • argument polecenia jest „literałem” (tzn. ciągiem ujętym w cudzysłów), po którym następuje liczba oktetów ujęta w zwykłe nawiasy i <CRLF>, • argumenty polecenia wymagają „sprzężenia zwrotnego” od serwera (np. w poleceniu AUTHENTICATE). • W obu powyższych przypadkach serwer, gdy jest gotowy, odsyła tzw. „odpowiedź na żądanie kontynuacji polecenia” poprzedzoną prefiksem „+”, • Linie danych, przesyłane normalnie przez serwer w odpowiedzi na polecenie klienta, poprzedzone są prefiksem „*”, • Linia informująca o zakończeniu obsługi polecenia przez serwer zaczyna się od tego samego znacznika („tag”), od którego zaczynała się linia polecenia, odpowiedzi właściwej (OK, NO lub BAD), oraz ewentualnych dodatkowych informacji.

19. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) • Klient może przed odebraniem odpowiedzi o zakończeniu obsługi poprzedniego polecenia wydać kolejne polecenie o innym znaczniku i odebrać odpowiedź o zakończeniu obsługi tego nowego polecenia przed odpowiedzią o zakończeniu obsługi poprzedniego (pod warunkiem, że nie kłóci się to z logiką obsługi). • Przykład: • S: * OK IMAP4 Service Ready • C: a001 login marc secret • S: a001 OK LOGIN completed • C: a002 select inbox • S: * 18 EXISTS • S: * FLAGS (\Answered \Flagged\ Deleted\ Seen) • S: * 2 RECENT • S: a002 OK [READ-WRITE] SELECT completed • Serwer IMPA4 może znajdować się podczas sesji komunikacyjnej z klientem w jednym z czterech stanów: • stan braku uwierzytelnienia (non-authenticated), • stan uwierzytelnienia (authenticated), • stan wybrania (selected), • stan wylogowania (logout).

20. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) Diagram przejść między stanami Inicjacja połączenia i pozdrowienie od serwera Wylogowanie i zamknięcie połączenia (1) połączenie bez uwierzytelniania wstępnego (potwierdzenie OK.) (2) połączenie ze wstępnym uwierzytelnieniem (potwierdzenie PREAUTH) (3) połączenie odrzucone („pożegnanie” BYE) (4) pomyślne wykonanie polecenia LOGIN lub AUTHENTICATE (5) pomyślne wykonanie polecenia SELECT lub EXAMINE (6) polecenie CLOSE lub niepomyślny wynik polecenia SELECT lub EXAMINE (7) polecenie LOGOUT, wyłączenie serwera lub zamknięcie połączenia 1 Non-authenticated 2 4 3 Autenticated 6 3 7 7 Selected 7

21. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) Polecenia wydawane w dowolnym stanie: CAPABILITY Pytanie o listę dostępnych na serwerze usług, niezależną od stanu połączenia i samego użytkownika; serwer MUSI odesłać informację o dostępności IMAP4 jako pierwszą pozycję listy; pozostałe pozycje listy mogą wskazywać na dostępne usługi zgodne z rozszerzeniami protokołu IMAP4, nowelizacjami lub uzupełnieniami specyfikacji tego protokołu (przez wskazanie odpowiednich rozszerzeń, nowelizacji lub uzupełnień). Przykład: C: abcd CAPABILITY S: * CAPABILITY IMAP4 S: abcd OK CAPABILITY completed

22. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) NOOP Polecenie „puste”, ale np. zerujące licznik czasu odmierzający „time-out” podczas bezczynności klienta; może być także wykorzystywane do „odświeżania” informacji o bieżącym stanie „skrzynki pocztowej”. Przykład: C: a002 NOOP S: a002 OK NOOP completed ... C: a047 NOOP S: * 22 EXPUNGE S: * 23 EXISTS S: * 3 RECENT S: * 14 FETCH (FLAGS (\Seen \Deleted)) S: a047 OK NOOP completed

23. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) LOGOUT Polecenie sygnalizujące serwerowi zamiar zakończenia sesji przez klienta; serwer musi w odpowiedzi „pożegnać” klienta (wierszem danych bez znacznika zawierającym słowo kluczowe BYE), a następnie potwierdzić fakt zamknięcia połączenia odpowiedzią z odpowiednim znacznikiem. Przykład: C: a023 LOGOUT S: * BYE IMAP4 Server logging out S: a023 OK LOGOUT completed

24. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) Polecenia wydawane w stanie NON-AUTHENTICATED: LOGIN Polecenie uwierzytelniające klienta, którego argumentami są nazwa klienta i jego hasło w formie jawnej; po pomyślnym uwierzytelnieniu następuje przejście do stanu AUTHENTICATED. Przykład: C: a031 LOGIN PEJAS ABRAKADABRA S: a031 OK LOGIN completed

25. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) AUTHENTICATE Polecenie wskazujące serwerowi wybrany (sugerowany) przez klienta mechanizm uwierzytelniania; jeżeli serwer zapewnia obsługę sugerowanego mechanizmu, to jest to jednocześnie inicjacja wskazanego protokołu uwierzytelniającego; w trakcie realizacji tego protokołu możliwe jest także uzgodnienie kluczy kryptograficznych zapewniających (wraz z odpowiednimi algorytmami) integralność i poufność wszystkich danych wymienianych podczas sesji komunikacyjnej (po zakończeniu uwierzytelniania i przejściu do stanu AUTHENTICATED kolejne polecenia klienta i odpowiedzi serwera przesyłane są w formie pakietów bajtów poprzedzonych 4-bajtową informacją o długości kryptogramu i kryptograficznej sumy kontrolnej). Przykład: S: * OK KerberosV4 IMAP4 Server C: a033 AUTHENTICATE KERBEROS_V4 S: + AmFYig== (wyzwanie serwera) C: BAcAQU5EUkVXLkNNVS5FRFUA…. S: + or//EoAADZI== C: DiAF5A4gA+o0IalUBkAAmw== S: a033 OK Kerberos V4 authentication succesful

26. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) Polecenia wydawane w stanie AUTHENTICATED: SELECT Polecenie wyboru „skrzynki pocztowej”; w odpowiedzi serwer zwraca informacje dotyczące między innymi: bieżących atrybutów (FLAGS) wskazanej w poleceniu „skrzynki”, liczby wiadomości w „skrzynce”, liczby wiadomości, które pojawiły się w „skrzynce” od poprzedniej sesji (jeżeli brak mechanizmu rozróżniania takich wiadomości, to wszystkie wiadomości mają status „świeżych”), trybu dostępu do wiadomości, itd. W trakcie jednej sesji komunikacyjnej można wybrać tylko jedną „skrzynkę pocztową”. Przykład: C: a142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: a142 OK [READ-WRITE] SELECT completed

27. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) EXAMINE Polecenie wyboru „skrzynki pocztowej” w trybie odczytu (bez możliwości manipulacji zawartością „skrzynki”); odpowiedzi serwera identyczne, jak w przypadku polecenia SELECT. Przykład: C: a423 EXAMINE dziekanat S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] Message 8 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No permanent flags S: a423 OK [READ-ONLY] EXAMINE completed

28. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) CREATE Polecenie utworzenia nowej „skrzynki pocztowej”; w zależności od implementacji istnieje możliwość (za pomocą separatora „/”) utworzenia jednocześnie dwóch różnych równorzędnych „skrzynek”, bądź zainicjowania hierarchicznej struktury „skrzynek”. Przykład: C: b001 CREATE baby/ S: b001 OK CREATE completed C: b002 CREATE baby/sitter S: b002 OK CREATE completed DELETE Polecenie usunięcia „skrzynki pocztowej”. Przykład: C: b011 DELETE baby S: b011 OK DELETE completed

29. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) RENAME Polecenie zmiany nazwy „skrzynki pocztowej”. Przykład: C: b111 RENAME baby adult S: b111 OK RENAME completed (nowa nazwa „skrzynki pocztowej” - adult) SUBSCRIBE Polecenie powoduje dodanie wskazanej „skrzynki pocztowej” do listy „skrzynek aktywnych” obsługiwanych przez serwer. Przykład: C: mama SUBSCRIBE #news.comp.mail.mime S: mama OK SUBSCRIBE completed

30. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) UNSUBSCRIBE Polecenie powoduje usunięcie wskazanej „skrzynki pocztowej” z listy „skrzynek aktywnych” obsługiwanych przez serwer. Przykład: C: moma UNSUBSCRIBE #news.comp.mail.mime S: moma OK UNSUBSCRIBE completed LIST Polecenie, którego argumentami są nazwa odniesienia i nazwa „skrzynki pocztowej” (z możliwością stosowania znaków wieloznaczności, tzw. wildcards), służy do uzyskania informacji o „skrzynkach pocztowych” dostępnych dla użytkownika. Przykład: C: A002 LIST “~/Mail/” “%” S: * LIST (\Noselect) “/” ~/Mail/foo S: * LIST () “/” ~/Mail/meetings S: A002 OK LIST completed

31. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) LSUB Polecenie analogiczne jak polecenie LIST, lecz tym razem uzyskuje się informacje o „skrzynkach pocztowych”, które zostały zadeklarowane przez użytkownika jako aktywne (za pomocą polecenia SUBSCRIBE). Przykład: C: A003 LSUB “#news.” “comp.mail.*” S: * LSUB () “.” #news.comp.mail.mime S: * LSUB () “.” #news.comp.mail.misc S: A003 OK LSUB completed

32. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) APPEND Polecenie umieszczenia pewnego tekstu jako nowej wiadomości w skrzynce pocztowej. UWAGA: nie jest to polecenie wysłania wiadomości (tym się zajmuje np. SMTP). Przykład: C: A004 APPEND saved-messages (\Seen) {310} C: Date: Sun, 29 Feb 2004 15:40:00 –0800 (PST) C: From: redhead <nick@wi.ps.pl> C: Subject: balanga C: To: barbapapa@wi.ps.pl C: Message-Id: <X1673-010000@wi.ps.pl> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: What should we do with the drunken sailor ? C: S: A004 OK APPEND completed

33. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) Polecenia wydawane w stanie SELECTED: CHECK Sprawdzenie bieżącego stanu wybranej „skrzynki”. UWAGA: nie umożliwia sprawdzenia nowych wiadomości, które „wpłynęły” po zakończeniu obsługi poleceń SELECT lub EXAMINE. Przykład: C: X004 CHECK S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] Message 8 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No permanent flags S: X004 OK CHECK completed

34. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) CLOSE Zamknięcie bieżącej skrzynki, a ponadto w przypadku wcześniejszego wyboru poleceniem SELECT w trybie umożliwiającym zapis – trwałe usunięcie wszystkich wiadomości oznaczonych jako Deleted (bez jawnego informowania o tym użytkownika); powrót do stanu AUTHENTICATED. UWAGA: możliwy jest wybór nowej „skrzynki” bez uprzedniego polecenia CLOSE, ale nie są wtedy trwale usuwane wiadomości oznaczone jako Deleted. Przykład: C: Xxyz CLOSE S: Xxyz OK CLOSE completed

35. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) EXPUNGE Trwałe usunięcie wszystkich wiadomości oznaczonych jako Deleted z jawnym informowaniem o usuwaniu kolejnych (numerowanych) wiadomości. Przykład: C: D001 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: D001 OK EXPUNGE completed UWAGA: w powyższym przykładzie usunięto wiadomości o numerach pierwotnych 3, 4, 7 i 11 (efekt bieżącej aktualizacji numeracji wiadomości w „skrzynce”).

36. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) SEARCH Wyszukiwanie wiadomości na podstawie różnych opcjonalnych kryteriów wyszukiwania (patrz: RFC 1730). Przykład: C: C101 SEARCH FLAGGED SINCE 12-Feb-2004 NOT FROM PEJAS S: * SEARCH 2 84 882 (znaleziono wiadomości o numerach 2, 84 i 882) S: C101 OK SEARCH completed FETCH Pobranie wiadomości (jednej lub wielu; wybór na podstawie różnych opcjonalnych kryteriów; patrz: RFC 1730). Przykład: C: CCCC FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM)) S: * 2 FETCH ... S: * 3 FETCH ... S: * 4 FETCH ... S: CCCC OK FETCH completed

37. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) PARTIAL Pobranie części wiadomości (podobnie jak w przypadku FETCH - wybór na podstawie różnych opcjonalnych kryteriów; patrz: RFC 1730). Przykład: C: CC1C PARTIAL 4 RFC822 1 1024 S: * 1 FETCH (RFC822 {1024} S: Return-path: <jpejas@wi.ps.pl> S: … S: ….FLAGS (\Seen)) S: CC1C OK PARTIAL completed

38. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) STORE Aktualizacja wiadomości lub jej atrybutów; dodatkowe zastosowanie opcji SILENT powoduje, iż serwer nie zwraca informacji o stanie wiadomości po wykonaniu operacji STORE (różne opcjonalne kryteria; patrz: RFC 1730). Przykład: C: A00C STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH FLAGS (\Deleted \Seen) S: * 3 FETCH FLAGS (\Deleted) S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) S: A00C OK STORE completed COPY Kopiowanie wskazanych wiadomości do wskazanej „skrzynki pocztowej”. Przykład: C: A012 COPY 2:4 dziekanat S: A012 OK COPY completed

39. STANDARDY I SYSTEMY OTWARTEIMAP4 (Internet Message Access Protocol – RFC 1730) UID Umożliwia wybór konkretnych wiadomości do operacji FETCH, COPY, STORE lub SEARCH; wszystkie wiadomości mają swoje unikalne identyfikatory – Unique IDentifiers (w przeciwieństwie do numerów kolejnych nie ulegają one nigdy zmianie). Przykład: C: A033 UID FETCH 4827313:4828442 FLAGS S: * 23 FETCH (FLAGS (\Seen) UID 4827313 S: * 24 FETCH (FLAGS (\Seen) UID 4827943 S: * 25 FETCH (FLAGS (\Seen) UID 4828442 S: A033 OK UID FETCH completed X<polecenie własne użytkownika> Możliwość tworzenia własnych specyficznych poleceń użytkownika (co mu „w duszy zagra” i co zechce zaimplementować). Przykład: C: A442 XPIG-LATIN S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: A442 OK XPIG-LATIN completed