Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft
Douglas Foster <dougfoster.emailstandards@gmail.com> Thu, 09 February 2023 12:23 UTC
Return-Path: <dougfoster.emailstandards@gmail.com>
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 6E66EC14CE44 for <dmarc@ietfa.amsl.com>; Thu, 9 Feb 2023 04:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i6rLiuSdPFV for <dmarc@ietfa.amsl.com>; Thu, 9 Feb 2023 04:23:00 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EABC14F74E for <dmarc@ietf.org>; Thu, 9 Feb 2023 04:23:00 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id x29so1899015ljq.0 for <dmarc@ietf.org>; Thu, 09 Feb 2023 04:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=g1sLBfeawhzoA0NXOzzAX4N4sbD+GBHPGwBhU046HIY=; b=nYhxQ4959H4jqrYQ3QePrNFejy6zx+kXw0f1ix1sBy6mb4APmFWiuzd0kGtqQKMkbf gIbRf7vje8g8KM5hM/xGw+YdB7hcMNWq+9xj23uE1UoVt1BY3CV+JGFIq/UMRGtBuxdF fPIy1aSzU35xjeGANFPjy77TlrM17Dbn34JMAKmu/8nu5/b0iNIqzUCcrfKNTGn8FR4q V80HeuCGUyPMuBNk89E5qbMznGJGAFLr0ymDZK5O4lpUB1BDR2r1fVCh/e0tCEoeh+Fv HaUUF5Ehus6SpI8gh8ULAAqln5eawgJTHOXyKfOx5PewpB5BMEFi59aUmk2xXBYgDELc QgAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g1sLBfeawhzoA0NXOzzAX4N4sbD+GBHPGwBhU046HIY=; b=BrseQT4+eZwFOyQh3CXRG5ek5jpBSgpfsHk6Fju9IAqpEXrF81HFRR13QR22ZtnYd1 MZNYyWwsAf4O+u5OVKe+pMNk2AfapLybOlF+lGoat2DAZhtMD+6b/rveKUoQXLXSEbh1 MT77D4KyZGgz5rLv6fxTlswZFfs8PUhtCwbA2Lh2A+lMpVpeSNz9eLinr6k0u6N3YS74 +3mm+YqztMQgAWqwnkQ/QMZvGH5hgq+MCB5Maa7XTBCnwEprS07J6zjaiC/AzkrWtOtL Lwb/wynsSLu0iwV2P9IFkqn+gc6LSYH8VCoIZyojxkhKJYZsQJY7enRkWVhjAwTV0D3H ryBA==
X-Gm-Message-State: AO0yUKWp9nlhNInRfLLIaV6SabdwXejQaRkIhKQKPCeZzN69tNZyV36x irpFD6gwU/zJu874+wvrDfyRfQWhNhu1iHbEb6JMfLmh
X-Google-Smtp-Source: AK7set/1xwpUvLI7EZwN9pGrQqzq//5KelsyxUBcF8tMsqV3Ck6TDHvxfOauurMk+Ppi9gPMgyr5JtKSlNe7g9jjiPw=
X-Received: by 2002:a2e:b0f1:0:b0:293:3436:e698 with SMTP id h17-20020a2eb0f1000000b002933436e698mr79800ljl.183.1675945377840; Thu, 09 Feb 2023 04:22:57 -0800 (PST)
MIME-Version: 1.0
References: <11529029.Y877iPkkNG@zini-1880> <MN2PR11MB43510C0C3C2B94846144F102F7EA9@MN2PR11MB4351.namprd11.prod.outlook.com> <CABZJ8k=Rkh9+AoDA+N2tawU+GkizNRS-MG14sRayYHWBmFP62A@mail.gmail.com> <CAH48Zfy8eqoXhqEZCe8GGSDvTccYiBi0ETipfWRMvNuTEqy-_w@mail.gmail.com> <CAHej_8=mDe15Soyt-VN7Sb_==8ggXQPJ=8a9vkdC1-PYJS-PWg@mail.gmail.com> <CAH48ZfxKY7ZPo0K=SBQxr1frMPvijjR1wuw+xGZ7wbjNjvYZrg@mail.gmail.com> <CAH48Zfyn0gckyrjwmSjF_hMMVhJuCK0ipWq=7pUVzmwzRSfS9w@mail.gmail.com> <CAHej_8nZnFdM04Ss6kN+9BkGbB2gnLC4jn69xBKkoJv6Khk_Qw@mail.gmail.com> <CAH48Zfxz9vbGYhfM-23F+EyYwxpLJbrNy3xZ+ug-C8yyCE37cw@mail.gmail.com> <CAHej_8krE0atAx8-_cVqgm6LrVcuXyRyFctcwUOLdOCc_p-ajA@mail.gmail.com>
In-Reply-To: <CAHej_8krE0atAx8-_cVqgm6LrVcuXyRyFctcwUOLdOCc_p-ajA@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Thu, 09 Feb 2023 07:22:47 -0500
Message-ID: <CAH48ZfyBJ71nP6O8jNPbGMi7FRof+R7KdmXi2d8KV7C9cwZhtw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e8c09f05f4437060"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-HcuoY5J90I8E5o3J2uIRn70AMY>
Subject: Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 09 Feb 2023 12:23:04 -0000
Reject only occurs if DMARC fails. No disagreement there. NP only services a useful purpose it is is stricter than SP, So I assume that normal use will be SP=NONE, P=REJECT. Acceptable impersonation always uses a real email address, so this combination allows mailing lists and acceptable impersonations, without allowing malicious impersonations based on fake subdomains. This is a small potential benefit, if we assume that, in the absence of NP, spammers will attack a fake subdomain even though valid subdomains remain unprotected. On Tue, Feb 7, 2023 at 8:51 AM Todd Herr <todd.herr= 40valimail.com@dmarc.ietf.org> wrote: > On Mon, Feb 6, 2023 at 9:25 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> You actually summarize my points pretty well. Here are the three >> concepts: >> >> 1) People send mail with non-existent RFC5322.From domains (subdomains of >> existent domains) all the time, and that mail is wanted. >> >> Yes, that is my assertion based on research into my mail stream. I >> spent several months checking every From address for NXDomain, MX Exists, >> or A Exists. I found that none of these tests added any value; it was >> mostly an exercise for the benefit of this issue and this group. After a >> while, I stopped checking to reduce overhead. This is an assertion of >> fact, which I have presented several times. Every mail stream is >> different, so maybe someone else can present different data. But oddly, >> no one has presented other data, which makes me wonder if no one else can. >> >> Anyone can prove me wrong with more comprehensive data, or you can accept >> my results on blind faith, but you should not write text based on untested >> assumptions, when actual data will answer the question. >> >> 2) The NP=reject tag is useful when PSD=Y, when applied to the PSD+1 >> organizational domain only. >> >> Every organizatioin MUST be registered. Mail coming from an unregistered >> organization should be rejected. >> >> However, when a PSD's NP clause is applied to non-existent subdomains of >> an existent organization that has no DMARC record, the use is >> inappropriate. Based on #1, it is not only inappropriate but also likely >> to be wrong. With this limitation, PSD policies should always publish >> NP=reject. >> >> 3) The NP tag may be of interest to some organizations. >> >> Whether NP on organization policies is useful or not will depend on >> whether it is applied correctly or not. My expectation is that some >> organizations will publish NP=reject when they should not, causing false >> positives. I also expect that some organizations will publish NP=reject >> correctly, and the test will never fail because spammers are very unlikely >> to send using non-existent subdomains of registered domains. >> >> Assuming that there are exceptions to everything, perhaps someone can >> find some messsages that fits these characteristics. If so, we have to >> look at the signal-to-noise ratio between correctly blocked messages and >> incorrectly blocked messages. If the ratio is wrong, evaluators will >> disable the test anyway. >> >> Finally, I don't have any problem with the definition of non-existent. >> A domain or subdomain is non-existent if it returns NXDOMAIN. If the >> organization domain does not exist, any messages that use that domain >> should be blocked. If the organization domain does exist, I am >> unconcerned whether a particular subdomain exists. If someone wants to >> convince me that I should be concerned, I need data. >> >> > It's not clear to me that your understanding of the np tag matches mine, > so I'm going to ask a clarifying question or two. > > Do you believe that a DMARC policy record containing the tag "np=reject" > means: > > 1. If the RFC5322.From domain (which is necessarily a sub-domain of > the domain publishing the policy record) does not exist, then reject the > message, OR > 2. If the RFC5322.From domain (which is necessarily a sub-domain of > the domain publishing the policy record) does not exist AND the message > does not pass DMARC validation checks, then reject the message > > The current text for DMARCbis describes the np tag as choice 2 here, and > so I don't understand your contention that "some organizations will publish > NP=reject when they should not, causing false positives", because even a > domain so careless (in my opinion) as to permit mail to be emitted using > non-existent sub-domains while still publishing a DMARC policy record > should have things configured to ensure that such mail will pass DMARC > validation checks. A message using a non-existent From domain that also > fails DMARC validation checks where a prevailing DMARC policy exists seems > to me to be the epitome of unauthorized mail, so I don't see how rejecting > it would be a false positive. Can you help me understand why rejecting such > a message would be the wrong thing to do? > > -- > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* todd.herr@valimail.com > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [dmarc-ietf] PSD Related Privacy Considerations F… Scott Kitterman
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Scott Kitterman
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Brotman, Alex
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Emil Gustafsson
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Todd Herr
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Emil Gustafsson
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John R Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Emil Gustafsson
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John R Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Scott Kitterman
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Scott Kitterman
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Todd Herr
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Todd Herr
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… John R. Levine
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Scott Kitterman
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Todd Herr
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster
- Re: [dmarc-ietf] PSD Related Privacy Consideratio… Douglas Foster