Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.55.2

invalid-virtual-mta-fallback

Global

A fallback stream for messages that named a nonexistent one
in the configuration this is a lineinvalid-virtual-mta-fallbackinside the block Global
Do not reject a message because of a wrong stream name

A node directive, not a source one. It names the stream through which messages that chose a nonexistent stream will leave — instead of rejecting them at submission.

There are two conditions, and both are required. Here — the name of the fallback stream; in the source — reject-invalid-virtual-mta set to false. The latter defaults to true, so this line alone changes nothing.

It works only at submission. The manual stipulates this separately: the mechanism does not extend to queue rerouting — neither to reroute-to-virtual-mta nor to backoff-reroute-to-virtual-mta. Rerouting to a nonexistent stream is not saved by the fallback.

The main trap. Writing this line and considering the matter closed. Until the refusal is turned off in the source, it does nothing — and there will be no warning on apply. Always check both lines at once.
What the Hub does. It does not write it. The Hub itself puts stream names on messages, and a message with an unknown name is a mismatch between the plan and the node: it is better to learn about it from a refusal than to silently send from the wrong address. The pair will come in handy when headers are set by someone else’s platform whose updates we do not control.
Recommended values

What to set. The value is the name of an existing stream; it makes sense only together with the refusal turned off. The fallback stream is worth choosing by one rule: it must not be one under warm-up. Messages that land here are messages with an unknown intended destination, and putting them on an address building reputation means risking someone else’s history.

A sensible choice is the common submission pool or a separate stream on a warmed-up address, by which all such messages are easy to find in accounting later.

The pair requirement and the non-applicability to rerouting come from the manual. The advice not to use an address under warm-up as the fallback is ours.
Example configuration
# both lines are needed together: the fallback stream name and the refusal turned off
invalid-virtual-mta-fallback mta-hub-pool
<source 10.0.0.0/24>
    process-x-virtual-mta yes
    reject-invalid-virtual-mta false
</source>
The fallback stream line is written at the root of the file, without an enclosing block. A message from the specified subnet that names a stream that does not exist will leave through the pool. This does not extend to queue rerouting.
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▶

Writing a fallback stream without the paired line

§ 3.3.1.55.2

What it costsThe refusal in the source is on by default and fires earlier. The directive sits in the configuration and affects nothing.
How to spot itSubmission refusals continue, while in the configuration “everything is set up.”
How to do it rightAdd reject-invalid-virtual-mta false to the submission source. It is worth keeping a check for this pair in the configuration generator.

Counting on the fallback stream when rerouting a queue

§ 3.3.1.55.2

What it costsThe mechanism works only at submission. Rerouting to a nonexistent stream — reroute-to-virtual-mta or its backoff form — is not saved by the fallback.
How to spot itA queue that was supposed to be moved by rerouting behaves unexpectedly, and the fallback stream plays no part in it.
How to do it rightCheck reroute stream names when assembling the configuration: there is no fallback here, only the correct name.

Using a stream under warm-up as the fallback

our experience

What it costsMessages with an unknown destination land here — often erroneous or outdated ones. Sending them from an address under warm-up means mixing random traffic into a careful plan.
How to spot itThe daily volumes of an address under warm-up are above plan, and the excess is not explained by the schedule.
How to do it rightUse a warmed-up address or the common submission pool as the fallback — and keep it separate, so that such messages are visible in accounting by the vmta field.
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
invalid-virtual-mta-fallback VMTA-NAME
Values
the name of a stream declared in the configuration
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A node-level directive with no inheritance: there is one for the whole installation. Its pair, reject-invalid-virtual-mta, is inherited — it is written in <source> and merges by the source rule, where a narrower block overrides a wider one. So the fallback stream can be enabled pointwise, for one submission subnet.
How to check on the node
Both lines are checked at once; they are in the same file:
grep -n "invalid-virtual-mta" /etc/pmta/config
Two lines are expected in the output. Next, make sure the named stream is actually declared: pmta show vmtas will show the list, and the name must match literally.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Connect a sending platform