Email cannot be encrypted at rest and this cannot be fixed

The Drawbacks List

You have read all about the benefits and freedoms hundreds of thousands of users get via Migadu. Now you are trying to figure out where is the catch.

We do not want you to use our services if they do not fit your requirements. It’s not a sales trick, but a transparency policy we would appreciate to see around ourselves.

Here is everything you need to know before you find out as a surprise.

Delayed configuration

Most of the email changes you make through our UI will take about 3 minutes to take effect. Even if you change mailbox password, it will be delayed. Surprisingly, it has never been a problem for any of our users so far.

This is an architectural limitation and we are working on lifting it.

Free TLDs are banned

We refuse hosting email for free domain names as they are by majority involved in fraud, spamming and phishing. If you want a reliable email, and we believe that is why you are here, it is pointless to get a domain name of poor reputation, penalized by each email provider on the planet.

No mailbox 2FA

This is a common surprise.

IMAP protocol as well email clients do not support second factor authentication for the mailboxes. Even if they did, IMAP connections are made way too often which would make authentication unusable. Imagine needing to enter your TOTP token every few minutes.

We could enable 2FA on the webmail, but IMAP/POP/SMTP accesses remain unprotected which beats the purpose. We are working on solution here which will allow sand-boxing a username/password pair to a webmail use only.

We do offer so called App-specific passwords via mailbox identities though. These are commonly touted by email providers as 2FA. They are not.

We refuse to sell quackery.

Not encrypted at rest

Email as we know it and encryption are incompatible. If someone is telling you otherwise, they are not to be trusted.

Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses, index messages for searching or recover messages when a password gets lost. Not to mention the usability issues of changing passwords and encryption keys.

This cannot be fixed, at least not any time soon without breaking the protocols on which email relies.

If we were to roll out our own encryption at rest, we would have to keep the encryption keys ourselves. That means we would be encrypting and decrypting messages on the fly using a key which is available on the same storage where your data is. That is not encryption but rather encoding. We already have all messages encoded and compressed.

Some other providers automatically encrypt messages as they arrive using users’ public keys. That sounds exciting but in practice that means you cannot access your messages using the webmail unless you pasted your private key into a browser, and have it handled by script and a myriad of third party code. Ouch.

Further more, you would not be able to search your messages, unless we indexed them all before encrypting, which again beats the purpose of encryption. Lastly, if you were to lose your key or wanted to change it, you would lose all your data unless your provider allowed you re-encryption of all messages. With the norm of very big mailboxes we are seeing nowadays, that would be a significant effort, and it would not come cheap.

You may be thinking now, what if someone stole the hard drives from the servers? Our servers are kept in secure data centers under constant, internationally certified physical security. A Hollywood-like action would be needed to get access to the physical servers.

If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself.

If you are one of those that want absolute secrecy, sorry, email was really not built for you.

We refuse to sell quackery.

Human email use only

You could try using Migadu to send transactional as well bulk mails, but you will quickly find out it will not work as expected. There are rate limits per mailbox, domain as well account which, if crossed, will block your mailbox, domain or even full account.

If we find out this limit crossing was intentional, you will be banned from using our services permanently and placed on a blacklist.

That said, an occasional transactional mail is completely fine such as those from contact forms. If you arrive to a point where you need to send a dozen messages per second, you will want another service anyway, as your sending requests will start being rejected.

The same rule applies for incoming messages. If you are blasting automated mails to your mailboxes, they will be rate-limited after which they might even be rejected.

Daily limits apply

Our subscription plans are divided by daily capacity requirements. We really do not care how many addresses you have but rather how you use them. As such, we limit daily traffic on the account.

Depending on how many users you have, you will need to select a plan. If you have hundreds of email addresses which are seldom used, even the lowest of our plans might suffice.

If you try blasting mails in or out, your limit will be quickly gone and you will not be able to receive and/or send more. This will also trigged a bunch of alerts on our end.

In most normal situations, you will be warned if you are reaching your limits so you have time to analyze the traffic and possibly upgrade your plan. This allows you to pay only what you really use.

If no upgrade is made, incoming messages will be deferred until the following day, and sending messages will be refused.

No bulk messaging

You cannot use Migadu to send mails fast. These attempts are monitored and will be quickly sanctioned.

We do not approve of or accept bulk mailing, even if it is not spam. Please use dedicated services for that.

Basic calendar

We make the basic CalDAV and CarDAV services available, but they are not our focus. We continue developing them but please do not expect we will ever compete with dedicated calendar services.

Spam filters are not perfect

That should not come as a surprise as there are no perfect spam filters.

While we do process a significant email traffic, we base our spam filtering on open source tools which we support and contribute to. We do not use proprietary data of blacklists for filtering.

For most of our users the spam filters work great, but each mailbox receives a unique messages stream. What works for others may not work well for you.

We offer all the tools for you to adjust your domain as well mailbox spam filtering, so you might need to flip a few switches. Unlike with BigCos, we give the spam filter control to you.

Messages might go to Junk

We give no guarantees your messages will reach recipient’s inbox. No one can, as message processing at the recipient’s side is outside of the sender’s control.

We care deeply about our reputation. We monitor and keep our IPs clean. However, the IPs may get on blacklists from time to time due to an occasional bad apple using our service. We are quick to react, both in banning users and cleaning or rotating our IPs.

Please understand though that blacklists are not sender’s problem but rather a recipient’s problem. A blacklist entry is only a signal, one of many in spam classification. Email providers which blindly rely on blacklists are just inconsiderate of their users and email interoperability. Ham is ham, even if sent from an IP address which is listed.

Running a blacklist is not even close to the task of running an email service. To add to the insult, some blacklist require a removal fee, making them really - blackmailers.

We refuse to use blacklists and encourage others to consider dropping the same.

Sending might get rejected

Sometimes your outgoing messages may get rejected by our spam filter. We have yet to see a false positive here. If it happens, it most likely means your DNS configuration is incorrect or your message is spammy.

Not cheapest

You might be out looking for cheap email hosting. We may fit your bill but there certainly are other possibilities which cost less. If all you need is one or two email addresses, you might want to stick to the BigCo providers.

We do not offer email at our domains

Our whole service was built around the premise of giving email liberties back to the users, not taking them away. We refuse to fence users and lock them in.

Domains are so cheap nowadays. Why jail yourself voluntarily? Email was always meant to be portable and independent.

We do not chase the cool factor

Unicorns, fairies and investors. None here. We do not have cash to burn. We do not talk about “scaling” but rather serving better. We are careful about the features we bring in or take out and stay very loyal to our users.

In Switzerland, but servers are not

This may come as a surprise, but we do not host our servers in Switzerland. Current data centers are located in France. We may in the near future add Swiss data centers too but this is not our priority.

We find EU privacy laws much more elaborate and restrictive than the Swiss ones. Switzerland used to be famous for banking secrecy, but that has nothing to do with digital data.

We refuse to sell quackery.

Only English interface

While we speak 8 languages, our interface for the moment remains in English. We plan on adding additional languages but it is not our highest priority.

No instant responses

Not every issue requires immediate attention. During office hours (CEST time), we are quite responsive. After hours we monitor the tickets of Standard and Maxi plan accounts, but respond and act only if the matter is urgent and cannot wait, as it rarely is.

No telephone support

When you submit a ticket to us, you will get an answer from a professional who is involved in building and maintaining Migadu. Most of the time issues we see require data from users, followed by log analysis and triage by us. These flows are by nature asynchronous. Phone calls do not fit.

No SLAs by default

In case of a significant outage, we might compensate users to what is fair without any agreement. Email is asynchronous and composed of many services that most of the time outages and maintenances are unnoticeable. Nevertheless, we cannot give service quality guarantees and do not offer service level agreements (SLA) in the default offer.

If you are interested in an SLA, we can offer you our enterprise pricing, starting from $5.000 monthly. Contact us for more information.

Downtimes

All email providers have occasional downtimes and outages, even the largest ones, without exceptions.

There will never be a finished on-line service. We work continuously at making our service better. That implies that bugs will happen and service may be affected at times.

We may be also be a subject of DDoS or spam attacks. Email providers are a common targets. While we do have DDoS measures in place, some delivery delays may happen.

Our data centers may also have connectivity issues and our hardware may manifest faults.

If you cannot accept a few hours of email downtime under any circumstances, Migadu is probably not for you.

That said, email was built to be very fault tolerant. In a case of a total outage where we are unable to accept messages for your domain(s), incoming messages will not get lost. They will be delayed until the service recovers. The senders’ systems will simply keep retrying periodically for up to 48 hours until the message finally goes through.

While periodical outages in incoming streams are not noticeable, accessing messages over webmail, IMAP or POP3, as well sending via SMTP are. We have redundant services in place that ensure fail overs, or in worst case, a short downtime.

No feature parity

We really do not care what service X offers and will not try to match them unless we believe it is a genuinely good thing.

We are however always interested in hearing suggestions from users. This is how we came so far. Roughly a half of our features were at some point user suggestions.

We did it our way

We are very opinionated and will refuse to follow trends or “best practices” if they do not make sense to us. This refers to business as well email policies.

from Hacker News https://ift.tt/34jwAp2