RFC 2387

RFC 2387 definiuje typ multipart/related dla wiadomości z powiązanymi ze sobą częściami.

RFC 2387 – czym jest i do czego służy

RFC 2387 to dokument opisujący sposób oznaczania wiadomości MIME, w których kilka części tworzy jeden logiczny zasób. Najczęściej chodzi o dokument HTML wraz z elementami, które są potrzebne do jego poprawnego wyświetlenia, na przykład obrazami, arkuszami stylów lub innymi obiektami osadzonymi w treści. Zamiast traktować każdą część jako całkowicie niezależny załącznik, można wskazać, że wszystkie należą do wspólnej struktury.

Najważniejszym elementem tego mechanizmu jest typ multipart/related. Oznacza on, że poszczególne fragmenty wiadomości pozostają ze sobą w relacji określonej przez zawartość wiadomości i nagłówki MIME. Sama deklaracja nie mówi jeszcze, która część jest dokumentem głównym. Do tego służy parametr type, wskazujący typ głównego zasobu, a często również parametr start, identyfikujący część, od której należy rozpocząć interpretację całego zestawu.

W praktyce RFC 2387 ma znaczenie przy analizie wiadomości zawierających treść HTML z obrazami wyświetlanymi bezpośrednio w tekście. Obraz nie musi być pobierany z publicznego adresu internetowego, ponieważ może znajdować się w innej części tej samej wiadomości. Dokument określa więc relację między zasobem nadrzędnym a jego składnikami, a nie tylko sposób technicznego dołączenia plików.

RFC 2387 a struktura MIME i porównania z innymi typami

Wiadomość oparta na multipart/related może zawierać wiele części, ale ich kolejność nie powinna być jedynym sposobem ustalania znaczenia. Każdy fragment ma własne nagłówki, między innymi Content-Type, Content-ID oraz opcjonalnie Content-Disposition. Dokument główny odwołuje się do zasobów pomocniczych za pomocą identyfikatorów, często w formie adresów cid:. Dzięki temu program pocztowy może powiązać odwołanie zapisane w kodzie HTML z właściwą częścią MIME.

Warto odróżnić multipart/related od multipart/mixed. Typ multipart/mixed służy zwykle do połączenia niezależnych elementów, takich jak tekst wiadomości i osobne załączniki. W takim zestawie pliki mogą być użyteczne, ale nie muszą być wymagane do odczytania głównej treści. W przypadku multipart/related części są ze sobą funkcjonalnie związane: obraz, styl lub inny zasób wspiera interpretację głównego dokumentu.

Inne znaczenie ma także multipart/alternative. Ten typ pozwala przekazać różne reprezentacje tej samej treści, na przykład wersję tekstową i HTML. Odbiorca wybiera wariant, który potrafi obsłużyć. Możliwe jest zagnieżdżanie struktur MIME, dlatego wiadomość może mieć zewnętrzny kontener multipart/alternative, a wewnątrz wariantu HTML strukturę multipart/related. Taki układ wymaga poprawnego odczytania poziomów zagnieżdżenia i właściwego przypisania zasobów do konkretnej reprezentacji.

Parametr start jest przydatny wtedy, gdy pierwsza część nie jest głównym dokumentem. Jego wartość powinna odpowiadać identyfikatorowi zapisanym w nagłówku Content-ID właściwego elementu. Jeżeli parametr zostanie pominięty, odbiorca zazwyczaj przyjmuje pierwszą część za zasób główny. Właśnie dlatego błędna kolejność, brak identyfikatora albo niespójne odwołanie może powodować, że wiadomość wyświetli się jako zestaw plików zamiast jako spójny dokument.

RFC 2387 – typowe problemy podczas odczytu wiadomości

Jednym z częstszych problemów jest niezgodność między identyfikatorem użytym w kodzie HTML a wartością Content-ID. Nawet drobna różnica w zapisie może sprawić, że obraz nie zostanie odnaleziony. Znaczenie może mieć także sposób interpretacji nawiasów ostrych otaczających identyfikator w nagłówku. Program pocztowy powinien prawidłowo znormalizować te wartości, lecz różne aplikacje mogą różnić się tolerancją na błędy.

Problemy pojawiają się również wtedy, gdy zasób został oznaczony jako zwykły załącznik, mimo że treść HTML odwołuje się do niego jako do elementu powiązanego. Niewłaściwe użycie Content-Disposition, brak Content-ID albo błędny typ mediów może spowodować wyświetlenie grafiki wyłącznie na liście załączników. Nie zawsze oznacza to uszkodzenie samego pliku. Często problem dotyczy sposobu zbudowania całej wiadomości.

Na interpretację wpływa także kodowanie transferowe, zwłaszcza przy danych binarnych. Obrazy mogą być przekazywane z użyciem base64, a tekstowe elementy z inną metodą kodowania. Jeżeli deklaracja kodowania nie odpowiada faktycznej zawartości, część wiadomości może zostać odczytana jako uszkodzona. W przypadku dokumentów HTML należy dodatkowo sprawdzić, czy odwołania do zasobów nie zostały zmienione przez filtr bezpieczeństwa, system archiwizacji lub program pocztowy.

Niektóre aplikacje ograniczają wyświetlanie obrazów z powodów prywatności, nawet gdy struktura multipart/related jest poprawna. Dotyczy to zwłaszcza obrazów zewnętrznych, lecz podobne objawy mogą wystąpić przy zasobach osadzonych, jeśli klient pocztowy traktuje je jako potencjalnie niebezpieczne. W diagnostyce warto więc oddzielić błąd składni MIME od decyzji programu dotyczącej blokowania zawartości.

RFC 2387 – praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od pełnego źródła wiadomości, a nie od widoku użytkownika. Należy odszukać granice poszczególnych części wyznaczone przez parametr boundary, następnie sprawdzić nagłówki każdej części i ustalić, która z nich jest dokumentem głównym. Warto porównać wartość parametru type z rzeczywistym typem treści oraz zweryfikować, czy parametr start wskazuje istniejący Content-ID.

W treści HTML należy wyszukać odwołania w rodzaju src="cid:obraz-1" lub podobne identyfikatory. Następnie trzeba sprawdzić, czy odpowiadające im części MIME posiadają właściwy nagłówek Content-ID i poprawny Content-Type, na przykład image/png albo image/jpeg. Jeżeli odwołanie prowadzi do identyfikatora, którego nie ma w wiadomości, przyczyną może być niepełne wygenerowanie wiadomości albo ingerencja w jej zawartość podczas przekazywania.

Pomocne jest porównanie tej samej wiadomości w kilku klientach pocztowych, ale wynik takiego testu należy interpretować ostrożnie. Różny sposób prezentacji nie zawsze oznacza naruszenie RFC 2387. Jeden program może pokazać obraz w treści, drugi może dodatkowo wyświetlić go jako załącznik, a trzeci może zażądać zgody na pokazanie elementów graficznych. Istotne jest ustalenie, czy struktura i zależności w źródle są spójne.

Przy tworzeniu wiadomości warto stosować stabilne, unikalne identyfikatory, konsekwentnie określać typy danych i unikać niepotrzebnego mieszania kilku metod osadzania zasobów. Dobrą praktyką jest przygotowanie także wersji tekstowej w ramach multipart/alternative, ponieważ nie każdy odbiorca obsługuje HTML albo chce go wyświetlać. Taka wersja nie zastępuje multipart/related, lecz uzupełnia ją o wariant awaryjny.

RFC 2387 – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy problem z wiadomościami powtarza się na jednym komputerze, występuje w kilku programach albo towarzyszą mu inne objawy, takie jak błędy otwierania załączników, nieprawidłowe działanie przeglądarki, problemy z kodowaniem znaków lub samoczynne usuwanie elementów wiadomości. W takiej sytuacji przydatne jest zachowanie przykładowej wiadomości w oryginalnym formacie, bez przekazywania jej dalej, ponieważ przekazanie może zmienić nagłówki i strukturę MIME.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnozowaniem problemów z laptopami i komputerami PC, a naprawy są z reguły realizowane do 3 dni roboczych. Przed przekazaniem urządzenia można przygotować opis: w jakim programie występuje problem, czy dotyczy wszystkich wiadomości, czy obrazy są widoczne jako załączniki oraz czy błąd pojawia się również po otwarciu tej samej wiadomości na innym urządzeniu.

Warto pamiętać, że sama znajomość RFC 2387 nie rozstrzyga każdej usterki związanej z pocztą. Przyczyną może być uszkodzony profil programu, nieaktualne komponenty, filtr bezpieczeństwa, błędna konfiguracja konta albo problem z plikiem lokalnej skrzynki. Analiza struktury MIME pomaga zawęzić obszar poszukiwań, natomiast pełna diagnoza powinna uwzględniać także system operacyjny, używany program pocztowy, sposób odbierania wiadomości i zachowanie urządzenia.