Add option to process unencrypted messages

[link2xt]

We currently have an is_chatmail config option that is set automatically when you connect to an IMAP server that has XCHATMAIL capability. This roughly means that the server is a chatmail relay and can only process encrypted messages¹, so UIs disable some features like adding contacts by email address, hides settings that are related to folders like mvbox_move and changes available options for delete_server_after.

This distinction between chatmail and non-chatmail profiles does not work well for multi-transport (#7357) as the user can start with a non-chatmail profile, but then add a chatmail transport and set it as the primary address.

As the primary distinction between chatmail and non-chatmail is the ability to work with unencrypted messages, unencrypted chats and email-address-contacts, the idea is to add a setting "enable unencrypted messaging" that is disabled by default for all profiles and can be manually enabled if the user want to use the client for unencrypted messaging.

If the setting is turned off, the client will drop all unencrypted messages into trash chat. UIs can also use this setting to decide whether to allow adding a contact by email address and whether to allow creating a new unencrypted chat, instead of using is_chatmail for this.

One exception is NDNs. NDNs should still be processed for now even though they are not encrypted. It is not clear we really want to keep processing them and displaying errors especially with multi-transport where one failing transport does not mean you need to worry, but for this issue changing how we work with NDNs is out of scope, let's see how it works in practice first.

Footnotes

1. Operator can configure exceptions for some addresses and otherwise customize the relay, but we likely don't want to support this long term. ↩

[Simon-Laux]

would it make sense to set it to true in migration if user is either on non-chatmail or has unencrypted chats?

[r10s]

first, i like the idea. it would upgrade "use classic mail as transport" closer to the security chatmail is offering.

however, having such a switch in the normal at "advanced settings", would look like a worsening to the situation we have now. and would add confusion to the user and to ppl judging about how "safe" delta chat is.

it would also not work for most profiles.

but having that switch available with "Use Classic Email at Transport" would be fine - also natural, as this is the place where we currently say "Classic email server allow chats without end-to-end encryption marked by a mail icon" - we could strike that. dialog could look as follows:

[link2xt]

@r10s This looks like having the setting per-transport and we likely don't want to make this per-transport configurable, in the end you have unencrypted chats in the chatlist regardless of your transports.

[r10s]

idea after discussion with @hpk42 and @link2xt is:

a profile with more than one transport cannot have "Enable Unencrypted Messaging" being set on any of them

that way, the option can stay in "Edit Transport" as shown above.

core must not allow adding a transport when the first one has "Enable Unencrypted Messaging" set - and the other way round, not allow setting "Enable Unencrypted Messaging" if there are multiple transports.

this maintains the typical usecase we have today - a classic address being used for classic email. there, the expectation is not that multi-transport is working. and we also do not remove anything for that usecase.

but: you can add chatmail and non-chatmail transports in any order with the default options.

this cut probably makes also makes multi-transport easier as some cases cannot happen - eg. the question from where to answer an unencrypted message

[iequidoo]

whether to allow adding a contact by email address

Note that even now chatmail users can have email-address-contacts, e.g. if an encrypted multi-recipient message arrives -- it will be assigned to an unencrypted group with address contacts.

Is a UI option for this really needed? Can't we just disable processing unencrypted messages if the user switches to a chatmail primary address, showing a warning to the user? And if the primary address is non-chatmail, allow unencrypted messages. Otherwise if the user wants to use multi-transport, but also needs unencrypted messaging, they need to create two separate profiles and this actually will be the "shared mailbox" use case which we don't want to support.

[link2xt]

Note that even now chatmail users can have email-address-contacts, e.g. if an encrypted multi-recipient message arrives -- it will be assigned to an unencrypted group with address contacts.

This is not nice, but this is already how it is, not a new problem. If this happens, user gets a chat where they cannot reply. You can probably also get unencrypted contacts by importing a vCard and some other ways, but UIs should not offer it when the user enters an email address in the search bar.

Can't we just disable processing unencrypted messages if the user switches to a chatmail primary address, showing a warning to the user?

We want to get rid of is_chatmail, not to make it per-transport. Ideally we don't need to distinguish between chatmail and non-chatmail addresses.

Otherwise if the user wants to use multi-transport, but also needs unencrypted messaging

If user already has an existing profile used for unencrypted messaging, then they cannot add second transport.

they need to create two separate profiles and this actually will be the "shared mailbox" use case which we don't want to support

If the user creates a second profile to use multi-transport, they can just not configure existing mailbox as the transport.

"Shared mailbox" is a mailbox shared with other MUA. Sharing a single mailbox between multiple profiles is strange, but might actually work if all messages that cannot be decrypted and unencrypted messages are ignored by each profile. Likely not something we want to support as well, but so far this was never seriously discussed.

---

In short, why it is like this: we want to support multi-transport as soon as possible, but we don't want to spend a lot of effort on multi-transport unencrypted messaging and all the problems that come from it such as having some transports that do not allow unencrypted messaging, having to remember which address we use in which chat and so on. So multi-transport and unencrypted chatting is mutually exclusive, you can have unencrypted chatting without multi-transport and vice versa.

[iequidoo]

Supporting multi-transport for unencrypted messages isn't necessary, instead we could:

• Allow unencrypted messaging if the primary address is non-chatmail.
• Use multi-transport only for encrypted messages.

This way a new UI option isn't needed (but can be added if we want to allow disabling unencrypted messaging manually also), a warning may be shown instead.

We want to get rid of is_chatmail, not to make it per-transport. Ideally we don't need to distinguish between chatmail and non-chatmail addresses.

But in case of "single-transport", how do we know if unencrypted messaging is possible at all?

[link2xt]

But in case of "single-transport", how do we know if unencrypted messaging is possible at all?

For existing configurations, likely is_chatmail converted to this option during migration as @Simon-Laux wrote above.

For new configurations, unencrypted messaging is off by default and we know by the user enabling it. If user enables it on chatmail, then attempts to send unencrypted messages results in errors from the server, but we don't need to do anything special to guess on the client whether unencrypted messaging is allowed.

[iequidoo]

So "unencrypted messaging" is controlled by the user. But this doesn't make it impossible to only use multi-transport for encrypted messages and the primary transport for unencrypted (if the user enables it).

[hpk42]

On Tue, Nov 25, 2025 at 10:21 -0800, iequidoo wrote: iequidoo left a comment (chatmail/core#7494) So "unencrypted messaging" is controlled by the user. But this doesn't make it impossible to only use multi-transport for encrypted messages and the primary transport for unencrypted (if the user enables it).

If you need unencrypted messages, then you can use a single-transport profile and enable "allow unencrypted". There is no need to mix multi-transport usage into this kind of unencrypted profile. This is no regression to how things are now (because no one has multi-transport).