Subject: [Emailcore] Ticket #50: Use of top level domains in SMTP

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Jul 2021 15:38:30 +0100

Dear WG participants,

I believe this was discussed on the mailing list, but after doing a 
quick mailing list search I couldn't find the discussion thread. But 
let's have a quick discussion of this.

I believe there was rough agreement in the past that use of top level 
domains is going to cause interop problems, as depending on context they 
might not be distinguishable from local hostnames. If people agree, I 
think the Applicability Statement draft should talk briefly about this.

Best Regards,

Alexey

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Jul 2021 07:52:59 -0700

> think the Applicability Statement draft should talk briefly about this.

Yes, as long as the language makes clear that the conflict is between an 
enhanced, standardized bit of functionality, with local, 
non-standardized functionality.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jul 2021 12:21:16 -0400

--On Friday, July 23, 2021 07:52 -0700 Dave Crocker
<[email-masked]> wrote:

>> I believe there was rough agreement in the past that use of
>> top level  domains is going to cause interop problems, as
>> depending on context they  might not be distinguishable from
>> local hostnames. If people agree, I  think the Applicability
>> Statement draft should talk briefly about this.

> Yes, as long as the language makes clear that the conflict is
> between an enhanced, standardized bit of functionality, with
> local, non-standardized functionality.

Dave,

I think I agree, but I'm not certain what you have in mind.
Could you, or someone else, elaborate a bit?

On a possibly-related topic, the DNSOP WG is considering
proposals to officially allow private-use strings as top level
domains.  If those proposals are approved, is it necessary to
add language to either the discussion of FQDNs in RFC5321bis
(noting that ticket #41 has been closed) or to add language to
the A/S to be clear that MTAs are expected to not let such
things escape onto the public Internet, just as they are
expected to prevent such addresses as example@local and
[email-masked] from escaping.

   best,
     john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Jul 2021 09:35:26 -0700

> Could you, or someone else, elaborate a bit?

Support for TLDs as FQDNs is standardized, albeit new.  Hence it can -- 
and should -- be within formal email standards specifications.

Support for local -- ie, private -- names is fully and completely 
outside formal email standards specifications.

There's nothing wrong with an operations-related specification noting 
the fact of private behaviors and possibly even offering commentary 
about their use.

There's quite a lot wrong with having a formal specification incorporate 
support for private behaviors, because it them makes those private 
behaviors part of the public, official specification.

So I'd guess it's fine to have language about this issue in the 
Applicability Statement, as long as it note that compliance to the 
standard requires giving precedence to legitimate, public domain names, 
which now includes TLDs.

> domains. 

So the wg chartered for DNS operations issues is going to modify the DNS 
protocol?

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jul 2021 13:55:55 -0400

--On Friday, July 23, 2021 09:35 -0700 Dave Crocker
<[email-masked]> wrote:

> Support for TLDs as FQDNs is standardized, albeit new.  Hence
> it can -- and should -- be within formal email standards
> specifications.
> 
> Support for local -- ie, private -- names is fully and
> completely outside formal email standards specifications.
> 
> There's nothing wrong with an operations-related specification
> noting the fact of private behaviors and possibly even
> offering commentary about their use.
> 
> There's quite a lot wrong with having a formal specification
> incorporate support for private behaviors, because it them
> makes those private behaviors part of the public, official
> specification.
> 
> So I'd guess it's fine to have language about this issue in
> the Applicability Statement, as long as it note that
> compliance to the standard requires giving precedence to
> legitimate, public domain names, which now includes TLDs.

Thanks.  I think we are in complete agreement.

> So the wg chartered for DNS operations issues is going to
> modify the DNS protocol?

I am trying to not have an opinion about that.  One
interpretation of what is going on would certainly reach either
that conclusion or that the propose to modify long-standing
principles on which both people and code had come to depend.
Another is that one or more clever tricks are being designed
that stay in conformance with the DNS protocols (whether or not
in conformance with standards on which the DNS, in practice,
depends and therefore it is ok.

But, if you (or anyone else here) are interested in those
issues, probably best to either follow them their or watch to
see if those proposal enter IETF Last Call and then comment.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2021 18:37:19 -0400

>non-standardized functionality.

Ever since Paul Hoffman and I published RFC 7085 in 2013 I've been doing surveys of what's
in the top level of TLDs.  There are currently 17 ccTLDs that have MX records at the top,
For most of them, even if you can persuade your MUA to send them mail, it doesn't actually
work.  GT. and TT. point their MX at Google, which I think is a surprise to Google.

So I agree, if you want to interoperate, the domain in an address has to have at least
two components.  I suppose Dave's point is correct, but that applies to just about anything
in any IETF standard.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2021 18:40:59 -0400

>[email-masked] from escaping.

I don't see why mail is special here.  Why is it any different
from a domain in a web page?

For that matter, if I send a message with mailto: adddresses in an
HTML body, or an attached PDF that includes javascript that shows
clickable e-mail addresses, some of which are local, how hard should
the MTA try to keep them from escaping? Let's not.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2021 18:44:08 -0400

>and should -- be within formal email standards specifications.

I hope you're not referring to things like .BANANAREPUBLIC (clothes)
or .DUCK (a toilet cleaner.)

The address n@ai has been around for at least a decade, and I think
if you can persuade your MUA to send it mail, it works, so it's not
that new.  But I still think it's a bad idea to expect undotted domains
in addresses to work, since that is a fairly significant incompatible change.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2021 20:24:37 -0400

>or .DUCK (a toilet cleaner.)

FYI, the DNS rules at ICANN for vanity domains are the same as the
rules for any other gTLDs. You cannot put an A or MX record at at the
apex of a vanity domain, same as you cannot put one at the apex of
.COM or .WTF.

The only TLDs with MX at the apex are a handful of ccTLDs, and as I said, most of those
don't actually work.

R's,
John