Issue Description
When an incoming message contains more Received: headers than the untrusted Sieve interpreter’s maxReceivedHeaders limit (default: 10), the redirect action is skipped due to loop protection. This is legitimate behavior in principle - however, the redirect is dropped completely silently: no event is emitted at any tracing level (checked down to trace), while other actions in the same script (e.g. fileinto) execute normally.
From an admin’s perspective the message simply vanishes: the Sieve rule visibly matched (fileinto worked), but the redirected copy never arrives, is never queued, and leaves no trace in the logs.
Expected Behavior
At minimum, a log event when the redirect is skipped (e.g. sieve.redirect-skipped / loop-protection, INFO or DEBUG level), so the behavior is diagnosable.
Actual Behavior
fileinto executes, redirect is skipped, zero log output related to the skip - even at trace level. Diagnosing this required manually bisecting the message (headers vs. MIME structure) because nothing in the logs pointed at the cause.
Reproduction Steps
- Default configuration (untrusted interpreter, maxReceivedHeaders = 10).
- User Sieve script containing both a fileinto and a redirect action.
- Deliver a message with 11 or more Received: headers (any real-world message that traversed a Microsoft Exchange / Outlook.com environment typically qualifies - my triggering messages had 11 hops).
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
Stalwart’s own SMTP DATA stage uses maxReceivedHeaders = 50 by default for the same loop-protection purpose, so messages pass the MTA check and then die silently in Sieve.
RFC 5321 §6.2 (referenced by RFC 5228 for loop control) recommends a large rejection threshold for Received counting, “normally at least 100”.
Real-world Exchange delivery chains routinely produce 10+ Received headers, so with the current default, redirects fail for a significant share of legitimate mail.
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.
on