Protocolo de acceso a mensajes de Internet

En informática, el Protocolo de acceso a mensajes de Internet (IMAP) 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 un protocolo TCP/IP. conexión. IMAP está definido por RFC 9051.

IMAP fue diseñado con el objetivo de permitir la administración completa de un buzón de correo electrónico por parte de múltiples clientes de correo electrónico, por lo tanto, 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 normalmente 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 son compatibles con 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 actual (IMAP4), como se detalla a continuación:

IMAP originales

El protocolo provisional de acceso al correo original se implementó como un cliente de máquina Xerox Lisp 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 se reemplazó rápidamente por el Protocolo interactivo de acceso al correo (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. Se publicó como RFC 1203 en 1991. Se escribió específicamente como una contrapropuesta de RFC 1176, que a su vez proponía modificaciones a IMAP2. IMAP3 nunca fue aceptado por el mercado. El IESG reclasificó RFC1203 "Protocolo interactivo de acceso al correo - Versión 3" como protocolo histórico en 1993. El grupo de trabajo de IMAP utilizó el RFC 1176 (IMAP2) en lugar del RFC 1203 (IMAP3) como punto de partida.

IMAP2bis

Con la llegada de MIME, IMAP2 se amplió para admitir estructuras de cuerpo MIME y agregar funciones de administración de buzones (crear, eliminar, renombrar, cargar mensajes) que no existían en IMAP2. Esta revisión experimental se denominó IMAP2bis; su especificación nunca se publicó en forma de borrador. En octubre de 1993, el grupo de trabajo de IMAP del IETF publicó un borrador en Internet de IMAP2bis. Este borrador se basó en las siguientes especificaciones anteriores: documento IMAP2bis.TXT no publicado, RFC 1176 y RFC 1064 (IMAP2). El borrador IMAP2bis.TXT documentaba 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 el tiempo que se tarda en descargar los mensajes nuevos. 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 menciona específicamente el "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 indicadores definidos en el protocolo IMAP4, los clientes pueden realizar un seguimiento del estado del mensaje: por ejemplo, si el mensaje se ha 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. 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 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 de correo 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 correo nuevo. 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 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 niegan efectivamente 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 los algoritmos de búsqueda y almacenamiento de correo en el servidor se implementen cuidadosamente, un cliente puede 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 una notificación 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 básico requiere transmitir el contenido del mensaje dos veces, una 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 puede 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: Conexión activadaS: * OK IMAP4rev1 Service Ready
C: a001 login mrc secretS: a001 OK L acción completed
C: a002 select inboxS: * 18 EXISTENCIAS
S: * FLAGS (Respuesta Flagged Deleted Seen Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Mensaje 17 es el primer mensaje invisible
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 fullS: * 12 FETCH (Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg resumen y minutos"
(Terry Gray) NIL "gray" "cac.washington.edu")
(Terry Gray) NIL "gray" "cac.washington.edu")
(Terry Gray) NIL "gray" "cac.washington.edu")
(NL NIL "imap" "cac.washington.edu"))
(NIL NIL "minutos" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU") NIL NIL
"Seguido"
ÓRGANO ("TEXTO" "PLAIN" ("CHARSET" "US-ASCII") NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]S: * 12 FETCH (BODY [HEADER] {342}
S: Fecha: Wed, 17 jul 1996 02:23:25 -0700 (PDT)
S: A partir de: Terry Gray
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA. US, John Klensin *KLENSIN@MIT.EDU
S: Message-Id: יB27397-0100000@cac.washington.edu confianza
S: MIME-Version: 1.0
S: Tipo de contenido: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:)
S: a004 OK FETCH completed
C a005 tienda 12 +flags deletedS: * 12 FETCH (FLAGS (Seen Deleted))
S: a005 OK +FLAGS completado
C: a006 logoutS: * BYE IMAP4rev1 servidor que termina la conexión
S: a006 OK LOGOUT completado