Knowledge base

log-resolution

<domain>

Whether to log name resolution for this receiver
in the configuration this is a linelog-resolution falseinside the block <domain>
Why messages cannot find the receiver

The line adds to the log the course of name and route lookup for this receiver. The default is off.

This is a tool for investigating DNS faults, and the vendor calls it exactly that: useful when wrong records in the zone are to blame.

It answers a question not visible in accounting. There you will see only the result — the message did not go out; here you can see which records were found, which were not, and where the node was going to connect.

Enable it for a specific receiver, not for <domain *>: name resolution happens on every connection, and a general record gives volume without benefit.

The main trap is leaving it on after the investigation. The line breaks nothing and therefore outlives the investigation: the log grows, rotation speeds up, and last week’s entries are pushed out before they are needed.
What the Hub does. It does not write it: it is enabled by hand for the duration of an investigation. The Hub rewrites the configuration entirely, and a line added by hand will disappear at the next apply — in this case, that is exactly right.
Recommended values

Enabled for the duration of an investigation and turned off afterwards:

Value When
no (default) normal operation
yes messages do not go out to one receiver, and DNS is suspected
The default and the subject of the record come from the manual (§ 3.3.10.4). The order of investigation and the warning about volume are ours.
Example configuration
# for the duration of the investigation
<domain …>
    log-resolution true</domain>
After the investigation the line is removed. With edits through the Hub it will disappear anyway at the next configuration apply.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling it in the wildcard block

our experience

What it costsName resolution happens on every connection with all receivers at once. The log grows several-fold, and the case under investigation gets lost in it.
How to spot itThere are many entries, and the needed receiver cannot be found among them.
How to do it rightLimit it to the block of a specific receiver.

Looking for these entries in the accounting file

our experience

What it costsThe log and accounting are different files and different questions. Accounting has the result per message, but not the course of the node’s work.
How to spot itThere is nothing resembling the expected entries in the accounting file.
How to do it rightLook at the log whose path is set by the log-file line.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
log-resolution <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.4
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file — so the line in <domain *> enables logging for all receivers at once. The log, meanwhile, is one per node — entries from all enabled switches land in it intermixed.
How to check on the node
We look at the engine log, filtering the relevant lines:
grep -i "resolv\|dns\|mx" /var/log/pmta/log | tail -20
You can see which records were found and which host the engine was going to connect to. Nothing means things did not get as far as name resolution.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability