PowerMTA Listener Hardening

Purpose and scope

Separate submission and internal listeners, restrict source networks and reduce unauthenticated exposure. The objective is a controlled, observable design that preserves sender attribution and supports rollback.

• Document the traffic owner and sending purpose.
• Define boundaries before tuning throughput.
• Prefer explicit policy over broad implicit permissions.

Architecture and dependencies

Map submission applications, credentials, sender domains, Return-Path domains, DKIM selectors, VMTAs, source IPs, DNS, provider policies, logs and suppression systems.

Application -> authenticated submission -> sender authorization -> VMTA/pool -> provider policy -> recipient
                                         |-> accounting/bounce/complaint pipeline

Implementation approach

1. Inventory the current state and capture configuration checksums.
2. Build the policy in staging with representative messages.
3. Verify envelope sender, visible From, DKIM, HELO, PTR and source IP.
4. Introduce the change to a limited stream.
5. Watch queue age, SMTP responses, bounces, complaints and authentication results.

Configuration pattern

# Illustrative pattern for PowerMTA Listener Hardening
# Replace example values and verify directive support.
<domain example.net>
  max-smtp-out 2
  max-msg-rate 60/h
  retry-after 30m
  bounce-after 4d
</domain>

Validation checklist

• Syntax and service startup verified.
• Test message routed through the expected VMTA and source IP.
• HELO and PTR match the intended identity.
• SPF, DKIM and DMARC results reviewed.
• Temporary and permanent failure handling confirmed.
• Rollback procedure exercised.

Common failure modes

• Applying one provider policy globally.
• Allowing authenticated users to select unauthorized sender domains.
• Increasing rates while queue age and temporary failures are rising.
• Changing DNS and MTA policy simultaneously without evidence.
• Deleting queues before preserving incident data.

Operational ownership

Assign an owner, review date, monitoring threshold and rollback trigger. Keep changes small enough that their effect can be distinguished from provider or list-quality changes.