Структура MIME электронного письма: multipart/alternative, текстовая часть и кодировки

Что это такое

Электронное письмо — это блок заголовков, за которым следует тело; MIME позволяет представить тело деревом частей, каждая со своим Content-Type. Письмо с текстовой и HTML-версиями использует multipart/alternative. RFC 2046 требует располагать части по возрастанию предпочтительности, с предпочтительным форматом последним, поэтому text/plain идёт первым, а text/html — последним; клиенты показывают последнюю часть, которую способны отобразить. Встроенные изображения располагаются в оболочке multipart/related вокруг HTML-части; вложения — во внешней multipart/mixed. Тела с байтами вне ASCII объявляют Content-Transfer-Encoding: quoted-printable для преимущественно ASCII-текста (закодированные строки ограничены 76 символами с мягкими переносами) или base64 для двоичных данных. Поля заголовков, такие как Subject, и отображаемые имена в классической почте не могут содержать необработанный UTF-8; их оборачивают в encoded-words по RFC 2047 (=?utf-8?q?...?=, не более 75 символов каждое).

Почему это важно

Письмо без текстовой части, с текстовой частью «просмотрите это в HTML-клиенте» или с темой, в которой умлауты приходят в виде вопросительных знаков, выглядит как спам и для фильтров, и для людей. Большинство ошибок шаблонов находится на этом уровне: экранирование, кодирование и длина строк, а не формулировки письма.

Как применять

• Создавайте текстовую часть из тех же данных, что и HTML, а не удалением тегов: заголовки — строками, ссылки — как label: URL, таблицы — списками. Храните оба шаблона в одном месте, чтобы изменение одного означало изменение обоих.
• Формируйте письма библиотекой MIME платформы (например, пакетом email в Python); никогда не склеивайте границы частей вручную.
• Экранируйте каждую переменную, вставляемую в HTML-часть, по тем же правилам, что и на веб-страницах, а текстовую часть оставляйте без HTML-сущностей.
• Позвольте библиотеке выбирать quoted-printable для текста и base64 для вложений; держите исходные строки короткими, поскольку формат сообщений (RFC 5322) ограничивает строки 998 символами и рекомендует 78.
• Передавайте не-ASCII-темы и отображаемые имена через encoded-words; проверьте имя с умлаутами и эмодзи.
• Используйте абсолютные URL HTTPS и встроенный CSS; внешние таблицы стилей и скрипты игнорируются или блокируются почтовыми клиентами.

Подводные камни

Текстовая часть, написанная один раз и забытая при изменении HTML. Альтернативные части в неверном порядке, из-за чего клиенты, предпочитающие текст, показывают не ту часть. Заявленная кодировка UTF-8 при байтах Latin-1. Изображения multipart/related без ссылок Content-ID, приходящие как вложения. Перенаправления для отслеживания в текстовой части, где читатель видит сам URL.