wildduck VS proton-bridge

Nodemailer author here. I now publish all my libraries/tools (like Nodemailer) under some permissive license (MIT, MIT-0, ISC). This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway. For example if I build a OSS software and commercial software that both use such library, then it is easier to manage it under permissive license - I don't want copyleft licenses turning up in my commercial software even if I'm the owner.

For OSS applications, I use EUPL (eg. https://wildduck.email/) or AGPL copyleft licenses. The license does not stop anyone using it as an application, but at the same time people are not free to copy, rename and sell it either.

- https://wildduck.email/ (E-mail)

Even though I have self-hosted things individually (eg: my Ghost blog on a RasPi connected to my home WiFi), something which I've always been concerned about is the separation of all these services, since they must have APIs and access rules. What's an ideal way of setting up a multi-service server like this, and what security policies should I implement. Additionally what are some must haves that you have running on your servers?

I understand self-hosting is a huge labour of love, and I have no qualms in investing time/effort learning :)

The largest WildDuck installation manages 100k+ email accounts with around 300TB of stored emails. So it does not always have to be one of the old and tried softwares. https://wildduck.email/

or install https://wildduck.email or mail in the box type of server, just host it yourself. Wildduck web interface allows you to make unlimited alias already.

I want to create an email service. I want to use MongoDB as a storage option. I want to store every email in a that DB but I can't find an email server technology that supports that. Are there any technologies that support that out there? As far as I could go only wildduck supports that but I don't like their documentation, setup, ecosystem, and more, so I'm looking for an alternative technology.

I use: https://github.com/nodemailer/wildduck for Mails.

I had noticed this/similar feature on wildduck mail server. Checkout the Advanced Security section there, might be what you are looking for.

WildDuck https://wildduck.email/

That isn't really fair. If you read the article, protonmail essentially supplied the FBI the recovery email of the account. This is metadata that protonmail must have that isn't encrypted by the user for obvious reasons.

Regarding the "MITM" for every email sent, this is related to their "bridge" software which allows regular IMAP/SMTP software to use Proton Mail. This software must edit the emails to encrypt them in their scheme.

This software is open source and can be inspected and/or built locally. https://github.com/ProtonMail/proton-bridge

> This appears to be related to a behaviour that ProtonMail has of dropping all plaintext email if any mime-encoded parts exist.

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.

Repository here https://github.com/ProtonMail/proton-bridge

The privkey is never loaded out of the keychain. Rather, it acquires a handle to the privkey and relies on the keychain to carry out cryptographical operations. (https://github.com/ProtonMail/proton-bridge/blob/master/pkg/keychain/helper_darwin.go and https://github.com/ProtonMail/proton-bridge/blob/master/pkg/keychain/keychain_darwin.go)

Oh yes. The Bridge shouldn’t have been marketed as stable for the past years because of this issue (see issue #220 on Github, reported 2021-09-29). It’s fixed in Bridge 3.0.