So I think the only objection I have to this is the function naming. is_email_domain_in_list() is okay, but not great. It receives a full email address, but its name suggests it is not just checking only the email's domain, but also only receives the domain. I think we might be able to generalize it further. What about is_domain_in_list() that is allowed to receive an email address? If @ exists, we explode on it, otherwise, we just assume the whole string is the email. The reason for this is it could be potentially useful when whitelisting domains in the HTTP API, such as safe redirection and such. It would be nice to be able to do is_domain_in_list( 'make.wordpress.org', array( '*.wordpress.org', '*.wordcamp.org' ) ).
I don't actually care much about that, as much as I care that these are opposites:
- is_email_address_allowed(), which searches limited_email_domains
- is_email_address_unsafe(), which searches banned email domains
"unsafe" in is_email_address_unsafe() implies security, which is wrong. "allowed" does not strongly imply whitelisted.
The UI isn't even well thought out. It names the settings "Limited Email Registrations" and "Banned Email Domains", as if they are two unrelated settings, versus being direct opposites and more or less mutually exclusive? (I guess you could allow a domain but block a particular subdomain, like allowing *.school.edu (professors/administrators) but blocking students.school.edu.)
What about is_email_address_whitelisted() and is_email_address_blacklisted()? Should these be multisite-specific? ms_email_whitelisted() ms_email_blacklisted()?