this post was submitted on 17 Jul 2024
57 points (95.2% liked)
Programming
17028 readers
244 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
They will have access to metadata - otherwise they wouldn't be able to work as email service. That's sufficient to implement those protocols.
The client then would have to bring their own crypto, and you'd probably want the SMTP server to reject mails if delivered unencrypted (though their FAQ says you can send unencrypted mails).
The reason they claim they can't is probably trying to keep full control over what users are doing, in which case I agree - fuck them, don't use services like that.
Receiving email, the service provider has full access to the metadata agreed. The main difference between proton and tuta is what data is kept encrypted at rest.
Proton does not encrypt the metadata, from, too, subject
Tuta does encrypt all of that metadata at rest
The clients are open source, you can do anything you want, you just have to implement it. I don't know where the hate is coming from. Tuta is unique being the only email provider that encrypts all the data at rest, and I want to give them a lot of love for that, I don't understand the hate at all
Kneejerking.
At the time of sending the mail I need the metadata - so offering a SMTP server implementation which keeps this in memory while forwarding is not hard. You'd lose a persistent spool in case of delivery errors - but we've been doing relays that keep the client connection open while trying to deliver the mail to relay errors directly to the client already 30 years ago, so that also isn't an excuse.
For IMAP - if you don't do serverside searching or similar it'll work with fully encrypted mails.