Disabling the “Forward” option in ReportSettings (described as “Whether reports should be forwarded to their final recipient after analysis”) causes all incoming messages to be silently discarded, not just DMARC/TLS/ARF reports. The SMTP session still returns 250 2.0.0 Message queued for delivery., so sending MTAs consider delivery successful and never retry or bounce. Mail is lost with no trace.
Expected Behavior
The setting affects only inbound report messages (DMARC aggregate, TLS, ARF). Regular mail is unaffected.
Actual Behavior
Processing stops immediately after the DMARC check. The message is neither queued nor ingested, and no error is logged at any tracing level.
Reproduction Steps
Set forward to false in ReportSettings.
Send any regular (non-report) message to a local account over port 25.
Observe the SMTP session complete with 250, and the message never appear in any mailbox or queue.
Relevant Log Output
With tracing at trace, a working delivery produces:
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
I confirmed this in the source (crates/smtp/src/inbound/data.rs and crates/smtp/src/reporting/analysis.rs). What you’re seeing is real, but it’s scoped narrower than “all incoming mail”: it only affects messages from unauthenticated senders whose recipient matches the inboundReportAddresses pattern (default postmaster@*). For those messages, when inboundReportForwarding (called ReportSettings.forward in code) is false, the session code path is:
if !rc.analysis.forward {
self.server.analyze_report(...);
self.data.messages_sent += 1;
return (b"250 2.0.0 Message queued for delivery.\r\n"[..]).into();
}
It spawns the report analysis task and immediately returns a 250 success response without ever calling into queueing (queue.message-queued) or local ingestion. So any message that is classified as a “report” candidate (matching the report-address pattern) is analyzed and then dropped entirely, with the misleading 250 ... queued for delivery response and no corresponding trace event for the discard itself. If inboundReportAddresses is configured broadly (e.g. covering all or many of your local addresses, not just postmaster@*), this would indeed make it look like “all mail” disappears, since any message hitting that address pattern from an unauthenticated sender takes this path regardless of whether it’s actually a DMARC/TLS/ARF report.
This does not match the documented intent (“Whether reports should be forwarded to their final recipient after analysis” implies only actual reports are affected, and non-reports should proceed normally), and the misleading 250 response combined with the silent drop and lack of any log event is a real gap. This will need engineering follow-up rather than a docs fix, since the behavior diverges from the documented field description.