Multipart Content-Type headers identify multipart messages. They require that a subtype and other elements be included in the header.
The multipart/alternative content type is used when the same information is presented in different body parts in different forms. The body parts are ordered by increasing complexity. For example, a message that consists of a heavily formatted MicrosoftВ® Word 97 document might also be presented in Word 6.0 format, rich text format, and a plain text format. In this case the plain text would be presented as the first alternative body part. The rich text version would follow, then the Word 6.0, then the most complex, Word 97. Placing the plain text version first is the friendliest scheme for user agents (UAs) that are not compliant with Multipurpose Internet Mail Extensions (MIME), because they will see the recognizable version first. MIME-compliant UAs should present the most complex version that they can recognize or give the user a choice of which version to view. Content-ID values should be different for each part where there are different levels of complexity between parts. The content-ID of each part should be different from the content-ID of the overall multipart/alternative. That is, one content-ID value will refer to the multipart/alternative entity, while one or more other content-ID values will refer to the parts inside it.
The multipart/byteranges content type is defined as a part of the HTTP message protocol. It includes two or more parts, each with its own Content-Type and Content-Range fields. The parts are separated using a MIME boundary parameter. This allows for binary as well as 7-bit and 8-bit files to be sent as multiple parts with the lengths of the parts being specified in the header of each part. Note that while HTTP makes provisions for using MIME for HTTP documents, HTTP is not strictly MIME-compliant.
The multipart/digest content type is used to send collections of plain-text messages. This is accomplished in the same way as the multipart/mixed content-type, but each body part is expected to be of content-type: message/RFC 822.
The multipart/form-data content type is intended to allow information providers to express file upload requests uniformly, and to provide a MIME-compatible representation for file upload responses.
The multipart/mixed content type is used when the body parts are independent and need to be bundled in a particular order. When a UA does not recognize a multipart subtype, it will treat the message as multipart/mixed.
The purpose of the multipart/parallel content type is to display all of the parts simultaneously on hardware and software that can do so. For instance, an image file can be displayed while a sound file is playing.
The multipart/related content type is used for compound documents (that is, messages in which the separate body parts are intended to work together to provide the full meaning of the message). Additionally, multipart/related can be used to provide links to content not contained within the message. Multipart/related can be used for compound documents where the object is built progressively from pieces, starting with the "root" body part as specified in the start parameter. If the start parameter is not specified, then the first body part is considered the starting point or "root" body part. Multipart/related requires a type parameter. The type parameter specifies the content type of the first or "root" part. Multipart/related processing takes precedence over content-disposition. Many MIME user agents do not recognize multipart/related and treat these messages as multipart/mixed. To allow for this, some UAs will include the technically unnecessary Content-Disposition header in multipart/related body parts. Content-Location and Content-Base headers are defined to resolve URL references to other body parts. Both headers are valid in any message or body part. They are valid for the content heading or message heading where they occur and for its content. The Content-Location and Content-Base headers apply to headers and body parts where they occur and do not have meaning in multipart headings. The Content-Base header gives a base for relative URIs occurring in other heading fields and in HTML documents that do not have any BASE element in its HTML code. Its value must be an absolute Uniform Resource Identifier (URI). The Content-Location header contains a URL that specifies the body of that body part. The URL may be relative to a URL specified in a Content-Base header. The following example shows how these headers are used:
The multipart/report content type was defined for returning delivery status reports, with optional included messages. It is finding wider use in machine-to-machine communication. The multipart/report is used for Message Disposition Notification.
multipart/signed, multipart/encrypted [RFC1847]
The multipart/signed and multipart/encrypted content types provide a security framework for MIME parts. These headers do not define security protocols, but exist to carry the protected documents. Each multipart/signed or multipart/encrypted body part is carried as two related parts, one with the control information describing the protocol and one with the protected document. The multipart/signed content type specifies how to support authentication and integrity services using digital signature. The control information is carried in the second of the two required body parts. The multipart/encrypted content type specifies how to support confidentiality using encryption. The control information is carried in the first of the two required body parts.
Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтакс письма 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-письмо) состоит из двух частей, требующих параллельного представления пользователю, — графическое изображение и звуковой фрагмент.
Привет, администраторы 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 – это хорошая идея.
Вот что мы имеем: проблема, исправление, проблема с этим исправлением, исправление проблемы с исправлением.
