log-resolution

<domain>

Записывать ли разрешение имён для этого приёмника
в конфигурации это строкаlog-resolution falseвнутри блока <domain>
Почему письма не находят приёмника

Строка добавляет в журнал ход поиска имён и маршрутов для этого приёмника. Умолчание — выключено.

Это инструмент разбора неисправностей DNS, и вендор называет его именно так: полезен, когда виноваты неверные записи в зоне.

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

Включать надо на конкретный приёмник, а не на <domain *>: разрешение имён идёт при каждом соединении, и общая запись даёт объём без пользы.

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

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

Значение Когда
no (умолчание) обычная работа
yes письма не уходят одному приёмнику, и подозрение на DNS
Умолчание и предмет записи — из руководства (§ 3.3.10.4). Порядок разбора и предупреждение про объём — наши.
Пример в конфигурации
# на время разбора
<domain …>
    log-resolution true</domain>
После разбора строку убирают. При правках через Хаб она и так исчезнет при следующем применении конфигурации.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают в блоке со звёздочкой

наш опыт

Чем чреватоРазрешение имён идёт при каждом соединении со всеми приёмниками сразу. Журнал растёт кратно, а разбираемый случай в нём теряется.
Как заметитьЗаписей много, нужного приёмника среди них не найти.
Как правильноОграничить блоком конкретного приёмника.

Ищут эти записи в файле учёта

наш опыт

Чем чреватоЖурнал и учёт — разные файлы и разные вопросы. В учёте есть результат по письму, но не ход работы узла.
Как заметитьВ файле учёта нет ничего похожего на ожидаемые записи.
Как правильноСмотреть журнал, путь к которому задан строкой log-file.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
log-resolution <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.10.4
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу, — поэтому строка в <domain *> включит запись сразу для всех приёмников. Журнал при этом один на узел — записи всех включённых переключателей ложатся вперемешку.
⇄

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

1 связь

Как проверить на узле
Смотрим журнал MTA, отобрав нужные строки:
grep -i "resolv\|dns\|mx" /var/log/pmta/log | tail -20
Видно, какие записи нашлись и к какому узлу MTA собрался подключаться. Пусто означает, что до разрешения имён дело не дошло.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью