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

Dave Crocker <dhc@dcrocker.net> Fri, 23 July 2021 16:35 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E4D3A0ACB for <emailcore@ietfa.amsl.com>; Fri, 23 Jul 2021 09:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeWzkNE0wtnq for <emailcore@ietfa.amsl.com>; Fri, 23 Jul 2021 09:35:40 -0700 (PDT)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9F53A0AD8 for <emailcore@ietf.org>; Fri, 23 Jul 2021 09:35:34 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 84680123815; Fri, 23 Jul 2021 16:35:32 +0000 (UTC)
Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-11-33.trex.outbound.svc.cluster.local [100.96.11.33]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 10951123804; Fri, 23 Jul 2021 16:35:31 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.11.33 (trex/6.3.3); Fri, 23 Jul 2021 16:35:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Wide-Eyed-Wide-Eyed: 25380ed079fdee22_1627058131755_4027949719
X-MC-Loop-Signature: 1627058131754:286386281
X-MC-Ingress-Time: 1627058131754
Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 1361910E99F4; Fri, 23 Jul 2021 16:35:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627058130; bh=MxWJ/4R3t6ydhXNSUjhXVzZ+eOaUOhKZF1PSXplE1tQ=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=enmU3tOSrofd1SCzu5iJpLapYs+my2coSvlEL6vcwz45jV3USlZcNc6Yb7gLgjPjb YpxU0au12QFjX08/V032UJnJr0mdSAujOCMhGu0GSHOii/myTYOFFvexpBKbhWTyXS 32PtwR4W6nPqSOdVV4ICibt0WmN+0k1zCW9QYA2KTz13+Z2lIj/TNFJL9Zkh3UlNiA dBIOjhGHG73RJepiFbjV34AbolWH9knTluU3iCf256SO7O981WA4TFEH1WWbRdk7TF X+jQs5A8EPyEKEaorst9YdZWNSFnRRSPuZwQpmCUk9OdyEZdpUKHMPxDh18GGTsk3A OJFShA7i+F1JQ==
Reply-To: dcrocker@bbiw.net
To: John C Klensin <john-ietf@jck.com>, dcrocker@bbiw.net, Alexey Melnikov <alexey.melnikov@isode.com>, emailcore@ietf.org
References: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> <f716d1fe-1a25-5c08-3046-95597ec1e279@dcrocker.net> <6DE94CD481CE96AAD9FFED7B@PSB>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <11162acc-85fe-0863-fb47-8c6365edf8e4@dcrocker.net>
Date: Fri, 23 Jul 2021 09:35:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <6DE94CD481CE96AAD9FFED7B@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/3xykFdh1BYDrlfM_8AlwJ-TRAUA>
Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2021 16:35:48 -0000

On 7/23/2021 9:21 AM, John C Klensin wrote:
> 
> 
> --On Friday, July 23, 2021 07:52 -0700 Dave Crocker
> <dhc@dcrocker.net> wrote:
> 
>> On 7/23/2021 7:38 AM, Alexey Melnikov 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?

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.



> 
> On a possibly-related topic, the DNSOP WG is considering
> proposals to officially allow private-use strings as top level
> domains. 

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

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net