Adding a relay leads to "Error: Cannot use multi-transport with mvbox_move enabled"

[ell1e]

When I try to add a chatmail relay, I first get this dialog:

When I press "Yes", I just get shown the relay list again, but with no relay added. There is no error message shown inside deltachat-desktop. However, the log shows this message, which looks like a chatmail core error:

2025-12-20T22:46:20.388Z renderer ERROR "\nfile:///app/delta/resources/app/src/App.tsx:125:10" "Unhandled Rejection: Configuration failed. Error: Cannot use multi-transport with mvbox_move enabled." {"isTrusted":true} {"code":-1,"message":"Configuration failed. Error: Cannot use multi-transport with mvbox_move enabled."}

In the DC Community room, some other users ran into this as well when trying to add a relay. So this seems to be a relatively common error. Is it somehow related to using the "Deltachat" IMAP subfolder perhaps? I got that enabled, specifically the only check for mail in that subfolder option.

• Operating System (Linux/Mac/Windows/iOS/Android): Linux
• Core Version: core v2.33.0
• Client Version: desktop 2.33.0 via flathub

Expected behavior

Adding a relay works

Actual behavior

Adding a relay silently fails, log shows error that seems to be a chatmail core error.

Steps to reproduce the problem

1. Try to add a relay

Screenshots

See above

Logs

2025-12-20T22:46:20.388Z renderer ERROR "\nfile:///app/delta/resources/app/src/App.tsx:125:10" "Unhandled Rejection: Configuration failed. Error: Cannot use multi-transport with mvbox_move enabled." {"isTrusted":true} {"code":-1,"message":"Configuration failed. Error: Cannot use multi-transport with mvbox_move enabled."}

[ell1e]

Potentially relevant options shown. Interestlingly, the "Only Fetch From DeltaChat Folder" is only relevant for my base account, and I wonder if part of the problem is that it doesn't seem to be a per-relay option.

For what it's worth, if "Only Fetch from DeltaChat Folder" is removed, I won't be able to use DeltaChat via my current setup anymore, although I don't know how common that would be. But I have a feeling it wouldn't be just me:

Interestingly, my kind of setup doesn't really rely on the "Move" part, since incoming mail for DeltaChat uses a different alias that already causes it to be moved into the folder on the server side. Many classic e-mail accounts have multiple aliases, and the easy option to e.g. automate moving something coming from an alias into a subfolder, but don't have multiple inboxes. It therefore seems like the only option really essential for such a setup is "Only Fetch From DeltaChat Folder", which I'm guessing might therefore impact a significant amount of users if removed. The chat protocol header for example isn't important either when using aliases, only this option is.

Anyway, I don't want to discuss removal plans here since it probably belongs into the forum, I just wanted to make you aware.

[Simon-Laux]

that the error is not shown to the user is an desktop issue (deltachat/deltachat-desktop#5868), that was already fixed, so should be in the next release.

Also the error messages were improved to be more user friendly in #7604, which will also be in the next release.

For what it's worth, if "Only Fetch from DeltaChat Folder" is removed, I won't be able to use DeltaChat via my current setup anymore, although I don't know how common that would be.

you could probably redirect the alias to a different mailbox and still use old smtp server and credentials for sending?

[Simon-Laux]

Anyway, I don't want to discuss removal plans here since it probably belongs into the forum, I just wanted to make you aware.

So this issue is then only about that the error is not shown and about what to do as a user. As a user you need to disable the special options, in your case migrating may include custom steps, but your usecase is a custom variant of the usecase that we don't support anymore -> using the same mailbox with DC and other email clients other than delta chat.
Those options will be removed sooner or later see #7631

In my understanding we can close this issue and discuss the other topic in other issues or on the forum.

---

Maybe it would be a good idea to start an unofficial forum topic where users can share tricks to make it work even though it is unsupported, or how to migrate to a supported setup.

[ell1e]

don't support [...] using the same mailbox with DC and other email clients other than delta chat.

Just to point it out, I feel like that's going to kill off most remaining classic mail users that don't use a paid VPS, which increases the barrier for self-hosting somewhat (a shame, that's one of the things that's cool about DC).

But wouldn't it make sense to support relays for this use case, so that users can actually migrate away with them? I'm actually not sure how to migrate away, even if I had a separate mailbox, which I won't have a for a while.

I would definitely be interested in a forum thread on how to deal with this situation, if there's one.

[iequidoo]

Potentially relevant options shown. Interestlingly, the "Only Fetch From DeltaChat Folder" is only relevant for my base account, and I wonder if part of the problem is that it doesn't seem to be a per-relay option.

So the bug is that the "Move automatically to DeltaChat folder" setting is checked before "Only fetch from DeltaChat folder" when adding a relay, but the former setting has no effect in presense of the latter, i.e. the checks should be done in the reverse order so that the correct log entry appears. Of course, it should be (and it is already) fixed in Delta Chat Desktop that these errors aren't shown to the user.

Anyway, there's no regression because it's a new feature and it was decided to forbid the aforementioned settings enabled in presense of multi-transport because those settings make no sense for chatmail, we don't want to move messages to DeltaChat for one transport and not to move for another. The same for fetching messages from INBOX/DeltaChat.

[iequidoo]

But wouldn't it make sense to support relays for this use case, so that users can actually migrate away with them?

If you want to migrate away from your email account where all emails arrive to DeltaChat (so you have OnlyFetchMvbox enabled) to chatmail, this is indeed hard to do currently because some emails will still arrive to "DeltaChat" in your old account, but this looks like a feature request.

[ell1e]

It wasn't meant to be on my end, although it might be useful to rephrase the error message to explain it better. I was simply pointing out the caveats. This thread might be useful for feature plans if any. Feel free to close this issue at any point, I'm not exactly sure what tasks might still be left to do e.g. in regards to the error not showing in the UI, and so on.

[adbenitez]

I think it would be better if when adding a transport the dialog just warns that such legacy options will be disabled and then proceeds with success, otherwise this failures to add transport are worse

(this would need to be done in the clients, not in core)

[adbenitez]

Just to point it out, I feel like that's going to kill off most remaining classic mail users that don't use a paid VPS

@ell1e these people can continue to use delta chat the same way as it was recommended, using that email account only for chats, they don't need a vps etc. what they shouldn't do is use the same email account for DC and other email client at the same time because that has a lot of problems we can't care about, in your particular case it is even more special, you are one of the 0.01% that went as far as using "only fetch from DeltaChat folder" option + server-side filters which most people don't do or is not supported by their webmail

[ell1e]

these people can continue to use delta chat the same way as it was recommended

I elaborated on the forum why for technical reasons that's sometimes not possible! (And there is also no clear migration away from this right now.)

[adbenitez]

yeah, but there you are talking about someone paying to some provider, in that case they can just use free chatmail accounts for chatting, without needing to pay for another address/inbox to such provider