arc-identity-fallback

<domain>

Запасное имя заверения, если по основному ключа не нашлось
в конфигурации это строкаarc-identity-fallbackвнутри блока <domain>
Для пересыльщика это норма, а не исключение

Работает так же, как dkim-identity-fallback: не нашёлся ключ по основному имени — берётся запасное. Требует заданного arc-identity.

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

Отсюда простой вывод: при пересылке разумнее задать своё имя прямо в arc-identity, а эту строку держать для случая, когда часть отправителей всё же отдала ключи.

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

При пересылке ставьте своё имя основным. Откат оставьте для тех отправителей, чьи ключи у вас есть.

Имя должно совпадать с доменом объявления domain-key или быть его поддоменом — как и основное.

Без arc-identity строка не работает. Требование руководства, а не рекомендация.

Совет ставить своё имя основным — наш. Из руководства здесь назначение строки и требование задать основное имя заверения.
Пример в конфигурации
# часть отправителей отдала ключи, остальных заверяем от себя
domain-key key1, esp456.com, /etc/pmta/key1.esp456.com.pem

<domain *>
    arc-sign yes
    arc-identity sender-or-from
    arc-identity-fallback @esp456.com</domain>
Порядок здесь такой: сначала ищется ключ отправителя, и только не найдя его, узел заверяет письмо своим именем.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Задают без основного имени

§ 3.3.10.37

Чем чреватоСтрока не работает: руководство требует заданного arc-identity. Запасной вариант выглядит настроенным и не срабатывает ни разу.
Как заметитьЧасть писем уходит без заверения.
Как правильноЗадать основное имя рядом.

Строят пересылку на откате

наш опыт

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