Matrix: M14M15M25
Open in panel — /app/appliance
Matrix refs: {r}{r}{r}
Operators

Production Hardening Flags

Production hardening flags control the runtime behaviour of the PostMTA Hybrid appliance. Each flag has a defined risk level, a default value set at install time, and a documented rollback procedure. All flags live under thepmh.runtime Helm values namespace. Changing a flag in production requires a helm upgrade and a subsequent smoke-gate verification pass.

Reference Identifier

The authoritative reference for this page isPMH-SEC-025 — Production Hardening Flags. When opening a related security ticket, always quote PMH-SEC-025 in the subject line.

Flag Overview

Nine runtime flags govern critical subsystems: MIB/SNMP inspection, development seed injection, lab-metrics bypassing, TLS minimum version enforcement, queue drain pacing, bounce classification strictness, credit enforcement, spam-score gating, and WAL archiving. The table below enumerates each flag, its default, its risk classification, and the one-step rollback command.

Flag Reference Table

Flag NameDefaultRisk LevelDescriptionRollback Command
MIB_CHECK_ONLYfalseMEDIUMWhen true, the Kumo MTA runs in MIB-check-only mode: no mail is transmitted, SNMP traps are still evaluated. Used during provisioning to validate the SNMP endpoint before enabling delivery.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.MIB_CHECK_ONLY=false \
  --namespace pmh-system
ALLOW_DEV_SEEDfalseHIGHPermits injection of seed addresses from the pmh.seeds.*values block into the suppression engine. Should never betrue in a production tenant namespace.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.ALLOW_DEV_SEED=false \
  --namespace pmh-system
KUMO_METRICS_LAB_BYPASSfalseMEDIUMBypasses the Prometheus metrics scrape path for lab environments where the scrape endpoint is unreachable. Must never be truein production — metrics will silently drop.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.KUMO_METRICS_LAB_BYPASS=false \
  --namespace pmh-system
ENFORCE_TLS12_MINtrueLOWRequires TLS 1.2 or higher for all inbound and outbound SMTP connections. Disable only for legacy MTAs that do not support TLS 1.2; doing so voids compliance with PMH-SEC-012.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.ENFORCE_TLS12_MIN=true \
  --namespace pmh-system
QUEUE_FLUSH_INTERVAL30 secondsMEDIUMMinimum elapsed time between queue drain batches. Lower values drain faster but increase API pressure on the PostgreSQL credit ledger. Values below 10 are not supported.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.QUEUE_FLUSH_INTERVAL=30 \
  --namespace pmh-system
BOUNCE_CLASSIFICATION_STRICTtrueMEDIUMWhen true, every non-2xx SMTP response is classified as a hard bounce and immediately suppresses the recipient. Whenfalse, transient 4xx codes are retried for up to 72 hours before suppression.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.BOUNCE_CLASSIFICATION_STRICT=true \
  --namespace pmh-system
CREDIT_ENFORCEMENTtrueHIGHWhen true, messages are rejected at the shaping layer if the credit balance is zero or negative. When false, the credit check is bypassed and messages are sent on credit float — billing reconciliation will be incorrect.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.CREDIT_ENFORCEMENT=true \
  --namespace pmh-system
SPAM_SCORE_THRESHOLD5.0LOWSA Score above which a message is quarantined rather than delivered. Range is 0.110.0. Raising above7.0 effectively disables spam filtering.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.SPAM_SCORE_THRESHOLD=5.0 \
  --namespace pmh-system
WAL_ARCHIVE_MODEarchiveHIGHControls PostgreSQL WAL destination. Legal values: archive(write to S3-compatible path), local (write to/var/lib/postgresql/wal), disabled(no WAL captured). Switching to disabled breaks point-in-time recovery and is not permitted on production tiers.
helm upgrade pmh oci://registry.internal/pmh/helm/pmh \
  --set pmh.runtime.WAL_ARCHIVE_MODE=archive \
  --namespace pmh-system

Smoke Gate Procedure

After every flag change you must run the smoke gate. The smoke gate is a four-step manual verification sequence. Do not skip any step. If any step fails, roll back immediately before continuing.

Step 1 — Pod Restart Verification

Confirm the pmh-core Deployment has restarted after the helm upgrade and that all desired replicas are in the Running state.

kubectl rollout status deployment/pmh-core \
  --namespace pmh-system --timeout=120s

Step 2 — Shaping Endpoint Check

Call the internal shaping health endpoint and confirm it returns200 OK with a JSON body that includes"status": "ok".

kubectl exec -n pmh-system \
  $(kubectl get pod -n pmh-system -l app=pmh-core \
    -o jsonpath='{.items[0].metadata.name}') \
  -- curl -sf http://localhost:8081/health/shaping

Step 3 — Queue Depth Sanity

Query the Kumo MTA queue depth via the admin RPC port. The value must be non-negative and less than the configured overflow threshold (pmh.runtime.MAX_QUEUE_DEPTH, default 50 000).

kubectl exec -n pmh-system \
  $(kubectl get pod -n pmh-system -l app=pmh-core \
    -o jsonpath='{.items[0].metadata.name}') \
  -- kumoctl -c /etc/pmh/kumoctl.toml \
     queue depth 2>&1 | grep -E '^total'

Step 4 — Credit Ledger Sync

Verify the credit ledger is advancing by reading the last_sync_attimestamp from the Caddy-side API and confirming it is within the last two minutes.

curl -sf http://localhost:9080/internal/credits/last_sync \
  | python3 -c "import sys,json; t=json.load(sys.stdin)['last_sync_at']; \
    import datetime,time; \
    age=int(time.time())-int(t); \
    assert age<120, f'Credit sync stale: {age}s old'); \
    print(f'Credit sync OK: {age}s ago')"
Rollback required if any smoke gate step fails.Run the Rollback Command from the flag table immediately. Do not wait for the next maintenance window. A stale credit sync older than five minutes will cause double-sends on the next queue drain cycle.

Risk Level Definitions

LevelColourDefinitionChange Requires
LOWGreenNo impact on deliverability, billing, or compliance. Safe to change during business hours with a single engineer.One engineer approval
MEDIUMAmberMay affect deliverability rates or cause brief increased API load. Requires two-engineer approval and a 15-minute monitoring window post-change.Two engineer approvals
HIGHRedDirectly affects billing accuracy, data integrity, or compliance. Requires a change freeze exception approved by the on-call SRE before the maintenance window begins.SRE on-call approval + change freeze exception

Related Documentation