proton-bridge VS aws-lambda-ses-forwarder

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.

If they cannot use cloudflare(since we need to use its nameserver), you can self hosted a tool like https://github.com/arithmetric/aws-lambda-ses-forwarder It's powered by AWS Lambda so work flawlessly.

> Could there be a serverless alternative where the service wakes up only to receive emails and will be charged only when emails are processed, filtered and served & rest of the time no charge - avoiding $3 to $5 charged by behemoths per inbox?

I love ideas as much as the next guy and serverless email is kind of floating out there:

https://medium.com/schibsted-engineering/building-a-serverle...

https://github.com/arithmetric/aws-lambda-ses-forwarder

https://github.com/0x4447/0x4447_product_s3_email

It's possible to build it, but the problem is that you still have the same problem of deliverability. Obviously it works fine/great for receving emails though.

> Idea is how cheap can it go for personal inbox with all the features denied by the superlative pricing plans

It could get really cheap, but would people buy it? I always wonder if price is really the limiting factor for self hosted emails.

Zoho is already QUITE cheap: https://www.zoho.com/mail/zohomail-pricing.html

Maybe this would work as a business, but it's a bit questionable to me.

When using SES, you cannot set FROM header to anything. The FROM has to be either an whitelisted email address or a domain that you own and verified with SES.

When forwarding email, we are receiving email from unknow domains. If we rewrite the FROM headers then the DKIM will invalid, so service will have to rewrite the FROM and clear out DKIM.

This is a well-known SES issue and project has to work around https://github.com/arithmetric/aws-lambda-ses-forwarder

```

If you are willing to mess around with code https://github.com/arithmetric/aws-lambda-ses-forwarder use this. It's essentially use AWS SES to process inbound email and lambda to forward email out.

It is unmaintained https://github.com/arithmetric/aws-lambda-ses-forwarder/issues/119 and written in godawful JS promise syntax. So while it may work, I didn't feel like trying it.

Thanks to Joe Turgeon for inspiration of the tutorial: https://github.com/arithmetric/aws-lambda-ses-forwarder