Resumen

  • RFC 9787 distingue de hecho dos estados operativos: mientras un mensaje sigue siendo borrador, puede necesitar protección frente al almacenamiento remoto sin quedar disponible para los destinatarios; el cifrado para ellos corresponde al envío real.
  • Para un borrador protegido, el RFC exige cifrar únicamente para el certificado del propio usuario o una clave equivalente bajo su control, y prohíbe firmarlo con la clave de firma ordinaria. La continuidad entre varios clientes depende entonces de que compartan acceso al buzón y una capacidad secreta de descifrado que el propio RFC reconoce como problema no resuelto.
  • IMAP y JMAP pueden representar que un objeto es un borrador, pero ese estado de almacenamiento no constituye por sí solo una política criptográfica. La cuestión crítica es qué cliente puede leer, modificar y transformar ese objeto en un mensaje enviado.
  • Como propuesta editorial, no como requisito de RFC 9787, un «recibo de custodia de la intención del borrador» podría conservar evidencia mínima sobre esa transición sin registrar el contenido del correo ni convertir la trazabilidad en vigilancia general.

El valor de un borrador reside precisamente en que todavía puede cambiar. Una frase puede desaparecer, un destinatario puede ser retirado, una afirmación puede quedar matizada y el mensaje entero puede no enviarse jamás. El almacenamiento remoto complica esa libertad porque convierte un estado provisional en un objeto persistente que puede cruzar dispositivos, servidores y sesiones.

RFC 9787, publicado como RFC Informational en agosto de 2025 y no como documento Standards Track, aborda esa exposición en su sección 9.5. El punto de partida es sencillo: muchos agentes de usuario de correo, o MUA, guardan mensajes incompletos en una carpeta de borradores. Si esa carpeta reside en un servicio remoto —por ejemplo mediante IMAP—, guardar el borrador en claro puede exponer un texto que el mensaje final sí habría protegido criptográficamente. La seguridad del correo terminado no corrige retrospectivamente una copia provisional ya almacenada sin esa protección.

La recomendación intenta evitar que el cliente tenga que conocer demasiado pronto el destino final. RFC 9787 indica que un MUA debería cifrar todos los borradores salvo que sepa que el mensaje acabado se enviará en claro o que el almacenamiento de Drafts no es legible por un atacante potencial. La importancia de esa formulación está en la incertidumbre: el cliente puede no saber todavía si el texto acabará cifrado, quiénes serán exactamente sus destinatarios o incluso si será enviado.

El borrador protegido tampoco debe convertirse prematuramente en un mensaje para sus futuros receptores. RFC 9787 establece que debe cifrarse únicamente para el certificado del usuario —o para una clave equivalente que solo posea ese usuario—. La consecuencia operacional es deliberada: una persona inicialmente incluida en los campos de destinatarios no adquiere por ello capacidad de leer el borrador. El acceso de destinatarios corresponde a otra fase.

Ese diseño vuelve visible la frontera entre custodia y entrega. Durante la redacción, el problema es que el autor pueda recuperar y modificar su propio objeto sin entregárselo a terceros. En el envío real, el cliente puede aplicar el cifrado destinado a quienes efectivamente recibirán el mensaje. Entre ambos momentos cambia no solo un indicador de estado, sino el conjunto autorizado de lectores.

La firma plantea una separación parecida. Un MUA conforme no debe firmar el borrador mediante la clave normal del usuario. RFC 9787 advierte que una firma no repudiable sobre un texto aún inacabado podría ser interpretada como señal de compromiso si ese objeto se filtrara. Esa observación debe conservarse dentro de su contexto técnico: no demuestra por sí misma que toda firma digital produzca el mismo efecto jurídico en todas las jurisdicciones, relaciones contractuales o sistemas de firma.

La cautela del RFC es más concreta. La misma credencial utilizada para autenticar el mensaje finalmente enviado no debería convertir una etapa mutable en una declaración que parezca acabada. El documento sugiere que otra clave podría servir para coordinar firmas de borrador, pero no especifica ese mecanismo. La sugerencia reconoce una necesidad sin transformar el reconocimiento en interoperabilidad resuelta.

Ahí aparece el problema más difícil: varios clientes.

Un borrador que solo existe en un dispositivo puede protegerse con una clave disponible allí. Pero el escenario práctico que da sentido al almacenamiento remoto es precisamente el contrario: el usuario empieza en un cliente, continúa en otro y quizá envía desde un tercero. Para que el segundo MUA abra el borrador cifrado necesita dos cosas distintas: acceso al mismo buzón y una clave secreta capaz de descifrar el objeto.

RFC 9787 reconoce expresamente que la distribución segura de esas claves o certificados entre múltiples MUA sigue sin resolverse y queda fuera de alcance. La especificación puede establecer quién no debe recibir la clave del borrador —los destinatarios previstos— sin resolver cómo todos los dispositivos legítimos del autor obtienen la capacidad necesaria.

La dificultad no es puramente criptográfica. También es de continuidad del objeto. Si un portátil descarga la versión A, un teléfono crea la versión B y otro cliente todavía conserva una copia anterior, el sistema necesita saber qué versión se está modificando, qué escritura prevaleció o qué fusión ocurrió antes del envío. El cifrado impide ciertas lecturas; no decide por sí mismo qué modificación es la vigente.

Los protocolos de almacenamiento ofrecen piezas de esta maquinaria, no toda la política. IMAP4rev2 define el indicador \Draft, mientras RFC 6154 define el buzón de uso especial \Drafts. JMAP Mail utiliza $draft y documenta la transición en que ese estado se elimina al presentar el mensaje y el objeto pasa a Sent. Estas señales describen estados o ubicaciones del correo. No especifican, por sí mismas, qué clave debe proteger el borrador, cómo distribuirla entre dispositivos ni qué evidencia debería conservarse cuando el objeto deja de ser provisional.

S/MIME 4.0 y OpenPGP proporcionan mecanismos criptográficos de mensaje relevantes para el contexto, pero su existencia tampoco demuestra un despliegue generalizado de claves exclusivas de borrador sincronizadas entre varios clientes. En el corte de fuentes utilizado para este análisis tampoco había erratas coincidentes de RFC 9787. Y ninguna de las fuentes examinadas establece prevalencia de esta práctica, conformidad concreta de proveedores, tasas medidas de filtración, efectos jurídicos generales o un intercambio estandarizado de claves de borrador entre dispositivos.

Ese límite probatorio importa. Una recomendación técnicamente razonable no es evidencia de adopción.

Una propuesta: recibo de custodia de la intención del borrador

A partir de esa separación entre persistencia, edición y envío, propongo como herramienta editorial —no como requisito de RFC 9787 ni como extensión atribuida al IETF— un «recibo de custodia de la intención del borrador».

Su propósito sería estrecho: demostrar qué autoridad tuvo el objeto en cada transición importante sin conservar su contenido. El recibo acompañaría la continuidad entre dispositivos y, sobre todo, el cambio final de un objeto privado y mutable a un mensaje realmente presentado para entrega.

Debería registrar una referencia al objeto y su versión; la clase de almacenamiento; el alcance y la clase de la clave exclusiva del autor utilizada para proteger el borrador; qué clientes estaban autorizados técnicamente para descifrarlo y modificarlo; y el estado de último escritor o, si existió, de fusión. También debería dejar constancia de que la clave normal de firma del usuario no fue utilizada para firmar ese borrador. Eso no equivale a afirmar que dicha clave faltaba del dispositivo: la evidencia relevante es su no utilización para esa operación concreta.

Antes del envío, el recibo debería indicar además la ausencia de cifrado dirigido a destinatarios. Cuando el envío ocurra de verdad, debería registrar el evento, el cliente que lo ejecutó, la hora y un digest del conjunto final de destinatarios. A ello se sumarían un hash del objeto, la limpieza o tombstone de la copia provisional, el responsable del registro y una fecha de revisión o caducidad.

La restricción negativa es tan importante como los campos positivos. Este recibo no debería guardar el cuerpo, el asunto, la lista completa de destinatarios, claves, credenciales ni registros generales del comportamiento del usuario. No es un historial exhaustivo de redacción.

Tampoco conviene confundir hash con anonimato. Un hash ordinario puede permitir enumerar valores de baja entropía o correlacionar registros repetidos. Si la evidencia necesita resistir esa clase de inferencia, puede requerir construcción con clave o acceso controlado, además de finalidad estricta y retención breve. La trazabilidad deja de ser mínima si crea un segundo repositorio capaz de reconstruir relaciones que el diseño pretendía no conservar.

El recibo serviría así para responder una pregunta limitada: ¿qué ocurrió con la autoridad sobre este objeto cuando pasó de estar guardado a estar enviado? No probaría qué pensaba subjetivamente el autor ni resolvería por sí mismo disputas jurídicas. Su utilidad sería técnica y operativa: hacer auditable la transición sin sustituir el texto provisional por una nueva acumulación de datos sensibles.

Las tres lentes editoriales de Heng Lu ayudan a mantener esa propuesta dentro de límites verificables. Running-Code Primacy obliga a separar una recomendación escrita de un comportamiento efectivamente desplegado. Minimum Initial Specification favorece una frontera común pequeña: proteger el borrador, reservar el acceso de destinatarios para el envío y no pretender que la especificación resuelva todos los sistemas de sincronización. Reality Not Advocacy exige distinguir lo que RFC 9787 dice, lo que se deduce operacionalmente y lo que aquí se propone. Son lentes editoriales, no doctrina del IETF.

Ese método también evita adjudicar al RFC resultados que sus fuentes no prueban. Sabemos cómo debería protegerse un borrador conforme a la recomendación. Sabemos por qué otro cliente necesita capacidad de descifrado. Sabemos que el problema seguro de compartir esa capacidad queda fuera de alcance. No sabemos, a partir de estas fuentes, cuántos proveedores lo implementan, cuántos usuarios se benefician de ello ni con qué frecuencia falla.

Fuentes