Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.36

arc-identity

<domain>

От чьего имени заверена пересылка
в конфигурации это строкаarc-identity sender-or-fromвнутри блока <domain>
Разница с обычной подписью, которую легко пропустить

Задаёт имя, от которого ставится заверение. Умолчание — sender-or-from: брать из заголовка Sender, а если его нет, из From. Значения те же, что у dkim-identity, включая strict-from.

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

Практическое следствие одно: заданное здесь имя обязано иметь свою запись в DNS. Для обычной подписи можно было поставить имя, а ключ взять по домену; здесь имя и домен ключа — одно и то же.

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

Умолчание годится, пока пересылают почту одного домена. Имя возьмётся из заголовков, и ключ найдётся по нему же.

Свой домен — когда пересылают чужое. Тогда заверение ставится от вашего имени и проверяется по вашей записи в DNS — именно так и задумано у пересыльщика.

Имя обязано совпадать с доменом объявления domain-key или быть его поддоменом. Правило то же, что у обычной подписи.

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

<domain *>
    arc-sign yes
    arc-identity @esp123.com</domain>
Открытый ключ получатель будет искать по имени key1._domainkey.esp123.com — то есть по заданному здесь домену, а не по домену из From.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Переносят значение с обычной подписи

§ 3.3.10.36

Чем чреватоСтроки принимают одни значения, но здесь имя становится доменом подписи. Имя без своей записи в DNS оставляет заверение непроверяемым.
Как заметитьЗаголовки заверения есть, приёмник не может их проверить.
Как правильноСтавить домен, чья запись опубликована, и следить за совпадением с объявлением ключа.

Оставляют умолчание при пересылке разных доменов

наш опыт

Чем чреватоИмя берётся из заголовков каждого письма, то есть у каждого своё. Ключ придётся иметь на каждый пересылаемый домен — а его у вас нет, это чужие домены.
Как заметитьЧасть пересылаемых писем без заверения.
Как правильноЗадать своё имя явно — пересыльщик заверяет от себя.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · linux
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
arc-identity <enumeration-or-address>
Значения
домен или адрес электронной почты; sender-or-from — брать из заголовков; strict-from — только точный домен из From
Умолчание
sender-or-from § 3.3.10.36
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Задаёт домен подписи, поэтому обязано совпадать с доменом объявления domain-key или быть его поддоменом. Подхватывается по pmta reload.
⇄

Связанные директивы

2 связи

Без чего не работает

arc-sign<domain>Ничего не делает, пока заверение пересылки не включено. § 3.3.10.36

То же имя в других блоках

dkim-identity<domain>Та же настройка для обычной подписи — но там имя дополняет домен ключа, а здесь заменяет его. § 3.3.10.36

Как проверить на узле
Действующее значение печатает команда настроек очереди; по какому имени ищется ключ — видно в заголовках заверения:
pmta show settings gmail.com/vmta1 | grep -i arc-identity
dig +short TXT key1._domainkey.esp123.com
Пустой ответ второй команды означает, что заверение непроверяемо: записи по заданному имени нет. Хаб этой строки не пишет.
◇

Что ещё почитать

3 статьи

◇Не отправлять то, что не пройдёт проверку у получателяУзел сам проверяет SPF своей почты перед отправкой: не прошло — отбивает, не дожидаясь чужого отказа.◇Как узел подписывает письма и выбирает ключКлюч выбирается по домену отправки из заголовков, перебором объявлений сверху вниз.◇Заголовок письма, которым подающая сторона правит подписьПять параметров в X-DKIM-Options: селектор, домен, имя подписи, способ запроса и список ключей.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подпись и аутентификация писем
Соседние настройки блока <domain>:dkim-signcheck-spf-outbounddkim-identitydkim-headersdkim-disallow-adding-headersВсе 135 директив блока →