Knowledge base

log-disabled-ips

<domain>

Whether to log when and which outgoing addresses were disabled
in the configuration this is a linelog-disabled-ips falseinside the block <domain>
A history of disablings — or its absence

Enables writing to the node log when and which sending addresses were taken out of service. The default is false, that is, by default no history is kept at all.

How this differs from the list of disabled addresses. The show disabled sources command shows the current state and lives in the engine’s memory: a service restart wipes it clean. The log is a file on disk; it survives a restart and answers a different question: what happened, when and in what order.

When you cannot do without it. Addresses are disabled and come back by themselves — on a timer, on a receiver’s response — and by the time of the investigation the list may be empty. Without the log there will be nothing to link “volume dropped on Tuesday” with “on Tuesday a rule disabled three addresses.”

The main trap. The directive lives in the receiver block, not at the node level: enabled for one recipient, it stays silent about the others. It should be set in the general <domain *> block — otherwise the history will be selective, and there may be no entries precisely about the receiver that caused the problem.
What the Hub does. It does not write it. The Hub keeps its own disablings in its own node management log — which records the operation, who started it and when it expires.

The line is worth enabling if the node has its own mailbox provider rules with disable-source-ip: such disablings do not get into the Hub’s log, and apart from the file on the node there is no trace of them anywhere.

Recommended values

Enable it in the general receiver block — the history should be complete, not about selected domains.

It is cheap. An entry appears only at the moment of an event, and such events are rare: the log does not grow because of it.

Leaving false makes sense only where nobody ever disables addresses — that is, where there are neither rules with disable-source-ip nor people with access to the node console.

From the manual here come the false default and the directive’s purpose. The advice to enable it in the general block and the cost estimate are ours.
Example configuration
# history is needed for all receivers, not for selected ones
<domain *>
    log-disabled-ips true    disabled-source-ip-notify ops@example.net
    reenable-source-ip-after 4h
</domain>
The three lines cover the mechanism completely: find out right away (an email), investigate later (the log), do not forget to bring it back (a timer).
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 one receiver's block

our experience

What it costsThe directive lives in the recipient block. Enabled for gmail.com, it will record nothing about disablings for all the others — and the problem usually comes from where it is not expected.
How to spot itThe log is empty, although there were addresses in the list of disabled ones.
How to do it rightSet it in the general <domain *> block, and in specific ones only if you need the opposite — to turn it off.

Relying on the list of disabled addresses as history

our experience

What it costsThe list lives in the engine’s memory and shows only the current state. An address that was disabled and came back on a timer leaves no trace in it; a service restart wipes even what is there.
How to spot itVolume dropped, the list is empty, and there is nothing to explain it.
How to do it rightEnable the log in advance — history cannot be restored retroactively.
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-disabled-ips <boolean>
Values
true or false (yes/no are accepted too)
Default
false § 3.3.10.6
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 merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload, no restart needed.
How to check on the node
It is checked in the log itself — which is where the node-level log-file directive points:
grep -rn log-disabled-ips /etc/pmta/
grep -i "disabl" /var/log/pmta/log | tail -20
Empty output from the second command with the directive enabled means there simply were no disablings. If the line is not in the configuration, there is no history at all, and past disablings cannot be recovered from anywhere: the list of disabled addresses shows only the current state.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability