Resumen

  • RFC 3503 convirtió $MDNSent en memoria común para que varios agentes que abrían el mismo buzón IMAP no generaran notificaciones de disposición duplicadas.
  • La marca registraba una prohibición futura, no necesariamente un envío pasado: también aparecía tras una negativa, en copias enviadas y en mensajes sin terminar.

Imaginemos el mismo buzón abierto por una aplicación de escritorio, un portátil y otro agente remoto. El primero encuentra una petición de notificación de disposición y toma una decisión. Su archivo local puede recordar lo ocurrido. Los otros dos no leen ese archivo. Sin una señal alojada junto al mensaje, cada agente puede iniciar de nuevo el mismo razonamiento y multiplicar las respuestas.

La solución de RFC 3503 fue pequeña a propósito. Publicado en marzo de 2003, el documento no creó un comando IMAP ni una nueva respuesta. Definió la palabra clave especial $MDNSent y estableció cómo debían interpretarla los agentes de usuario. El buzón común transportaría el mínimo estado necesario para coordinar clientes independientes.

Ese mínimo no era la crónica de un envío. El nombre sugiere que ya salió una MDN, pero el procedimiento exigía fijar la marca después de ciertos tratamientos automáticos tanto si la notificación había sido enviada como si no. El usuario podía negar el permiso y el cliente podía registrar igualmente la marca. Las copias guardadas de mensajes enviados y los mensajes aún incompletos también debían recibirla.

Por ello, varias causas incompatibles compartían el mismo resultado visible. La inferencia correcta no era “se envió el acuse”, sino “ningún cliente conforme debe generar otro acuse para esta copia almacenada”. El dato tenía autoridad sobre una acción futura. No tenía autoridad para describir la creación, entrega o lectura de una notificación anterior.

El cliente empezaba por examinar PERMANENTFLAGS. El servidor debía poder conservar $MDNSent en particular o aceptar palabras clave arbitrarias. Pero la publicidad de una capacidad no garantizaba cada escritura. RFC 3503 contemplaba que STORE recibiera NO incluso después de anunciarse palabras arbitrarias, por ejemplo porque el buzón ya no admitiera otra.

La respuesta recomendada era abstenerse de enviar la MDN si no se podía guardar la marca. Esa política sacrifica una posible notificación para mantener el límite contra duplicados. Si el programa enviara sin dejar memoria compartida, otro programa podría hacerlo de nuevo. No es una transacción universal ni una garantía de una sola ejecución; es una decisión conservadora ante la pérdida del mecanismo coordinador.

\Recent parecía una señal disponible, pero RFC 3503 prohibió usarla como disparador. Cuando varias conexiones seleccionaban un buzón a la vez, IMAP no definía cuál vería el mensaje como reciente. La condición podía aparecer en una conexión y faltar en otra. \Seen podía ser una razón adicional para no enviar, y \Draft excluía un mensaje incompleto, pero ninguna debía fingir que significaba “MDN ya gestionada”. Con $MDNSent presente, el agente tenía que ignorar las demás para esta decisión.

La marca tampoco debía borrarse. Su transición era de una sola dirección. Esto reducía la posibilidad de reactivar accidentalmente la petición, aunque a cambio no conservaba un historial rico. Un bit permanente no decía qué agente lo escribió, a qué hora, con qué permiso ni qué ocurrió en el transporte. Era una cerradura lógica sin acta notarial.

Copiar un mensaje podía romper la propiedad si el estado se quedaba atrás. El cliente debía comprobar que COPY conservaba $MDNSent. Cuando la copia entre servidores se efectuaba mediante APPEND, el agente tenía que añadir la palabra correctamente. La misma regla explicaba por qué una copia de correo enviado o un mensaje sin terminar llegaban marcados: el destino no debía volver a tratar esos objetos como candidatos a un acuse.

El cruce con las ACL separó dos autorizaciones. El servidor seguía obligado a verificar que el cliente pudiera copiar el mensaje. Sin embargo, cuando la copia estaba permitida, la recomendación era preservar $MDNSent aun si el cliente no poseía el derecho general de escribir marcas. La conservación pertenecía a la semántica de la copia; no era una edición libre concedida al cliente.

La comparación sin distinción de mayúsculas evitaba otra forma de duplicación. Los ejemplos mezclaban $MdnSENt, $MdnSENT y $mdnsent y los trataban como una sola palabra. Una diferencia gráfica no podía partir en dos la memoria común.

El contenido de una MDN debe leerse por separado. RFC 2298 dio el formato temprano, RFC 3798 lo revisó y RFC 8098 lo convirtió en el estándar de Internet STD 85. Sus tipos describen eventos delimitados. displayed afirma que el agente mostró el mensaje a alguien que consultaba el buzón, pero no garantiza lectura ni comprensión. processed puede corresponder a una regla automática. deleted no revela si el mensaje se vio antes ni impide que se restaure.

La privacidad limita además la generación. La configuración predeterminada debería ser no enviar; ciertas discrepancias de dirección requieren consentimiento; una MDN puede falsificarse, perderse o utilizarse para amplificar correo. RFC 8098 rechaza expresamente la idea de que proporcione no repudio o garantice que el mensaje fue o no fue visto.

El registro posterior de palabras clave aclaró el propósito. RFC 5788 describió $MDNSent como una palabra compartida que especifica que no debe enviarse una MDN para el mensaje anotado. La definición oficial habla en futuro y en negativo. Describe una barrera.

RFC 9007 trasladó esa barrera a JMAP con una unión más explícita. MDN/send debe ir acompañado de la actualización $mdnsent; el servidor debe rechazar la llamada si no produciría el cambio, y mdnAlreadySent señala que el estado ya existe. Esa composición reduce la distancia entre acción y memoria dentro de JMAP. No prueba la lectura humana, y no convierte automáticamente los productos anteriores en conformes.

Una auditoría honesta conserva cada escalón. PERMANENTFLAGS informa de capacidad. Un STORE OK confirma una mutación. La presencia de $MDNSent ordena suprimir nuevas MDN. La construcción del informe, la entrega al sistema de correo, el tránsito y la llegada producen evidencias diferentes. El tipo de disposición aporta una afirmación acotada. Atención, comprensión y aceptación pertenecen a capas posteriores.

El valor histórico de RFC 3503 está en esa modestia. El sistema compartido necesitaba evitar repeticiones, no decidir qué había comprendido una persona. Un solo bit pudo coordinar a varios programas porque su autoridad era estrecha. Leer el nombre como un certificado sería pedirle una historia que nunca almacenó.

La lección continúa vigente en cualquier servicio distribuido. Una marca de “hecho” puede ser en realidad una orden de “no repetir”. Antes de convertirla en métrica, prueba o obligación, hay que leer todas las rutas que la escriben. En RFC 3503, algunas de esas rutas terminaban precisamente sin enviar nada.

Fuentes