Кратко

  • RFC 3462 требовал, чтобы multipart/report был внешним MIME-контейнером с двумя обязательными частями в заданном порядке: объяснением для человека и типизированной записью для машины. Третья часть могла вернуть исходное сообщение или полезный фрагмент.
  • Формат делал отчёт узнаваемым, но не достоверным. report-type называл подтип второй части, однако правильно оформленная подделка всё ещё могла обмануть читателя или запустить опасную автоматизацию.

Одно событие читали по-разному

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

Опубликованный в январе 2003 года RFC 3462 задал такую упаковку. Текстовая версия, карточка RFC Editor, Datatracker, история документа, ссылки, последующие цитирования и поиск исправлений образуют проверяемую запись. Документ заменил RFC 1892 и превратил оболочку уведомления в общее семейство MIME-отчётов.

multipart/report должен был стоять на самом внешнем уровне MIME-содержимого. Помимо boundary, обязательного для multipart по RFC 2046, требовался report-type. Его значение называло MIME-подтип второй части. Программа могла увидеть внешний заголовок, распознать отчёт и заранее узнать ожидаемый формат машинной записи.

Порядок был частью смысла

Первая часть была обязательной и предназначалась человеку. Допускался любой MIME-тип, заданный стандартом, подходящие язык и кодировка, а также multipart/alternative для нескольких представлений. Гибкость была необходима: полезное объяснение зависит от аудитории.

Вторая часть тоже была обязательной, но предназначалась машине. Зарегистрированный медиатип описывал событие обработки сообщения и мог нести детали для специалистов. Для уведомлений о состоянии доставки RFC 3464 использовал message/delivery-status. Общий контейнер не заменял запрос уведомлений SMTP из RFC 3461 и расширенные коды состояния из RFC 3463. RFC 3462 определял место и вид машинного утверждения, а не сам факт доставки.

Третья часть была необязательной. Она возвращала исходное сообщение или фрагмент, достаточный для диагностики и сопоставления. При отсутствии явного уровня возврата рекомендовалось вернуть сообщение целиком, хотя это расходовало полосу и раскрывало содержимое. Если обратный путь для восьмибитных или двоичных данных был ненадёжен, генератор мог перекодировать их в допустимый семибитный MIME либо вернуть только text/rfc822-headers. Такие заголовки восходили к RFC 822, но не составляли полного сообщения и не могли честно называться message/rfc822.

Так возникло простое разделение доказательств. Первая часть объясняла, вторая позволяла вычислять, третья давала контекст. Убедительная фраза не становилась полем состояния. Поле не было исходным объектом. Набор заголовков не был целым сообщением. Общий конверт не стирал границы.

Распознавание не удостоверяло источник

Внешнее положение позволяло быстро отбирать отчёты по Content-Type. Реестр медиатипов IANA поддерживал общий словарь. Позже ту же оболочку использовали уведомления о распоряжении сообщением из RFC 3798, пересмотренные в RFC 8098, и интернационализированные статусы доставки из RFC 6533.

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

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

Позднейшая идея Heng Lu о слоях реальности помогает разделить полученный документ, интерпретацию парсера, событие почтовой системы и административное решение. Приоритет реально исполняемого кода направляет внимание на MIME-дерево, генератор, проверку и автоматического потребителя. Это последующие редакционные инструменты, а не свидетельство о частном замысле авторов RFC.

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

Источники