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 al

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