There are a lot of names we should probably disallow either because they have reserved meanings or because they pose an unusual phishing risk.
"admin"-ish usernames (phishing risk):
rfc2142 reserved email addresses (in case we ever support receiving e-mail as email@example.com):
Addresses that some SSL CAs will use to verify ownership (bold = non-repeat, italic = repeat listed earlier) (I swear I am not making these up):
other commonly-used email addresses:
things specific to us (phishing risk):
For hostnames -- these are great ideas for things to block. Thanks; I was planning to get to this, just wasn't sure what to specifically block.
For email addresses -- we'll be letting individual hosts (e.g. asheesh.sandcats.io receive mail, since they'll hopefully have port 25 (SMTP) inbound open to them). Given that, I don't understand the purpose of the list of email addresses here. We could block the use of these email address names as hostnames, but that seems odd to me.
I think someday we may want people to be able to use firstname.lastname@example.org in addition to *@name.sandcats.io. Maybe I'm wrong and we'll never do that, but I don't think it hurts to block these things just in case.
+1, seems reasonable to me.
Apparently I just pinged @name. Sorry @name. (Looks like an inactive account anyhow.)
Updated with what I hope (but have no reason to believe) is a complete list of addresses used to verify ownership by various SSL CAs.
Block wpad, used for proxy autodiscovery in IE and several other browsers. While it's unlikely that someone will stuff a general-purpose web browser into a Sandstorm grain, it's not impossible (think Selenium), and you don't want it to fetch proxy autoconfig from whoever got wpad.sandcats.io.
Block isatap, used for IPv6 tunnel autodiscovery, for similar reasons, even though it's even more unlikely someone will stuff an IPv6 stack into a grain.
Block autoconfig, which is used in Thunderbird autoconfig if you try to set up sandcats.io email. While you're at it, if you do intend to support email@example.com email, reserve imap, pop, and pop3 as well as smtp.
Probably also worth blocking localhost, localdomain, and broadcasthost, as well as _tcp and _udp (if you allow underscores) so you don't have weird things happen with SRV records.
The CAs are locking down what they let people use for domain validation; there's currently a thread on mozilla.dev.security.policy on the subject. Compliant CAs aren't allowed to use anything other than administrator, admin, webmaster, hostmaster, or postmaster these days. But no harm a better-safe-than-sorry policy for those names.
Add test for blocking certain names
Block dangerous hostnames