Inbound Mail-Server Protocol Hardening

Threat Context (mid-2026)

A mail server that terminates inbound SMTP, IMAP, POP3, JMAP, or ManageSieve exposes a protocol surface that sender-authentication (SPF/DKIM/DMARC) and transport TLS do not protect. SMTP smuggling (CVE-2023-51764/51765/51766) exploits a server that accepts a non-standard end-of-data sequence to deliver a second message that inherits the outer connection's authentication pass — spoofed mail past DMARC. STARTTLS command/response injection (CVE-2021-38371, CVE-2021-33515) executes attacker plaintext buffered before the handshake. An open relay lends the operator's reputation to spammers. Uncapped Sieve redirect is a silent mail-exfiltration primitive. Mailbox-DAV (CalDAV/CardDAV) endpoints add path-traversal and XXE. Each is a configuration or parser-hardening gap, not a CVE to patch.

Framework Lag Declaration

Organizational mail controls center on sender authentication and transport encryption: SPF, DKIM, DMARC, and a TLS certificate. None prescribe the server-side protocol hardening this skill audits. NIST 800-53 SI-2 expects flaw remediation via a patch cadence, but the smuggling and STARTTLS-injection fixes are configuration (strict end-of-data handling, receive-buffer drain) the patch process never surfaces. NIS2 Art.21 names network security of essential services but assumes SPF/DKIM/DMARC and TLS suffice — they are bypassed at the protocol layer. A clean DMARC + TLS audit is therefore NON-EVIDENCE for inbound protocol hardening; the two address different boundaries.

TTP Mapping

The inbound mail-protocol failures map to MITRE ATT&CK: T1190 (Exploit Public-Facing Application) for command-literal injection in the IMAP/POP3/ManageSieve parsers and mailbox-DAV traversal/XXE; T1071.003 (Application Layer Protocol: Mail Protocols) for SMTP smuggling delivering spoofed mail and open-relay abuse; and T1557 (Adversary-in-the-Middle) for STARTTLS receive-buffer injection that crosses the TLS boundary. Cleartext AUTH before STARTTLS enables T1040 (Network Sniffing); absent auth rate limiting enables T1110 (Brute Force); uncapped Sieve redirect enables T1114 (Email Collection). The weakness classes are CWE-93 (CRLF/smuggling), CWE-77 (command injection), CWE-22 (path traversal), CWE-611 (XXE), CWE-863 (open-relay authorization), and CWE-400 (uncapped Sieve/PUTSCRIPT resource use).

Exploit Availability Matrix

These are protocol-posture gaps, so weaponization is low-cost and reusable. SMTP smuggling has public tooling (SEC Consult, December 2023) and the CVE-2023-51764/51765/51766 entries are cataloged. STARTTLS injection has public test tooling from the 2021 "NO STARTTLS" research (CVE-2021-38371, CVE-2021-33515). Open-relay testing requires only an unauthenticated MAIL FROM + RCPT TO probe. Command-literal injection and mailbox-DAV traversal require only a crafted protocol line. None need a novel exploit; the exploit is the absence of the check. Real-world priority is driven by internet-reachability of the listener and whether the gap yields spoofing/relay (reputation + phishing delivery) or mailbox-data exposure.

Analysis Procedure

1. Inventory every inbound mail listener and its port (implicit-TLS 465/993/995 vs opportunistic-STARTTLS 25/587/143/110/4190). 2. Probe SMTP for non-standard end-of-data acceptance (smuggling) and unauthenticated relay. 3. Probe each opportunistic-STARTTLS listener for an undrained pre-handshake buffer and for AUTH offered before TLS. 4. Inspect the IMAP/POP3 parsers for bare-CR/LF acceptance and the ManageSieve listener for unbounded PUTSCRIPT and cleartext AUTH. 5. Inspect the Sieve engine for an uncapped redirect and the mailbox-DAV endpoint for traversal + XXE. 6. Confirm auth rate limiting / greylisting is active. Run the mail-server-hardening playbook to execute these as detect indicators with false-positive checks, then score by reachability and impact class.

Output Format

Report per listener and protocol, marking each hardening check enforced / missing / inconclusive (visibility gap). For every missing check, state the port, whether it is internet-facing, and whether the gap yields spoofing/relay or mailbox-data exposure. Distinguish a live-listener finding from a documented test fixture or an upstream-proxy-enforced control. Provide the prioritized remediation (enforce standard end-of-data, drain the STARTTLS buffer and gate AUTH on TLS, harden the command parsers, restrict relay and cap Sieve redirect, harden mailbox-DAV and add rate limits) and the negative validation tests that prove each fix (smuggling rejected, relay rejected, STARTTLS injection rejected) plus the functional test that legitimate mail still flows.

Compliance Theater Check

The recurring theater is "we have SPF/DKIM/DMARC and TLS, so our mail server is secure" and "relay is restricted in our config." Sender authentication and transport TLS protect different boundaries than the inbound protocol parser; a config flag is not evidence the listener enforces it. The distinguishing test: probe the live inbound listener for non-standard end-of-data acceptance, an undrained STARTTLS buffer, unauthenticated relay, and cleartext AUTH. If any probe succeeds, the DMARC record and TLS certificate did not protect the protocol layer, and the assurance is paper. "Relay is restricted" is theater until an unauthenticated RCPT-to-external probe is actually refused.

Defensive Countermeasure Mapping

Map findings to MITRE D3FEND: strict end-of-data enforcement and command-parser hardening realize Message Authentication and Inbound Traffic Filtering (countering T1071.003/T1190); STARTTLS receive-buffer draining and AUTH-after-TLS gating realize Transport Session Integrity (countering T1557/T1040); relay authorization realizes Outbound Traffic Filtering (countering open-relay reputation abuse); Sieve redirect caps realize Email Filtering (countering T1114 exfiltration). Pair the protocol hardening with auth rate limiting and greylisting (countering T1110). The residual risk after hardening is a compromised authenticated account acting within its own authorization, which protocol hardening does not address — accept it at the CISO level with identity-control compensation.