RFC 2387 – MIME multipart/related

RFC 2387 opisuje mechanizm łączenia treści HTML z osadzonymi obrazami przez identyfikatory CID.

RFC 2387 – MIME multipart/related: czym jest ten format

RFC 2387 definiuje sposób opakowania kilku powiązanych części wiadomości MIME w jeden logiczny zestaw. Najczęściej chodzi o dokument HTML oraz zasoby, które są potrzebne do jego poprawnego wyświetlenia, na przykład obrazy, arkusze stylów albo inne elementy wskazywane z treści dokumentu. Zamiast traktować każdą część jako niezależny załącznik, odbiorca może odczytać je jako elementy jednej prezentacji.

Najważniejszą cechą multipart/related jest relacja między częściami. Jedna z nich pełni rolę głównego dokumentu, a pozostałe dostarczają zasobów, do których ten dokument się odwołuje. W wiadomości HTML odwołanie może mieć postać adresu cid:logo@example. Taki zapis nie oznacza zwykłego adresu internetowego. Wskazuje na część wiadomości, której nagłówek Content-ID zawiera odpowiadający identyfikator.

Przykładowy pakiet może zawierać część HTML z nagłówkiem Content-Type: text/html oraz obraz opisany jako Content-Type: image/png. W obrazie umieszcza się Content-ID: <logo@example>, natomiast w kodzie HTML pojawia się <img src="cid:logo@example">. Dzięki temu klient pocztowy wie, który element graficzny ma zostać użyty w konkretnym miejscu dokumentu. Sam identyfikator nie jest ścieżką do pliku w systemie i nie powinien być analizowany jak lokalna nazwa pliku.

Warto odróżnić ten mechanizm od zwykłego multipart/mixed. W wariancie mixed części są zazwyczaj prezentowane jako osobne elementy wiadomości, na przykład tekst i załączniki. W multipart/related nacisk położono na zależność pomiędzy częściami. Odbiorca powinien rozpoznać, że zasób graficzny lub inny element jest używany przez dokument nadrzędny, a nie tylko dołączony obok niego.

RFC 2387 – MIME multipart/related a powiązania między częściami

Struktura wiadomości jest wyznaczana przez granicę MIME, czyli wartość parametru boundary. Każda część rozpoczyna się od własnych nagłówków, po których występuje właściwa zawartość. Dla poprawnego odczytu konieczne jest zachowanie granic, pustej linii oddzielającej nagłówki od danych oraz właściwego kodowania transferowego. Nawet drobne uszkodzenie separatora może sprawić, że program pocztowy pokaże surowy tekst albo potraktuje zasoby jako niezależne załączniki.

W nagłówku typu multipart/related często wskazuje się część startową za pomocą parametru start. Jeżeli parametr nie występuje, przyjmuje się zwykle, że główną częścią jest pierwsza część pakietu, jednak bezpieczniej jest jawnie określić dokument nadrzędny. Parametr type może informować o typie głównej zawartości, na przykład text/html. Te informacje pomagają odbiorcy ustalić, od którego elementu rozpocząć interpretację całej struktury.

Identyfikatory Content-ID powinny być unikatowe w obrębie wiadomości i konsekwentnie używane w odwołaniach. Należy zwrócić uwagę na nawiasy ostre występujące w nagłówku oraz na prefiks cid: używany w HTML. Nie jest to jednak mechanizm automatycznej konwersji dowolnych ścieżek. Jeśli dokument wskazuje obraz przez cid:baner@example, w pakiecie musi znaleźć się część z dokładnie dopasowanym identyfikatorem, z uwzględnieniem sposobu interpretacji wartości przez konkretny klient.

W praktyce multipart/related bywa zestawiane z osadzaniem obrazu jako danych w adresie data:. Oba rozwiązania pozwalają ograniczyć zależność od zewnętrznego serwera, ale działają inaczej. Przy cid: obraz jest osobną częścią wiadomości, a HTML zawiera jedynie odwołanie. Przy data: dane obrazu znajdują się bezpośrednio w atrybucie dokumentu. Pierwszy wariant ułatwia rozdzielenie dokumentu i zasobów, drugi może zwiększać rozmiar samego kodu HTML.

Nie należy także mylić multipart/related z techniką pobierania obrazów z publicznych adresów HTTP lub HTTPS. Zasób referowany przez CID jest przekazywany w ramach tej samej wiadomości. Odbiorca nie musi pobierać go z sieci, choć klient pocztowy może stosować własne reguły bezpieczeństwa dotyczące wyświetlania grafiki.

RFC 2387 – MIME multipart/related: typowe problemy z wyświetlaniem

Jednym z częstych problemów jest pojawienie się pustego miejsca zamiast obrazu. Przyczyną może być literówka w identyfikatorze, brak nagłówka Content-ID, niezgodność między deklarowanym typem pliku a jego rzeczywistą zawartością albo niepoprawne kodowanie transferowe. Zdarza się również, że program pocztowy rozpoznaje obraz jako załącznik, ale nie wiąże go z elementem HTML, ponieważ całość została opakowana jako inny typ MIME.

Problemy mogą wynikać także z niejednoznacznej części startowej. Jeśli pierwszy element jest tekstem alternatywnym, a właściwy HTML znajduje się później, odbiorca może otworzyć niewłaściwą reprezentację. Pomocne jest jawne wskazanie start oraz kontrola parametru type. Warto sprawdzić również, czy identyfikator głównej części ma poprawną składnię i czy nie został zmieniony podczas generowania albo przekazywania wiadomości.

Innym przypadkiem jest wielokrotne zagnieżdżenie MIME. Wiadomość może mieć zewnętrzny typ multipart/mixed, wewnątrz którego znajduje się multipart/alternative, a w jednej z alternatyw dodatkowo multipart/related. Taka konstrukcja jest dopuszczalna, lecz wymaga precyzyjnego ustalenia, do którego poziomu należy każdy identyfikator i gdzie znajduje się odpowiadający mu zasób. Błąd na jednym poziomie może być widoczny dopiero w określonym programie pocztowym.

Warto pamiętać, że poprawna konstrukcja MIME nie gwarantuje identycznego wyglądu w każdej aplikacji. Klienci pocztowi mogą usuwać niektóre elementy HTML, blokować skrypty, zmieniać style albo ograniczać automatyczne ładowanie grafiki. RFC 2387 opisuje powiązanie części wiadomości, ale nie narzuca pełnego sposobu renderowania dokumentu. Dlatego testy powinny obejmować kilka środowisk, a dokument powinien zachowywać czytelność również wtedy, gdy obraz nie zostanie pokazany.

Problematyczne bywają także nazwy plików i parametry Content-Disposition. Obraz przeznaczony do użycia wewnątrz HTML nie powinien być konfigurowany wyłącznie jako zwykły załącznik bez sprawdzenia, jak zinterpretuje go klient. Należy też uważać na kodowanie znaków w dokumencie, wielkość liter w nazwach typów MIME oraz dodatkowe nagłówki generowane automatycznie przez biblioteki pocztowe.

RFC 2387 – MIME multipart/related: praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od zapisania pełnej wiadomości w formacie źródłowym, a nie od samego widoku wizualnego. W źródle należy odszukać nagłówek Content-Type: multipart/related, jego parametry oraz wszystkie granice boundary. Następnie trzeba ustalić, która część jest dokumentem głównym i czy jej identyfikator odpowiada wartości parametru start, jeśli taki parametr został użyty.

Kolejny krok polega na stworzeniu tabeli powiązań: adres z atrybutu src lub innego odwołania w HTML, odpowiadający mu Content-ID, typ mediów oraz kodowanie transferowe. Takie zestawienie szybko pokazuje, czy nie występuje brakujący element, duplikat identyfikatora albo różnica w zapisie. Przydatne jest również sprawdzenie, czy po dekodowaniu zawartość rzeczywiście zaczyna się od poprawnego nagłówka pliku graficznego i czy nie została obcięta na granicy MIME.

W przypadku wiadomości generowanych automatycznie należy zweryfikować bibliotekę lub moduł odpowiedzialny za budowanie MIME. Niektóre narzędzia tworzą poprawny HTML, ale nie dodają części z obrazem. Inne dodają obraz, lecz używają identyfikatora różnego od tego, który trafia do atrybutu src. Warto zachować testową wiadomość przed wysłaniem oraz porównać ją z wersją odebraną, ponieważ po drodze system pocztowy może zmienić kodowanie, dopisać nagłówki albo przekształcić strukturę.

Przy diagnozowaniu nie należy ograniczać się do jednego obrazu. Jeśli jeden zasób działa, a drugi nie, można porównać ich identyfikatory, typy MIME, kodowanie i położenie w strukturze. Jeżeli nie działa cała wiadomość, większe znaczenie mają nagłówki nadrzędne, granice oraz wybór części startowej. Oddzielne testy pozwalają rozdzielić błąd w kodzie HTML od błędu w pakowaniu danych.

Dobrym rozwiązaniem jest przygotowanie prostego wariantu awaryjnego: tekstu alternatywnego, opisowego atrybutu alt oraz układu, który zachowuje sens bez grafiki. Dzięki temu ograniczenie obsługi CID przez konkretny program nie pozbawia odbiorcy najważniejszej informacji.

RFC 2387 – MIME multipart/related: kiedy potrzebna jest pomoc serwisu

Do specjalistycznej analizy warto zgłosić się wtedy, gdy wiadomości są poprawnie generowane w jednym środowisku, lecz po przekazaniu przestają wyświetlać osadzone zasoby, gdy załączniki zmieniają się w niezrozumiałe pliki albo gdy problem powtarza się mimo zgodności identyfikatorów. Pomoc może obejmować odczyt źródła wiadomości, sprawdzenie struktury MIME, rozpoznanie błędnego kodowania oraz ocenę, czy problem dotyczy programu pocztowego, konfiguracji urządzenia czy samego generatora wiadomości.

W takich przypadkach Warszawskie Pogotowie Komputerowe 24/7 przyjmuje zgłoszenia dotyczące diagnostyki laptopa i problemów z oprogramowaniem, w tym sytuacji, w których nieprawidłowo obsługiwane wiadomości utrudniają codzienną pracę. Przed przekazaniem materiału warto usunąć poufne treści, adresy odbiorców i dane, które nie są potrzebne do analizy. Najbardziej pomocne są opis objawu, informacja o programie, w którym występuje problem, oraz przykładowa wiadomość zapisana w bezpiecznej, zanonimizowanej formie.

Jeśli trudność dotyczy wyłącznie jednego klienta pocztowego, można rozpocząć od aktualizacji programu, sprawdzenia ustawień wyświetlania obrazów i porównania tej samej wiadomości w innym środowisku. Jeżeli natomiast problemy pojawiają się w wielu aplikacjach, konieczne jest dokładniejsze zbadanie nagłówków oraz sposobu generowania całej struktury MIME. RFC 2387 daje zasady tworzenia relacji między częściami, lecz skuteczna diagnoza wymaga jeszcze sprawdzenia implementacji, kodowania i zachowania odbiorcy.