Muchos sistemas de correo envían mensajes multipart/alternative en los que la parte text/plain no contiene el contenido equivalente del correo, sino un mensaje de error como "Plain text version not available" o instrucciones publicitarias. El estándar RFC 2046 de la IETF define multipart/alternative para presentar la misma información en formatos intercambiables, normalmente HTML y texto plano, pero en ningún caso para transmitir errores o mensajes comerciales. Cuando un cliente de correo prefiere la versión de texto plano, el usuario recibe ese texto en lugar del contenido real, y solo acierta a encontrar el mensaje si conoce a fondo su cliente.
El artículo recorre tres escenarios de uso: un cliente anterior a MIME, un cliente MIME que no admite text/html, y un cliente MIME configurado para preferir texto plano. En ninguno de los casos el mensaje de error aporta valor; en el tercero, omitir la parte text/plain habría ofrecido directamente la experiencia prevista.
Además, esta práctica puede perjudicar la reputación del remitente: reglas de filtrado como las de Apache SpamAssassin penalizan los correos que declaran una parte text/plain inexistente o inútil. La recomendación final es sencilla: no enviar alternativas text/plain que no lo sean, y reservar multipart/alternative únicamente para representar el mismo contenido en distintos formatos.