Demo
Demo

Knowledge base

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

disabled-source-ip-notify

<domain>

Whom to notify when an outgoing address is disabled or re-enabled for this receiver
in the configuration this is a linedisabled-source-ip-notifyinside the block <domain>
How to find out that an address has gone out of service

A comma-separated list of addresses the engine writes to when a sending address is taken out of service — and when it comes back. Both events, with no “only the bad news” setting.

Why it is needed. Disabling an address is the quietest of the engine’s events: the configuration does not change, there are no errors, messages keep going from other addresses. It is usually discovered by a drop in volume, a day or two later. The notification turns “we will notice someday” into “we will know right away.”

The reason for disabling does not matter. The message will arrive both when a person removed the address with the disable source command and when a mailbox provider rule removed it based on the receiving server’s reply.

An empty string clears the inherited value. “” in a specific block cancels the value set in the general one — this way an addressee can skip notifications for a particular receiver.

The main trap. The notification goes out by the same mail — through the same node that is losing sending addresses at that moment. If all of a queue’s addresses are disabled, the message about it may not go out at all. So the notification recipient should be on a domain the node delivers reliably and, if possible, not through the same sending address.
What the Hub does. It does not write it: it performs its own disabling itself and knows about it without messages — the operation is recorded in the node control log, with its reverse pair and auto-return period.

The line is needed where disabling may be done not by the Hub: the node’s own mailbox provider rules or a person with console access. The Hub will see such disabling only at the next check via show disabled sources, while the message arrives immediately.

Recommended values

Put it in the general receiver block. Disabling an address is an event about the node, not about a specific mailbox provider; there is no reason to set it separately for each receiver.

The addressee should not be on the domain you send from. The notification goes out through the same node; if it goes from the problematic address, it will not arrive. It is sensible to specify a mailbox on a third-party domain.

Several addresses — comma-separated, with no spaces after the commas, as in the manual’s example.

The addressee requirements are our recommendation. From the manual here are the list format, clearing with an empty string and the fact that a message arrives for both events.
Example configuration
# the general block: an event about the node, not about a specific mailbox provider
<domain *>
    disabled-source-ip-notify ops@example.net,dev@example.net    reenable-source-ip-after 4h
</domain>
The notification domain is deliberately a different one: the message goes out through the same node that is losing sending addresses.
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▶

Specifying a mailbox on the same domain you send from

our experience

What it costsThe notification goes out through the same node that is having problems with sending addresses at that moment. In the worst case — when all of a queue’s addresses are disabled — the message will not go out at all, and nobody will learn about the event precisely when it matters most.
How to spot itThere are addresses in the disabled list, but no messages arrived.
How to do it rightSpecify a mailbox on a third-party domain that is not delivered through this node.

Not setting it at all, relying on monitoring

our experience

What it costsDisabling does not change the configuration and writes no errors. Regular node monitoring does not see it: the process is alive, queues are flowing, the volume drops gradually. The mechanism goes unnoticed for weeks.
How to spot itThe calculated volume is not reached, and the cause is found neither in the configuration nor in the log.
How to do it rightSet the notification and enable log-disabled-ips — together they cover both “know right away” and “analyze later.”
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
disabled-source-ip-notify <email-list>
Values
comma-separated addresses; an empty string clears the inherited value
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. An empty string “” clears the inherited value — otherwise there would be no way to cancel a general value in a specific block. It is picked up by pmta reload; no restart is needed.
⇄

Related directives

4 relations

Depends on

smtp-proxy-source-hostGlobalWhen sending through a proxy, the notification concerns the proxy’s client address, not the node’s local interface. § 3.3.1.23

Works together with

Take one address out of service for one queueOne of the two events a message arrives about. § 3.3.10.52Return an address to serviceThe second event: a message also arrives when the address is re-enabled. § 3.3.10.52reenable-source-ip-after<domain>Decides when the address comes back — and a second message arrives about the return. § 3.3.10.56

How to check on the node
The line is checked by reading the configuration. It can be checked for real only with an event — by disabling an address and bringing it back:
grep -rn disabled-source-ip-notify /etc/pmta/
pmta disable source --reenable-after=1m 1.2.3.4 example.com/vmta1
The second line is a deliberately short disabling: two messages will arrive, about disabling and about re-enabling a minute later. It is worth checking this way on a test receiver, not a production one. The Hub does not write this directive and does not read the messages.
◇

What else to read

3 articles

◇The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.◇The sender names the stream for each messageThe message carries the name of the stream it should be sent through — the choice is made by the submitting program, not by the node configuration.◇The node takes the stream whose address matches the connection addressThe source default accepts a reserved value instead of a stream name — then the node chooses the stream whose sending address matches the address the connection arrived at.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Sending address rotation · Sending through proxies
Neighboring settings of the block <domain>:backoff-notifymax-events-recordedtrack-recipient-eventsdisable-acct-recordsdkim-signAll 135 directives of the block →