I’ve been seeing comments about mailing lists. They usually want plaint text emails like these.
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.
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.
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?
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
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.
