En informática, el Protocolo de acceso a mensajes de Internet ( IMAP ) es un protocolo estándar de Internet utilizado por 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 . [1] IMAP está definido en RFC 9051.
IMAP fue diseñado con el objetivo de permitir la gestión completa de una casilla de correo electrónico por parte de varios clientes de correo electrónico, por lo que los clientes generalmente dejan mensajes en el servidor hasta que el usuario los elimine explícitamente. Un servidor IMAP normalmente escucha en el puerto número 143. A IMAP sobre SSL/TLS ( IMAPS ) se le asigna el puerto número 993. [2] [3]
Prácticamente todos los clientes y servidores de correo electrónico modernos admiten IMAP, que junto con el anterior POP3 (Protocolo de oficina postal) son los dos protocolos estándar más frecuentes para la recuperación de correo electrónico. [4] Muchos proveedores de servicios de correo web como Gmail y Outlook.com también ofrecen soporte para IMAP y POP3.
El Protocolo de acceso a mensajes de Internet es un protocolo de Internet de capa de aplicación que permite a un cliente de correo electrónico acceder al correo electrónico en un servidor de correo remoto . La versión actual está definida por RFC 9051. Un servidor IMAP normalmente escucha en el puerto conocido 143, mientras que IMAP sobre SSL/TLS (IMAPS) utiliza el 993. [2] [3]
Los mensajes de correo electrónico entrantes se envían a un servidor de correo electrónico que almacena los mensajes en la bandeja de entrada del destinatario. El usuario recupera los mensajes con un cliente de correo electrónico que utiliza uno de los numerosos protocolos de recuperación de correo electrónico disponibles. Si bien algunos clientes y servidores utilizan preferentemente protocolos propietarios específicos del proveedor , [5] casi todos admiten POP e IMAP para recuperar correo electrónico, lo que permite que muchos usuarios elijan libremente entre muchos clientes de correo electrónico, como Pegasus Mail o Mozilla Thunderbird , para acceder a estos servidores y permite que los clientes se utilicen con otros servidores .
Los clientes de correo electrónico que utilizan IMAP generalmente dejan los mensajes en el servidor hasta que el usuario los borra explícitamente. Esta y otras características del funcionamiento de IMAP permiten que varios clientes administren el 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. [6] IMAP ofrece acceso al almacenamiento de correo. Los clientes pueden almacenar copias locales de los mensajes, pero se consideran una caché temporal.
IMAP fue diseñado por Mark Crispin en 1986 como un protocolo de buzón 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 actual VERSIÓN 4rev2 (IMAP4), como se detalla a continuación:
El Protocolo de acceso a correo provisional original se implementó como un cliente de Xerox Lisp Machine y un servidor TOPS-20 .
No existen copias de la especificación del protocolo provisional original ni de su software. [7] [8] 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.
El protocolo provisional fue rápidamente reemplazado por el Protocolo de acceso a correo interactivo (IMAP2), definido en RFC 1064 (en 1988) y posteriormente actualizado por RFC 1176 (en 1990). IMAP2 introdujo el etiquetado de comando/respuesta y fue la primera versión distribuida públicamente.
IMAP3 es una variante extremadamente rara de IMAP. [9] Se publicó como RFC 1203 en 1991. Fue escrito específicamente como una contrapropuesta a RFC 1176, que proponía modificaciones a IMAP2. [10] IMAP3 nunca fue aceptado por el mercado. [11] [12] El IESG reclasificó el RFC1203 "Interactive Mail Access Protocol – Version 3" como un protocolo histórico en 1993. El grupo de trabajo IMAP utilizó el RFC 1176 (IMAP2) en lugar del RFC 1203 (IMAP3) como punto de partida. [13] [14]
Con la llegada de MIME , IMAP2 se amplió para soportar estructuras de cuerpo MIME y añadir funcionalidad de gestión de buzones (crear, eliminar, renombrar, subir mensajes) que no existía en IMAP2. Esta revisión experimental se denominó IMAP2bis; su especificación nunca se publicó en forma no preliminar. El grupo de trabajo IMAP de la IETF publicó un borrador de Internet de IMAP2bis en octubre de 1993. Este borrador se basaba en las siguientes especificaciones anteriores: documento IMAP2bis.TXT no publicado, RFC 1176 y RFC 1064 (IMAP2). [15] El borrador IMAP2bis.TXT documentaba el estado de las extensiones de IMAP2 a diciembre de 1992. [16] Las primeras versiones de Pine se distribuyeron ampliamente con soporte para IMAP2bis [9] (Pine 4.00 y posteriores admiten IMAP4rev1).
A principios de los años 90, se formó un grupo de trabajo sobre IMAP en el IETF que se hizo cargo del diseño de IMAP2bis. El grupo de trabajo sobre IMAP decidió cambiar el nombre de IMAP2bis a IMAP4 para evitar confusiones.
Cuando se utiliza POP, los clientes suelen conectarse al servidor de correo electrónico brevemente, solo el tiempo necesario para descargar mensajes nuevos. Cuando se utiliza IMAP4, los clientes suelen permanecer conectados mientras la interfaz de usuario esté activa y descargan el contenido de los mensajes a pedido. Para los usuarios con muchos mensajes o mensajes de gran tamaño, este patrón de uso de IMAP4 puede dar como resultado tiempos de respuesta más rápidos.
Después de una autenticación exitosa, el protocolo POP proporciona una vista completamente estática del estado actual del buzón y no proporciona un mecanismo para mostrar los cambios externos en el estado durante la sesión. Por el contrario, el protocolo IMAP proporciona una vista dinámica y requiere que se detecten los cambios externos en el estado, incluidos los mensajes recién llegados, así como los cambios realizados en el buzón por otros clientes conectados simultáneamente, y que se envíen las respuestas apropiadas entre los comandos, así como durante un comando IDLE , como se describe en RFC 2177. Consulte también RFC 3501, sección 5.2, que cita específicamente "el acceso simultáneo al mismo buzón por parte de varios agentes".
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 contenido 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 cualquiera de las partes individuales o del mensaje completo. Estos mecanismos permiten a los clientes recuperar la parte de texto de un mensaje sin recuperar archivos adjuntos o transmitir contenido a medida que se recupera.
Mediante el uso de indicadores definidos en el protocolo IMAP4, los clientes pueden realizar un seguimiento del estado de los mensajes: por ejemplo, si el mensaje ha sido leído, respondido o eliminado. Estos indicadores se almacenan en el servidor, de modo que distintos clientes que accedan al mismo buzón en distintos 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, de modo que si un único usuario accede a un buzón con dos clientes POP diferentes (en distintos momentos), la información de estado (por ejemplo, si se ha accedido a un mensaje) no se puede sincronizar entre los clientes. El protocolo IMAP4 admite indicadores de sistema predefinidos y palabras clave definidas por el cliente. Los indicadores de sistema indican información de estado, por ejemplo, si se ha leído un mensaje. Las palabras clave, que no son compatibles con todos los servidores IMAP, permiten asignar a los mensajes una o más etiquetas cuyo significado depende del cliente. Las palabras clave IMAP no deben confundirse con las etiquetas propietarias de los servicios de correo electrónico basados en la Web , que a veces se traducen en carpetas IMAP por los servidores propietarios correspondientes.
Los clientes IMAP4 pueden crear, cambiar el nombre y eliminar buzones de correo (que normalmente se presentan al usuario como carpetas) en el servidor, y copiar mensajes entre buzones de correo. La compatibilidad con varios buzones de correo también permite a los servidores proporcionar acceso a carpetas públicas y compartidas. La extensión de lista de control de acceso (ACL) de IMAP4 ( RFC 4314) se puede utilizar para regular los derechos de acceso.
IMAP4 ofrece un mecanismo para que un cliente solicite al servidor que busque mensajes que cumplan una serie de criterios. Este mecanismo evita que los clientes tengan que descargar todos los mensajes del buzón para realizar estas búsquedas.
Como reflejo de la experiencia de los protocolos de Internet anteriores, IMAP4 define un mecanismo explícito mediante el cual puede extenderse. Se han propuesto muchas extensiones de 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.
IMAP IDLE ofrece una forma para que el servidor de correo notifique a los clientes conectados que se han producido cambios en un buzón de correo, por ejemplo, porque ha llegado un correo nuevo. POP no ofrece ninguna función comparable y los clientes de correo electrónico deben conectarse periódicamente al servidor POP para comprobar si hay correo nuevo.
Si bien IMAP soluciona muchas de las deficiencias de POP, esto inherentemente introduce una complejidad adicional. Gran parte de esta complejidad (por ejemplo, varios clientes que acceden al mismo buzón de correo 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 anulan su utilidad. Por ejemplo, la especificación establece que cada mensaje almacenado en el servidor tiene un "identificador único" para permitir que los clientes identifiquen los mensajes que ya han visto entre sesiones. Sin embargo, la especificación también permite que estos identificadores únicos sean invalidados casi sin restricciones, lo que prácticamente frustra su propósito. [17]
Desde un punto de vista administrativo y de recursos, el protocolo IMAP puede considerarse una implementación temprana de la computación en la nube , ya que la intención y el propósito de IMAP es mantener la estructura de su buzón (contenido, estructura de carpetas, estado de mensajes individuales, etc.) en el servidor de correo, mientras que con POP, todo esto se mantiene en el dispositivo local del usuario. Por lo tanto, IMAP requiere muchos más recursos del lado del servidor, lo que genera un costo significativamente mayor por buzón.
A menos que los algoritmos de almacenamiento, indexación y búsqueda de correo en el servidor se implementen con cuidado, un cliente puede potencialmente consumir grandes cantidades de recursos del servidor al buscar en buzones de correo masivos.
Los clientes IMAP4 necesitan mantener una conexión TCP/IP con el servidor IMAP para recibir notificaciones de la llegada de correo nuevo. La notificación de la llegada de correo se realiza mediante señalización en banda , lo que contribuye en cierta medida a la complejidad del manejo del protocolo IMAP del lado del cliente. [18] Una propuesta privada, push IMAP , ampliaría IMAP para implementar el correo electrónico push enviando el mensaje completo en lugar de solo una notificación. Sin embargo, push IMAP no ha sido generalmente aceptado y el trabajo actual de IETF ha abordado el problema de otras maneras (consulte el Perfil 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 básico requiere transmitir el contenido del mensaje dos veces, una a SMTP para su entrega y una segunda a IMAP para almacenarlo 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 mediante IMAP copiando un mensaje saliente a una carpeta de bandeja de salida dedicada. [19]
Para proteger criptográficamente las conexiones IMAP entre el cliente y el servidor, se puede utilizar IMAPS en el puerto TCP 993, que utiliza SSL/TLS. [2] [3] A partir de enero de 2018, TLS es el mecanismo recomendado. [20]
Como alternativa, se puede utilizar STARTTLS para cifrar la conexión al conectarse al puerto 143 después de comunicarse inicialmente mediante texto sin formato .
Este es un ejemplo de conexión IMAP tomado de la sección 8 del RFC 3501:
C: <abrir conexión>S: * OK Servicio IMAP4rev1 ListoC: a001 inicio de sesión mrc secretoS: a001 OK INICIO DE SESIÓN completadoC:a002 seleccionar bandeja de entradaS: * 18 EXISTES: * BANDERAS (\Respondidas\Marcadas\Eliminadas\Vistas\Borrador)S: * 2 RECIENTESS: * OK [NO VISTO 17] El mensaje 17 es el primer mensaje no vistoS: * OK [UIDVALIDITY 3857529045] UID válidosS: a002 OK [LECTURA-ESCRITURA] SELECCIONAR completadoC: a003 buscar 12 completoS: * 12 FETCH (BANDERAS (\Seen) FECHA INTERNA "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 "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) ((NIL NIL "imap" "cac.washington.edu")) ((NIL NIL "minutos" "CNRI.Reston.VA.US") ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL "<[email protected]>") CUERPO ("TEXTO" "SENCILLO" ("JUEGO DE CARACTERES" "US-ASCII") NULO NULO "7BIT" 3028 92))S: a003 OK FETCH completadoC: a004 buscar 12 cuerpo[encabezado]S: * 12 FETCH (CUERPO[ENCABEZADO] {342}S: S: S: S: S: S : S: S:Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)From: Terry Gray <[email protected]>Subject: IMAP4rev1 WG mtg summary and minutesTo: [email protected]Cc: [email protected], John Klensin <[email protected]>Message-Id: <[email protected]>MIME-Version: 1.0Content-Type: TEXT/PLAIN; CHARSET=US-ASCIIS:S: )S: a004 OK FETCH completadoC a005 almacena 12 +banderas \eliminadoS: * 12 FETCH (BANDERAS (\Visto \Eliminado))S: a005 OK +BANDERAS completadoC: a006 cerrar sesiónS: * BYE El servidor IMAP4rev1 finaliza la conexiónS: a006 OK CERRAR SESIÓN completado
El conocimiento del IMAP original (antes de IMAP2) existe principalmente en mi mente, ya que todas las especificaciones e implementaciones originales de IMAP fueron reemplazadas por IMAP2.
