nvm, looks like the encryption key is derived from password, stored on the server side encrypted with these passphrases

I'm just a new user like everyone else commenting here. I should have been clear about that with a comment in the original post, sorry. I think x.com/rootshell0 looks like they have an X account but idk

Maybe x.com/rootshell0 is their X account? I wish I could tell you more.

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.

[1] https://objective-see.org/products/lulu.html

Weirdly, if I click Load Images, all I get is a load more CSP errors and the image fetches don't happen.

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

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

Because it is a shell for the root user [1].

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

[2] https://en.wikipedia.org/wiki/Number_sign

[3] https://unix.stackexchange.com/a/291733