Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 2

Seguimos con el Análisis de captura de correo entrante IMAP, STARTTLS e IMAP IDLE que incicimos ya aquí: Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 1.

Vimos que era IMAP, las diferencias con POP, modos de funcionamiento, estados de una sesión IMAP, palabras clave como CAPABILITY, LOGIN, STARTTLS, IMAP IDLE, EXAMINE y SELECT. También las distintas respuestas del servidor, etc.

Seguimos en este capítulo, que no será el último, con SELECT, las respuestas del servidor a SELECT y otros comandos como FETCH y resto de palaras clave de IMAP y cierre de la conexión. 

La captura para tener la referencia:

En la Parte I nos quedamos  en que a una petición SELECT, el Servidor….:

El Servidor responde en el paquete 25 con una serie de FLAGS ó banderas y respuestas OK, en este caso:

* FLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1274868094] UID validity
* OK [UIDNEXT 2] Predicted next UID
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)] Permanent flags
0003 OK [READ-WRITE] SELECT completed

Estas líneas no son otra cosa que información devuelta por el Servidor a la petición SELECT con datos sobre el buzón INBOX, para este caso en el que solo hay un mensaje.

• * FLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk) Banderas o Flags especificados en buzón INBOX seleccionado. Significado de algunas banderas:
  

\Seen El mensaje ha sido leído

\Answered Mensaje contestado

\Flagged El mensaje está marcado por urgencia y de atención especial

\Deleted El mensaje tiene la marca o bandera de «borrado». Se eliminaría definitivamente (PURGE) con la orden o palabra clave EXPUGNE.

\Draft  El mensaje no ha completado no se haterminado de escribir, está marcado como borrador.

\Recent Mensaje que acaba de ser recibido justo en esta sesión.

• * 1 EXISTS Esiste un mensaje en INBOX
• * 0 RECENT Ningún mensaje reciente
• * OK [UIDVALIDITY 1274868094] UID validity Valor de vigencia de identificador único para control de sesiones.
• * OK [UIDNEXT 2] Predicted next UID Valor de UID que serrá asignado al primer mernsaje nuevo que llegue a INBOX.
• * OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)] Permanent flags Indica al cliente cual de las banderas conocidas pueden ser cambiadas de manera permanente.
  
• 0003 OK [READ-WRITE] SELECT completed Respuesta OK del servidor. Exito en la operación. Se slelecionó INBOX en modo Lectura – Escritura.

En este caso solo hay 1 mensaje en INBOX. si hubiese más, por ejemplo 20, otro tipo de mensaje contenido en las líneas anteriores sería:  * OK [UNSEEN 8] que significa: El mensaje 8 es el primer que aún no se ha visto, al que aún no se ha accedido.

Paquetes 26 a 29. Se trata, como ya hemos comentado en la Parte I de paquetes de petición (Cliente) y respuesta (Servidor) de IMAP IDLE cuyo objetivo es que el servidor avise al cliente de cuando ha llegado un correo y se sincronicen, esta sincronización se realiza de forma instantánea. Mientras el cliente está trabajando, gestionando el correo, enviando correos, será, en todo momento y de inmediato, notificado sobre nuevos mensajes.

Paquete 30. con el envío de este paquete alcanzamos el Select State ó Estado seleccionado. El cliente con SELECT ya seleccinó INBOX, ahora éste y con la orden o comando FETCH solicita la recuperación parcial o total de un mensaje, en este caso de mensaje número 1:

El Request Tag es ahora 0005

Vamos con el resto…

• BODY.PEEK  recuperamos parte del mensaje seleccionando partes del cuerpo de éste.
• HEADER.FIELD que partes de la cabecera se recupera. En este caso X-Ref, X-Priority…
• ENVELOPE estructura de la cabecera del mensaje procesado por el servidor en formato RFC822.
• RFC822.SIZE tamaño de mensaje en formato RFC822. 

RFC822 es una norma internacional para la legibilidad, de quien lo recibe, de los mensajes de texto de correo electrónico. Norbaliza, esntr otros aspectos, las cabeceras de los mensajes y cuerpo.

• UID identificador único del mensaje
• FLAGS banderas activadas paraéste mensaje
• INTERNALDATE fechainterna del mensaje

Como resúmen podemos decir que el Cliente pide al Servidor, respecto al mensaje número 1, información sobre las banderas activadas, fecha interna, estructura del cuerpo y cabecera del mensaje y fecha interna del mensaje.

Paquete 31. Respuesta del servidor a la petición FETCH conteniendo toda la información solicitada del mensaje número 1. En este caso las respuesta es:

* 1 FETCH (UID 1 RFC822.SIZE 1007 INTERNALDATE «26-May-2010 12:02:37 +0200» ENVELOPE («Wed, 26 May 2010 12:08:27 +0200» «Correo pruebas.» ((«Afon.» NIL «fon» «dominio.es»)) ((«Afon.» NIL «fon» «dominio.es»)) ((NIL NIL «usuario» «dominio.es»)) ((NIL NIL «seguridadyredes» «seguridadyredes.es»)) NIL NIL NIL «») BODY[HEADER.FIELDS («References» «X-Ref» «X-Priority» «X-MSMail-Priority» «X-MSOESRec» «Newsgroups»)] {2} FLAGS (\Seen))

0005 OK UID FETCH completed

Vemos que el Servidor responde con el mismo Request Tag: 0005. Devuelve la información pedida e informa de que todo se ha completando de forma exitosa  (OK UID FETCH completed).

Observad que la respuesta también contiene:

• El UID ó identificador único.
• RFC822.SIZE 1007 tamaño del mensaje en bytes.
• INTERNALDATE «26-May-2010 12:02:37 +0200″ Datos de fecha y hora internos del mensajede en que momento llegó dichomensaje al servidor.
• ENVELOPE datos de la estructura cabecera del mensaje. Observad que los datos fecha/hora no son los mismos que INTERNALDATE. Los NIL son datos que no está en el mensaje como Cc:, Bcc, etc. Si aparecen otros como el Subjet: «Correo pruebas.»
• BODY datos del a estructura del cuerpo delmensaje.
• FLAGS banderas o indicadores informando del estado. En este caso \Seen está indicando que el mensaje está leído.

En este caso la respuesta del servidor es OK. Pero se pueden dar otros dos casos:

• NO indicativo de error. El comando no se ejecutó o completó.
• BAD el comando es desconocido o el argumento que lo acompaña es inválido.

El resto de paquetes ya está visto.

Respecto a los paquetes Paquetes 42 y 43, decir que se trata de una petición (42) al servidor de recuperación completa del mensaje. En el paquete 43 el servidor devuelve toda la información disponible de cabeceras y cuerpo. Hemos abierto el mensaje. Aparecen otras cabeceras como X-Enigmail, X-Antivirus, X-User-Agent, X-Spam-status, etc.

Los últimos paquetes se refieren al término de la conexión. En este caso abrupto, solo TCP. De ser un cierre ordenado (Salir en el cliente de correo), seria de la siguiente forma:

• Petición de cierre de la conexión por parte del cliente:  Request: 0012 logout.
• Respuesta del Servidor: Response: BYE loggin out
• Cierre de la conexión ordenada TCP.

NOTA:

—————————————————————————-

Pensé que este iba a ser el último capítulo pero no, habrá más sobre IMAP. Hasta ahora hemos visto y estudiado un caso sencillo. Me quedan muchas cosas en el tintero sobre gestión de carpertas, otras formasde autentificación, otras respuestas del servidor, etc, etc.

Nos vemos, pués,  en el próximo…

—————————————————————————-