MIME-формат: структура email-сообщений, типы и кодирование

MIME (Multipurpose Internet Mail Extensions) - набор стандартов, которые расширяют базовый формат электронной почты. Без MIME email мог бы содержать только 7-битный ASCII-текст: ни вложений, ни HTML-вёрстки, ни кириллицы, ни изображений. MIME определён в RFC 2045-2049 (1996) и с тех пор является фундаментальной частью каждого email-сообщения.

Предыстория: ограничения RFC 822

Оригинальный формат email (RFC 822, 1982) допускал в теле сообщения только символы US-ASCII с кодами 0-127. Строки ограничивались 1000 символами. Этого хватало для английского текста в академической среде, но к началу 1990-х стало очевидно, что нужны файлы, языки за пределами латиницы и хоть какое-то форматирование.

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

Заголовки MIME

MIME добавляет к письму несколько заголовков, определяющих тип и структуру содержимого:

• MIME-Version: 1.0 - обязательный маркер. Сообщает получающей стороне, что сообщение использует стандарт MIME. Значение не менялось с 1996 года.
• Content-Type - тип содержимого тела (или отдельной части сообщения). Формат: тип/подтип; параметры. Например, text/html; charset=utf-8.
• Content-Transfer-Encoding - способ кодирования тела для передачи через 7-битный транспорт: base64, quoted-printable, 7bit, 8bit, binary.
• Content-Disposition - способ отображения: inline (встроено в тело) или attachment (вложение, предлагается скачать). Может содержать параметр filename.
• Content-ID - уникальный идентификатор части сообщения. Используется для ссылок на inline-изображения из HTML через схему cid:.

Content-Type: основные типы

• text/plain - обычный текст без форматирования. Параметр charset указывает кодировку (utf-8, iso-8859-1, windows-1251).
• text/html - HTML-содержимое. Каждое маркетинговое письмо с вёрсткой, кнопками и стилями использует этот тип.
• multipart/alternative - несколько альтернативных версий одного содержимого. Типичный пример: text/plain + text/html. Клиент выбирает версию, которую умеет отображать.
• multipart/mixed - тело письма плюс вложения. Каждая часть содержит отдельный объект: текст, файл, изображение.
• multipart/related - HTML с inline-ресурсами. Изображения встроены в письмо и ссылаются из HTML через Content-ID (cid:logo@example).
• application/pdf, image/png, application/octet-stream - конкретные типы вложений. Реестр типов ведётся IANA и содержит более 1500 записей.

Структура multipart-сообщения

Составное сообщение разделяется на части при помощи boundary - уникальной строки-разделителя, указанной в заголовке Content-Type. Каждая часть имеет собственные заголовки Content-Type и Content-Transfer-Encoding.

Двойной дефис в конце (--abc123--) обозначает конец составного блока. Boundary может быть произвольной строкой, не встречающейся в теле частей.

Вложенные multipart-структуры

Типичное маркетинговое письмо с вложением имеет трёхуровневую структуру:

• multipart/mixed (верхний уровень)
  • multipart/alternative (текст письма)
    • text/plain
    • text/html
  • application/pdf (вложение)

Если в HTML-версии есть inline-картинки, добавляется уровень multipart/related между alternative и html.

Кодирование: base64 и quoted-printable

SMTP исторически рассчитан на передачу 7-битного текста. Двоичные данные (файлы, изображения) и не-ASCII символы требуют кодирования:

• base64 - представляет произвольные двоичные данные в виде набора из 64 ASCII-символов (A-Z, a-z, 0-9, +, /). Увеличивает размер на ~33%. Используется для вложений и изображений.
• quoted-printable - оставляет ASCII-символы как есть, а не-ASCII заменяет на =XX (шестнадцатеричный код). Текст остаётся частично читаемым. Подходит для писем на кириллице, где большая часть символов вне ASCII.

Современные серверы поддерживают 8BITMIME (RFC 6152), что позволяет передавать UTF-8 текст напрямую без кодирования. Но для совместимости с устаревшими системами quoted-printable и base64 продолжают использоваться повсеместно.

MIME и email-маркетинг

Несколько практических аспектов для маркетолога:

• text/plain обязателен. HTML-письмо без text/plain альтернативы - сигнал для спам-фильтров. Большинство ESP генерируют текстовую версию автоматически, но стоит проверить, что она не пуста и содержит осмысленный текст.
• Размер имеет значение. Gmail обрезает HTML-часть, если она превышает 102 КБ, показывая ссылку «View entire message». Тяжёлые inline-изображения раздувают MIME-сообщение. Предпочтительно ссылаться на картинки по URL, а не встраивать их через base64.
• Корректный charset. Если указан charset=iso-8859-1, а текст содержит UTF-8 кириллицу, получатель увидит набор бессмысленных символов. Всегда используйте charset=utf-8.
• Валидность структуры. Несовпадающий boundary, отсутствие завершающего маркера, неправильное вложение частей - всё это может привести к тому, что клиент не сможет разобрать сообщение. Результат - пустой экран вместо письма.

MIME за пределами email

Система типов MIME вышла далеко за рамки электронной почты. HTTP использует заголовок Content-Type с MIME-типами для определения формата ответа (text/html, application/json, image/webp). Браузеры полагаются на MIME-тип при принятии решения, как обработать загруженный файл. Регистрация новых типов происходит через IANA.