Cloudron 10.0.1 upgrade breaks chained forwarding addresses

[d19dotca]

I encountered what appears to be a mail-forwarding migration regression after upgrading from approximately Cloudron 9.2.0 to 10.0.1.

Before the upgrade, I had forwarding chains like:

address-a@example.com
→ address-b@example.com
→ external-recipient@example.net

Cloudron 10 migrated the former forwarding addresses into mailboxes with forwarding enabled, but these multi-stage chains no longer worked.

Mail sent to the first address was accepted and redirected to the second local mailbox, but never reached the external recipient. The messages remained in:

/home/yellowtent/boxdata/mail/haraka-queue

The queued messages confirmed that the first redirect occurred:

X-Sieve-Redirected-From: address-a@example.com
Delivered-To: address-a@example.com

After affected messages entered the queue, the entire mail service became unreliable. Roundcube reported:

SMTP Error (0): Connection to server failed.

Sending and receiving mail stopped working. Restarting the mail service did not resolve it because the problematic queue entries and forwarding configuration remained.

I recovered by:

1. Moving the four stranded messages out of haraka-queue.
2. Changing each affected mailbox to forward directly to its final external recipient, eliminating the intermediate local forwarding mailbox.
3. Restarting the mail service.
4. Replaying the preserved messages through SMTP.

All replayed messages received SMTP 250 responses and appeared as Sent in Cloudron’s event log. New mail is also working normally.

Possible reproduction

1. On Cloudron 9, create a forwarding address A that forwards to another local forwarding address B.
2. Configure B to forward externally to C.
3. Upgrade to Cloudron 10.0.1.
4. Send mail to A.
5. Check whether it reaches C or remains in haraka-queue.

It may also be reproducible directly on 10.0.1 by configuring forwarding-enabled mailboxes as:

A → B → external C

My suspicion is that the migration preserves each forwarding relationship without flattening the chain, while the new forwarding implementation does not safely handle mailbox-to-mailbox forwarding chains.

[james]

Hello @d19dotca
Thanks for reporting, I will look into this.

[james]

Hello @d19dotca
I was able to reproduce your issue.
A forwarding chain from fw1@cloudron.dev > fw2@cloudron.dev > james@cloudron.dev worked without issues.
But a chain from fw1>fw2>placeholder@gmail.com did not forward the mail to Gmail.

[avatar1024]

May not be related but I faced issues with those kinds of double forwarding even before Cloudron 10: https://forum.cloudron.io/post/99639

[james]

Hello @d19dotca
A warning.
When doing a chain forwarding like fw1 > fw2 > external on Cloudron 10.0.2 the haraka service crashes inside the mail service.
The mail service stays running but since the harka service inside stopped working all mail related things will fail.
A mail service restart will also not resolve the issue since haraka keeps crashing.

The solution I found is removing the forwarding config from the fw1 and fw2 mail boxes and then restarting the mail service.
But if you re-add these forwards again and send a mail to fw1 the same thing will happen.

So @d19dotca please check your mail service container by connecting to your server with ssh and running:

docker exec -ti mail supervisorctl status

If that reports:

haraka                           FATAL     Exited too quickly (process log may have details)

you are affected by this issue.
Remove the forwards and restart your mail service.

[d19dotca]

@james Hi James. I think you may have misunderstood my current status. Sorry for any confusion there.

I already found the root cause and worked around it by manually flattening the forwards I had in place which were affected, so by going from A to B to C to instead using A to C directly, cutting out the middle layer forwarding chain. It’s all fixed for me at the moment, although I would prefer to use the original chain so that aliasing works well whenever C needs to be updated so that only one account needs to be updated instead of several.

But I am reporting it here to the Cloudron team because it still should be a use-case that is handled by Cloudron in the migration from mailing lists to the new forwarding style.

Cloudron either needs to flatten the mailing lists so that A goes directly to C instead of via B, or else Cloudron needs to properly support A to B to C as it did before.

Otherwise when 10.0 goes out to more people you’re going to have a lot of complaints from users who use the same forwarding scheme.

[girish]

Thanks for the report @d19dotca . It's fixed for 10.0.2.

The issue was that when having multiple internal forwards, sieve was adding multiple headers. The haraka code headers.get() was concatenating all the headers with '\n' and this caused a crash since I wasn't expecting haraka to concat it this way. There is a get_all() API which returns an array and I pick the latest forwarder from there.