Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 1.1

Accept, route, deliver

PowerMTA basic functionality
Three steps between which all the settings live

The node takes a message over SMTP or through a submission API, decides by name records or by the configuration where to take it, and delivers.

Three steps — three places where something can go wrong. Acceptance is decided by the submission block, routing by the merging of receiver blocks, delivery by limits and the delivery method. Investigating any fault starts with the question of which of the three steps it happened at.

The main trap is looking for the fault at the wrong step. A message not accepted by the node will not appear in the queue, and one that was accepted and got stuck will not produce a rejection at submission: first find out whether the message reached the queue, and only then investigate delivery.
What the Hub does. The whole path of a message runs inside the node. The Hub sees it from three sides: its own submission — warm-up messages; the middle — through monitor requests and control commands: queues, connections, pauses, backoff mode; the outcome — through accounting.
Recommended values

Where to look for what:

Step What decides it Where it is visible
receiving the <source> block and the listener the reply at submission, the submission log
routing DNS records and <domain> blocks show settings, resolve
delivery limits, queue mode, delivery method show queues, accounting
The three steps and the ways of receiving, routing and delivery come from the manual (§ 1.1). The breakdown by where to investigate is ours.
Example configuration
# three steps of one message: is it in the queue, which rules apply, what about delivery
pmta list --rcpt=user@example.com
pmta show settings example.com/vmta1pmta show queues --errors example.com/vmta1
The first line answers whether the message is in the queue; the second, which rules will apply to it; the third, what is happening with delivery.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
⇄

Related entries

2 relations

Applies to

How a message gets into the engineA related mechanism: they work together. § 1.1How a message leaves the nodeA related mechanism: they work together. § 1.1

Referenced from

What the node tells about itself and through which channelsWhat is being observed: a message’s path through the node from receipt to delivery. § 1.4Node backup and restoreThe spool is where a message lives between receipt and sending; that is why copying it means preserving the messages. § 1.8

How to check on the node
Check all three steps on the node:
pmta show status
pmta show queues --no-rcpt-events --maxitems=50
The number of accepted but undelivered messages is growing — it is a delivery question; the number of accepted messages is not growing — a receiving question.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Configuration lifecycle