Don't remove the option “Move automatically to DeltaChat Folder"!

link2xt · October 22, 2026, 7:56pm

You can open the database (e.g. with sqlitebrowser) located somewhere in ~/.config/DeltaChat/accounts. If you have multiple profiles, refer to ~/.config/DeltaChat/accounts.toml for the order or just try all databases if you have multiple profiles and check the display name in the config table. Then find the transports table and modify the transport to add imap_folder: "DeltaChat" next to imap_user into configured_param. Here is an example of how it may look like:

github.com/chatmail/core

src/transport/transport_tests.rs

41eed949a


      
              }],
              smtp_user: "".to_string(),
              smtp_password: "bar".to_string(),
              certificate_checks: ConfiguredCertificateChecks::Strict,
          };
          
          param
              .clone()
              .save_to_transports_table(&t, &EnteredLoginParam::default(), time())
              .await?;
          let expected_param = r#"{"addr":"alice@example.org","imap":[{"connection":{"host":"imap.example.com","port":123,"security":"Starttls"},"user":"alice"}],"imap_folder":"Folder","imap_user":"","imap_password":"foo","smtp":[{"connection":{"host":"smtp.example.com","port":456,"security":"Tls"},"user":"alice@example.org"}],"smtp_user":"","smtp_password":"bar","certificate_checks":"Strict","oauth2":false}"#;
          assert_eq!(
              t.sql
                  .query_get_value::<String>("SELECT configured_param FROM transports", ())
                  .await?
                  .unwrap(),
              expected_param
          );
          assert_eq!(t.is_configured().await?, true);
          let (_transport_id, loaded) = ConfiguredLoginParam::load_all(&t).await?.remove(0);
          assert_eq!(param, loaded);

If you have multiple devices, also increase add_timestamp and add and remove another transport in the UI to trigger synchronization of all transports to your other devices.
This should work with 2.64.0, noting it here because this may get outdated.

I would not call it easier, not all providers even allow aliases and filters. When I tried to configure this sort of filtering with Mailcow I had to use X-Original-To header because there is no way to access original envelope address, it is already rewritten to non-alias address by the time the filter is reached: It may be unobvious that the "Deltachat" folder use case is going away (update: is apparently still being looked into) - #37 by link2xt

This problem with writing a proper filter have in the past resulted in users relying on filtering based on Chat-Version header. E.g. here is a bad advice that is not going to work anymore: Sieve rule to move DeltaChat mails to DeltaChat folder - #10 by cracker0dks
But then when the user realizes that the filter does not work and they cannot write a working filter, they are already receiving a lot of chat messages in their inbox and cannot get rid of them.

If you have your own server or server operated by someone for you, setup a separate mailbox with a separate login instead of an alias and a folder. There is no technical reason for why aliases are cheaper than proper mailboxes.

bleb · October 22, 2026, 10:39pm

Thanks for the instructions, I will update when I figure out which sqlite3 commands to run.

Okay, there are some circumstances where it is easier to add a new mailbox. But I am assessing usability in the context of a broader set of recommendations for ditching Google and reclaiming the communication platforms that already exist outside the control of Big Tech. The use of email aliases and filters seem like the simplest way to maintain the viability of email as a communication platform in the face of services that spam any address that you give them. Companies have recognized this and released services such as SimpleLogin (https://simplelogin.io/).

So if email aliases and filters are already part of this set of practical recommendations, using it for Delta Chat is the path of least resistance if we want people to contribute their own resources (e.g. an email account that they pay for) to sustaining the network. Delta Chat developers don’t have to take on this broader task of preserving or revitalizing the use of email, but I would ask you to consider the benefits of accommodating this work against the costs of exposing the imap_folder setting. I hope it makes sense why someone with my goals would insist on using a client that supports this option.

The emails I see in my inbox still have the Chat-Version header, so I guess you’re saying it’s not going to work at some point in the future? Having some way to identify from the outside that an email is a Delta Chat message doesn’t violate the “zero metadata” property that Delta Chat has been claiming, does it? Then I’m left wondering what’s the benefit of this planned change against the user disruption that you clearly foresee.

link2xt · October 22, 2026, 11:53pm

Filtering on the server based on Chat-Version was never supported, it only caused problems in the past e.g. when Mailcow introduced a filter that moved messages to DeltaChat folder: this resulted in users not receiving messages when they disabled moving to DeltaChat folder (and watching it). The filter also previously had a bug that resulted in unconditionally marking the messages as seen and user receiving notifications. There are also servers that removed Chat-Version header and this resulted in users not receiving messages when they had “show emails” setting turned off. There are also reports of some servers that delay messages with Chat-Version header, seemingly on purpose. One of these problems is mentioned in `Chat-Version:` header seems to do more harm than good meanwhile · Issue #8593 · chatmail/core · GitHub

Encrypting Chat-Version avoids all these problems with servers messing up with chat messages and we planned to move Chat-Version into encrypted part since we added RFC 9788 support (Don't prefetch Chat-Version header and don't copy it into outer part by iequidoo · Pull Request #7405 · chatmail/core · GitHub). It is basically the same logic as why QUIC is encrypting all the fields it can: to avoid middleboxes peeking into the traffic and making decisions. The only reason we did not do it from the start is compatibility problems that were solved with feat: Don't depend on cleartext Chat-Version, In-Reply-To, and References headers for prefetch_should_download by Hocuri · Pull Request #7932 · chatmail/core · GitHub and we had to wait around half a year to make sure everyone using old version with “show emails” setting not set to “all” have time to upgrade.

bleb · October 25, 2026, 12:08am

Thank you, that is very helpful for understanding the reasoning behind the planned encryption of the Chat-Version header. I might have some follow ups on this point, but first I wanted to repeat some questions I asked above:

Could someone please refer me to the announcement that @adbenitez is referencing here?

I am also still missing a clear picture of the reasoning behind removing support for shared email account usage via email aliases, which doesn’t depend on the Chat-Version header and would be enabled with a per-relay IMAP folder setting. Could someone in the know break down the costs/benefits of removing this facility?