[mike-cardwell]

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.

[mike-cardwell]

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.

[daneel_w]

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

[mike-cardwell]

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

[mike-cardwell]

I wasn't able to sign up for [e-mail], but I was able to get [e-mail]. 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

[charcircuit]

Wouldn't the better guidance be to use different domain for official communication similar to sites where you can customize the subdomain? Attackers can always come up with something you didn't think to block.

Google doesn't let just anyone make a mail on the google.com domain for example.

[mike-cardwell]

That wouldn't be better guidance. That would be additional guidance. I'm sure Google also never let anybody set up [e-mail]

[sc0rt]

I found the guy on X, wasn't that hard: https://x.com/haptagod You should probably hit him up and tell him these things?

[mike-cardwell]

I don't use X. You can tell him if you want.

[jszymborski]

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.

[rho138]

Or just read the RFCs tbh. I keep them indexed locally as text, it’s super useful for finding random garbage that may not pop up from a search.

[jszymborski]

There's a lot of stuff that looks officious enough that will trick folks, especially those distracted or not well-versed in the attack vector.

[rho138]

> not well-versed in the attack vector.

Stochastic outputs that may not mesh with reality? xD