MIME (Multipurpose Internet Mail Extensions)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 10:32, 26 мая 2017.
MIME
Protocol stack
Purpose Передача различных типов данных по электронной почте
Developer(s) IETF (Internet Engineering Task Force)
Introduced 1991; 29 years ago (1991)
OSI layer Уровень представления
RFC(s) RFC 1341, RFC 1342, RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2049, RFC 2045, RFC 1521, RFC 1522, RFC 2183, RFC 2231, RFC 6152, RFC 3030, RFC 2822, RFC 2387, RFC 2388, RFC 6522, RFC 1847, RFC 3156, RFC 7578, RFC 2616

MIME (англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — стандарт, описывающий передачу различных типов данных по электронной почте (позволяющий вставлять изображения, звуки и текст в сообщение), который впервые был предложен Bell Communications в 1991 году. Также является спецификацией для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по Интернету. Первоначально он был определен RFC 1341 и RFC 1342 в июне 1992 года. Используя заголовки, MIME описывает тип содержимого сообщения и используемую кодировку. [Источник 1]

MIME добавляет следующие функции в службу электронной почты:

  • Возможность отправлять несколько вложений одним сообщением;
  • Длина сообщений не ограничена;
  • Использование наборов символов, отличных от кода ASCII;
  • Использование разнообразного текста (макеты, шрифты, цвета и т. д.)
  • Двоичные вложения (исполняемые файлы, изображения, аудио- или видеофайлы и т. д.), которые при необходимости могут быть разделены. [Источник 2]

MIME указан в шести связанных RFC-стандартах: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 и RFC 2049 с интеграцией с электронной почтой SMTP, подробно описанной в RFC 1521 и RFC 1522.

Хотя MIME был разработан в основном для SMTP, типы контента, определенные стандартами MIME, также важны в протоколах связи вне электронной почты, таких как HTTP для World Wide Web. Серверы вставляют заголовок MIME в начале любой веб-передачи. Клиенты используют этот тип контента или заголовок медиа-типа, чтобы выбрать подходящее приложение-просмотрщик для типа данных, которые указаны в заголовке. Некоторые из этих просмотрщиков встроены в веб-клиент или браузер (например, почти все браузеры оснащены GIF- и JPEG-изображениями, а также возможностью обработки HTML-файлов). [Источник 3].

Заголовки MIME

MIME-Version

Рис.1.

Наличие этого заголовка указывает, что сообщение имеет формат MIME. Обычно это значение «1.0», поэтому этот заголовок отображается так:

MIME-Version: 1.0

По словам создателя MIME Натаниэля Боренштейна, целью было разрешить MIME изменяться до версии 2.0 и так далее, но это решение привело к противоположному результату. Стало почти невозможно создать новую версию стандарта. Со слов Боренштейна они не определили как будут обрабатывать будущую версию MIME.

Content-Type

Этот заголовок указывает тип мультимедийного содержимого сообщения, состоящего из типа и подтипа, например: Content-Type: text/plain Благодаря использованию типа multipart, MIME даёт возможность почтовым сообщениям иметь части, расположенные в древовидной структуре, где листовые узлы являются любым многокомпонентным типом содержимого, а не листовые узлы являются любым типом из множества многокомпонентных типов. Этот механизм поддерживает:

  • Простые текстовые сообщения с использованием текста или простой части (значение по умолчанию для «Content-Type:»);
  • Текст и вложения (многокомпонентный / смешанный с текстом / простой частью и другими не текстовыми частями). Сообщение MIME, включающее прикрепленный файл, обычно указывает исходное имя файла с заголовком «Content-disposition:», поэтому тип файла указывается как по типу содержимого MIME, так и по обычному (для ОС) расширению имени файла;
  • Ответ с оригиналом прилагается (многокомпонентный / объединённый с текстом / простая часть и оригинальное сообщение как часть message / rfc822);
  • Альтернативный контент, такой как сообщение, отправленное как в обычном текстовом формате, так и в другом формате, таком как HTML (многокомпонентные / альтернативные с тем же содержимым, в текстовых / обычных и текстовых / html-формах);
  • Изображения, аудио, видео и приложения (например, изображения / jpeg, аудио / mp3, видео / mp4 и приложения / msword и т. д.);
  • и др.

Content-Disposition

Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затрагивали проблему стилей презентации. Поле заголовка Content-Disposition было добавлено в RFC 2183 для определения стиля представления. Часть MIME может иметь:

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

В дополнение к стилю представления данный заголовок также предоставляет поля для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения. Следующий пример взят из RFC 2183, где определяется заголовок:

  Content-Disposition: attachment; filename=genome.jpeg;
  modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

Имя файла может быть закодировано в соответствии с RFC 2231.

По состоянию на 2010 год, большинство пользователей почтовых программ не полностью соблюдают это предписание. Широко используемый почтовый клиент Mozilla Thunderbird сам принимает решения о том, какие части MIME должны отображаться автоматически, игнорируя заголовки содержимого в сообщениях. До версии 3 Thunderbird также отправлял новые составленные сообщения с встроенным местоположением контента для всех частей MIME. Большинство пользователей не знают, как установить местоположение контента для вложений. Многие почтовые пользовательские агенты также отправляют сообщения с именем файлам в строке с именем параметра в заголовке content-type вместо параметра имени файла заголовка content-disposition. Эта практика не приветствуется - имя файла должно быть указано либо через параметр имени файла, либо через имя файла и параметры имени.

В HTTP заголовок Content-Disposition: attachment используется для указания представления клиенту тела ответа в виде загружаемого файла. Обычно при получении такого ответа веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его как страницу в окне браузера с параметром имени файла, предлагающим имя файла по умолчанию (это полезно для динамически сгенерированного содержимого, при котором извлечение имени файла из URL-адреса может быть бессмысленным или сложным для пользователя).

Content-Transfer-Encoding

В июне 1992 года MIME определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Кодирование передачи содержимого (Content-Transfer-Encoding): заголовок MIME имеет двустороннее значение:

  • Он указывает, использовалась ли схема кодирования из двоичного кода в текст поверх исходной кодировки, как указано в заголовке Content-Type:
  1. Если такой способ кодирования двоичного кода в текст использовался, он указывает, какой именно.
  2. Если нет, он предоставляет описательную метку для формата содержимого, в отношении наличия 8-битного или двоичного содержимого.

RFC и список кодов передачи IANA определяют значения, указанные ниже, которые не чувствительны к регистру. Стоит отметить, что '7bit', '8bit' и 'binary' означают, что кодировка от двоичного кода к тексту не использовалась поверх исходной кодировки. В этих случаях заголовок фактически является избыточным для декодирования тела сообщения, но он может быть полезен в качестве индикатора того, какой тип объекта отправляется. Значения 'quoted-printable' и 'base64' указывают клиенту электронной почты, что используется схема кодирования двоичного текста в текст, и для того, чтобы сообщение могло быть прочитано с его оригинальной кодировкой (например, UTF-8), необходимо соответствующее начальное декодирование.

  • Подходит для использования с обычным SMTP:
  1. 7bit - до 998 октетов на строку кодового диапазона 1..127 с CR и LF (коды 13 и 10 соответственно) разрешено появляться только как часть конца строки CRLF. Это значение по умолчанию.
  2. Quoted-printable - используется для кодирования произвольных октетных последовательностей в форму, которая удовлетворяет правилам 7bit. Был разработан, чтобы быть понятным и эффективным в использовании для простого пользователя. Используется для текстовых данных, состоящих в основном из символов US-ASCII, но также содержащих небольшую часть байтов со значениями вне этого диапазона.
  3. Base64 - используется для кодирования произвольных октетных последовательностей в форму, которая удовлетворяет правилам 7bit. Предназначен для работы с не текстовыми 8-битными и двоичными данными. Иногда используется для текстовых данных, которые часто используют символы, отличные от US-ASCII.
  • Подходит для использования с SMTP-серверами, поддерживающими расширение 8BITMIME SMTP (RFC 6152):
  1. 8bit - до 998 октетов на строку с CR и LF (коды 13 и 10 соответственно) разрешено появляться только как часть конца строки CRLF.
  • Подходит для использования с серверами SMTP, которые поддерживают расширение BINARYMIME SMTP (RFC 3030):
  1. Binary - любая последовательность октетов.

Не определено кодирование, которое явно предназначено для отправки произвольных двоичных данных через SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда полезно использовать base64 или quoted-printable (с их ассоциированной неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с MIME-приложениями или MTOM.

Закодированные слова

Начиная с RFC 2822, соответствующие заголовки и значения заголовка сообщения должны быть символами ASCII. Значения, которые содержат данные, отличные от ASCII, должны использовать синтаксис закодированного слова MIME (RFC 2047) вместо строковой буквы. Этот синтаксис использует строку символов ASCII, указывающую как исходную кодировку символов, так и кодировку передачи содержимого, используемую для отображения байтов кодировки в символы ASCII. Например, "=?кодировка?кодирование?закодированный текст?=".

  • Кодирование может быть любым набором символов, зарегистрированным в IANA. Обычно это будет та же самая кодировка, что и для тела сообщения.
  • Кодирование может быть либо «Q», обозначающим Q-кодирование, которое аналогично кодировке quoted-printable, либо «B», обозначающее кодирование base64.
  • Зашифрованный текст - это текст, закодированный в формате Q или base64.
  • Длина закодированного слова не должна превышать 75 символов, включая кодировку, закодированный текст и разделители. Если хочется закодировать больше текста, чем можно поместить в закодированное слово из 75 символов, можно использовать несколько закодированных слов (разделенных CRLF SPACE).

Различия между кодированием Quoted-printable и Q-кодированием

Коды ASCII для вопросительного знака («?») и знака равенства («=») могут быть представлены не напрямую, поскольку они используются для ограничения кодированного слова. Код ASCII для пространства не может быть представлен напрямую, потому что это может привести к тому, что более старые парсеры будут беспорядочно делить закодированное слово. Чтобы сделать кодировку меньше и чтобы её было проще читать, используют символ подчёркивания для представления кода ASCII для пространства, создающего побочный эффект, который не может быть представлено напрямую. Использование закодированных слов в некоторых частях заголовков накладывает дополнительные ограничения на то, какие символы могут быть представлены непосредственно.

Например, Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?= Это можно перевести как: "Subject:¡Hola, señor!"

Формат кодированного слова не используется для имен заголовков (например, Subject). Эти имена заголовков всегда пишутся на английском языке в исходном сообщении. При просмотре сообщения с почтовым клиентом, отличным от английского, имена заголовков обычно переводится клиентом на нужный язык.

Многокомпонентные сообщения

Многокомпонентное сообщение MIME содержит границу в заголовке «Content-Type:»; Эта граница, которая не должна встречаться ни в одной из частей, помещается между частями, а в начале и в конце тела сообщения следующим образом:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

Это многокомпонентное сообщение в формате MIME.
--frontier
Content-Type: text/plain

Тело сообщения.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

Каждая часть состоит из собственного заголовка содержимого (ноль или более полей Content-header) и тела. Многостраничный контент может быть вложенным. Кодирование передачи содержимого многокомпонентного типа всегда должно быть «7bit», «8bit» или «binary», чтобы избежать осложнений, которые могли бы возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет кодировки. Не-ASCII-символы в заголовках элементов обрабатываются системой Encoded-Word, а в телах деталей могут быть заданы кодировки, если это необходимо для их типа содержимого.

Примечания:

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

Подтипы многокомпонентного сообщения

Стандарт MIME определяет различные подтипы multipart-сообщений, которые определяют характер частей сообщения и их взаимосвязь друг с другом. Подтип указан в заголовке «Content-Type» для всего сообщения. Например, для многокомпонентного MIME-сообщения, использующего подтип дайджест, его Content-Type будет установлен как «multipart/digest». RFC первоначально определил 4 подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный тип и тип дайджест. Другие подтипы являются необязательными. Приложения должны обрабатывать не распознанные подтипы как «multipart/mixed». Дополнительные подтипы, такие как подпись и данные формы, с тех пор были отдельно определены в других документах RFC. Ниже приведен список наиболее часто используемых подтипов. Он не является исчерпывающим.

Смешанный

Multipart/mixed используется для отправки файлов с различными заголовками Content-Type в очереди (или вложениями). При отправке изображений или других легко читаемых файлов большинство почтовых клиентов будут отображать их в строке (если иное не указано в заголовке «Content-disposition»). В противном случае он будет предлагать их как вложения. Тип контента по умолчанию для каждой части - «text/plain». Определено в RFC 2046, раздел 5.1.3.

Дайджест

Multipart/digest - это простой способ отправки нескольких текстовых сообщений. По умолчанию для каждого компонента используется тип содержимого message/rfc822. Определено в RFC 2046, раздел 5.1.5.

Сообщение

Message/rfc822 содержит сообщение электронной почты, включая любые заголовки. Это используется для дайджестов, а также для пересылки электронной почты. Определено в RFC 2046.

Альтернативный

Подтип multipart/alternative указывает, что каждая часть является «альтернативной» версией того же (или подобного) контента, каждый в другом формате, обозначенном его заголовком «Content-Type». Порядок частей является важным. RFC1341 утверждает, что, в общем случае, пользовательские агенты, создающие multipart/alternative объекты, должны размещать части в порядке возрастания предпочтений, то есть с предпочтительным последним форматом. Затем системы могут выбрать «лучшее» представление, которое они способны обрабатывать. Это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы. Поскольку клиент вряд ли захочет отправить версию, которая менее верна, чем версия простого текста, эта структура сначала поместит версию простого текста (если она присутствует). Это облегчает жизнь пользователям клиентов, которые не понимают многокомпонентных сообщений. Чаще всего multipart/alternative используется для электронной почты с двумя частями, одним простым текстом (text/plain) и одним HTML (text/html). Текстовая часть обеспечивает обратную совместимость, в то время как часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю вариант использования обычного текста поверх HTML. Это пример того, как локальные факторы могут влиять на то, как приложение выбирает «лучшую» часть отображаемого сообщения. Хотя предполагается, что каждая часть сообщения представляет один и тот же контент, стандарт не требует, чтобы это применялось каким-либо образом. В свое время фильтры защиты от нежелательной почты рассматривали только текстовую/обычную часть сообщения (text/plain), поскольку ее легче анализировать, чем часть text/html. Но в конечном итоге спамеры воспользовались этим, создав сообщения с безобидным текстом/простой частью и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге подхватило этот трюк, штрафуя сообщения с очень разным текстом в multipart/alternative сообщении. Определено в RFC 2046, раздел 5.1.4.

Связанный

Компонент multipart/related используется, чтобы указать, что каждая часть сообщения является компонентом одного целого. Это делается для составных объектов, состоящих из нескольких взаимосвязанных компонентов - надлежащее отображение не может быть достигнуто путем индивидуального отображения составных частей. Сообщение состоит из корневой части (по умолчанию первой), которая ссылается на другие части в очереди, которая, в свою очередь, может ссылаться на другие части. Части сообщения обычно ссылаются на заголовок части «Content-ID». Синтаксис ссылки не указан и вместо этого продиктован кодировкой или протоколом, используемым в части. Одним из распространенных вариантов использования этого подтипа является отправка веб-страницы с изображениями в одном сообщении. Корневая часть будет содержать HTML-документ и использовать теги изображений для ссылки на изображения, хранящиеся в последних частях. Определено в RFC 2387.

Отчёт

Multipart / report - это тип сообщения, который содержит данные, отформатированные для чтения почтовым сервером. Он разделяется между текстом/обычным (или другим содержимым, легко читаемым) и сообщением/статусом доставки, который содержит данные, отформатированные для почтового сервера для чтения. Определено в RFC 6522.

Подписанный

Multipart/signed используется для присоединения цифровой подписи к сообщению. Он имеет ровно две части тела: часть тела и подпись. Вся часть тела, включая заголовки mime, используется для создания части подписи. Возможны многие типы сигнатур, например «application/pgp-signature» (RFC 3156) и «application/pkcs7-signature» (S/MIME). Определено в RFC 1847, Раздел 2.1.

Зашифрованные

Сообщение multipar /encrypted состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для дешифрования второй части приложения/октетного потока. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются по отдельным типам контента для элемента управления. Наиболее распространенными типами являются «application/pgp-encrypted» (RFC 3156) и «application/pkcs7-mime» (S/MIME). Определено в RFC 1847, раздел 2.2.

Form-Data

Как следует из названия, multipart/form-data используется для выражения значений, представленных через форму. Первоначально определенный как часть HTML 4.0 наиболее часто используется для отправки файлов через HTTP. Определено в RFC 7578 (ранее RFC 2388).

Смешанно-заменяемый

Тип содержимого multipart/x-mixed-replace был разработан как часть технологии, имитирующей технологию push и потоки через HTTP. Все части сообщения со смешанной заменой имеют одинаковое смысловое значение. Тем не менее, каждая часть аннулирует - «заменяет» - предыдущие части, как только они получены полностью. Клиенты должны обрабатывать отдельные части сразу после их прибытия и не должны дожидаться завершения всего сообщения. Первоначально разработанная Netscape, все еще поддерживается Mozilla, Firefox, Chrome, Safari и Opera, но традиционно игнорируется Microsoft. Он широко используется в IP-камерах в качестве типа MIME для потоков MJPEG.

Byteranges

Параметр multipart/byterange используется для представления несмежных диапазонов байтов одного сообщения. Он используется HTTP, когда сервер возвращает несколько байтовых диапазонов и определен в RFC 2616.

Тест Марка Криспина

Марк Криспин, автор протокола IMAP, написал тест для проверки корректности обработки MIME. Тест представляет собой письмо в формате mbox с таким содержанием: "Это сумасшедшее письмо! В нём около 30 вложенных друг в друга частей. Очень хороший тест". [Источник 4]

См. также

  1. 8BITMIME
  2. Письмо от Марка Криспина с описанием теста (архив)

Источники

  1. Multipurpose Internet Mail Extensions (MIME) // technopedia. URL:https://www.techopedia.com/definition/1693/multipurpose-internet-mail-extensions-mime (дата обращения: 20.05.2017).
  2. MIME (Multipurpose Internet Mail Extensions) // ccm.net. URL:http://ccm.net/contents/120-mime-multipurpose-internet-mail-extensions (дата обращения: 20.05.2017).
  3. MIME // Wikipedia. [2017—2017]. Дата обновления:16.05.2017. URL: https://en.wikipedia.org/wiki/MIME#External_links (дата обращения: 20.05.2017).
  4. MIME // Википедия. [2017—2017]. Дата обновления: 14.07.2016. URL: http://ru.wikipedia.org/?oldid=79569169 (дата обращения: 24.05.2017).