Кратко

  • RFC 2017 добавил тип доступа URL к message/external-body: сообщение содержало описание извлечения, а байты объекта оставались вне его.
  • Разбиение и кодирование сохраняли адрес в заголовке, но не доказывали доступность, постоянную идентичность, подлинность или разрешение на обращение.
  • Сверка типа, явное согласие и проверка Content-MD5 были независимыми мерами; официальные источники не подтверждают широкое внедрение.

Модель отсутствующего тела появилась в MIME раньше. RFC 1521 перечислял FTP, анонимный FTP, TFTP, локальный файл и почтовый сервер как способы получить содержимое извне. RFC 2017 зарегистрировал ещё один вариант — URL. Обязательный одноимённый параметр задавал путь, а внутренний заголовок сущности объявлял ожидаемый тип данных.

При этом подходил не любой URL. Спецификация допускала только схемы, которые действительно извлекают объект, и прямо исключала mailto. Эта схема обозначает почтовый ящик и действие отправки, а не непосредственный доступ к данным внешнего тела. Синтаксическое родство не означает одинакового результата.

Длинный указатель требовалось безопасно провести через заголовок письма. RFC 2017 представлял его как заключённую в кавычки последовательность фрагментов URL-word длиной не более сорока знаков, разделённых линейными пробелами. Получатель удалял кавычки и эти пробелы. До разбиения пробелы без кодирования, управляющие знаки, кавычки, обратные косые черты и восьмибитные октеты кодировались по историческим правилам RFC 1738.

Это сохраняло представление адреса, но не его обещание. Узел мог исчезнуть, потребовать иных полномочий, перенаправить запрос или выдать новые байты. Безошибочно доставленная инструкция могла так и не привести к объекту.

Объявленный тип и ещё неизвестные байты

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

«Фантомное тело» для URL не использовалось и должно было оставаться пустым. Пустота честно показывала: внутри нет даже уменьшенной копии. Это отличало режим URL от mail-server, где та же область содержала команду серверу.

RFC 2046 вскоре заменил RFC 1521, сохранил external-body и потребовал Content-ID для связи кэша с последующими уведомлениями. Он также сформулировал риск: разрешение внешнего тела заставляет получателя выполнить операцию, указанную отправителем. Агент должен объяснить действие и запросить явное разрешение.

Верный синтаксис такого разрешения не даёт. Совпавший дайджест не является подписью. RFC 2017 допускает Content-MD5 для проверки целостности полученных байтов и соответствия намерению отправителя, но сразу уточняет, что это не цифровая подпись. RFC 1864 проводит ту же границу.

Поэтому письмо и удалённый объект имеют разные цепочки доказательств. Проверка сообщения автоматически не распространяется на байты, позднее полученные по другому протоколу. Маршрут можно подменить, ресурс — изменить. URL описывает способ извлечения, но не постоянную идентичность содержимого.

Актуальные записи по-прежнему относят RFC 2017 к Proposed Standard; поиск не показал относящихся к нему исправлений на момент проверки. RFC 1738, чьи правила кодирования использовались исторически, теперь устарел; RFC 3986 задаёт более поздний общий синтаксис URI. Это устанавливает контекст документов, но не доказывает масштаба внедрения, успеха эксплуатации или прямого родства с современными продуктами.

Исторический урок прост: адрес получен, действие разрешено, объект извлечён, тип подтверждён и целостность проверена — пять разных фактов. Объединяя их в один зелёный статус, система создаёт гарантию, которой в RFC 2017 нет.

Источники