Artica Milter is multi-instance by design: a single milter daemon serves every Postfix instance on the gateway, while each instance keeps its own, fully isolated rule set — its own ACLs, DKIM/ARC signing, greylisting and DLP policies. You get per-instance mail policies without running one filter process per instance.
¶ How it works
Every Postfix instance announces its identity to the milter through the standard milter macro v:
# /etc/postfix-instance1/main.cf (managed by Artica)
milter_macro_v = $mail_name instance-1
smtpd_milters = unix:/var/spool/postfix/var/run/artica-milter/milter.sock
At connection time the milter parses instance-N from the macro and selects that instance's rule set. Rules are stored per instance, so rule evaluation, DKIM/ARC options, greylisting and DLP policies are all resolved per instance — a rule created for instance 1 can never fire on instance 0's traffic.
You can verify the wiring from the console:
postconf -c /etc/postfix-instance1 -h milter_macro_v
# -> $mail_name instance-1
¶ Advantages
- One daemon, many policies: a single process (one socket, one cache, one database writer) filters all instances — nothing extra to install, supervise or monitor when you add an instance.
- Strict policy isolation: each instance selects only its own rules. Different domains, different DKIM keys, different DLP severity — no cross-instance leakage.
- Fail-safe identification: if the
vmacro is missing or unreadable, the milter falls back to the configured default instance (instance0by default), increments a dedicated counter and logs a rate-limited warning — mail keeps flowing. - No-rules safety: an instance that has no rules simply accepts its mail (and a
no_rulescounter tracks it), so a freshly created instance is never blocked by the filter. - Per-instance observability: message counters per instance in the statistics, and
mail.logverdict lines carry each instance's own syslog tag so log analysis stays per-instance.
¶ Use cases
- Inbound MX vs outbound relay: instance 0 receives Internet mail with greylisting, SpamAssassin scoring and reject rules; instance 1 relays authenticated submissions with DKIM signing, ARC sealing and an outbound DLP policy.
- Multi-tenant gateway: one instance per customer or brand, each with its own signing domain, allow-lists and data-protection rules.
- Progressive migration: run a relaxed policy on a migration instance while the production instance keeps strict enforcement.
¶ Managing instances
SMTP instances themselves are created and operated in SMTP Router » Parameters » Multiple instances (see the dedicated section Multiple SMTP instances):
¶ Per-instance rules in practice
Open Access Control Lists from the instance's own menu: the rules table only shows — and the editor only creates — rules for that instance.
Instance 0 (inbound MX policy):
Instance 1 (outbound relay policy):
¶ Verifying isolation without sending mail
The DLP simulator evaluates the active policy of the instance you name — a quick way to prove isolation:
SOCK=/usr/share/artica-postfix/bin/run/artica-milter.sock
# instance 0 has no DLP rule -> allow
curl -s --unix-socket $SOCK -X POST http://x/dlp/simulate \
-d '{"instanceid":0,"text_body":"this is confidential"}'
# instance 1 carries the DLP policy -> quarantine
curl -s --unix-socket $SOCK -X POST http://x/dlp/simulate \
-d '{"instanceid":1,"text_body":"this is confidential"}'
¶ Monitoring
GET /stats exposes an instances block: message counts per instance id (by_id), plus three health counters — fallbacks (messages that arrived without a readable v macro), no_rules (messages accepted because their instance has no rules) and overflow. Rising fallbacks means an instance's milter_macro_v is missing; rising no_rules means an instance is filtered by nothing — both worth an alert.
In mail.log, every verdict line is emitted under the instance's own syslog tag (e.g. postfix-instance1/artica-milter), so per-instance log routing and SIEM attribution keep working.
¶ Related pages
- Multiple SMTP instances — create and operate the instances themselves
- The Power of SMTP ACLs · Rule actions
- Monitoring & REST API