logi IMAP

Logi IMAP to zapisy sesji tego protokołu, pomocne przy diagnozowaniu problemów z synchronizacją folderów.

Co zawierają logi sesji IMAP

Logi IMAP to tekstowe zapisy komunikacji między programem pocztowym a serwerem obsługującym dostęp do wiadomości przez protokół IMAP. W zależności od aplikacji mogą obejmować datę i godzinę połączenia, adres serwera, numer portu, wybraną metodę szyfrowania, wynik uwierzytelniania oraz kolejne polecenia i odpowiedzi protokołu. IMAP umożliwia pracę na wiadomościach pozostających na serwerze, dlatego log może pokazać między innymi otwarcie skrzynki, wybór folderu, pobieranie listy wiadomości, synchronizowanie nagłówków oraz pobieranie treści lub załączników.

W zapisie diagnostycznym często występują nazwy poleceń IMAP, takie jak CAPABILITY, LOGIN, AUTHENTICATE, SELECT, EXAMINE, UID FETCH, STORE, EXPUNGE i LOGOUT. Serwer może odpowiadać kodami stanu OK, NO albo BAD. OK oznacza pomyślne wykonanie operacji, NO sygnalizuje odrzucenie żądania, na przykład z powodu braku uprawnień lub nieistniejącego folderu, natomiast BAD wskazuje na niepoprawne polecenie albo błędny sposób jego użycia. Sama obecność błędu w logu nie zawsze oznacza awarię; niektóre programy próbują opcjonalnych funkcji, których dany serwer nie obsługuje, po czym przechodzą do innego mechanizmu synchronizacji.

Jak odczytać przebieg połączenia z serwerem pocztowym

Analizę warto rozpocząć od ustalenia, czy problem występuje przed nawiązaniem sesji, podczas uwierzytelniania, czy dopiero przy synchronizacji folderów. Błąd DNS, brak odpowiedzi na połączenie TCP albo komunikat o przekroczeniu czasu oczekiwania wskazuje na problem z rozwiązywaniem nazwy, siecią, zaporą lub niedostępnym serwerem. Jeżeli log pokazuje rozpoczęcie TLS i błąd certyfikatu, trzeba sprawdzić nazwę hosta, datę i godzinę systemową oraz zgodność certyfikatu z używanym adresem. W przypadku szyfrowanego IMAP standardowo spotyka się port 993 dla połączenia IMAPS, natomiast port 143 może być używany dla połączenia, które rozpoczyna się bez szyfrowania i przechodzi do TLS po poleceniu STARTTLS, jeśli serwer oraz klient to obsługują.

Jeśli połączenie zostało ustanowione, ale serwer odrzuca logowanie, log może zawierać odpowiedź o nieprawidłowym haśle, zablokowanym koncie, wyłączonym dostępie IMAP albo wymaganej metodzie uwierzytelniania. Nie należy utożsamiać każdego komunikatu AUTHENTICATIONFAILED z błędnym hasłem, ponieważ identyczny objaw może wynikać z odrzucenia starego sposobu logowania, dodatkowego wymagania po stronie dostawcy poczty lub użycia niewłaściwego identyfikatora konta. Po udanym uwierzytelnieniu istotne są odpowiedzi dotyczące folderów. Problemy z mapowaniem folderu „Wysłane”, „Kosz” lub „Spam” mogą wynikać z różnic w nazwach, separatorach hierarchii i atrybutach folderów, a nie z uszkodzenia samych wiadomości.

Synchronizacja wiadomości widoczna w szczegółowym zapisie

Podczas synchronizacji klient zwykle pobiera listę folderów, a następnie porównuje lokalny stan z informacjami przechowywanymi na serwerze. Do identyfikowania wiadomości może wykorzystywać numery UID, które są przypisane do wiadomości w obrębie konkretnego folderu. Log może pokazać polecenia UID SEARCH, UID FETCH i UID STORE, używane odpowiednio do wyszukiwania, pobierania oraz zmiany flag wiadomości. Flagi, takie jak \Seen, \Answered, \Flagged i \Deleted, opisują stan wiadomości na serwerze. Gdy klient wielokrotnie pobiera te same dane, zgłasza niespójność UID albo ponownie tworzy lokalny indeks, przyczyną może być utrata informacji o stanie synchronizacji, nieprawidłowa implementacja serwera lub uszkodzona lokalna baza programu pocztowego.

W logach warto porównywać kolejność zdarzeń z objawem zgłaszanym przez użytkownika. Jeżeli wiadomości są widoczne na stronie internetowej dostawcy, lecz nie pojawiają się w aplikacji, należy sprawdzić, czy klient otwiera właściwy folder, czy nie stosuje filtra daty lub limitu pobierania oraz czy synchronizacja nie kończy się błędem po komendzie SELECT albo FETCH. Jeżeli wiadomość znika po usunięciu jej w jednym urządzeniu, może to być prawidłowy skutek współdzielenia stanu przez IMAP. Z kolei duplikaty często wskazują na problem z lokalnym indeksem, zmianę identyfikatorów UIDVALIDITY albo nieprawidłowe odtwarzanie stanu po przerwanym połączeniu. Wnioski powinny być oparte na pełnym fragmencie sesji, ponieważ pojedynczy wiersz bez wcześniejszych poleceń i odpowiedzi może być mylący.

Logi IMAP przy naprawie konfiguracji programu pocztowego

Przed przekazaniem logu do analizy należy ustalić, jaki program pocztowy, system operacyjny i dostawca skrzynki brały udział w połączeniu. Pomocne są dokładna godzina problemu, nazwa niedziałającego folderu, informacja o tym, czy odbiór działa na innym urządzeniu, oraz rozróżnienie między brakiem nowych wiadomości a błędem logowania. Logi mogą zawierać adres konta, identyfikatory sesji, nazwy folderów, tematy wiadomości, adresy nadawców, a w niektórych trybach także fragmenty treści. Przed udostępnieniem zapisu trzeba więc usunąć hasła, tokeny, pełne adresy e-mail i inne dane, które nie są potrzebne do rozpoznania błędu. Hasła nie powinny być zapisywane w logach w postaci jawnej; jeśli taki zapis wystąpił, należy niezwłocznie zmienić dane uwierzytelniające.

Na laptopie lub komputerze PC technik może na podstawie logu sprawdzić ustawienia nazwy serwera, portu, szyfrowania, metody uwierzytelniania i zakresu synchronizowanych folderów, a następnie porównać je z konfiguracją aplikacji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz ich oprogramowania, w tym diagnozowaniem problemów z lokalną konfiguracją klienta pocztowego i synchronizacją skrzynki. Sam log nie naprawia połączenia i nie zastępuje testu w aplikacji, ale pozwala ustalić, w którym miejscu sesja IMAP przestaje przebiegać prawidłowo. Po zmianie ustawień należy wykonać nową próbę, sprawdzić odbiór, widoczność folderów oraz stan wiadomości i porównać świeży zapis z wcześniejszym błędem.