19
La respuesta a Mail multipart/alternative vs multipart/mixed sugiere que los accesorios deben ser pares del mensaje multipart/alternative, como:tipo MIME para satisfacer HTML, correo electrónico, imágenes y texto sin formato?
- multipart/mixed
- multiparte/alternativo
- text/plain
- text/html
- s ome/Lo (Disposition: attachment)
- algunos/Lo (Disposition: attachment)
- ...
- multiparte/alternativo
me gustaría enviar un correo electrónico con una parte html con algunas imágenes en línea y una alternativa de texto plano. ¿Cuál es el diseño MIME preferido para las distintas partes? Un par de opciones aparecen en el código de ejemplo y en otras preguntas, pero ¿cuál ha funcionado mejor en la práctica? Mi inclinación es la siguiente:
- multiparte/alternativo
- text/plain
- multipart/relacionados
- text/html (referencia a las imágenes de Cid) Imagen
- /gif
- imagen/gif
- ...
De esa manera, las imágenes son claramente con el propósito de hacer que la parte html. Un ejemplo completo de esto sería:
From: Rich Example <[email protected]>
To: A Recipient <[email protected]>
Subject: An example of email with images and a plain alternative
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="outer-boundary"
This is a MIME-encoded message. If you are seeing this, your mail
reader is old.
--outer-boundary
Content-Type: text/plain; charset=us-ascii
This message might make you :) or it might make you :(
--outer-boundary
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html"; start="<[email protected]>"; boundary="inner-boundary"
--inner-boundary
Content-Type: text/html; charset=us-ascii
Content-Disposition: inline
Content-ID: <[email protected]>
<html>
<body>
This message might make you
<img src="cid:[email protected]" alt="smile">
or it might make you
<img src="cid:[email protected]" alt="frown">
</body>
</html>
--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
R0lGODlhEAAQAKEBAAAAAP//AP//AP//ACH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci6JrasrqkypxJr8S0oNpgqkGLtcY6hoFADs=
--inner-boundary
Content-Type: image/gif
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
R0lGODlhEAAQAKEBAAAAAAD//wD//wD//yH5BAEKAAIALAAAAAAQABAAAAIzlA2px6IBw2
IpWglOvTahDgGdI0ZlGW5meKlci75drDzm5uLZyZ1I3Mv8ZB5Krtgg1RoFADs=
--inner-boundary--
--outer-boundary--
Parece ser un engaño exacto de la pregunta que refs: http://stackoverflow.com/questions/3902455/smtp-multipart-alternative-vs-multipart-mixed –
Una pequeña diferencia en la intención (si la transmití claramente) o no) podría tener que ver con el propósito de los archivos adjuntos. Si son _para_ la representación rica (por ejemplo, logos, aletas, etc.), ¿deberían estar "en" la rica alternativa? La pregunta ref'd tampoco hace mención de 'related'. –