RFC 1521 — Почтовый стандарт MIME

7.3.2. Подтип 'message/partial'

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

Для этого подтипа необходимо указание трех параметров:

1. "id" — уникальный идентификатор, позволяющий обнаружить остальные части послания.
2. "number" — целое число, означающее номер части послания.
3. "total" — целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

Пример: часть 2 3-х частного послания имеет следующие варианты заголовка:

Content-Type: Message/Partial;
     number=2; total=3;
     id="[email protected]
"
Content-Type: Message/Partial;
     id="[email protected]
";
     number=2

Но часть 3 обязательно должна содержать параметр "total":

Content-Type: Message/Partial;
     number=3; total=3;
     id="[email protected]
"

Необходимо заметить, что нумирация частей начинается с 1, а не с 0.

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

Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем "внутреннее" письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.

При "сборке" таких посланий в пункте назначения должны учитываться следующие правила:

1. Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.
2. Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
3. Заголовки второй и последующих частей целиком игнорируются.

Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом:

   X-Weird-Header-1: Foo
   From: [email protected]
   To: [email protected]
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: message/partial;
        id="[email protected]
";
        number=1; total=2
   X-Weird-Header-1: Bar
   X-Weird-Header-2: Hello
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64
... здесь имеет место быть первая часть закодированных аудио-данных ...

А вторая может выглядеть так:

From: [email protected] To: [email protected] Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; id="[email protected] "; number=2; total=2 ... здесь имеет место быть вторая часть закодированных аудио-данных ...

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

   X-Weird-Header-1: Foo
   From: [email protected]
   To: [email protected]
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64
... первая часть закодированных аудио-данных ...
... вторая часть закодированных аудио-данных ...

Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа "message" никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим "8-бит" и "binary", запрещается их использование для данных message/partial.

Многие почтовые агенты могут автоматически фрагментировать большие письма.

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

Поле заголовка "Encrypted" вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.