I signed up to give it a brief test and immediately noticed that emails are returned from the server in plain text. This means that the emails are decrypted on the server, which defeats the entire purpose of E2EE. The encrypted email contents and metadata should be returned to the user and decrypted on the client.
It's also painfully obvious that the entire thing is vibe-coded. While that in itself isn't an issue, it raises scrutiny. If the author doesn't have a full understanding of the code their LLM generates, some nasty bugs could be lurking.
Not very promising.
If you're keying off 3rd party assessment, which is sane, you should be evaluating the combination of the testing team (the best firms will publish reports with the names of the consultants on them) and the scope and depth of the results. The company shouldn't matter; the scope should matter a lot.
A meaningful security assessment for an "E2EE mail service" is nosebleed expensive.
If you plan on launching this as a monetized project of some sort, I, as a potential customer, would suffice for audits but I'm sure they can get pricey.
I'll give it a shot either way, just my two cents
I’m trying to create an account to test this service. I get this error message, what does it mean? Why is the error message so short to the point where I (the user) don’t know what to do next? Why can’t software developers learn how to communicate better with their non-tech users? And this is coming from someone with a 30+ years career in software engineering.
edit: after hitting the button “I’ve saved my recovery phrase - continue” multiple times and getting the same repeated error message, it finally worked but then the API returned “error: Registration failed”. And at this point I give up. This is why many projects, even at Big Tech companies, fail: too much friction for new users, or too many features, or too many options to choose from.
> encryption key is derived from the password > One can use the passphrase in case password is lost
What does this really means? is the password encrypted with these pass phrases instead of being hashed?
Your MX TLS configuration supports various anon ciphers. These should be disabled.
Your DANE is broken. Try any of a number of freely available online validators.
RFC 2142 mailbox names (the core list):
postmaster@ — required by RFC 5321; mail systems expect it to always work abuse@ — for reporting spam/misuse hostmaster@ — DNS issues webmaster@ — website issues noc@ — network operations security@ — security/vulnerability reports info@, marketing@, sales@, support@ — business functions
TLS/certificate validation addresses (RFC 8552 / CA-Browser Forum):
admin@, administrator@ ssladmin@, ssladministrator@, sysadmin@ These can be used to validate domain control and issue certificates, so handing them to a random user is a real security risk.
Common automated/system senders people impersonate or that cause confusion:
noreply@, no-reply@, donotreply@ mailer-daemon@ — bounce messages (RFC 5321 sender) root@, daemon@, bin@, sys@ — Unix-style system accounts null@, devnull@
Brand/trust-sensitive ones worth blocking too:
billing@, accounts@, payments@ help@, contact@, service@ legal@, privacy@, dmca@ register@, registration@, signup@ The service's own name (e.g. [brand]@, team@, staff@, official@)
[edit] Re the TLS issue. You should set up a CAA DNS record and also check on crt.sh later to see if anybody managed to get a cert for rootshell.is if you didn't lock down the validation addresses
Google doesn't let just anyone make a mail on the google.com domain for example.
Stochastic outputs that may not mesh with reality? xD
- https://uk.trustpilot.com/review/runbox.com
- https://cyberinsider.com/email/reviews/runbox/
A year later same attitude from a different one hosting a web site for Covid misinformation which was against their own AUP.
Or at least the app’s logo is the root user symbol: a number sign [2]
Normal users typically get a $ prompt, while the superuser (root) gets a # prompt [3]
[1] https://wiki.debian.org/Root