Message-ID, In-Reply-To, References: jak trzyma się wątek

To, że odpowiedzi układają się pod pierwotną wiadomością, wydaje się oczywiste. Nie jest. Wątek nie jest niczym, co gdziekolwiek by leżało zapisane — składa się go od nowa przy każdym otwarciu skrzynki, z trzech nagłówków niesionych w każdej wiadomości. Gdy wątki się rozpadają, prawie zawsze brakuje jednego z nich.

Trzy nagłówki

Message-ID wygląda tak:

Message-ID: <1a4f9c02-7e3b-4d51-9f18-2c6a0b7d4e88@firma.pl>

Część po znaku @ to domena systemu, który go utworzył; przed nią stoi wartość, która nie może się powtórzyć. Nawiasy ostre należą do formatu, nie są ozdobą.

Jak wątek rośnie

Różnica między tymi polami jest miejscem, w którym robi się ciekawie. Samo In-Reply-To wystarczyłoby na łańcuch — ale tylko dopóty, dopóki każda wiadomość jest obecna. Zginie jedna i łańcuch pęka, a reszta wisi w powietrzu.

References rozwiązuje dokładnie to: ponieważ każda wiadomość niesie pełną drogę do początku, program odnajdzie wspólne źródło również wtedy, gdy trzy wiadomości pomiędzy nigdy nie dotarły. Dlatego przekazana dalej odpowiedź układa się u nowego odbiorcy poprawnie, choć nigdy nie widział on początku.

Druga droga: po temacie

Część programów — Gmail robił tak przez długi czas — grupuje zamiast tego po temacie i uczestnikach. Ma to jedną praktyczną zaletę: działa również przy nadawcach, którzy nagłówków nie ustawiają. I dwie wady, które każdy zna, nie znając przyczyny:

• Kto zmieni temat, bo rzecz się przesunęła, rozszczepia wątek.
• Dwie niezależne wiadomości o temacie „Faktura" lądują w jednym wątku, choć nie mają ze sobą nic wspólnego.

Ani jedno, ani drugie nie zdarza się przy grupowaniu po identyfikatorach. Temat może zmieniać się dowolnie, dopóki jest References.

Gdzie to pęka w praktyce

Prawie zawsze przy wiadomościach generowanych automatycznie i prawie zawsze z jednego z tych powodów:

• Brak odwołań do odpowiedzi. System zgłoszeń odpowiada klientowi, ale nie ustawia ani In-Reply-To, ani References. Odpowiedź pojawia się u klienta jako nowa, niepowiązana wiadomość. To zdecydowanie najczęstszy przypadek.
• Znaczniki w temacie zamiast nagłówków. Właśnie dlatego w tylu tematach stoi [#48213]: system rozpoznaje po tym własne sprawy, bo na nagłówkach nie polega. Dla człowieka przed ekranem to szum.
• Zmienny identyfikator przy ponownej wysyłce. Gdy ta sama wiadomość zostaje doręczona dwa razy i za każdym razem dostaje nowy Message-ID, żaden odbiorca nie rozpozna powtórzenia. I odwrotnie: dwie różne wiadomości z tym samym identyfikatorem bywają przez część programów traktowane jako jedna — druga znika po cichu.
• Ucięte References. Część bramek skraca długie nagłówki. Po tym początku wątku nie da się już odnaleźć.

Co powinien robić system wysyłający

Reguły są krótkie:

1. Nadaj każdej wiadomości własny, trwale zapisany Message-ID. Kto zechce później na nią odpowiedzieć, będzie go potrzebował.
2. Przy odpowiadaniu ustaw In-Reply-To na identyfikator wiadomości, na którą odpisujesz, a References zbuduj z jej References plus jej Message-ID.
3. Gdy References nie ma, nowe składa się z samego Message-ID poprzednika.
4. Przy ponownej wysyłce tej samej wiadomości zachowaj identyfikator. Przy nowej wiadomości nadaj nowy.

To dwa pola więcej w wywołaniu wysyłki. Różnica dla odbiorcy jest znaczna: zamiast sześciu niepowiązanych wiadomości w skrzynce stoi jedna sprawa.

Sprawdzić samodzielnie

Wszystkie trzy pola stoją w nagłówku wiadomości i da się je pokazać w każdym programie — w Thunderbirdzie przez podgląd źródła, w Gmailu przez „Pokaż oryginał". Gdy wątek się rozpada, spojrzenie tam odpowiada na pytanie w dziesięć sekund: czy w odpowiedzi jest In-Reply-To i czy jego wartość to Message-ID wiadomości, która przyszła wcześniej? Jeśli nie, problemem nie jest program pocztowy.