end-to-end encryption? yes, if both users are on Proton - but don't call it email then.
Storing encrypted makes only sense when keys are not in their hands. Plaintext password enters their system on each login which means they can have your decryption key at any point if needed.
if they use the email/smtp protocol then it's email.
plaintext password does not enter their system. For example I still have to enter a second password for the in-browser decryption (although these days they use the same password). Most of security feels like theatrics, but small measures that add difficulty for a potential threat actor add up.
I think you are misreading my comment: they are the threat actor themselves, tricking users in believing they are better off via Proton.
SMTP does not encrypt messages and they arrive at Proton's inbound relays unencrypted, are scanned in plaintext for spam etc. At this point they can Bcc anything to another relay/account and keep a copy of all inbound messages BEFORE anything gets encrypted.
Access to historical messages? One line of code for logging, and let's not forget GPG does not encrypt the metadata which is readily available. How about FTS indexes, are they also decrypted on the fly in the browser?
Email is complex and not many have the patience to understand the monster behind, but lying about it, as Proton does - I find it just insulting to our profession.
Also "Swiss neutral", this is even more offending. Swiss execute US orders regularly.
just forwarding is great if you can afford losing mail. Gmail will drop your messages occasionally.
You can use gmail's own relay for sending but it won't DKIM sign which is a must even for Gmail itself.
for a more reliable solution use forwarding AND POP3 fetching with some provoder OR use https://gmailify.com which offers own relays too for ~$7 a year.
I think you're reading that wrong. It's an issue with the protocol. IMAP/SMTP as implemented in most clients do not support 2FA. You can add 2FA on your own on the webmail, but you could still circumvent it by using the protocol directly. It's not a Migadu-specific thing.
You could also stick with free Gmail accounts and add on top all addresses and domains you need via gmailify.com[1] for flat $6 per year. It's custom domains extensions for Gmail with own dedicated relays.
If you are just doing cold mailing on one-to-one basis, you can use migadu.com for it. Everyone has to do that at some point and it is not spam. 500 mails is not a lot. Just cap it daily to e.g. 50-100 or you could hurt your own domain reputation.
> Email spam, also known as junk email, refers to unsolicited email messages, usually sent in bulk to a large list of recipients.
It is Gmailify serving the "unlimited", not Google. No ToS violation - not using Google's APIs. Gmailify is an extension of existing features of Gmail.
Many Gmail users already do this, but through a complete service like Fastmail, Migadu etc. Gmailify provides a thinner layer made for this purpose specifically.
Thank you for the comment and typo correction! Fixed.
> Allowing multiple customers to send mail from the same IP seemed too risky.
There are two sides of this problem. Sending very little traffic from an IP can also have negative effects as it will often be seen as "new". Using a shared range to send out mails of all customers could keep all IP addresses warm. The benefit is also that if there is one bad apple, it is statistically very low.
Storing encrypted makes only sense when keys are not in their hands. Plaintext password enters their system on each login which means they can have your decryption key at any point if needed.
smoke and mirrors marketing...