Кратко

  • Каждый фрагмент message/partial оставался самостоятельным почтовым сообщением. id связывал предполагаемый набор, number задавал место, а total — ожидаемое количество частей.
  • После сборки действовала семантика внутренней MIME-сущности. Заголовки первой внешней оболочки объединялись с выбранными внутренними полями; заголовки последующих оболочек не входили в производный результат.
  • Совпадающий идентификатор и полный ряд номеров не удостоверяли отправителя, равенство дублей, целостность или показ пользователю. Формат описывал проверяемую заявку, а рабочий объект создавался локальной проверкой.

У одного объекта не было одного предела

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

RFC 1123 зафиксировал противоречие в 1989 году. Почтовая программа должна была уметь отправлять и принимать не менее 64 Кбайт; значительно больший предел назывался весьма желательным. Одновременно документ признавал ограничения реализаций и передачу по почте файлов размером в мегабайт и больше. Это был общий минимум, а не сквозное обещание каждого узла.

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

Полное письмо могло нести неполное содержимое

Опубликованный в июне 1992 года RFC 1341 ввёл message/partial. Тело внешнего письма было фрагментом более крупного сообщения. Сама оболочка оставалась настоящим письмом со своим Message-ID, цепочкой Received, временем и результатом доставки.

Это противоположно multipart/mixed. Multipart помещает несколько частей в одну доставку. Partial распределяет одну предполагаемую сущность по нескольким доставкам. Часть 4 могла прийти раньше части 1 и пройти другой шлюз, не меняя своего смыслового места.

Успешный приём одной оболочки доказывал только её приём. Наличие трёх оболочек доказывало только три записи хранения. Промежуточный журнал не получал права объявить внутреннюю сущность завершённой.

Три параметра задавали порядок, но не доверие

id связывал части и должен был генерироваться максимально близко к всемирной уникальности. number обозначал позицию, начиная с 1. total сообщал ожидаемое число частей. Порядок параметров в Content-Type значения не имел.

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

RFC 1521 сохранил механизм в 1993 году и уточнил ограничения. Однако id не стал хешем содержимого. Две копии одного номера могли не совпадать по байтам. Идентификатор мог повториться по ошибке, а разные оболочки — назвать разные total. Поля формировали кандидата в набор, но не выдавали сертификат.

Получатель должен был проверить непрерывную последовательность от 1 до границы, применить локальное правило к дублям, отвергнуть противоречивые числа, ограничить объём и разобрать соединение как MIME. Стандарт давал одинаковые вопросы разным реализациям; ответ возникал у работающего кода с фактическими частями.

После сборки оболочка переставала определять смысл

Результатом становилась полная MIME-сущность со своим Content-Type. Если внутри находилось аудио, оно должно было выглядеть как аудио, а не как письмо с письмом, в котором спрятано аудио. Частичная упаковка была прозрачной транспортной конструкцией.

Отсюда следовали два уровня Message-ID. Каждая внешняя оболочка могла иметь собственный идентификатор, потому что совершала отдельное путешествие. Внутреннее сообщение могло иметь другой идентификатор, относящийся к собранной сущности. Первые описывали доставки, второй — объект. Их подмена стирала границу между путём и содержанием.

Время прибытия тоже не задавало порядок байтов. Если первой приходила часть 3, это характеризовало очереди и маршрут. Соединение всё равно выполнялось по number. Наблюдение за сетью не становилось властью над структурой.

Первая часть несла основу заголовка

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

Из первой внешней оболочки копировались обычные заголовки, кроме Content-* и полей Subject, Message-ID, Encrypted, MIME-Version. Из внутренней сущности добавлялись Content-* и перечисленные поля; остальные внутренние заголовки отбрасывались. Все заголовки второй и последующих внешних оболочек исключались из собранной сущности.

RFC 2046 закрепил это распределение в 1996 году. Оболочка number=1 давала сохраняемый внешний контекст. Внутреннее сообщение давало тип и выбранные смысловые поля. Другие оболочки оставались доказательствами отдельных маршрутов, но не голосовали за итоговый заголовок.

Поэтому первая часть была не просто первым диапазоном данных. Система могла сохранить все сегменты тела, удалить первую оболочку и лишиться нормативной основы заголовка. Выбор первой прибывшей оболочки вместо number=1 также создавал бы иной протокол.

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

Разные шлюзы потребовали общего режима 7bit

Данные 8bit и binary создавали особую ловушку. Тело типа message нельзя было просто закодировать снаружи в base64 или quoted-printable. Если разделить бинарную внутреннюю сущность, каждый partial потребует бинарного транспорта. Шлюз 7bit, увидевший одну часть, не мог ждать остальные, собрать и перекодировать всё: другие фрагменты могли идти через другие шлюзы.

Поэтому message/partial должен был использовать передачу 7bit, а внутреннее сообщение — не зависеть от 8bit или binary. RFC 2045 определял общую систему MIME-кодирования, а RFC 2046 накладывал более строгое правило на partial.

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

Разные пороги могли также породить вложенную фрагментацию. Собранная сущность сама могла оказаться message/partial. Спецификация прямо разрешала это. Получатель повторял процедуру по слоям, одновременно устанавливая собственный предел глубины и ресурсов.

SIZE заранее сообщал об ограничении, но не собирал объект

В 1995 году RFC 1870 ввёл расширение SMTP SIZE. Сервер мог объявить фиксированный максимум, а клиент — оценку размера до передачи тела. Очевидный отказ происходил раньше.

SIZE и message/partial управляли соседними, но разными поверхностями. SIZE решал вопрос приёма одного письма между SMTP-клиентом и сервером. Partial описывал сборку нескольких доставленных писем в пользовательском агенте. Положительный ответ на SIZE не гарантировал дальнейшую передачу или конечную доставку и ничего не говорил о поддержке сборки.

Первый механизм делал один локальный предел видимым. Второй сохранял значение через несколько пределов. Это не простая история замены старого новым, а разделение транспортного допуска и представления.

Три журнала не дают производному объекту стать ложной первичностью

Журнал оболочек хранит исходные байты, внешние Message-ID, Received, время и результат каждой доставки. Журнал набора хранит нормализованный id, номера, общие числа, пробелы, конфликтующие дубли и истечение. Журнал сборки хранит выбранную часть для каждой позиции, порядок, слияние заголовков, результат разбора, тип и последующие уровни.

Происхождение, целостность и безопасность оцениваются отдельно. Численно полный набор может нести вредоносное содержимое. Результаты аутентификации оболочек способны различаться. Успешный MIME-парсинг не подтверждает подпись, показ или прочтение человеком.

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