¿Qué son las “partes” en un correo electrónico multiparte?

Un poco de contexto …

Hace algún tiempo, escribí en Python un progtwig que trata con los mensajes de correo electrónico, una cosa que siempre aparece es saber si un correo electrónico es “multiparte” o no.

Después de un poco de investigación, supe que tiene algo que ver con los correos electrónicos que contienen HTML, o archivos adjuntos, etc. Pero no lo entendí realmente.

Mi uso se limitó a 2 instancias:

1. Cuando tuve que guardar el archivo adjunto del correo electrónico en bruto

Acabo de encontrar esto en Internet (probablemente aquí – Lo siento por no haber dado crédito a la persona que lo escribió, pero parece que no puedo encontrarlo nuevamente: /) y lo pegué en mi código.

def downloadAttachments(emailMsg, pathToSaveFile): """ Save Attachments to pathToSaveFile (Example: pathToSaveFile = "C:\\Program Files\\") """ att_path_list = [] for part in emailMsg.walk(): # multipart are just containers, so we skip them if part.get_content_maintype() == 'multipart': continue # is this part an attachment ? if part.get('Content-Disposition') is None: continue filename = part.get_filename() att_path = os.path.join(pathToSaveFile, filename) #Check if its already there if not os.path.isfile(att_path) : # finally write the stuff fp = open(att_path, 'wb') fp.write(part.get_payload(decode=True)) fp.close() att_path_list.append(att_path) return att_path_list 

2. Cuando tuve que obtener el texto del email crudo

También pegado de alguien en Internet sin entender realmente cómo funciona.

 def get_text(emailMsg): """ Output: body of the email (text content) """ if emailMsg.is_multipart(): return get_text(emailMsg.get_payload(0)) else: return emailMsg.get_payload(None, True) 

Lo que sí entiendo …

Es que si el mensaje de correo electrónico es multiparte, las partes pueden repetirse.

Mi pregunta es

¿Qué son exactamente estas partes? ¿Cómo sabes cuál es html por ejemplo? ¿O cuál es un archivo adjunto? ¿O simplemente el cuerpo?

No existe una jerarquía u orientación estricta sobre cómo usar exactamente los mensajes de varias partes. MIME simplemente define una forma de recostackr múltiples cargas útiles en un solo mensaje de correo electrónico. Una de las motivaciones originales que creo fue poder incrustar imágenes en el texto; pero poder adjuntar binarios a un mensaje de texto, y más en general, poder crear mensajes estructurados con cargas útiles que se relacionan de manera arbitraria es algo que simplemente ha estado ahí para que las aplicaciones las usen de la forma que consideren adecuada.

Un malentendido común es postular una jerarquía en una parte “principal” y “subordinada”. Ciertamente es posible crear esta estructura, pero de ninguna manera se hace universalmente. De hecho, la mayoría de los mensajes de varias partes simplemente tienen una secuencia de partes sin ninguna jerarquía. El cliente de correo electrónico del usuario comúnmente elegirá una de las partes “en línea” como la parte “principal” preferida para mostrar en un panel de mensajes, pero esto no es de ninguna manera dictada por la norma, ni puede ser ejecutada por la parte que envía.

Cada parte MIME tiene un conjunto de encabezados que le indican el tipo, la encoding y la disposición; para partes de tipo text/* la disposición predeterminada es “en línea” (por lo que a menudo no está explícitamente deletreada), mientras que la mayoría de las otras partes tienen una disposición predeterminada de “adjunto”. Tendrá que consultar los estándares pertinentes para una definición estricta, pero probablemente lo tome con un grano de sal, porque muchas aplicaciones del mundo real no son particularmente compatibles con RFC.

Para su pregunta concreta, encuentre las partes superiores de la hoja que están (implícitamente o explícitamente) en línea, y muestre una que sea compatible con su caso de uso como la “principal”. Si desea aplicar HTML como el formato preferido, puede hacerlo; pero muchas aplicaciones de correo electrónico difieren esto para que el usuario decida, y algunos usuarios definitivamente (debido a la necesidad técnica, las discapacidades físicas o el gusto personal) preferirán el texto sin formato cuando esté disponible.

Desafortunadamente, la práctica común de los productores de mensajes recientemente ha sido crear un contenedor multipart/alternative con text/plain text/html miembros de text/html , pero luego proporcionar una parte de text/plain completamente inútil y tener todo el contenido real en una parte de text/html . El arreglo correcto en esta situación sería simplemente no proporcionar una parte de text/plain si no puede poner algo útil en ello (pero supongo que solo se preocupan por superar un filtro de correo no deseado mal orientado, no por realmente acomodar las preferencias del destinatarios).

Las respuestas que está buscando están todas en el estándar MIME, especialmente:

  • RFC2045
  • RFC2046

Estos estándares juntos transformaron los correos electrónicos de texto simple, solo en inglés a su estado actual, donde tenemos formas interesantes de enviar Poo de Unicode, mapas de bits propios con lindos gatitos y también docenas de formas para software no compatible y middleboxes a lo largo del camino a Corrompe el mensaje de manera sutil y no sutil. Más detalles de estas características están en:

  • RFC2047
  • RFC2048 , ahora RFC4288 , RFC4299
  • RFC2049 para ejemplos y que no

Para la parte específica de IMAP de su pregunta, es decir, cómo acceder mejor al árbol MIME de estas partes a través de IMAP, vea RFC3501 , especialmente los capítulos que hablan sobre las construcciones BODY y BODYSTRUCTURE .

Si desea maravillarse con la belleza de MIME en acción, eche un vistazo a la “prueba de tortura MIME”. Es un poco difícil de encontrar, porque este elemento aleatorio en github definitivamente no es lo que quise decir. Aquí está el original de Mark Crispin, un ingeniero que creó IMAP:

  • Prueba de tortura MIME de Mark Crispin

Sí, eso es mucha lectura. Desafortunadamente, realmente necesitará entender todo lo anterior para manejar MIME de manera adecuada y segura. Por favor, no omita estos recursos y estándares a menos que desee crear abominaciones, como un envío masivo aleatorio que divida constantemente puntos de código no ASCII en UTF-8 en varios fragmentos codificados MIME adyacentes, etc. Gracias.