MailScanner vs Amavisd-new: 2027 Queue Spool Directory Inspection vs In-Band SMTP/LMTP Filtering
Published by Fred Dawson • Senior Deliverability Systems Architect • 17 min read
When integrating virus and spam scanning into Unix MTAs like Postfix or Sendmail, system architects must choose between two distinct execution topologies: MailScanner (an out-of-band queue spooler that splits mail delivery into incoming and outgoing directories) and Amavisd-new (an in-band content filtering daemon communicating over local TCP/LMTP sockets). This technical guide benchmarks both approaches across RFC 5321 transaction handshakes, timeout vulnerability, backscatter risk, and NVMe disk spool I/O loads.
- 1. Architectural Topologies: Spool Split vs Socket Stream
- 2. SMTP Connection Timeouts & Denial of Service Defense
- 3. In-Band 550 Rejection vs Asynchronous Backscatter Risk
- 4. Disk I/O Queue Thrashing vs Resident Memory
- 5. MailScanner vs Amavisd Technical Matrix
- 6. The AutoSMTP Deliverability Defense Advantage
1. Architectural Topologies: Spool Split vs Socket Stream
How an email moves through the MTA during virus and spam inspection fundamentally impacts server stability:
MailScanner (Queue Split Architecture): MailScanner decouples Postfix into two distinct instances. The first Postfix instance receives the email from the network, writes it to an incoming spool directory (/var/spool/postfix/hold), and immediately returns an SMTP 250 OK acknowledgment to the sending client. MailScanner runs as an independent daemon that periodically reads raw files from the hold directory, unpacks MIME parts, runs ClamAV/SpamAssassin, sanitizes HTML, and moves clean messages to the second Postfix outgoing queue (/var/spool/postfix/incoming) for delivery.
Amavisd-new (In-Band Loopback Stream): Amavisd-new acts as an in-line SMTP/LMTP content filter proxy. When Postfix receives a message, it holds the external client’s TCP connection open while piping the message over a local TCP loopback port (default 127.0.0.1:10024) to an Amavisd worker process. Amavisd scans the message in RAM and passes it back to Postfix via port 10025 before Postfix issues the final 250 OK acknowledgment to the remote sender.
# Amavisd-new in-band filtering loop in master.cf:
smtp inet n - y - - smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10024
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
# MailScanner out-of-band hold configuration in main.cf:
header_checks = regexp:/etc/postfix/header_checks
# In header_checks:
# /^Received:/ HOLD
2. SMTP Connection Timeouts & Denial of Service Defense
Because Amavisd-new holds the client’s TCP socket open during deep scanning, it is vulnerable to SMTP timeouts. RFC 5321 mandates a maximum timeout of 300 seconds for the DATA termination dot (.). If a complex archive (such as a 40MB nested ZIP file or high-entropy PDF) takes longer to decompress and scan than the remote MTA’s timeout threshold, the remote sender drops the socket and immediately retries, causing an endless queue accumulation loop.
MailScanner is completely immune to SMTP timeouts. Because Postfix writes to disk and acknowledges the remote client within milliseconds, external connections are never kept waiting. If MailScanner takes 45 seconds to scan a complex document, it occurs entirely out-of-band on local disk without tying up network sockets.
3. In-Band 550 Rejection vs Asynchronous Backscatter Risk
While MailScanner wins on timeout resilience, it suffers from a major deliverability flaw: backscatter spam generation.
Amavisd-new: Clean In-Band 550 Rejection
Because Amavisd-new scans while the external SMTP session is still open, it can instruct Postfix to reject spam or infected messages with a real-time 550 5.7.1 Message rejected as spam before the handshake finishes. The receiving server never takes responsibility for the message; the sending MTA handles the bounce locally. Zero backscatter is generated.
MailScanner: Asynchronous Backscatter Risk
Because MailScanner already sent a 250 OK acceptance to the remote server, it owns the message. If it later decides to bounce the email, it must compose a Non-Delivery Report (NDR) and send it back to the envelope sender address. Since spammers forge sender addresses, these NDRs strike innocent third-party mailboxes—instantly earning the server a listing on Backscatterer (DNSBL).
4. Disk I/O Queue Thrashing vs Resident Memory
MailScanner requires writing every single message to disk, unlinking it, scanning files in temp directories, and writing it back to an outgoing queue. On mechanical hard drives, this causes severe disk head thrashing and I/O bottlenecks. While enterprise PCIe NVMe SSDs mitigate this penalty, Amavisd-new remains significantly more efficient on storage hardware by streaming message payloads directly over memory sockets.
5. MailScanner vs Amavisd Technical Matrix
| Technical Dimension | MailScanner (Queue Spooler) | Amavisd-new (In-Band Loopback) | Deliverability & Sysadmin Verdict |
|---|---|---|---|
| Inspection Point | Out-of-band (disk spool hold directory) | In-band (local TCP port 10024/10025) | Amavisd: Compliant with modern real-time filtering |
| In-Session 550 Rejection | No (Message already accepted with 250 OK) | Yes (Rejects during active SMTP DATA phase) | Amavisd: Eliminates backscatter DNSBL listing risk |
| SMTP Timeout Vulnerability | Immune (Socket closes in milliseconds) | Vulnerable on large attachments / slow AV engines | MailScanner: Superior resilience against mail-bombs |
| Disk I/O Intensity | Very High (Multiple disk writes & directory reads) | Low to Moderate (In-memory socket streaming) | Amavisd: Far gentler on storage subsystems |
| Modern Relevance | Declining; mostly legacy cPanel & Sendmail | Stable standard in Debian/Ubuntu Postfix stacks | Amavisd: Better aligned with RFC standards |
The Backscatterer Catastrophe: How Out-of-Band Bounces Paralyzed Corporate Email
A hosting provider running MailScanner configured automated rejection notices for all spam exceeding score 8.0. Over a weekend, an overseas botnet hit the server with 450,000 dictionary attack messages with forged sender headers pointing to legitimate Microsoft and Apple domains. MailScanner accepted all messages, generated 450,000 NDR bounce emails, and flooded destination MX servers. Within 3 hours, their primary IP was blacklisted across UCEPROTECT and Backscatterer.org, halting all corporate outbound communications for 5 business days until an emergency cutover to in-band rejection was executed.
The AutoSMTP Deliverability Defense Advantage
Inbound and outbound filtering pipelines require robust underlying transport hardware. AutoSMTP provisions sovereign, dedicated bare-metal MTA infrastructure engineered for high-throughput filtering, synchronous 550 bounce suppression, and permanent reputation control.
Provisions fully licensed PowerMTA and KumoMTA clusters on enterprise bare-metal with dedicated IPv4 subnets and predictable flat pricing.
Monitors Google Postmaster spam ratios (<0.1%) and real-time ISP deferrals with algorithmic volume scaling across your entire IP pool.
RFC 5321 in-band 550 bounce suppression, automated Yahoo/Outlook Complaint Feedback Loops (CFL), and instant bad-IP eviction.
Pre-configured forward and reverse DNS (PTR) per IP, SPF CIDR alignment, 2048-bit DKIM rotation, and strict DMARC enforcement.
Upgrade Your Email Infrastructure with Dedicated Bare Metal
Eliminate filter lag, queue serialization bottlenecks, and noisy neighbor contamination. Deploy a turnkey AutoSMTP cluster today.
Deploy Turnkey MTA Cluster →