Кратко

  • Начиная с RFC 733 уникальность обеспечивал хост, создававший идентификатор. Редакция получала новый ID, а добавленная при передаче трассировка не обязательно меняла исходную идентичность.
  • In-Reply-To и References превратили ID в рёбра беседы. Netnews сделал его локальной памятью: сервер записывал увиденные значения и отбрасывал повторы, останавливая циклы распространения.
  • Имя не было подписью или хешем содержимого. Netnews считал статьи с одним ID одной статьёй даже при разных телах; предсказуемое значение можно было занять заранее и вытеснить ожидаемую публикацию.

Байты изменились, сообщение — нет

На пути почты следующий сервер добавляет Received. Сохранённые байты уже не совпадают с поданными, но ретранслятор не создал новую редакцию мысли автора. Исходный Message-ID сохраняется.

Если автор меняет смысл и выпускает исправленный вариант как новую версию, ему нужен другой идентификатор, даже когда различается одна фраза. RFC 733 провёл эту границу в 1977 году: ID относится ровно к одной версии или реализации сообщения, последующие редакции получают новые значения, уникальность гарантирует создающий хост.

RFC 822 сохранил правило в 1982 году. Значение предназначалось машине и не обязано было что-либо объяснять человеку. Это не тема и не доказательство личности, а устойчивый указатель на объявленную версию.

Глобальное имя из локального учёта

RFC 5322 требует глобальной уникальности msg-id и возлагает гарантию на генератор. При этом никакая мировая служба не выдаёт номер каждому письму.

Пространство делится: справа от @ рекомендуется идентификатор домена, слева — значение, уникальное в его пределах, например время вместе со счётчиком или данными процесса. Глобально различимая область и локальный журнал образуют мировое имя без мировой транзакции.

Похожая на адрес форма ограниченна. Правая часть не является ящиком, не обязана разрешаться сегодня и не доказывает контроль домена или авторство. Левая часть тоже не обещает внешнему наблюдателю делового смысла.

RFC связывает идентичность с намерением отправителя. Поля трассировки и повторной отправки могут изменить синтаксис, не создавая иного сообщения. Смену ID определяет смысл — то же это сообщение или другое, — а не конкретное отличие байтов. Message-ID не checksum и не номер SMTP-транзакции.

Ответ стал переносимым ребром

In-Reply-To несёт ID родительского сообщения. References наследует его предков и добавляет ID родителя. Программа может собрать беседу, хотя письма пришли разными путями и в разное время.

Уже RFC 850 в 1983 году требовал, чтобы follow-up Usenet продолжал References исходной статьи. Целью было группировать публикации в разговоры и позволять читателю скрыть весь разговор, не покидая группу. RFC 1036 сохранил схему.

Объявленное ребро не является доказательством. RFC 5322 отмечает, что многие клиенты обходят цепочку назад, предполагая одного родителя; случай нескольких родителей определён не полностью. References не удостоверяет авторов и не доказывает понимание предшественника.

Каждый сервер превратил ID в память

При рассылке Usenet между соседями одна статья могла прийти с разных сторон. Повторная пересылка каждого экземпляра поддерживала бы цикл. RFC 1036 описывает локальную history: хост запоминает увиденные статьи по Message-ID и немедленно отбрасывает новый экземпляр того же ID. Path дополнительно экономит передачу, но списка увиденных имён достаточно, чтобы разорвать петлю.

Центральный сервер не объявляет глобальное завершение. Каждый узел сравнивает имя со своей памятью и решает, что логическую статью уже принял. Ссылка для человеческой беседы стала ключом распределённого подавления копий.

Одинаковое имя оказалось сильнее разного тела

RFC 5536 прямо задаёт цену: статьи с одинаковым Message-ID считаются одной статьёй независимо от различий заголовков или тела. Узкий синтаксис, предел длины и сохранение регистра позволяют сравнивать октеты напрямую. Уникальность охватывает почту и Netnews.

Так коллизия получает власть. Если злоумышленник предскажет ID будущей статьи и первым разместит другой объект, ожидаемую статью могут отвергнуть как уже виденную. Поэтому RFC 5536 рекомендует непредсказуемость. Не отказал хеш содержимого — хеша не было. Неверное заявление первым вошло в распределённую книгу имён.

Чего имя никогда не доказывало

Message-ID решает ссылку, не доверие. Он не подписывает тело, не удостоверяет From, не обозначает SMTP-конверт, не доказывает чтение и не гарантирует одинаковые байты. Равные ID могут скрыть коллизию, разные — нести одинаковый текст.

Механизм выжил благодаря скромности: источник именует; транспорт добавляет след без переименования; почтовый клиент строит отношения; сервер новостей ведёт локальную history. Криптографическое доказательство относится к другому слою.

Источники и пределы

Замкнутый набор: RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 и RFC 5536. Они не измеряют нынешние коллизии, алгоритмы провайдеров, долю внедрения или сроки history.