Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Sun, 21 July 2019 18:01 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB9E120165 for <dmarc@ietfa.amsl.com>; Sun, 21 Jul 2019 11:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 RZisUq_hP5ab for <dmarc@ietfa.amsl.com>; Sun, 21 Jul 2019 11:01:08 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FE412015F for <dmarc@ietf.org>; Sun, 21 Jul 2019 11:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563732065; bh=N2ooXE3O2U0lMqaPelTweF+AbiQvGNjFW9GeLAH1jUw=; l=2184; h=To:References:From:Date:In-Reply-To; b=A/hxfR8SB/GFQa/7UJFmIC3ECMm91M+ZqdF44ysFvVWpllZHYsA1Uw+iqfOW9dKzp sXE/1BM49eM0ReUp3w4HSoC6hbz5Ns5fd7ZoqT3vAoOICuuvxYDM0878GpUBpWsHt9 s+qtEIPM74QkEhSbcUTZMEDDsBlC9obIgN1VJilVyqA/WG9F5k9Tx80HYAggc
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC07B.000000005D34A861.0000666B; Sun, 21 Jul 2019 20:01:05 +0200
To: dmarc@ietf.org
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <1808303.aIhlromXIS@l5580> <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com> <1692123.ljdY5SVR4M@l5580> <CAD2i3WPGWe8Z3av1Jua6sazsoStc7VTOLBve7psVo=K4VGTgig@mail.gmail.com> <D42C419C-F02E-4B5A-BB10-E8D49000349B@kitterman.com> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <855283a4-ece7-019b-f075-04eee82b0614@tana.it>
Date: Sun, 21 Jul 2019 20:01:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/VXqYB9XwbrCK98VtrkV1BX73RAI>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 18:01:10 -0000

On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote:
>>
>>> Keep in mind that senders do send from what we call non-existent domains for
>>> reasons that seem good and sufficient to them.  Let's take that as a fact,
>>> whether it makes sense to us or not.
>>
>>
>> Fair enough.  Let me quote the current spec:
>>
>> A.4.  Domain Existence Test
>>
>>   A common practice among MTA operators, and indeed one documented in
>>   [ADSP], is a test to determine domain existence prior to any more
>>   expensive processing.  This is typically done by querying the DNS for
>>   MX, A, or AAAA resource records for the name being evaluated and
>>   assuming that the domain is nonexistent if it could be determined
>>   that no such records were published for that domain name.
>>
>>   The original pre-standardization version of this protocol included a
>>   mandatory check of this nature.  It was ultimately removed, as the
>>   method's error rate was too high without substantial manual tuning
>>   and heuristic work.  There are indeed use cases this work needs to
>>   address where such a method would return a negative result about a
>>   domain for which reporting is desired, such as a registered domain
>>   name that never sends legitimate mail and thus has none of these
>>   records present in the DNS.
> 
> Yes, but that was for a different use case.  It was , AIUI, considered that
> reporting could be skipped on such 'non-existant' domains, but that proved
> problematic since such domains as these are used in mail.

Wasn't it for rejecting non-existent domains?  That is, IIRC, <sciencefiction>
as if there were a root DMARC record (_dmarc.) with np=reject.</sciencefiction>


> 'np' doesn't have the same issue.  It uses non-existence in a positive (do
> some processing) not a negative sense (reporting can be skipped for these),
> so the problems described in that paragraph are not only not relevant, the
> paragraph supports the case for 'np'.


Uh?  (I don't understand your parenthesized phrase...)


At any rate, the first paragraph gives a definition of non-existence equal to
the one we've been discussing these days, doesn't it?


Best
Ale
--