How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I find it very hard to trust any email service that claims to be E2EE without an audit by a reputable firm like Cure53 or Trail of Bits.
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.
I guess we need to coin a new term, something like VibeE2EE. As in "we asked to make something E2EE but we have no idea what it has made, nor we asked anyone to audit it (because it wouldn't pass a code review, let alone security audit)"
The E2EE claim is BS, unless qualified by saying that the platform supports GPG-encrypted emails only. Proton makes the same claim and it’s just completely false. E2EE is not possible with existing email protocols.
Has anyone actually looked at what Cure53 or Trail of Bits specifically tests for when scoping an email security audit? My suspicion is the scope matters enormously — an audit that never tests the encryption boundary between server and client wouldn't catch exactly the flaw described here.
I'm not wild about this benchmark. There are well-known firms (definitely not saying that about Trail! no experience at all with the other one here) that issue public-facing audit docs that read the same no matter what the project scope was.
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.
I know it's in it's infancy here, but if it's a solo passion project I'd consider open-sourcing it so the E2EE can be verified.
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 do not understand why anyone would want their email provider to be "E2EE". If I want end-to-end encryption then I will exchange public keys with the recipient.
I'd like to know more about the operator, besides them being from USA. Having the data in Iceland sounds great, but we should be wary of any new service designed specifically to attract confidential conversations.
Maybe x.com/rootshell0 is their X account? I wish I could tell you more.
edit: the operator is one of the accounts 10 followers Lol https://x.com/haptagod
There is no such thing as E2EE email. You can encrypt your storage or some of the hops, but the plain-text email contents goes through between every layer, unless you're talking about PGP, or some similar scheme you built on top of the email protocol (where obviously both the sender and the recipient must participate).
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.
Nice, the more stand alone non corporate email providers the better. You have it on a good host. I've never tried to email from their CIDR blocks, curious how it works out.
You defeated https://www.emailprivacytester.com straight off. Which is more than most new email services. You seem to be relying on CSP entirely for this, but it works.
You declare HSTS preload, but you are not in the preload list. You can not be added to the preload list at https://hstspreload.org/ because www.rootshell.is exists but has an invalid certificate.
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.
I gave your service a test, seeing all buttons in gray, and could not figure out if the service was broken, if my browser was broken, or if my e-mail client (Betterbird) was doing something good. Then I remembered that I use LuLu[1] to deny it all network access besides reaching my private e-mail server. Not ideal, I've learned to live with the caveats, but I do suppose it really does get the job done of stopping in-mail tracking.
I wasn't able to sign up for postmaster@rootshell.is, but I was able to get abuse@rootshell.is. You should be careful about what standard email addresses you allow people to take. I recommend you take abuse@ back from me and you should really have a strong denylist. I just asked an LLM for a list of things you should be blocking and it came back with the following. The cert validation ones seem particularly important:
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
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:
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
I hate shoving LLMs everywhere, but honestly this is probably a good use case for tiny models like the 0.6B Qwen model to flag account names for human review.
for a moment i thought it was rootshell.be - many many years ago they were giving away shell accounts, and teenager me used to have one for learning purposes (and also for the cool domain)
I’m never hosting or dealing with any companies in Iceland. I had a run in with a hosting company there who was DoS attacking us from compromised nodes. I emailed them and they told me to get a letter from a local lawyer telling them to stop and they’ll look at it. In the end we contacted our DC provider and they dumped all traffic from their entire blocks.
A year later same attitude from a different one hosting a web site for Covid misinformation which was against their own AUP.
Fair point, but in practice most hosts don't actually kick people off quickly — Iceland or otherwise. We got abuse from an AWS IP once and it took three weeks and six escalations to get action. Geography matters less than how fast their abuse desk actually responds.
Probably also a double meaning — "rootshell" as in gaining root access. We used to call a compromised machine with a root backdoor a "rootshell" back in the day. The # prompt angle makes sense too, though I'd guess the security connotation was intentional.
The naming makes sense as a brand signal — it's positioning itself toward a technically sophisticated audience who'd recognize the # prompt. The root user association implies full control, unrestricted access. As far as branding choices go, it's fairly deliberate even if the connection to email is loose.
Another company tried the Iceland root, and after growing steadily and without reporting issues (at least I never saw anything reported) just shut down one day.
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.