Почтовые сообщения с типом вложений Multipart/Mixed

项目
06/06/2011

Привет, администраторы 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 – это хорошая идея.

Вот что мы имеем: проблема, исправление, проблема с этим исправлением, исправление проблемы с исправлением.

Джейсон Нельсон

Перевод: Илья Сазонов, MVP

Пояснение переводчика: «Область вложений» https://msdn.microsoft.com/ru-ru/library/aa126081(v=exchg.65).aspx

Comments

Anonymous
January 01, 2003
Пожалуйста, уточните, какая именно проблема: первоначальная (отображение смешанных сообщений) или недавняя (отображение PDF)?
Anonymous
January 01, 2003
установлен Exchange 2007 SP3 Update Rollup 5. описанная проблема все равно наблюдается при отправке сообщений с вложениями с iPad. поможет ли установка Update Rollup 6 ?

通过