Кратко

  • RFC 5256 делает сортировку и построение потоков воспроизводимыми, но результат остаётся проекцией, зависящей от поиска, алгоритма, правил сравнения, качества заголовков и состояния ящика.
  • Ребро может возникнуть из заявленной ссылки Message-ID, фиктивного предка для отсутствующего сообщения или слияния по теме; ни один механизм сам по себе не доказывает намерение ответить, полную родословную, хранение или доставку.

Интерфейс завершил историю раньше расследования

В отчёте об инциденте семь писем висели под одним корнем. Рисунок читался как распоряжение, подтверждения и исполнение. Позднее выяснилось, что запрос исключал предыдущие двое суток. Сервер правильно упорядочил выбранный набор; читатели ошибочно приняли набор за всю переписку.

THREAD сначала выполняет поиск. Только затем выбранный алгоритм применяется к совпавшим сообщениям. Новый диапазон дат, слово, папка или состояние ящика способны изменить дерево без изменения самих писем. Результат отвечает, как правило организует эти записи сейчас, а не восстанавливает исчерпывающую человеческую беседу.

Нужно различать слой записей, преобразования и отображения. Письма и серверные метаданные — записи. Поиск, декодирование, нормализация, сравнение и построение дерева — преобразование. Отступы, линии и надпись «разговор» — отображение. Экран вправе объединить их для удобства, но не получает доказательную власть, которой не было у исходных данных.

Управление распределено между участниками

Клиент выбирает критерии, кодировку и алгоритм. Сервер обрабатывает конкретное состояние ящика, толкует заголовки и возвращает номера последовательности или UID. Отправляющая программа создала Message-ID, References и In-Reply-To. Приложение рисует связи.

Все могут действовать по стандарту, а вывод останется ошибочным. Ложный References:, корректно обработанный сервером, станет убедительной ветвью. Отсутствующий родитель мог быть отфильтрован, удалён или никогда не получен. Линия не аутентифицирует автора заголовка, а пробел не объясняет свою причину.

Агентская проблема возникает, когда владелец запроса или интерфейса получает возможность определять институциональную память. Выбор представления не даёт полномочий единолично утверждать, кто кому ответил, согласился или принял ответственность.

ORDEREDSUBJECT честно группирует темы

RFC 5256 называет ORDEREDSUBJECT «poor man's threading». Обязательная процедура извлекает базовую тему, одинаковые результаты собираются вместе и сортируются по дате отправки. Первое письмо становится корнем; все последующие — его непосредственными детьми и соседями друг другу. Внуков нет.

Это классификация по теме, а не генеалогия ответов. Она полезна при нехватке ссылок, но может объединить независимые письма с одинаковой темой или разделить настоящий разговор после изменения заголовка.

Базовая тема уже является производным значением. Кодированные слова декодируются, пробелы сжимаются, определённые префиксы ответа, оболочки пересылки, хвосты и блоки удаляются. Подключённые и автономные реализации обязаны применять один процесс, чтобы не показывать разные результаты. Такая согласованность подтверждает выполнение правила, но не смысл удаления. RFC предупреждает, что значимый текст можно ошибочно принять за служебный фрагмент.

REFERENCES разрешает неполные заявления

REFERENCES использует Message-ID из References, а при определённых условиях — первый допустимый ID из In-Reply-To. Эквивалентные написания нормализуются, связи с циклом запрещаются.

Если допустимого Message-ID нет, письмо получает уникальный идентификатор для вычисления. Если несколько писем повторяют один ID, значение сохраняет только первое с наименьшим номером последовательности, остальным назначаются выдуманные ID. Если упомянутого предка нет в наборе, создаётся фиктивное сообщение.

Затем структура обрезается. Фиктивный узел без детей удаляется. Узел с детьми может исчезнуть, а дети подняться на уровень выше. У корня структурный фиктивный узел иногда сохраняется. Конфликты усечённых цепочек решаются явными правилами сохранения или разрыва родительской связи.

Это детерминированный ремонт, а не восстановление прошлого. Фиктивный узел не является найденным письмом. Подъём ребёнка не доказывает отсутствия посредника. Выдуманный ID не становится аутентифицированной личностью. Дерево фиксирует реакцию алгоритма на неопределённость.

Тема может соединить корни после обработки ссылок

После построения дерева идентификаторов REFERENCES сравнивает базовые темы корневых потоков. Одинаковые непустые темы могут быть слиты; предпочтение может получить письмо, не выглядящее ответом, либо создаётся новый фиктивный родитель.

Две одинаковые линии интерфейса могут иметь разное происхождение: прямую ссылку, цепочку идентификаторов или слияние по теме. Без происхождения каждого ребра аудитор не отличит заявление заголовка от решения представления.

RFC прямо предупреждает, что ложные данные References: могут втянуть один поток в другой. Нормализация устраняет различия кавычек, но не аутентифицирует автора поля и не подтверждает описанную связь.

В сортировке по дате встречаются разные часы

SORT сначала ищет, потом применяет ключи по приоритету. При равенстве всех явных критериев номер последовательности ящика становится последним неявным ключом. Поэтому REVERSE SUBJECT не является полным переворотом SUBJECT: неявное разрешение равенства не разворачивается.

DATE начинает с Date:, приведённого к UTC. Недопустимые зоны и времена получают предусмотренные замены. Если дату отправки разобрать нельзя, используется INTERNALDATE. Одна колонка способна смешать заявленное автором время, нормативную замену и серверную дату.

RFC 5957 добавляет сортировку по отображаемому имени. Используется полное декодированное имя, а при его отсутствии — ящик и хост; фамилия по языковым правилам не угадывается. Это правильная граница: порядок должен называть ключ, а не изображать универсальный человеческий порядок.

Обновляемое представление не становится журналом хранения

UID устойчивее номера последовательности, но требует контекста ящика и UIDVALIDITY. RFC 5267 обновляет поисковые и сортировочные виды при изменениях, RFC 5182 повторно использует сохранённые результаты. Они повышают эффективность, не создавая неизменяемую историю.

Для важных решений сохраняйте состояние ящика, запрос и кодировку, алгоритм, сравнение, возможности и версию сервера, UIDVALIDITY и UID, исходные заголовки, нормализованные Message-ID, правило каждого ребра, фиктивные узлы и повышения, слияния тем, ключи равенства, хеш результата и версию отображения.

«В этом снимке представление RFC 5256 поместило B под A» проверяемо. «B написано как ответ на A» требует иных доказательств. «Получатель прочитал и принял A» — отдельное событие.

Источники