Кратко

  • RFC 2076 был информационным каталогом, а не общей стандартизацией: почта, Usenet, шлюзы X.400 и нестандартная практика сохраняли разные области действия.
  • Из каталога исключались конверты SMTP, UUCP и NNTP, а также внутренние поля тел PEM и MOSS. Блок заголовков никогда не описывал всю транзакцию.
  • Цепочка доказательств идёт от появления к определению, протоколу, статусу, локальному решению и наблюдаемому исходу; один этап не удостоверяет следующий.

В 1997 году RFC 2076 не предложил очередное поле. Он упорядочил уже встречавшиеся имена, не скрывая разницу между стандартными, экспериментальными, спорными, нежелательными, специфичными для Usenet, шлюзовыми и просто распространёнными полями.

Одна форма не означала одну юрисдикцию

Каталог ссылался на почту RFC 822, новости RFC 1036 и преобразования X.400 из RFC 1327. Попадание поля Usenet в письмо не стандартизировало его для почты. X400-Received и Alternate-Recipient сохраняли контекст шлюза.

Позднее RFC 3864 оформил постоянный и предварительный реестры. Одно имя может иметь записи для разных протоколов, а предварительная регистрация не является одобрением IETF или IANA. RFC 4021 и нынешний реестр IANA по-прежнему разделяют протокол, статус и ссылку.

Исключения обозначали границы слоёв

Транспортный конверт, поля внутри тел PEM/MOSS и чисто HTTP-заголовки не входили в область RFC 2076. Поэтому видимая строка не заменяла реальных получателей, обратный адрес транспорта или утверждение безопасности внутри содержимого.

Для расследования нужны исходное сообщение, конверт, цепочка ретрансляторов, преобразования шлюзов и решение клиента. Раннее сведение в единый объект стирает происхождение факта.

Apparently-To превратил догадку в утечку

Некоторые версии sendmail добавляли поле из получателей конверта, если отсутствовало To. RFC 2076 называл его нестандартным и нежелательным: могли раскрыться получатели скрытой копии. Частное знание транспорта становилось содержимым для читателя.

Reply-To имел стандартное определение, но оставался спорным: личный ответ, ответ группе и политика рассылки отражают разные намерения. Errors-To и Return-Receipt-To были нестандартными и нежелательными; запрос уведомления не доказывал доставку, чтение или последствие.

Надёжна лишь цепочка: появление → документ → контекст → статус → обработка → результат.

Источники