Demo
Demo

Knowledge base

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

notify-of-delay-every

<domain>

How often the node checks whether it is time to report a delay
in the configuration this is a linenotify-of-delay-every 4hinside the block <domain>
The frequency is decided by the node, not by whoever requested it

The default is 4h. The line sets how often the node checks whether it is time to send a delay notification — the one the submitting side requested with the NOTIFY=DELAY parameter of the RCPT command.

The distinction matters: the submitting side requests, but you decide the frequency. The sender cannot ask to “report once”; it asks to be notified, and how many times is a consequence of the interval and of how long the message hangs in the queue.

The value never turns off such notifications for this receiver entirely.

How many notifications will arrive per message in total is simple to calculate: the message lifetime (bounce-after) divided by this interval.

The main trap is that the notification does not arrive just once. A message to a problematic receiver lives until bounce-after, and with a four-hour interval over three days eighteen notifications pile up per message. On a mailing stuck as a whole, that is an avalanche of messages to your own sender.

Hence a practical rule: the interval should be matched to the message lifetime, not chosen “by feel”.

What the Hub does. It does not write it — the vendor 4h stays, and it cannot show up: suppress-local-dsn true, in effect in all submission sources, turns off report generation entirely.

The Hub sees delays through transient failure records in telemetry, and it does not need notifications by message.

Recommended values

What to set. The interval is calculated from the message lifetime:

Value When
4h (default) lifetime of one to two days: around a dozen notifications
a day or more lifetime of three days or more, and notifications are needed as a signal, not as a chronicle
never outcomes are analyzed from accounting, notifications by message are not needed

The third is the usual choice for a sending platform. The first two make sense where a person reads the reports.

The 4h default, the never value and the tie to the NOTIFY=DELAY parameter of the RCPT command come from the manual, § 3.3.10.17. The calculation of the number of notifications and the breakdown of cases are ours.
Example configuration
# message lifetime is three days — a four-hour interval would give eighteen messages
<domain *>
    notify-of-delay-every 12h    bounce-after 3d
</domain>
The two lines are read together: the number of notifications per message is the lifetime divided by the interval. Here there will be six instead of eighteen.
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▶

Keeping the default with a long message lifetime

our experience

What it costsFor a single stuck message a notification arrives every four hours until the final bounce. On a stuck mailing that is an avalanche of messages to your own sender.
How to spot itThe sender’s mailbox is flooded with identical delay notifications.
How to do it rightMatch the interval to the message lifetime or turn notifications off with the value never.

Expecting the submitting side to set the frequency

§ 3.3.10.17

What it costsIt requests a notification, but not its schedule. The expectation “they will report once” does not come true, and the submitting platform looks to blame.
How to spot itMore notifications arrive than expected from the request.
How to do it rightConfigure the interval on the node — that is where it is decided.
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
notify-of-delay-every <time-interval>
Values
a time interval or never
Default
4h § 3.3.10.17
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 directive lives in <domain> and obeys the merging of receiver blocks: a message falls under all matching blocks, and a narrower one overrides a wider one. A value from the * block goes to all receivers that did not name their own.
⇄

Related directives

1 relation

Works together with

bounce-after<domain>The message lifetime and this interval together set the number of notifications per message. § 3.3.10.17

How to check on the node
The line is read together with the message lifetime and with report suppression:
grep -n 'notify-of-delay-every\|bounce-after\|suppress-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
If report suppression is on, the line will not show up at all. If not, divide the lifetime by the interval: that is how many notifications will arrive per stuck message.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Receiving inbound mail
Neighboring settings of the block <domain>:smtp-553-means-invalid-mailboxsmtp-pattern-listbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingAll 135 directives of the block →