¿Por qué los webmails (como Gmail) envían mensajes MIME usando multipart/subtipo alternativo (al componer en HTML) mientras que otros envían HTML como MIME con partes de texto/html adentro (sin usar subtipo alternativo)?Subtipo multiparte/alternativo, cuando el cliente lo usa?
multipart/alternative indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en un formato diferente denotado por su encabezado "Content-Type". Los formatos están ordenados por lo fieles que son al original, con el primero menos fiel y el último más fiel.
Agentes de correo como Gmail saben lo que están haciendo, y convierten text/html en text/plain y ponen ambas alternativas en sus correos electrónicos y dejan que el receptor decida qué alternativa usar.
También hay agentes de correo que no saben cómo extraer una versión de solo texto del contenido html, simplemente porque el desarrollador no se molestó en implementarlo, por lo que solo enviaron text/html sin ninguna alternativa.
Y a veces - los llamo los locos - envíe multipart/alternative, pero en realidad solo coloque texto/html sin ninguna alternativa. Lo cual no es realmente agradable, pero no va contra ninguna especificación.
El section 5.1.4 de RFC 2046 define multipart/alternative tipo MIME para permitir que el remitente para proporcionar diferentes representaciones, intercambiables de el mismo mensaje y dejarlo hasta el receptor de elegir la forma de presentación más adecuado para sus capacidades. Tenga en cuenta que si bien debe conservarse el significado general de cada representación para el usuario, generalmente hay cierta pérdida de información de una representación a la otra (por ejemplo, text/plain falta la información de formato con respecto a text/html). Por lo general, las alternativas deben ordenarse de la más simple a la más rica, es decir, si las alternativas son nuevamente text/html y text/plain, entonces text/plain debería ser lo primero. Esto ayuda a los usuarios de visores que no cumplen con MIME en los que se mostrará primero la parte más fácil de interpretar. En general, un visor conforme a MIME debería mostrar la última representación que es capaz de ver, ya que es la más preferible.
Este tipo de contenido a menudo se contrasta con multipart/mixed donde se combinan un número de recursos diferentes en un solo mensaje.
La razón principal por la que algunos servicios de correo proporcionan mensajes como multipart/alternative es para admitir diferentes tipos de aplicaciones de visualización en el extremo de recepción. Por ejemplo, algunos espectadores carecen de la capacidad de representar HTML y requieren una representación de text/plain para que el mensaje sea legible. Al mismo tiempo, otros espectadores tienen la capacidad de procesar HTML y pueden proporcionar una experiencia de usuario mucho mejor cuando el mensaje se entrega como text/html. La solución más flexible para la compensación entre el soporte de una amplia gama de visores y la mejora de la experiencia del usuario para los más capaces se logra mediante la entrega de ambas representaciones envueltas en un mensaje multipart/alternative.
Para más información, vea RFC 2046.
Buena explicación. –