Grupo de Trabajo en Red M.Crispin Comentarios: 2060 Universidad de Washington Obsoletos: 1730 Diciembre 1996 Categoría: En proceso de estandarización PROTOCOLO DE ACCESO A MENSAJES DE INTERNET - VERSION 4rev1 Status de este memorándum Este documento especifica un protocolo de Internet en vías de estandarización, y es susceptible de recibir críticas y sugerencias para su mejora. Le remito a la edición actual de "Estándares de Protocolos Oficiales de Internet" para conocer el estado de estandarización y status de este protocolo. La distribución de este memorándum es ilimitada. Resumen El protocolo de acceso a mensajes de Internet, versión 4rev1 (IMAP4rev1) permite a un cliente acceder y manipular los mensajes de correo electrónico contenidos en un servidor. IMAP4rev1 nos permite manipular las carpetas remotas contenedoras de mensajes, llamadas comúnmente "buzones", con una funcionalidad equivalente a la que obtenemos con los contenedores de mensajes locales. IMAP4rev1 también ofrece la posibilidad de que un cliente "offline", establezca una sincronización con el servidor. IMAP4rev1 ofrece además, operaciones para crear, borrar, y renombrar estos buzones; comprobación de nuevos mensajes; borrado permanente de mensajes; establecimiento y borrado de banderas; procesado [RFC-822] y [MIME-IMB];búsqueda genérica; y recuperación selectiva de atributos de mensaje, textos, y porciones de texto. El acceso a mensajes a través de IMAP4rev1 se realiza a través de números. Estos números pueden ser, una secuencia de números, o bien identificadores únicos. IMAP4rev1 da soporte a un único servidor. Para más información acerca de configuraciones pensadas para múltiples servidores le remitimos a [ACAP]. IMAP4rev1 no especifica un medio de distribución de correo; esta función es desempeñada por un protocolo de transferencia de correo como [SMTP]. IMAP4rev1 se ha diseñado para mantener la compatibilidad con los protocolos anteriores partiendo desde [IMAP2] y los protocolos IMAP2bisno publicados. A lo largo del tiempo de vida de IMAP4rev1, algunos aspectos del protocolo inicial han quedado obsoletos. Estos M. Crispin [Pág. 1] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 aspectos, como pueden ser, comandos, respuestas, y formatos de datos con los que trataba IMAP4rev1 en sus versiones más tempranas se describen en [IMAP-OBSOLETE]. Todo lo relacionado con compatibilidades con IMAP2bis, la versión más común del protocolo más primitivo, se discute en [IMAP-COMPAT]. Una discusión más a fondo acerca de los problemas de compatibilidad con variantes poco usadas de IMAP2 se encuentra en [IMAP-HISTORICAL]; este documento es en esencia, de interés histórico. M. Crispin [Pág. 2] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Tabla de contenidos Especificación del protocolo IMAP4rev1 .......................... 3 1. Cómo leer este documento ................................ 4 1.1. Estructura del documento ................................ 4 1.2. Convenciones utilizadas ................................. 4 2. Primer contacto con el protocolo ........................ 5 2.1. Nivel de enlace ......................................... 5 2.2. Comandos y respuestas ................................... 5 2.2.1. Transmisor de protocolo Cliente y Receptor de protocolo Servidor ................................................ 5 2.2.2. Transmisor de protocolo Servidor y Receptor de protocolo Cliente ................................................. 6 2.3. Atributos del mensaje ................................... 7 2.3.1. Números del mensaje ..................................... 7 2.3.1.1. Atributo de mensaje Identificador único ......... 7 2.3.1.2. Atributo de mensaje Número de secuencia de mensaje ......................................... 8 2.3.2. Atributo de mensaje Banderas ............................ 9 2.3.3. Atributo de mensaje Fecha interna ....................... 10 2.3.4. Atributo Tamaño de mensaje .............................. 10 2.3.5. Atributo de mensaje Estructura del envoltorio ........... 10 2.3.6. Atributo de mensaje Estructura del cuerpo ............... 10 2.4. Textos del mensaje ...................................... 10 3. Diagrama de estado y de flujo ........................... 10 3.1. Estado no autentificado ................................. 11 3.2. Estado autentificado .................................... 11 3.3. Estado seleccionado ..................................... 11 3.4. Estado desconexión ...................................... 11 4. Formatos de datos ....................................... 12 4.1. Átomo ................................................... 12 4.2. Número .................................................. 12 4.3. Cadena .................................................. 12 4.3.1 Cadenas binarias y de 8 bits ............................ 13 4.4. Lista entre paréntesis .................................. 13 4.5. NIL ..................................................... 13 5. Consideraciones operacionales ........................... 14 5.1. Dando nombre al buzón ................................... 14 5.1.1. Dando nombre a la jerarquía de buzones .................. 14 5.1.2. Convenciones acerca de la denominación del espacio de nombres de buzón ........................................ 14 5.1.3 Convenciones acerca de la denominación internacional de los buzones .......................................... 14 5.2. Tamaño y actualización del estado de los mensajes en el buzón ................................................... 15 5.3. Respuesta sin comando en progreso ....................... 16 5.4. Contador de desconexión automático ...................... 16 5.5. Múltiples comandos en progreso .......................... 16 M. Crispin [Pág. 3] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 6. Comandos de cliente ..................................... 17 6.1. Comandos de cliente - Estado cualesquiera ............... 17 6.1.1. Comando CAPABILITY ...................................... 18 6.1.2. Comando NOOP ............................................ 18 6.1.3. Comando LOGOUT .......................................... 19 6.2. Comandos de cliente - Estado no autentificado ........... 19 6.2.1. Comando AUTHENTICATE .................................... 20 6.2.2. Comando LOGIN ........................................... 21 6.3. Comandos de cliente - Estado autentificado .............. 21 6.3.1. Comando SELECT .......................................... 22 6.3.2. Comando EXAMINE ......................................... 23 6.3.3. Comando CREATE .......................................... 24 6.3.4. Comando DELETE .......................................... 24 6.3.5. Comando RENAME .......................................... 26 6.3.6. Comando SUBSCRIBE ....................................... 28 6.3.7. Comando UNSUBSCRIBE ..................................... 28 6.3.8. Comando LIST ............................................ 29 6.3.9. Comando LSUB ............................................ 31 6.3.10. Comando STATUS .......................................... 31 6.3.11. Comando APPEND .......................................... 32 6.4. Comandos de cliente - Estado seleccionado ............... 34 6.4.1. Comando CHECK ........................................... 34 6.4.2. Comando CLOSE ........................................... 34 6.4.3. Comando EXPUNGE ......................................... 35 6.4.4. Comando SEARCH .......................................... 36 6.4.5. Comando FETCH ........................................... 39 6.4.6. Comando STORE ........................................... 43 6.4.7. Comando COPY ............................................ 44 6.4.8. Comando UID ............................................. 44 6.5. Comandos de cliente - Experimental/En desarrollo ........ 45 6.5.1. Comando X ......................................... 45 7. Respuestas de servidor .................................. 46 7.1. Respuestas de servidor - Respuestas de estado ........... 47 7.1.1. Respuesta OK ............................................ 49 7.1.2. Respuesta NO ............................................ 49 7.1.3. Respuesta BAD ........................................... 50 7.1.4. Respuesta PREAUTH ....................................... 50 7.1.5. Respuesta BYE ........................................... 50 7.2. Respuestas de servidor - Estados del servidor y del buzón ................................................... 51 7.2.1. Respuesta CAPABILITY .................................... 51 7.2.2. Respuesta LIST .......................................... 52 7.2.3. Respuesta LSUB .......................................... 53 7.2.4. Respuesta STATUS ........................................ 53 7.2.5. Respuesta SEARCH ........................................ 53 7.2.6. Respuesta FLAGS ......................................... 53 7.3. Respuestas de servidor - Tamaño del buzón ............... 54 7.3.1. Respuesta EXISTS ........................................ 54 M. Crispin [Pág. 4] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 7.3.2. Respuesta RECENT ........................................ 54 7.4. Respuestas de servidor - Estado del mensaje ............. 54 7.4.1. Respuesta EXPUNGE ....................................... 54 7.4.2. Respuesta FETCH ......................................... 54 7.5. Respuestas de servidor - Solicitud de continuación de comando ................................................. 61 8. Ejemplo de conexión IMAP4rev1 ........................... 61 9. Sintaxis formal ......................................... 62 10. Notas del autor ......................................... 73 11. Consideraciones de seguridad ............................ 73 12. Dirección del autor ..................................... 73 Apéndices ....................................................... 73 A. Referencias ................................................. 73 B. Variaciones respecto a RFC 1730 ............................. 74 C. Glosario .................................................... 76 M. Crispin [Pág. 5] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Especificación del protocolo IMAP4rev1 1. Cómo leer este documento 1.1. Estructura de este documento Este documento está escrito desde la óptica tanto del implementador del cliente IMAP4rev1 como del servidor IMAPrev1. Más allá del primer contacto tomado en la sección 2, este documento no está dirigido a aquella persona que pretenda comprender el modo de operar de este protocolo. El contenido que va desde la sección 3 hasta la sección 5 expone el contexto general y las definiciones con las que IMAP4rev1 trata. Las secciones 6, 7, y 9 describen los comandos, respuestas, y sintaxis respectivamente de IMAP. La relación existente entre ellos es tal, que es prácticamente imposible comprender cualquiera de ellos por separado. En concreto, no intente comprender la sintaxis de los comandos a partir de la sección de comandos, sino que inténtelo en la sección de sintaxis formal. 1.2. Convenciones utilizadasen este documento Por ejemplo, "C:" y "S:" indica respectivamente, las líneas enviadas por el cliente y las enviadas por el servidor. Los siguientes términos se utilizan en el documento para hacer patentes los requerimientos de esta especificación. 1) DEBE, o el adjetivo REQUERIDO, significa que la definición es un requerimiento imprescindible en la especificación. 2) NO DEBE, la definición está absolutamente prohibida por la especificación. 3) DEBERIA significa que es posible que existan motivos razonables en determinadas circunstancias para ignorar un elemento en particular, pero todas las consecuencias que se derivan de ello deben ser conocidas y sopesadas cuidadosamente antes de actuar de manera diferente. 4) NO DEBERIA significa que es posible que existan motivos razonables en determinadas circunstancias en las cuales el comportamiento concreto sea aceptable o incluso útil, pero las posibles consecuencias DEBERIAN ser conocidas y en su caso sopesadas antes de actuar conforme a un dictado descrito con esta etiqueta. M. Crispin [Pág. 3] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 5) ES POSIBLE, o el adjetivo OPCIONAL, significa que un elemento es de hecho, opcional. Un vendedor puede incluir dicho elemento en un momento dado por los requerimientos del mercado, o también porque cree que potencia el producto, mientras que otro vendedor puede omitir el mismo elemento. Un desarrollo que no incluya una opción en particular DEBE estar preparado para operar con otro desarrollo que sí lo incluya. "Poder" se utiliza en lugar de "Es posible" cuando nos referimos a una situación o circunstancia que es factible que pueda darse, en contraposición a una característica opcional del protocolo. "Usuario" se utiliza para hacer referencia al usuario en cuestión, mientras que "cliente" hace referencia al software utilizado por dicho usuario. "Conexión" hace referencia a la secuencia total de comunicaciones ocurridas desde el establecimiento inicial de la conexión de red hasta su finalización. "Sesión" se refiere a la secuencia de comunicaciones Cliente/servidor a partir del momento en que se selecciona un buzón (comando SELECT o EXAMINE) hasta el momento en que esta selección termina. (SELECT o EXAMINE sobre otro buzón, comando CLOSE, o finalización de la conexión). Se utilizan caracteres de 7 bit US-ASCII salvo que se especifique otro formato diferente. Para utilizar otro conjunto de caracteres se indica usando un "CHARSET", como se describe en [MIME-IMT] y se define en [CHARSET]. Los CHARSETs tienen una semántica adicional importante además de dar la definición de un conjunto de caracteres; para más información le remito a los documentos anteriores. 2. Primer contacto con el protocolo 2.1. Nivel de enlace El protocolo IMAP4rev1 confía en la existencia de un flujo de datos estable, como los suministrados por TCP. Cuando utilizamos TCP, un servidor IMAP4rev1 escucha el puerto 143. 2.2. Comandos y respuestas Una conexión IMAP4rev1 consiste en el establecimiento de una conexión de red cliente/servidor, un reconocimiento inicial por parte del servidor, y una serie de comunicaciones cliente/servidor. Estas comunicaciones consisten en un comando de cliente, datos del servidor, y una respuesta por parte del servidor de transferencia completada. M. Crispin [Pág. 4] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 La comunicación entre cliente y servidor se realiza en forma de líneas; es decir, cadenas que terminan con un CTRLF. El receptor de protocolo del cliente o servidor IMAP4rev1 lleva a cabo o la lectura de una línea, o bien la lectura de una secuencia de octetos con un contador conocido seguido de una línea. 2.2.1. Transmisor de protocolo cliente y Receptor de protocolo servidor El comando de cliente da comienzo a una operación. A cada comando de cliente se le asigna un prefijo consistente en un identificador (normalmente una cadena corta de caracteres alfanuméricos, p.ej. A0001, A0002, etc.) llamado "etiqueta". El cliente asigna a cada comando una etiqueta diferente. Hay dos casos, en los cuales una línea de cliente no representa un comando completo. En primer lugar, un argumento del comando está dotado de un número de octetos (ver la descripción de literal en Cadena en Formato de Datos); en segundo lugar, los argumentos del comando requieren una realimentación por parte del servidor (ver el comando AUTHENTICATE). En ambos casos, el servidor envía una respuesta de solicitud de continuación del comando si este está preparado para recibir los octetos (si es lo adecuado) y el recordatorio del comando. Esta respuesta viene precedida del token"+". Nota: Si en su caso, el servidor detecta un error en el comando, envía una respuesta de transacción errónea con la etiqueta que corresponde con el comando (como se describe abajo) para rechazar el comando, y con ello evita que el cliente envíe más información del comando. Es posible que el servidor envíe una respuesta de transacción completa para otros comandos (si hay varios comandos en progreso), o datos no etiquetados. En cualquier caso, la solicitud de continuación de comando está todavía pendiente; el cliente actúa de manera adecuada a la respuesta, y lee otra respuesta del servidor.En todos los casos, el cliente DEBE enviar un comando completo (incluyendo la recepción de todas las respuestas de solicitud de continuación de comando y las continuaciones de comando para dicho comando) antes de inicializar un nuevo comando. El receptor de protocolo de un servidor IMAP4rev1 lee una línea de comando desde el cliente, analiza el comando y sus argumentos, y transmite los datos del servidor y una respuesta de transacción completa de comando. M. Crispin [Pág. 5] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 2.2.2. Transmisor de protocolo servidor y Receptor de protocolo cliente Los datos transmitidos por el servidor hacia el cliente y las respuestas de estado que no indiquen el procesado completo del comando van precedidas del token "*", y se denominan respuestas no etiquetadas. Los datos del servidor ES POSIBLE que sean enviados como resultado de un comando del cliente, o ES POSIBLE que sean enviados de forma unilateral por el servidor. No hay diferencia sintáctica entre los datos enviados como resultado de un comando del cliente y los enviados de forma unilateral por el servidor. La respuesta de transacción completa por parte del servidor indica el éxito o fracaso de la operación. Esta es etiquetada con la misma etiqueta con la que el comando del cliente comenzó la operación. Por tanto, si hay más de un comando en progreso, la etiqueta de una respuesta de transacción completa de un servidor identifica al comando al cual corresponde la respuesta. Hay tres posibles respuestas de transacción completa por parte del servidor: OK (indica éxito), NO (indica fracaso), o BAD (indica un error de protocolo tal como comando no reconocido o error de sintaxis para el comando). El receptor de protocolo cliente IMAP4rev1 lee una línea de la respuesta enviada por el servidor. Después, lleva a cabo una acción en función de dicha respuesta basándose en el primer token que constituya la misma, esta puede ser una etiqueta, un "*" o un "+". Un cliente DEBE estar preparado para recibir cualquier número de respuestas por parte del servidor en cualquier momento. Esto incluye datos del servidor que no fueron solicitados. Estos datos DEBERIAN ser almacenados, para que el cliente pudiera hacer una referencia a la copia ya almacenada de esos datos, evitando así enviar un comando al servidor para solicitar dichos datos. Ciertos datos enviados por el servidor DEBEN ser almacenados. Este asunto se discute con más detalle en la sección Respuestas de Servidor. 2.3. Atributos del Mensaje. Además del texto del mensaje, cada uno de los mensajes posee M. Crispin [Pág. 6] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 una serie de atributos. Estos atributos se pueden recuperar individualmente o en conjunción con otros atributos o textos del mensaje. 2.3.1. Números del Mensaje. Para tener acceso a los mensajes en IMAP4rev1 se utilizan uno de los siguientes números; el identificador único y el número de secuencia del mensaje. 2.3.1.1. Atributo de mensaje Identificador Único (UID) Asignamos a cada mensaje un valor de 32 bit, junto con el valor de vigencia de identificador único obtenemos un valor de 64 bit, con lo cual garantizamos que hacemos referencia al mensaje en concreto y no a cualquier otro presente en el buzón. Los identificadores únicos se asignan en el buzón en orden ascendente; de forma que cualquier mensaje que llegue al buzón recibirá un UID mayor que el identificador asignado al mensaje recibido justo antes que él. Al contrario que los números de secuencia de mensaje, los identificadores únicos no son necesariamente contiguos. Los identificadores únicos también permanecen a lo largo de sesiones diferentes. Esto permite al cliente resincronizar su estado partiendo desde una sesión previa con el servidor. (p.ej. clientes "offline" o desconectados); esto se discute más ampliamente en [IMAP-DISC]. Todo buzón lleva asociado un valor de vigencia de identificador único, el cual se envía en un código de respuesta UIDVALIDITY dentro de una respuesta de tipo OK no etiquetada en tiempo de selección del buzón. Si algún identificador único de una sesión anterior pierde su vigencia en la sesión actual, el valor de vigencia de identificador único DEBE ser mayor que el usado en la sesión anterior. Nota: los identificadores únicos DEBEN seguir un orden ascendente en todo momento en la estructura del buzón. Si el almacén físico de mensajes es reordenado por un agente no-IMAP, es preciso que los identificadores únicos del buzón sean regenerados, ya que los primeros identificadores únicos no mantendrán el orden ascendente como resultado de la reorganización. Otra situación en la cual se puede producir una reorganización del buzón es aquella en la que el buzón no disponga de un mecanismo para almacenar identificadores únicos. Aunque esta M. Crispin [Pág. 7] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 especificación reconoce que esto pueda darse en ciertos entornos de servidor, se RECOMIENDA ENCARECIDAMENTE que el almacén de mensajes implemente técnicas que eviten este problema. Otro causa de no persistencia ocurre si se elimina el buzón y se crea posteriormente uno nuevo con el mismo nombre. Puesto que el nombre es el mismo, puede suceder que el cliente no sepa que dispone de un nuevo buzón a menos que la vigencia del identificador único sea diferente. Una buena práctica consiste en asignar al valor de vigencia de identificador único una representación en 32 bit de la hora/fecha de creación de dicho buzón. Es igualmente correcto, usar una constante como 1, pero únicamente si está garantizado que estos identificadores sean únicos, incluso en el caso de que se borre el buzón y se vuelva a crear uno nuevo con el mismo nombre en una fecha posterior. El identificador de usuario de un mensaje NO DEBE cambiarse a lo largo de la sesión, y NO DEBERIA ser cambiado entre sesiones. Sin embargo, si no es posible preservar el identificador único de un mensaje en una sesión posterior, cada sesión posterior DEBE tener un nuevo valor de vigencia de identificador único que sea mayor que cualquiera de los ya usados previamente. 2.3.1.2. Atributo de mensaje Número de secuencia de mensaje Posición relativa desde 1 al número de mensajes en el buzón. Esta posición DEBE estar ordenada ascendentemente por identificador único. Conforme se añadan nuevos mensajes, se le asignará a cada uno un número de secuencia de mensaje que sea una unidad mayor que el número total de mensajes presentes previamente en el buzón. Los números de secuencia de mensaje pueden ser reasignados a lo largo de la sesión. Por ejemplo, cuando se borra definitivamente un mensaje del buzón (tachado), el número de secuencia de mensaje para los mensajes posteriores se ve decrementado. De la misma manera, un mensaje nuevo puede recibir un número de secuencia de mensaje asignado a otro mensaje antes de su eliminación. Además de tener acceso a los mensajes por su posición relativa en el buzón, los números de secuencia de mensaje pueden ser usados en cálculos matemáticos. Por ejemplo, si M. Crispin [Pág. 8] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 se recibe un "EXISTS 11" no etiquetado, y anteriormente recibimos un "8 EXISTS" no etiquetado, hemos recibido tres nuevos mensajes con números de secuencia de mensaje 9,10 y 11 respectivamente. Otro ejemplo; si el mensaje 287 almacenado en un buzón contenedor de 523 mensajes tiene un identificador 12345, hay exactamente 286 mensajes poseen un UID menor y 236 mensajes que tienen un UID mayor. 2.3.2. Atributo de mensaje Banderas Lista de cero o más tokens dotados de nombre asociados con el mensaje. Una bandera se establece añadiéndola a dicha lista, y se elimina borrándola de la misma. Hay dos tipos de banderas en IMPA4rev1. Una bandera sea cual sea su tipo puede ser permanente o de sesión única. Una bandera de sistema es un nombre de bandera que viene predefinida en esta especificación. Todas las banderas de sistema vienen precedidas de "\". Ciertas banderas de sistema (\Deleted y \Seen) tienen una semántica especial descrita en otra sección. Las banderas de sistema definidas actualmente son: \Seen El mensaje ha sido leído \Answered El mensaje ha sido respondido \Flagged El mensaje está "reseñado" por merecer una atención especial o urgente \Deleted El mensaje está "borrado" para ser eliminado posteriormente mediante EXPUNGE \Draft El mensaje está inacabado \Recent El mensaje ha llegado recientemente al buzón. Esta sesión es la primera en la que se notificará la llegada de este mensaje, en sesiones posteriores este flag será deshabilitado para este mensaje en concreto. Este flag no puede ser modificado por el cliente. Si no es posible saber si esta sesión es la primera sesión en la que se deba notificar la llegada del mensaje, entonces este debería ser considerado como reciente. M. Crispin [Pág. 9] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Si varias conexiones han seleccionado el mismo buzón simultáneamente, será impredecible saber cual de ellas verá los mensajes nuevos con la bandera \Recent activada y cual de ellas la verán desactivada. Una clave se define por la implementación del servidor. Las claves no comienzan con "\". Los servidores ES POSIBLE que permitan al cliente definir nuevas claves en el buzón. (Ver la descripción del código de respuesta PERMANENTFLAGS para más información). Una bandera puede ser permanente o de sesión única partiendo de una base por-bandera. Las banderas permanentes son aquellas que el cliente puede añadir o eliminar de las banderas del mensaje de forma permanente; es decir, las sesiones posteriores serán conscientes de cualquier cambio en estas banderas permanentes. Los cambios realizados sobre las banderas de sesión sólo serán válidos en esa sesión en concreto. Nota: La bandera de sistema \Recent es un caso especial de una bandera de sesión. \Recent no puede ser utilizado como argumento en un comando STORE, y por tanto no se puede cambiar. 2.3.3. Atributo de mensaje Fecha interna La fecha y hora interna del mensaje en el servidor. Esta no es la fecha y hora de la cabecera [RFC-822], sino que es una fecha y una hora que refleja el momento de recepción del mensaje. En el caso de mensajes distribuidos vía [SMTP], DEBERIA ser la fecha y hora de distribución final del mensaje como se define por [SMTP]. En el caso de los mensajes enviados mediante el comando COPY de IMAP4rev1, esta DEBERIA ser la fecha y hora interna del mensaje origen. En el caso de ser enviado mediante el comando APPEND de IMAPrev1, esta DEBERIA ser la fecha y hora especificada en la descripción del comando APPEND. En cualquier otro caso está definida por la implementación. 2.3.4. Atributo Tamaño de mensaje [RFC-822] Número de octetos del mensaje, como se expresa en el formato [RFC-822]. 2.3.5. Atributo de mensaje Estructura del envoltorio M. Crispin [Pág. 10] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Una representación procesada acerca de la información de envoltorio [RFC-822] (no confundir con un envoltorio [SMTP]) del mensaje. 2.3.6. Atributo de mensaje Estructura del cuerpo Una representación procesada de la información sobre la estructura del cuerpo del mensaje [MIME-IMB]. 2.4. Textos del mensaje Además de ser capaz de recuperar todo el texto [RFC-822] de un mensaje, IMAP4rev1 permite la recuperación de fragmentos del texto completo del mensaje. En concreto, es posible recuperar la cabecera del mensaje [RFC-822], el cuerpo del mensaje [RFC-822], una sección del cuerpo [MIME-IMB], o una cabecera [MIME-IMB]. 3. Diagrama de estado y de flujo Un servidor IMAP4rev1 puede encontrarse en cuatro estados. La mayoría de los comandos son válidos únicamente en ciertos estados. Es un error de protocolo de parte del cliente intentar ejecutar un comando mientras este no se encuentra en el estado apropiado. En este caso, un servidor responderá con un resultado de fin de procesado de comando BAD o NO (dependiendo de la implementación del servidor). 3.1. Estado no autentificado En este estado, el cliente DEBE suministrar credenciales de autentificación antes de que la mayoría de los comandos puedan ser aceptados. Este estado se alcanza cuando comienza la conexión salvo que la conexión haya sido pre-autentificada. 3.2. Estado autentificado En este estado, el cliente está autentificado y DEBE seleccionar un buzón antes de que se le permita utilizar cualquier comando que afecte a los mensajes contenidos en el mismo. Este estado se alcanza cuando comienza una conexión pre-autentificada, cuando se suministran credenciales de autentificación válidas, o tras un error debido a la selección de un buzón. 3.3. Estado seleccionado En este estado, se ha seleccionado un buzón al que acceder. M. Crispin [Pág. 11] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Este estado se alcanza cuando la selección del buzón es aceptada. 3.4. Estado desconexión En este estado, la conexión está en proceso de finalización, y el servidor cerrará la conexión. Este estado puede alcanzarse como resultado de la petición del cliente o por decisión unilateral del servidor. M. Crispin [Pág. 12] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 +------------------------------------------------+ | conexión inicial y reconocimiento del servidor | +------------------------------------------------+ | | (1) | | (2) | |(3) V V | | | | | | | | +------------------+ | | | | |no autentificado | | | | | +------------------+ | | | | | | (7) | | (4) | | | | | | V V V V | | | | +----------------------+ | | | | | autentificado |<=++ | | | | +----------------------+ || | | | | | | (7) | | (5) ||(6) | | | | | | V V || | | | | | | +------------+ || | | | | | | |seleccionado|<==++ | | | | | | +------------+ | | | | | | | | (7) | | V V V V V V V V +------------------------------------------------+ | desconexión y cierre de la conexión | +------------------------------------------------+ (1) Conexión sin pre-autentificación (reconocimiento OK) (2) Conexión pre-autentificada (reconocimiento PREAUTH) (3) Conexión rechazada (reconocimiento BYE) (4) LOGIN aceptado o comando AUTHENTICATE (5) SELECT aceptado, o comando EXAMINE (6) Comando CLOSE, o SELECT rechazado o comando EXAMINE (7) Comando LOGOUT, apagado del servidor, o conexión cerrada 4. Formatos de datos IMAP4rev1 utiliza comandos y respuestas en formato texto. Los datos en IMAP4rev1 pueden encontrarse en una de estas cuatro formas: átomo, número, cadena, lista entre paréntesis, o NIL. 4.1 Átomo Un átomo está constituido de uno o más caracteres no especiales. 4.2. Número Un número está constituido de uno o más caracteres numéricos, M. Crispin [Pág. 11] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 y representa un valor numérico. 4.3. Cadena Una cadena puede encontrarse en dos formatos: literal o cadena entre comillas. El literal es la forma genérica de una cadena. La cadena entre comillas es una alternativa que evita la sobrecarga provocada por el procesamiento realizado sobre un literal, como contrapartida tenemos una limitación en cuanto al número de caracteres que pueden utilizarse en una cadena entre comillas. Un literal es una secuencia de cero o más octetos (incluyendo CR y LF), precedida de un prefijo que encierra una cifra de octetos con el siguiente formato: una llave abierta ("{"), el número de octetos, llave cerrada ("}"), y CRLF. En el caso de los octetos transmitidos desde el servidor al cliente, los datos del octeto van directamente tras el CRFL. En el caso de los octetos transmitidos desde el cliente al servidor, el cliente DEBE esperar a recibir por parte del servidor una solicitud de continuación de comando (esto se explicará más adelante) previo al envío de los datos del octeto. (y el recordatorio del comando). Una cadena entre comillas es una secuencia de cero o más caracteres 7-bit, excluyendo CR y LF, con comillas dobles (<">) al principio y al final.La cadena vacía se representa como "" (una cadena entre comillas con cero caracteres entre comillas dobles) o como {0} seguido de CRLF (un literal con una cifra de octetos igual a cero). Nota: Incluso si la cifra de octetos es igual a 0, un cliente que transmita un literal DEBE esperar a recibir una solicitud de continuación de comando. 4.3.1. Cadenas binarias y de 8-bit El correo en formato binario y texto de 8-bit se transmite a través del uso de la codificación de transferencia de contenido [MIME-IMB]. Para las implementaciones IMAP4rev1 ES POSIBLE transmitir caracteres de 8-bit o multi-octetos incluidos en literales, pero únicamente debería hacerse cuando el CHARSET se conoce y está identificado. Aunque está definida una codificación para el cuerpo en BINARIO, no se permiten cadenas binarias no codificadas. Una "cadena en binario" es una cadena con caracteres NUL. Las implementaciones DEBEN codificar los datos binarios en una M. Crispin [Pág. 12] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 representación tipo texto tales como BASE64 antes de que los datos sean transmitidos. Una cadena que contenga una cantidad excesiva de caracteres CTL ES POSIBLE que sea considerada como binaria. 4.4. Lista entre paréntesis Las estructuras de datos se representan mediante "listas entre paréntesis"; una secuencia de elementos de datos, delimitados por un espacio, y encerrados al principio y al final por paréntesis. Una lista entre paréntesis puede contener otras listas entre paréntesis, haciendo uso así de múltiples niveles de paréntesis para constituir anidamiento. La lista vacía se representa por () -- una lista entre paréntesis sin elementos. 4.5. NIL El átomo especial "NIL" representa la no existencia de un determinado elemento de datos, el cual viene definido como cadena o como lista entre paréntesis, siendo diferente de la cadena vacía "" o de la lista entre paréntesis vacía (). 5. Consideraciones operacionales 5.1. Dando nombre al buzón La interpretación de los nombres de buzón es una interpretación dependiente de la implementación. Sin embargo, el nombre de buzón no sensible a mayúsculas-minúsculas denominado INBOX es un nombre especial que representa "el buzón principal para este usuario en este servidor". 5.1.1. Dando nombre a la jerarquía de buzones Es deseable que los nombres jerárquicos utilizados en los buzones se exporten, los nombres de los buzones DEBEN ser jerárquicos de izquierda a derecha utilizando un único carácter para separar distintos niveles de la jerarquía. Se utiliza un único carácter separador para la jerarquía en todos los niveles de la misma en el ámbito de un mismo nombre. 5.1.2. Convenciones acerca de la denominación del espacio de M. Crispin [Pág. 13] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 nombres de buzón Por convención, el primer elemento de la jerarquía de cualquier nombre de buzón que comience con "#" identifica el "espacio de nombres" del recordatorio del nombre. Esto hace posible la distinción entre diferentes tipos de almacén de buzones, cada uno de ellos con sus propios espacios de nombre. Por ejemplo, las implementaciones que ofrecen acceso a los grupos de noticias USENET ES POSIBLE que utilicen el espacio de nombres "#news" para separar el espacio de nombres del grupo de noticias USENET de otros buzones de correo. Por tanto, el grupo de noticias "#news.comp.mail.misc", y el nombre "comp.mail.misc" podrían hacer referencia a objetos diferentes. (p.ej. el buzón de correo privado de un usuario). 5.1.3. Convenciones acerca de la denominación internacional de los buzones Por convención, los nombres internacionales de buzón vienen especificados por el uso de una versión modificada de la codificación UTF-7 descrita en [UTF-7]. El propósito de estas modificaciones está dirigido a corregir, utilizando UTF-7, los problemas que se explican a continuación: 1) UTF-7 usa el carácter "+" para espaciado; esto entra en conflicto con el uso común de "+" en los nombres de los buzones, en particular con los nombres de grupos de noticias de USENET. 2) La codificación UTF-7 es BASE64, la cual utiliza el carácter "/"; esto entra en conflicto con el uso de "/" como conocido constructor de jerarquías. 3) UTF-7 prohibe el uso decodificado de "\"; ya que entra en conflicto con el uso de "\" como conocido constructor de jerarquías. 4) UTF-7 prohibe el uso decodificado de "~"; ya que entra en conflicto con el uso de "~" en algunos servidores como indicador de directorio home. 5) UTF-7 permite múltiples maneras para representar la misma cadena; en particular, los caracteres imprimibles US-ASCII pueden ser representados en forma codificada. M. Crispin [Pág. 14] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 En el UTF-7 modificado los caracteres US-ASCII imprimibles salvo el "&"representan el mismo carácter; es decir, los caracteres con valores de octeto 0x20-0x25 y 0x27-0x7e. El carácter "&" (0x26) se representa por la secuencia de dos octetos "&-". Otros caracteres (valores de octeto 0x00-0x1f, 0x7f-0xff, y todos los octetos de 16-bit Unicode) se representan en BASE64 modificado, con una modificación más profunda de [UTF-7], en la que "," se utiliza en lugar de "/". El BASE64 modificado NO DEBE usarse para representar ningún carácter imprimible US-ASCII que pueda representarse por sí mismo. "&" se utiliza para activar el BASE64 modificado y "-" para volver al US-ASCII, y DEBE terminar en US-ASCII (un nombre que finalice con un octeto 16-bit Unicode DEBE terminar con un "-"). Por ejemplo, aquí tenemos un nombre de buzón de correo que mezcla Inglés, Japonés y texto Chino: ~peter/mail/&ZeVnLIqe-/&U,BTFw- 5.2 Tamaño y actualización del estado de los mensajes en el buzón En cualquier momento un servidor puede enviar datos que el cliente no solicitó. En algunas ocasiones, este comportamiento es OBLIGATORIO. Por ejemplo, otros agentes aparte del servidor ES POSIBLE que añadan mensajes en el buzón de correo (p.ej. nueva distribución de correo), cambiar el estado de las banderas del mensaje presente en el buzón de correo. (p.ej. acceso por parte de múltiples agentes al mismo buzón de correo), o incluso eliminar mensajes del buzón de correo. Un servidor DEBE enviar automáticamente actualizaciones acerca del tamaño del buzón si su tamaño varía durante el procesamiento de un comando. Un servidor DEBERIA enviar automáticamente actualizaciones acerca de las banderas del mensaje, sin necesidad de que el cliente tenga que solicitarlo explícitamente. Existen reglas especiales para que el servidor notifique al cliente la eliminación o borrado de mensajes para evitar errores de sincronización; ver la descripción de la respuesta EXPUNGE para más información. Sean cuales sean las decisiones de implementación que un cliente establezca para la memorización de datos desde el servidor, cualquier implementación de cliente DEBE registrar las actualizaciones del tamaño del buzón de correo. No DEBE asumirse que cualquier comando ejecutado tras la selección M. Crispin [Pág. 15] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 inicial del buzón de correo devolverá el tamaño de dicho buzón. 5.3. Respuesta sin comando en progreso Las implementaciones de servidor permiten enviar respuestas no etiquetadas (salvo para EXPUNGE) mientras no exista un comando en progreso. Estas implementaciones DEBEN tomar consideraciones acerca del flujo de control. Especialmente, DEBEN o (1) verificar que el tamaño de los datos no excedan el tamaño de ventana de transporte subyacente, o (2) usen escrituras sin bloqueo. 5.4. Contador de desconexión automática Si un servidor dispone de un contador de inactividad de desconexión automática, este DEBE ser de al menos 30 minutos de duración. La recepción de un comando enviado por el cliente durante este intervalo DEBERIA suponer la inicialización de dicho contador. 5.5 Múltiples comandos en progreso El cliente ES POSIBLE que envíe cualquier comando sin necesidad de tener que esperar a la respuesta de resultado tras el procesado completo de un comando, sujetos a las reglas de ambigüedad y restricciones de control de flujo del flujo de datos subyacente. De la misma manera, un servidor ES POSIBLE que comience a procesar otro comando antes de que el tiempo de procesado del comando actual termine, sujeto a las reglas de ambigüedad. Sin embargo, cualquier respuesta de solicitud de continuación de comando y continuación de comandos DEBE ser tratado antes de que cualquier comando posterior sea iniciado. La excepción surgiría si hubiera ambigüedad como resultado de que un comando afectara a los resultados de otros comandos. Los clientes NO DEBEN enviar múltiples comandos sin esperar que pueda darse ambigüedad. Si el servidor detecta una posible ambigüedad, DEBE ejecutar comandos para mantener la integridad en el orden dado por el cliente. El ejemplo más claro de ambigüedad es cuando un comando afecta el resultado de otro; por ejemplo, un FETCH sobre las banderas de un mensaje y un STORE sobre las mismas banderas de dicho mensaje. Una situación de ambigüedad no tan clara ocurre con aquellos M. Crispin [Pág. 16] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 comandos que permiten una respuesta EXPUNGE no etiquetada (comandos diferentes a FETCH, STORE, y SEARCH), ya que una respuesta EXPUNGE no etiquetada puede invalidar números de secuencia de un comando posterior. Esto no supone un problema para los comandos FETCH, STORE, o SEARCH puesto que a los servidores no les está permitido enviar respuestas EXPUNGE mientras está en progreso cualquiera de estos comandos. Por tanto, si el cliente envía un comando que no sea FETCH, STORE o SEARCH, DEBE esperar una respuesta antes deenviar un comando con números de secuencia de mensaje. Por ejemplo, las siguientes secuencias de comando sin espera no son válidas: FETCH + NOOP + STORE STORE + COPY + FETCH COPY + COPY CHECK + FETCH Los siguientes son ejemplos de secuencias de comando sin espera válidas: FETCH + STORE + SEARCH + CHECK STORE + COPY + EXPUNGE 6. Comandos de cliente En esta sección se detallan los comandos IMAP4rev1. Los comandos se organizan en función del estado en el cual está permitida su ejecución. Los comandos que puedan utilizarse en varios estados se listan en el estado mínimo permitido. (por ejemplo, los comandos válidos en los estados autentificado y seleccionado se listan entre los comandos permitidos en el estado autentificado). Los argumentos de comando, identificados por "Argumentos:" en las descripciones de los comandos situadas más abajo, se describen por su función, no por su sintaxis. La sintaxis precisa de los argumentos de cada comando se describe en la sección Sintaxis Formal. Algunos comandos provocan la devolución de determinadas respuestas por parte del servidor; estas se identifican por "Respuestas:" en la descripciones de los comandos situadas más abajo. Para más información acerca de estas respuestas y sus descripciones diríjase a la sección de Respuestas, y a la sección de Sintaxis Formal en caso de que desee conocer más a fondo la sintaxis de estas respuestas. Es posible que M. Crispin [Pág. 17] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 se transmitan datos del servidor como resultado de la ejecución un comando; por tanto, para comandos que no requieran datos del servidor especifique "no respuestas específicas para este comando" en lugar de especificar "ninguna". "Result:" en la descripción de comandos se refiere a las posibles respuestas de estado etiquetadas para un comando, y cualquier otra interpretación especial de estas respuestas de estado. 6.1. Comandos de cliente - Estado cualesquiera Los siguientes comandos son perfectamente válidos en cualquiera de los estados: CAPABILITY, NOOP, y LOGOUT. 6.1.1.Comando CAPABILITY Argumentos: ninguno Respuestas: respuesta no etiquetada REQUERIDA: CAPABILITY Resultado: OK comando CAPABILITY completado BAD comando desconocido o argumentos no válidos El comando CAPABILITY solicita un listado de todas las aptitudes de que dispone el servidor. El servidor DEBE enviar una respuesta CAPABILITY no etiquetada incluyendo entre la lista de aptitudes "IMAP4rev1" antes de la respuesta (etiquetada) OK. Este listado de aptitudes no depende del estado de la conexión o del usuario. Por lo tanto, no es necesario elaborar un comando CAPABILITY más de una vez por conexión. Un nombre de aptitud que comience con "AUTH=" indica que el servidor dispone de este mecanismo de autentificación en particular. Tales nombres son, por definición, parte de esta especificación. Por ejemplo, la aptitud de autorización para un autentificador experimental llamado blurdybool sería "AUTH=BLURDYBLOOP" y no " XAUTH=BLURDYBLOOP" o "XAUTH=XBLURDYBLOOP". Otros nombres de aptitud se refieren a extensiones, revisiones, o añadidos a esta especificación. Para más información diríjase a la documentación referente a la respuesta CAPABILITY. No hay aptitudes más allá del M. Crispin [Pág. 18] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 conjunto IMAP4rev1 base definido en esta especificación, que puedan invocar la aptitud sin una acción especifica del cliente que la invoque. Ver la sección titulada "Comandos de Cliente - Experimental/En Desarrollo" para más información acerca de las aptitudes específicas de cada implementación. Ejemplo: C: abcd CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 S: abcd OK CAPABILITY completado 6.1.2. Comando NOOP Argumentos: ninguno Respuestas: no hay respuestas especificas para este comando Resultado: OK noop completado BAD comando desconocido o argumentos no válidos El comando NOOP siempre se ejecuta correctamente. No hace nada. Puesto que un comando puede devolver como dato no etiquetado una actualización de estado, el comando NOOP puede ser utilizado como un centinela permanente para comprobación de nuevos mensajes o de actualizaciones sobre el estado de los mensajes durante un periodo de inactividad. El comando NOOP también se puede utilizar para inicializar cualquier contador de desconexión por inactividad presente en el servidor. Ejemplo: C: a002 NOOP S: a002 OK NOOP completada . . . C: a047 NOOP S: * 22 EXPUNGE S: * 23 EXISTS S: * 3 RECENT S: * 14 FETCH (FLAGS (\Seen \Deleted)) S: a047 OK NOOP completada 6.1.3. Comando LOGOUT M. Crispin [Pág. 19] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Argumentos : ninguno Respuestas: respuesta no etiquetada OBLIGATORIA : BYE Resultado: OK logout completado BAD comando desconocido o argumentos no válidos El comando LOGOUT informa al servidor de que el cliente ha conseguido conectarse. El servidor DEBE enviar una respuesta no etiquetada BYE antes de la respuesta (etiquetada) OK, y a continuación cerrar la conexión de red. Ejemplo: C: A023 LOGOUT S: * BYE IMAP4rev1 servidor cerrando conexión S: A023 OK LOGOUT completado (Servidor y cliente cierran la conexión) 6.2. Comandos de cliente - Estado no autentificado En el estado no autentificado, el comando AUTHENTICATE o LOGIN establece la autentificación y nos introduce en un estado autentificado. El comando AUTHENTICATE ofrece un mecanismo global para una gran variedad de técnicas de autentificación, mientras que el comando LOGIN hace uso del par nombre de usuario tradicional y contraseña de texto plano. Las implementaciones de servidor ES POSIBLE que permitan un acceso no autentificado a ciertos buzones de correo. Por convención se utiliza un comando LOGIN con el identificador de usuario "anonymous". Se REQUIERE una contraseña. Es dependiente de la implementación, en cuanto a requerimientos, si hay alguno, están en función de la clave y en cuanto a las restricciones de acceso se establecen en los usuarios anónimos. Una vez autentificado (incluyendo al acceso anónimo), no es posible volver al estado no autentificado. Además de los comandos universales (CAPABILITY, NOOP, y LOGOUT), los siguientes comandos son considerados válidos en el estado no autentificado: AUTHENTICATE y LOGIN. 6.2.1. Comando AUTHENTICATE Argumentos: nombre del mecanismo de autentificación M. Crispin [Pág. 20] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Respuestas: puede solicitarse una continuación de datos Resultado: OK autentificación completada, ahora estado autentificado NO fallo de autentificación: mecanismo de autentificación no soportado, credenciales rechazadas BAD comando desconocido o argumenttos no válidos, transacción de autentificación cancelada. El comando AUTHENTICATE indica un mecanismo de autentificación, tal y como se describe en [IMAP-AUTH], al servidor. Si el servidor soporta dicho mecanismo de autentificación, lleva a cabo una transacción de protocolo de autentificación e identifica al cliente. Es POSIBLE manejar un mecanismo de protección OPCIONAL para sucesivas interacciones del protocolo. Si no está soportado dicho mecanismo de autentificación, el servidor DEBERIA rechazar el comando AUTHENTICATE enviando una respuesta NO no etiquetada. El intercambio de protocolo de autentificación consiste de una serie de desafíos de servidor y respuestas del cliente que son específicos del mecanismo de autentificación. Un desafío de servidor consiste en una respuesta de solicitud de continuación de comando con el token "+" seguido de una cadena codificada en BASE64. La respuesta del cliente consiste en una línea constituida de una cadena codificada en BASE64. Si el cliente desea cancelar una transacción de autentificación, elabora una línea con un "*". Si el servidor recibe tal respuesta, DEBE rechazar el comando AUTHENTICATE enviando una respuesta BAD etiquetada. Un mecanismo de protección ofrece una capa de protección sobre la integridad y privacidad de la conexión. Si se utiliza un mecanismo de protección, este se aplica a todos los datos enviados en sucesivas transmisiones en uso de la conexión actual. Este mecanismo de protección se activa justo a continuación del CRLF que finaliza la transacción de autentificación del cliente, y justo después del CRLF de la respuesta OK etiquetada por parte del servidor. Una vez que el mecanismo de protección está en acción, el flujo de comandos y octetos de respuesta se procesan dentro de buffers de texto cifrado. Cada uno de los buffers se transmiten a lo largo de la conexión como flujos de octetos precedidos de un campo de cuatro octetos en orden de byte de red que representan la longitud del dato siguiente. La longitud máxima del buffer de M. Crispin [Pág. 21] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 texto cifrado viene definido por el mecanismo de protección. Los mecanismos de autentificación son OPCIONALES. Los mecanismos de protección son también OPCIONALES; un mecanismo de autentificación ES POSIBLE que se implemente sin ningún mecanismo de protección. Si un comando AUTHENTICATE falla con la devolución de una respuesta NO, el cliente ES POSIBLE que intente otro mecanismo de autentificación elaborando otro comando AUTHENTICATE, o ES POSIBLE que intente la autentificación mediante la utilización del comando LOGIN. En otras palabras, el cliente ES POSIBLE que solicite tipos de autentificación en orden de precedencia decreciente, con el comando LOGIN como último recurso. Ejemplo: S: * OK KerberosV4 IMAP4rev1 Servidor C: A001 AUTHENTICATE KERBEROS_V4 S: + AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: A001 OK Kerberos V4 autentificación conseguida. Nota: los espacios en blanco en la primera respuesta del cliente se utilizan en mor de la claridad editorial y no se utilizan en autentificadores reales. 6.2.2. Comando LOGIN Argumentos: nombre de usuario contraseña Respuestas: no hay respuestas especificas para este comando Resultado: OK login completado, ahora en estado autentificado NO login fallido: nombre de usuario o contraseña rechazados BAD comando desconocido o argumentos no válidos El comando LOGIN identifica el cliente al servidor y se hace cargo de la clave en texto plano autentificando al usuario. Ejemplo: C: a001 LOGIN SMITH SESAME M. Crispin [Pág. 22] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 S: a001 OK LOGIN completado 6.3. Comandos de cliente - Estado autentificado En el estado autentificado, se permite utilizar los comandos que manipulan el buzón de correo como entidades atómicas. De entre estos comandos, los comandos SELECT y EXAMINE seleccionarán un buzón de correo para conseguir acceso y entrada al estado seleccionado. Además de los comandos universales (CAPABILITY, NOOP, y LOGOUT), los comandos que vemos a continuación son válidos en el estado autentificado: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, y APPEND. 6.3.1. Comando SELECT Argumentos: nombre del buzón de correo Respuestas: respuestas no etiquetadas OBLIGATORIAS: FLAGS, EXISTS, RECENT respuestas no etiquetadas OPCIONALES: UNSEEN, PERMANENTFLAGS Resultado: OK selección completada, ahora en estado seleccionado NO selección fallida, ahora en estado autentificado: no existe el buzón de correo, no es posible acceder al buzón. BAD comando desconocido o argumentos no válidos El comando SELECT selecciona un buzón de correo para que en un futuro se pueda tener acceso a los mensajes que este contiene.Antes de enviar un OK al cliente, el servidor DEBE enviar al cliente los datos no etiquetados que se refieren a continuación: FLAGS banderas especificadas en el buzón de correo. Ver la descripción de las respuestas FLAGS para más información. EXISTS Número de mensajes existentes en el buzón de correo. Ver la descripción de la respuesta EXISTS para más información. RECENT M. Crispin [Pág. 23] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Número de mensajes con la bandera \Recent activa. Ver descripción de la respuesta RECENT para más información. OK [UIDVALIDITY ] El valor de vigencia de identificador único. Ver la descripción del comando UID para más información. para definir el estado inicial del buzón de correo al cliente. El servidor DEBERIA enviar un código de respuesta UNSEEN dentro de una respuesta no etiquetada OK, indicando el número de secuencia de mensaje del primer mensaje no visto hasta ahora presente en el buzón de correo. Si el cliente no puede cambiar el estado de una o más de las banderas listadas en la respuesta no etiquetada FLAGS, el servidor DEBERIA enviar un código de respuesta PERMANENTFLAGS dentro de una respuesta no etiquetada OK, listando las banderas que el cliente puede cambiar de forma permanente. Sólo puede seleccionarse un único buzón de correo por conexión; un acceso simultáneo a múltiples buzones de correo precisa de múltiples conexiones. El comando SELECT deselecciona automáticamente el buzón de correo actual antes de intentar seleccionar uno nuevo. En consecuencia, si se ha seleccionado un buzón de correo y se intenta un comando SELECT fallido, no se selecciona ningún buzón de correo. Si se permite al cliente modificar el buzón de correo, el servidor DEBERIA preceder al texto de la respuesta etiquetada OK con el código de respuesta "[READ-WRITE]". Si se permite que el cliente modifique el buzón de correo pero si se le permite un acceso de lectura, el buzón de correo está seleccionado como de solo lectura, y el servidor DEBE preceder el texto de la respuesta etiquetada OK del SELECT con el código de respuesta "[READ-ONLY]". El acceso de solo lectura a través de SELECT difiere del comando EXAMINE en que ciertos buzones de correo de solo lectura ES POSIBLE que permitan cambiar el estado permanente a uno por-usuario (en oposición al global). Los mensajes de noticias de red marcados en un archivo M. Crispin [Pág. 24] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 permanente por-usuario que puede ser modificado con buzones de correo de solo lectura. Ejemplo: C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENTS: * OK [UNSEEN 12] El mensaje 12 es el primer mensaje no visto S: * OK [UIDVALIDITY 3857529045] UIDs válido S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limitado S: A142 OK [READ-WRITE] SELECT completado 6.3.2. Comando EXAMINE Argumentos: nombre de buzón Respuestas: respuestas no etiquetadas OBLIGATORIAS: FLAGS,EXISTS, RECENT respuestas no etiquetadas OK OPCIONALES: UNSEEN, PERMANENTFLAGS Resultado: OK examine completado, ahora en estado seleccionado NO examine fallido, ahora en estado autentificado: no existe el buzón de correo, no puede accederse al buzón. BAD comando desconocido o argumentos no válidos El comando EXAMINE es idéntico al comando SELECT y devuelve la misma salida; sin embargo, el buzón de correo seleccionado se establece como de solo lectura. No se permiten modificaciones en el estado permanente del buzón de correo, incluyendo el estado por-usuario. El texto de la respuesta OK etiquetada al comando EXAMINE DEBE comenzar con el código de respuesta [READ-ONLY]. Ejemplo: C: A932 EXAMINE blurdybloop S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] El mensaje 8 es el primero que se ha visto S: * OK [UIDVALIDITY 3857529045] UIDs válido M. Crispin [Pág. 25] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No se permiten banderas permanentes S: A932 OK [READ-ONLY] EXAMINE completado 6.3.3. Comando CREATE Argumentos: nombre de buzón de correo Respuestas: no hay respuestas especificas para este comando Resultado: OK creación completada NO creación fallida: no puede crearse un buzón de correo con este nombre BAD comando desconocido o argumentos no válidos El comando CREATE crea un buzón de correo con el nombre especificado. Se devolverá una respuesta OK siempre y cuando haya sido creado este nuevo buzón con el nombre especificado. Cuando intentemos crear un buzón o INBOX con un nombre asociado igual a un nombre de buzón ya existente obtendremos un error. Cualquier error ocurrido durante la creación devolverá una respuesta etiquetada NO. Si el nombre de buzón de correo contiene como sufijo el carácter separador de la jerarquía del servidor (de la misma manera que cuando se ejecuta un comando LIST), quiere decir que el cliente quiere crear nombres de buzón con el nombre dado, dentro de la jerarquía. Las implementaciones de servidor que no requieren esta declaración DEBEN ignorarla. Si el carácter separador de jerarquía del servidor aparece en cualquier otro lugar del nombre, el servidor DEBERIA crear los nombres de jerarquía superiores que necesite el comando CREATE para ejecutarse de manera correcta. En otras palabras, un intento de crear "foo/bar/zap" en un servidor cuyo carácter separador de jerarquía es "/" DEBERIA crear foo/ y foo/bar si es que estos no existen ya. Si se crea un buzón de correo con el mismo nombre que el que poseía un buzón borrado anteriormente, sus identificadores únicos DEBEN ser mayores que cualquiera de los identificadores únicos usados por el buzón de correo anterior a menos que el nuevo buzón posea un valor de vigencia de identificador único diferente. Ver la M. Crispin [Pág. 26] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 descripción del comando UID para más información. Ejemplo: C: A003 CREATE owatagusiam/ S: A003 OK CREATE completado C: A004 CREATE owatagusiam/blurdybloop S: A004 OK CREATE completado Nota: La interpretación de este ejemplo depende de si el carácter separador de jerarquía del servidor es "/". Si "/" lo es, se creará un nuevo nivel en la jerarquía con nombre "watagusiam" que incluirá un miembro llamado "blurdybloop". Si no lo es, se crearán dos buzones de correo en el mismo nivel de la jerarquía. 6.3.4. Comando DELETE Argumentos: nombre de buzón de correo Respuestas: no hay respuestas especificas para este comando Resultado: OK borrado completado NO borrado fallido: no puede eliminarse el buzón que posee este nombre. BAD comando desconocido o argumentos no válidos El comando DELETE borra de forma permanente el buzón de correo que posea el nombre especificado. Si este ha sido borrado, se devolverá una respuesta etiquetada NO. Es un error intentar borrar INBOX o cualquier buzón cuyo nombre no exista. El comando DELETE NO DEBE eliminar nombres de jerarquía inferiores. Por ejemplo, si un buzón llamado "foo" tiene un nombre de jerarquía "foo.bar" inferior (asumiendo que "." es el carácter delimitador de la jerarquía), si se intenta eliminar "foo", "foo.bar" NO DEBE ser eliminado. Cualquier intento de borrar un nombre que posea nombres de jerarquía inferiores y que tenga el atributo de nombre de buzón \Noselect, constituye un error. (ver descripción de la respuesta dada por el comando LIST para más información). Está permitido eliminar un nombre de jerarquía que posea nombres de jerarquía inferiores pero que carezcan del atributo de nombre de buzón \Noselect. En este caso, se borrarán todos los mensajes del buzón, y este nombre M. Crispin [Pág. 27] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 recibirá el atributo de nombre de buzón \Noselect. El valor más alto de identificador único del buzón borrado con anterioridad DEBE preservarse para que si alguna vez se crea un buzón con el mismo nombre este no utilice los identificadores del buzón anterior, a menos que el nuevo buzón posea un valor de vigencia de identificador único diferente. Ver la descripción del comando UID para más información. Ejemplos: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completado C: A683 DELETE blurdybloop S: A683 OK DELETE completado C: A684 DELETE foo S: A684 NO nombre "foo" tiene nombres de jerarquía inferiores. C: A685 DELETE foo/bar S: A685 OK DELETE completado C: A686 LIST "" * S: * LIST (\Noselect) "/" foo S: A686 OK LIST completado C: A687 DELETE foo S: A687 OK DELETE completado C: A82 LIST "" * S: * LIST () "." blurdybloop S: * LIST () "." foo S: * LIST () "." foo.bar S: A82 OK LIST completado C: A83 DELETE blurdybloop S: A83 OK DELETE completado C: A84 DELETE foo S: A84 OK DELETE completado C: A85 LIST "" * S: * LIST () "." foo.bar S: A85 OK LIST completado C: A86 LIST "" % S: * LIST (\Noselect) "." foo S: A86 OK LIST completado 6.3.5. Comando RENAME Argumentos: nombre del buzón existente nombre del nuevo buzón M. Crispin [Pág. 28] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Respuestas: no hay respuestas específicas para este comando Resultado: OK cambio de nombre completado NO cambio de nombre: no puede cambiarse el nombre de buzón por este nombre. BAD comando desconocido o argumentos no válidos El comando RENAME cambia el nombre del buzón de correo. Se devolverá una respuesta etiquetada OK sólo si el nombre del buzón de correo ha sido modificado. Es un error intentar renombrar un buzón desde un buzón cuyo nombre no exista o utilizar un nombre de buzón correo que ya exista. Cualquier error relacionado con el cambio de nombres de buzón de correo devolverá una respuesta etiquetada NO. Si dicho nombre posee nombres de jerarquía inferiores, estos también DEBEN cambiarse de nombre. Por ejemplo, si cambiamos el nombre "foo" por "zap" provocará que "foo/bar" (asumimos que "/" es el carácter separador de jerarquía) se convierta en "zap/bar".Se DEBE preservar el identificador único más alto que se haya utilizado en el buzón anterior, para que en el caso de que se cree un nuevo buzón con el mismo nombre que el anterior evitar la utilización de los identificadores propios del buzón anterior, a menos que el buzón anterior posea un valor de vigencia de identificador único diferente. Ver la descripción del comando UID para más información. Se permite el cambio de nombres de INBOX, y posee un comportamiento especial: se crea un nuevo buzón de correo con el nombre especificado que contiene todos los mensajes presentes en INBOX y los elimina de INBOX. Si la implementación del servidor permite nombres de jerarquía inferiores para INBOX, estos no se ven afectados por un cambio de nombre del INBOX. Ejemplo: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/"foo S: * LIST () / foo/bar S: A682 OK LIST completado C: A683 RENAME blurdybloop sarasoop S: A683 OK RENAME completado C: A684 RENAME foo zowie S: A684 OK RENAME completado C: A685 LIST "" * M. Crispin [Pág. 29] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 S: * LIST () "/" sarasoop S: * LIST (\Noselect) "/" zowie S: * LIST () "/" zowie/bar S: A685 OK LIST completado C: Z432 LIST "" * S: * LIST () "." INBOX S: * LIST () "." INBOX.bar S: Z432 OK LIST completado C: Z433 RENAME INBOX old-mail S: Z433 OK RENAME completado C: Z434 LIST "" * S: * LIST () "." INBOX S: * LIST () "." INBOX.bar S: * LIST () "." old-mail S: Z434 OK LIST completado 6.3.6. Comando SUBSCRIBE Argumentos: buzón de correo Respuestas: no hay respuestas especificas para este comando Resultado: OK comando completado NO suscripción fallida: no puede asignarse dicho nombre BAD comando desconocido o argumentos no válidos El comando SUBSCRIBE añade el nombre de buzón de correo especificado al conjunto de buzones "activos" o "suscritos" presentes en el servidor, conjunto que se lista tras la ejecución del comando LSUB. Este comando devuelve una respuesta OK etiquetada únicamente si la suscripción tiene éxito. Un servidor ES POSIBLE que valide el argumento del buzón de correo utilizado en SUBSCRIBE para verificar que este existe. Sin embargo, no DEBE eliminarse de forma unilateral un nombre de buzón de correo existente de la lista de suscripción incluso si el buzón de correo que posee ese nombre no existe. Nota: esto es necesario puesto que algunos sitios de servidor mantienen tareas rutinarias que eliminan buzones con nombres bien conocidos (p.ej. "system-alerts") tras la M. Crispin [Pág. 30] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 pérdida de interés de su contenido, con la intención de volver a crearlo con contenido actualizado o apropiado al momento actual. Ejemplo: C: A002 SUBSCRIBE #news.comp.mail.mime S: A002 OK SUBSCRIBE completado 6.3.7. Comando UNSUBSCRIBE Argumentos: nombre de buzón de correo Respuestas: no hay respuestas especificas para este comando Resultado: OK abandonar suscripción completado NO abandonar suscripción fallido: no puede darse de baja ese nombre BAD comando desconocido o argumentos no válidos El comando UNSUBSCRIBE elimina el nombre de buzón de correo especificado del conjunto de buzones "activos" o "suscritos" del servidor que se muestran con el comando LSUB. Este comando devuelve una respuesta OK etiquetada únicamente cuando el comando tiene éxito. Ejemplo: C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completado 6.3.8. Comando LIST Argumentos: nombre de referencia nombre del buzón con los posibles comodines Respuestas: respuestas no etiquetadas: LIST Resultado: OK listado completado NO- listado fallido: no puede listarse el nombre oreferencia BAD comando desconocido o argumentos no válidos El comando LIST devuelve un subconjunto de nombres del conjunto global de todos los nombres disponibles, al cliente. Se devuelven cero o más respuestas, conteniendo los atributos del nombre, delimitador de jerarquía, y nombre; ver la descripción de la respuesta LIST para más información. M. Crispin [Pág. 31] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 El comando LIST DEBERIA devolver sus datos con rapidez, sin retraso. Por ejemplo, NO DEBERIA tener demasiados problemas en calcular el estado \Marked o \Unmarked o llevar a cabo cualquier otro procesamiento; si cada nombre requiere 1 segundo de procesamiento, entonces un listado de 1200 nombres supondría !20 minutos! Un argumento de nombre de referencia vacío (cadena "") indica que el nombre del buzón se interpreta como en un SELECT. Los nombres de buzón devueltos DEBEN coincidir con el patrón de nombre especificado. Un argumento de nombre de referencia no vacío es el nombre de un buzón o un nivel de la jerarquía del buzón, e indica un contexto en el cual la interpretación del nombre del buzón se realiza en base a la implementación. Un argumento de nombre de buzón vacío (cadena "") supone una solicitud especial que consiste en la devolución del delimitador de jerarquía y el nombre del root asociado al nombre dado en la referencia. El valor devuelto como root ES POSIBLE que sea null si la referencia no es en función del root o es null. En cualquier caso, se devolverá el delimitador de jerarquía. Esto permite que un cliente obtenga el delimitador de jerarquía incluso cuando no existan buzones que posean el nombre especificado. Los argumentos referencia y nombre de buzón son interpretados en función de la implementación, en forma canónica que representa una jerarquía de izquierda a derecha no ambigua. Los nombre de buzón devueltos estarán en forma interpretada. Cualquier parte del argumento referencia incluida en la forma interpretada DEBERIA preceder a la misma. DEBERIA encontrarse en el mismo formato que el argumento nombre de referencia. Esta norma permite que el cliente conozca si el nombre de buzón devuelto se encuentra en el contexto del argumento de referencia, o si el argumento de buzón anuló el argumento de referencia. Sin ayuda de esta norma, el cliente tendría que conocer la semántica de nombres utilizada en el servidor incluyendo cuales son los caracteres "ruptura" que anulan un contexto de nombres. Por ejemplo, aquí tenemos algunos ejemplos de cómo pueden interpretarse en un servidor basado en UNIX, las referencias y nombre de buzón: Referencia Nombre de buzón Interpretación M. Crispin [Pág. 32] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 ---------- --------------- -------------- ~smith/Mail/ foo.* ~smith/Mail/foo.* archive/ % archive/% #news. comp.mail.* #news.comp.mail.* ~smith/Mail/ /usr/doc/foo /usr/doc/foo archive/ ~fred/Mail/* ~fred/Mail/* Los primeros tres ejemplos muestran cómo se produce la interpretación en el contexto del argumento referencia. Ha de observarse que "~smith/Mail" NO DEBERIA ser transformado en algo como "/u2/users/smmith/Mail", o resultaría imposible para el cliente determinar si la interpretación se hizo en el contexto de la referencia. El carácter "*" es un comodín, y equivale a un patrón que aceptacero o más caracteres en dicha posición. El carácter "%" es similar a "*", pero este no acepta un carácter delimitador de jerarquía. Si el carácter comodín "%" es el último carácter de un argumento nombre de buzón, se devolverán también todas los niveles de jerarquía coincidentes. Si estos niveles son buzones no seleccionables, se devolverán con el atributo de nombre de buzón \Noselect (ver la descripción de la respuesta LIST para más información). Las implementaciones de servidor permiten "esconder" buzones accesibles de la inclusión de caracteres comodín, evitando de esta forma que determinados nombres o caracteres coincidan con un carácter comodín en ciertas situaciones. Por ejemplo, un servidor basado en UNIX puede restringir la forma de interpretar el carácter "*" para que un carácter "/" inicial no coincida. El nombre especial INBOX se incluye en la salida de LIST, si el servidor soporta INBOX para este usuario en concreto y si la cadena "INBOX" con mayúsculas concuerda con los argumentos referencia y nombre de buzón ya interpretados con los caracteres comodín en la forma descrita más abajo. El criterio para omitir INBOX es si un SELECT INBOX devolverá un error; no es relevante si el INBOX del usuario real reside en este u otro servidor. Ejemplo: C: A101 LIST "" "" S: * LIST (\Noselect) "/" "" S: A101 OK LIST completado M. Crispin [Pág. 33] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 C: A102 LIST #news.comp.mail.misc "" S: * LIST (\Noselect) "." #news. S: A102 OK LIST completada C: A103 LIST /usr/staff/jones "" S: * LIST (\Noselect) "/" / S: A103 OK LIST completado C: A202 LIST ~/Mail/ % S: * LIST (\Noselect) "/"~/Mail/foo S: * LIST () "/"~/Mail/meetings S: A202 OK LIST completado 6.3.9. Comando LSUB Argumentos: nombre de referencia nombre de buzón con posibles comodines Respuestas: OK lsub completado NO lsub fallido: no puede listarse la referencia o el nombre BAD comando desconocido o argumentos no válidos El comando LSUB devuelve un subconjunto de nombres del conjunto de nombres declarados por el usuario como "activos" o "suscritos". Se devolverán cero o más respuestas LSUB no etiquetadas. Los argumentos de LSUB tienen el mismo formato que en el comando LIST. Un servidor ES POSIBLE que valide los nombres suscritos para comprobar que estos aun existen. Si uno de los nombres no existe, esto se DEBERIA indicar incluyendo el atributo \Noselect en la respuesta LSUB. El servidor NO DEBE eliminar de forma unilateral un nombre de buzón existente de la lista de suscripción incluso cuando el buzón que posea dicho nombre ya no exista. Ejemplo: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () "." #news.comp.mail.mime S: * LSUB () "." #news.comp.mail.misc S: A002 OK LSUB completado 6.3.10. Comando STATUS Argumentos: nombre de buzón nombres de elemento de datos de estado Respuestas: respuestas no etiquetadas: STATUS M. Crispin [Pág. 34] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Resultado: OK comprobación de estado completado NO comprobación de estado fallido: el nombre no posee estado BAD comando desconocido o argumentos no válidos El comando STATUS solicita el estado del buzón especificado. No produce ningún cambio en el buzón seleccionado, ni afecta al estado de los mensajes contenidos en el buzón (en particular, STATUS NO DEBE provocar la pérdida de la bandera \Recent). El comando STATUS ofrece una solución alternativa para la apertura de una segunda conexión IMAP4rev1 y generar un comando EXAMINE sobre el buzón para averiguar su estado sin tener que deseleccionar el buzón actual de la primera conexión IMAP4rev1. A diferencia del comando LIST, el comando STATUS no garantiza que las respuestas que este produzca se ejecuten con rapidez. En algunas implementaciones, el servidor está obligado a abrir el buzón en modo solo lectura internamente para obtener cierta información de estado. También al contrario que el comando LIST, el comando STATUS no acepta comodines. Los elementos de datos de estado que están definidos actualmente y pueden ser solicitados son: MESSAGES El número de mensajes que contiene el buzón. RECENT El número de mensajes con la bandera \Recent activa. UIDNEXT El valor de UID que le será asignado al primer mensaje nuevo que llegue al buzón. Se garantiza que este valor no cambiará a menos que se añadan nuevos mensajes al buzón; si esto sucede entonces este valor será modificado incluso si estos mensajes nuevos son expulsados o borrados posteriormente. UIDVALIDITY Valor de vigencia para el identificador único del buzón M. Crispin [Pág. 35] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 UNSEEN El número de mensajes que no tienen la bandera \Seen activada. Ejemplo: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: A042 OK STATUS completado 6.3.11. Comando APPEND Argumentos: nombre de buzón lista entre paréntesis de banderas OPCIONAL cadena fecha/hora OPCIONAL literal mensaje Respuestas: no hay respuestas especificas para el comando Resultado: OK acción de añadido completada NO acción de añadido error: no puede añadirse al buzón, error en banderas o en fecha/hora o en texto del mensaje BAD comando desconocido o argumentos no válidos El comando APPEND añade el argumento literal como un nuevo mensaje al final del buzón destino especificado. Este argumento DEBERIA estar en formato de mensaje [RFC-822]. Se permiten caracteres de 8-bit en el mensaje. La implementación de servidor que sea incapaz de preservar de forma adecuada los datos de 8-bit DEBE ser capaz de convertir los datos APPEND de 8-bit a 7-bit usando una codificación de transferencia de contenidos [MIME-IMB]. Nota: ES POSIBLE que haya excepciones, p.ej. borradores de mensaje, en los cuales las líneas de cabecera necesarias se omiten en el argumento literal de mensaje de APPEND. Las razones para hacer esto DEBEN ser sopesadas cuidadosamente. Si se especifica una lista entre paréntesis de banderas, las banderas DEBERIAN establecerse en el mensaje resultante; de otra manera, la lista de banderas del mensaje resultante estaría vacía por defecto. Si se especifica una fecha_hora, la fecha interna DEBERIA M. Crispin [Pág. 36] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 establecerse en el mensaje resultante; de otra forma, la fecha interna del mensaje resultante ser la fecha y hora actuales por defecto. Si el comando append no es eficaz por cualquier razón, el estado del buzón previo a la ejecución del comando APPEND debe ser restaurado; no se permiten añadidos parciales. Si el buzón destino no existe, un servidor DEBE devolver un error, y NO DEBE crear el buzón de forma automática. A menos que no puedacrearse el buzón destino, el servidor DEBE enviar el código de respuesta "[TRYCREATE]" como prefijo del texto de la respuesta etiquetada NO. Esto indica al cliente que puede intentar ejecutar un comando CREATE y volver a ejecutar el APPEND si el comando CREATE anterior tiene éxito. Si el buzón está seleccionado, DEBERIAN tener lugar las acciones asociadas a la llegada de nuevos mensajes. Más específicamente, el servidor DEBERIA notificarlo al cliente de manera inmediata mediante una respuesta EXISTS no etiquetada. Si el servidor no lo hace, el cliente puede ejecutar un comando NOOP (o si este falla, un comando CHECK) tras uno o más comandos APPEND. Ejemplo: C: A003 APPEND mensajes almacenados (\Seen) {310} C: Fecha: Mon, 7 Feb 1994 21:52:25 0800 (PST) C: Desde: Fred Foobar C: Asunto: reunión por la tarde C: Destinado a: mooch@owatagu.siam.edu C: Identificador-mensaje: C: Versión MIME: 1.0 C: Tipo de contenido: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hola Joe, podemos quedar mañana a las 3:30? C: S: A003 OK APPEND completado Nota: el comando APPEND no se utiliza para el envío de mensajes, porque no ofrece un mecanismo de transferencia de información de envoltura [SMTP]. 6.4. Comandos de cliente - Estado seleccionado En el estado seleccionado, están permitidos los comandos que manipulan mensajes en un buzón.Además de los comandos universales (CAPABILITY, NOOP, y LOGOUT), y los comandos de M. Crispin [Pág. 37] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 estado autentificado (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, y APPEND), los comandos siguientes son válidos en el estado seleccionado: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, y UID. 6.4.1. Comando CHECK Argumentos: ninguno Respuestas: no hay respuestas especificas para este comando Resultado: OK comprobación completada BAD comando desconocido o argumentos no válidos El comando CHECK solicita un punto de comprobación en el buzón seleccionado. Un punto de comprobación hace referencia a un proceso de mantenimiento dependiente de la implementación asociado al buzón (p.ej. compara el estado en memoria del buzón en el servidor con el estado en disco) que normalmente no se ejecuta por comando. El establecimiento de un punto de comprobación ES POSIBLE que suponga una cantidad de tiempo no despreciable. Si una implementación de servidor no contempla estas consideraciones de mantenimiento, el comando CHECK es equivalente a NOOP. No está garantizado que como resultado de la ejecución de un comando CHECK obtengamos una respuesta no etiquetada EXISTS. El comando NOOP DEBERIA ser utilizado para el sondeo de nuevo correo, en lugar de CHECK. Ejemplo: C: FXXZ CHECK S: FXXZ OK CHECK completado 6.4.2. Comando CLOSE Argumentos: ninguno Respuestas: no hay respuestas especificas para este comando Resultado: OK cierre completado, ahora en estado autentificado NO cierre fallido: ningún buzón seleccionado BAD comando desconocido o argumentos no válidos M. Crispin [Pág. 38] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 El comando CLOSE elimina de manera permanente todos los mensajes del buzón que tengan la bandera \Deleted activada, y cambia el estado del buzón de seleccionado a autentificado. No se envía ninguna respuesta EXPUNGE no etiquetada. Si se selecciona el buzón mediante un comando EXAMINE o en modo solo lectura no se eliminará ningún mensaje, y no se producirá ningún error. Incluso si el buzón está seleccionado, ES POSIBLE ejecutar los comandos SELECT, EXAMINE o LOGOUT sin haber ejecutado previamente un CLOSE. Los comandos SELECT, EXAMINE y LOGOUT cierran implícitamente el buzón seleccionado sin necesidad de ejecutar un borrado (expunge). Sin embargo, cuando se borran muchos mensajes, una secuencia CLOSE-LOGOUT o CLOSE-SELECT es considerablemente más rápida que una secuencia EXPUNGE-LOGOUT o EXPUNGE-SELECT puesto que no se envían respuestas EXPUNGE no etiquetadas (las cuales el cliente ignoraría). Ejemplo: C: A341 CLOSE S: A341 OK CLOSE completado 6.4.3. Comando EXPUNGE Argumentos: ninguno Respuestas: respuestas no etiquetadas: EXPUNGE Resultado: OK borrado completado NO borrado fallido: no puede borrarse (p.ej. permiso denegado) BAD comando desconocido o argumentos no válidos El comando EXPUNGE borra permanentemente todos los mensajes del buzón que tengan la bandera \Deleted activada. Antes de devolver un OK al cliente, se envía una respuesta no etiquetada EXPUNGE por cada mensaje que haya sido eliminado. Ejemplo: C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK EXPUNGE completado M. Crispin [Pág. 39] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Nota: en este ejemplo, los mensajes 3,4,7, y 11 tenían la bandera \Deleted activada. Ver descripción de la respuesta EXPUNGE para más información. 6.4.4. Comando SEARCH Argumentos: especificación [CHARSET] OPCIONAL patrón de búsqueda (uno o más) Respuestas: respuesta no etiquetada REQUERIDA Resultado: OK búsqueda completada NO error en búsqueda: no puedo buscar por ese [CHARSET] o por el patrón BAD comando desconocido o argumentos no válidos El comando SEARCH busca los mensajes del buzón que coincidan con el patrón de búsqueda especificado. Este consiste en una o más claves de búsqueda. La respuesta no etiquetada SEARCH del servidor contiene un listado de números de secuencia de mensaje que se corresponden con aquellos mensajes que coinciden con el patrón de búsqueda. Cuando se especifican múltiples claves, el resultado es la intersección (función AND) de todos los mensajes que coinciden con dichas claves. Por ejemplo, el patrón DELETED FROM "SMITH"SINCE 1-Feb-1994 se refiere a todos los mensajes enviados por Smith que han sido eliminados y fueron recibidos en el buzón desde el 1 de Febrero de 1994. Una clave de búsqueda puede consistir también en una lista entre paréntesis que contenga una o más claves de búsqueda. (p.ej. para el uso con las claves OR o NOT). Las implementaciones de servidor ES POSIBLE que excluyan fragmentos del cuerpo con tipos multimedia distintos de TEXT o MESSAGE del patrón de búsqueda. La especificación OPCIONAL de [CHARSET] está constituida por la palabra "CHARSET" seguida de una [tabla de caracteres] registrada. Esto indica la [tabla de caracteres] utilizada en las cadenas que aparecen en el patrón de búsqueda. Las codificaciones de transferencia de contenido [MIME-IMB], y cadenas [MIME-HDRS] en las cabeceras [RFC-822]/[MIME-IMB], DEBEN ser decodificadas antes de comparar texto con una [tabla de caracteres] distinta del US-ASCII. Se DEBE tener soporte para el US-ASCII; también ES POSIBLE que se permitan otras [tabla M. Crispin [Pág. 40] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 de caracteres] . Si el servidor no soporta la [tabla de caracteres] especificada, DEBE devolver una respuesta etiquetada NO (no una respuesta BAD). En todas las claves de búsqueda que contengan cadenas, un mensaje coincide con la clave si la cadena es una subcadena del campo. El patrón no hace distinción entre mayúsculas-minúsculas. Las claves de búsqueda definidas son como sigue. Ver la sección Sintaxis Formal para una definición sintáctica más precisa de los argumentos. Mensajes con números de secuencia de mensaje que se corresponden al conjunto de números de secuencia de mensaje especificado ALL Todos los mensajes del buzón; la clave inicial por defecto para la intersección (AND). ANSWERED Mensajes con la bandera \Answered activada. BCC Mensajes que contienen la cadena especificada en el campo BCC de la estructura del envoltorio. BEFORE Mensajes cuya fecha interna es anterior a la fecha especificada. BODY Mensajes que contienen la cadena especificada en el cuerpo del mensaje. CC Mensajes que contienen la cadena especificada en el campo CC de la estructura de envoltorio. DELETED Mensajes con la bandera \Deleted activada. DRAFT Mensajes con la bandera \Draft activada FLAGGED Mensajes con la bandera \Flagged M. Crispin [Pág. 41] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 activada. FROM Mensajes que contienen la cadena especificada en el campo FROM de la estructura de envoltorio. HEADER Mensajes cuya cabecera posee el nombre de campo especificado (como se define en [RFC-822]) y que contiene la cadena especificada en el campo cuerpo. KEYWORD Mensajes con el conjunto de claves especificado LARGER Mensajes con un tamaño [RFC-822] mayor que el número de octetos especificado. NEW Mensajes cuya bandera \Recent está activada pero no lo está la bandera \Seen. Esto es equivalente en funcionalidad a "(RECENT UNSEEN)". NOT Mensajes que no coinciden con la clave de búsqueda especificada. OLD Mensajes cuya bandera \Recent no está activada. Esto es equivalente en funcionalidad a "NOT RECENT" (lo contrario de "NOT NEW"). ON Mensajes cuya fecha interna está dentro de la fecha especificada. OR Mensajes que coinciden con ambas claves RECENT Mensajes cuya bandera \Recent está activada. SEEN Mensajes cuya bandera \Seen está activada. SENTBEFORE Mensajes cuya Fecha [RFC-822]: M. Crispin [Pág. 42] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 cabecera anterior a la fecha especificada. SENTON Mensajes cuya Fecha [RFC-822]: cabecera está dentro de la cabecera especificada. SENTSINCE Mensajes cuya Fecha [RFC-822]: cabecera está dentro o es posterior a la fecha especificada. SINCE Mensajes cuya fecha interna está dentro o es posterior a la fecha especificada. SMALLER Mensajes de un tamaño [RFC-822] menor queel número de octetos especificado. SUBJECT Mensajes que contienen la cadena especificada en el campo SUBJECT de la estructura de envoltorio. TEXT Mensajes que contienen la cadena especificada en la cabecera o cuerpo del mismo. TO Mensajes que contienen la cadena especificada en el campo TO de la estructura de envoltorio. UID Mensajes con identificadores únicos quese corresponden con el conjunto de identificadores únicos especificado. UNANSWERED Mensajes cuya bandera \Answered no está activada. UNDELETED Mensajes cuya bandera \Deleted no está activada. UNDRAFT Mensajes cuya bandera \Draft no está activada. UNFLAGGED Mensajes cuya bandera \Flagged no está activada. M. Crispin [Pág. 43] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 UNKEYWORD Mensajes que no poseen el conjunto de claves especificado. UNSEEN Mensajes cuya bandera \Seen no está activada. Ejemplo: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM Smith S: * SEARCH 2 84 882 S: A282 OK SEARCH completado 6.4.5. Comando FETCH Argumentos: conjunto de mensajes nombres de elementos de datos de mensaje Respuestas: respuestas no etiquetadas: FETCH Resultado: OK recuperación completada NO error en recuperación: no puede encontrarse el dato BAD comando desconocido o argumentos no válidos El comando FETCH recupera datos asociados a un mensaje contenido en el buzón. Los elementos de datos que pueden obtenerse son un único átomo o una lista entre paréntesis. Los elementos de datos definidos actualmente que pueden recuperarse mediante FETCH son: ALL Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) BODY Forma no extensible de BODYSTRUCTURE BODY[]<> El texto de una sección del cuerpo en particular. La forma de especificar la sección es un conjunto de cero o más especificadores de parte delimitados por puntos. Un especificador de parte es o un número de parte o uno de los siguientes especificadores: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, y TEXT. Una especificación de sección vacía se refiere al mensaje al completo, incluyendo la cabecera. M. Crispin [Pág. 44] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Todos los mensajes tienen al menos un número de parte.Los mensajes no [MIME-IMB], y los mensajes no multiparte [MIME-IMB] sin mensaje encapsulado, solo tienen una parte 1. A los mensajes multiparte se les asignan números de parte consecutivos, de la misma forma en que estas se sitúan en el propio mensaje. Si una parte en particular es de tipo mensaje o multiparte, su parte DEBE ser indicada por un punto seguido de un número de parte dentro de la parte anidada en la multiparte. Una parte de tipo MESSAGE/RFC822 también tiene números de parte anidados, que se refieren a partes del cuerpo de parte del MESSAGE. Los especificadores de parte HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, y TEXT pueden formar por sí solos un especificador de parte o pueden ir precedidos de uno o más especificadores de parte numéricos, teniendo en cuenta que los especificadores de parte numéricos se refieren a una parte del tipo MESSAGE/RFC822. El especificador de parte MIME DEBE ir precedido de uno o más especificadores de parte numéricos. Los especificadores de parte HEADER, HEADER.FIELDS, y HEADER.FIELDS.NOT se refieren a la cabecera [RFC-822] del mensaje o de un mensaje MESSAGE/RFC822 encapsulado [MIME-IMT]. Tras HEADER.FIELDS y HEADER.FIELD.NOT se sitúa una lista de nombres nombre-campo (definido en [RFC-822]), y devuelve un subconjunto de la cabecera. El subconjunto devuelto por HEADER.FIELDS contiene solo aquellos campos de cabecera con un camponombre que coincida con alguno de los incluidos en la lista; de igual manera, el subconjunto devuelto por HEADER.FIELDS.NOT contiene solo los campos de cabecera que no coincidan con ningún campo-nombre de la lista. No hay distinción entre mayúsculas-minúsculas. En cualquier caso, siempre se incluye una línea en blanco entre la cabecera y el cuerpo. El especificador de parte MIME se refiere a la cabecera de esta parte [MIME-IMB]. El especificador de parte TEXT se refiere al cuerpo del texto del mensaje, omitiendo la cabecera M. Crispin [Pág. 45] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 [RFC-822]. Aquí, tenemos un ejemplo de un mensaje complejo con alguno de sus especificadores de parte: HEADER ([RFC-822] cabecera del mensaje) TEXT MULTIPART/MIXED 1 TEXT/PLAIN 2 APPLICATION/OCTET-STREAM 3 MESSAGE/RFC822 3.HEADER ([RFC-822] cabecera del mensaje) 3.TEXT ([RFC-822] cuerpo del texto del mensaje) 3.1 TEXT/PLAIN 3.2 APPLICATION/OCTET-STREAM 4 MULTIPART/MIXED 4.1 IMAGE/GIF 4.1.MIME ([MIME-IMB] cabecera para la imagen/GIF) 4.2 MESSAGE/RFC822 4.2.HEADER ([RFC-822] cabecera del mensaje) 4.2.TEXT ([RFC-822] cuerpo del texto del mensaje) 4.2.1. TEXT/PLAIN 4.2.2 MULTIPART/ALTERNATIVE 4.2.2.1 TEXT/PLAIN 4.2.2.2 TEXT/RICHTEXT Es posible recuperar una subcadena del texto designado. Esto se hace añadiendo un ("<"), la posición del octeto del primer octeto que deseamos que sea el primero, y un (">") en el especificador de parte. Si el primer octeto está más allá del final del texto, se devuelve una cadena vacía. Cualquier intento de recuperación parcial más allá del final del texto es truncado para que se ejecute de manera correcta. Una búsqueda que comience en el octeto 0 se toma como una búsqueda parcial, incluso si esta ya ha sido truncada. Nota: esto significa que BODY[]<0.2048> de un mensaje de 1500 octetos devolverá BODY[]<0> con un literal de tamaño 1500, no BODY[]. Nota: una recuperación de subcadena de un especificador de parte HEADER.FIELDS o HEADER.FIELDS.NOT se calcula tras establecer M. Crispin [Pág. 46] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 la cabecera. Implícitamente la bandera \Seen está activada; si esto provoca que el estado de las banderas cambie DEBERIAN incluirse como parte de las respuestas FETCH. BODY.PEEK[]<> Una forma alternativa de BODY[] que no establece implícitamente la bandera \Seen como activa. BODYSTRUCTURE La estructura [MIME-IMB] del cuerpo del mensaje. Esto es procesado por el servidor analizando los campos cabecera de la cabecera [RFC-822] y cabeceras [MIME-OMB]. ENVELOPE La estructura del envoltorio del mensaje. Esto se procesa por el servidor analizando la cabecera [RFC-822] en las partes de componente, dejando por defecto tantos campos como sea necesario. FAST Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE) FLAGS Las banderas que están activadas para este mensaje. FULL Macro equivalente a: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) INTERNALDATE La fecha interna del mensaje. RFC822 Funcionalidad equivalente a BODY[], difieren en la sintaxis de los datos FETCH no etiquetados resultantes (se devuelve RFC822). RFC822.HEADER Funcionalidad equivalente a BODY.PEEK[HEADER], difieren en la sintaxis de los datos FETCH no etiquetados resultantes (se devuelve RFC822.HEADER). RFC822.SIZE M. Crispin [Pág. 47] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 El tamaño del mensaje [RFC-822]. RFC822.TEXT Funcionalidad equivalente a BODY[TEXT], difieren en la sintaxis de los datos FETCH no etiquetados resultantes (se devuelve RFC822.TEXT). UID Identificador único del mensaje. Ejemplo: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH .... S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completado 6.4.6. Comando STORE Argumentos: conjunto de mensajes nombre de elemento de datos del mensaje valor de elemento de datos del mensaje Respuestas: respuestas no etiquetadas: FETCH Resultado: OK almacenamiento completado NO error en almacenamiento: no puedo almacenar ese dato BAD comando desconocido o argumentos no válidos El comando STORE modifica los datos asociados con un mensaje contenido en un buzón. Normalmente, STORE devolverá el valor actualizado de los datos con una respuesta FETCH no etiquetada. El sufijo ".SILENT" en el nombre de elemento de datos evita la respuesta FETCH no etiquetada, y el servidor DEBERIA asumir que el cliente ha determinado el valor actualizado por sí mismo o que no le preocupa cual es este valor actualizado. Nota: dejando a un lado la utilización o no del sufijo ".SILENT", el servidor DEBERIA enviar una respuesta no etiquetada FETCH si detecta un cambio en las banderas del mensaje realizado por un agente externo. Su propósito es que el estado de las banderas sea M. Crispin [Pág. 48] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 establecido sin una condición de prueba. Los elementos de datos que pueden ser almacenados actualmente son: FLAGS Sustituye las banderas del mensaje por el argumento. Se devolverá el nuevo valor de las banderas como si realmente se hubiera realizado un FETCH sobre las mismas. FLAGS.SILENT Equivalente a FLAGS, pero sin devolver un nuevo valor. +FLAGS Añadir el argumento a las banderas del mensaje. Se devolverá el nuevo valor de las banderas como si realmente se hubiera realizado un FETCH sobre las mismas. +FLAGS.SILENT Equivalente a +FLAGS, pero sin devolver un nuevo valor. -FLAGS Elimina el argumento de las banderas del mensaje. Se devolverá el nuevo valor de las banderas como si realmente se hubiera realizado un FETCH sobre las mismas. -FLAGS.SILENT Equivalente a -FLAGS, pero sin devolver unnuevo valor. Ejemplo: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH FLAGS (\Deleted \Seen) S: * 3 FETCH FLAGS (\Deleted) S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) S: A003 OK STORE completado 6.4.7. Comando COPY Argumentos: conjunto de mensajes nombre del buzón M. Crispin [Pág. 49] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Respuestas: no hay respuestas especificas para este comando Resultado: OK copia completado NO error en copia: no puedo copiar los mensajes o al destino especificado BAD comando desconocido o argumentos no válidos El comando COPY copia el/los mensaje/s especificado/s al final del buzón indicado. Las banderas y fecha interna de el/los mensaje/s DEBERIAN ser conservados en la copia. Si el buzón destino no existe, el servidor DEBERIA devolver un error. No se DEBERIA crear el buzón automáticamente. A menos que sepamos con seguridad que no puede crearse un nuevo buzón, el servidor DEBE enviar un código de respuesta "[TRYCREATE]" como prefijo del texto de la respuesta etiquetada NO. Esto hace saber al cliente que puede intentar ejecutar un comando CREATE y volver a ejecutar el comando COPY si el comando anterior tuvo éxito. Si el comando CREATE falla por cualquier razón, las implementaciones de servidor DEBEN restaurar el estado del buzón destino a su estado original antes del intento de copia. Ejemplo: C: A003 COPY 2:4 MEETING S: A003 OK COPY completado 6.4.8. Comando UID Argumentos: nombre de comando argumentos del comando Respuestas: OK comando UID completado NO error en comando UID BAD comando desconocido o argumentos no válidos El comando UID tiene dos variantes. La primera, toma como argumento un comando COPY, FETCH, o STORE con los argumentos adecuados para cada comando. Sin embargo, los números del argumento conjunto de mensajes son identificadores únicos en lugar de números de secuencia de mensaje. M. Crispin [Pág. 50] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 En la segunda variante, el comando UID recibe un comando SEARCH con los argumentos del propio comando. La interpretación de los argumentos es la misma que se hace con SEARCH; sin embargo, los números devueltos en una respuesta SEARCH para un comando UID SEARCH son identificadores únicos en lugar de números de secuencia de mensaje. Por ejemplo, el comando UID SEARCH 1:100 UID 443:557 devuelve los identificadores únicos correspondientes a la intersección del conjunto de números de secuencia de mensaje 1:100 y el conjunto de UID 443:557. Se permiten rangos de conjuntos de mensaje; sin embargo, no existe garantía de que los identificadores únicos sean contiguos. Cualquier identificador único no existente dentro de un rango de conjunto de mensajes es ignorado sin provocar ningún mensaje de error. El número situado tras el "*" en una respuesta FETCH no etiquetada es siempre un número de secuencia de mensaje, no un identificador único, incluso para una respuesta del comando UID. Sin embargo, las implementaciones de servidor DEBEN incluir implícitamente el elemento de datos de mensaje UID como parte de cualquier respuesta FETCH originada por un comando UID, sin importar si un UID se concibió como un elemento de datos de mensaje para el FETCH. Ejemplo: C: A999 UID FETCH 4827313:4828442 FLAGS S: * 23 FECTH (FLAGS (\Seen) UID 4827313) S: * 24 FETCH (FLAGS (\Seen) UID 4827943) S: * 25 FETCH (FLAGS (\Seen) UID 4828442) S: A999 UID FETCH completado 6.5. Comandos de Cliente - Experimental/En desarrollo 6.5.1. Comando X<átomo> Argumentos: definidos por la implementación Respuestas: definidos por la implementación Resultados: OK comando completado NO fallo BAD comando desconocido o argumentos no válidos M. Crispin [Pág. 51] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Cualquier comando precedido de una X se trata de un comando experimental. Los comandos que no forman parte de esta especificación, de un estándar o revisión de un estándar de esta especificación, o de un protocolo experimental aprobado por IESG, DEBE hacer uso del prefijo X. Cualquier respuesta añadida no etiquetada generada por un comando experimental DEBE venir precedida de una X. Las implementaciones de servidor NO DEBEN enviar estas respuestas no etiquetadas, a menos que el cliente la solicite ejecutando el comando experimental asociado. Ejemplo: C: a441 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4XPIG-LATIN S: a441 OK CAPABILITY completado C: A442 XPIG-LATIN S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: A442 OK XPIG-LATIN ompleted-cay 7. Respuestas de servidor Hay tres tipos de respuestas de servidor: respuestas de estado, datos del servidor, y solicitud de continuación de comando. La información contenida en una respuesta de servidor, identificada por "Contenido:" en la descripción de la respuesta que se describe más abajo, viene descrita por su función, no por su sintaxis. La sintaxis exacta para las respuestas de servidor se describe en la sección Sintaxis Formal. El cliente DEDE estar preparado para aceptar cualquier respuesta en cualquier momento. Las respuestas de estado pueden ser tanto etiquetadas como no etiquetadas. Las respuestas etiquetadas indican el resultado de la ejecución de un comando de cliente (estado BAD, NO, o OK), y poseen una etiqueta que coincide con el comando. Algunas respuestas de estado, y todas los datos de servidor, son no etiquetadas. Una respuesta no etiquetada se indica mediante el token "*" en lugar de una etiqueta. Las respuestas de estado no etiquetadas indican el reconocimiento por parte del servidor, o el estado del servidor que no indique la finalización de un comando (por M. Crispin [Pág. 52] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 ejemplo, una alerta de apagado inminente del sistema). Por razones históricas, las respuestas de datos de servidor no etiquetadas se denominan también "datos no solicitados", aunque en realidad solo las respuestas unilaterales de datos de servidor son realmente "no solicitadas". Ciertos datos de servidor DEBEN ser almacenados por el cliente cuando se reciben; estos datos son reconocidos mediante su descripción. Estos datos constituyen información crítica que afecta a la interpretación de todos los comandos y respuestas posteriores (p.ej. actualizaciones que reflejan la creación o destrucción de mensajes). Otros datos de servidor DEBERIAN ser almacenados para posteriores consultas; si el cliente no necesita grabar los datos, o si la grabación de estos datos no tiene un propósito claro (p.ej. una respuesta SEARCH sin comando SEARCH en progreso), los datos DEBERIAN ser ignorados. Un ejemplo de datos de servidor no etiquetados unilaterales sucede cuando la conexión IMAP se encuentra en estado seleccionado. En el estado seleccionado, el servidor comprueba si hay nuevos mensajes en el buzón como parte de la ejecución del comando. Normalmente, esto se hace en la ejecución de cualquier comando; por tanto, un comando NOOP es suficiente para comprobar la existencia de nuevosmensajes. Si hay mensajes nuevos, el servidor envía respuestas no etiquetadas EXISTS y RECENT indicando el nuevo tamaño del buzón. Las implementaciones de servidor que ofrecen múltiples accesos simultáneos al mismo buzón DEBERIAN también enviar las respuestas adecuadas FETCH y EXPUNGE de forma unilateral si cualquier otro agente cambia el estado de las banderas de los mensajes o elimina cualquier mensaje. Las respuestas de solicitud de continuación de comando utilizan el token "+" en lugar de una etiqueta. El servidor envía estas respuestas para indicar la aceptación de un comando de cliente incompleto y la disponibilidad del recordatorio del comando. 7.1. Respuestas de servidor - Respuestas de estado Las respuestas de estado son OK, NO, BAD, PREAUTH y BYE. Las respuestas OK, BAD y NO pueden estar etiquetadas o no. PREAUTH y BYE van siempre etiquetadas. M. Crispin [Pág. 53] RFC 2060 Protocolo IMAP - Versión 4rev1 Diciembre 1996 Las respuestas de estado ES POSIBLE que incluyan un "código de respuesta" OPCIONAL. Un código de respuesta consiste en datos encerrados entre corchetes en forma de un átomo, seguidos posiblemente de un espacio y argumentos. El código de respuesta contiene información adicional o códigos de estado para el software del cliente más allá de la condición OK/NO/BAD, y se definen cuando un cliente lleva a cabo una acción especifica en base a dicha información adicional. Los códigos de respuesta definidos actualmente son: ALERT El texto inteligible por el usuario contiene una alerta especial que DEBE mostrarse al usuario de manera que el mensaje consiga atraer la atención del mismo. NEWNAME Seguido de un nombre de buzón y un nombre de nuevo buzón. Un SELECT o EXAMINE no se ejecutan correctamente porque el nombre de buzón de destino no existe porque ha sido renombrado con el nuevo nombre de buzón. Esto indica al usuario que la operación puede tener éxito si se vuelven a ejecutar los comandos SELECT, EXAMINE con el nuevo nombre de buzón. PARSE El texto inteligible por el usuario representa un error en el procesado de la cabecera [RFC-822] o cabeceras [MIME-IMB] de un mensaje del buzón. PERMANENTFLAGS Seguido de una lista entre paréntesis de banderas, indica al cliente cual de las banderas conocidaspueden ser cambiadas de manera permanente. Cualquier bandera presente en la respuesta no etiquetada FLAGS,pero no en la lista PERMANENTFLAGS, no puede ser establecida de forma permanente. Si el cliente intenta ejecutar un STORE de una bandera que no se encuentra en la lista PERMANENTFLAGS, el servidor lorechazará con una respuesta NO o almacenará el estado del recordatorio de la sesión M. Crispin