arc-oversigned-headers

<domain>

Какие заголовки должны ломать заверение, если их добавят после него
в конфигурации это строкаarc-oversigned-headersвнутри блока <domain>
Сделать добавление заголовка заметным

Полный аналог dkim-disallow-adding-headers для подписи пересылки. Перечисленные имена ставятся в заверение лишний раз, и появление второго такого заголовка его ломает.

Задача та же: обычное заверение защищает имеющиеся заголовки, но не запрещает добавить ещё один. Второй Subject в письме с верным заверением показывается почтовым клиентом, а проверка проходит.

Умолчания нет. Где строка не задана, защита не действует.

Главная ловушка — забыть её при настройке пересылки. ARC придуман ровно для того, чтобы приёмник поверил пересыльщику; без этой строки заверение пересыльщика можно дополнить чужим заголовком, и оно останется верным. То есть механизм доверия работает против того, ради чего его включали.
Что делает Хаб. Не пишет: пересылки чужой почты у него нет. Появится — задавать её надо сразу вместе с arc-sign, тем же набором, что и у обычной подписи.
Рекомендуемые значения

Тот же набор, что у обычной подписи: отправитель, получатель, тема, адрес для ответа.

Задавайте сразу вместе с включением. Заверение без этой строки защищает слабее, чем от него ждут.

Не перечисляйте всё подряд. Каждое имя добавляется в заверение лишний раз; смысл есть только у заголовков, которые видит читатель.

Набор для начала — наш, тот же что и для обычной подписи. Из руководства здесь назначение строки и синтаксис.
Пример в конфигурации
# заверение и защита от дописывания заголовков — вместе
<domain *>
    arc-sign yes
    arc-oversigned-headers from,to,subject</domain>
Имена попадают в заверение лишний раз — приёмник видит, что заголовков с такими именами должно быть ровно столько, сколько было при подписи.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Не задают её вовсе

наш опыт

Чем чреватоЗаверение пересыльщика можно дополнить вторым Subject или From, и оно останется верным. Механизм, включённый ради доверия, начинает работать против него.
Как заметитьСтроки нет в конфигурации при включённом заверении.
Как правильноЗадать хотя бы from,to,subject.

Задают у обычной подписи и забывают здесь

наш опыт

Чем чреватоОбычная подпись защищена, заверение пересылки — нет. Приёмник, доверяющий цепочке заверений, получает незащищённое звено.
Как заметитьdkim-disallow-adding-headers задан, arc-oversigned-headers нет.
Как правильноДержать обе строки с одинаковым набором.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · linux
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
arc-oversigned-headers <header-list>
Значения
имена заголовков через запятую; умолчания нет — без строки защита не действует
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Умолчания нет: где строка не задана, защита не действует. Подхватывается по pmta reload.
Как проверить на узле
Действующее значение печатает команда настроек очереди; результат виден по повторам имён в заголовке заверения:
pmta show settings gmail.com/vmta1 | grep -i oversigned
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
Имя, встречающееся в перечне подписанных заголовков дважды, и есть защищённое этой строкой. Хаб её не пишет.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подпись и аутентификация писем