Bring your own domain. I'm doing that and it works perfectly fine.
>they don't support open protocols including SMTP and IMAP
Use the bridge, that supports SMTP and IMAP just fine. I even managed to make it run on my server and basically abuse that for login via VPN (though I stopped because running the X server for that got annoying)
>the only way to export your emails is through a proprietary end-user application.
They're working on an import/export tool. In the meantime, use the IMAP bridge and any sane IMAP backup tool like I do.
>it's a scam
I wouldn't call it a scam, nobody is taking the money and running off with it or not giving you what they advertise. You do get encrypted mail, you do get a lot more security than most people with simple SMTP or IMAP, atleast the average user.
I think your description is a bit dishonest or atleast biased.
An email "provider" which doesn't support IMAP/SMTP is a scam, I didn't stutter.
The problem I see is not that they're not providing IMAP access, but that they're not providing any alternatives except for their product. Would the attitude be "here is a living API spec we currently use, subject to changes without warning, some endpoints not really documented (documentation PRs welcome), and some endpoints require paid account - but that's the best we can afford to provide" - I would've felt very differently about them.
In my opinion, it's the intent of true openness (even if there are no guarantees of stability or availability) is what matters, not the promise of eventual availability.
The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there.
If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen.
And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE.
The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have. Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway.
> release access to them
Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they?
Re: API access control, sure they do, but given that export is essentially calling 'GET message X' it's not as if we can restrict that to a subset of users.
Still, please consider providing API specifications and, ideally, free licensing of mobile applications' source code, if those won't negatively impact your business. I don't think they should.
I currently self-host but I'm open to the promise of email as a service. I think I can trust you with really encrypting my spam before it hits the storage, however, when evaluating any options I'm always considering "shall they be unable to provide something I'll need - what would be my options?". Full API availability (even if specs are in flux) and ability to hack on client software would mean I can achieve most things or hire someone to do so.
> but given that export is essentially calling 'GET message X' You can rate limit, I guess. That would be fair.
IMAP doesn't have a builtin way to deal with fully encrypted mail transmission including all headers and the GPG user experience is last I checked still subpar while additionally I'm fairly certain it doesn't handle fully encrypted mail.
Show me the international contract of email providers that says all email providers need to give you free IMAP/SMTP access or IMAP/SMTP access at all. Even google doesn't give you IMAP/SMTP out of the box, you have to dig through the settings to enable that. I don't need this other than occasional backup via their bridge. I don't want a desktop mail client, I#ve been running Rainloop for about a year until I switch to PM and it still annoyed me to no end because frankly IMAP sucks. It sucks majorly.
I am working on a fairly high scale email service. IMAP and POP are very resource intensive parts of our infrastructure.
2. We support IMAP/SMTP via the bridge (protonmail.com/bridge).
3. You can run the web client lcoally if ProtonMail itself is part of your threat model (github.com/ProtonMail/WebClient) and the rest of the clients (mobile and bridge) are working on open sourcing soon (mostly library/API version updates and documentation).
2. The proprietary bridge which only supports paid users and communicates with protonmail over a proprietary API. Give me a break.
3. "Open sourcing soon" isn't the same as "open source". Until you fulfill this promise it's not worth anything.
Also, while I have a Protonmail rep on the line, your mail server sends invalid Message-ID headers. I sent an email about this to [email protected], is that box monitored?
2. I don't see the issue with the API. Yes, we developed a separate API, because IMAP is several decades old, ridiculously inefficient, and wasn't designed with encryption in mind. The paid restriction may be lifted once we complete certain infrastructure, one major reason it's there that we were concerned about bandwidth.
3. I agree, and we're pushing as hard as we can for this. The latest mobile releases were the first ones on our latest API, so that will help. That said, the web client IS open source and anyone can use that locally and see exactly how the client-server interaction is handled in our API.
Yes, it's monitored. I was notified of this problem today and will look into it.
2. Your criticism of IMAP is awfully convenient when it allows you to design a platform which has vendor lock-in. IMAP might not be designed for encryption but people have been using it for PGP since the start and it's worked fine. Every other email provider does fine with the bandwidth. You're a terrible email provider if your bandwidth constraints don't even allow for IMAP. Having an API is fine, but it's no replacement for open and standard protocols.
3. Excellent. You'll still hear me criticize Protonmail for this until the promise is fulfilled, though. You don't need the software to be perfect to make it open source, you know.
>Yes, it's monitored. I was notified of this problem today and will look into it.
Thanks!
3. True, but part of open-sourcing is people building stuff to interface with the API and I don't want people building stuff on obsolete interfaces which might further delay dropping support for them.
3. People can reverse engineer it today and do the same thing. People have done this. You should just open it up already.
I don't see how this is false. Protonmail encrypts all user emails on the server, which can only be unlocked by the user's password. SMTP and IMAP would require transmitting the password to the server for decryption, which makes it prey to interception a la HushMail [0]. This is why they have the bridge, which runs its own IMAP server on the client and performs all authentication and decryption locally. Of course, the bridge isn't open source yet, so we can't be sure it isn't sniffing your password anyway, but that is orthogonal to the issue of supporting SMTP.
You can't verify that. As a rule of thumb, I think no one should trust a service provider to prevent themselves from doing something that benefits them and that their clients have no way of verifying that they're not doing.
If you want a server to only hold a file encrypted, don't provide it unencrypted and trust them to encrypt it. Encrypt it before giving it to them.
I must say, it's surprising to see a comment like yours here on HN. Where've you been?
I'm not using protonmail myself, but I'm sure they're not playing around with your data.
I'm not saying if it's good or not, but if they wouldn't abide, they'd be blocked from doing business in the EU.
They have a gdpr section on their webpage by the way.
Only because the EU said it does. I don't think any country, the US included, agreed to abide by their laws. No one has such a treaty that somehow includes the GDPR, as far as I know. I can only imagine their only way of enforcing it is by using their economic strength as leverage and threatening to place tariffs on some export or import or such.
> I'm not saying if it's good or not, but if they wouldn't abide, they'd be blocked from doing business in the EU.
Is that the plan? Put up a giant firewall around the whole EU, heuristically blocking foreign businesses that didn't comply?
As far as I know, they "require" world internet businesses to have a company branch physically in the EU, but how are they going to enforce that? They put fines on violations, but are they really planning to go to any nation in the world and enforce payment, citing law that's foreign to the citizens of that land? It seems silly, or unjust and scary if it turns out doable.
EDIT: I'm not necessarily against the GDPR. I think it's a move in the right direction with respect to respecting user data, but I am concerned with the fact that it tries to assign obligations worldwide without being a worldwide treaty. Not that I'm saying that it would be practical (or even a practical possibility) to have a worldwide treaty, but the way this is forced also seems like a move in the wrong direction with respect to world internet unity or international respect for national sovereignty.
We'll see for sure if and when it happens in practice. Though I suppose it won't, any company sizeable enough would lose too big a market this way. And I don't think they'll go after the smaller ones, at least for a while.
I don't like the methods they can try to enforce gdpr with, though I literally love the law itself.
This might be true but we dont know that. Offering fake security or selling people out for money are a recurring theme in markets for "private" services. You're expecting us to believe nobody on your team would take a payout from or be coerced by US LEO's or spooks. That's crazy. It's better to not put you in that position of us having to trust you like that.
To drive it home, Crypto AG in Switzerland backdoored stuff in the past, RSA was paid $30 million IIRC, and US ISP's got in $100 million range. The NSA was spending several hundred million a year with FBI helping on domestic coercion and CIA using tradecraft against foreign targets. Even Swiss have Onyx system now. There's a real, even if slim,chance people in the company get paid off, legally coerced, or hacked at some point in future. So, it's better if those of us that might be affected push for as little 3rd-party access to secrets and closed implementations as possible plus maximum rigour and review in design/implementation.
No, we're saying that we don't store the data partly so that such a scenario isn't available because historical data simply doesn't exist.
> It's better to not put you in that position of us having to trust you like that.
Look, we freely admit that you can't verify that we do this. If we are part of your threat model, you probably shouldn't rely on us doing it. If we aren't, then it's an additional layer of security relative to other providers who explicitly don't. If you receive unencrypted email, which is virtually everyone, those are your two options. Regardless of whether you believe us, we're still going to do it, because it's better for us and its better for users. There is no 'third way' that allows us or anyone else to receive unencrypted mail on your behalf and verifiably not save a copy. The only solution is to not have unencrypted mail, which is part of the reason we spent a year developing easy-to-use PGP interoperability.
They get steady stream of law enforcement inquiries. The best way for them to operate is to do just what they say. Encrypt incoming encrypted mail with users's public key and throw unencrypted mail away.
Why? There's nothing in the SMTP or IMAP specification that I'm aware of that requires that the email be in a decrypted form when stored in a mailbox. When a client fetches the email via IMAP, it can then be decrypted on the client side.
On the SMTP side, I could do the following over telnet
EHLO test
AUTH PLAIN XXXX
EHLO test
MAIL FROM: <my@address>
RCPT TO: <your@address>
DATA
<encrypted ascii armor text>
CRLF.CRLF
. SELECT Inbox
. FETCH 1 (BODY[])
I think in the end most computer users will sacrifice a bit of security for convenience. PGP signature and encryption for email will most likely never take off. Encrypted chat services like Signal seems to have done much better, likely because of how convenient they are to use.
This stores the private key as a password-encrypted file in a specified location on the IMAP server. It already has multiple interoperable implementations, by the looks of things.
As for the bridge, that is exactly what we'd like to do, as I've said before.
And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.
And like I've said before, what you'd like to do and what you are doing are different. Nothing stops you from open sourcing it today. Put in comments that the APIs you use are not officially supported if you must. Open source it! It should have been open source a year ago! Open source it!
Some people are just like that :)
Great product, Proton team, thanks.
My understanding of Protonmail's argument (not that I agree with it) is they encrypt the full message, including headers upon accepting it. Based on my understanding of IMAP, you're effectively looking at a new protocol once you do everything needed to decrypt headers on the client-side.
Other than the Received, Delivered-To and Return-Path headers added by the intermediate MTA servers, every other header in the original message could be encryped, along with the message body when it's delivered to the server (or appended via IMAP).
Your suggested method basically is no different from any other provider. You rely on the sender encrypting the message and header information is entirely unencrypted on the disk.
I would prefer to see them promote standards to extend PGP rather than invest that time in a new, proprietary system with no buy-in from the email-related-software development community. I can follow the logic but I can also see their eyes lighting up when they realize this is a great excuse for having a proprietary, locked-in platform.
>It also encrypts the messages received that weren't encrypted when they weren't first sent
This could be done with PGP
How can you trust imap and smtp but distrust pgp? Protonmail emails are encrypted only when you send them to other protonmail users.
I am really flabbergasted with your thought process. Gmail isn't a scam but protonmail is? PKI is trustworthy but pgp (wot) isn't?
If you're afraid they'll modify their javascript,use their app!! Please tell me what webmail service you use,do they not use javascript?
Scam implies intentional deception,you failes to prove that. Moreover you sir are slandering them.
Let me say this - I don't care if they literally cloned yahoo's codebase, they are in switzerland and I pay them for their service, that alone makes them worth paying every cent!
you mean the address? that's expected of every hosted email service. you're always free to use your own domain though.
>they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators.
fair point. although if you were serious about security, you'd be using self hosted server + your own PGP keys. but for most people who just want something that works just like gmail/outlook, it's definitely a step up.
>This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail?
how is SMTP/IMAP access supposed to work? you send the plaintext password to their server to decrypt and hope they're not storing your password?
> Why don't you open source your desktop & mobile applications or your bridge? What a joke.
they're talking about interoperability, not open source.
No, I mean they own the contents of your correspondence because you can't get the emails out.
>how is SMTP/IMAP access supposed to work? you send the plaintext password to their server to decrypt and hope they're not storing your password?
No, you send it over TLS. You can also take some cues from Google and do IMAP-specific passwords or OAuth over IMAP/SMTP.
Isn't this just a variant of the "can't access your mails without using their client" argument? If you're really keen on using your favorite IMAP client, pay for premium and use their bridge.
>No, you send it over TLS. You can also take some cues from Google and do IMAP-specific passwords or OAuth over IMAP/SMTP.
How does that solve the issue of them (protonmail) stealing your password (and thus the private key used to encrypt your emails)? They need your private key to decrypt your emails server-side. If they have your private key, they can decrypt all future and past emails. Worst of all, it's totally undetectable, unlike the backdoored javascript threat that you mentioned earlier.
No, that's absolute bullshit. Paying to export your own data from a service is nuts. Not implementing features which have been expected from every mail server for the past 20 years is nuts. This behavior is inexcusable.
>They need your private key to decrypt your emails server-side
No, they don't, they can just send you PGP encrypted emails over IMAP and you can decrypt them client-side. This is how it works for everyone else.
The only thing really fundamental to email is SMTP.
It looks like you can using beta.protonmail.com.[1]
[1] https://protonmail.com/support/knowledge-base/how-to-export-...
This goes back to the my original point that protonmail is pgp for most people. You sound like the sort of person who'd use a self hosted email server + some IMAP/POP3 client + some PGP client with self managed keys. Maybe having an open stack is important to you, but people like you are definitely in the minority. Most people don't know and/or care what PGP, IMAP, or MTA is, but they want something more secure than gmail/outlook.
And for the record, I wrote my comments on "Hacker" News, not in my local newspaper. The readers here are not "most people" and I can expect many more of them to have similar values to me.
A year ago, they posted on Reddit: "Audits have been done, about one per year usually. Cyberkov has done 3 audits since 2014 (they recommend it for their activities with Palestinian activists, so security audits are necessary)"
Do you claim that the independent security firm Cyberkov is lying too?
With the preponderance of evidence they've provided (security audits, open source, and transparency into how everything works), if you're saying that this is a big scam and they're lying about everything, it's really up to you now to provide some evidence.
I don't think you understand how zero-knowledge encryption works.
When I signed up for the free tier nowhere did it say you can't forward your mail or access ot via IMAP or POP3.
A bit misleading IMHO.
> This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.
These are the exact reasons I have discouraged ProtonMail in every discussion it comes up. This is not a system that boasts the best of email as a platform, the decentralized and federated nature of it. In reality, it's just a walled garden of its own, even worse than Gmail, because there's no easy "takeout" solution.
The IMAP support has been in the works for more than two years, and continues to remain in beta for a long time. To make things worse, when I checked a while ago, it's available only to paying customers. That's like holding the free user base for ransom.
I would not recommend any email platform that actively makes it difficult to switch out. ProtonMail is a good example of such a platform, for my considerations.
* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ENABLE UIDPLUS SASL-IR NAMESPACE CONDSTORE SORT LIST-EXTENDED QRESYNC MOVE SPECIAL-USE CREATE-SPECIAL-USE IDLE AUTH=PLAIN
and after:
* CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SEARCH=FUZZY SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES THREAD=REFS ANNOTATE-EXPERIMENT-1 METADATA LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS LIST-METADATA WITHIN QRESYNC SCAN XLIST XMOVE MOVE SPECIAL-USE CREATE-SPECIAL-USE DIGEST=SHA1 X-REPLICATION STATUS=SIZE OBJECTID SAVEDATE X-CREATEDMODSEQ XAPPLEPUSHSERVICE LOGINDISABLED XCONVERSATIONS COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE
They only have the TLS ports open; the plain text services are disabled (no need for STARTTLS since that's insecure from MITM).
They allow having a password different from the account password specifically for these services.
>they could easily siphon off plaintext at the SMTP level
This doesn't make any sense.
It's great that you aren't taking things at straight face value, but they have very little benefit from doing what you say they could hypothetically do and an incredibly amount of risk and potential to blow up in their faces. In business terms, it's a ludicrous proposition to actually do what you claim they could do.
At the end of the day, you can claim all the hypotheticals in the world, but do you have any proof that they're actually doing anything remotely like what you say they could be? Because I haven't seen anything that would come even close to the scenarios in your hypotheticals.
You claim they're "a scam". That has certain implications, including willful misuse of data/money. Can you prove they're actually "a scam", or is all of this just posturing because they aren't running their company in the exact way you would want them to?
So, once again, what about Protonmail makes them a scam, other than not doing things exactly the way you want them to? I've seen absolutely no indication they're a scam from any of your comments or their replies, and your grievances seem to boil down to one feature (the bridge) being paid-for. That's hardly scam-worthy.
A service which makes you pay to extract your own data with standard tools is a scam in my book. If you don't support IMAP and outgoing SMTP you can't even call yourself an email provider in my book.
Then your book is flawed and doesn't align with the actual definitions of "scam" and "email provider". Especially for the former, there's a much higher bar, and your arguments are far from meeting it.
Let's define the requirements for the former, then. If someone claims to offer a service they don't, is that a scam? I think so. Now if we can justify the, by your own admission, weaker requirements for calling Protonmail "not an email provider", we've established they're a scam.
An "email provider" that doesn't provide IMAP and SMTP isn't an email provider any more than Facebook's proprietary "free internet but only on Facebook" is "internet service".
By your incredibly rigid definition, sure. Good thing the world doesn't live by your definition.
An email service provider is, based on the words alone, someone that provides email services. Do they allow for sending and receiving email from one or more email accounts they manage? Yes? Well then they're an email service provider. Many providers supported POP3 only for years, yet they were still called ESPs just fine, even without the IMAP support. Funny how that works.
This is going to be my final message on this, because your incredibly rigid and stubborn definitions and beliefs clearly leave no room for debate and nobody is going to change your mind because you are totally and completely right™, but what I will say is that if you care about this so much, there's absolutely nothing stopping you from making your own alternative that works the way you think it should. Just stop calling things scams because you disagree with their design decisions.
Obviously this does not apply to internal or external messages that are encrypted, so the real solution is to receive less unencrypted mail, which is exactly what today's announcement is about.
We have to take your word for it. Genuinely secure systems don't require trust. Now, I think this feature is a genuinely good one and applaud you for it, but I've seen Protonmail reps lean on it as an excuse for why they can't support IMAP and SMTP, which is nonsense. I also think that users should be educated about the difference between security guarantees (which this isn't) and security promises (which this is).
Your incentives may be aligned in a way that means you'll want to avoid storing plaintext email, but it's entirely possible you could be compelled by your government to secretly start siphoning off plaintext. This is why it's necessary to design systems which don't ask for trust at all, and to educate users on the limitations of encrypting incoming emails.
2. We don't believe such compulsion would be legal and would fight it in court.
3. Yes, this is a security promise not a verifiable guarantee. As I said though, our incentives for this are correct. We would love more than anything for all email to be encrypted already. Signal and Wire require trust-on-first-use. There's always some small degree of trust, and the smaller the better. Given the reality of unencrypted email, this is the best we (and anyone else) can do. Whether you are comfortable with it is up to you and your threat model.
Do I need to repeat why I'm not going to take this argument yet again?
>We don't believe such compulsion would be legal and would fight it in court
Good to hear, but you should still be honest about the limitations in your approach. Secure systems are not built around trust and ones that are should not be advertised as such.
and what is this "Genuinely secure system" you speak of? as long as the sender is sending in plain text, your mail provider can intercept and record it. how are you going to communicate with the 99.9% of people/companies out there that don't PGP encrypt their outgoing mail?
>All emails are secured automatically with end-to-end encryption. This means even we cannot decrypt and read your emails. As a result, your encrypted emails cannot be shared with third parties.
This is a lie.
Regarding email between ProtonMail users, Lavabit once claimed "Our team of programmers answered with a system so secure that even our administrators can’t read your e-mail." Which is very similar to your claim, "even we cannot decrypt and read your emails." Lavabit was then asked to give up its TLS key, to evidently allow impersonation and delivery of malicious JavaScript designed to exfiltrate "non-decryptable" data. ProtonMail users are vulnerable to the same attack if anyone in a conversation ever uses the web interface. Or the mobile app, if it's just a web view.
In contrast, native SMTP+IMAP (+-E2E) clients are not typically developed by the email service provider, making orchestrated compromise much more difficult, and users can benefit by performing actual audits themselves because their email client hopefully doesn't fetch malleable remote code at runtime.
1. https://web.archive.org/web/20151116024152/https://protonmai...
2. https://web.archive.org/web/20130115080859/https://lavabit.c...
Personally I use pass: https://www.passwordstore.org/
>PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source.
This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.