Кратко

  • RFC 5293 направляет обычные проверки, сохранение и отправку к текущему изменённому заголовку, а MDN, DSN и неявное сохранение после ошибки — к исходному неизменённому.
  • Изменённая форма считается тем же сообщением при удалении дублей, поэтому успешный сценарий не доказывает, какая версия сохранена, проверена или доставлена.

Ошибка была в модели журнала

Почтовый шлюз удалял внешний штамп одобрения, добавлял внутренний и пересылал письмо. В интерфейсе всё было зелёным. Позже DSN показал старые поля, архив — новые, а DKIM перестал сходиться.

addheader и deleteheader работают с последовательным текущим состоянием. Поле добавляется в начало либо с :last в конец. Удаление может охватывать все вхождения или позицию :index; позиция считается до проверки значения. После удаления нумерация следующего шага уже иная.

Один финальный хеш не объясняет промежуточное решение. Нужна цепочка состояний.

Исходник остаётся нормативным входом

Проверки exists, header, действие vacation и обычные операции хранения, отправки и изменения видят текущий заголовок. Правки проходят через включённые сценарии. Но MDN, DSN и аналогичные уведомления обязаны брать исходный заголовок. При аварийном завершении неявное сохранение также использует исходник. Обычное неявное сохранение происходит после правок, если его не отменили.

Поэтому запись keep без причины не определяет сохранённую форму.

Одна идентичность не требует одинаковых байтов

Для дедупликации отредактированное письмо остаётся исходным сообщением. Два лишних keep не должны создать две копии в одном ящике, но реализация может выбрать исполняемое действие.

Ключ дедупликации отвечает на вопрос «сколько», а не «какие заголовки». Его нельзя подменять хешем представления или фактом доставки.

Тихий отказ — тоже результат

Локальная политика может запретить правку, и попытка будет проигнорирована без ошибки. Удалять Received и Auto-Submitted нельзя; редактирование Subject должно поддерживаться. Сохранение Received защищает след против SMTP-петель.

Нормальное завершение не доказывает применение каждой команды. Журнал должен различать запрос, решение политики и фактическое изменение.

Подпись относится к конкретному слою

Правка способна нарушить DKIM, включая подпись, подтверждавшую отсутствие поля. В S/MIME и OpenPGP/MIME внутренняя подписанная копия может остаться прежней при изменении внешнего заголовка. Итог зависит от проверенного слоя.

Правильный синтаксис также не подтверждает происхождение: отправитель может заранее поставить похожий штамп. Сначала следует заморозить и проверить вход, затем изолировать недоверенные метки и только после этого выпустить локальное утверждение.

Что должно остаться в квитанции

Сохраните хеш исходного заголовка, порядок всех вхождений, версию сценария и журнал каждого действия: селектор, сравнение, решение политики, текущий хеш до и после, прочитанную форму. Добавьте результаты подписи, ключ дедупликации, выбор избыточного действия, подтверждение хранения или отправки и независимое наблюдение на стороне назначения.

Выбор redirect доказывает ветвление сценария, но не приём письма получателем.

Источники