Тип Multipart. 
Разработка почтовой программы на основе протоколов SMTP и POP3

Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтаксис письма RFC 822 (то есть, иметь заголовок, пустую строку и тело), но должна иметь открывающую и закрывающую границы.

Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть начинающиеся с «Content-». Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться «X-» поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.

Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Программы должны иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содержащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь «Content-Type: message» и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка «Content-Type: image» .

Граница части письма не должна появляться внутри самой части письма.

Общий синтаксис Поле Content-Type многочастного письма требует одного параметра, «boundary», который определяет границы вложения. Границей является строка, состоящая из двух символов «-» и значения параметра 'boundary' из поля заголовка Content-Type.

Зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит.

Метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части. Сразу за меткой границы должен следовать конец строки (CRLF). Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.

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

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

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

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

Граница.

0*69.

символ границы := символ_границы_без_SPACE / ««.

символ_границы_без_SPACE := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА /.

" '" / «(«/ «)» / «+» / «_» / «,» /.

" -" / «.» / «/» / «:» / «=» / «?» .

Многочастное письмо приамбула * признак_конца эпилог вложение := разделитель часть_тела CRLF.

разделитель := «—» метка_границы CRLF.

признак конца := «—» метка_границы «—» CRLF.

приамбула := игнорируемый текст эпилог := игнорируемый текст игнорируемый текст := *(*текст CRLF).

часть_тела :=.

Основной подтип «multipart/mixed» .

Это основной подтип для типа 'multipart', он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу 'mixed'.

Подтип «multipart/alternative» .

Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику. Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.

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

Подтип «multipart/digest» .

Этот подтип идентичен подтипу 'multipart/mixed', но имеет другую семантику. Например, для 'digest' значением по умолчанию является не «text/plane», а «message/rfc822» .

Подтип «multipart/parallel» .

Отличие этого подтипа от «multipart/mixed», в частности, состоит в том, что порядок расположения частей письма не принципиален.

Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями.