Re: [dns-privacy] Last Call: <draft-ietf-dprive-rfc7626-bis-03.txt> (DNS Privacy Considerations) to Informational RFC

S Moonesamy <sm+ietf@elandsys.com> Fri, 24 January 2020 18:38 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A7120052; Fri, 24 Jan 2020 10:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
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 hZINi47HH7o5; Fri, 24 Jan 2020 10:38:28 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA412004C; Fri, 24 Jan 2020 10:38:28 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.146.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00OIcEX7003849 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2020 10:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579891107; x=1579977507; i=@elandsys.com; bh=0fKY6IWXNdIX9QTWxgyFgWZv2SZ0rYhkp04z2mJaWaY=; h=Date:To:From:Subject:In-Reply-To:References; b=j0TEv/eB873FIf9f3JnqgD2KczMzGus5djwFjDyqcw/cjLBDUDA/Z/ngrakiphe8j IP44plbxZd0w84xSoKB7LCraGtF6nSRvMFLFScYJRVd3MeazSahvevrx3xVDDU1Nbr XKmf+viS7HmMfVP4KrZPd/07r093F4fB79VB2G1A=
Message-Id: <6.2.5.6.2.20200124091818.081e6680@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 24 Jan 2020 10:37:54 -0800
To: Brian Haberman <brian@innovationslab.net>, draft-ietf-dprive-rfc7626-bis@ietf.org, dprive-chairs@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <4FEA964A-E161-4669-AA14-99EAE4A40DA5@sinodun.com>
References: <157412591286.14148.8912544206473080519.idtracker@ietfa.amsl.com> <6.2.5.6.2.20200101181705.081679d0@elandnews.com> <5C842DC4-0D89-4348-B810-9441F381B588@sinodun.com> <6.2.5.6.2.20200123054531.0be20578@elandnews.com> <4FEA964A-E161-4669-AA14-99EAE4A40DA5@sinodun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/0VdGwI-fOnCSmDKAOtuE84gHHBY>
Subject: Re: [dns-privacy] Last Call: <draft-ietf-dprive-rfc7626-bis-03.txt> (DNS Privacy Considerations) to Informational RFC
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 18:38:30 -0000

Hi Brian,
At 06:44 AM 24-01-2020, Sara Dickinson wrote:
>Thanks to Brian for his explanation on this point which I agree with.

Thanks, I see an explanation at 
https://mailarchive.ietf.org/arch/msg/dns-privacy/tr6ZNtxgScyDWwwyy3pUIpJxmY0 
I used the word "validation" as it would be generally understood in 
(IETF) discussions about mail protocols.  From a DNS perspective, it 
would be a DNS query.  Mail User Agents (MUA) generally do not 
perform DNS queries on the domain part of an email address.  The only 
exception I can think of is "direct-to-MX".  It is unlikely that 
sending an email directly to a mail server (identified by the MX RR) 
would work as outgoing TCP port 25 is usually blocked by Internet 
Service Providers.  In terms of IETF specification, the MUA sumbits 
email to a MSA (RFC 6409).  The DNS queries are intended to be 
performed by the MSA (not the MUA).

In my opinion, the case made in the second paragraph of Section 3.2 
does not match how the code works on the Internet.  I prefer to move 
on instead of pushing back on this issue as I spent more than enough 
effort on it.

For what it is worth, I preferred not to get into a discussion about 
the Introduction section of the draft.  If I am ever asked about the 
text, I will say that I disagreed with it as it is like looking down 
on Internet users ...

Regards,
S. Moonesamy