• Mail arrives at info@{hostedDomainB} (mailbox).
• Sieve filter on info@{hostedDomainB} redirects to alan@{hostedDomainB} and malcolm@{hostedDomainB}.
• Both alan@{hostedDomainB} and malcolm@{hostedDomainB} mailboxes also have Sieve rules that redirect to their external {externalDomain} addresses.

Expected:
Messages should reach {externalDomain}.

Observed:
The second redirect (Alan/Malcolm → {externalDomain}) generates a malformed SRS MAIL FROM such as: SRS0=17e0=36={hostedDomainA}=dustin@{hostedDomainB}

This string is invalid because it lacks the final @<srs-domain> (according to ChatGPT). The result is a permanent SMTP error: 550 5.1.0 … invalid address

"550 5.1.0 <SRS0=17e0=36={hostedDomainA}=dustin@{hostedDomainB} invalid address '<SRS0=17e0=36={hostedDomainA}=dustin@{hostedDomainB}'"

If I recreate info@{hostedDomainB} as a mailing list (what it used to be) instead of a mailbox with Sieve, forwarding works fine. So this seems to be a bug somehow in the way the filtering is handled when redirecting mail across multiple hops on Cloudron, where it seems to choke on the second hop.

It looks like Haraka’s SRS plugin fails when a message is redirected twice via Sieve filters.

Are we aware of any known issues on this? I couldn't find this in the forum posts earlier in a quick search but maybe I missed it. Ultimately if we have three mailboxes created, and one has a sieve filter to the other two mailboxes and those two mailboxes in-turn have a sieve filter each to send to the respective external addresses not hosted on Cloudron, then this is when the issue is seen.

PS: (I was running low on time to send this into the forum here so used ChatGPT to format this quick summary as I was using it to help me troubleshoot earlier, so if it reads a little odd that's why, lol. Have to run but will be checking on this later today).