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
- [dns-privacy] Last Call: <draft-ietf-dprive-rfc76… The IESG
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… S Moonesamy
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… Stephane Bortzmeyer
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… S Moonesamy
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… Eric Rescorla
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… Sara Dickinson
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… S Moonesamy
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… Brian Haberman
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… Sara Dickinson
- Re: [dns-privacy] Last Call: <draft-ietf-dprive-r… S Moonesamy