Executive Summary: End-to-end technical guide to PowerMTA Feedback Loop (FBL) processing: configuring pipe directives, parsing RFC 5965 ARF payloads, and syncing real-time suppression lists.
PowerMTA’s built-in feedback loop (FBL) processing framework is one of the most underutilised features in bulk email operations. Most operators register for Yahoo FBL and Microsoft JMRP and have complaint reports delivered to a mailbox — then process them manually or not at all. PowerMTA can process ARF-format complaint reports automatically: parsing the original message headers to identify the sending stream, extracting the complainant’s address, and feeding it directly into your suppression pipeline without human intervention. This document covers the full implementation from FBL configuration to automated suppression.
How PowerMTA FBL Processing Works
PowerMTA handles FBL reports as inbound email delivered to a specially configured virtual MTA. When a Yahoo or Microsoft FBL report arrives at your designated feedback address (e.g., fbl@mail.yourdomain.com), PowerMTA receives it at the SMTP level, parses the ARF structure, and routes it to a processing script via a pipe directive. The processing script extracts the complainant’s email address from the Original-Recipient header in the ARF report body and adds it to a suppression database or file.
This architecture has significant advantages over mailbox-based processing. There is no latency from mailbox polling — suppression happens at SMTP delivery time. There is no risk of FBL reports getting lost in a shared mailbox or spam folder. And the processing logic lives in a versioned script rather than an ad-hoc manual process.
PowerMTA Configuration for FBL Reception
# Define a virtual MTA for inbound FBL reception
# virtual-mta fbl-inbound
# smtp-source-host 0.0.0.0 [your-ip]
# host [your-ip]
# /virtual-mta
# Define the FBL domain to receive reports
# domain fbl.yourdomain.com
# type mx
# route [your-ip]:25
# Accept connections from Yahoo, Microsoft, Comcast FBL servers
# accept-from 66.228.36.0/24 # Yahoo FBL IP range
# accept-from 157.55.0.0/16 # Microsoft FBL IP range
# accept-from 69.252.80.0/20 # Comcast FBL IP range
# /domain
# Route all mail to fbl.yourdomain.com through the processing pipe
# recipient-domain fbl.yourdomain.com
# pipe-record "/opt/pmta/scripts/process-fbl.py"
# PowerMTA pipes the raw ARF email to this script's stdin
# /recipient-domainThe FBL Processing Script
The processing script receives the full ARF report on stdin. It must extract the complainant address and write it to your suppression system within the SMTP session window — PowerMTA waits for the pipe command to exit before returning a response to the sending FBL server. Keep the script fast: database writes or API calls that exceed 30 seconds will cause timeouts.
#!/usr/bin/env python3
import sys, email, re, sqlite3, logging
from datetime import datetime
SUPPRESSION_DB = '/opt/pmta/data/suppressions.db'
LOG_FILE = '/var/log/pmta/fbl-processing.log'
logging.basicConfig(filename=LOG_FILE, level=logging.INFO,
format='%(asctime)s %(levelname)s %(message)s')
def init_db(conn):
conn.execute(
"CREATE TABLE IF NOT EXISTS suppressions "
"(email TEXT PRIMARY KEY, source TEXT, added_at TEXT)"
)
conn.commit()
def parse_arf(raw):
msg = email.message_from_string(raw)
complainant, source_ip = None, None
for part in msg.walk():
if part.get_content_type() == 'message/feedback-report':
try:
payload = part.get_payload(decode=True)
text = payload.decode('utf-8', errors='replace') if payload else str(part.get_payload())
m = re.search(r'Original-Recipient:s*rfc822;s*(.+)', text, re.I)
if m: complainant = m.group(1).strip().lower()
m2 = re.search(r'Source-IP:s*(.+)', text, re.I)
if m2: source_ip = m2.group(1).strip()
except Exception as e:
logging.error(f"Parse error: {e}")
return complainant, source_ip
def suppress(conn, addr, source):
try:
conn.execute(
"INSERT OR IGNORE INTO suppressions (email, source, added_at) VALUES (?, ?, ?)",
(addr, source, datetime.utcnow().isoformat())
)
conn.commit()
return True
except Exception as e:
logging.error(f"DB error: {e}")
return False
def main():
raw = sys.stdin.read()
conn = sqlite3.connect(SUPPRESSION_DB)
init_db(conn)
complainant, source_ip = parse_arf(raw)
if complainant:
ok = suppress(conn, complainant, source_ip or 'fbl')
logging.info(f"{'Suppressed' if ok else 'FAILED'}: {complainant} ({source_ip})")
else:
logging.warning("No complainant address found in FBL report")
conn.close()
sys.exit(0) # Must exit 0 for PowerMTA to accept the message
if __name__ == '__main__':
main()Querying the Suppression Database
The SQLite database works well for single-server deployments. For multi-server setups, replace the SQLite write with a call to a centralised Redis set, PostgreSQL table, or your ESP’s suppression API.
# Count suppressions in last 7 days (complaint rate indicator):
sqlite3 /opt/pmta/data/suppressions.db
"SELECT COUNT(*) FROM suppressions WHERE added_at > datetime('now', '-7 days');"
# Export all suppressions to CSV for ESP import:
sqlite3 -csv /opt/pmta/data/suppressions.db
"SELECT email, source, added_at FROM suppressions ORDER BY added_at DESC;"
> /tmp/fbl_suppressions_$(date +%Y%m%d).csv
# Find IPs generating most complaints (last 30 days):
sqlite3 /opt/pmta/data/suppressions.db
"SELECT source, COUNT(*) as complaints FROM suppressions
WHERE added_at > datetime('now', '-30 days')
GROUP BY source ORDER BY complaints DESC LIMIT 10;"
# Check if an address is suppressed:
sqlite3 /opt/pmta/data/suppressions.db
"SELECT * FROM suppressions WHERE email = 'user@example.com';"Deployment Checklist
Before going live, verify each step in this checklist. Missing any one item causes the processing chain to fail silently.
▶ FBL processing deployment checklist
fbl.yourdomain.com MX 10 mail.yourdomain.com. Without this, FBL reports cannot be delivered to your PowerMTA.cat test_arf.eml | python3 /opt/pmta/scripts/process-fbl.py. Confirm address appears in suppression database.Before: FBL reports to a shared mailbox, processed manually twice per week. Average lag from complaint to suppression: 3.5 days. Complainants continued receiving campaigns during this lag, generating additional complaints.
After PowerMTA pipe implementation: Suppression applied within 8 seconds of complaint receipt. Yahoo complaint rate dropped from 0.09% to 0.04% within 6 weeks as re-complaint events were eliminated. Microsoft SNDS colour for all IPs remained Green continuously for 4 months post-implementation.
Last updated: September 3, 2025