Кратко

  • RFC 1524 позволил разным почтовым клиентам использовать общие правила mailcap: сообщение объявляло Content-Type, а локальная очерёдность, совпадение и тест выбирали просмотр, создание, редактирование или печать.
  • В UNIX выбранное правило становилось командной строкой Bourne shell с подставленными параметрами или временными именами. Совпадение, успешный тест и нулевой код процесса не доказывали подлинность, безопасность или согласие пользователя.

Тип пересекал сеть, программа — нет

MIME дал интернет-почте имена для изображений, звука и составных тел и способы перенести их через старую инфраструктуру. Но Content-Type не устанавливал просмотрщик у адресата. Машины различались программами, оконными системами, терминалами и устройствами.

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

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

Побеждало первое применимое правило

Действующая конфигурация была виртуальным объединением нескольких файлов mailcap. Запись должна была совпасть с Content-Type, содержать требуемое действие и пройти необязательный test=. Использовалась первая запись, выполнившая все условия.

Порядок становился поведением. В UNIX-приложении пользовательский файл шёл перед системными, а переменная MAILCAPS могла заменить весь путь. Администратор задавал общий вариант, пользователь дополнял или перекрывал его. Поэтому одинаковые байты в двух учётных записях могли вызвать разные программы.

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

Тест мог запускать сложную проверку архитектуры, оконной системы или аудиоустройства. Нулевой код означал применимость записи в среде. Он ничего не утверждал о безопасности полученного тела.

Шаблон превращался в исполняемый текст

UNIX-семантика RFC 1524 считала действия полными строками для Bourne shell, фактически с /bin/sh -c впереди. %t заменялся типом, %{name} — параметром Content-Type, %n — числом частей, %F — последовательностью типов и файлов, %s — именем файла с телом.

Значит, система анализировала заголовок, выбирала запись, разбирала экранирование, подставляла значения, строила аргументы и передавала исполняемый текст ОС. Каждому переходу нужен свой след. Синтаксически допустимый параметр мог получить неверные границы аргумента. Запущенный процесс мог прочитать не тот объект или выдать бесполезный результат.

%s менял канал данных. Без него просмотр и редактирование читали стандартный ввод. С ним клиенту мог понадобиться временный файл. RFC предупреждал: после завершения команды нельзя рассчитывать на его существование; фоновый обработчик должен был сам сохранить нужные данные.

nametemplate позволял добавить суффикс вроде .gif, требуемый программой. Удобное имя не проверяло байты, автора и безвредность.

Создание имело собственную границу

Программа compose производила данные, которым вызывающий клиент присваивал тип правила. composetyped могла сама выдать Content-Type и связанные заголовки. Транспортное кодирование оставалось обязанностью вызывающей стороны, если производитель явно не объявлял его.

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

Расширяемость не передавала доверие

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

RFC 2045, 2046 и 2048 переработали MIME, а RFC 6838 обновил регистрацию типов. Регистрация делает имя и документацию общими. Она не устанавливает обработчик, не доказывает победившее правило и не разрешает выполнение.

Для расследования нужны полученные байты и тип; действующие mailcap-файлы и порядок; запрошенное действие; правило и тест; развёрнутая команда; stdin или временный файл; процесс и результат; показанный объект и решение человека. Фраза «вложение открылось» стирает именно место превращения описания в полномочие.

Источники