arc-expire-after

<domain>

Через сколько заверение пересылки перестаёт считаться действительным
в конфигурации это строкаarc-expire-after neverвнутри блока <domain>
Срок годности заверения

Аналог dkim-expire-after: добавляет в заверение момент, после которого оно считается просроченным. Умолчание — never.

У пересыльщика это соображение весомее. Он ставит заверение на чужие письма, которых у него много и которые он не составлял; сохранить такое письмо и разослать заново — заметно более естественный сценарий, чем с собственной рассылкой.

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

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

Считайте от срока жизни письма. Срок заверения должен быть заметно больше bounce-after.

Для пересылки срок уместнее, чем для рассылки. Чужое письмо с вашим заверением — более привлекательная цель для повторной отправки.

Не заменяет защиту от дописывания. От добавления заголовка защищает arc-oversigned-headers, и это разные задачи.

Соображение о ценности срока для пересыльщика — наше. Из руководства здесь оба вида значения и умолчание.
Пример в конфигурации
# срок заверения заметно больше срока жизни письма
<domain *>
    bounce-after 1d
    arc-expire-after 3d</domain>
Порядок величин тот же, что у обычной подписи: письмо успеет уйти в отказ раньше, чем заверение просрочится.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят срок короче срока жизни письма

наш опыт

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