Allow ICANN TLDs as registration email domains

[aarongable]

We currently use the same logic to ensure that domain names are valid for certificate issuance and are valid for being the domain component of a subscriber's contact email address. However, we do not need to be as strict for email addresses: namely, it is possible for a subscriber to have an email whose domain component is exactly an ICANN TLD, while it is forbidden for us to issue a certificate to a name that is exactly an ICANN TLD.

Move the TLD logic out of ValidDomain and into its two callers: willingToIssue and ValidEmail. Slightly modify the logic in ValidEmail to not reject ICANN TLDs.

Fixes #5372
Fixes #4736

[aarongable]

Note to reviewers: I don't love this solution, because ValidDomain is exported and could be called by some other code which is expecting it to enforce this ICANN TLD restriction. Currently the only other caller is the new ratelimits code:

boulder/ratelimits/names.go

Lines 145 to 148 in 260bbab

	// validateDomain validates that the provided string is formatted 'domain',
	// where domain is a domain name.
	func validateDomain(id string) error {
	err := policy.ValidDomain(id)

Maybe we can find some other solution for that?

[jsha]

Yes it is technically possible to have an email domain that is exactly an ICANN TLD (notable I've heard of email addresses @ai). But I think this is exceedingly rare and not worth supporting. It increases the likelihood of accepting garbage email addresses without meaningfully improving the service. I vote to close.

[jprenken]

I agree it's not worth supporting newly added emails @ exact TLDs, but LE does have some legacy ones that made it into the DB before the check existed (#5372).

[aarongable]

Honestly I'm not concerned about us not sending emails to a tiny subset of folks that signed up long ago; they haven't been receiving emails for a long time and haven't complained about it. The only reason to do this imo is to prevent the "wait, but this is a real email address!" case during new registration.

I'm totally happy to not land this, I don't feel strongly either way. But then I think we should close both attached bugs as WontFix to make our stance clear.

[aarongable]

Closing in favor of #7220

[kansal15]

Yes it is technically possible to have an email domain that is exactly an ICANN TLD (notable I've heard of email addresses @ai). But I think this is exceedingly rare and not worth supporting. It increases the likelihood of accepting garbage email addresses without meaningfully improving the service. I vote to close.

We have nic.in and gov.in added in PSL but also have more than 3 Million email ids over nic.in/gov.in
without the support of email ids available over PSL , all these users will not be able to register for LE

[kansal15]

I agree it's not worth supporting newly added emails @ exact TLDs, but LE does have some legacy ones that made it into the DB before the check existed (#5372).

nic.in and gov.in are added in PSL but also have more than 3 million email ids over nic.in/gov.in

[kansal15]

Honestly I'm not concerned about us not sending emails to a tiny subset of folks that signed up long ago; they haven't been receiving emails for a long time and haven't complained about it. The only reason to do this imo is to prevent the "wait, but this is a real email address!" case during new registration.

I'm totally happy to not land this, I don't feel strongly either way. But then I think we should close both attached bugs as WontFix to make our stance clear.

kindly consider to re-open this issue as all domains who are added in PSL but are not TLDs, will not be able to use their email ids for LE registration including myself and all other GOV.IN and NIC.IN email ids.