Under the hood, we are using IETF Internet Messaging specifications commonly tagged as "email". Sounds old, right? Actually there is a lot of new stuff going on! For example, #chatmail apps now fully support:
- RFC9788 ("Header Protection") to achieve minimal metadata
- RFC9580 ("OpenPGP") to use modern cryptography
By comparison, "Messaging Layer Security (MLS)" has an older numbered RFC9420 (and doesn't have mass-usable app releases).
Maybe time to revisit old/new assumptions? :)
@delta hi! My friends trying to switch to DC, but most of the chatmail servers are blocked.
So I’m still wondering if you have any plans for message transit/proxy via non-trusted regular email servers. Email traffic itself is not blocked and some domestic email servers are reachable even if strict allow lists are in effect. Obviously traffic itself will be visible to email provider, but if it just goes tor-likesh to random chatmail servers without disclosing actual recipient mailbox will give them option to use DC without trying to find working VPN
@ben @delta no, I’m not talking about classic mode, because you will be addressed by your mailbox, which comes with a lot of issues by itself in said environment. I’m talking about using allowlisted servers as pure transit not exchange
I’m talking about harsh very real environment. To re-iterate: there are time and places where ALL traffic is blocked. Not some, all of it. Only tiny list of allowed destination sometime is reachable. And in some places this list includes domestic email services.
Just to put into context: last week people were developing tunnels via videoconferencing. Back then it was dumb tunneling via WebRTC, but services are slowly adapting to this. So I heard people are talking about hiding traffic in video stream itself. This is how bad it is and how quickly this environment evolves. This is not universal and heavily depends on specific region, but there are places where cellular communication are not available for weeks.
“host you own chatmail” is not an option because it will be blocked in a week. It’s pure speculation, but very specific set of constraints might make chatmail vulnerable to active probing. I’m not sure that even a recent update with multipath routing will make things better, because it doesn’t matter if there are no servers reachable
I have to deal with this bullshit on a daily basis to keep connected to people out there, so sorry if I sound harsh
@ben @delta oh, I think I did a bad job explaining what I mean:
The idea is that you have 2 mailboxes: one [email protected] in allow-listed provider and second one outside the country, i.e [email protected] or other major email provider. Usually there is no restrictions for email traffic outside the country to this destinations. While you can’t access gmail directly, you emails still cab.
So your traffic flows [email protected] → [email protected] → chatmail sever and routed back chatmail → [email protected] → [email protected]
So there is no direct exchange between chatmail servers and allowlisted servers inside the country. Mass email scanning is not here yet, but transit level traffic filtering is slowly being rolled out
Also it does not expose your bare email address as contact address for DC
@ben @delta but to be fair, deltachat is not a long term solution and was built for quite diffirent circumstances. Even in mentioned flow DC traffic itself is very obvious and can be cheaply filtered with just a few rules on the email server side
Steganography could help, but even then, hiding messages in memes can be filtered by trivial throttling.
Sadly, there is very little technology built for being able to tunnel seemingly legitimate traffic over very weird lossy transports. I wasn’t expecting that tunneling traffic by encoding it in videostream would be a viable option in real life and not just hypothetical scenario from cryptopunk sci-fi
bjoern
Delta Chat
Ⓥ Gregory Trolliet Ⓐ🔻 🇵🇸
yopp
Benjamin Kwiecień 🇵🇸
Andrea Lattmann