dejan

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.

Translated: https://daslamm-ch.translate.goog/ueberwachungsoase-statt-da...

Original: https://daslamm.ch/ueberwachungsoase-statt-datenschutzparadi...

What we really need instead of such shams is a new mail system that does not depend on trusting providers and especially not a SINGLE provider.

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.

smoke and mirrors marketing...

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.

hmm, at that price you could try https://migadu.com

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.

Why?

Try https://gmailify.com so you can add domains to your Gmail account.

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.

[1] https://www.gmailify.com

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.

It was useful during development.

Thank you for your comment. The service did not exist in December :)

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.

You can ask us directly such questions.

When we started, we were unsure how to cover the costs of the free tier which were becoming steep. One of the ideas was to allow internal advertising of paid users towards the free users for their products and services through text banners on incoming messages. We did not like that after all and preferred to drop the free plan all together.

Btw. When you register a company, you want to give it the widest possible scope, to avoid later paperwork. The purpose in the Handelsregister is completely irrelevant to actual operations, as long as it is larger in scope.

Our infrastructure is split among several datacenters. We utilize also multliple datacenters within individual regions. In case of a complete datacenter disaster as it has happened in Strasbourg, we'd be minimally affected with possible data loss of 15 - 60minutes of the most recent data.

That said, chances another OVH datacenter will burn down are significantly lower now compared to other datacenter providers.

That is not quite fair; even though we did raise prices, we informed twice in an announcement to all users months before it happened giving opportunity to act upon it. We have also grandfathered old pricing for an additional year to all users that asked for it.

Nevertheless, glad you found MXRoute fits your needs and budget!

We could all bake our own bread at home, but very few do. It boils down to convenience and time best spent.

By all means, I would recommend [5] if you have the technical knowledge to run it. This will give you more insight and appreciation for email as well [2] & [1] and humbly... [0].

Unfortunately, running an email service is a very underappreciated task; after Gmail - it is taken for granted. Cheers to Postmasters at MXRoute and Postale.io!

Forwarding will always be unreliable, regardless of which service you use. Gmail has POP3 fetching feature for a reason, so people would forward less.

Disliking the answer does not make it incorrect. =)

Dejan from Migadu here.

>Hate speech, racism, calls for violence, Nazism as well any other immoral, unethical or socially unacceptable activity will be denied service. If illegal, we will report such to the authorities.

That is not referring to the content of messages but rather general usage of our email service. We never look at the messages except when asked to. If you use our email service for things such as "hate speech, racism, calls for violence", all being illegal and punishable by law, we would know about it only once we receive a harassment complaint. With a valid proof we would act upon it, first level being asking you politely not to do it because it involves us then.

That is rather common sense, and we speak here from experience and past cases.

try migadu.com

Seen it :)

The notice was actually given in early August, and the change took effect in October. We have extended trial to all that asked for it without problems. We did say in the update what happened.

The lowest paid plan has only limitations in tools for multi-admin, everything else is the same with lower quota obviously, but that is already double what was on the free plan.

All good, just that has nothing to do with trust. Trust works both ways. There is no such thing as free lunch, and we have always called the "free" plan "unlimited trial" with clear statement that we can revoke it at anytime.

Pandemic hit everyone, including us, that is why we cannot afford to subsidize free users anymore.

The new paid tier is ~$1.6 monthly or about 5 cents a day, which is affordable in every corner of the planet. We also never refused to help those that by some chance cannot afford it.

> I don't like such tone.

Corrected, not intention to make a "tone", just pointing out that information is intentionally omitted.

> Its perfectly possible to get IMAP to work with TOTP

Yes, but that's not available in generally available email clients. There are OTP extensions to IMAP.

> I don't trust webmail at all because I don't audit the JavaScript

This. We are working on one that uses no JS or just conditinaly for enhancements.

> Then again, I also don't trust e-mail authenticity because the protocol is broken by design, and nobody has come up with a suitable alternative.

Glad I am not the only one thinking that =)

> A lot of people are using a weak password as first factor, btw. Do you protect against such?

No, we set a minimum 6 char password. However we think it is less secure to have a complex one you canot remember than one of average strength.

Posteo is not very transparent there. They do not mention SMTP/IMAP/POP access on their 2FA docs. 2FA is not supported by any email client for generic IMAP/POP/SMTP[1]. Just think of that experience, providing a token on every sync or sending. This is why we sometimes take such a harsh stand in our copy. You need to tell users about these things and not throw marketing BS counting on information asymmetry.

We (Migadu) do support TOTP + Yubikey on the admin account. We also support TOTP on the webmail just like Posteo does. However, we call that B.S. ourselves and are working on a real solution for mailboxes.

If you do setup 2FA on Posteo, how is your e.g. IMAP access protected? They most likely offer an app-specific password which is very different than 2FA. We do those too, they are called _identities_ in our context.

We have a long and bumpy road behind and ahead of us, but one thing we made clear on day one is that we will not B.S. users. Email is not perfect, it has serious conceptual issues due its age, but one should not go about it as "there we fixed it!" (Hey hey.com!)

[1] https://security.stackexchange.com/questions/173807/does-ima...

The control panel does have 2FA via TOTP and Yubikey already. Webauthn is coming. We're working on a solution for the mailbox 2FA, hence the (yet).

No risk of flamewar, I genuinely want to know your view, not defend ourselves in public. If we messed up, knowing where and how helps not to repeat it.

I agree we could have done that better, however an announcement was made via email and site, taken it reached you via notification address in account.

Nevertheless, my apologies on behalf of our team. We will take your criticism to improve. None of us were born doing this and we are learning as we go.

Thank you for your criticism here (offtopic though), but we have never had an outage where mail was lost. Where did that comment come from? I am sorry for that bitterness, but I don't think we deserve it.

I rather think the issue here was that your regexes which were supported on our legacy system were not all converted to the new system during migration. This was something we did notify our users about via email and our home page. Not sure what more we could have done there.

Nevertheless, that has nothing to do with being "trustworthy".

Thank you for posting this. Interesting!

But in this case, if user were to forget password, the data would be lost, would it not?

Thank you, appreciated that! I think the "quackery" part reads as too arrogant. Was not intention and I will make sure we get that rewritten.

Same paragraph has a mixture of E2EE and Encryption at rest topics which may confuse users. We'll separate that.

>claiming that everyone who chooses differently is selling quackery

We never say that anywhere, but thank you for the heads up.

> The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.

Indeed, you have all the rights to say so, but we both enjoy the liberties to differ on what "security-in-depth" is.