El comando IMAP_MsgFetch permite al usuario recuperar uno o varios elementos de datos simples de un mensaje especificado sin necesidad de descargar el mensaje.

imap_ID es una referencia entero largo a una conexión abierta creada con IMAP_Login.

numMsg es un valor entero largo que indica el mensaje a examinar. Este valor representa la posición de un mensaje dentro de la lista actual de los mensajes. El numMsg de un mensaje no es un valor estable, difiere de una sesión a otra.

datosMsg es una variable texto que indica el o los elementos a recuperar. En el caso de varios elementos de datos, un carácter de espacio debe separar cada uno de ellos. Hay dos tipos de elementos de datos:

• Elementos de datos simples, que sólo recuperan una pieza de información y
• Macro elementos de datos, que recuperan varias piezas de información a la vez. Tres macros definen los conjuntos de información actuales disponibles. Una macro debe ser utilizada sola, es decir sin otra macro ni elemento de datos.

Para obtener más información sobre los elementos de datos, consulte los párrafos "Elementos de datos simples" y "Macro elementos de datos"

valoresMsg es una variable texto que puede devolver un par simple Elemento de datos/Valor de datos, o una lista de pares Elemento de datos/Valor de datos.

• En el primer caso, la estructura del texto devuelto es la siguiente: Elemento de datos + Espacio + Valor de datos
• En el segundo caso, la estructura del texto devuelto es la siguiente: Elemento de datos1 + Espacio + Valor de datos1+Elemento de datos2 + Espacio + Valor de datos2.

valoresMsg puede contener una lista entre paréntesis, una cadena entre comillas o una sola cadena en función del parámetro datosMsg.

• La lista entre paréntesis está estructurado de la siguiente manera (ver el ejemplo FLAGS): (Valor de datos1 + Espacio +Valor de datos2). Si la lista entre paréntesis devuelve sólo paréntesis, esto significa que no hay ningún valor de datos. Esta regla no se aplica a listas de direcciones entre paréntesis (ver el ejemplo ENVELOPE).
• Las cadenas entre comillas se estructuran de la siguiente manera (ver el ejemplo  INTERNALDATE): Elemento de datos + comillas + valores de datos + Comillas. Cuando un valor de datos es inexistente, se devuelve una cadena vacía "".
• Las cadenas simples (sin comillas) indican los valores de tipo entero, entero largo o numérico y se estructuran de la siguiente manera: Elemento de datos + espacio + Valor de datos. En este caso, lo más probable es que tenga que convertir al tipo adecuado (ver el ejemplo UID).

Nota: las comillas se utilizan por lo general cuando las cadenas contienen caracteres especiales, como un espacio o paréntesis. Por lo tanto, al analizar la cadena de caracteres devuelta por el comando IMAP_Fetch, los caracteres comillas se tienen en cuenta al procesar el contenido de la cadena.

• INTERNALDATE
  Recupera la fecha y la hora internas en el servidor IMAP. Esta no es la fecha y hora devueltas por el encabezado "Date”, sino la fecha y hora que indican el momento en que el mensaje fue recibido. Para los mensajes enviados vía un servidor SMTP, esta información indica por lo general la fecha y la hora de la entrega final del mensaje. Para los mensajes enviados vía luego de un comando IMAP_Copy, esta información indica generalmente la fecha y la hora internas del mensaje fuente.
  El elemento de datos INTERNALDATE devuelve una cadena entre comillas.

Ejemplo:

valoresMsg devuelve INTERNALDATE "17-Jul-2001 15:45:37 +0200"

• FLAGS
  Recupera entre paréntesis la lista de los marcadores definidos para el mensaje. Los marcadores están separados por espacios.

Ejemplo:

valoresMsg devuelve FLAGS () si no hay ningún marcador definido para el mensaje especificado.
valoresMsg devuelve FLAGS (\Seen \Answered) si los marcadores \Seen y \Answered están definidos para el mensaje.

• RFC822.SIZE
  Recupera el número de bytes del mensaje, expresado en el formato RFC-822. El nombre del elemento de datos está separado del valor devuelto por un espacio. Se devuelve una cadena sin comillas, lo que significa que probablemente necesite convertir esta cadena en entero largo (ver el ejemplo UID).

Ejemplo:

valoresMsg devuelve RFC822.SIZE 99599

• ENVELOPE
  Recupera entre paréntesis la lista que describe la parte del encabezado del mensaje. El servidor trata esta parte analizando los campos de encabezado y los valores por defecto si es necesario.
  Los campos de encabezado se devuelven en el siguiente orden: fecha, asunto, de, responder a, para, cc, bcc, en respuesta a y "message-id")
  Ejemplo:

valoresMsg devuelve ENVELOPE ("Tue, 17 Jul 2001 17:26:34 +0200" "Test" (("RSmith" NIL "RSmith" "test")) (("RSmith" NIL "RSmith" "test")) (("RSmith" NIL "RSmith" "test")) (("RSmith" NIL "RSmith" "test")) () () "" "<ee6b33a.-1@Mail.x6foadRIbnm>")

Los encabezados de, para, en respuesta a, cc y bcc son listas entre paréntesis de estructuras de direcciones. Una estructura de direcciones es una lista que describe una dirección de correo electrónico. Los campos de una estructura de dirección se presentan en el siguiente orden: nombre, [SMTP] at-domain-list (source route), nombre del buzón y nombre del servidor. Por ejemplo, (("RSmith" NIL "RSmith" "test")).

• BODY
  Devuelve la misma información que BODYSTRUCTURE excepto para los datos de extensión (ver BODYSTRUCTURE).
  Ejemplo:

valoresMsg devuelve BODY ("TEXT" "PLAIN" ("CHARSET" "us-ascii") NIL NIL "8BIT" 8 1)

• BODYSTRUCTURE
  Recupera la estructura MIME del mensaje. El servidor trata esta parte analizando los campos del encabezado MIME en el encabezado y cuerpo del mensaje. Este elemento de datos es particularmente útil para analizar el contenido de un mensaje sin descargarlo. Por ejemplo, puede probar rápidamente el tamaño de cada parte o los nombres de los archivos adjuntos. BODYSTRUCTURE devuelve una lista entre paréntesis, cadenas entre comillas y cadenas sin comillas.
  En función del contenido del mensaje, BODYSTRUCTURE devolverá una lista “non- multipart” o una anidada (“multipart”):
  
  • Lista “non-multipart”: similar, por ejemplo, a un correo electrónico "non-multipart"; la estructura del cuerpo de un mensaje texto simple de 48 líneas y 2279 bytes puede ser la siguiente: ("TEXT" "PLAIN" ("CHARSET" "us-ascii") NIL NIL "8BIT" 8 1 NIL NIL NIL).
    Los campos simples de una lista “non-multipart” entre paréntesis aparece en el siguiente orden:
    

    body type	Cadena que da el tipo del contenido de media (Content-type: media type ej. TEXT)
    body subtype	Cadena que da el subtipo del contenido de media (Content-type: subtype ej. PLAIN)
    body parameter	Lista entre paréntesis de pares atributos/valores
    parenthesized list	[ej. ("CHARSET" "US-ASCII" "NAME" "cc.diff") donde "US-ASCII" es el valor de "CHARSET" y "cc.diff" es el valor de "NAME".
    body id	Cadena que da el número de ID del contenido (permite a un cuerpo hacer referencia a otro). Por lo tanto, los cuerpos pueden etiquetarse utilizando el campo  de encabezado "Content-ID". El valor Content-ID tiene una sintaxis particular en el caso de un tipo de media multipart/alternative. Ver la explicación en la sección de la RFC 2046 relativa a los casos multipart/alternative.
    body description	Cadena que describe el contenido
    body encoding	Cadena que da la codificación de transferencia del contenido (Content-Transfer-Encoding)
    body size	Valor numérico que indica que el tamaño del cuerpo en bytes. Note que este es el tamaño durante la codificación de transferencia y no el tamaño resultante después de la decodificación.

    
    - Un cuerpo de tipo MESSAGE y subtipo RFC822 contiene, justo después los campos simples, la estructura de sobre, la estructura de cuerpos y el tamaño en líneas de texto del mensaje encapsulado.
    - Un cuerpo de tipo TEXT contiene, justo después los campos simples el tamaño en líneas de texto del cuerpo. Note que este es el tamaño durante la codificación y no el tamaño resultante después de la decodificación. Los datos de extensión siguen los campos simples y los campos de tipo listados arriba. Los datos de extensión no se devuelven con el elemento BODY, pero pueden devolverse con BODYSTRUCTURE.
    Si están presentes, los datos de extensión de una lista “non multipart” entre paréntesis deben aparecer en el siguiente orden:
    

    body MD5	Cadena que da el valor MD5 del cuerpo, como se define en [MD5]
    body disposition	Lista entre paréntesis que consiste de una cadena de tipo de disposición seguida por una lista entre paréntesis de pares de atributos/valores como se definió en [DISPOSITION]
    body language	Cadena o lista entre paréntesis que indica el lenguaje del cuerpo como se definió en [LANGUAGE-TAGS]

    
    
    Ejemplo: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48 NIL NIL NIL)
    Descripción:("bodytype" "bodysubtype" (BodyParameterParenthesizedList) bodyId bodyDescription "bodyEncoding" BodySize BodySizeInTextLines ExtensionDataBODYmd5 ExtensionDataBodyDisposition ExtensionDataBodyLanguage)
  • Lista “multipart” entre paréntesis: este es el caso del e-mail multipart; incluye una lista “non-multipart” entre paréntesis.
    Los paréntesis anidados indican dos partes múltiples (multiple parts). El primer elemento de la lista entre paréntesis es un cuerpo anidado y no un tipo de cuerpo. El segundo elemento de la lista es el subtipo multipart (mixed, digest, parallel, alternative, etc.).
    El subtipo multipart está seguido por los datos de extensión. Cuando están presentes, los datos de extensión deben aparecer en el siguiente orden:
    

    body parameter	Lista entre paréntesis de pares atributos/valores
    body disposition	Lista entre paréntesis consiste de una cadena de tipo de disposición seguida de una lista entre paréntesis de pares atributos/valores  como se definió en [DISPOSITION]
    body language	Cadena o lista entre paréntesis que indica el lenguaje del cuerpo como se define en [LANGUAGE-TAGS]

    
    Los datos de extensión posteriores no están aún definidos en esta versión del protocolo. Estos datos de extensión pueden consistir de cero o más NILs, cadenas, números o listas entre paréntesis de estos datos. Las implementaciones clientes utilizan el elemento de datos BODYSTRUCTURE DEBEN estar preparadas para aceptar tales datos de extensión. Las implementaciones Server NO DEBEN enviar tales datos de extensión hasta que haya sido definido en una revisión del protocolo.
    Ejemplo: BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii") NIL NIL "7BIT" 22 1 NIL NIL NIL)("APPLICATION" "BYTE-STREAM" ("NAME" "casta37.jpg" "X-MAC-TYPE" "4A504547" "X-MAC-CREATOR" "6F676C65") NIL NIL "BASE64" 98642 NIL ("ATTACHMENT" ("FILENAME" "casta37.jpg")) NIL) "MIXED" ("BOUNDARY" "4D_====================1385356==") NIL NIL)
    Descripción: (("bodytype" "bodysubtype" (BodyParameterParenthesizedList) bodyId bodyDescription "bodyEncoding" BodySize BodySizeInTextLines ExtensionDataBODYmd5 ExtensionDataBodyDisposition ExtensionDataBodyLanguage) ("bodytype" "bodysubtype" (BodyParameterParenthesizedList) bodyId bodyDescription "bodyEncoding" BodySize BodySizeInTextLines ExtensionDataBODYmd5 ExtensionDataBodyDisposition ExtensionDataBodyLanguage) "multipartSubtype" (ExtensionDataBodyParameterList) ExtensionDataBodyDisposition ExtensionDataBodyLanguage))

• UID
  Recupera el número de identificación único del mensaje, equivalente a ejecutar IMAP_UIDToMsgNum. Como este número se devuelve en un área de texto, debe convertirlo en Entero largo.
  Ejemplo:

valoresMsg devuelve UID 250000186

Para obtener un entero largo:

• FAST
  Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE)
  Ejemplo:

valoresMsg devuelve "FLAGS (\Seen \Answered) INTERNALDATE "17-Jul-2001 15:45:37 +0200" RFC822.SIZE 99599"

• ALL
  Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
• FULL
  Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)