Resumen

  • La revisión 06 del borrador Expires deja deliberadamente abierta la expresión «pierde su validez»: una fecha declarada no es una medición independiente.
  • El software no debe rechazar ni descartar por ese único campo, y no debería borrar sin que el dueño del buzón lo haya configurado de forma deliberada.
  • Ordenar la vista, conservar los bytes, retener evidencia y purgar definitivamente son decisiones distintas; un estado cómodo no debe ocultarlas.

La alerta vieja que todavía explica el incidente

Un sistema de pagos envía una alerta que caduca en dos horas. La cola de correo se retrasa y el equipo de seguridad la abre al día siguiente. Ya no sirve como aviso preventivo, pero sí para reconstruir el momento en que apareció el riesgo. La utilidad inmediata terminó; la función probatoria acaba de empezar.

El borrador 06 del grupo Mail Maintenance amplía el uso de Expires en el correo de Internet. El creador escribe una fecha y hora a partir de la cual considera que el mensaje «pierde su validez». Solo puede haber un campo. El texto no define con mayor precisión la palabra, porque no existe consenso que abarque los usos heredados.

Ese límite impide una falsa universalidad. Una oferta, una cita, un parte periódico y un código temporal caducan de maneras diferentes. Ninguna de esas fechas prueba recepción, lectura, fraude, consentimiento para borrar ni fin de una obligación de conservación.

El documento está en la cola del RFC Editor y busca el nivel Proposed Standard. Sigue siendo un Internet-Draft activo, no un RFC publicado ni un censo de despliegues.

La fecha pertenece al mensaje; la acción pertenece al receptor

La norma propuesta permite usar el dato para atenuar mensajes, ocultarlos de una vista predeterminada o ofrecer reglas de limpieza. También dibuja una línea: no se debe rechazar ni descartar un correo basándose solo en Expires. No se debería eliminar un mensaje pasado de fecha salvo que el propietario del buzón haya elegido deliberadamente ese comportamiento.

Rechazar evita la entrega. Descartar puede aceptar y hacer desaparecer. Ocultar afecta la interfaz. Mover conserva el contenido en otro lugar. Borrar una copia no garantiza la desaparición de diarios o copias de seguridad. Purgar puede cerrar la recuperación. Llamar a todo «gestionar el vencimiento» destruye la trazabilidad.

La decisión local debe indicar quién configuró la regla, qué componente la ejecutó, si el resultado es reversible y qué réplicas quedan.

Un dominio autenticado también puede tener incentivos

DKIM ayuda a atribuir campos firmados a un dominio responsable. No certifica que el instante sea correcto ni que el destinatario deba obedecerlo. La autenticidad del emisor y la autoridad sobre el archivo del receptor son preguntas distintas.

El propio borrador describe abusos. Un remitente malicioso puede usar una fecha pasada para reducir la visibilidad y las denuncias, afectando incluso el aprendizaje de filtros. Una fecha inminente puede crear urgencia y dificultar la reclamación posterior. Una fecha muy distante puede intentar mantener el mensaje destacado.

Convertir el campo en señal antifraude sería incoherente: quien podría beneficiarse de ocultar la prueba elige el valor. La automatización tiene que conservar la asimetría de autoridad.

No existe un solo reloj de caducidad

El encabezado tiene la hora del creador. El transporte registra saltos y recepción. El cliente conoce la primera visualización. El negocio tiene su plazo real. El archivo registra retención y purga. La zona horaria, el desfase de reloj o un error de análisis pueden separarlos aún más.

Por eso conviene conservar el valor bruto, el resultado del análisis y el contexto temporal. «Caducado» es una conclusión demasiado compacta para reemplazarlos.

Un modelo seguro mantiene cuatro planos: declaración del remitente; estado de presentación; estado de almacenamiento; y estado probatorio. Un mensaje puede estar oculto pero buscable, eliminado del buzón pero presente en un diario, o caducado comercialmente y retenido por un litigio.

Un recibo local puede registrar identificador o huella, recepción, valor bruto y fecha interpretada, identidad disponible, versión de la regla, consentimiento del propietario, acción visual, acción de almacenamiento, ventana de recuperación y purga final. No es un nuevo requisito del protocolo, sino una disciplina para no fingir resultados.

Interoperar sin entregar soberanía

La historia va de Expiry-Date en RFC 1327 al mapeo de RFC 2156 y al registro de RFC 4021, que lo marcó como no apto para uso general. La revisión 06 ampliaría el uso, pero no el poder del remitente.

Una especificación mínima puede fijar nombre, sintaxis y significado limitado. Cada usuario o proveedor conserva decisiones futuras. No adoptar una política de limpieza no vuelve inválido al cliente; adoptar otra tampoco autoriza a imponerla fuera de su buzón.

La prueba está en el código en ejecución: aceptación, vista, almacenamiento, recuperación y resultado. Ni la publicación del estándar, ni la fecha, ni una firma demuestran por sí mismas esos efectos.

Sources

  1. Borrador Expires 06, texto
  2. Borrador Expires 06, HTML
  3. Datatracker, revisión 06
  4. Historial en Datatracker
  5. RFC 1327
  6. RFC 2156
  7. RFC 4021
  8. RFC 5322
  9. RFC 5536
  10. RFC 5598
  11. RFC 6376, DKIM
  12. RFC 7942
  13. Registro IANA de encabezados
  14. Lu Heng, Minimum Initial Specification
  15. Lu Heng, On Reality Layers
  16. Lu Heng, Running Code Primary