My use case is built around a small group of users, all chatting with Delta Chat through emails on the same domain and the same hosted MailCow server.
I had been using DeltaChat for a few years, based on the old setup of email/subfolder. Chat effectively stopped working through updates in recent months. This may or may not be related to the fact that we didn’t proactively enable the new settings (giving up the subfolder).
Whatever: I accept that this solution is effectively not supported any more, so I decided to give up on this unmaintained solution, and just created new email accounts to be used only with DeltaChat for all people involved.
The process seems to work just fine: I can create the new Delta Chat account, the app says it’s connected, all looks fine.
However, when I do add one of the other users and try to send a message, the message is apparently sent as expected, but I do not receive it on the other device.
Key facts:
all involved devices use the latest version 2.57.0
all involved accounts are newly created email accounts on hosted MailCow, that have nothing else in them besides DeltaChat
connection setup seemingly works fine, all accounts created with v2.57.0
messages are sent fine, but never received by the recipient
if I check in the email account itself, I can see that there are a bunch of encrypted messages in a “DeltaChat” subfolder (I expected them to be in the Inbox, but there is now no setting anywhere visible that allows me to customise this option) - this includes messages from both users
messages to self, and sent messages are not synced across devices
How can I troubleshoot this further?
I appreciate that relays are now the default option, but I also understand email accounts (accounts used only for Delta Chat) are still supported and will be supported in the future. I’d much rather not add external relays, and see no reason why my setup shouldn’t work. I’m sure it’s just some small issue related to folders, or some other (semi)invisible setting, so I’d really welcome guidance in order to be able to get back to using Delta Chat.
Do you mind specifying how you added the contact? By QR code or link?
That process is also supposed to do an email round-trip. If it succeeded then it means that messages were actually exchanged.
I’ve tried tinkering switching back and forth between the SSL and STARTTLS connection, and dropping the “enforce encryption for all relay options”, and such, but to no avail. Log looks seemingly fine. But if there is anything I should be looking for specifically, happy to check it out.
I’ve tried both, and yes, messages were actually exchanged, as I can see them (encrypted) in webmail, from both users, but nothing in DeltaChat itself.
Adding the user seemingly worked well through both QR and link, but the messages were not received, and the newly started chat was not visible from the other device used by the sending user.
So when you add a contact it first says “Establishing connection, please wait…” for a second and then “Messages are end-to-end encrypted. Tap to learn more.”?
And sending follow-up messages displays one checkmark on them?
Sounds weird, maybe someone else knows better.
Maybe some server-side filtering issue or something. Or maybe the receiving side’s logs show something interesting when the sender sends a message.
Thanks for your support and look forward to any further advice!
I found it slightly surprising that when I look in webmail of this newly created email account, the messages are stored in a DeltaChat folder, which I thought was not going to be the case, but perhaps this is all as expected.
Yes, “add profile” → “I already have a profile” → “add as second device”.
the messages that are “sent to self” before adding the second device appear also on the second device, but new messages do not appear.
It appears the issue is that the new account sends messages just fine (and they are visible encrypted in webmail), but simply cannot read them back, although the Log gives no connectivity error.
But I think here is the issue, ultimately. The log shows the following:
"src/imap/select_folder.rs:78: Transport 1: Selected folder \"INBOX\"."
2026-08-12T11:57:11.499Z core/event INFO "" 2 "src/imap.rs:541: Transport 1: No new emails in folder \"INBOX\"."
2026-08-12T11:57:11.508Z core/event INFO "" 2
But as I mentioned, if I look at the mailbox in webmail, the messages are effectively stored in a DeltaChat subfolder.
I wonder if the issue here is that even if I’m creating a new DeltaChat account with a new email account, the fact that the same app already had a user with classic email based on the DeltaChat subfolder (as used to be common) somehow led the new account to also store message in the DeltaChat sub-folder when it writes them, but not when it reads them.
I assumed other accounts on the same app wouldn’t matter, but I will try to troubleshoot this further resetting completely the app from previous accounts.
And there we are: if I go into webmail, and manually move emails from the DeltaChat folder to Inbox, then all messages arrive.
The puzzling question is how a newly created profile on a newly created email account decided to store messages in the DeltaChat subfolder in the first place.
But also, how do I move forward? If I send new messages, they again end up in the DeltaChat subfolder.
I suppose that if I completely reset all apps involved and all accounts involved, the issue will be solved, but surely, this is not the intended behaviour when creating a new profile, no matter what the settings were for previous profiles.
Also, glancing at the “refactor” MR I mentioned, kind of looks like deleting the “DeltaChat” folder could work (as long as you don’t have anything important there, of course)?
Are you sure that there’s no server rule in place that moves messages to the DeltaChat folder (the server-side filtering as mentioned by @wofwca)?
If there are no server rules in place that move messages: Are you sure that there are no devices that are running an earlier version of DC for the given profile?
These are newly created email accounts, with no settings and not even a login done before using DeltaChat.
And I checked, all devices involved had version 2.57.0.
But, all devices involved had a previous profile which relied on the previous setting of using a DeltaChat folder.
I’ve tried completely removing local storage of DeltaChat on the host machine, so that this would result in a clean DeltaChat install, created a new profile, and indeed, all went seemingly fine, messages are sent and received alright. I will try this on the other accounts involved, but I don’t expect anything different. So there was no issue with the email server, the issue was somewhere in local settings of DeltaChat.
In brief, the only explanation I see is that somewhere in local configuration files the setting of using a DeltaChat folder stuck and applied even to new profiles.
So I must give up on the previous account (even if I suppose that reimporting it afterwards -would work), but besides it, probably everything will be back to normal after I completely reset local storage of DeltaChat for all devices involved.
Amending previous messages, I have to say that the issue has not been fixed by removing all local DeltaChat files (the one time I thought it worked, I inadvertedly took a non-email relay).
So I’m still stuck.
I’m considering the option that the issue may be MailCow specific, e.g. that some earlier integration introduced to enhance DeltaChat support in MailCow servers support is now effectively leading to troubles, by automating moving emails to a DeltaChat subfolder.
This would be consistent with previous suggestions that this may be a server-side issue, although not determined by any visible setting.
I will try to figure out if there may be something on MailCow’s side. If anybody happens to know anything about it, that would be welcome.
