Please merge this. Running email clients and protonmail-bridge on separate machines is really useful!

Yes. Please merge this because it is very useful to have the bridge in one machine and the mail client on another one.

We can definitely see the need here but as I'm sure you see this is breaking the basic principal of e2ee. We first need to build a strong use case here and then review our threat model.

TL;DR I'm running mail bridge on a host machine, and want to use it within a kubernetes pod (within a bridged private network).

--

I'm running minikube which spins up kubernetes clusters. My kubernetes cluster has bridged to a private ip network like 192.168.51.1

My cluster has a pod, say 192.168.51.2 which is running NextCloud https://nextcloud.com/

That pod wants to use the mail bridge that is running on the host machine. It can only do that by calling the host IP 192.168.51.1:1025, but this isn't allowed because protonmail bridge doesn't allow binding to any other IP but 127.0.0.1

This is my use case. I'm not convinced this is even a meaningful security measure because all you're doing is forcing me to bypass it with some kind of reverse proxy

I solved this by simply compiling the bridge with the listening host changed as in this commit 1e85c8d

--- a/internal/constants/constants.go
+++ b/internal/constants/constants.go
@@ -60,7 +60,7 @@ const (   
KeyChainName = "bridge-v3"                                                                                                                                                                                                                                          // Host is the hostname of the bridge server.
-        Host = "127.0.0.1"
+       Host = "0.0.0.0"                                                                                                           
)  

and then build bridge without gui as per this instruction build-bridge-without-gui

I understand that there are use cases it is useful to be able to configure this. I can agree this is useful. But I don't like the Listen on port 0.0.0.0 by default commit at all.

Enabling the Bridge to listen to all IP addresses by default is the wrong move, and it is a security risk related to that. Keep listening to localhost by default, but make this address configurable - and make the user type in 0.0.0.0 manually if needed.

For anyone wondering, I decided Proton is creating this bizarre proprietary protocol thinly veiled as "security" actually for vendor lock-in. The complete disregard for user friendliness is evidence of this. I ended up abandoning Proton and am now happily using Fastmail instead.

This is sort of crap. I don't want to setup a reverse proxy manager to enable my docker instances to talk to my Proton Mail Bridge....

The above hands down should be configurable with a bias on configured for local usage, not internal usage.

At this point in time this is not something we officially support. Bridge is intended to be run on the same machine where the user runs their email client.

For everyone who wishes to use bridge in non-standard use cases, please follow the steps listed here: #270 (comment)

I've had ongoing problems deleting emails from Thunderbird for the past year. Having the option to run the bridge, which is little more than an IMAP/SMTP server, on another computer would definitely help diagnosing the issues I'm having.

I really wish this whole scheme would be simply dropped in favor of using straight IMAP/SMTP as other email providers do, or at least give users the option to stick with the bridge or go "normal."

The way I see it, the bridge gives a false sense of security since, regardless of how iron-clad secure the connection to one's email provider is, there's absolutely no way to control (or even tell) how many servers an email goes through in transit.

@alexmcwi

I really wish this whole scheme would be simply dropped in favor of using straight IMAP/SMTP as other email providers do, or at least give users the option to stick with the bridge or go "normal."

If you want an e-mail service provider providing a more "normal" approach, then there are viable alternatives in that scope. mailbox.org is the first one popping up in my head.

The way I see it, the bridge gives a false sense of security since, regardless of how iron-clad secure the connection to one's email provider is, there's absolutely no way to control (or even tell) how many servers an email goes through in transit.

I'm sorry to say, but it seems you have not fully understood the security model and scope Proton Mail provides and how Proton Mail Bridge fits into that model.

Some pointers with more information:

• https://proton.me/blog/bridge-security-model
• https://proton.me/blog/protonmail-threat-model

One of the features Proton provides which is impossible to achieve via the "normal" approach is the Secure Remote Password, which both Proton's web portals, mobile apps and Mail Bridge facilitates. To explain it simply: Your account (and mailbox) password are never sent to Proton's servers in a way they can retrieve your real password. Just that is a huge security improvement over the "normal" approach.

For everyone who wishes to use bridge in non-standard use cases, please follow the steps listed here: #270 (comment)

What if Bridge is made accessible from outside by nginx's "stream"? That would be a direct access. Can Bridge handle attacks (crafted packets maybe?) or its design assumes running in a trusted environment?

@ivan-boikov The Bridge is designed to run on the user machine . All our efforts are focused on this use case. We have not done any testing for malicious scenarios where you expose this connection to an insecure environment.

Just make it configurable? And then users can do what they want? It only concerns our own email so why do you care? The use case is clearly for integrating ProtonMail with other services, like administrative email sending in Nextcloud / Vaultwarden for example. The more people integrate with ProtonMail, the better for your business! Pay attention! :D

@LBeernaertProton

@reinthal I'd argue that it is configurable. You just need to apply your patch and build it yourself 😉

@dsommers:

You're technically right, David, except I don't have hours to learn a new skill that I'm unlikely to use more than once in a blue moon. Hence my wish for this functionality, which seems to be trivial to implement by proton.

Proton's marriage to the bridge idea is going to last a long time only because those of us who still use email clients are an insignificant group compared to those that rely on the web interface.

Ironically, the end-result of using an email client is that emails are stored in plain-text in my computer anyway, which makes the encryption provided by the bridge pretty much useless (at least in my use-case). From what I've been able to glean, the bridge connects periodically to proton's servers, sends outgoing emails and grabs, decrypts and re-encrypts incoming ones, and then acts like a local smtp/imap server.

If the goal is to secure communications between my device and proton's servers, any vpn client would suffice. Otherwise, it's little more than yet another way to waste hard-drive space.

Please make it easier to use mailbridge within local networks. I dont feel supported as a business user trying to integrate your product into applications that dont all run on the same machine. This is a remarkably simple and important feature to ignore.

Thanks everyone for the feedback. Bridge was designed with a specific user profile in mind, and to run on the end user's machine. In its current state, we can't offer this feature set. Please note that the desired functionality can be achieved by an appropriate network setup outside of Bridge. It is not impossible, but is not encouraged and supported by Proton.