Кратко

  • RFC 934 считал строку, начинающуюся с дефиса, возможной границей между вложенными сообщениями. Агент пересылки ставил перед похожей строкой данных, а агент извлечения снимал эту добавку.
  • Операция обратима для каждой оболочки, но промежуточная строка не остаётся той же длины: при каждом следующем вложении появляется ещё один префикс.
  • MIME сохранил потребность в однозначной границе, но ввёл объявляемое значение boundary, которого не должно быть в части. RFC 2046 прямо связывает отказ от RFC-934-квотирования с ростом строк и переносами длинных SMTP-строк.

Символ получает полномочие только в известной грамматике

У ранней почты уже была структура. RFC 822 отделяет поля заголовка от тела первой пустой строкой; в структурированных полях кавычки, скобки и обратная косая черта могут быть синтаксисом, а не данными. Но это не делает их управляющими знаками во всём сообщении. Их роль определяют поле, положение и состояние разбора.

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

RFC 934 описывал forwarding agent, создающий внешний черновик до отправки, и bursting agent, разбирающий его после доставки. Внешнее тело могло содержать вступление, вложенные сообщения и заключение. В начальном соглашении encapsulation boundary была любая строка, начинающаяся с .

Так несколько писем удобно располагать подряд: граница может быть концом одного и началом следующего, а две соседние границы обозначают пустое сообщение. Но вложенный автор вполне мог написать строку - заметка как элемент списка. Без дополнительного различителя агент извлечения не знает, нужно ли отдать эту строку как данные или завершить внутреннее письмо.

Внешний слой оставлял обратимую отметку

RFC 934 предложил character stuffing. Когда forwarding agent видит во вложенном тексте строку, начинающуюся как граница, он выводит перед оригиналом дефис и пробел. - заметка во внешнем представлении становится - - заметка. Если bursting agent встречает в начале строки , он не признаёт границу и выводит остаток. Настоящая граница, напротив, переключает его на другое сообщение.

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

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

Восстановление не отменяет рост в пути

RFC 934 справедливо говорит о рекурсивной пересылке. Первая оболочка превращает - заметка в - - заметка. Вторая снова видит строку, начинающуюся с дефиса, и добавляет своё ; снаружи получается - - - заметка. Каждая оболочка при разборе должна снять только свою добавку. Удалить все похожие префиксы означало бы уничтожить метку внутреннего слоя или сами данные.

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

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

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

MIME перенёс работу по предотвращению коллизии

RFC 2045 называет RFC 934 и RFC 822 среди предшественников MIME. MIME вводит описанные сущности и multipart-тела. Это общий синтаксис для тех, кто его применяет, а не ретроспективное доказательство поведения всей старой почты.

В RFC 2046 multipart-сущность объявляет параметр boundary. Разделяющая строка состоит из двух дефисов и этого значения; значение не должно встречаться внутри вложенной части отдельной строкой или префиксом строки, а вложенные multipart-сущности выбирают другие значения. Работа переносится к составителю: он обязан выбрать границу без коллизии с материалом.

Граница всё ещё локальна. Она действует потому, что заголовок данной сущности её объявил и потому, что получатель разбирает именно эту multipart-грамматику. Те же символы в простом тексте не приобретают структуры от одного внешнего сходства.

RFC 2046 сохраняет два дефиса для приблизительной совместимости с методом RFC 934 и удобства поиска границ, но подчёркивает, что multipart не подчиняется конвенции RFC 934 для цитирования вложенных строк с дефисом. Причина практическая: строки растут на каждом уровне, а SMTP-реализации иногда переносят длинные строки. Для глубокой вложенности временная форма сама становится источником несовместимости.

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

У структурного полномочия должен быть срок действия

Главный вопрос таков: когда метка становится структурой и когда обязана снова стать данными? В RFC 934 защищает строку только от толкования внешней оболочкой и исчезает при извлечении. В MIME boundary имеет силу только внутри сущности, объявившей его.

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

Растущий дефис добавляет тест композиции: насколько увеличивается форма, где она встречает ограничение, какие посредники её меняют и сохраняет ли нормализация признаки, нужные для возврата. Без этих вопросов «обратимо» остаётся слишком слабым эксплуатационным утверждением.

Источники и границы доказательств

Закрытый набор источников: RFC 822, RFC 934, RFC 2045 и RFC 2046. Он подтверждает исторические правила и документированное различие MIME, но не подтверждает всеобщее развертывание, поведение современного продукта, измеренную частоту глубокого вложения или безопасность конкретного парсера.