2.62 broke mixed use of regular email and chatmail relays for one identity

Mutual Help
, ,
1

Not being able to pick a primary relay means I can’t send an unencrypted email with my regular email and then switch back. If there’s a way, please tell me how because I couldn’t find it.

This use case was important to me because it’s how I could DeltaChat while at work by going through an encrypted relay but have the same identity. It’s broken now and I’ll have to either (1) not upgrade, depending on how far backwards compatibility will be broken in the future (2) make multiple identities, which is something I didn’t want to do, due to the logistics of trying to synchronize a new identity at work or (3) finally start making my own client.

I’m trying to be as civil as possible, but the changes are upsetting to me: trying to replicate Signal over email is not the thing I liked about DeltaChat. What I liked was that it was progressive security that recycled existing technologies rather than reinvent. That is what autocrypt, in my opinion, was genius. I thought DeltaChat was really clever. It was using things I already had and other people had - I got to own my messages in a chat experience.

Trying to be Signal over email is exactly the thing that bothers me about computer security, security researchers, etc. - that there’s never compromise and usability is always at the bottom of the list. Yeah, PGP/GPG isn’t perfect, but the ideas behind autocrypt v1 went a long way to on-boarding rather than forcing.

I doubt I’m going to change anyone’s mind and you’re not going to change mine, but I know my use case isn’t important anymore. That makes me sad because I was really enthusiastic about DeltaChat until I started seeing the signs of the direction it was heading.

I know all the arguments that will be made pro-security and the future of DeltaChat - but that’s not what made me like it. DeltaChat was a pragmatic, usable way to integrate encryption and email. It was so different from any other thing I’ve used, where usability is always at the bottom of the list (ever try to use openssl or GPG?).

Sure, there’s ways for me to get around the new changes - like, make another identity. But, I fear DeltaChat will keep going down the route of making it harder and harder to use regular email.

Again, I will caveat (and be embarrassed) if there still is a way to use regular email and chatmail with one identity, but I couldn’t find it. I can’t pick a primary relay to send a regular email. But, still, these are my fears what DeltaChat is becoming and not what I wanted. And yeah, maybe I need to make my own client, because DeltaChat has a different audience. That’s fine.

Sincerely, a disgruntled DeltaChat user

2

What do you mean by “identity” here? The email address or your cryptographic key? Why not have one profile (account) for using it for unencrypted messaging where your identity is the email address, and another profile (account) for using it with “relays” where your identity is your cryptographic identity?

3

One is a logistics reason. Coordinating making an account that I have access to at work and elsewhere is logistically a pain - for me. This may be foreign to a lot of people reading this, but if you’re working somewhere with physical security and restricted access, it’s hard to coordinate these things. I send the backup data to myself… but how was I supposed to get the key when now it’s QR codes to get that to myself - when if I knew the email, autocrypt would have done the key exchange.

But I can’t send an email in the clear to get the autocrypt negotiation if I’m trying to go through a chatmail if I want to send that backup data to another identity of mine.

There’s ways it could happen… but they’re now they’re workarounds.

The whole reason that one identity was attractive to me was that once I set it up, because it’s a logistical pain, each client knew the relays. So, if an email was sent, it would eventually to get to me. I was hoping that at some point the relay system would send messages to other clients when one of them couldn’t reach… which is exactly the problem I was solving with my work.

My regular email is firewalled, at work, but I want to be reachable in one place. Why can’t I be allowed to have my regular email be a relay? You’ll give me some security reason, but see, this is exactly what I’m talking about usability - it’s not considering the practical realities. As an outsider, how I see it is the only concern is security.

And two, why should I have to separate the accounts? Like, a real person is NOT this paranoid about encryption. If someone wants my information that badly, realistically they’re going to kidnap me or blackmail me or get someone else to give them my information or just ask me. I’m willing to sacrifice perfect security for usability. That’s my point.

For instance, autocrypt is a solution that worked… but oh god, it’s not perfect security - there was an unencrypted email that we sent. We can’t DO that. So, we have to have QR codes so it’s secure from the very first message… and I get I’m the wrong audience.

That’s fine. I’ll have to work around it until things don’t work anymore - because to me, you’re describing a work around, not a solution. It’s the “reddit non-answer” - “why would you do X, when Y is the only accepted solution.” Pragmatism requires compromising.

I’m not trying to insult the DeltaChat developers, I think you’ve created something really neat, but from my perspective it keeps getting worse and not what I thought I was getting.

4

This is not about paranoia, it’s about the fact that if you have a Delta Chat profile where the only “relay” is your email that you use to send unencrypted stuff then you don’t need the “select primary relay” feature.
I’m not getting it - you are fine with having multiple relays but not fine with having multiple Delta Chat profiles? Maybe it’s just me but I’m not understanding what you want to achieve and why having two profiles is not the solution.

5

Mixed use allows the profile of your choice to communicate with each and every person in the world. This is the second best selling point of DeltaChat (at least from my point of view).

The first selling point of DeltaChat is the possibility of choosing whatever email account you wish as your transport. And unless you are planning to remove this, the changes in 2.62 really brake many usage scenarios for very little gain.

I’d like to clarify that I embraced the changes that came with version 2. I believe the benefits surpass the inconveniences.

Version 2.62 removes freedom from users. The same result could have been achieved by adding an “allow for sending” setting to each transport, enabled by default.

For example, suppose you are in a network (country?) that restricts sending to some particular IMAP servers. You can use DC because you can add accounts that works with those servers and that is great. Imagine now that you move to another network where those IMAP servers are not accessible: In the current scenario you are forced to switch profiles. That is confusing for your not so expert contacts. Also, when you come back to the original network, trying to send though other not authorized transports may be detected and problematic.

A different situation is when you have some classic email transport to surpass the 20-day storage but the account has recipients/time restrictions for sending. You can’t tell DC not to send with those accounts. This is also the case when the classic account forbids sending when connecting through a proxy.

And finally, if you want to send a message to an uninitiated human being, you are forced to create a new profile and find another classic account for it. This makes it really difficult to lure people to the light of DeltaChat.

Also, after a few tests (at least in my case), DC keeps trying with the previously set sending relay (set with previous DC version). In case of error the message is not sent and nothing can be done about it. The automatic switching is not happening.

In any case, assuming the automation works, it is very inefficient to keep trying with transports that can’t send in the current context (as described in the previous examples).

Automation is probably the best for most regular users, but those users do not bring new people to use DC. I think the best for us (DC evangelists) and regular users could be to have the possibility to enable more than one transport for sending with all enabled by default. Ideally, it would also be great to be able to set a different proxy for each transport, but I don’t think that will happen.

What do you think about this?

A regular user will never enter the transports menu and will probably never notice the “allow for sending” setting in each transport…

6

I think maybe I’m not explaining the part that’s important to me very well.

I’m not trying to have two different ways of accomplishing the same thing. What I want is one Delta Chat profile/identity, where the profile can use different transports depending on what network I’m on.

To me, the profile is me and my conversations. The email account or chatmail relay is just how that profile gets messages in and out.

For example, at work my normal email is firewalled, but chatmail works. I understand that this means I can’t receive my normal email messages while I’m at work. I’m not expecting the current setup to magically make those messages available there.

What I was hoping for, though, was that eventually Delta Chat could support some kind of message replication between clients, so that a message that one client can see but another client can’t reach yet could eventually become available on the other client. Then I could still have one identity and one set of conversations, even though the available transports aren’t the same everywhere.

That’s why making two profiles doesn’t feel equivalent to me. I understand why you would think they should be separate, and technically that works around the connectivity problem. I just liked that they didn’t have to be separate.

If I make two profiles, I’ve created two separate inboxes/identities that I have to keep track of. If someone messages me on one, I have to be looking at that profile to see it. And I have to keep track of which people/conversations are associated with which profile.

That’s what I mean when I call the second profile a workaround. I understand that it can technically solve the connectivity problem, but it moves the problem from the transport layer onto me as the user.

The thing I liked about having multiple relays on one identity was that I didn’t have to think about any of this. I set up my identity once, and the clients knew the ways it could be reached. Which transport was available could change without me having to maintain separate identities and separate conversation lists.

I think the simplest way I can explain what I’m trying to get at is: I’m one person, and I want to see my messages in one place. The single identity captures that for me. I want the transports to support that identity, rather than having the identity change depending on which transport happens to be available.

And I think that’s why I’m having a hard time with the suggestion to just use two profiles. I understand the reasoning behind it; I just liked that Delta Chat’s model seemed to leave open the possibility of eventually solving the problem at the transport/client level instead of requiring me to split myself into two profiles.

It feels like the direction is going the opposite way from what I was hoping for.

7

The solution I purposed addresses your problem and many others, while allowing for automation for the average user.

I don’t think message synchronization between clients is going to happen any time soon, as well as being able to choose a different proxy for each transport.

Let’s wait for what the developers think about this…

8

feels like a case of XKCD 1172

9

I’m one of the Chatmail/Core maintainers, but answering from my personal POV here:

~Five years of experience with building Delta Chat and Chatmail showed that that trying to support two separate use cases (being a chat messenger, i.e. Delta-to-Delta-communication, and being an email client) meant being kind of bad at both of them. So, we want to concentrate our limited resources on one use case.

I would love if someone forks Delta Chat, and makes a version of it that focuses on being an email client that shows the emails in chats and supports both unencrypted emails as well as easy-to-use encryption!

If you actually do this, I’m happy to answer questions that may arise.

Using any email server as the transport for your encrypted Delta Chat messages will stay, but the email account should be used by Delta Chat only, i.e. you shouldn’t mix DC and a regular MUA on the same email inbox.

10

I would like this as well, but for a different use case - I an the relay sysop. I want to send my messages to my friends, also using my relay, primarily through my relay where I provide quality assurances. The second relay in our configurations is for HA/DR purposes, I do not want nor had intended for all relays to be treated as equals. I agree DC 2.62.0 takes away a freedom-of-choice I had previously wanted and used by designating my own relay as the sender.

11

Thanks! I am really happy to hear that.

Have you considered that probing an SMTP server of a classic mail transport may get your account blocked or worse, depending on your provider or political regime? Wouldn’t this hinder the support for classic email as transport?

Also a failed message in 2.62 Android was not tried over the other relays. Going back to 2.59.1 the same sending relay remained selected and by manually changing to another the message went through.

13

BTW, there is a more detailed answer in another thread: Chatmail interoperability with regular email accounts - #4 by r10s

That may be a bug, I’ll message you in private