Resumen

  • En marzo de 2011, la RFC 6154 definió atributos opcionales que un servidor IMAP puede incluir en LIST para señalar buzones \Sent, \Drafts o \Trash aunque sus nombres visibles sean distintos.
  • La marca comunica una función, no una rutina uniforme de archivo. El servidor puede guardar las copias enviadas automáticamente o indicar al cliente que las guarde. Un buzón puede llevar varios atributos y varios buzones pueden compartir uno.
  • LIST extendido permite anunciar SPECIAL-USE; CREATE y METADATA ofrecen vías opcionales para pedir o cambiar funciones, sujetas a la decisión del servidor. El registro de IANA mantiene los nombres comunes de los atributos.

El nombre visible no era una instrucción fiable

Un usuario añade la misma cuenta a dos programas. El primero encuentra una carpeta que parece servir para los mensajes enviados. El segundo crea otra porque no reconoce el nombre. Pronto existen dos archivos parciales de la correspondencia saliente. También puede ocurrir lo contrario: ambos programas esperan que el servidor guarde las copias y nadie lo hace. La pantalla muestra un problema de configuración; para el usuario es una pérdida de memoria sobre lo que escribió.

Una guía del IETF de 1999 ya hablaba de nombres convencionales como «Sent Mail» y «Trash». Una costumbre ayuda a las personas, pero un programa necesita algo más preciso. El servidor puede usar otro idioma, el usuario puede renombrar la carpeta, y la palabra «Enviados» no revela quién la alimenta. El cliente estaba convirtiendo una decisión de almacenamiento en una apuesta sobre ortografía.

La RFC 6154 trasladó la respuesta al servidor. Definió siete marcas iniciales: \All, \Archive, \Drafts, \Flagged, \Junk, \Sent y \Trash. Se entregan junto con los demás atributos del buzón en LIST. El cliente busca \Sent aunque el buzón se llame SentMail o tenga un nombre elegido por su propietario. La función viaja en el protocolo; el nombre de la carpeta puede seguir siendo humano.

El cambio asigna el trabajo al actor que conoce mejor la disposición del almacén. Un programa recién instalado no sabe qué buzones ha reservado el servicio. El servidor sí puede declarar la función que atribuye a cada uno. Eso reduce las preguntas al usuario sin arrebatarle el control de su cuenta. El servidor informa; cliente y usuario siguen tomando decisiones sobre uso y presentación.

Una función anunciada no mete cartas en la carpeta

La RFC reconoce diferencias operativas. Una marca \Sent puede acompañar a un servidor que coloca automáticamente las copias de salida. En otro servicio solo aconseja al cliente que las guarde allí. Si el cliente espera al servidor equivocado, la carpeta queda vacía. Si guarda una copia mientras el servidor ya lo hace, aparecen duplicados. La marca resuelve dónde se supone que está el buzón de enviados; el recorrido de un mensaje revela quién hizo el trabajo.

\All puede ofrecer una vista virtual y omitir mensajes de \Trash o \Junk. \Archive depende de lo que el servidor entiende por archivar. \Drafts puede ser una vista de mensajes marcados como borradores o el destino al que el cliente los envía. \Trash puede ajustarse al modelo de eliminación del servidor o servir al cliente que no usa el indicador IMAP \Deleted como forma principal de descartar. Una palabra común en la lista no iguala todos esos comportamientos.

Hay más combinaciones que una carpeta por función. Un buzón puede llevar ninguna marca, una o varias. Dos buzones pueden llevar \Sent. Los papeles suelen depender del usuario: dos personas pueden compartir un buzón físico sin asignarle el mismo papel en sus cuentas. Suponer que siempre existe un único destino sería repetir la vieja adivinanza con una cadena estandarizada.

El registro de atributos de buzón de IANA fija un vocabulario y sus referencias. No guarda mensajes ni registra qué programa depositó cada copia. Una entrada para Sent ayuda a que implementaciones distintas hablen de la misma función. El hecho de que el mensaje esté allí se comprueba en el almacén en funcionamiento.

Una petición de función podía ser rechazada

La extensión utilizó el marco LIST extendido. Un servidor que lo soporta anuncia SPECIAL-USE en CAPABILITY. El cliente puede solicitar solo buzones con marca especial o pedir que las marcas aparezcan en la respuesta; la selección implica el retorno de los atributos. El servidor también puede incluir marcas en un LIST ordinario, que no dispone de una señal CAPABILITY separada para ese uso. Hay que leer el intercambio completo, no una sola línea del saludo.

RFC 6154 también añadió el parámetro opcional USE a CREATE. Un cliente puede pedir que un buzón nuevo nazca con cierta función si el servidor anuncia CREATE-SPECIAL-USE. El servidor puede negar una asignación conflictiva, mover la designación desde otra carpeta o admitir duplicados. Si no puede crear el buzón con la función pedida, debe rechazar la operación sin crear el buzón. El cliente recibe una decisión, no una carpeta a medias que pueda tratar como configurada.

En servidores que admiten IMAP METADATA, /private/specialuse puede exponer y, si se permite, cambiar las funciones de buzones existentes. El servidor debe validar el cambio conforme a sus reglas. Renombrar una carpeta, declararle una función y mover un mensaje son actos diferentes. Sus respuestas también lo son.

La función puede activar consecuencias reales. RFC 6154 describe el caso de \Junk: si el servidor coloca automáticamente allí el correo considerado basura y se permite asignar esa función a un buzón compartido, mensajes legítimos mal clasificados pueden quedar a la vista de otras personas. El servidor debe decidir qué petición acepta. La pequeña marca se convierte en una palanca cuando gobierna una acción automática.

La norma describe anuncio, solicitud y validación de funciones. Para saber dónde acabó una copia enviada de una cuenta concreta faltan la respuesta CAPABILITY/LIST fechada, cualquier cambio CREATE o METADATA y el destino observado del mensaje. El nombre de la carpeta es la prueba más débil.