It won't take off with email interoperability issues

1

Hey everyone!

I glad the project is still alive, but I tried it once again and I’m afraid it will die. Before today I attempted to use it in 2022, and the account I set up (Fastmail with my own domain) has been checking IMAP periodically since then.

I saw DC as a tool for “clever misuse” — something like using GitHub as a cloud storage or IP-over-DNS to get around the lockdown through the smallest loophole — but now it suggests me to register a separate account on a special server that support distinctive non-email features. Also, being an XMPP user previously, the coolest thing about DC for me was that I can use the same address for email and IM. Now it’s strongly discouraged, and that’s not cool.

In my understanding, DC is an IM-over-email thing, and the only way it can survive is to actually support communication between DC and non-DC users. Of course, with support for unencrypted email — after all, in most cases it’s better to have a cleartext transmission channel than to have none at all. I ran a few manual tests, and unfortunately, nothing worked out.

What did I test?

DC (Fastmail) → Gmail: a message is readable (however the sender isn’t the right address), but reply isn’t available in DC

DC (nine.testrun.org) → DC (Fastmail): a contact is added, the client got stuck on “establishing connection”
DC (Fastmail) → DC (nine.testrun.org): a message is sent with To: "hidden-recipients": ;

DC (e2e.sus.fr) → DC (Fastmail): a contact is added, the client got stuck on “establishing connection”
DC (Fastmail) → DC (e2e.sus.fr): a message is with To: "hidden-recipients": ;

That means, DC is basically more broken for a user who knows it as IM-over-email thing than it was 4 years ago. For users who are new to it, this is yet another messenger with even fewer users than Matrix.

2

This is not a bug, the real To is protected with RFC 9788: Header Protection for Cryptographically Protected Email
It is inside the encrypted part. The real list of the recipients that the server uses is in the RCPT TO SMTP commands which are not part of the message. This is similar to how Bcc works.

It is not clear what you tested in each case. E.g. with “DC (Fastmail) → Gmail” I assume you typed in the email address of the recipient? I don’t understand what “but reply isn’t available in DC” means, you mean you sent a reply from Gmail to Fastmail and it is not displayed? This is because of the “Show classic emails” setting likely, you can set it to “All” for Fastmail profile and then reply from Gmail should be received.

As for getting stuck on “establishing connection”, is any message delivered to Fastmail? This sounds like spam filter problem.

3

Sans different providers, the same tests Worked For Me™. Have you checked the spam folder? That’s where the problem always is.

Speaking of which. Can’t DC client just check for Spam / Junk / Спам / same-for-different-languages folder?