IMAP (internet)

En informática, el Protocolo de acceso a mensajes de Internet o IMAP por sus siglas en inglés de Internet Message Access Protocol, es un protocolo estándar de Internet que utilizan los clientes de correo electrónico para recuperar mensajes de correo electrónico de un servidor de correo a través de una conexión TCP/IP. IMAP está definido por RFC 9051.

IMAP fue diseñado con el objetivo de permitir la gestión completa de un buzón de correo electrónico por parte de múltiples clientes de correo electrónico, por lo que los clientes generalmente dejan mensajes en el servidor hasta que el usuario los elimina explícitamente. Un servidor IMAP normalmente escucha en el puerto número 143. A IMAP sobre SSL/TLS (IMAPS) se le asigna el número de puerto 993.

Prácticamente todos los clientes y servidores de correo electrónico modernos admiten IMAP, que junto con el anterior POP3 (Protocolo de oficina de correos) son los dos protocolos estándar más frecuentes para la recuperación de correo electrónico. Muchos proveedores de servicios de correo web, como Gmail y Outlook.com, también brindan soporte para IMAP y POP3.

Protocolos de correo electrónico

El Protocolo de acceso a mensajes de Internet es un protocolo de Internet de capa de aplicación que permite que un cliente de correo electrónico acceda al correo electrónico en un servidor de correo remoto. La versión actual está definida por RFC 9051. Un servidor IMAP generalmente escucha en el conocido puerto 143, mientras que IMAP sobre SSL/TLS (IMAPS) usa 993.

Los mensajes de correo electrónico entrantes se envían a un servidor de correo electrónico que almacena los mensajes en el buzón de correo electrónico del destinatario. El usuario recupera los mensajes con un cliente de correo electrónico que utiliza uno de varios protocolos de recuperación de correo electrónico. Si bien algunos clientes y servidores utilizan preferentemente protocolos propietarios específicos del proveedor, casi todos admiten POP e IMAP para recuperar correo electrónico, lo que permite que muchos elijan libremente entre muchos clientes de correo electrónico como Pegasus Mail o Mozilla Thunderbird para acceder a estos servidores y permite a los clientes para ser utilizado con otros servidores.

Los clientes de correo electrónico que usan IMAP generalmente dejan mensajes en el servidor hasta que el usuario los elimina explícitamente. Esta y otras características del funcionamiento de IMAP permiten que varios clientes gestionen un mismo buzón. La mayoría de los clientes de correo electrónico admiten IMAP además del Protocolo de oficina postal (POP) para recuperar mensajes. IMAP ofrece acceso al almacenamiento de correo. Los clientes pueden almacenar copias locales de los mensajes, pero se consideran cachés temporales.

Historia

IMAP fue diseñado por Mark Crispin en 1986 como un protocolo de buzón de correo de acceso remoto, en contraste con el ampliamente utilizado POP, un protocolo para simplemente recuperar el contenido de un buzón.

Pasó por varias iteraciones antes de la VERSIÓN 4rev1 (IMAP4) actual, como se detalla a continuación:

IMAP originales

El Protocolo provisional de acceso al correo original se implementó como un cliente Xerox Lisp Machine y un servidor TOPS-20.

No existen copias de la especificación del protocolo provisional original ni de su software. Aunque algunos de sus comandos y respuestas eran similares a IMAP2, el protocolo provisional carecía de etiquetado de comando/respuesta y, por lo tanto, su sintaxis era incompatible con todas las demás versiones de IMAP.

IMAP2

El protocolo provisional fue reemplazado rápidamente por el Protocolo de acceso de correo interactivo (IMAP2), definido en RFC 1064 (en 1988) y luego actualizado por RFC 1176 (en 1990). IMAP2 introdujo el etiquetado de comando/respuesta y fue la primera versión distribuida públicamente.

IMAP3

IMAP3 es una variante extremadamente rara de IMAP. Fue publicado como RFC 1203 en 1991. Fue escrito específicamente como una propuesta contraria al RFC 1176, que a su vez proponía modificaciones a IMAP2. IMAP3 nunca fue aceptado por el mercado. El IESG reclasificó RFC1203 "Protocolo de acceso de correo interactivo - Versión 3" como un protocolo histórico en 1993. El Grupo de trabajo de IMAP utilizó RFC 1176 (IMAP2) en lugar de RFC 1203 (IMAP3) como punto de partida.

IMAP2bis

Con la llegada de MIME, IMAP2 se amplió para admitir estructuras de cuerpo MIME y agregar la funcionalidad de administración de buzones (crear, eliminar, renombrar, cargar mensajes) que estaba ausente en IMAP2. Esta revisión experimental se denominó IMAP2bis; su especificación nunca se publicó en forma de borrador. El grupo de trabajo IMAP del IETF publicó un borrador de Internet de IMAP2bis en octubre de 1993. Este borrador se basó en las siguientes especificaciones anteriores: documento IMAP2bis.TXT no publicado, RFC 1176 y RFC 1064 (IMAP2). El borrador de IMAP2bis.TXT documentó el estado de las extensiones de IMAP2 a partir de diciembre de 1992. Las primeras versiones de Pine se distribuyeron ampliamente con compatibilidad con IMAP2bis (Pine 4.00 y posteriores admiten IMAP4rev1).

IMAP4

Un grupo de trabajo de IMAP formado en el IETF a principios de la década de 1990 asumió la responsabilidad del diseño de IMAP2bis. El IMAP WG decidió cambiar el nombre de IMAP2bis a IMAP4 para evitar confusiones.

Ventajas sobre POP

Modos conectado y desconectado

Cuando se usa POP, los clientes generalmente se conectan al servidor de correo electrónico brevemente, solo durante el tiempo necesario para descargar nuevos mensajes. Al usar IMAP4, los clientes a menudo permanecen conectados siempre que la interfaz de usuario esté activa y descargan el contenido del mensaje a pedido. Para usuarios con muchos o grandes mensajes, este patrón de uso de IMAP4 puede resultar en tiempos de respuesta más rápidos.

Múltiples clientes simultáneos

El protocolo POP requiere que el cliente actualmente conectado sea el único cliente conectado al buzón. Por el contrario, el protocolo IMAP permite específicamente el acceso simultáneo de varios clientes y proporciona mecanismos para que los clientes detecten los cambios realizados en el buzón por otros clientes conectados simultáneamente. Consulte, por ejemplo, RFC 3501, sección 5.2, que cita específicamente "acceso simultáneo al mismo buzón por parte de varios agentes" como ejemplo.

Acceso a partes de mensajes MIME y recuperación parcial

Por lo general, todo el correo electrónico de Internet se transmite en formato MIME, lo que permite que los mensajes tengan una estructura de árbol donde los nodos de hoja son cualquiera de una variedad de tipos de contenido de una sola parte y los nodos que no son de hoja son cualquiera de una variedad de tipos de varias partes. El protocolo IMAP4 permite a los clientes recuperar cualquiera de las partes MIME individuales por separado y también recuperar partes de partes individuales o del mensaje completo. Estos mecanismos permiten a los clientes recuperar la parte de texto de un mensaje sin recuperar los archivos adjuntos o transmitir el contenido a medida que se recupera.

Información del estado del mensaje

Mediante el uso de banderas definidas en el protocolo IMAP4, los clientes pueden realizar un seguimiento del estado del mensaje: por ejemplo, si el mensaje ha sido leído, respondido o eliminado. Estos indicadores se almacenan en el servidor, por lo que diferentes clientes que acceden al mismo buzón en diferentes momentos pueden detectar cambios de estado realizados por otros clientes. POP no proporciona ningún mecanismo para que los clientes almacenen dicha información de estado en el servidor, por lo que si un solo usuario accede a un buzón con dos clientes POP diferentes (en diferentes momentos), la información de estado, como si se ha accedido a un mensaje, no se puede sincronizar entre el clientela. El protocolo IMAP4 admite indicadores del sistema predefinidos y palabras clave definidas por el cliente. Los indicadores del sistema indican información de estado, como si se ha leído un mensaje. Palabras clave, que no son compatibles con todos los servidores IMAP, permitir que los mensajes reciban una o más etiquetas cuyo significado depende del cliente. Las palabras clave de IMAP no deben confundirse con las etiquetas propietarias de los servicios de correo electrónico basados ​​en web que, a veces, los servidores propietarios correspondientes traducen a carpetas IMAP.

Múltiples buzones en el servidor

Los clientes IMAP4 pueden crear, cambiar el nombre y eliminar buzones (generalmente presentados al usuario como carpetas) en el servidor y copiar mensajes entre buzones. La compatibilidad con varios buzones también permite que los servidores proporcionen acceso a carpetas públicas y compartidas. La extensión de la lista de control de acceso (ACL) IMAP4 (RFC 4314) se puede utilizar para regular los derechos de acceso.

Búsquedas del lado del servidor

IMAP4 proporciona un mecanismo para que un cliente le pida al servidor que busque mensajes que cumplan con una variedad de criterios. Este mecanismo evita que los clientes descarguen todos los mensajes del buzón para realizar estas búsquedas.

Mecanismo de extensión incorporado

Como reflejo de la experiencia de los protocolos de Internet anteriores, IMAP4 define un mecanismo explícito mediante el cual se puede extender. Se han propuesto muchas extensiones IMAP4 al protocolo base y son de uso común. IMAP2bis no tenía un mecanismo de extensión y POP ahora tiene uno definido por RFC 2449.

Notificaciones push del servidor

IMAP IDLE proporciona una forma para que el servidor de correo notifique a los clientes conectados que hubo cambios en un buzón, por ejemplo, porque llegó un nuevo correo. POP no ofrece una función comparable y los clientes de correo electrónico deben conectarse periódicamente al servidor POP para comprobar si hay correo nuevo.

Desventajas

Si bien IMAP soluciona muchas de las deficiencias de POP, esto inherentemente introduce una complejidad adicional. Gran parte de esta complejidad (p. ej., varios clientes que acceden al mismo buzón al mismo tiempo) se compensa con soluciones alternativas del lado del servidor, como Maildir o backends de bases de datos.

La especificación IMAP ha sido criticada por no ser lo suficientemente estricta y permitir comportamientos que efectivamente niegan su utilidad. Por ejemplo, la especificación establece que cada mensaje almacenado en el servidor tiene una "identificación única" para permitir que los clientes identifiquen los mensajes que ya han visto entre sesiones. Sin embargo, la especificación también permite que estos UID se invaliden sin restricciones, lo que prácticamente anula su propósito.

A menos que el almacenamiento de correo y los algoritmos de búsqueda en el servidor se implementen cuidadosamente, un cliente puede consumir potencialmente grandes cantidades de recursos del servidor al buscar buzones de correo masivos.

Los clientes IMAP4 necesitan mantener una conexión TCP/IP con el servidor IMAP para ser notificados de la llegada de correo nuevo. La notificación de la llegada del correo se realiza a través de la señalización en banda, lo que contribuye a la complejidad del manejo del protocolo IMAP del lado del cliente. Una propuesta privada, push IMAP, extendería IMAP para implementar el correo electrónico push enviando el mensaje completo en lugar de solo una notificación. Sin embargo, el impulso de IMAP no ha sido generalmente aceptado y el trabajo actual del IETF ha abordado el problema de otras maneras (consulte el Perfil de Lemonade para obtener más información).

A diferencia de algunos protocolos propietarios que combinan operaciones de envío y recuperación, enviar un mensaje y guardar una copia en una carpeta del lado del servidor con un cliente IMAP de nivel base requiere transmitir el contenido del mensaje dos veces, una vez a SMTP para la entrega y una segunda vez a IMAP para almacenar en una carpeta de correo enviado. Esto se soluciona mediante un conjunto de extensiones definidas por el perfil Lemonade de IETF para dispositivos móviles: URLAUTH (RFC 4467) y CATENATE (RFC 4469) en IMAP, y BURL (RFC 4468) en SMTP-SUBMISSION. Además de esto, Courier Mail Server ofrece un método no estándar de envío usando IMAP copiando un mensaje saliente a una carpeta de bandeja de salida dedicada.

Seguridad

Para proteger criptográficamente las conexiones IMAP entre el cliente y el servidor, se pueden usar IMAPS en el puerto TCP 993, que utiliza SSL/TLS. A partir de enero de 2018, TLS es el mecanismo recomendado.

Alternativamente, STARTTLS se puede usar para cifrar la conexión cuando se conecta al puerto 143 después de comunicarse inicialmente a través de texto sin formato.

Ejemplo de diálogo

Este es un ejemplo de conexión IMAP tomada de RFC 3501 sección 8:

C: <abrir conexión>
S: * OK IMAP4rev1 Servicio Listo
C: a001 iniciar sesión mrc secreto
S: a001 OK INICIO DE SESIÓN completado
C: a002 seleccionar bandeja de entrada
S: * 18 EXISTE
S: * BANDERAS (RespondidoMarcadoEliminadoVistoBorrador)
S: * 2 RECIENTES
S: * OK [UNSEEN 17] El mensaje 17 es el primer mensaje no visto
S: * OK [UIDVALIDITY 3857529045] UID válidos
S: a002 OK [LECTURA-ESCRITURA] SELECCIÓN completada
C: a003 buscar 12 completos
S: * 12 FETCH (BANDERAS ( Visto) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 SOBRE ("Miércoles, 17 de julio de 1996 02:23:25 -0700 (PDT)"
      "Resumen y actas de la reunión del grupo de trabajo IMAP4rev1"
      (("Terry Gray" NIL "gris" "cac.washington.edu"))
      (("Terry Gray" NIL "gris" "cac.washington.edu"))
      (("Terry Gray" NIL "gris" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutos" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
      "<B27397-0100000@cac.washington.edu>")
      CUERPO ("TEXTO" "NORMAL" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
      92))
S: a003 OK FETCH completado
C: a004 buscar 12 cuerpo [encabezado]
S: * 12 FETCH (CUERPO [ENCABEZADO] {342}
S: Fecha: miércoles, 17 de julio de 1996 02:23:25 -0700 (PDT)
S: De: Terry Gray <gray@cac.washington.edu>
S: Asunto: Resumen y actas de la reunión del grupo de trabajo IMAP4rev1
S: Para: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Id. de mensaje: <B27397-0100000@cac.washington.edu>
S: MIME-Versión: 1.0
S: Tipo de contenido: TEXTO/NORMAL; CONJUNTO DE CARACTERES=US-ASCII
S:
S:)
S: a004 OK FETCH completado
C a005 almacenar 12 +banderas borrado
S: * 12 FETCH (INDICADORES ( Visto  Eliminado))
S: a005 OK +BANDERAS completado
C: a006 cerrar sesión
S: * BYE IMAP4rev1 servidor terminando conexión
S: a006 OK LOGOUT completado