Issue Description
Hi,
I’m running Stalwart 0.16.14 and trying to archive outgoing mails from a shared mailbox into a “Sent Items” folder using a system Sieve script in the DATA stage.
Question:
Is redirect :copy intentionally disabled or restricted in the DATA stage for authenticated submissions (port 465)? If so, what is the recommended way to archive outgoing mails server-side in Stalwart 0.16?
Any help appreciated!
Expected Behavior
A copy of the Mail should be sent to the “Sent Items” of the authenticated user.
Actual Behavior
The script is executed – logs show Sieve action: Accept (sieve.action-accept) for every submission
However, no redirect is performed – no Sieve action: Redirect in the logs
No copy arrives at [email protected]
Sub-addressing is enabled
Reproduction Steps
Stalwart 0.16.14, binary installation on Ubuntu 24.04
System Sieve script configured in MTA → Session → DATA Stage
Script is active and assigned correctly
The script (simplified to bare minimum for testing):
sieve
require [“copy”];
redirect :copy “[email protected]”;
Relevant Log Output
DEBUG Sieve action: Accept (sieve.action-accept) listenerId = “submissions”, localPort = 465, id = “savesent”, elapsed = 0ms
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
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
redirect :copy is not disabled for authenticated submissions and nothing special-cases port 465, so the script is running. The reason you see no Redirect line is that there is no such log event: the trusted interpreter only logs accept, reject, replace and discard, and :copy leaves the keep action in place, which is exactly what produces the accept line you are seeing. To tell whether the redirect happened, look for a queue event for a new outbound message rather than a Sieve action.
What redirect actually does at that stage is: it builds and queues a brand new message, sent from MAILER-DAEMON@yourdomain with an empty return path, which then goes out through the normal outbound queue. If the target is external it can fail there without the script ever knowing. And if the target is local with sub-addressing enabled, the +sent detail is stripped before delivery and nothing records the original address, so the receiving account cannot tell that copy apart from anything else it receives.
On the underlying goal: there is no way to file a copy into a mailbox from an MTA-stage script, fileinto is deliberately not available in the trusted interpreter. So server-side sent-mail archiving in that shape does not have an answer today. If you want the copy in the sender’s own Sent folder, that is a client concern and most clients upload there themselves. If you want a separate archive mailbox, the workable route is redirecting to a dedicated local account with a user Sieve rule on that account. Which of the two are you after?
Thank you for the detailed explanation – that clears things up completely.
We now understand why the redirect is working but the copy cannot be filed into a specific folder from the MTA stage, and why the sub-address stripping prevents the user script from identifying the copy.
For our use case (a shared notification mailbox where sent copies should be visible to all users), we will go with your suggested approach: redirecting to a dedicated local archive mailbox and using a user Sieve script on that account to organize the incoming copies.
Thanks again for the quick and thorough response!