Resumen

  • Un servidor conforme podía rechazar DELETE/RENAME, mantener un buzón fantasma para sesiones existentes o desconectar a los demás clientes; ninguna estrategia era la única realidad permitida.
  • La responsabilidad de interoperar recaía también en el cliente, que debía resolver EXPUNGE pendientes, resultados parciales y números de secuencia móviles sin atribuir demasiado significado a un OK.

La operación terminó; el mundo no convergió

En el ejemplo más incisivo de RFC 2180, dos clientes tienen seleccionado FOO. El primero lo elimina y recibe OK. Un tercero ya no puede localizarlo con STATUS ni crear otro buzón con el mismo nombre. Sin embargo, el segundo cliente todavía puede hacer STORE sobre el contenido que seleccionó antes.

El servidor ha retirado el nombre público, pero conserva el objeto mientras exista una referencia activa. Cuando el último cliente cierre, los datos se eliminan y el nombre puede reciclarse. Es una política posible, no obligatoria. También se puede rechazar la eliminación mientras haya usuarios, o aceptarla y enviar BYE a las demás conexiones.

La elección revela prioridades. Rechazar protege las sesiones pero puede bloquear indefinidamente la administración de un buzón popular. Mantener una copia fantasma favorece continuidad, pero aplaza el borrado de información sensible. Desconectar protege una interpretación más fuerte de la eliminación, pero rompe trabajo en curso.

RENAME añade otra escena. El servidor puede cambiar el atributo de nombre y dejar que las sesiones ya seleccionadas continúen con FETCH. Solo cuando una de ellas vuelve a usar FOO como nombre descubre el cambio, quizá mediante NEWNAME. El directorio y la sesión seleccionada no son el mismo plano de realidad.

Los números se movían antes de que llegara la noticia

Los números de secuencia de RFC 2060 describen posiciones actuales. Al expurgar un mensaje, los posteriores se desplazan. Pero el servidor no puede insertar EXPUNGE mientras responde a FETCH, STORE o SEARCH. La lista puede haber cambiado y el cliente aún no está autorizado a saberlo por esa vía.

RFC 2180 documentó cuatro salidas. El servidor puede retener mensajes fantasma hasta completar el FETCH; devolver solo mensajes supervivientes y terminar con NO; devolver datos normales y respuestas NIL para los desaparecidos, terminando con OK; o impedir el expunge mientras haya varios accesos.

Una respuesta NIL no siempre distingue ausencia de contenido de ausencia del mensaje. Por eso el cliente debe usar NOOP cuando la ambigüedad importe, recibir los EXPUNGE pendientes y reconstruir el mapa. Un parser que acepta la forma sintáctica pero omite esta reconciliación no ha implementado la responsabilidad completa.

STORE.SILENT también limita la semántica de éxito. El servidor puede modificar todos los mensajes todavía existentes y devolver OK, aunque parte del rango solicitado ya se haya expurgado. La orden completó una operación válida; no certificó que el conjunto original sobreviviera intacto.

COPY creó una isla de determinación

Para COPY, los números se fijan en el momento de iniciar la orden. Si después llega un EXPUNGE, el servidor puede informar del cambio, pero una copia exitosa debe contener los mensajes que aquellos números designaban al principio. Si fracasa, el destino debe volver a su estado previo.

La garantía está acotada a la orden. No congela el buzón ni sincroniza otras sesiones. Es una isla de referencia estable dentro de un sistema que sigue cambiando.

El documento no es una medición del presente

La ficha del RFC Editor clasifica RFC 2180 como informativo, y el propio texto declara que no define por sí mismo la conformidad. Recoge prácticas existentes y consenso razonable de la lista IMAP; para la norma base remite a RFC 2060. No demuestra qué hace hoy un proveedor, cuántos sistemas eligieron cada estrategia ni si una implementación concreta borra datos físicamente.

Su valor histórico es mostrar que la libertad del servidor tenía una contraparte contractual: el cliente debía programarse contra todo lo permitido por el protocolo, no contra la costumbre de un servidor conocido.

RFC 2177 permitió recibir actualizaciones mediante IDLE; RFC 7162 incorporó mod-sequences, VANISHED y QRESYNC para reducir el coste de volver a sincronizar. Son mejoras de aviso y recuperación. No convierten el OK de una orden en prueba de que nombre, acceso, secuencia y bytes convergieron a la vez.

La enseñanza puede expresarse como cuatro recibos: orden completada, nombre retirado, sesiones existentes privadas de acceso y datos destruidos. El primero no sustituye a los otros tres.