Resumen

  • UIDPLUS permitió que el éxito de APPEND y COPY incluyera el UIDVALIDITY del buzón de destino y los UID recién asignados, de modo que un cliente desconectado pudiera reconciliar su acción sin adivinar.
  • La correspondencia estaba limitada a una operación y una generación de buzón: podía omitirse por privacidad o UIDNOTSTICKY, no era una identidad global y UID EXPUNGE solo afectaba a mensajes nombrados y ya marcados \Deleted.

Dos listas contaban lo que había ocurrido

Un UID no cruza una frontera de buzón como si fuera una matrícula universal. Al copiar un mensaje, el servidor crea una instancia en el destino y le da un UID válido allí. Si varios mensajes entran en una sola orden, el problema no consiste únicamente en conocer los números nuevos; hay que saber cuál pertenece a cuál.

COPYUID responde con tres piezas: UIDVALIDITY de la carpeta de destino, conjunto de UID de origen y conjunto de UID de destino. Ambos conjuntos deben contener la misma cantidad de elementos. Su orden crea la relación. El primer elemento de la lista de origen corresponde al primero de destino; el segundo, al segundo. No se permite * ni un UID ajeno a la orden.

Esa disciplina evita una deducción peligrosa basada en la posición visible de los mensajes. Los números de secuencia cambian cuando alguien expurga correo. Una fila que era la cuarta puede pasar a ser la tercera mientras COPY sigue en curso. Los UID empleados por la orden y devueltos por el recibo mantienen el ámbito aunque la vista se renumere.

La respuesta prueba una consecuencia concreta de una orden concreta. No afirma que el contenido conserve el mismo nombre en todas partes. Tampoco permite que otro cliente, que no vio la respuesta, reconstruya después la identidad entre buzones. RFC 8474 señalaría precisamente esa carencia al justificar identificadores de objeto más amplios.

APPEND necesitaba cerrar su propio circuito

APPEND tenía una dificultad más silenciosa. El cliente enviaba el mensaje y recibía un OK; sin embargo, el servidor era quien elegía el UID. Para actualizar una cola fuera de línea, el cliente necesitaba enlazar el elemento local con la nueva referencia remota.

APPENDUID añadió esa referencia al resultado etiquetado. La respuesta contiene el UIDVALIDITY de destino y el UID asignado. No es un acuse de entrega de correo: el mensaje ya está entrando en un buzón mediante IMAP. Es la constancia de cómo quedó nombrado el resultado de esa mutación dentro de ese buzón.

Cuando una extensión permite agregar varios mensajes a la vez, APPENDUID puede devolver un conjunto. Su orden sigue el de los mensajes enviados. Al excluir valores extraños y comodines, el protocolo hace posible verificar que la respuesta tiene la misma forma que la petición.

Guardar solo el UID destruiría parte de la prueba. La referencia depende del servidor, el nombre del buzón y UIDVALIDITY. Un cambio de validez anuncia que los UID antiguos ya no pueden conservar su significado. La generación no adorna el número: define hasta dónde puede confiarse en él.

Borrar exigía dos condiciones

UIDPLUS también añadió UID EXPUNGE. La orden EXPUNGE normal elimina permanentemente todo mensaje que lleve \Deleted en el buzón seleccionado. En un buzón compartido, una marca pudo haber sido puesta por otra sesión con una intención distinta.

UID EXPUNGE toma un conjunto de UID y calcula una intersección. Solo desaparece el mensaje que está en la lista y tiene la marca. Un UID nombrado pero sin \Deleted no se borra; un mensaje marcado pero fuera de la lista tampoco. La orden permite que el cliente complete sus propias eliminaciones sin apropiarse de todas las decisiones pendientes de los demás.

El método de compatibilidad para un servidor sin UIDPLUS era retirar temporalmente la marca de los mensajes que debían sobrevivir, ejecutar EXPUNGE y restaurarla. Puede ser necesario, pero manipula un espacio mayor de estado compartido. La nueva orden hizo visible la intención destructiva en el mismo mandato que la ejecutaba.

Un servidor podía callar con razón

Un usuario puede tener permiso para APPEND o COPY hacia una carpeta sin poder SELECT o EXAMINE esa carpeta. Devolver UIDVALIDITY y UID revelaría datos sobre una zona que el control de acceso no le permite inspeccionar. RFC 4315 indica que el servidor no debería entregar APPENDUID o COPYUID en ese caso.

También puede omitirlos si el destino anuncia UIDNOTSTICKY. Allí los UID no están garantizados entre sesiones. El estándar desaconseja crear almacenes así, pero reconoce que un recibo con apariencia persistente sería peor que una omisión explícitamente explicable.

El silencio no revoca el éxito de la orden. Si luego puede abrir el destino, el cliente puede buscar un marcador único insertado en el mensaje. Esa ruta de compatibilidad cuesta más y puede encontrar ambigüedades, pero separa correctamente el resultado de tres políticas: mutar, observar y conservar nombres.

De RFC 2359 a IMAP4rev2

RFC 2359 introdujo UIDPLUS en 1998 pensando en clientes que trabajaban desconectados y debían reconciliar cambios con pocos viajes. RFC 4315 lo sustituyó en 2005, corrigió las reglas de los conjuntos y precisó privacidad y UIDNOTSTICKY. El registro de IANA conserva la capacidad.

MOVE mostró una nueva arista. Mover crea UID nuevos en el destino y elimina los originales. Si el servidor anuncia primero EXPUNGE, las posiciones de origen cambian antes de que el cliente reciba COPYUID. RFC 6851 recomendó enviar el mapping en un OK no etiquetado antes de las expulsiones. RFC 9051 incorporó la conducta a IMAP4rev2 y reforzó el orden.

La evolución fue de una optimización opcional a una regla integrada de coherencia. Aun así, el alcance no creció sin límite. El recibo sigue describiendo el resultado de una operación en un espacio de nombres local.

La exactitud depende del ámbito

UIDPLUS no eliminó todas las carreras ni volvió transaccional un buzón compartido. Hizo algo más concreto: devolvió los identificadores que la operación acababa de crear y permitió nombrar el conjunto de una limpieza irreversible. Sus excepciones protegieron la misma precisión, pues evitaron revelar o prometer un nombre cuando el permiso o la persistencia no lo sostenían.

La enseñanza histórica no es que toda respuesta exitosa deba contener más datos. Debe contener los datos que permiten verificar su consecuencia, junto con la frontera que impide reutilizarlos fuera de contexto.

Fuentes y límites

La versión inicial está en RFC 2359 y la vigente de la extensión en RFC 4315. RFC 3501 aporta el contexto de IMAP4rev1; RFC 6851 trata MOVE; RFC 8474 explica el límite para otros clientes; y RFC 9051 integra estas reglas en IMAP4rev2. El registro de IANA lista UIDPLUS. Ninguna fuente mide adopción universal ni convierte un UID en prueba criptográfica.