2.1 KiB
mailman
The site-wide antispam defaults are deliberately empty:
mailman_antispam_header_checks: []
mailman_antispam_chain_behaviour: discardMailing-list owners can manage list-specific header matches and
select their action (accept, discard,
hold, or reject) from Postorius. The global
chain is used only when a matching rule has no explicit action.
Existing lists without any header matches can be initialized through the Mailman database model by enabling the optional seed operation:
mailman_seed_empty_list_header_matches: true
mailman_empty_list_header_matches:
- header: 'X-Spam-Flag'
pattern: '^YES$'
action: 'discard'The operation is idempotent. A list is modified only when its header-match collection is empty; lists with one or more existing rules are left untouched.
Verified weekly restart
The optional weekly restart performs separate stop and start
operations. It waits for systemd, mailman status, and the
configured LMTP listener to confirm that Mailman has stopped before
starting it. It then requires the master and the LMTP port to become
available before considering startup successful:
mailman_enable_weekly_verified_restart: true
mailman_weekly_verified_restart_on_calendar: 'Sun *-*-* 04:00:00'
mailman_service_stop_timeout: 30
mailman_weekly_verified_restart_stop_timeout: 120
mailman_weekly_verified_restart_start_timeout: 120The timer is deliberately not persistent, so a missed run is not
executed immediately after a server boot. Failures are recorded by
systemd in the mailman-verified-restart.service
journal.
The managed mailman.service uses
KillMode=control-group and an explicit
TimeoutStopSec. If Mailman’s own stop command hangs,
systemd terminates the whole service cgroup and removes a stale master
PID file. The weekly job still verifies the real stopped state and does
not start a second instance until the master and LMTP listener are gone.
The normal role execution also waits for the configured LMTP port and
fails if the listener does not become available after starting or
restarting Mailman.