База знаний PMTA›Механизм§ 10.4

Подпись, которая сохраняет чужую проверку при пересылке

ARC signing

Кому она нужна и кому нет

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

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

Оно устроено поверх того же ключа. Объявления domain-key, правило выбора, набор строк — всё как у обычной подписи, только с приставкой arc-.

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

Что делает Хаб. Не задействует и не планирует: узлы Хаба отправляют собственную почту, а не пересылают чужую. Механизм понадобится, если появится сценарий пересылки — например, приём и переотправка почты клиента.

Пример в конфигурации

# ключ тот же, что и у обычной подписи; набор строк — свой
domain-key key1, esp123.com, /etc/pmta/key1.esp123.com.pem

<domain *>
    dkim-sign yes
    arc-sign yes    arc-identity @esp123.com</domain>

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

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

▲

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

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

Включают на рассылке собственных писем

наш опыт

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

Как заметитьARC включён на узле, который ничего не пересылает.

Как правильноВыключить; механизм для пересыльщиков.

Рассчитывают на него на Windows

§ 10.4

Чем чреватоПоддержка появилась в версии 6.0r3 и только для Linux — руководство говорит это прямо. На Windows строки принимаются, а подписи нет.

Как заметитьСтроки заданы, заголовков ARC в письмах нет.

Как правильноПроверить платформу и версию узла.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · linux

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

⇄

Связанные записи

1 связь

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

Как узел подписывает письма и выбирает ключТе же объявления ключей и то же правило выбора, только набор строк подписи другой. § 10.4.2

Как проверить на узле

Работает ли, видно по заголовкам письма: их появляется сразу три, с одинаковым номером в цепочке:

pmta show settings gmail.com/vmta1 | grep -i arc-
grep -ci 'ARC-Seal' /var/log/pmta/pmta.log

Три заголовка — ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results — ставятся вместе; появление одного без остальных означает сбой. Хаб этот механизм не задействует.

◇

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

3 статьи

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

В Хабе

Цена ошибки: безопасно: неверное значение ничего не ломает
Сценарии: Подпись и аутентификация писем