arc-headers

<domain>

Какие заголовки попадают под заверение пересылки
в конфигурации это строкаarc-headersвнутри блока <domain>
Что защищено заверением

Полный аналог dkim-headers для подписи пересылки. Обязательный набор совпадает — около тридцати заголовков подписываются всегда, если есть в письме, — а строка к нему добавляет.

Особенность пересылки. Заголовки, которые добавляете вы сами как пересыльщик — метка списка в теме, служебные пометки, — попадают под заверение штатно: оно ставится после ваших правок. Заверение отвечает за письмо в том виде, в каком оно уходит от вас.

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

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

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

Сузить обязательный набор нельзя, как и у обычной подписи.

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

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

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

Перечисляют заголовки чужих отправителей

наш опыт

Чем чреватоПри пересылке письма приходят от разных отправителей, и набор заголовков у них разный. Названный отсутствующий читается как удалённый в пути — проверка не проходит.
Как заметитьПровалы проверки заверения у части пересылаемых писем.
Как правильноОставить в списке только заголовки, которые ставит сам пересыльщик.

Пытаются сузить набор

§ 3.3.10.35

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