Knowledge base

queue-filter

<acct-file>

Selecting accounting records by queue name
in the configuration this is a linequeue-filter off — records for all queues are writteninside the block <acct-file>
The most dangerous line in the block

The line selects records by the queue field: a match with a non-negated name — the record is written, a match with a negated one (with ! in front) — it is not. By default there is no selection, all records are written.

🔴 Filtered-out records are lost forever. The manual singles this out in a separate paragraph: a record that does not pass the selection goes nowhere — unless another accounting block writes it. This is not hiding in the output, it is data never coming into existence.

The selection does not apply to all record types. Only d, b, t and tq have the queue field; complaints, bounces by message and receptions (f, rb, rs, r) are written unconditionally, all of them.

Matching goes in the order in which the names are listed — as in an access list: the first match wins.

The queue name must be syntactically valid. The domain must be complete and not reserved (that is, not {feedbackLoop} and not {bounceProcessor}); the sending address, if given, must be a syntactically valid name or {default}. Whether such a sending address actually exists, the engine does not check. A name without a sending address means {default}: foo.com reads as foo.com/{default}.

If all names are negated, no record will pass.

The main trap is forgetting that a name without a sending address means {default}. The line queue-filter foo.com lets through only records of the foo.com/{default} queue — and traffic going through named sending addresses is filtered out and lost. Write foo.com/*.
What the Hub does. It does not write it — and that is the right choice for the fleet. Telemetry must see all queues; selection at the source would mean blind spots the dashboard does not know about.

If such a task ever comes up (for example, giving a client accounting only for their domains), it should be done with a second accounting block, not with selection in the main one: then the full stream is preserved.

Recommended values

Before selecting, create a second block without it:

Entry What it means
foo.com only foo.com/{default} — almost always not what was meant
foo.com/* all sending addresses of this domain
!*/vmta3 everything except this sending address
[*.]b.com/* the domain and its subdomains

🔴 What is filtered out cannot be recovered. Check the line before applying, not after.

The selection rule, the matching order, the irreversibility of what is filtered out, the unconditional writing of the f, rb, rs and r types and the substitution of the default sending address name come from the manual (§ 3.3.11.5). The advice to create a second block instead of selecting in the main one is ours.
Example configuration
# selection in the main stream is dangerous — create a separate block for the client
<acct-file /var/log/pmta/acct.csv>
    records d, b, t
</acct-file>

<acct-file /var/log/pmta/client-a.csv>
    records d, b
    queue-filter [*.]client-a.com/*</acct-file>
The first block writes everything, the second only what the client needs. This way the selection deprives no one of data.
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 domain name without a sending address

§ 3.3.11.5

What it costsA name without a sending address reads as domain/{default}. Records of queues with named sending addresses are filtered out and lost forever.
How to spot itThe file has records for only part of the traffic of this domain.
How to do it rightWrite domain/* if all sending addresses are needed.

Setting a selection in the only accounting block

§ 3.3.11.5

What it costsEverything that did not pass is not written anywhere. There is nothing to recover these events from — for analytics they do not exist.
How to spot itEntire sending directions have disappeared from the statistics.
How to do it rightKeep a full accounting block and do the selection in a second, separate one.

Expecting the selection to narrow complaints and bounces by message too

§ 3.3.11.5

What it costsThe f, rb, rs and r types have no queue field and are written unconditionally. The file will be larger than expected.
How to spot itThe selection is set narrowly, yet the file is full of records of other types.
How to do it rightNarrow them with the set of types in records, not with selection by queue.
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
queue-filter <queue-list>
Values
queue names separated by commas, each can be preceded by an exclamation mark
Default
off — records for all queues are written § 3.3.11.5
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<acct-file>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <acct-file> and narrows only its stream. That is exactly why selection is safe in a second block and dangerous in the only one.
How to check on the node
Check it by what the selection lets through: count the records by queue in the resulting file:
cut -d, -f1,4 /var/log/pmta/client-a.csv | sort | uniq -c | head
The queue column number depends on the set of fields — check it against the file header. An empty result with traffic flowing means the selection is too narrow; recall that a name without a sending address means {default}.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry · Sender isolation