The block contains sender-or-from rules — one per line. Each names a sender domain pattern and a decision: enable the export or disable it, with an optional subaccount and tracking domain.
The list is named and does nothing by itself. It is attached with the scope line: enable-signals ListName.
🔴 Anything that matches no rule is considered disabled. That is why the last line is almost always the * pattern.
The rules are evaluated in order, and wildcards work — specific cases are written above general ones.
🔎 Seeding has no such selection. Using both mechanisms, you will have to keep subaccounts consistent by hand.
# specific cases above, the general rule last <signals-filter ListOne> sender-or-from marketing.customer1.com enable-signals,subaccount=555 sender-or-from transact.customer1.com disable-signals sender-or-from * enable-signals,subaccount=222 </signals-filter> enable-signals ListOne
3 articles
◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇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.