Demo
Demo

Knowledge base

PMTA knowledge base›Block <signals-filter>›Directive§ 11.1.6.3.1

sender-or-from

<signals-filter>

A selection rule by sender domain
in the configuration this is a linesender-or-frominside the block <signals-filter>
Selection by message, not by stream

The usual export scope is set by streams — node, pool, sending address. This line offers a second way: selection by the sender’s domain from the message itself, regardless of which stream it went out through.

The rule consists of two parts: a domain pattern and a decision — enable-signals or disable-signals. When enabling, a subaccount and a tracking scope can be added to the decision.

Patterns are matched in order, and wildcards work: *.customer1.com covers subdomains, * everything else. The usual technique is to list the specific cases and put the general rule last.

The list is named, and it is attached to the scope by name: instead of enable-signals true you write enable-signals ListName.

🔴 Whatever matches no rule counts as disabled. The manual says so directly: when a list is attached, the scope defaults to false for everything that did not match.

🔎 Seeding has no such selection at all. The vendor notes that this may make the subaccounts of the two mechanisms diverge — and advises keeping them consistent.

The main trap is forgetting the final general rule. Without a line with the * pattern, everything that did not match explicitly drops out of the export silently. The list looks configured, while half the traffic never reaches analytics.
What the Hub does. It does not write it: we do not use export to external analytics.

🔎 The technique itself is useful and familiar: selection by the sender’s domain rather than by stream — the same thing our sending address selection list does. The difference is that there the rule chooses a stream, while here it decides the fate of the data about the message.

Recommended values

The order of rules matters, the general one goes last:

Pattern Decision What it covers
marketing.customer1.com enable-signals,subaccount=555 the exact name
transact.customer1.com disable-signals an exception
*.customer1.com enable-signals,subaccount=333 the other subdomains
* enable-signals,subaccount=222 everything else

The subaccount and tracking scope are set only when enabling.

The structure of the rule, the significance of order, the ban on subaccount and tracking-domain when disabling and the “unmatched is disabled” rule come from the manual (§ 11.1.6.3.1, § 11.1.6.1.1). The remark about seeding having no such selection is from § 11.2.1.
Example configuration
# the last rule is mandatory, otherwise whatever does not match drops out silently
<signals-filter ListOne>
    sender-or-from  marketing.customer1.com  enable-signals,subaccount=555    sender-or-from  transact.customer1.com   disable-signals
    sender-or-from  *.customer1.com          enable-signals,subaccount=333
    sender-or-from  *                        enable-signals,subaccount=222
</signals-filter>

enable-signals ListOne
The last line attaches the list to the scope. Without it the list itself does nothing.
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▶

Not adding the final general rule

§ 11.1.6.1.1

What it costsEverything that matched no pattern counts as disabled. Part of the traffic drops out of analytics silently.
How to spot itThe service’s reports show noticeably fewer messages than were sent.
How to do it rightAdd a final line with the * pattern and the needed decision.

Setting subaccounts through selection while also using seeding

§ 11.2.1

What it costsSeeding has no such selection. The subaccounts of the two mechanisms will diverge, and the data in reports will fall under different accounts.
How to spot itThe seeding and export reports show different subaccounts for the same traffic.
How to do it rightKeep subaccounts consistent; use selection with care.
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
sender-or-from <domain> [subaccount N]
Values
a domain pattern, then enable-signals with optional subaccount and tracking-domain, or disable-signals
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<signals-filter>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The line has no inheritance: it lives inside its named list. What is inherited is the attachment of the list — by the enable-signals scope line, which has three levels: node, pool, sending address.
⇄

Related directives

2 relations

Works together with

enable-signalsGlobalThe rule list is attached to the scope by name: the scope line names this list instead of a value. § 11.1.6.1.1

Affects

The vendor's analytics — and what leaves the node for itThe mechanism whose scope these rules narrow. § 11.1.6.3.1

How to check on the node
Check it by what reached the service — the selection is not visible from the node’s side:
grep -i "signals" /var/log/pmta/log | tail -20
A gap between the volume sent and the volume in the service’s reports is a sign that some messages were filtered out by the selection.
◇

What else to read

3 articles

◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.◇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.◇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
Sender isolation