Resumen

  • RFC 5293 hace que la vista del encabezado dependa de la acción: el flujo ordinario usa el estado actualizado, pero los avisos de disposición y la conservación implícita por error usan el original.
  • La versión editada sigue siendo el mismo mensaje a efectos de deduplicación; por eso una auditoría debe registrar qué vista consumió cada paso y qué resultado se observó después.

El panel verde no resolvía la contradicción

Un banco usaba Sieve para quitar una marca de aprobación recibida del exterior, insertar una clasificación interna y enviar el correo a una cola de revisión. El motor informó éxito. Días después, el equipo de fraude encontró que el DSN mostraba la marca antigua, la copia guardada mostraba la nueva y DKIM ya no validaba.

El primer impulso fue buscar una copia manipulada. El problema real era más sencillo: se había conservado el estado final, pero no la secuencia que relacionaba cada acción con su vista.

addheader incorpora un campo al comienzo, salvo que :last lo lleve al final. deleteheader puede eliminar todas las apariciones o una posición concreta. La cuenta empieza en uno y puede invertirse con :last; el índice se decide antes de comparar el valor. Tras borrar una aparición, la numeración cambia para la instrucción siguiente.

El encabezado no es un bloque estático durante la ejecución. Es un estado ordenado.

La norma conserva el pasado a propósito

Las pruebas exists y header, la respuesta de vacaciones y las acciones que almacenan, envían o alteran el mensaje trabajan con el estado vigente tras las modificaciones anteriores. Los scripts incluidos también reciben esos cambios y devuelven los suyos al llamador.

Hay excepciones decisivas. Un MDN, un DSN o una notificación parecida debe generarse con el encabezado original sin editar. Si un error termina la ejecución, la conservación implícita usa asimismo el original. En cambio, la conservación implícita normal se concibe al final, después de las ediciones, si no fue cancelada.

Por tanto, registrar “se ejecutó keep” sin anotar su causa pierde la regla que selecciona la evidencia.

Deduplicar no equivale a igualar

La extensión obliga a considerar la forma modificada y la original como un mismo mensaje para evitar duplicados. Si dos acciones redundantes piden guardarlo en la misma carpeta, solo debe aparecer una copia, aunque la implementación pueda escoger cuál de las acciones ejecuta.

La identidad operativa no exige igualdad byte a byte. Tampoco una diferencia de bytes demuestra un segundo mensaje. El identificador de deduplicación, la vista utilizada y la copia finalmente observada son datos distintos.

El silencio también necesita telemetría

La política local puede limitar los cambios. Un intento prohibido se ignora en silencio. Nunca se puede autorizar el borrado de Received ni Auto-Submitted; la modificación de Subject, en cambio, debe estar disponible. Proteger Received conserva la cadena necesaria para detectar bucles SMTP.

Un script sin excepción no garantiza que su orden se aplicara. La bitácora debe distinguir intento, decisión de política y efecto comprobado. También debe preservar los campos retirados: una defensa que borra una marca falsa antes de congelarla puede destruir prueba útil.

Las firmas no siguen todas la misma capa

Una edición puede invalidar DKIM, incluso cuando la firma certificaba que cierto campo no existía. En S/MIME y OpenPGP/MIME puede sobrevivir una copia interna firmada mientras cambia el encabezado exterior. El verificador y el archivo pueden estar describiendo capas distintas.

Además, un encabezado bien formado no es confiable por ese solo hecho. El remitente puede anticiparse y crear una etiqueta similar a la del filtro. La secuencia segura es capturar y verificar la forma recibida, neutralizar los sellos no confiables y emitir una afirmación local con procedencia clara.

La prueba mínima para una decisión máxima

El recibo debería contener el hash del encabezado original, la lista ordenada de apariciones, la revisión del script y un registro por acción. Para cada paso: selector, comparador, patrón, decisión local, hash antes y después y vista que consumió la siguiente operación.

También hacen falta la verificación de firma en ambas fronteras, la clave de equivalencia usada para deduplicar, la acción redundante elegida, la confirmación de almacenamiento o envío y una observación independiente del destino. Elegir redirect no prueba que el receptor aceptó el mensaje.

Fuentes