- cross-posted to:
- hackernews@derp.foo
- cross-posted to:
- hackernews@derp.foo
I’ve been seeing comments about mailing lists. They usually want plaint text emails like these.
You must log in or # to comment.
Also, when building services that are expected to send HTML email, make sure to generate a plain text version of the content and put it in the appropriate multipart section of the message. Otherwise, people reading in plain text won’t see it unless they’re willing to jump through hoops to do so (and there’s a good chance they’ll toss it in the trash instead).
Bonus points if the plain text part is formatted well.
Tuta
Notice: Use of IMAP and SMTP, open standards for email clients, is not possible with Tuta. This is not acceptable behavior for an email provider and use of Tuta is strongly recommended against for this reason. Tuta’s stated reasons for not supporting these protocols are lies and you would be well served by closing your account there.
Well that’s a strong opinion. And yes, 100%, IMAP is not a end to end encrypted protocol so how can they offer it when the server can’t read the data?
To be fair, these folks are advocating for plain text emails, not surprising they are against encrypted emails.
How does that even relate?
Mail encryption has nothing to do with how the mail is formatted (html vs plain text). And the client protocol for fetching the mail from the server also has nothing to do with that.
I read it as sarcasm
It was meant in jest, I should have contrasted plain text / cipher text to be more clear. Though it’s a similar kind of extenstion to email technology that they are advocating against.
These folks want to read their emails in their terminal email client, and for you to cater to their limitations. If you use tuta and send them an email, tuta just emails them a link to view the message on tuta’s webapp. I’d say this anti-HTML group aren’t fans of that.
Not to argue semantics, but I would consider encryption in general is a change in message formatting. The client needs to change how the bytes are interpreted. It adds complexity, and clients may not support it, their exact arguments against HTML.
Unrelated?
They just need to tunnel the data and let the client decrypt it. Basically what Proton does with their bridge app. And also basically what Tuta’s client does.
Fair enough. The clients are open source, nothing’s preventing anybody from making a gateway if that’s the real desire.
Frankly, I can’t really wrap my head around what services like Proton and Tuta are trying to do, so in turn I can’t get a clear idea of the threat model.
They’re basically running encrypted file storage servers that are used to store email messages, forcing their users to use proprietary protocols to access them. But sending and receiving email messages implies messages passing through other, non-encrypted servers.
The only scenario where they’d approach anything resembling security is if both the recipient and sender are on the same service. Not even passing messages between two such services (Tuta & Proton) is really secure. And since the vast majority of the average user’s messages are exchanged with other servers it means that the vast majority of their messages have a copy in clear on at least one other server out there, and have passed through clear relays that are also not encrypted at rest, making more potential copies available.
So what exactly is solved by having one copy encrypted if there are non-encrypted copies readily available?
Data at rest. I totally agree for normal email usage patterns email is unencrypted. But most people have a massive multi-year backlog of archived messages. There’s no reason that can’t be encrypted.
The benefit tuta provides is the entire backlog is encrypted on disk, client side encrypted. That means you’re unencrypted exposure is only live messages, and not your backlog. It reduces your risk window.
It’s good data hygiene to keep all of your data at rest encrypted.
For the scenario where email is sent between two tuta users, The message is encrypted with the other users key and the service never sees the unencrypted message. But as you indicated that is a vanishingly small percentage of the population. And nowadays you would just use signal or simple x to message somebody securely directly. So email is definitely for the legacy world
This is equivalent to having full disc encryption, your email client always downloading all the email to disk and deleting it from the server. Your email archive is encrypted at rest. The difference here is it’s a cloud service provider, so you can have different clients on different devices all synchronized.
- The email stored on T/P is not end-to-end encrypted. T/P have access to it without going through you. Why? Because that’s how email works. When receiving mail, their server is contacted by another (non-encrypted) server who says “I have a message for you, accept it and store it”. And they have to be able to do that 24/7 without involving you. Same for sending, they have to take your message and store it for several days until they can send it out in clear and another (non-encrypted) server has confirmed it has accepted it. Any pretense that any of this is secure is just security theater.
- You cannot have multiple clients on multiple devices, because they’ve replaced standard protocols (IMAP and SMTP) with their proprietary wrappers to maintain the pretense. So you can only use their apps (insofar as they’re available for your devices), or their webmail, that know how to speak the proprietary protocols. This locks you into their service.
You can’t do secure email. You really can’t, sorry. Point (1) above is a game-ending design flaw that makes it impossible, and (2) is just lock-in and hoops to jump through without really adding anything of value.
You could do remote encrypted storage of your email archive but only if you give up the notion that you can also allow that storage server to send and receive messages for you. If they have access then it can be subverted and the whole proposition is worthless.
The way to achieve such storage is by using a remote file storage service reflected locally as a virtual filesystem, preferably with the encryption layer controlled by your device not their service, and use it to store messages managed by your local email client. Your local email client would then use IMAP and SMTP connections to unrelated email servers to send/receive messages. But you’d have to replicate this stack on every device, which is impractical.
The better approach is to self-host your mail archive, with a webmail client on top connected to a SMTP service, and have a local tool on the server that pulls emails from a POP3 server and deletes them afterward. And you can encrypt the disk there if you want, and use whatever you want to access your archive (regular email clients or webmail).
I agree with 1.
I disagree with 2. Tuta works on multiple devices at the same time. Empirically
A. My point about having all data at rest encrypted still stands.
Depending on your threat model, having properties one, and a are sufficient. All of your historic data encrypted at rest has value for people.
I also agree with your statement about keeping all of your mail history local on an encrypted drive. That would also work. But you lose the cloud aspect of having a completely client-side encrypted service provider
Clearly tuta doesn’t fit your threat/usage model. But it does work and does provide a valuable service/trade off for people who want cloud based client side encryption for data at rest.
Just because Tuta and Proton don’t rub you the right way doesn’t mean they’re not valid options, stop FUDing around.
You can’t do secure email. You really can’t, sorry
PGP would like a word.
Which part do you think it’s FUD, and why?
PGP is not particularly related to email. It’s also used to encrypt files, partitions etc.
You can use public key cryptography with any system, because you simply encrypt the content and then send it through the normal unencrypted system.
But PGP does nothing for the headers and nothing for the fact messages are still waiting around on various servers. Also PGP on its own is very impractical due to the need to get keys for every recipient – but even if there were a generalized system of public key autodiscovery (over DNS) it still wouldn’t fix the problems with IMAP/POP3/SMTP.
Each of these things holds a piece of the puzzle – including what Proton & Tuta are doing – but these pieces on their own are useless. We need all of them to come together.
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
I don’t know where the hate is coming from.
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.
