IMAP STORE to polecenie tego protokołu modyfikujące flagi wskazanej wiadomości, np. oznaczenie jako przeczytana.
Składnia polecenia IMAP STORE
IMAP STORE jest poleceniem używanym w stanie selected, czyli po wybraniu konkretnej skrzynki pocztowej poleceniem SELECT albo EXAMINE. Służy do zmiany atrybutów jednej lub wielu wiadomości wskazanych przez zbiór numerów sekwencyjnych. Ogólna składnia polecenia ma postać tag STORE message_set [UNCHANGEDSINCE modseq] item_name value, przy czym wariant z parametrem UNCHANGEDSINCE należy do rozszerzeń obsługujących kontrolę zmian. W podstawowym IMAP najczęściej spotyka się zapis A001 STORE 25 +FLAGS (\Seen), gdzie A001 jest znacznikiem żądania, 25 numerem wiadomości, a +FLAGS (\Seen) oznacza dodanie flagi informującej o przeczytaniu.
Element message_set może wskazywać pojedynczą wiadomość, zakres, kilka zakresów albo wszystkie wiadomości. Przykład 1:10 obejmuje wiadomości o numerach od 1 do 10, natomiast 1,4,7:9 wskazuje wiadomości 1, 4, 7, 8 i 9. Znak * oznacza najwyższy aktualnie dostępny numer sekwencyjny w wybranej skrzynce. Numer sekwencyjny nie jest trwałym identyfikatorem wiadomości: może zmienić się po usunięciu wiadomości lub po innej zmianie stanu skrzynki. Dlatego aplikacje, które muszą jednoznacznie odwołać się do wiadomości, zwykle korzystają z polecenia UID STORE i identyfikatorów UID.
Dodawanie, usuwanie i zastępowanie flag
Podstawowe warianty modyfikacji są określane przez nazwę elementu danych. +FLAGS dodaje wskazane flagi do już istniejącego zestawu, -FLAGS usuwa wskazane flagi, a FLAGS zastępuje cały dotychczasowy zestaw flag podaną wartością. Wariant +FLAGS.SILENT, -FLAGS.SILENT albo FLAGS.SILENT wykonuje tę samą zmianę, ale nie wymaga od serwera wysyłania do klienta odpowiedzi FETCH opisującej zmodyfikowane flagi. Przykładowo B002 STORE 7 +FLAGS (\Flagged) oznacza wiadomość jako oznaczoną, a B003 STORE 7 -FLAGS (\Seen) usuwa oznaczenie przeczytania.
Flagi systemowe mają określone znaczenie protokołowe. \Seen wskazuje, że zawartość wiadomości została odczytana, \Answered informuje o udzieleniu odpowiedzi, \Flagged służy do oznaczenia wiadomości jako wyróżnionej, \Deleted oznacza ją jako przeznaczoną do usunięcia, a \Draft wskazuje wersję roboczą. Flaga \Recent jest zarządzana przez serwer i nie powinna być traktowana jak zwykła etykieta ustawiana przez klienta. Serwer może również obsługiwać słowa kluczowe, czyli własne nazwy flag bez prefiksu odwrotnego ukośnika. Ich dostępność zależy od możliwości konkretnej skrzynki i serwera.
Ustawienie \Deleted nie usuwa wiadomości natychmiast. W standardowym przebiegu wiadomość otrzymuje oznaczenie usunięcia, a fizyczne usunięcie następuje dopiero po wykonaniu EXPUNGE albo operacji, która obejmuje ten etap. Ma to znaczenie przy analizowaniu sytuacji, w której wiadomość nadal jest widoczna po użyciu funkcji „Usuń”. Klient pocztowy może najpierw wysłać STORE z flagą \Deleted, a dopiero później wykonać EXPUNGE, zamknąć skrzynkę lub zastosować własną politykę opróżniania usuniętych wiadomości.
Numery sekwencyjne, UID i odpowiedzi serwera
W zwykłym poleceniu STORE wiadomości są identyfikowane numerami sekwencyjnymi obowiązującymi w bieżącej sesji i wybranej skrzynce. Po zmianie zawartości skrzynki numery wiadomości znajdujących się za usuniętym elementem mogą się przesunąć. Polecenie UID STORE wykorzystuje natomiast trwałe identyfikatory UID przypisane przez serwer w ramach konkretnej skrzynki. Przykład C001 UID STORE 385 +FLAGS (\Seen) modyfikuje wiadomość o UID 385, a nie wiadomość o aktualnym numerze sekwencyjnym 385. UID jest stabilniejszym odwołaniem, ale jego znaczenie jest ograniczone do danej skrzynki i obowiązuje wraz z wartością UIDVALIDITY.
Po poprawnym wykonaniu STORE serwer zwykle zwraca odpowiedź oznaczoną numerem żądania, na przykład A001 OK STORE completed. Przy użyciu zwykłego wariantu bez .SILENT serwer może wcześniej przesłać nieoznaczone odpowiedzi FETCH zawierające aktualne flagi wiadomości. Klient musi je przetworzyć, ponieważ inne sesje IMAP mogą równocześnie zmieniać stan tej samej skrzynki. W protokole IMAP zmiany mogą być również przekazywane klientowi asynchronicznie jako odpowiedzi FETCH lub EXPUNGE. Nieprawidłowo działająca aplikacja może więc wyświetlać stan niezgodny z serwerem, jeśli ignoruje odpowiedzi niespodziewane, błędnie mapuje UID na numer sekwencyjny albo zapisuje lokalny stan bez jego ponownej synchronizacji.
Serwer może odrzucić STORE z powodu złego stanu sesji, niepoprawnego zestawu wiadomości, braku uprawnień albo nieobsługiwanej flagi. Szczególne znaczenie ma stan READ-ONLY, uzyskiwany między innymi po EXAMINE. W takim stanie można przeglądać wiadomości, lecz operacje zmieniające dane, w tym STORE, nie powinny być wykonywane jako modyfikacje trwałe. Odpowiedzi BAD, NO i OK mają różne znaczenie: BAD oznacza błąd składni lub nieprawidłowe żądanie, NO odmowę wykonania operacji, a OK jej zaakceptowanie.
Rozpoznawanie problemów z oznaczeniami wiadomości
Objaw w postaci wiadomości stale oznaczanych jako nieprzeczytane może wynikać z kilku różnych miejsc przepływu danych. Należy ustalić, czy klient wysyła STORE z +FLAGS (\Seen), czy wysyła wersję z .SILENT, czy serwer potwierdza zmianę oraz czy późniejsza synchronizacja nie nadpisuje lokalnego widoku starszym stanem. W przypadku wielu urządzeń ważne jest także sprawdzenie, czy żądanie trafia do tej samej skrzynki i tego samego konta. Samo otwarcie wiadomości w aplikacji nie dowodzi jeszcze, że do serwera wysłano prawidłową zmianę flagi.
Analiza komunikacji powinna rozróżniać numer sekwencyjny od UID i obejmować kolejność poleceń. Przykładowy poprawny przebieg to zalogowanie, przejście do wybranej skrzynki, otrzymanie informacji o jej stanie, wysłanie STORE albo UID STORE, odebranie odpowiedzi FETCH oraz potwierdzenie zakończenia oznaczonego tagiem. Warto sprawdzić, czy zakres wiadomości nie stał się nieaktualny po odpowiedzi EXPUNGE, czy klient nie używa flagi FLAGS zamiast +FLAGS oraz czy nie wykonuje później operacji usuwającej wcześniej ustawione oznaczenie. Przy problemach z lokalną aplikacją pomocne jest porównanie jej zachowania z innym klientem IMAP, bez zakładania, że źródłem problemu jest sam protokół.
Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach z aplikacją pocztową można sprawdzić lokalne działanie komputera, konfigurację programu oraz poprawność połączenia z usługą IMAP w zakresie związanym ze stanowiskiem użytkownika.
