Archivos y mensajes adjuntos

Hace referencia a: Outlook 2013 | Outlook 2016

Si se usa MIME con TNEF al codificar el contenido del mensaje, todas las propiedades de datos adjuntos y el contenido se encuentran en la secuencia de TNEF. El propio TNEF es un único archivo adjunto binario denominado Winmail.dat, codificado como se describe para MIME sin TNEF.

Si se usa MIME sin TNEF, los archivos adjuntos se envían como partes de contenido del mensaje MIME. El nombre de archivo se coloca en el parámetro name en el encabezado Content-type para los datos adjuntos. El juego de caracteres para los datos adjuntos se coloca en el parámetro charset en content-type; y la codificación de transferencia de contenido se determinan mediante el examen de todo el contenido de los datos adjuntos. Los datos adjuntos de direcciones URL se tratan especialmente:

• Si los datos adjuntos son una dirección URL (un archivo adjunto con extensión . URL) y el modo de acceso definido en él es FTP anónimo, se codifica como un mensaje externo y el contenido del archivo (la dirección URL) se copia en el encabezado del mensaje externo. Tipo de contenido: message/external-body; access-type=anon-ftp (Content-Transfer-Encoding: 7bit is assumed.)

• Si solo se encuentran caracteres de 7 bits y ninguna línea supera los 140 caracteres, los datos adjuntos son texto ASCII. Tipo de contenido: texto/sin formato; charset=us-ascii Content-Transfer-Encoding: 7 bits

• Si se encuentran líneas largas o hasta un 25 % de caracteres de 8 bits, el contenido de los datos adjuntos es texto y el juego de caracteres viene determinado por la configuración regional. Debe elegirse entre los juegos de caracteres definidos por la norma ISO 8859. Tipo de contenido: texto/sin formato; charset=ISO-8859-1 (por ejemplo)

  Content-Transfer-Encoding: quoted-printable

• Si el 25 % o más de los caracteres tienen el bit alto establecido, los datos adjuntos son binarios. Se codifica mediante el algoritmo Base64. Tipo de contenido: application/octet-stream (de forma predeterminada, en función de la extensión de archivo)

  • Content-Transfer-Encoding: base64 *

En los mensajes salientes, el tipo de contenido debe derivarse de la extensión de tres letras del nombre de archivo. Esta asignación existe en el Registro del sistema; en hay un valor de cadena denominado "Tipo de contenido" que proporciona el tipo de contenido MIME si se define uno. Este ejemplo es para un archivo de imagen TIFF:

HKEY_LOCAL_MACHINE\

Software\

Microsoft\

Clases\

.Tif

Tipo de contenido = "image/tiff"

Si no hay ninguna asignación para la extensión de archivo, se debe usar la secuencia de aplicación o octeto predeterminada.

En los mensajes entrantes, el tipo de contenido de los datos adjuntos siempre debe copiarse en la propiedad MAPI PR_ATTACH_MIME_TAG (PidTagAttachMimeTag). Incluso si se define un nombre de archivo para un archivo adjunto, la extensión asignada por el tipo de contenido debe usarse en las propiedades PR_ATTACH_FILENAME (PidTagAttachFilename) y PR_ATTACH_EXTENSION (PidTagAttachExtension).

Rfc 821 desusó oficialmente el parámetro name . A medida que evolucionan los estándares, Microsoft considerará la posibilidad de especificar una asignación alternativa para los nombres de archivo adjuntos.

Los mensajes adjuntos salientes se envían como tipo de contenido: los mensajes message/rfc822 dentro de los mensajes adjuntos se codifican de forma recursiva, en su lugar adecuado. Elementos de contenido de mensajes entrantes con Content-Type: multipart/digest también se asignan a mensajes incrustados.

Si uuencode con TNEF se usa durante la codificación del contenido del mensaje, todas las propiedades de datos adjuntos y el contenido se encuentran en la secuencia de TNEF. El propio TNEF es un único archivo adjunto binario denominado Winmail.dat, codificado como se describe para Uuencode sin TNEF.

Si uuencode se usa sin TNEF, todos los archivos adjuntos se tratan como binarios y uuencoded, siguiendo el texto del mensaje. El nombre de archivo está presente en el encabezado uuencode:

begin 0755 Winmail.dat

... Datos...

end

Los mensajes adjuntos se textizan en el texto del mensaje. La jerarquía de los mensajes adjuntos siempre se aplana; es decir, los mensajes dentro de los mensajes adjuntos se extraen al nivel superior.

Se descartan los objetos OLE incrustados.

Las posiciones de representación de datos adjuntos se transmiten literalmente mediante la propiedad PR_ATTACH_RENDERING (PidTagAttachRendering) en el TNEF. Si no se usa TNEF, se pierden. Los datos adjuntos entrantes sin posición de representación (incluso cuando no hay ningún TNEF) tienen su posición de representación establecida en 0xFFFFFFFF, es decir, sin posición en el texto del mensaje.

Vea también

Asignación de atributos de correo de Internet a propiedades MAPI