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