Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 1.3

How a message leaves the node

delivery interfaces
The introduction names two, the configuration adds three

The introduction lists two delivery methods: ordinary extended SMTP to the recipient’s server and handing the message to a local program.

The list is incomplete — and this is visible from the manual itself. The type line in the receiver block adds delivery to a file, delivery over HTTP and discarding; the “local program” from the introduction is pipe delivery, pipe. So the introduction gives an outline that the configuration chapter extends rather than replaces.

The practical point of the list is that SMTP is not the only one. A receiver configured for delivery to a file or for discarding behaves completely differently: no messages go to it at all, and in accounting they look different.

Discarding is worth knowing separately. It is a way to configure a receiver so that mail to it disappears silently — useful for tests and dangerous in production.

The main trap is a forgotten non-standard delivery. A receiver once configured for discarding or delivery to a file for a test keeps behaving the same way. Messages to it go nowhere, while the report shows successful delivery — because from the node’s point of view it was successful. This can be found only by reading the configuration, not by sending behavior.
What the Hub does. It does not set the delivery method at all — the default applies, ordinary SMTP.

Other methods are not used here. The closest mechanism in meaning is discarding messages to role addresses (postmaster@, abuse@, dmarc@), but it is done by acceptance and an address list, not by changing the delivery method.

Discarding would come in handy on a test bench: a receiver to which messages go nowhere lets you test sending without sending anything. But on a production node such a line is a source of silent mail loss.

Recommended values

Five methods, of which the introduction names two:

Method Where described When it occurs
SMTP to the receiver introduction default, ordinary delivery
to a local program, via pipe introduction processing with your own code
to a file receiver block archive, testing
over HTTP receiver block delivery to another service
discarding receiver block testing; dangerous in production

The method is set per receiver, not globally. So a non-standard one can sit on a single domain and go unnoticed.

Mark discarding with a comment. A line that makes mail disappear must explain itself to whoever reads the configuration.

The table of five methods was compiled by us from two places in the manual: the first two are from the introduction (§ 1.3), the rest from the type line of the receiver block (§ 3.3.10.60).
Example configuration
# a test receiver to which no mail goes at all
<domain test.example.com>
    type discard        # messages disappear silently — for the test bench only</domain>
The highlighted line is the one that makes mail loss invisible: the node considers such delivery successful, and in accounting it looks successful too.
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 ends3 mistakes▶

Leaving a test discard in the configuration

§ 3.3.10

What it costsMessages to the receiver disappear silently, while accounting shows successful delivery: from the node’s point of view it was successful. The mail loss is not visible in any report.
How to spot itThe domain’s recipients complain about messages not received, reports show one hundred percent delivery.
How to do it rightCheck the delivery method with the queue settings command. Remove test lines right away and mark them with a comment while they stand.

Writing a non-standard method into the general receiver block

§ 3.3.10

What it costsMerging goes from general to specific: a method written in the asterisk block will go to all receivers at once.
How to spot itSending stopped to all domains at once, with no errors.
How to do it rightSet a non-standard method only in a specific block and check the effective value for neighboring receivers.

Believing the introduction's list is complete

§ 1.3

What it costsThe introduction names two methods, the configuration adds three. Analyzing someone else’s config by the introduction’s list will leave three values out of five unrecognized.
How to spot itA receiver block contains a delivery method value that “does not exist”.
How to do it rightKeep the full list of five in mind. The introduction gives an outline, not an inventory.
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.
Inheritance
The delivery method is set in the receiver block and merged by the usual rule — from the general pattern to the specific one and by the node, pool and sending address levels. So a non-standard method written in a general block will go to all receivers at once.
⇄

Related entries

1 relation

Applies to

Accept, route, deliverA message’s path inside the node ends with one of these methods. § 1.3

Referenced from

Queue depthThe depth breakdown follows the delivery methods: when messages are discarded, the queue does not grow at all. § 5.3Hand a message to a webhook instead of a receiverOne of the ways a queue hands over a message, along with regular sending, a file and a program. § 8.5Handing a message to a program on the same nodeOne of the ways a queue hands over a message, alongside ordinary sending, a file and a webhook. § 11.21What to do with an accepted messageA related mechanism: they work together. § 13.1

How to check on the node
Check the configuration: a non-standard method is not visible from sending behavior:
grep -n -B2 'type ' /etc/pmta/config | grep -A2 '<domain'
pmta show settings test.example.com/mta-news-1 | grep '^type'
The second command prints the effective delivery method for a specific queue — that is the reliable answer. A value other than the ordinary one should be explained with a comment right in the configuration.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing