Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.56

reenable-source-ip-after

<domain>

The interval after which a disabled outgoing address returns to service
in the configuration this is a linereenable-source-ip-after neverinside the block <domain>
The default return time — and it equals “never”

Sets how long it takes for a sending address that was taken out of service to come back by itself. The value applies only where no deadline is given explicitly.

Priority goes to whoever disabled it. If the address was disabled by a mailbox provider rule with the reenable-after= option, this directive is ignored — the manual says so directly. The same goes for the disable source command: its –reenable-after option takes precedence. The directive works as a fallback value for cases where no deadline was set.

The default is never. This is not “a long time” and not “until a restart” — it is never. The address will be excluded from sending for its queue until someone runs enable source by hand. Not a single configuration line changes in the process: the disabling lives in the engine’s memory.

The main trap. A mailbox provider rule with the disable-source-ip action without reenable-after=, combined with this directive’s default, means “disable forever based on a receiver’s response.” One unlucky response — and the address leaves service indefinitely, quietly, without any trace in the configuration. It can be checked only with the show disabled sources command, and noticed only by a drop in volume.
What the Hub does. It does not write it — and does not rely on it: it always performs its own disablings with an explicit –reenable-after (policies substitute 4h). That way the behavior does not depend on what is written in the node’s configuration, including someone else’s inherited one.

If the node has its own mailbox provider rules with disable-source-ip, the line is worth setting: it covers exactly the case the Hub does not control.

Recommended values

Set it explicitly, even if you only use the command. The line takes a minute, and it protects against an indefinite disabling caused by a mailbox provider rule.

From an hour to a day is a reasonable range for reacting to a block: in less than an hour a receiver usually has not had time to change its attitude, and more than a day is no longer automation but a human decision.

never makes sense only where disabling an address is an event that requires a human to investigate, and you are sure that someone regularly looks at the list of disabled addresses.

The range is our recommendation. From the manual here come the never default, the priority of the reenable-after= option in a rule and the fact that the directive is ignored when that option is present.
Example configuration
# a safety net in case a mailbox provider rule did not name its own deadline
<domain *>
    reenable-source-ip-after 4h    disabled-source-ip-notify ops@example.com
</domain>
Both lines are in the common block — the disabling mechanism is worth configuring for all receivers at once, not for selected ones.
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▶

Leaving the default while mailbox provider rules are in effect

§ 3.3.10.56

What it costsThe default is never. A rule with the disable-source-ip action and no reenable-after= of its own disables the address indefinitely: it drops out of sending on a single unlucky receiver response and will never come back by itself.
How to spot itThe fleet’s volume gradually declines, and addresses of different ages accumulate in the list of disabled ones.
How to do it rightSet the interval in the common receiver block — or specify reenable-after= in every rule that has disable-source-ip.

Expecting the edit to apply to already disabled addresses

§ 3.3.10.56

What it costsThe deadline is fixed at the moment of disabling. A line added later affects only the addresses disabled after it — the ones already hanging have to be brought back by hand.
How to spot itThe line is in the configuration, the deadline has passed, and the address is still disabled.
How to do it rightBring back the accumulated addresses with the enable source command, and from then on rely on the directive.
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
reenable-source-ip-after <time-interval>
Values
a time interval or never — for example 1h, 30m, 2d
Default
never § 3.3.10.56
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 is needed. The new value does not apply to addresses that are already disabled — their deadline was fixed at the moment of disabling.
How to check on the node
The line is checked by reading the configuration, and its effect by the list of disabled addresses: if addresses stay there longer than the set deadline, their deadline was not assigned by this parameter.
grep -rn reenable-source-ip-after /etc/pmta/
pmta show disabled sources
An empty result from the first command means the never default — that is, an address disabled without an explicit deadline will not come back by itself. In the second, look at how long ago: an address that has been hanging for days with an hour set was disabled with its own deadline or before the line was added.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Tune the pace for a provider