Привет, администраторы Exchange! В этой статье мы рассмотрим, как Exchange обрабатывает сообщения, генерируемые клиентами iPhone, iPad и Macintosh Mail. В частности, мы собираемся рассмотреть, что из себя представляют сообщения с типом содержимого /mixed , как Exchange обрабатывает их сейчас и как мы обрабатываем их. Перед тем, как мы погрузимся в эту тему, вы сначала должны понять, как интернет сообщения структуризированы, т.е. как Exchange хранит сообщения, и что такое MIME.
Exchange, почтовые сообщения и прикольные коты
Exchange хранит сообщения как ряд свойств, где каждое свойство имеет имя и значение. Например, PR_SUBJECT – это свойство заголовка, а Test Message – это значение. Сообщения в Exchange имеют одно тело с множеством форм его представления (HTML, Rich Text и Plain text).
Представление тела сообщения в формате HTML выглядит вот так:
Это кот.
Не нравится
Представление RTF (rich text format) того же самого тела сообщения также способно включать как форматированный текст, так и картинки и должно выглядеть так:
Это кот.
Не нравится
Версия тела сообщения в формате plain text состоит из простого текста, что должно быть очевидно из его названия. Хорошая имитация генерации тела сообщения типа plain text – это вставка его в Блокнот. Если вставка в Блокнот получится, то это будет plain text. К сожалению изображения кота не будет:
Это кот.
Не нравится
Сообщения в Exchange могут иметь множество вложений (attachments). Это хорошо, потому что даже если Exchange вынужден генерировать версию тела сообщения в формате plain text , картинка с котом может прийти вместе с ним, так что если вы решите нажать на него, то вы сможете увидеть изображение кота, которому что-то не нравится.
Суть для гуманитариев и аллергиков на кошек: в Exchange сообщения могут иметь одно тело и множество вложений.
Теперь о MIME
MIME – это простой текстовый формат для почтовых сообщений. MIME сообщения делятся на "части", каждая из которых может иметь содержимое, в том числе вложенные части, подобно русской матрешке. Каждая часть MIME (даже корневая часть, или сообщение в целом) имеет заголовок Content-Type , который описывает тип содержимого этой части сообщения. Тип содержимого делится на основную и дополнительную части через дробь. Например, типы содержимого multipart/alternative или multipart/mixed. Каждая часть обязательно имеет тип, и даже если мы не можем точно определить тип части, ей назначается хоть какой-то тип (text/plain).
Иногда типы являются весьма полезными для понимания смысла содержимого, иногда это не так. Например. Content-Type: Application/PDF – этот тип содержимого означает, что это Adobe Portable Document Format. С другой стороны, Content-Type: application/octet означает: «Я не могу сказать, что это такое. Это двоичный объект. Надеюсь, вы разберетесь, что с ним делать».
Multipart/ – это обобщенный тип, означающий, что эта часть MIME может содержать множество дочерних частей MIME. Подтип части (то, что после дроби) говорит нам больше о дочерних частях, и в этом случае как они связаны друг с другом. Теперь рассмотрим подробнее некоторые подтипы обобщенного типа multipart, чтобы понять, где могут возникать проблемы.
Взаимосвязь
Прежде всего мы рассмотрим Multipart/related , (так называемые «связанные» части). «Связанные» в этом случае означает, что дочерние части MIME действительно связаны друг с другом. Другими словами, это дает следующую MIME структуру:
1. Multipart/related
1.1. Text/HTML
1.2. Image/Gif
Части 1.1 and 1.2 не должны восприниматься как «отдельные» части – они представляют собой единое целое. В этом случае html содержит ссылки на изображение в части 1.2 (на нашего кота).
Суть для гуманитариев и аллергиков на кошек: Multipart/Related означает «Мы единое целое.»
Альтернативы
Multipart/alternative означает, что каждая дочерняя часть – это иное представление одних и тех же данных. Они являются альтернативными версиями друг друга. Смысл в том, что клиент выбирает тип, который он может отобразить лучше, и отображает только его. Возьмем, например, следующую структуру mime:
1. Multipart/alternative
1.1.1. Text/Plain
1.1.2. Text/Html
1.1.3. Application/Pdf
Клиент не обязан показывать text/plain как тело сообщения. Нет, если клиент знает, как отобразить text/html, то ему разрешено сделать это.
Таким образом, multipart/alternative – это способ объединения ряда различных форматов одних и тех же данных и возможность для клиента решить, какой из них он показывает лучше.
Суть для гуманитариев и аллергиков на кошек: Multipart/Alternative означает: «Выбери то, что больше нравится.»
Смешанные
Multipart/Mixed , согласно RFC 1521, означает, что части сообщения полностью независимы друг от друга (не связаны друг с другом), но их порядок имеет значение. Какое поведение мы ожидаем? «Клиенты обычно отображают части сообщения друг за другом».
При этом начинает работать другой параметр в MIME части – Content-Disposition (расположение). Этот параметр имеет два возможных значения – Inline (внутри текста) и Attachment (как вложение). «Attachment» это легко понять – в контексте Exchange это означает «Покажи мне это в области вложений, так что Outlook может запретить мне сохранить или открыть его». «Внутри текста», с другой стороны, мы обрабатываем иначе. Помните фразу «сообщения имеют одно тело и могут иметь много вложений»? Помните это, пока мы рассматриваем, как наше сообщение с котом выглядит в случае тела сообщения типа /mixed:
1. Multipart/Mixed
1.1. Text/Html — Inline
1.2. Application/Gif — Inline
1.3. Text/Html — Inline
И цель почтовых клиентов, которые обрабатывают эту структуру, состоит в том, чтобы отобразить сначала часть text/html, затем после текста картинку и затем остаток тела сообщения. Не существует ограничений для вложений типа Multipart/«что-то», вы можете объединять их (и их расположение) в почти бесконечное число комбинаций. Например:
2. Multipart/Mixed
2.1. Text/Html -Inline
2.2. Image/Gif -Inline
2.3. Text/Html -Inline
2.4. Text/Plain -Inline
Это означает: «Покажи 2.1, затем картинку из 2.1, затем html из 2.3 и затем текст из 2.4. Сделай это СЕЙЧАС».
3. Multipart/Mixed
3.1. Text/HTML -Inline
3.2. Image/Gif –Attachment
3.3. Text/Html –Inline
3.4. Text/Plain –Attachment
Это означает «Покажи текст из 2.1, не показывай вложение из 3.2 пока кто-то кое-что не сделает, покажи текст из 3.3, но не показывай текст из 3.4 (пока кто-то не сделает что-то вроде клика мышкой на вложении)».
Проблема, конечно, происходит из определения в Exchange того, что есть сообщение – одно тело (с многими представлениями) и, возможно, несколько вложений.
Суть для гуманитариев и аллергиков на кошек: Multipart/Mixed может означать: «Можешь показать все это в указанном порядке».
Combo #5
Типы MIME не являются взаимоисключающими. Я могу объединить Multipart/Mixed, Multipart/Alternative и Multipart/Related в одно сообщение и получить
1. Multipart/Mixed
1.1. Multipart/Alternative
1.1.1.1. Text/Plain
1.1.1.2. Multipart/Related
1.1.1.2.1.1. Text/HTML
1.1.1.2.1.2. Image/Gif — inline
1.2. Image/Jpeg — attachment
Да, эта структура допустима. И она имеет смысл. Чтобы его понять, рассмотрите структуру по одному уровню за один раз.
Multi Mixed – это сообщение состоит из нескольких частей и порядок важен.
Multipart/Alternative – Я имею двух потомков, выбери лучшего и отобрази его.
Text/Plain – Я простой текст
Multipart/Related – Мои потомки это части одного целого
Text/HTML – «Милый, милый» текст.
Image/Gif – Я картинка кота, которая подписана «Милый, милый».
Image/Jpeg – Я вложение (на случай если вы не смогли увидеть картинку кота выше).
Exchange всегда хорошо обрабатывал части сообщения типа multipart/alternative, выбирая ту, которая лучше поддерживается. Мы также хорошо обрабатываем части сообщения типа multipart/related – не каждое вложение в сообщении видимое – вложения имеют параметр «расположение», который либо не задан, либо равен inline или attachment. Всё предельно ясно – клиент делает то, что он делает (и удачи тому, кто разработает алгоритм, работающий всегда). С другой стороны, для сообщений с типом вложений /mixed, где несколько частей заданы как «внутри текста», не работают настолько же хорошо.
Blender’d Messages
В случае типов вложений /mixed существует несколько частей MIME, которые должны объединяться вместе как японские роботы Voltron или как изображение кота и некоторый текст. Сегодня, если мы получаем такое сообщение, мы делаем лучшее, что мы можем с ним сделать (что абсолютно неудовлетворительно): мы выбираем первую часть тела сообщения, которая и задает тип тела сообщения – вроде части типа text/ , и именно эта часть становится видимой в Outlook. Все остальное – это вложения (attachments), и мы отображаем их области вложений (attachment well). О да, они могут иметь параметр «расположение» равный inline, но так как наиболее частое применение inline относится к HTML, то мы это реально проверяем, и всем, что не относится к ссылкам из тела HTML, мы не заморачиваемся – это все идет в область вложений.
С точки зрения Outlook вы берете первую часть сообщения, затем два вложения, одно из которых картинка, а другое завершающий текст. Вы можете открыть вложения друг за другом и объединить их мысленно в своей голове, чтобы получить сообщение, но как только вы получите больше, чем пару частей, это становится не приемлемым.
Exchange никогда не поддерживал “правильное” отображение сообщений с типом вложений /mixed в OWA или Outlook до настоящего времени.
Blended Messages
Начиная с Exchange 2007 Service Pack 3 Rollup 3 (E12SP3RU3) и Exchange 2010 Service Pack 1 Rollup 4 (E14SP1RU4) кумулятивные обновления включают изменения в том, как Exchange обрабатывает тело сообщения типа /mixed. Мы думаем, что в общем ваши пользователи получат удовольствие от меньшего искажения этих сообщений, но если я чему-то научился за 14 лет работы над Exchange, так это то, что “изменение == гнев”. Когда люди привыкают к чему-то, даже если это неправильно (или незавершенно), они ожидают именно такое поведение и опираются на него. Рассмотрим это справедливое предупреждение о появлении этого изменения, некоторые детали того, как оно работает, где оно работает, а где нет.
Мы добавили в Exchange поддержку объединения множественных частей сообщения в одно агрегированное тело сообщения. Суть в том, что части, на которые разорвано сообщение, должны отображаться объединенными в единое целое и читаться в OWA и Outlook. Однако в этом существуют ограничения.
Во-первых, прямо сейчас это будет работать только для сообщений созданных с помощью клиентов Apple iPod, iPad или Apple Mail. Это не случайно: мы разработали правила объединения частей сообщения, используя тестовую информацию от наших коллег из Apple, и в то время как мы хорошо обрабатываем такие сообщения, интернет широк и удивителен – любой может писать сообщения с вложениями типа multipart/mixed. В настоящее время это ограничено клиентами, которые мы хорошо протестировали, для которых имеем хорошие правила и хороший способ их идентификации.
Чтобы создать агрегированное тело сообщения, мы проверяем каждую часть MIME в разделе /mixed. Если часть MIME имеет параметр disposition, равный Attachment, то она отправляется в область вложений. Я не собираюсь спорить с почтовым клиентом, который указывает, что это вложение. Если часть тела сообщения имеет параметр disposition, равный inline (или параметр вообще не задан), и если она имеет тип plain text или html, мы добавляем ее к объединенному телу сообщения. Если часть тела сообщения – это картинка, которая может быть отображена inline, мы добавляем ссылку на нее в объединенное тело сообщения. Если часть тела сообщения не текст и не картинка, которую мы не можем отобразить inline, она идет в область вложений.
Если у вас есть приложение, которое используется для отправки сообщений с частями типа /mixed MIME, которые Exchange рассматривает как вложения, и вы отправляете их из платформы Apple, и вы не установили параметр content dispositio», и части являются текстом или картинкой (и вы установили параметр content type), то вам нужно добавить параметр Content-Disposition в те MIME части, которые вы хотите превратить во вложения, и установить его в значение Attachment. Если вы конечный пользователь, удивляющийся, почему сообщения с картинками или подписями не разбиты на части, то вам ничего не нужно делать.
Заключение
Сегодня мы рассмотрели различные структуры MIME, различные представления тел сообщений, расположений, типов и множество других вещей, но главный итог в том, что почта между клиентами Apple и клиентами Exchange будет обрабатываться лучше. Лучшее последствие не в том, что ваши пользователи будут звонить и говорить: «О! Я впечатлен тем, что сообщения, которые я получил от Джона с его Мака, больше не разбиты на куски». Лучшее последствие в том, что это просто работает. Никто не должен больше звонить, потому что вы не следите и не заботитесь о том, с какой платформы пришло сообщение и какого формата. Вы можете видеть свое письмо, подписи и да – ваших прикольных котов. Присоединяйтесь!
Эпилог: как получилась ошибка
Я уже прочитал (и ответил) на сообщения на форуме, которые касались новой проблемы, связанной с новым кодом. Вложения PDF от клиентов Mac, которые устанавливают расположение равным inline, не видимы в области вложений. Видимы в Outlook Web Access, да, но не в MAPI.
Так как же такое могло произойти на этой земле? И как мы пропустили этот баг? (“Осуществляете ли вы хоть какой-то контроль качества?” – как кто-то спросил меня). Ответ – да, мы это делаем. Но вместо пустых слов, давайте посмотрим на тот путь, который мы прошли до включения этого исправления в обновление, рассмотрим саму проблему, и то, как мы ее пропустили и что предпринимаем по ее поводу.
Это исправление берет начало с телефонной конференции между мной, несколькими моими товарищами по команде и нашими коллегами из Apple, в которой кто-то спросил: “Хорошо, ребята, вы можете сделать что-то для того, чтобы действительно поддерживать этот вид тела сообщения?” Я потратил несколько последующих дней, исследуя, что должно было бы быть сделано, чтобы построить единое тело сообщения из частей, и в конечном итоге пришел к выводу, что это возможно. После этого мы начали обсуждение: «Почему сейчас?» и «Что именно?» Это обсуждение заняло некоторое время. Основной проблемой было то, что создание нового типа тела сообщения требовало больших инвестиций в тестирование. В конце концов, мы пришли к выводу, что мы могли бы и должны были бы сделать это.
И мы сделали. Мы написали код, который поддерживает этот тип тела сообщения, мы написали код, который проверяет его. Мы имеем громадное число тестов, чтобы проверять различные типы и форматы тел сообщений. У нас были новые тесты для проверки новых тел сообщений. Вскоре код проверки превысил код самого исправления. Таким образом исправление было готово, код протестирован, но мы все еще не были готовы включить его. Вместо этого мы избрали более осторожный подход. Исправление было выпущено как промежуточное обновление, и оно строго контролировалось, т.к. мы хотели, чтобы оно дошло до заказчиков, которые будут использовать его ежедневно. Месяц спустя мы позволили установить исправление в четыре раза большему числу заказчиков, что в конечном итоге составило 12 заказчиков еще на три месяца. После трех месяцев испытаний с положительными результатами, мы решили включить это обновление в кумулятивное обновление (это должно было быть RU2, но получилось в RU3).
Но есть проблема. Видите ли, Exchange 2007 и 2010 не уделяли много внимания расположению содержимого, так что на протяжении многих лет параметр inline был отличным способом гарантировать по сути невидимость вложения (вложение inline имело скрытое свойство, установленное в true, т.к. оно отображалось в теле сообщения). И проверочный код пропустил этот случай – вложение inline, которое не может быть отображено Exchange, но входит в состав сообщения, которое содержит множество частей, которые могут быть объединены в единое тело сообщения. К сожалению, ни наши тесты, ни полевые испытания не обнаружили это.
Баг заключается в том, что при обработке этих сообщений мы отрабатываем параметр «расположение» для вложения в случае, когда мы не должны это делать. Любое вложение, которое не может отображаться внутри текста, не должно становиться частью объединенного тела сообщения. Мы знаем два типа вложений – TIFF и PDF, которые могут отображаться внутри текста на клиентах Mac, но не на клиентах Windows. Исправление для этих двух типов также исправляет любые другие типы, которые этот клиент может отображать внутри текста, а мы не можем.
Как мы это пропустили? Мы пересмотрели наш проверочный код, проверочные данные и сказали: «Он содержит PDF-ы и проверяет статус области вложений» Он и вправду делает это (в том числе для TIFF-ов). Он также даже не пытается создать PDF-вложение и отобразить его внутри текста. Вот этот пропущенный случай, и я определенно хотел бы, чтоб он был найден до того, как оказал влияние на любого заказчика.
Чтобы исправить это, мы выпустили промежуточное обновление, и мы включим его основной код, чтобы предотвратить будущие инциденты, подобные этому. Со временем я полагаю, мы будем расширять список почтовых клиентов, для которых мы создаем объединенное тело сообщения. Я думаю, этот опыт показал, что мы должны огранить этот список и расширять его тогда, когда можем обеспечить надежное тестирование. Я по-прежнему убежден, что улучшение взаимодействия между клиентами Mac и Exchange – это хорошая идея.
Вот что мы имеем: проблема, исправление, проблема с этим исправлением, исправление проблемы с исправлением.
Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтакс письма RFC 822 (то есть, иметь заголовок, пустую строку и тело), но должна иметь открывающую и закрывающую границы.
Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть. начтинающиеся с "Content-". Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться "X-" поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.
ЗАМЕЧАНИЕ: Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Шлюз между почтой Internet и X.400, например, должен иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содежащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь "Content-Type: message" и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка "Content-Type: image". Схожесть синтаксиса обеспечивает легкость конверсии от письма к части письма, но различие между ними должно быть усвоено производителями ПО.
Граница части письма не должна появляться внутри самой части письма.
Все существующие и будущие подтипы типа "multipart" должны иметь идентичный синтаксис. Они могут различаться своей семантикой. Это требование гарантирует, что совместимые пользовательские агенты смогут по крайней мере распознать и разделить части многочастного письма, даже имеющего неизвестный им подтип.
Как упомянуто в определении поля Content-Transfer-Encoding, использование других значений кроме "7bit", "8bit" или "binary" запрещено для типа "multipart". Почтовые шлюзы и другие почтовые агенты часто вносят изменения в заголовки верхнего уровня. В частности, они могут добавлять, убирать, переупорядочивать определенные поля. Такие изменения запрещены для заголовков частей письма, находяшихся внутри тела типа "multipart".
Multipart: общий синтаксис
Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" (десятичный код 45) и значения параметра ‘boundary’ из поля заголовка Content-Type.
ЗАМЕЧАНИЕ: Два символа "-" используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом "-", так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа ‘multipart’.
ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре ‘boundary’ заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа ‘multipart’ может выглядеть следующим образом:
Но в следующем примере содержится ошибка:
(из-за двоеточия), которая может быть исправлена следующим образом:
Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью:
Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных. Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.
Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.
Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец:
Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.
ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME’овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.
ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.
В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет:
Часть письма, в свою очередь, также может иметь тип ‘multipart’, то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.
Использование типа ‘multipart’ в одночастном письме может быть полезно в некоторых контекстах и не запрещено.
Единственным обязательным параметром для типа ‘multipart’ является параметр ‘boundary’, состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части).
Общий вид многочастного тела — следующий:
ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding. Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.
Основной подтип "multipart/mixed"
Это основной подтип для типа ‘multipart’, он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу ‘mixed’.
Подтип "multipart/alternative"
Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.
Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.
Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате:
В этом примере пользователь, чья система понимает этот гипотетический формат, увидят именно эту версию, в то время как остальные будут видеть размеченный либо простой текст в зависимости от возможностей их системы.
Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип ‘multipart’ и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.
ЗАМЕЧАНИЕ: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME’овским почтовым программам отобразить в первую очередь наиболее понятный вариант.
ЗАМЕЧАНИЕ ПО СЕМАНТИКЕ ПОЛЯ ‘CONTENT-ID’ В ПИСЬМЕ MULTIPART/ALTERNATIVE: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа "application/external- body" определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.
Подтип "multipart/digest"
Этот подтип идентичен подтипу ‘multipart/mixed’, но имеет другую семантику. Например, для ‘digest’ значением по умолчанию является не "text/plane", а "message/rfc822".
В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом:
Подтип "multipart/parallel"
Отличие этого подтипа от "multipart/mixed", в частности, состоит в том, что порядок расположения частей письма не принципиален.
Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями. Однако, почтовый агент отправителя должен сознавать, что программа получателя может не иметь подобных возможностей и отобразить все части письма последовательно.
Другие подтипы типа "multipart"
В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа ‘multipart’ аналогично "multipart/mixed".
Формальный синтаксис поля Content-Type для данных типа "multipart":
Полный пример Multipart-письма
Данный пример иллюстрирует письмо из пяти частей: две — простой текст, одна — вложенное multipart-письмо, одна — размеченный текст и одна — вложенное письмо, содержащее текст в не-US-ASCII языковой кодировке. Третья часть (вложенное multipart-письмо) состоит из двух частей, требующих параллельного представления пользователю, — графическое изображение и звуковой фрагмент.
A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the encapsulation is plain US-ASCII text. The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields are generally to be ignored in body parts. Although they should generally be retained in mail processing, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but should not be depended on. "X-" fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways.
The distinction between an RFC 822 message and a body part is subtle, but important. A gateway between Internet and X.400 mail, for example, must be able to tell the difference between a body part that contains an image and a body part that contains an encapsulated message, the body of which is an image. In order to represent the latter, the body part must have "Content-Type: message", and its body (after the blank line) must be the encapsulated message, with its own "Content-Type: image" header field. The use of similar syntax facilitates the conversion of messages to body parts, and vice versa, but the distinction between the two must be understood by implementors. (For the special case in which all parts actually are messages, a "digest" subtype is also defined.)
As stated previously, each body part is preceded by an encapsulation boundary. The encapsulation boundary MUST NOT appear inside any of the encapsulated parts. Thus, it is crucial that the composing agent be able to choose and specify the unique boundary that will separate the parts.
All present and future subtypes of the "multipart" type must use an identical syntax. Subtypes may differ in their semantics, and may impose additional restrictions on syntax, but must conform to the required syntax for the multipart type. This requirement ensures that all conformant user agents will at least be able to recognize and separate the parts of any multipart entity, even of an unrecognized subtype.
As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always 7-bit ASCII in any case, and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.
Mail gateways, relays, and other mail handling agents are commonly known to alter the top-level header of an RFC 822 message. In particular, they frequently add, remove, or reorder header fields. Such alterations are explicitly forbidden for the body part headers embedded in the bodies of messages of type "multipart."
The Content-Type field for multipart entities requires one parameter, "boundary", which is used to specify the encapsulation boundary. The encapsulation boundary is defined as a line consisting entirely of two hyphen characters ("-", decimal code 45) followed by the boundary parameter value from the Content-Type header field.
NOTE: The hyphens are for rough compatibility with the earlier RFC 934 method of message encapsulation, and for ease of searching for the boundaries in some implementations. However, it should be noted that multipart messages are NOT completely compatible with RFC 934 encapsulations; in particular, they do not obey RFC 934 quoting conventions for embedded lines that begin with hyphens. This mechanism was chosen over the RFC 934 mechanism because the latter causes lines to grow with each level of quoting. The combination of this growth with the fact that SMTP implementations sometimes wrap long lines made the RFC 934 mechanism unsuitable for use in the event that deeply-nested multipart structuring is ever desired.
Thus, a typical multipart Content-Type header field might look like this: This indicates that the entity consists of several parts, each itself with a structure that is syntactically identical to an RFC 822 message, except that the header area might be completely empty, and that the parts are each preceded by the line Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).
NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.
The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line — that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.
Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.
The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line: There appears to be room for additional information prior to the first encapsulation boundary and following the final boundary. These areas should generally be left blank, and implementations should ignore anything that appears before the first boundary or after the last one.
NOTE: These "preamble" and "epilogue" areas are not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways.
NOTE: Because encapsulation boundaries must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary. The boundary in the example above could have been the result of an algorithm designed to produce boundaries with a very low probability of already existing in the data to be encapsulated without having to prescan the data. Alternate algorithms might result in more ‘readable’ boundaries for a recipient with an old user agent, but would require more attention to the possibility that the boundary might appear in the encapsulated part. The simplest boundary possible is something like "—", with a closing boundary of "——".
As a very simple example, the following multipart message has two parts, both of them plain text, one of them explicitly typed and one of them implicitly typed: The use of a Content-Type of multipart in a body part within another multipart entity is explicitly allowed. In such cases, for obvious reasons, care must be taken to ensure that each nested multipart entity must use a different boundary delimiter. See Appendix C for an example of nested multipart entities.
The use of the multipart Content-Type with only a single body part may be useful in certain contexts, and is explicitly permitted.
The only mandatory parameter for the multipart Content-Type is the boundary parameter, which consists of 1 to 70 characters from a set of characters known to be very robust through email gateways, and NOT ending with white space. (If a boundary appears to end with white space, the white space must be presumed to have been added by a gateway, and should be deleted.) It is formally specified by the following BNF: Overall, the body of a multipart entity may be specified as follows: NOTE: Conspicuously missing from the multipart type is a notion of structured, related body parts. In general, it seems premature to try to standardize interpart structure yet. It is recommended that those wishing to provide a more structured or integrated multipart messaging facility should define a subtype of multipart that is syntactically identical, but that always expects the inclusion of a distinguished part that can be used to specify the structure and integration of the other parts, probably referring to them by their Content-ID field. If this approach is used, other implementations will not recognize the new subtype, but will treat it as the primary subtype (multipart/mixed) and will thus be able to show the user the parts that are recognized.
7.2.2 The Multipart/mixed (primary) subtype
7.2.3 The Multipart/alternative subtype
In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. Receiving user agents should pick and display the last format they are capable of displaying. In the case where one of the alternatives is itself of type "multipart" and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both.
NOTE: From an implementor’s perspective, it might seem more sensible to reverse this ordering, and have the plainest alternative last. However, placing the plainest alternative first is the friendliest possible option when mutlipart/alternative entities are viewed using a non-MIME- compliant mail reader. While this approach does impose some burden on compliant mail readers, interoperability with older mail readers was deemed to be more important in this case.
It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if mail includes both a nicely-formatted image version and an easily-edited text version. What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should explicitly be given the choice.
7.2.4 The Multipart/digest subtype
A digest in this format might, then, look something like this:
