Кратко

  • В RFC 2231 нумерация продолжений начинается с нуля и идёт без пропусков. Кодировка и необязательный язык объявляются только в начале первой кодированной части; порядок задают индексы, а не расположение полей.
  • Успешно восстановленный filename остаётся рекомендацией Content-Disposition. RFC 2183 требует удалить путь, исключить опасное размещение и перезапись и не допускать запуск без явного действия пользователя.

Сначала собрать октеты

Рассмотрим условный пример, составленный для объяснения:

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

Это не три имени. Нулевая часть объявляет UTF-8 и необязательный язык и начинает значение; первая продолжает процентно-кодированные данные; вторая завершает их без отметки кодирования. При полной и однозначной последовательности 0, 1, 2 получается Quarterly review final.pdf.

Нельзя полагаться на порядок появления. Порядок MIME-параметров сам по себе незначим, поэтому посредник может поставить *2 перед *0. RFC 2231 требует начала с нуля, шага ровно в единицу, отсутствия пропусков и ведущих нулей. Реализация группирует общий базовый параметр, обнаруживает неоднозначные дубликаты, проверяет ряд и соединяет части по индексу.

Декодировать каждый фрагмент как отдельный текст тоже неправильно. Кодировка и язык задаются один раз в начале. Граница продолжения нужна транспорту и не обязана совпадать с границей символа. Октеты одного знака UTF-8 могут оказаться в разных частях; раздельное декодирование породит заменяющий символ или расхождение между двумя программами.

Надёжная цепочка разделяет операции: разобрать имена; подтвердить единственную непрерывную серию; соединить полезные данные по номеру; превратить процентные последовательности в октеты; один раз применить объявленную кодировку; затем передать текст отдельной политике Content-Disposition. Раздел Security Considerations в RFC 2231 краток, но грамматика и единственное начальное объявление поддерживают именно такой порядок.

Понять значение — не значит исполнить его

RFC 2231 расширяет представление параметра и не даёт удалённому отправителю власть над локальной файловой системой. RFC 2183 называет filename предлагаемым именем для сохранения части тела сообщения.

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

Даже корректная строка UTF-8 может содержать ../, абсолютный путь, управляющие знаки, двунаправленные маркеры, зарезервированное имя или обманчивое расширение. Процентное декодирование ничего не очищает. Корректная кодировка не подтверждает отправителя. Совпадение имени с Content-Type не доказывает безопасность байтов. Ни одна проверка не разрешает заменить, открыть, запустить или приписать содержимое кому-либо.

Поэтому границы остаются независимыми. MIME-парсер оценивает структуру. Декодер определяет текст. Локальная политика создаёт безопасное имя. Хранилище ограничивает место и разрешает коллизии. Пользователь или отдельная авторизованная политика принимает решение об открытии. Успех на одной стадии не служит пропуском на следующую.

Авторство нельзя дополнять по соседству тем

Авторы RFC 2231 — Нед Фрид и Кит Мур. У заменённого им RFC 2184 те же два автора. Такова точная документальная граница соавторства механизма продолжений MIME.

Патрик Фальстрём важен для истории интернационализации Интернета, но он не автор RFC 2231 или RFC 2184. В RFC 3490 об исходной версии IDNA Фальстрём указан вместе с Полом Хоффманом и Адамом Костелло. Тематическое соседство не создаёт соавторства: документ, группа авторов и область технического соглашения остаются разными.

Большой корпус работ Фрида по почте и медиатипам виден в IETF Datatracker. В воспоминании Натаниэль Боренстайн описывает встречу своей цели сделать почту богаче с вниманием Фрида к устойчивости и совместимости. RFC 2045 задаёт формат тел MIME, RFC 2047 рассматривает не-ASCII-текст в заголовках, а RFC 2231 решает более узкую задачу параметров.

Узость предохраняет от ложных выводов. Звёздочка в имени любого поля сама по себе не включает семантику RFC 2231; определяющая спецификация должна принять её явно. Возможность передать международное имя не превращает это имя в утверждение личности.

HTTP оставил кодирование, но убрал продолжения

RFC 8187 использует для HTTP родственную форму кодированного параметра и требует UTF-8, однако не включает продолжения RFC 2231: HTTP они не понадобились. Техническая преемственность не требует одинакового контракта.

RFC 6266 повторяет главную границу для HTTP Content-Disposition: имя рекомендательное. Получатель отбрасывает путь, сам выбирает каталог, нейтрализует опасные расширения, управляющие знаки и специальные имена. Сервер предлагает метку, но не получает контроль над файловой системой клиента.

Наследие RFC 2231 состоит в двойной точности. Совместимость требует строгой нумерации, одного начального объявления и определённого порядка сборки. Безопасность требует столь же строго обозначить, чего результат не доказывает. Строку можно восстановить полностью и по-прежнему не доверять ей.

Источники