ProtonMail Rewrites Your Emails
jfloren.net
jfloren.net
That said, Proton's response to this issue is joke.
If they cannot handle basic things like PGP correctly, how should I trust other part of their software. Especially they are a "Privacy-first" company.
"Privacy" becomes a marketing term nowadays.
It’s a user benefit. By definition that means it’s a marketing term. That is not mutually exclusive with being a general concept.
download free full mp3 album now
(no download just spam, not free, not mp3, not the album you wanted and not now)
You can genuinely support privacy and still have features or user cases that don't work. This feature does nothing to weaken privacy.
But for PGP? You should treat it seriously, considering your target customers.
> though we could of course add that in the future.
> It’s absurd that there’s no way to disable this, no option to tell Proton “if you see a multipart/signed or multipart/encrypted message, just leave it the hell alone.”
which, as I said in my response, I disagree with the first half of that. Our goal is to (automatically) encrypt messages whenever possible, and leaving multipart/signed messages alone doesn't reach that goal. So I proposed two different solutions to what OP wants, one of which is already built into Proton Bridge, and one which we could add in the future (but which would be more effort than the one OP proposes).
Bridge is a proxy which hosts a local IMAP and SMTP server, and takes "normal" unencrypted and unsigned messages from desktop MUAs like Thunderbird, signs and encrypts them, and then sends them out. Note that this requires changing the MIME message somehow.
OP writes:
> Everything was great until I decided the other day that I’d also like to do PGP signing on my outgoing messages.
The "intended" way to do this is enable the setting in Proton Mail that says "Sign external messages" :) That way, Bridge will sign them for you. (Internal messages are always signed.)
> Tough luck, bucko, we’re the SECURE email company, you’ll upload your private key to our servers and you’ll like it!
FWIW, private keys are stored encrypted on the server, we don't have access to them.
But yes, the entire goal of Proton is to handle PGP for you, without having to set up PGP encryption and signing manually on all of your devices. I know that the HN audience is fully capable of doing so, but our goal is to make it easier for everyone else :)
> It’s absurd that there’s no way to disable this, no option to tell Proton “if you see a multipart/signed or multipart/encrypted message, just leave it the hell alone.”
IMO, if we see a multipart/signed message, we should still encrypt it whenever possible, not leave it alone. But note that normally in OpenPGP, signing and encrypting is a single operation. It's possible in PGP/MIME to sign a message first and then encrypt it, but we don't support sending that way at the moment, though we could of course add that in the future. But in any case, that's the reason we currently recommend signing using Bridge rather than manually using gpg or similar.
PS: the lack of threading support in your mobile apps is embarrassing, it's been like this for years. No I will never use your web client. Stop trying.
PS: yes, this is being worked on
I don't know why you think this is some sort of gotcha. Other than you think having standards is too entitled.
I'm always bothered by statements like this because it appears to be skimming over if the provider can perform cryptography with the key. My understanding is that those keys are only decrypted in the users apps/web browser, not server-side. Is that right?
You need to trust that the provider doesn't perform additional operations along side legitimate user triggered actions, which I believe PM handles.
"Don't have access" is a little too strongly worded IMNHO.
(I understand the reasoning - and I don't necessarily think it's bad - I just think it overpromises a bit)
Although they are open-source and can be scrutinized by anybody, it does not means that's what is run on the server side.
(Just say they have the capability; no accusation)
So at the end of the day, the question is whether you trust Proton or not. Encryption might not help in that case.
On mobile, to do such an attack we'd have to collaborate with Apple or Google to do it, which IMHO seems infeasible - but nevertheless also there a "Binary Transparency" feature of sorts might be valuable.
Thank you for moving the web forward. Proton mail does a lot of things well, and there's more to do. I was auditing DANE support and PM was one of the few I found with support.
> FWIW, private keys are stored encrypted on the server, we don't have access to them.
This is frankly fucking ridiculous. Users (including me) have been requesting a change to this for years. It's thanks to this bullshit that ProtonMail's key feature for me is just 'isn't Google'.
Brilliant quote!
https://github.com/ProtonMail/proton-bridge/issues/26#issuec...
I'm actually more shocked knowing that they drop plain text if there is a mime-encoded part (e.g. HTML). Just verified that all mails imported from GMail and all newer mails I received in PM only have the HTML part now, while GMail shows both HTML and plain text parts in message source. Great, now if I want to use a text-only client to read those mails in the future, I won't be able to.
Now I honestly wonder, how did they think this is something okay to mess up? Is there just no usable email hosting service for someone that want their mails not touched and also stored securely? Like, this is not even going to save storage space for PM - I'm paying for my storage.
I'm speculating but this has the smell of enshittification. Somehow this is saving them money while making the product worse, and they're hoping not enough customers notice to matter.
I'm happy to see this called out. Don't explain to me that I'm holding it wrong. At minimum admit that a shortcoming on your end prevents me doing what I want and think about if or how it's possible to change that.
Non-opinionated ... Opinionated ... My Way or the Highway
That's what opinionated means, yes.
For example
- being able to change an encryption protocol is "configurable"
- Setting the default to be unencrypted so that the user chooses it is "unopinionated defaults".
- Setting the most modern encryption protocol by default is "opinionated defaults"
To your point, setting the default to be unencrypted reflects the opinion "this layer of the stack shouldn't be responsible for handling encryption unless the user has no other choice".
What is a good example where software is described by its maker as opinionated and where it results in "their way or the highway"?
I'm asking because all software need defaults and no software can do anything that all users would want, so the software maker has to make choices of what they offer (i.e. reflecting the maker's opinion).
By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.
Black makes code review faster by producing the smallest diffs possible. Blackened code looks the same regardless of the project you’re reading.
I call Pettier a compromise tool, noone is happy noone is too mad when you force it on checkin etc
I know that you can go for descriptive classnames and "@apply", but I was still miffed about a change like this in an already existing tool, with a lot of community pushback and no compromise in sight.
(Here's a relevant discussion, but keep in mind that multi-line-classes worked at some point and now just don't: https://github.com/tailwindlabs/tailwindcss/discussions/7763)
So for prettier, it wasn't just "format your code our way or else" - which is a good approach for a formatter, see also gofmt - it was "your current set up doesn't work anymore, tough luck".
Out of curiosity, what did you find to be something unchangeable?
No big deal but a bit annoying to have two ways of doing it.
I’m 100% happy with Prettier. The trick is to not care too much about how the code looks. Consistent style trumps any choice for me.
1. Changing a preference with a GUI editor. Only a small percentage of all defaults can be changed this way.
2. Changing a preference with "defaults write..." and hoping the change will stick the next time you upgrade the OS.
3. Change the default for one usage but it will revert the next time you do that operation. Many examples wrt how Spotlight searches work in the Finder.
4. You can't change the default at all. Example: Themes. Last time I checked there were two, and nobody can make others.
This is a valid business strategy in my experience especially for B2B enterprise SaaS, where you know your product works very well if used to solve a specific set of problems using your SaaS tool in a way that you, the vendor, prescribe.
At our company we tell prospective customers that if they don’t like the workflows we demo to them, they shouldn’t buy our product because the customers who like our product are the ones who use this workflow, and people who don’t like our product use strange workflows we don’t recommend.
I think the problem is when the customer isn’t made aware of the opinionated workflows/features/etc until after the fact.
Where are they doing that?
Every time one of these threads come up I like to share my experience attempting to use protonmail for my business:
Protonmail charged us for every email account, whether or not they were active. When an employee left the company, we would disable their email address but we wanted to keep records of their email history. Of course, exporting email from protonmail is difficult to the point where you need an engineer to do it.
So I emailed protonmail saying "hey, do you think you could add a feature where email addresses can, say, be permanently disabled and then we don't pay for them any more?" They replied with a typical protonmail brush-off.
I was already frustrated with the service because their search is worse than a simple substring search and after a few years of using an email provider for professional use you sometimes have to find old conversations. So I canceled the account and closed the privacy.com card.
A year later I noticed that the (luckily closed) card was still being charged monthly, so I tried to log into the old account to see if there was a problem and the password (stored in a password manager) didn't work. I emailed them to let them know there was likely a bug and their support agent argued back and forth with me about it before finally demanding my credit card information (which I didn't have, the card was closed a year ago) to stop billing me. I just stopped responding at that point.
In my mind the fact that they are so hostile to their users is a big red flag. I think it's bad practice to trust people who indignantly dismiss reasonable questions from paying customers with private information.
IMHO, Proton is meant to keep conversations completely private between recipients. I’m more surprised that you can still access a former employee’s email at all.
What about now, did you tried to use Import-Export app for ProtonMail, did you try to use search now?
Oh my God, i thought it was just me! I've had multiple emails to doctors and financial advisors get cut off this way when i clearly remember typing the whole thing out and i was honestly wondering if all the medications I'm on (for cancer) were causing me to have brief hallucinations while sending emails or something like that.
I've had this bug hit me at times that matter. What if my recipient ignored my empty mail instead of notifying me?
IMHO this is really a "drop what you're doing and fix it" type of bug, even if it affects only a small portion of all users because it's such a critical high-impact bug, and any fix really shouldn't have to involve a complete rewrite.
these are application development regressions and bugs. maybe it is just too. uninteresting for Proton to build a great product?
I was hoping their big song and dance over privacy would lead the likes of Gmail, Outlook, etc to adopt native PGP too.
Wishful thinking. :')
https://support.google.com/a/answer/10741897
https://security.googleblog.com/2023/06/gmail-client-side-en...
1. User writes recipient address.
2. Server checks the address and asks mail host for encryption key.
3. Mail host sends encryption key
4. User continues writing email.
Similar to how UDP https works.
I'd call it Wave
For example...
1. what happens when you send an encrypted email, and the recipient forwards it?
2. What happens when the recipient replies? Will your original email be included encrypted, or decrypted? Most likely the latter, meaning the same cleartext is now present in two messages.
3. What happens when you email more than one person? What entity handles the encryption for each recipient?
3.a. what if only some of your recipients support encryption? What's the point of encrypting if you're sending some in the clear anyhow?
4. What happens when you email a mailing list, with unknown participants?...
5. What should be canonically encrypted? Just the message body? What about the subject, which is a header of the email? What about any other headers?
5.a. Oh you just want it signed? Again, what is canonically getting signed? How does that survive the many transformations the text receives in a conversation?
But when it comes to true security, 90%, or even 99%, is so far from "good enough" as to be pointless.
2) It's decrypted and re-encrypted with your public key.
3) Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key.
3a) It gets sent unencrypted. Frontend client warns the sender.
4) Separate emails get sent out with the receivers' public keys.
5) Everything except the receiver's single email address. Optionally, everything except the receiver's and sender's email address for spam filtering.
5a) Everything.
Not sure why any of this would prevent Apple, Gmail, and Office365 from implementing a transparent PGP encryption layer. If just those three entities worked this out, the vast, vast majority of emails in the western world would be encrypted effectively. Just because some emails wouldn't be well-encrypted doesn't change that this would be a huge benefit for privacy.
True story, I was an expert witness on a case once where I showed how the other guys were submitting forged emails into evidence -- by using DKIM signatures/hashes. That was probably some of the most fun I've ever had.
I agree, most people have no idea headers exist (beyond the short headers), but I expect lawyers and law enforcement to know better. Handling digital evidence is not new and at technology's timescale email is ancient.
And, on the other hand, either party can demand the other prove via live witness that the evidence is authentic, reliable and useful. If the witness isnt credible, the document can be excluded.
The DKIM signer selects a list of headers (h=) to be signed, but the body is always implicitly included (and thus not listed). I was confused because I thought there needed to be a flag to include it, and had never seen such from Gmail or others.
For anyone else that's curious: https://rfc-editor.org/rfc/rfc6376#section-3.7
(2) and (3) have similar problems.
(4) is a TOFU-ish scheme, meaning that it’s trivial for an adversary on the wire to replace the keys.
(5) doesn’t work, full stop. E-mail wasn’t designed with encrypted headers in mind. Trying to shoehorn these things together leads to all kinds of weird misplaced user assumptions around what is signed or not, etc.
2-3) What? Not seeing the problem here? Do you also think encrypted emails need to prevent someone taking a photo of their screen with their phone and sending the photo to someone else? If we can't prevent screenshots and copy/paste of decrypted content, we just shouldn't encrypt anything? What is the logic here?
4) It would also be signed by DKIM and/or the sender's private key, so your proposed MITM attack is not trivial at all. Are you aware of DKIM and PGP signing? You're trying to establish authority with "Email wasn’t designed with encrypted headers in mind [so you can't do it]" but that authority is undermined by not demonstrating understanding of modern email.
5) By the magic of controlling 90% of all end-user email in the western world, a consortium of Apple, Gmail and Office365 can do whatever they goddamned well please.
The right way to think about secure messaging and the compromises we should be willing to accept with it is avionics or radiotherapy software. Safety is practically the only thing that matters; if you can't provide it, there's no point in talking about how convenient, open, federated, or standardized it is.
At the end of the day, it's not a problem with the protocol.
1. It leaves metadata unprotected, which is usually just as valuable if not more so to investigators.
2. It leaves the subject unencrypted, which isn't even metadata --- it's message content.
3. It's effectively plaintext-by-default, which is why everybody who has ever used encrypted email has seen someone reply to an encrypted email with an unencrypted response that includes a transcript of the encrypted message.
4. It's based on long-term secrets and a cumbersome secret exchange process with no forward secrecy, something no other secure messenger does, because that configuration makes it just a matter of time before someone loses their key to an investigator and compromises the entire transcript --- put differently, the configuration of cryptography in secure email encourages investigators to simply record all encrypted messages in perpetuity, since they'll eventually get the one key that unlocks all of them.
These are disqualifying attributes that cryptography engineers would never accept in any modern design. The only reason they're tolerated in email is that almost everybody who uses encrypted email is doing so performatively, so that it simply doesn't matter when their counterparty replies in plaintext; it's a party foul, not the end of someone's life.
Part of this is, I think, that PGP came to popularity in the 1990s, during a time where the Internet was itself kind of a toy, and if you had a threat model, it probably involved someone you'd pissed off on EFNet IRC. If your only adversaries are script kids who are going to own you up for your mail spool, PGP does a great job!
The problem is, real-world adversaries, now that the Internet is as prolific and important as the telephone, don't play by IRC script kid rules. So much so that the plaintext content of a PGP'd email often doesn't even matter; they just need the source and destination email addresses and the time the mail was sent, to determine where to roll the van up to in order to beat the plaintext out of the recipient. Or, in the US case, 18 USC 1001 you into federal custody.
(You’ll note that even the simplest single sender case here assumes both key distribution and stable keys for users, neither of which PGP makes easy.)
The problem here is much simpler than that: you can’t encrypt to me if you don’t know my key. PGP doesn’t give you a sound way to get my key; every mechanism offered by the larger PGP ecosystem is either broken or disabled due to persistent abuse.
As others have pointed out: Signal (among others) does not have these problems. These problems occur because email was not meant to be encrypted (or signed); efforts to do so result in these kinds of convoluted “maybe secure, maybe not” models.
If we want people to be able to communicate privately, we should be encouraging them to use protocols that are meant that purpose.
I think it is secure, if, you don't install it via google and you actually do verify your contacts, but the NSA might relying on the fact that most people will not.
There is a reason nobody serious is trying to make email encryption work: secure messaging is already incredibly hard when you control every piece of the system; with email, you control absolutely nothing.
If B wants to forward it to C, they can strip off their own (B's) encryption, leaving A's (optional) private key signature, and send that to C.
C gets an email that contains a message from A which is (again, optionally) signed with A's private key, where if it was signed they can verify the A sent that part of the message. (Headers and newline mangling aside)
Or does that not work?
That could work. The PGP format is pretty modular. You could just strip out the content packet and signature packet. People don't do it because it would be confusing. Things like encrypted email list servers would be more likely to retain signatures.
Believe it or not, the possibility is actually something people have complained about in the past:
It's the only reasonable solution for proving your message X survived an intermediary. You have to do it regardless of message encryption.
Wouldn't this mean you lose the ability to show all recipients to all recipients? E.g. multiple To or Cc entries seem... probably not possible, since that would imply also sending to them? At that point it isn't "multiple recipients of an email", it's "multiple emails", and that's an only-sometimes-minor difference.
I definitely do not know email in enough detail to be sure though.
The challenge is key handling, especially the commonality of multidevice access to the mailbox. If you want to do this transparently, the only place you can store the key is... right next to the mailbox, so that anyone with access to the mailbox has access to the key. In other words, you're forced to limit the number of people who can read the message to anyone who has access to the mail server. But there's an easier way to limit the number of possible readers of a message to that set of people--just encrypt all the links involved in sending a message. And that was done about a decade or so ago, and happened pretty transparently.
Oh, and there's another problem. Encrypted emails break a lot of email features people like to rely on, such as spam filtering, server-side filters, or server-side search. (Assuming you don't just give up and give the server the keys.)
Encrypted email is a solution in search of a problem.
If the client can generate a unique public/private key pair for every sender/recipient combination, the key wouldn't need to be stored on any server, just ephemerally transmitted one time over TLS/SSL. But that would have the downside of if you lose all devices with the key, you can no longer read those emails. There's partial solutions for that, like your own collection of public keys could be encrypted with a passkey/passphrase and uploaded to the central server, but then if you lose your passphrase, Gmail still can't help you read past emails.
I agree that good key distribution is probably impossible.
I'm pretty sure an on-device LLM / statistical model could filter spam pretty darn well though.
> 3) Same thing that happens right now? Two separate emails get sent out each encrypted separately
I thought the email gets encrypted to multiple recipients (at PGP level), then MUA submits one single email with all those Cc and Bcc addresses. Then the SMTP service sends the same copy (that every recipient can decrypt) to every recipient's individual mail server (one message with per mailhost).
Not the way you've described it. I don't think anyone wants to trust SMTP server with their private keys (one single reason I do not use Protonmail).
> 4) Separate emails get sent out with the receivers' public keys.
I'm afraid this won't work. Mailing lists and encryption are quite incompatible. The whole point of a mailing list is that your client doesn't know or bother to know the recipients - and they can come and go. And if you specify every recipient it's just (3).
I'm not aware about any standard on how to implement email lists/archives/newsgroups with encryption (so one joining can read past messages) and forward secrecy (so kicking someone out ensures they can only read what they have already seen).
> 5a) Everything.
Problem with existing email infrastructure is that MTAs and MDAs do a lot of transformations on the headers part of "everything". So just saying "everything" isn't exactly informative. I think the best approach is to send a full MIME-encrypted message as an attachment in a minimal envelope (so just From/To/Subject). But then there's the infamous SPAM problem - and I'd really wish it would've worked, but sadly filtering solely based on sender-receiver pairs doesn't work in reality (or I wouldn't have to maintain and train rspamd on my servers).
I also do not claim that description to be 100% accurate - it's been a while since I've used PGP with email in practice, so I might misremember something. But to best of my awareness, this is how things are done today.
In my opinion, the main three problems with PGP today are: 1) lack of good no-frills "just works"-type tools; 2) issue with email metadata (at the very least, to/from addresses) being impossible to encrypt by design; and 3) abundance of haters (and they have a lot of right arguments, although many just boil down to the tooling issue and how it's easy to shoot everyone's legs with the current tools) who claim PGP should be buried (all together with email) - which is not exactly wrong.
Minor correction, but this is not true. The mail itself is encrypted symmetrically and only the key is encrypted with the receivers public key (this is true for all cases). In case of multiple receivers, the key is attached multiple times, encrypted with the PK of each receiver.
I'm not sure signal is what people who really care about their security should be using. Signal refuses to update its privacy policy to reflect the fact that for years now they've been permanently storing sensitive user data in the cloud. At this point I consider the fact that the very first sentence of their privacy policy has been a lie since 2020 to be a dead canary.
That, combined with their very unclear and misleading communications surrounding the data collection along with the dropping of highly popular features (the ability to handle unsecured SMS/MMS as well as secure communication) and inclusion of sketchy crypto features nobody asked for, makes me suspect even more that Signal may be telling people as loudly as they can to look for alternate solutions.
To anyone unaware that Signal was collecting and forever storing sensitive personal data in the cloud, that should tell you everything you need to know about how trustworthy it is.
For more info on this see:
https://community.signalusers.org/t/proper-secure-value-secu...
https://community.signalusers.org/t/dont-want-pin-dont-want-...
https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
I mostly agree. Although I don't know of something that can really replace email. Signal for example is not great for long form content, is kind of difficult to use on a desktop, is tied to your phone number, doesn't have a way to programmatically send messages (besides unsanctioned third party clients), and doesn't have a good way to group messages into conversations or threads. Most other e2e encrypted system have similar limitations.
Matrix is perhaps the most promising I've seen for replacing email. But the biggest problem is the network effect. It doesn't matter how good a system is if no one you know uses it.
This is not entirely true. I am not allowed to mention their names but there are a myriad of companies that use PGP in their software integrations. It is very heavily used for B2B in the financial world. That isn't to say that devs don't shake their fists in anger when trying to do QA testing on software/library matrix of tools that businesses use with PGP, there is plenty of that.
On a personal level I have taught many in my circle to use GPG with Thunderbird as it is really just a couple clicks to set it up and no effort to use it. Mozilla did a great job making that easy to use though I have no doubt that prior implementations had soured peoples experiences to the point of not wanting to try it again.
Some of your examples are real issues though. Mailing lists are a pseudo-problem in that it doesn't really make sense to use on a public distribution. I've seen it used on Usenet in that fashion long ago but adoption was low for that use case and people complained they could not read the messages not intended for them and that they should use email directly to the people it was intended for instead.
What happens when you email more than one person? What entity handles the encryption for each recipient?
The email client handles this.
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
[1] https://www.spiegel.de/international/germany/inside-the-nsa-...
Email is already encrypted in transit in most cases, and modern TLS has benefits over PGP. A big one is forward secrecy -- if you leak a TLS key, you haven't leaked all your past messages. But if you leak a key for an encryption scheme that doesn't support forward secrecy, you leak everything, as WikiLeaks found to their cost[0].
Mitigating this issue -- especially in the context of email -- is hard.
Also, PGP encrypts message data but not message metadata. Transport encryption still protects the per-message metadata, but adding PGP doesn't help.
Lastly, for this note at least, adding PGP into email in a way that is seamless will almost inevitably still involve some level of trust in your email provider. I'm all in favour of end-to-end encryption, but not at any cost. New protocols can have new capabilities, but for email my judgement is that your personal security boundary should include your email server. TLS for encryption in transit, DKIM for attestation of authenticity, and trust that the person you're communicating with has similar levels of trust with their mail host[1].
[0] https://www.spiegel.de/international/world/leak-at-wikileaks... - not that they necessarily used PGP, but the problem is the same.
[1] I recently sent emails with bank data in them to my solicitors, something that just seemed wrong on so many levels. But my mail server will[2] decline to send mail to their server without validated TLS, and however I give them the information it's going to end up in their O365 environment because that's how the company works. Submitting it over SMTP over TLS is no less secure than over HTTP over TLS.
[2] Because I have an advantage over many people who want email security, in that I run my own mail server and can configure it to require TLS for domains that I know support it. I'm not quite at the point of changing the default and only supporting plain text transport for explicitly-allowed domains, I need trust on first use and better observability of failures before I dare risk that -- and I'd use TLSA except that DNSSEC is annoying and so no-one else uses it.
What's the point of PGP if the e-mail company has the private key? Just security as the e-mail is being sent over the network + signature verification?
Sharing the private key is an odd way to keep secrets.
After testing and submitting a bug report, they were told that ProtonMail assumes attachments are encrypted with the user's address keys, and tries to decrypt them (the .gpg extension is stripped when recovering/recreating the original file name).
The biggest surprise was ProtonMail had suggested for my friend to import their private key corresponding to the public key for the attachments as a workaround. My friend did not agree to do this.
Use a low entropy things (I guess user's password would be not larger than 20 characters nowadays even using password managers) to encrypt a high entropy strings (PGP key).
Looks pretty weird to me.
The crypto refresh of the OpenPGP standard also has Argon2 built-in, exactly for this purpose, so that you don't have to do it manually. (RFC4880 also has "string-to-key" functions built-in but they are fairly weak so we don't rely solely on them.)
All of that being said, it's still important to choose a strong password or passphrase, of course; if you choose "123" then it's gonna be guessed instantly no matter how strong the hashing function is (well, unless it's so strong that even logging in becomes too expensive...) The main goal of password hashing functions is to tip the balance towards making it too expensive for an attacker to guess your password (as long as it has let's say "medium entropy") while still making it cheap to log in.
Proton makes it hard for open-source software developer to send patches and they don't care.
https://git-send-email.io/#step-2
Some quote from it.
> Be advised that Protonmail is generally known to be a pretty bad email host. They will munge up your outgoing emails and your patches may fail to apply when received by the other end. Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.
Glad that I jumped out the ship only after one week so I can get full refund lol
That sounds like a big fraction of the complexity of a self-hosted setup.
The wise man accepts that using a reputable forwarding host for sending is still valid self-hosting.
1. Account must be Approved and in good standing for at least 6 months
2. Account must be on a paid monthly plan for 6 consecutive months (or have purchase credits)
3. Account must have a lifetime sending volume of over 10,000 messages
https://postmarkapp.com/smtp-service
https://postmarkapp.com/support/article/1139-can-i-hide-or-d...
I've also got a 10 year old VPS whose IP presumably has a pretty good reputation by this point but I'm sure it's safest to use a dedicated service.
To quell your worries about a prospective service, you can try them without rushing to relying on it. Just point a mail client at their SMTP host and test for a while.
Google and Microsoft both were easy to deal with for me, and I even have a domain with a newer TLD (bar). DKIM+SPF is all it seems to take.
My host was also on Spamhaus' blacklist, but no one else's. I'm not sure it mattered, but they were nice enough to remove it and reply with a snippy email about how reluctant they were to do so. No surprise there, folks at Spamhaus would block their own mother.
Self-hosting email is just not that hard. It does take a bit of work, but that's why it's called DIY.
In short, I’m skeptical that, given the recurring cries of anguish I’ve seen here previously, your anecdata is universal.
I NEVER could send an email to a Microsoft email address and have it end up in the inbox. It was systematically flagged as spam. Microsoft's answer was to subscribe to some shitty, shady third party service to maybe, MAYBE change my reputation.
Before iCould I used to to this manually with my own mail
In the first iteration I had a catch all address, so I could invent any new email address and it would arrive to me. This was plagued by spam because any conceivable user @ my domain would be delivered to me.
In the second iteration I manually created aliases in the config file for my mail server when signing up for new things. This was additional overhead and annoying.
iCloud thanks to the integration into Safari and apps is so smooth with this. I just click the “hide my email” button and it generates a new unique email for the place I am filling in an email address.
I love it!
Do you have a source? I did find reports saying that it was limited to 100 during the beta but that the limit has since been lifted. People are claiming almost 350 addresses with no cap.
https://discussions.apple.com/thread/253893742
https://www.reddit.com/r/iOSBeta/comments/pbfg1t/hide_my_ema...
As is typical Apple fashion, it’s not documented anywhere that’s easy to find.
I agree Apple’s documentation is terrible, but if there is no limit (any more) then there would little reason to document that.
It seems that Apple has gotten better at online services, but MobileMe was not that long ago.
I guess the redback spiders do make nests in the server-racks sometimes.
I know it's swiss etc, but the honeypot tactic is not new. Protonmail could totally be infiltrated or controlled by an intelligence agency under the guise of "we offer you privacy".
I don't like conspiracy theories, but when it comes to escaping government electronic surveillance, Snowden made me realize that tinfoil hats are not so ridiculous.
Self hosting is a lost cause for e-mail unfortunately. You either get overrun by the amount of creatively formatted spam, or all of your e-mails are dropped despite having perfect SPF+DKIM+DMARC records and long-time owned domains.
Especially Microsoft has a horrible record of dropping e-mails everyone but big enough companies. Guess which software is the most popular choice in business e-mails: Microsoft Exhange. So no job applications, no communication with the various government offices, no business enquiries but loads and loads of spam that uses all possible codepoints in UTF.
I don't agree with it, but I could understand it. Because of the spam/blackist problem, every ISP I've worked for has ultimately either stopped providing email service or outsourced it.
You could title your mail to spamhaus: "You're today's lucky winner of $50!!!". That might get you on their good side.
Because Google and Microsoft have a monopoly on email.
Because of that, they don't have to play nice with anybody else and can make you jump through any arbitrary number of hoops since they hold most of the users.
Using them correctly is impractically difficult for most people.
Your key has to be as long as the sum total length of all of the messages you send along that communications channel, and it has to be completely random. Reusing any key material, or having a less-than-random key, breaks the security. Losing your place in the gigantic key you're using doesn't break security, but it makes the result impossible to decrypt unless you try every possible offset within the key to see which one gives a reasonable decryption.
Therefore, someone selling a "one-time pad" security system isn't really selling a one-time pad system at all, because people wouldn't buy an email encryption solution which required them to generate, distribute, and keep their place in an impractically large key.
It's possible to come up with scenarios where a one-time pad is a good solution. Spies have used them in the past and are likely using them now. But they're impractical and they're used as a buzzword by scammers.
I've always considered the OTP to be (not in some strict, rigorously correct sense) more like an ideal, theoretical/abstract cipher, much like how a Turing machine, generally unconcerned with a practical limit in tape size, is a sort of idealized, abstract computer.
"It is the Turing machine of encryption schemes"?
So you're only sending one email and not getting a reply?
Getting actually random (not pseudorandom) keys is very difficult.
Not reusing any key material ever is very difficult.
Exchanging the keys is difficult.
It’s not authenticated.
It’s just not useful in practice.
This postdates Proton Bridge, btw. But yes, probably we could do more to play nicely with it. But, when Bridge was created, using both Thunderbird and Proton to manage your keys was indeed not an expected or intended use case.
I guess this is a kind of "lite" vendor lockin if you want encrypted email for the masses.
If someone else has the key, it's not safe encryption. It's only as safe as the entities holding the keys. Do we know that they won't sell? Be forced? What happens if they get hacked?
Now it's not your security you have to monitor, but theirs. And you can't control theirs.
Anyway, your argument could be extended to any E2EE protocol...
And why we still use encryption? Because we usually trust the receiver and also the receiver can suffer from the leak of the message.
Never mind this pgp stuff that 1% of people find concerning, the current Android app is terrible at the basics. Half way through drafting a reply it closes your message and drops you in the inbox. Half the time it doesn't send, just boots your email into drafts where it sits forever, until you go and resend it. It also prematurely sends. The search is a random email finder now. It is hopeless.