Почтовый клиент автора умеет показывать и text/plain, и text/html, но он предпочитает текстовую версию. Проблема в том, что многие отправители неправильно используют multipart/alternative: вместо настоящего plain-text варианта кладут заглушку «Plain text version not available». Это извращение. По стандарту multipart/alternative — это способ передать одно и то же содержимое в разных взаимозаменяемых форматах, обычно text/plain рядом с text/html. А сообщение об ошибке — не контент. Если клиент не умеет открыть HTML, он сам должен сообщить об ошибке, а не получать такое письмо.
Автор разбирает три сценария. Древний клиент до MIME (как у путешественника во времени из 80-х) покажет кашу из HTML-кода, среди которой затеряется фраза «Plain text version not available». Вряд ли кто-то это поймёт. Клиент с MIME, но без поддержки HTML, примет эту заглушку как полноценную альтернативу и покажет её вместо содержимого, возможно, даже не предложив восстановить HTML. А если клиент умеет и HTML, и plain text, но настроен предпочитать text/plain, пользователь увидит заглушку вместо реального письма, и ему придётся самому разбираться, как переключиться на HTML. То есть ему сделали хуже, чем если бы text/plain части вообще не было — тогда клиент, скорее всего, просто показал бы HTML или дал путь к восстановлению.
Кто-то возразит: «Я ставлю text/plain первым, как велит стандарт, чтобы показать своё предпочтение HTML». Но это не работает: у получателя свои настройки, и он предпочитает plain text. Когда multipart/alternative используется правильно, текстовая часть может быть даже чище, чем то, что получится из HTML. Если же нормальной текстовой версии нет — не надо выдумывать ошибку. Это порадует всех десятерых любителей plain text и заодно снизит риск попадания письма в спам.
Автор приводит реальные примеры text/plain частей из полученных писем: «This email contains html content. Please configure your email client for html or visit site for latest show times», просто «text/html», или текст с полусотней пустых строк, случайным CSS, ссылкой на отписку и обрывками контента. Это не альтернативы, а мусор. Если уж хочется напугать получателя, можно было бы спрятать предупреждение в HTML-комментарий — эффект примерно тот же, зато без игнорирования RFC и без злости случайных людей в интернете.