I am trying to register an account using certbot @api2 but facing following error in logs:
{
“type”: “urn:ietf:params:acme:error:invalidEmail”,
“detail”: “Error creating new account :: contact email “xyz@nic.in” has invalid domain : Domain name is an ICANN TLD”,
“status”: 400
}
I checked MX record and found those publicly available.
> dig +tcp +short nic.in MX
> 0 mailgw.nic.in.
How this error can be resolved as this domain has well-known email accounts which are widely used.
To me, this looks like an unintended side-effect of the way Boulder validates email addresses: It re-uses the same rules that were implemented in order to determine whether the CA is willing to issue a certificate for any DNS identifier.
Since this would require a code change to fix, I’ve filed https://github.com/letsencrypt/boulder/issues/4736 .
However, even if the issue is accepted, it would take at least 2 weeks to get into production, so for now, I would suggest just using a different email address. At a future point in time when the issue is resolved, you can update your ACME account to use your nic.in email.
Interesting thread this… Because as far as I can tell, all the SMTP RFCs (5321, 5322) require a FQDN as domain part in the address spec. (See section 5.1 “Locating the Target Host” of RFC 5321 and section 3.4.1 “Addr-Spec Specification” of RFC 5322.
And I’m not really an expert, but as far as I can tell (didn’t find a good RFC quote though) a FQDN is a host part + domain part + TLD part. So if you think about it, just a TLD can never be a FQDN?
Although probably the DNS system doesn’t care and e-mail system don’t care either, so it does work in practice. But should it be allowed to work?
Well, nic.in. isn't a tld, in. is, but nic.in. is the second level domain of the registry for in.
That's probably what the error message means.
a FQDN should be anything that ends with a dot (fully qualified... descending from root) in a dns zone 
The idea in the public suffix list is that nic.in IS a TLD, despite appearances.
But yeah, I can’t think of a good reason from the perspective of mail why it should matter.
public suffixes and tlds are different things. (LE I think will also refuse to issue certs for a public suffix, but the error message should be different)
Hm, seems specifically the case for nic.in if I read the PSL correctly: "Please note, that nic.in is not an official eTLD, but used by most government institutions.".
I'm wondering how domain names like .co.uk. are regarded. Strictly speaking the .uk. part is the TLD and .co. just a "generic domain" under the TLD, if I'm reading Wikipedia correctly.
Some tlds, like uk. up until recently, only allowed registration on the third level. That means uk. is still the tld, but co.uk. is a public suffix (and a second level domain)
There are 20 TLDs with MX records anyway (excluding 6 new gTLDs in testing). 
(And more with A or AAAA records that may or may not run mail servers.)
I agree with you.
Relating the original Boulder error (is "is an ICANN TLD" misleading or even incorrect?) and how the PSL is built,
The Public Suffix List is subdivided, using markers in the comments, into two sections, labelled as ICANN domains and PRIVATE domains.
ICANN domains are those delegated by ICANN or part of the IANA root zone database.
I think I have gotten lost somewhere, because nic.in (well, all the in SLDs) is listed in the ICANN section.
What does "delegated by ICANN" mean here? Because nic.in is surely not directly delegated in the IANA root zone database. 
.
Does nic.in appear in the ICANN section just because in does?
Also,
Apparently DMARC uses it!
No, it's been put there explicitly: https://publicsuffix.org/list/public_suffix_list.dat
// in : https://en.wikipedia.org/wiki/.in
// see also: https://registry.in/Policies
// Please note, that nic.in is not an official eTLD, but used by most
// government institutions.
in
co.in
firm.in
net.in
org.in
gen.in
ind.in
nic.in
ac.in
edu.in
res.in
gov.in
mil.in
Right, but why is nic.in in the ICANN section and not the private section?
The bit of text I quoted says that the ICANN section contains domains delegated by ICANN or are in the IANA root zone db.
(This is definitely me not understanding some basic facts, I’m just trying to figure out what they are 
)
https://publicsuffix.org/list/
The authorized registry may express further policies on how they operate the TLD, such as subdivisions within it.
and;
While some applications, such as browsers when considering cookie-setting, treat all entries the same, other applications may wish to treat ICANN domains and PRIVATE domains differently. For example, Certification Authorities checking for wildcard misissuance would not issue a ".com" wildcard cert ("com" is in the ICANN domains list) but could legitimately issue a ".appspot.com" wildcard cert to the domain owner, in this case Google ("appspot.com" is in the PRIVATE domains list).
Ahh, I guess so. Seemed very vague the first time I read it.
Although it’s irrelevant for this email thing, I wonder whether there’s any better wording for “is an ICANN TLD”, which doesn’t seem to be exactly right. Maybe “is an ICANN TLD or a registry-controlled suffix”, to borrow some of the language from the ISRG CP.
Ah, euh, well, I don't use DMARC.. 
At least, not actively. Perhaps my SpamAssassin uses it without me actively knowing about it..
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.