From nobody Sun Apr 4 03:00:22 2021 Return-Path: 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 9541A3A2051 for ; Sun, 4 Apr 2021 03:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 f8mkKv6cIxk6 for ; Sun, 4 Apr 2021 03:00:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 992C03A2052 for ; Sun, 4 Apr 2021 03:00:11 -0700 (PDT) Received: (qmail 66725 invoked by uid 100); 4 Apr 2021 10:00:10 -0000 Date: 4 Apr 2021 09:59:46 -0000 Message-ID: <20210404095946.66643.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 4 06:00:09 2021 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 10:00:18 -0000 Count | Bytes | Who ------------+----------------+------- 1 (50.0%) | 7328 (69.4%) | Murray S. Kucherawy 1 (50.0%) | 3229 (30.6%) | John Levine From nobody Mon Apr 5 00:37:20 2021 Return-Path: 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 2EC953A2D62 for ; Mon, 5 Apr 2021 00:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EYMmpSF5lgx for ; Mon, 5 Apr 2021 00:37:17 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6923A254F for ; Mon, 5 Apr 2021 00:37:17 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id u11so3359871uaw.2 for ; Mon, 05 Apr 2021 00:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AXdv94d95kZJLBsKdCgOaOnjKtCUQouHnlTWUKrgB6Y=; b=nLux6PshkizhTCgv2RaPG3tZtx0loDUqJQniLH6P18unF7ZHzWB69Q0ixB6QZYNuse vDDQBFHOqtem23ZulcfXXVxSnbvDm6AZSyUaUXg1C9r9HMCgsgbneZtkzDBATCcI4oVK KPrysNS0BMyIpGrqywv3cNw04tTJ0DUzH76vs5PFLctFe1BazPJMoaNYIUplFsSswW4K KT6FjPyEojeQZvbct1qwFzQRQKfYKz9WELHQZgi2E4CHyknhtrjC+Jk5j/2NPH7zW3IE nUl+2OMXHxc3YN0YYO883hrwdaYP9e39BY6++qq4XpncqmzFrW31o5AWmsUrKIn8dCwx PjEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AXdv94d95kZJLBsKdCgOaOnjKtCUQouHnlTWUKrgB6Y=; b=EM5a0KXz7BHgyXxiylZ0Z9aCkNvzuePr7sqEn5vXa8Pl6He8cTHe/jUfLKZBXW8xzv zbBwu/cNZC8jjk2xPZ1jzuT7ZRXN7Mw5zd1FTXBErE5yhCL7vHpeJibjZAg16awruK35 1xWEkuxIj44bzL+OXfsgAZeL6XL/4YlzsLKBZhYw8+BGB+KBNu4zvSfUahZazMO2gKoP UnaN6Uiz1S0fvt+oBPZNFBphlwCfVt2ASVmfHakGaNG/ZDnv+M5M062rAWZzcP790q0l 2e7y403tF9BVSVWBlKu72pyfVvZOHnJBf0adviX/Xt6yXn547Zzjvs6zepb2zh/kw6L7 b40w== X-Gm-Message-State: AOAM531UXIR72ujsNVi3drBvDcDrBvLoo/QMckSz3yxjtmoA624yGgMq LB7EGKhM//Jmeore4uebtf0uUx8cWaqRTUr52XeOnpqX X-Google-Smtp-Source: ABdhPJyqTNCm+PM/ULJss6ks5uPS5e6zbaKnvB9LFVaPx24RTePvxFG9q6zjy1YqLgIwdhTROCVlMapfZwDkSQvhnc0= X-Received: by 2002:ab0:e17:: with SMTP id g23mr6360603uak.87.1617608234323; Mon, 05 Apr 2021 00:37:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Apr 2021 00:37:02 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000031523405bf34c46d" Archived-At: Subject: Re: [dmarc-ietf] AD Evaluation: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 07:37:19 -0000 --00000000000031523405bf34c46d Content-Type: text/plain; charset="UTF-8" On Fri, Mar 19, 2021 at 9:35 AM Murray S. Kucherawy wrote: > And with that, I'll set up the Last Call. > Last Call has ended. Scott/Tim, please make whatever resulting edits are appropriate and let me know when it's ready for a telechat. I've marked it as "Revised I-D Needed". -MSK --00000000000031523405bf34c46d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000031523405bf34c46d-- From nobody Mon Apr 5 01:13:47 2021 Return-Path: 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 4857F3A2EE1 for ; Mon, 5 Apr 2021 01:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=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=gmail.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 q9udMBWXV6lK for ; Mon, 5 Apr 2021 01:13:42 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E649A3A2EDF for ; Mon, 5 Apr 2021 01:13:41 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id c4so10812825qkg.3 for ; Mon, 05 Apr 2021 01:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=2GyJja69ip242nVmRAP4yV17Bv/hQ+GhWtsLw+PzAME=; b=l4v7Oais1PT6xttsxbQn7ZpwIAk8/4yvjJKZp6wsk9oLA0l0TG4e3VmN1ZhdyTr8oh jVthPlDFexjyrQF5v8u2Yc5NjpGmePNJPiS2q+A04i2dHuxZBd/+3p9RbHhZjDNDPmdO rkro1+Yr3q4SCRa1TBrR02UrJloJuWOUE+bIPjRYvSkL+Tiq42Sv/pIBbanAYX/jTB6j Y0EIQR9iBewUO+XRcH8D/t7NNxneos9rmXfgUDDQzLqDfprAvUJeJ53MjF0FeDoaZF4V R3GXDlps6su/1pMfqphz8hafMai8Unmz/ttL7axFw7WsVo/WcrUg+bfxOUPuprt1V2SE sYGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=2GyJja69ip242nVmRAP4yV17Bv/hQ+GhWtsLw+PzAME=; b=LW/tLB2XnfP65Dzz4cbebbDchhWDBZlgJnMbwep+0C5GzV7K5h+JNG3HWDnr/u9CO4 E/w7FJr3sfhCnW8vUzFCQTcGQsAu7r17dINKr+k37o12mRHf6H0am4Y0qw5Vet4st3cR ctVa00feoy/wmCtl9AjZxgCUXRGieGu9GWI8F6LbhP7teqYO0WYhcfBD4xkIDTJkalA5 qHqJfZA5CLPfJLjPZo5JrtPqq/PnFZV/TOkfUx7Ksuu0zmMGFQfjcaVbQIyy23pet+NB /vLfCQc18vjKSYXk93MFbTRwN/5SUaDDMQs3EVyShEINrxk90nNs9G4ASuS57FMF1Pu8 u/RQ== X-Gm-Message-State: AOAM5303t1kz+DfIQVRtXcBniVCQucIJQe/6/ANY6kCluNAIrmOS1qyJ XTi246wgeBeQPPG0wnvsHpC6h8UKPVhZjQ== X-Google-Smtp-Source: ABdhPJwnbFsWoXkWquiH6qgnsPKfWJwy01YbkB8+sxWsW30agANmbzSO/AJd5ylCcgqktypEs1exrA== X-Received: by 2002:ae9:c011:: with SMTP id u17mr23791692qkk.2.1617610419480; Mon, 05 Apr 2021 01:13:39 -0700 (PDT) Received: from [192.168.1.89] (50-110-88-182.clbg.wv.frontiernet.net. [50.110.88.182]) by smtp.gmail.com with ESMTPSA id r7sm11774693qtm.88.2021.04.05.01.13.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Apr 2021 01:13:39 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-69404D78-3699-457B-A05D-F7E8B554F806 Content-Transfer-Encoding: 7bit From: tjw ietf Mime-Version: 1.0 (1.0) Date: Mon, 5 Apr 2021 04:13:36 -0400 Message-Id: References: Cc: IETF DMARC WG In-Reply-To: To: "Murray S. Kucherawy" X-Mailer: iPhone Mail (18D70) Archived-At: Subject: Re: [dmarc-ietf] AD Evaluation: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 08:13:46 -0000 --Apple-Mail-69404D78-3699-457B-A05D-F7E8B554F806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99ve got some I=E2=80=99ll commit in the am.=20 Sent from my iPhone > On Apr 5, 2021, at 03:37, Murray S. Kucherawy wrote:= >=20 > =EF=BB=BF >> On Fri, Mar 19, 2021 at 9:35 AM Murray S. Kucherawy = wrote: >=20 >> And with that, I'll set up the Last Call. >=20 > Last Call has ended. Scott/Tim, please make whatever resulting edits are a= ppropriate and let me know when it's ready for a telechat. I've marked it a= s "Revised I-D Needed". >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-69404D78-3699-457B-A05D-F7E8B554F806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99ve got some I=E2=80=99ll commit i= n the am. 

Sent from my iPhone

On Apr 5, 2021, at 03:37, Murray S. Kuch= erawy <superuser@gmail.com> wrote:

=EF=BB=BF
And with t= hat, I'll set up the Last Call.

Last C= all has ended.  Scott/Tim, please make whatever resulting edits are app= ropriate and let me know when it's ready for a telechat.  I've marked i= t as "Revised I-D Needed".

-MSK
=
_______________________________________________
dmarc m= ailing list
dmarc@ietf.org
https://www.ietf.= org/mailman/listinfo/dmarc
= --Apple-Mail-69404D78-3699-457B-A05D-F7E8B554F806-- From nobody Mon Apr 5 14:02:27 2021 Return-Path: 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 917463A27E6 for ; Mon, 5 Apr 2021 14:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud9KYt3XGsgs for ; Mon, 5 Apr 2021 14:02:23 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142003A27E5 for ; Mon, 5 Apr 2021 14:02:22 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id g20so664348vst.2 for ; Mon, 05 Apr 2021 14:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SQYr5aPYvE/MpRSqyjTvMyZgF/HxwrVEWDr80AVPHE0=; b=VUozeqUzvDHef4mttBeClQ6nVct5bVvoC+t2zUEAPe5FQDBbFYP+6LMxMnsAv7sQGw z0fxupa6u8vI/9F+aNIk3XNJ2OyIWj/rvcyC92fdV6SKRjmX80xw6g1mnB0geyuQqFaY HSfSTpHt4552jQGD49KyTRAzUnbZsTdNA+t/e1xNcfJnBVclY7rcPV1WUuoQZWELCtZN 1vosQFhELScCED4OUgTjGJQzoXjPewet80auvAd3rs1MOVh98be00hKpKN7sU1QdxCUd pL9HGC/ZZIMGal82iYRpsj0t2TH9h6gSfyFUrH5HTCYPcTc4QCpRW09i/oGqUC6IuD8/ oZMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SQYr5aPYvE/MpRSqyjTvMyZgF/HxwrVEWDr80AVPHE0=; b=Fnnxq12BMmC1pRGh7mpvybY98B+b3/azryLYlVnCYpk42oW7vkPSpZNN5C2ZKTWaDt 9oMHl3aGu4Dhi/b256d+bECoWbZAoIr3qGlQRaUqxxzwNQ1ZwK8VDIk9/wuzrCD2cyu6 6dLhP/kbDl+hwR/lDUtQG+CD4SkWJ1bB/dupp9flXVhR+Fb1Y0uNlT+O8Zrl5YB2xyuP IiFtiFc1zry/oPt1Yy8BrGwdJQLbX7brMlKuYRTKaOOFdrGzOkzrrmaXTspkNfQhj+k1 RfPXkPmo1BmvvjDpHKjURKCKi3BywO1SXNDXNta7raupcOwVZZkG/t/5p0JCSdS+ysml RjiQ== X-Gm-Message-State: AOAM533FycnAnUaPqkh5oxMsUltiIDeEeinkumaRrodF1h3xea+hQUla ET/M6Qo4aP3qsZunrXek1FhsecEQBm/JiB4L6pCvt+Vp6bk= X-Google-Smtp-Source: ABdhPJzIS8Q/kqTaj0jnqXyCUsZqFzoW1FRDjG1DzFPKirVsiM9UDTdJyncsjGNSpyxBJ26+5ZKknvx1cqyFZfpDIHs= X-Received: by 2002:a67:fb95:: with SMTP id n21mr14628404vsr.25.1617656540785; Mon, 05 Apr 2021 14:02:20 -0700 (PDT) MIME-Version: 1.0 From: Douglas Foster Date: Mon, 5 Apr 2021 17:02:16 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007b6dbb05bf400394" Archived-At: Subject: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 21:02:26 -0000 --0000000000007b6dbb05bf400394 Content-Type: text/plain; charset="UTF-8" As a result of earlier discussions, I have been investigating NXDOMAIN as an email filtering criteria. One question from those discussions was the best way to detect NXDOMAIN. I realized that I needed a query which specifically returns NXDOMAIN as a result, not simply the absence of a particular result. Additionally, a lookup on A/AAAA with results could represent either a domain name with no host segment, or a host segment and a parent domain.. Consequently, the best test seems to query for type=TXT, match=domainname. I have applied this rule to incoming RFC5322.MailFrom addresses and found the test to be useful. For my mail stream, 20% of the messages with SPF=NONE have this result because of NXDOMAIN. The percentages were roughly equal whether evaluating unique domain names or unique messages. While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is probably unwanted, NXDOMAIN has a higher probability of being unwanted. I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead. Is anyone else collecting data on NXDOMAIN, and able to share experience? --0000000000007b6dbb05bf400394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As a result of ea= rlier discussions, I have been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?

--0000000000007b6dbb05bf400394-- From nobody Mon Apr 5 14:46:36 2021 Return-Path: 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 6B72A3A294D for ; Mon, 5 Apr 2021 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=valimail.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 cR87GZ7fxIlJ for ; Mon, 5 Apr 2021 14:46:30 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB5E3A294C for ; Mon, 5 Apr 2021 14:46:30 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id j7so9709229qtx.5 for ; Mon, 05 Apr 2021 14:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tkMKEIYEBuIDU7Pj2s3HwRt2l1j88PaxuqB8wgd0vGM=; b=TBg7Lo+eoEHiIUTEDZGYLb12RRjpeStHTojkjBKCZgqs0EkbbOKOjmQw94BHGpp3DT 0FK52noWkIYrA2l0bw3yB4R1B4VHG7GfPijGGVYD1S8gjhRigE0eNU32Ftl+IgFtnBIR bSaqfuaT8HSpeIJ0AI7UzTaojxZEnD4aR0QOMhsdzgyYiiI1h1c/AAv4anRrTNnJvbe/ nFU+eHgNEmQ6W2FfXpK4+PItHL/FS1a++IO5FUtpGUOqKGmJKLFc48bGnpRWYoFt5JXZ N5auDJ8SWT4uwMMoW1ErXxgj7nYc7idM9BkxPgC/lmsSbZsgATQyf8kEzsvdrLkNIpo0 oErg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tkMKEIYEBuIDU7Pj2s3HwRt2l1j88PaxuqB8wgd0vGM=; b=DK/QlE0KmVsUokDqCL4wb8b153J3XMQ6QNSs7XkzjVpTwjsJz4+3cFag9gvhqFC5qF BBo3JQTQUll+85D+3gfmIchDgHxYTOzU7ogl/YFNLZ5vfPoG0pKqJGpfKzUvpwao/hwO ko+bvSLA40/+MX85at4ZTfFfCDAQn1L9Um6wgSUzYtXVtW67oquUDvYduEPQQw+FnWTi aOjyQC0stASRnYqUkyllHDRKpUC5dx8M3NWdR+3VbgHRvIugMNlWnI4HmnD2KdGvzYZk sWqEIGQZQP2ly8grpjCVbhLDao5GRCX0jbMizxy9oXIZwnRQb4Q0blf4H27h4B8miFgp G5AA== X-Gm-Message-State: AOAM5330OzCFJ6wxqdphbCQEYo2M7XrbZhKcmqe/anjWoFY7nlirEWUq FEB6Pai8DbNLIB2RGjF9hFpxw1bKF3apTnXKtJMMQw== X-Google-Smtp-Source: ABdhPJyzFC6BcZ82XE9wVjnfZ72+qvT5L3+TaRSdxCRqbasNfg6FiTwDtsQmwU6Zlajte0yc/SEcTm9gqsdSsXSbAw4= X-Received: by 2002:ac8:1385:: with SMTP id h5mr24910576qtj.298.1617659189288; Mon, 05 Apr 2021 14:46:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Mon, 5 Apr 2021 17:46:13 -0400 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000058751505bf40a1f0" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 21:46:35 -0000 --00000000000058751505bf40a1f0 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > As a result of earlier discussions, I have been investigating NXDOMAIN as > an email filtering criteria. > > One question from those discussions was the best way to detect NXDOMAIN. > I realized that I needed a query which specifically returns NXDOMAIN as a > result, not simply the absence of a particular result. Additionally, a > lookup on A/AAAA with results could represent either a domain name with no > host segment, or a host segment and a parent domain.. Consequently, the > best test seems to query for type=TXT, match=domainname. > > I have applied this rule to incoming RFC5322.MailFrom addresses and found > the test to be useful. For my mail stream, 20% of the messages with > SPF=NONE have this result because of NXDOMAIN. The percentages were > roughly equal whether evaluating unique domain names or unique messages. > > While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is > probably unwanted, NXDOMAIN has a higher probability of being unwanted. > > I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but > hope to get that done in the weeks ahead. > > Is anyone else collecting data on NXDOMAIN, and able to share experience? > I can share experience... Several jobs ago, when I was in position to set anti-spam policy for a mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domain lacked both an MX record and an A/AAAA record, that was enough for me to reject the mail on the grounds that I was unwilling to accept anything to which the recipient could not reply. I don't recall any complaints from my side of the transaction. I'm not sure I'd make the same decision based on the lack of an SPF record, especially for the RFC5322.From domain, since SPF is keyed to the RFC5321.From domain (or the EHLO name), and so I have no expectations that an SPF record will exist for the RFC5322.From domain. Even a lack of SPF for the RFC5321.From domain doesn't, for me, automatically rule out a message. I'd be more inclined to reject mail where the SPF record ended in "+all" than I would where there was no SPF record, because "+all" lands differently for me than does "no SPF record published". Both say that the domain owner doesn't care about SPF, but "+all" strikes me as overt disregard for SPF, while a lack of a record might just signal less hostility. Lack of an SPF record eliminates one possible path to a DMARC pass verdict, and a DMARC pass verdict allows me to treat the mail as authentic, and therefore worthy of treatment earned by previous authentic messages for the DMARC domain, which could be good or bad, depending on the history. Authenticated mail is not necessarily wanted mail; it's just mail for which I can be reasonably sure of the identity of the responsible party, and if that responsible party has a history of sending unwanted mail, then I can treat its authenticated mail as unwanted. If I can't determine if the mail is authentic, then I will treat it no better than, and perhaps worse than, the treatment earned by previous authentic messages for the DMARC domain, assuming any previous authentic messages exist. -- *Todd Herr* | Sr. Technical Program Manager *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. --00000000000058751505bf40a1f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

As a result of earlier discussions, I have been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?


I ca= n share experience...

Several jobs ago, when I was in position to set an= ti-spam policy for a mid-sized US-based cable ISP, if the RFC5321.From or R= FC5322.From domain lacked both an MX record and an A/AAAA record, that was = enough for me to reject the mail on the grounds that I was unwilling to acc= ept anything to which the recipient could not reply. I don't recall any= complaints from my side of the transaction.

I'm not sure I'd ma= ke the same decision based on the lack of an SPF record, especially for the= RFC5322.From domain, since SPF is keyed to the RFC5321.From domain (or the= EHLO name), and so I have no expectations that an SPF record will exist fo= r the RFC5322.From domain. Even a lack of SPF for the RFC5321.From domain d= oesn't, for me, automatically rule out a message. I'd be more incli= ned to reject mail where the SPF record ended in "+all" than I wo= uld where there was no SPF record, because "+all" lands different= ly for me than does "no SPF record published". Both say that the = domain owner doesn't care about SPF, but "+all" strikes me as= overt disregard for SPF, while a lack of a record might just signal less h= ostility.=C2=A0

Lack of an SPF record eliminates one possible path to a = DMARC pass verdict, and a DMARC pass verdict allows me to treat the mail as= authentic, and therefore worthy of treatment earned by previous authentic = messages for the DMARC domain, which could be good or bad, depending on the= history. Authenticated mail is not necessarily wanted mail; it's just = mail for which I can be reasonably sure of the identity of the responsible = party, and if that responsible party has a history of sending unwanted mail= , then I can treat its authenticated mail as unwanted. If I can't deter= mine if the mail is authentic, then I will treat it no better than, and per= haps worse than, the treatment earned by previous authentic messages for th= e DMARC domain, assuming any previous authentic messages exist.
=

--

Todd Herr= | Sr. Technical Program Manager
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 aut= horized recipient you are hereby notified of any use, disclosure, copying o= r distribution of the information included in this transmission is prohibit= ed and may be unlawful. Please immediately notify the sender by replying to= this email and then delete it from your system.

--00000000000058751505bf40a1f0-- From nobody Mon Apr 5 14:47:02 2021 Return-Path: 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 E7EC13A291B for ; Mon, 5 Apr 2021 14:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=gmail.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 vqPANJW1S4qy for ; Mon, 5 Apr 2021 14:46:57 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967F23A294D for ; Mon, 5 Apr 2021 14:46:57 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so12734663otn.1 for ; Mon, 05 Apr 2021 14:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NbalqFztUEGXV1Tl/5aCvI9n78wBzshlCugAmWU4yOM=; b=lnEbpORfirhP6Xbi+0qbDjz8l7WxUzSZw9OZw/pYxnUo6MHMPajWLbr+YFR4r2fEM+ xyF7r45W/6tHpofkIy8IuCDv9aVhp1Bz//78qXrImqUmgummVouhgSR1Nguv2I8SOTLW 0pmNRN7SaACpbvZQ8S24Xv6NxAgZS5B3KZUawyaDmHd3FLsYCKtX/y43h+M2GcrH5fCw 0aQKzpSeBEiVg5TA6HZTuKIxrKQ8S0Os+RJYhQA0ZozY5UrOeviy9yxxDWm9Ril++UGs LrPhjLl9ecaiEbRa8DqxeiGsxA0LM1fzcjVBskn0aPATYCC41LO0tO01RSWTMzrGPWEN kQCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NbalqFztUEGXV1Tl/5aCvI9n78wBzshlCugAmWU4yOM=; b=VeZOYNIEklsbQ8/HXEzhyAUnBMcrJmbAGVdemTFmPCNOh9DdjA2j0BKIDGo5UO1tPr iJ/yD2INJ6BjOksuG6I4Ig3/2XaQnSx4/+OUbR2K6NFr7B/5ESM1itIpRgIDotCrQunu ZS/fe/f3jZ90iOob1B/GHOIT/BMsom8gnJ5n16bjYjq2DG+OYRw2isgMvjIb2oX++8kO oPSSNmzeIlJXpUh43f0yU1xL25GE5xIqvN550o/Atm4Gps1XAiXFQqvILKmtN0dThaHK 83AL8HR4jheG6hJ2rX/cn1iowYaz18FJg+zKMLfodBuj6k8pwh3e1qu3UFkAnl/EhcGO 2XWg== X-Gm-Message-State: AOAM532J7Ue8s5tDeWqc5akwKxWsvTG5+rJwV8/ykrLszWsnPIGstpA7 GRs2U4CjG7v1XSgXLjEfrJ5Y9im780QSEeyPUPDkWO4hl8UBgg== X-Google-Smtp-Source: ABdhPJzzghJS6sR+rb0Ytz1g4TSkKFnldF+WwJbW/9PvctxOou9SE1w6IGCGY8Hmm3X4AX9KkL+XHOBTfE0B9ru3Z9s= X-Received: by 2002:a05:6830:240f:: with SMTP id j15mr24335188ots.288.1617659216117; Mon, 05 Apr 2021 14:46:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 5 Apr 2021 17:46:45 -0400 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f1c23c05bf40a2c5" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 21:47:02 -0000 --000000000000f1c23c05bf40a2c5 Content-Type: text/plain; charset="UTF-8" Can you point me to some of the tests you are running? you can do that offline. you also want to do some testing with domains signed with DNSSEC and those without. This came up as an issue in opendmarc: https://github.com/trusteddomainproject/OpenDMARC/issues/103#issuecomment-810036114 On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > As a result of earlier discussions, I have been investigating NXDOMAIN as > an email filtering criteria. > > One question from those discussions was the best way to detect NXDOMAIN. > I realized that I needed a query which specifically returns NXDOMAIN as a > result, not simply the absence of a particular result. Additionally, a > lookup on A/AAAA with results could represent either a domain name with no > host segment, or a host segment and a parent domain.. Consequently, the > best test seems to query for type=TXT, match=domainname. > > I have applied this rule to incoming RFC5322.MailFrom addresses and found > the test to be useful. For my mail stream, 20% of the messages with > SPF=NONE have this result because of NXDOMAIN. The percentages were > roughly equal whether evaluating unique domain names or unique messages. > > While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is > probably unwanted, NXDOMAIN has a higher probability of being unwanted. > > I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but > hope to get that done in the weeks ahead. > > Is anyone else collecting data on NXDOMAIN, and able to share experience? > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f1c23c05bf40a2c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you=C2=A0point me to some of the=C2=A0tests you are running? you can= do that offline.

you also want to do some testing with domains signed with DNSSEC and t= hose without.=C2=A0

This came up as an issue in opendmarc:

https://github.com/tr= usteddomainproject/OpenDMARC/issues/103#issuecomment-810036114





On Mon, Apr 5,= 2021 at 5:02 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

As a result of earlier discussions, I hav= e been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f1c23c05bf40a2c5-- From nobody Mon Apr 5 14:56:28 2021 Return-Path: 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 6CEF43A299D for ; Mon, 5 Apr 2021 14:56:27 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 3HcLOlE3r9iW for ; Mon, 5 Apr 2021 14:56:23 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 010CD3A299B for ; Mon, 5 Apr 2021 14:56:22 -0700 (PDT) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 135LuKvA018227 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Apr 2021 16:56:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1617659781; bh=+156nlwPYSilIKuBJVgOidrXJCyCawPGkiilNPjK+VQ=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=ArDZAiVbt5hXU5P5S/13DmuacVFpRsTeG+IanwLWLqryUjfNX7L08amovKBFj+zMr IGJheejDUU8GQIdYaT86bQsreZtLZXZ3u31ciY7dEm2VckHjf7e0aV6KkpsMZ8dOOJ IOYXZw8cG/DXLrqQsq12RAuRC57wyM0O8f8BEqYA= To: dmarc@ietf.org References: From: Grant Taylor Organization: TNet Consulting Message-ID: Date: Mon, 5 Apr 2021 15:56:22 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070907030601010001040706" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 21:56:27 -0000 This is a cryptographically signed message in MIME format. --------------ms070907030601010001040706 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/5/21 3:46 PM, Todd Herr wrote: > Several jobs ago, when I was in position to set anti-spam policy for a = > mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domai= n=20 > lacked both an MX record and an A/AAAA record, that was enough for me t= o=20 > reject the mail on the grounds that I was unwilling to accept anything = > to which the recipient could not reply. I'm surprised at requiring an /MX/ record. I still see email routed to=20 A / AAAA records for the domain when there isn't an MX record for said=20 domain. I wouldn't give your statement another thought if it was "an MX record=20 or an A record or an AAAA record". But /requiring/ an /MX/ record is a=20 toe stubber for me. --=20 Grant. . . . unix || die --------------ms070907030601010001040706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA/wgXwQl9mDHSg5enGHBeSMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTIwMTExNjAwMDAw MFoXDTIxMTExNjIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM6cGNMlSUFPM3zVw+ VgSslz2QRtMj+FerQ0DpmgbhUzqm5hMRe0hMA2OBf41HDAeOV0RKcLx2+HozHlyQST2xagOX xiv91aEXezh8bEBfnOI564Ej/JfusomfoM7ByVXcLp3K3fOssHos6IXiAD6WT+jcRs7Cg+Gl bYyoDLDLXw4i/N+YRcp3JrwT+4g/i//wAea1qTEd+ZnfcqtvCHaiJrr16xEpzuraLcmH5qtN /c+5kkRN3zpJvQvPX7fMBdxiSjb/cb070DC1RIO+THkhQqJ4bxHhrwcvC5RME0iwnSo52a/i FSNzciw/SM37F5tMTjDs+F6iUT85K2IWyGkpAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU9SQ1EWwdWU0yBrPcbiR81rwNThUwDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8v c2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5j b20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmww gYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEaZ3RheWxvckB0 bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBABWLZrz0NricNKP3jS03B7lH KNfBetFHWlaarCghIjhyA3yoXizPMP1wsY+ARMT22BKNVmLlP1CvDoLuEQbThvT5hRa7HPc2 2yVX6MkgSZByW2xrkhKGAIdtl+mELX27GZM+xe+k84OO1hA0Egyha2gg0UWlAiTGkIYjNLg0 6zg1QP7Bj4P/19hbi8Z9FFu38CztkgKZPSKMV3kPxZopa/mOWOQXxHcs03Ph/qnwj5HfkeWI WE7TARmmU7w8AoxEONC1tB6bsdX3M+4YVbgwgiihhiVGflHfGI4bgKkuN4sqesRnX8C9mvv5 o7dYJe4kKuv0ZeIj8x1Hh2PGvn7GuRgwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZP MA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEU MBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEu MCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODEx MDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExp bWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB /975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMa XqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpG EGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0 PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J 4K0AMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/ aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRo b3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRw Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVt MnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1G wmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrN xP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ 2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb5 33JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7 crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq 4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0 ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR 87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5Zgt wCLXgAIe5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg5enGHBeSMA0GCWCGSAFlAwQCAQUAoIIC VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MDUyMTU2 MjJaMC8GCSqGSIb3DQEJBDEiBCAzU9UMNP1l1ENjPwOkKK6uAs1Z+nwAW+hSi6BXwr5IZDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECED/CBfBCX2YMdKDl6cYcF5Iwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGW MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg 5enGHBeSMA0GCSqGSIb3DQEBAQUABIIBALwtdDAjC6w+t7Qh/+mbwMDpqyjDBaev1HWnX3tv hg1xb5x/AqnjL6EpKBtC+w3Girx59YrLvwbHNn4WQY0vhkyZHbNEojXCk1kXhlGtlVLkDGoS JO5XQpCRa/QzjKO0VquZWeowPNU8D3tguw5z6BfeABzRaw8kGSmzMU3VNHhI63Mfy5fv3v/U R+ASaxKQt/bLBOagiAOkto5acjxV7tmIuAmeJhcXqyt6wBwoAFuRQdzYitLx8zw1F07ZeRG5 vox+8w60ISphS0uuny9KKWYeC0xslA/5aUxIOOG9YfEFhyVu11JclgdXHZJnHoxs7hvlPGmu I/rgAf59TxUcfaEAAAAAAAA= --------------ms070907030601010001040706-- From nobody Mon Apr 5 15:08:25 2021 Return-Path: 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 B03553A29EC for ; Mon, 5 Apr 2021 15:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=valimail.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 uiUDJUTsa47K for ; Mon, 5 Apr 2021 15:08:18 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900533A29EE for ; Mon, 5 Apr 2021 15:08:18 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id q3so12969785qkq.12 for ; Mon, 05 Apr 2021 15:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=J9+4LBpoSYOlBEsAWzo7idXAIOGP5wtlaCG27BiQDn4=; b=M+0zTUWaRpNzZXWvujLNpwKq1Rz4wPn1s3ctcMfc0ZgtwF0cxB4NRyiMx1ZoA6ed2W a9fVVOrTc7lTUeXckvzjKPm68BYwx+Vl0DPwy6EWuo17rhnSW3CSiIvLkCbFwMeRV2lh RO3ECsa7JUF3Pyo4VTgOU7KO6cMlI271gHNqTn+sVNMjzJWp7U+7TcMtitdwn2LfIs9j dBPsotZFSlsUt7TxtqHGTOtpJim0/XedKA5EnjFi5G7VbZQl3wPHDSm1hTUJ1izMaaEN u+mxyhaE7npY6AmQ6KOCTRArDWdp/mmiZJUWQZHpKeOVFdqvJ0d6/Udne1QMdJQcXfyn qZBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=J9+4LBpoSYOlBEsAWzo7idXAIOGP5wtlaCG27BiQDn4=; b=T8rwEZ/HpTTy+6AsZde27HLniWfMIzDWd8EP9I7SrkPplkN1/2CZAEpYgfhqR/TLH6 ZZfd2CUuPQfp42sERCoFMRbT7qj0TpL0diAqQEiVFer6AsJSqLuzWGIoNTAiack2wwmd 7vf9XoRys/FANKV4QsANYa5eFhgYR7hklO76avMPd0h4jpJ5JeHCdrlk560g0drBcT+3 pElN4BDGSVC+Sdh/+JF+4iujREWISjsReLkpK+SyvO28KZ3/8TC9I8R6e9inN529zp9T Ru8TYFnsJUvLmcwcPdH1PncFcLwgVhaXKuHyQ4IXUmUUYIkdyAj9EYhuclOvnbaozxN5 uDag== X-Gm-Message-State: AOAM530IHXGqVbGm5nltuiKUxWMRvQ7EHOyh0Gu9m428AS+V2KlFkZv3 uRkFNJuvOIobaxCrza5xZSs59PzDg5MgwJFqSMZd45AEjuI= X-Google-Smtp-Source: ABdhPJyJ8Oy+jIJndC6gMOyAsZeMzetRkwxXwmN02amyM56CV3T9LKQ2Qs+e2DixDraaPyAGr5zAo3SIDfEIUsMD8cg= X-Received: by 2002:a05:620a:954:: with SMTP id w20mr26600340qkw.208.1617660496945; Mon, 05 Apr 2021 15:08:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Mon, 5 Apr 2021 18:08:01 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000049bbf905bf40ef77" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 22:08:24 -0000 --00000000000049bbf905bf40ef77 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 5, 2021 at 5:56 PM Grant Taylor wrote: > On 4/5/21 3:46 PM, Todd Herr wrote: > > Several jobs ago, when I was in position to set anti-spam policy for a > > mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domain > > lacked both an MX record and an A/AAAA record, that was enough for me to > > reject the mail on the grounds that I was unwilling to accept anything > > to which the recipient could not reply. > > I'm surprised at requiring an /MX/ record. I still see email routed to > A / AAAA records for the domain when there isn't an MX record for said > domain. > > I wouldn't give your statement another thought if it was "an MX record > or an A record or an AAAA record". But /requiring/ an /MX/ record is a > toe stubber for me. > > > It appears my phrasing was confusing, and for that I apologize. I did not require an MX record, per se; the requirement was that there be either an MX record or, failing that, an A/AAAA record. Either one was sufficient, but if neither existed, then the mail was rejected. -- *Todd Herr* | Sr. Technical Program Manager *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. --00000000000049bbf905bf40ef77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 5, 2021 at 5:56 PM Grant Taylor <gtaylor=3D40tnetconsulting.net@dmarc.= ietf.org> wrote:
On 4/5/21 3:46 PM, Todd Her= r wrote:
> Several jobs ago, when I was in position to set anti-spam policy for a=
> mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From doma= in
> lacked both an MX record and an A/AAAA record, that was enough for me = to
> reject the mail on the grounds that I was unwilling to accept anything=
> to which the recipient could not reply.

I'm surprised at requiring an /MX/ record.=C2=A0 I still see email rout= ed to
A / AAAA records for the domain when there isn't an MX record for said =
domain.

I wouldn't give your statement another thought if it was "an MX re= cord
or an A record or an AAAA record".=C2=A0 But /requiring/ an /MX/ recor= d is a
toe stubber for me.



It appears my phrasing= was confusing, and for that I apologize.

I did not require an MX record= , per se; the requirement was that there be either an MX record or, failing= that, an A/AAAA record.=C2=A0

Either one was sufficient, but if neithe= r existed, then the mail was rejected.

--

Todd Herr | Sr. Technical Program Manager
m: 703.220.4153

This email and all data transmitted with it contains confid= ential and/or proprietary information intended solely for the use of indivi= dual(s) authorized to receive it. If you are not an intended and authorized= recipient you are hereby notified of any use, disclosure, copying or distr= ibution of the information included in this transmission is prohibited and = may be unlawful. Please immediately notify the sender by replying to this e= mail and then delete it from your system.

--00000000000049bbf905bf40ef77-- From nobody Mon Apr 5 15:33:01 2021 Return-Path: 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 447073A2ABD for ; Mon, 5 Apr 2021 15:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=gmail.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 ZgOeZ6rkybKo for ; Mon, 5 Apr 2021 15:32:55 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64853A2AB9 for ; Mon, 5 Apr 2021 15:32:55 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id o4so2763151vka.12 for ; Mon, 05 Apr 2021 15:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CcaRXbfMghaxnLRrYzzI3X0Usr4Aek3bHn1bftPef4I=; b=MIjrJkARehvRFjYvhBU+o5B9MKVaCFPTuBPEX4xElXCobPpnEClKqTlgidyCa6bUtj iPbg5RcA9gHJR/gV/RiJrBwIrcflb85e1m5V9RiUB9/TI1skW3x/UJGfbF7OHoYxmxX6 VmZwId4sTjDlr3gQMKamV75twdIhlLabcSYf3EVqO3hKx46wHQgWFiTwof02eVxyPEjF lLkUm7tRQzmUCCdHWZYMHdtepGmdS1xksU3/8AifqVBWC7cbBt5WPzytyye7u3+qve7O lIwQabRuGAKos0a1V4+7UkGyhEAY28tsoU2nkzajtBKPjFP6RAf/3F2/Mh4kHKsifOON MuKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CcaRXbfMghaxnLRrYzzI3X0Usr4Aek3bHn1bftPef4I=; b=SElKivedBGOUCkEZLC4wurpmrfIKhqCyOW+i3cEv7BMrCr+6sSNY6tR1R+OxFyNpms UgQfOBIOqIhoOoQyf73B7pb1fvgNNHAvpiYXCU5dF85AIx3cd1OMUPc019w+gAU2Id9j JPV283v48ALlP763E6BqwD8cL2vL5Hu704IEVbUJVZDtaSX4z9KHNeR0WT7rMFvbQPaP 2rf1Wb8yD1AlBbk/kXCJIalhXylw9pb6HX+6HuV/6Tox25ZCbXsN12/tmcpS7nqzOyYj +p0IhXv1QqxIRSdutnuXESS7iS+GHi3sNxOd3bdEzY0g58jdPP3DKpBdbSD/mI6r38Qf BngA== X-Gm-Message-State: AOAM533tusDSiDtMUyTHNJpteVqqdAeic/B7NnVCoQcqjDetJ9jOTayS nT2zkZc2HaQDgAC9uXnG0aJGl+rowq9TX+9TVBE= X-Google-Smtp-Source: ABdhPJwRFquyjJLMGS0Kfhm46STNvIwl4qzY6vpg1ERfJXEa1XYBgBTLSqSl/S0YebHllPeX5oDAIK/71T7dk/lKeE4= X-Received: by 2002:ac5:c7c2:: with SMTP id e2mr15316575vkn.25.1617661973898; Mon, 05 Apr 2021 15:32:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Mon, 5 Apr 2021 18:32:40 -0400 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000052292b05bf4147f6" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 22:33:00 -0000 --00000000000052292b05bf4147f6 Content-Type: text/plain; charset="UTF-8" Please forgive my typo. I meant to say that I am currently testing RFC5321.MailFrom (only). (I am not doing evaluating any non-standard SPF algorithms.) On Mon, Apr 5, 2021, 5:46 PM Todd Herr wrote: > On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> As a result of earlier discussions, I have been investigating NXDOMAIN as >> an email filtering criteria. >> >> One question from those discussions was the best way to detect NXDOMAIN. >> I realized that I needed a query which specifically returns NXDOMAIN as a >> result, not simply the absence of a particular result. Additionally, a >> lookup on A/AAAA with results could represent either a domain name with no >> host segment, or a host segment and a parent domain.. Consequently, the >> best test seems to query for type=TXT, match=domainname. >> >> I have applied this rule to incoming RFC5322.MailFrom addresses and found >> the test to be useful. For my mail stream, 20% of the messages with >> SPF=NONE have this result because of NXDOMAIN. The percentages were >> roughly equal whether evaluating unique domain names or unique messages. >> >> While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is >> probably unwanted, NXDOMAIN has a higher probability of being unwanted. >> >> I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but >> hope to get that done in the weeks ahead. >> >> Is anyone else collecting data on NXDOMAIN, and able to share experience? >> > > I can share experience... > > Several jobs ago, when I was in position to set anti-spam policy for a > mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domain > lacked both an MX record and an A/AAAA record, that was enough for me to > reject the mail on the grounds that I was unwilling to accept anything to > which the recipient could not reply. I don't recall any complaints from my > side of the transaction. > > I'm not sure I'd make the same decision based on the lack of an SPF > record, especially for the RFC5322.From domain, since SPF is keyed to the > RFC5321.From domain (or the EHLO name), and so I have no expectations that > an SPF record will exist for the RFC5322.From domain. Even a lack of SPF > for the RFC5321.From domain doesn't, for me, automatically rule out a > message. I'd be more inclined to reject mail where the SPF record ended in > "+all" than I would where there was no SPF record, because "+all" lands > differently for me than does "no SPF record published". Both say that the > domain owner doesn't care about SPF, but "+all" strikes me as overt > disregard for SPF, while a lack of a record might just signal less > hostility. > > Lack of an SPF record eliminates one possible path to a DMARC pass > verdict, and a DMARC pass verdict allows me to treat the mail as authentic, > and therefore worthy of treatment earned by previous authentic messages for > the DMARC domain, which could be good or bad, depending on the history. > Authenticated mail is not necessarily wanted mail; it's just mail for which > I can be reasonably sure of the identity of the responsible party, and if > that responsible party has a history of sending unwanted mail, then I can > treat its authenticated mail as unwanted. If I can't determine if the mail > is authentic, then I will treat it no better than, and perhaps worse than, > the treatment earned by previous authentic messages for the DMARC domain, > assuming any previous authentic messages exist. > > -- > > *Todd Herr* | Sr. Technical Program Manager > *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. > --00000000000052292b05bf4147f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please forgive my typo.=C2=A0 I meant to say that I am cu= rrently testing RFC5321.MailFrom (only).=C2=A0=C2=A0

<= /div>
(I am not doing evaluating any non-standard SPF algo= rithms.)

On Mon, Apr 5, 2021, 5:46 PM Todd Herr <todd.herr@valimail.com> wrote:
On Mon, Apr 5, 2021 at 5:02 PM Dougl= as Foster <dougfoster.emailstandards@gmail.com> = wrote:

As a result of earlier discussions, I have been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?


I ca= n share experience...

Several jobs ago, when I was in position to set an= ti-spam policy for a mid-sized US-based cable ISP, if the RFC5321.From or R= FC5322.From domain lacked both an MX record and an A/AAAA record, that was = enough for me to reject the mail on the grounds that I was unwilling to acc= ept anything to which the recipient could not reply. I don't recall any= complaints from my side of the transaction.

I'm not sure I'd ma= ke the same decision based on the lack of an SPF record, especially for the= RFC5322.From domain, since SPF is keyed to the RFC5321.From domain (or the= EHLO name), and so I have no expectations that an SPF record will exist fo= r the RFC5322.From domain. Even a lack of SPF for the RFC5321.From domain d= oesn't, for me, automatically rule out a message. I'd be more incli= ned to reject mail where the SPF record ended in "+all" than I wo= uld where there was no SPF record, because "+all" lands different= ly for me than does "no SPF record published". Both say that the = domain owner doesn't care about SPF, but "+all" strikes me as= overt disregard for SPF, while a lack of a record might just signal less h= ostility.=C2=A0

Lack of an SPF record eliminates one possible path to a = DMARC pass verdict, and a DMARC pass verdict allows me to treat the mail as= authentic, and therefore worthy of treatment earned by previous authentic = messages for the DMARC domain, which could be good or bad, depending on the= history. Authenticated mail is not necessarily wanted mail; it's just = mail for which I can be reasonably sure of the identity of the responsible = party, and if that responsible party has a history of sending unwanted mail= , then I can treat its authenticated mail as unwanted. If I can't deter= mine if the mail is authentic, then I will treat it no better than, and per= haps worse than, the treatment earned by previous authentic messages for th= e DMARC domain, assuming any previous authentic messages exist.
=

--

Todd Herr | Sr.= Technical Program Manager
m: 703.220.4153

This email and all data transmitted with it contains confid= ential and/or proprietary information intended solely for the use of indivi= dual(s) authorized to receive it. If you are not an intended and authorized= recipient you are hereby notified of any use, disclosure, copying or distr= ibution of the information included in this transmission is prohibited and = may be unlawful. Please immediately notify the sender by replying to this e= mail and then delete it from your system.

--00000000000052292b05bf4147f6-- From nobody Mon Apr 5 17:06:55 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB07D3A2DA8; Mon, 5 Apr 2021 17:06:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley via Datatracker To: Cc: dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161766760964.377.5520471023381576197@ietfa.amsl.com> Reply-To: Dale Worley Date: Mon, 05 Apr 2021 17:06:49 -0700 Archived-At: Subject: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-11 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 00:06:50 -0000 Reviewer: Dale Worley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: review-draft-ietf-dmarc-psd-08 Reviewer: Dale R. Worley Review Date: 2020-04-05 IETF LC End Date: 2020-04-05 IESG Telechat date: not known Summary: This draft is ready for publication as a Experimental RFC The -11 version is far clearer (to the naive) than the -08 version. [END] From nobody Mon Apr 5 17:45:54 2021 Return-Path: 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 10CFC3A2EE7 for ; Mon, 5 Apr 2021 17:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=d2Xog8uc; dkim=pass (2048-bit key) header.d=taugh.com header.b=0CCLfSgb 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 PLPIb1nbul2W for ; Mon, 5 Apr 2021 17:45:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7F1733A2EE8 for ; Mon, 5 Apr 2021 17:45:46 -0700 (PDT) Received: (qmail 31528 invoked from network); 6 Apr 2021 00:45:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7b26.606baf38.k2104; bh=Em9UsyBFpqsVLaR4q8Fm3kwXq/Az5yXb/Mi7E8QHQQ4=; b=d2Xog8ucKqFl5ImoJFQTE8Fy+jPlK8okapYSRaQRxt9QrwZqFQs79FJ3lDs0sRnHhutb1g+j5TkQRk3+6xjLn6xaghqPraiV6maCk0roOacnEFAAaf0jsQpvfc9PZHWnVauW8BdUwWkp7/jvJ68/jPwVrBH9K0yZJbjATTjiUUyTZeZVw6GcVbYwMOlP6EXbgsVYvrqBvrBCqM9tNWDanebXu3dBMy6dMXyeMiRzGochqary8TGacU+/ixNCsUKPyZ7UlZM/e6DEi5i3xjHgJuqj6I9WTDV57QXRxCS3cs65uTHe0DnG0iZH+wRilDbtLRZ0a4t9zn5NrGBp/3bcew== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7b26.606baf38.k2104; bh=Em9UsyBFpqsVLaR4q8Fm3kwXq/Az5yXb/Mi7E8QHQQ4=; b=0CCLfSgbuiJkpm/JYqYBevpc8bYieu3acBw8euGxclV5Iz7dA6GCQ/NNrtdnhRmo/zDpIqfBNmU+132rREWLVU1HzdUC8H6CKopCj1hU6rVvUYnNeA9e6cg13l32pvaqzRDcganZ96ovX3jrM2A8ReaAgeyYjayz1+N/GqXlaBRcCbtisuh9fJyLpdGfJOvxGY5aakAhqV9bfQDmq9kP9E6w17DyDuqbyvY/dJDGbQyPL1kjfgyMDFu8lDE5/lWfEbxinCjdS0InI8xB+cjGQHC0KiQH16iEuZySE87SuI3JMT74o8mVR+NaG2Z7zO1BpfvUZ6mzXyrLdsIE5NnCUQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Apr 2021 00:45:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 563BC720C6A4; Mon, 5 Apr 2021 20:45:42 -0400 (EDT) Date: 5 Apr 2021 20:45:42 -0400 Message-Id: <20210406004543.563BC720C6A4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 00:45:52 -0000 It appears that Todd Herr said: >Several jobs ago, when I was in position to set anti-spam policy for a >mid-sized US-based cable ISP, if the RFC5321.From or RFC5322.From domain >lacked both an MX record and an A/AAAA record, that was enough for me to >reject the mail on the grounds that I was unwilling to accept anything to >which the recipient could not reply. I don't recall any complaints from my >side of the transaction. On my small system I have the same experience. Nobody sends mail that you want from nonexistent domains. >I'm not sure I'd make the same decision based on the lack of an SPF record, I certainly wouldn't. I get plenty of mail from addresses with no SPF record. I think some of it is even DKIM signed. R's, John From nobody Mon Apr 5 18:01:02 2021 Return-Path: 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 0090C3A301F for ; Mon, 5 Apr 2021 18:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 w4UQxLPv1SyL for ; Mon, 5 Apr 2021 18:00:56 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B164B3A301E for ; Mon, 5 Apr 2021 18:00:56 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id q4so1594969vsm.0 for ; Mon, 05 Apr 2021 18:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqK025hAj1YOFh2k7HIROuvwzulYMiF+C6Z5yHFz3iw=; b=pxRbGVQ+0+JJG4nqamc7TbbWzNFHAAYMbsPxWzHKlsroo7wDYrxpdFeUcELu4XwmMd YFnVIpd2RhAyLQHjPEHhtwV9dwCSQdBCSPRokvntJWtA+ZIj6lxdnLP3AlHjqHWDRCnB q+blElFQ37m+s+DUzYAsszsOJsbayaZRPURjNbWMnsons32udN6FSb9cTyZKMT6izNlG Q7F87/hT7b71S2Vwtm+5x62DIgtmkEKqJPBj4v6AEKcrbzB+LOBLd6WtyxXID/9Jh98p 4Kuk9r/3py6hgjZoikYoI5sFvx1z7p3y3wGIWJVdXrhZkJbWwIDtH0smmM/ON54pWw5C XB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XqK025hAj1YOFh2k7HIROuvwzulYMiF+C6Z5yHFz3iw=; b=hAmbqbgeIReo8mqWOzGmgIadlvGFq5jHyswYlDmX4XwbReDyCKJBROxevTfKM7bFPM ZLl5VoNfN56idZm33MowqPVJ9t7PmnXz66t08lK5H9tSZq5AkeNKkJd0PIHovVqeu8b4 Jvf/gDpZoq/7GRNDACy6F7AJl7K/ONTqc9GbDHotwUB/YLUgWNJ9dOBOZXhHzHYd9fEg K236ZqsYq26LwYiPaqxKSZRIguzNtCABF2MFXcCWZdVWGWsvU97K7JiCiLSo9RUwkAbs tVyevpJd3ia7BMz0VOLqcSl153MlK/Yit1OmVuD1noT+cqRMJEidFFW/I1UxG68RugID adgg== X-Gm-Message-State: AOAM5327TS/LhQXR2M1LtSmtzajnly8Wh00bINAV1yhXRjmTvXE/B7T5 eVq2JExcpnFJ+4bhnEtAYyipKiyLXmessrs3lzg= X-Google-Smtp-Source: ABdhPJy1wJrROHDH+hS+S16PUsNlPkast3EasFu5+dPk8opZFrfcIN5VirjhdCFzNFsnHvDKlPzyDWK1SXYw+RQygIs= X-Received: by 2002:a67:1ac4:: with SMTP id a187mr6804899vsa.15.1617670854395; Mon, 05 Apr 2021 18:00:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Apr 2021 18:00:43 -0700 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a3cb1605bf4358d3" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 01:01:01 -0000 --000000000000a3cb1605bf4358d3 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 5, 2021 at 3:08 PM Todd Herr wrote: > I did not require an MX record, per se; the requirement was that there be > either an MX record or, failing that, an A/AAAA record. > Given that this is what RFC 5321 Section 5.1 prescribes in terms of answering the question "Where should I try to connect to deliver this?", that seems like a sane thing to use as a test. -MSK --000000000000a3cb1605bf4358d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 5, 2021 at 3:08 PM Todd Herr = <todd.herr=3D40valimail= .com@dmarc.ietf.org> wrote:
I did not re= quire an MX record, per se; the requirement was that there be either an MX = record or, failing that, an A/AAAA record.

<= /div>
Given that this is what RFC 5321 Section 5.1 prescribes in terms = of answering the question "Where should I try to connect to deliver th= is?", that seems like a sane thing to use as a test.

-MSK
--000000000000a3cb1605bf4358d3-- From nobody Mon Apr 5 18:08:04 2021 Return-Path: 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 7C1B43A3053 for ; Mon, 5 Apr 2021 18:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2RiD2z6HL5T for ; Mon, 5 Apr 2021 18:08:00 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9496A3A3056 for ; Mon, 5 Apr 2021 18:08:00 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id u29so6898778vsi.12 for ; Mon, 05 Apr 2021 18:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oeSIFhe9TrsbJRJMHUyBlS1eQovgH8l9tTpM50kDVhg=; b=P7pudUbx3DHNx3qOgj8joQGqHjT4mT/ADuCQqoH97CdctmBfOlrlsUckJwQVw76422 voB3PJw2gnZK2gxNCmvltajCh/YfYHdUnENxMYq7EBLRwM5K3yPeD3t2eazr7Ylc5qfs 4dpmc0FkQUeKKzBDRfBIHgoitgAdcv7Jt4nuhzJZWmQZhPx4xCVH+YzMxuAz5aiSXEnF oV/69K9mqYoEpIzmBmY1qtFkRQqYPY4pP37lPySCbhs2pfSu/bu70wHGjSqwQGlfi5v3 0s6ne9VimHxmvsNYV4dDh/n+v/t3tyToZhpGk4vgNI9ka98kBClZTRui8jvh0M2Heu4c m94w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oeSIFhe9TrsbJRJMHUyBlS1eQovgH8l9tTpM50kDVhg=; b=NC7Y9JsSWgzM6gO/U6uhQ1ao4Lt6BiYNbB+BSU2b1kIqko8D0XbVX+V0UTlryRIr0/ Wv0ucqGFvK5rSEK01ihi1NxX6Ri3LTq4lcq8xT1gRxRYGaS3b0/0efd/rQQq0TCnUOb3 O1NLlc8pTvcnXAslX1Qe2/CkkJ9rpHcqw8YZGZiHofWtN5CZyk88gyE3LfN/xMg6ZCx6 jcUy/4kdEbrDqBdcteHYlKjMFc2NDZNLKaCLSr+Twe/25/kIBC8TRXjpUMkQaVAGqtCr JuoLQ7dg4VfJeFNoy2nEOi+oDvezv9xZE5vKtoDDzjN2BidM7TB1GBXwHUIT+C5eELHa ZxwA== X-Gm-Message-State: AOAM532jUdoalbelgTL/0PgqdY6jF+JZWl5e3+Xo9Mcl6m5PDJycbu6s Z29jbKCHF4ZXPxOUSXfH89Jl7s8Qn4JF1zCoxwE= X-Google-Smtp-Source: ABdhPJx3RdixvF7bObArvaLxedKjvOmSnzc4m7XxzCrIjU5mRTVy6q87K7bNez2vuebR9lY2uELlSL1X7enRMeO4WKk= X-Received: by 2002:a67:7952:: with SMTP id u79mr15502905vsc.54.1617671279248; Mon, 05 Apr 2021 18:07:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Apr 2021 18:07:48 -0700 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f68a6305bf437108" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 01:08:04 -0000 --000000000000f68a6305bf437108 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > As a result of earlier discussions, I have been investigating NXDOMAIN as > an email filtering criteria. > > One question from those discussions was the best way to detect NXDOMAIN. > I realized that I needed a query which specifically returns NXDOMAIN as a > result, not simply the absence of a particular result. Additionally, a > lookup on A/AAAA with results could represent either a domain name with no > host segment, or a host segment and a parent domain.. Consequently, the > best test seems to query for type=TXT, match=domainname. > > I have applied this rule to incoming RFC5322.MailFrom addresses and found > the test to be useful. For my mail stream, 20% of the messages with > SPF=NONE have this result because of NXDOMAIN. The percentages were > roughly equal whether evaluating unique domain names or unique messages. > > While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is > probably unwanted, NXDOMAIN has a higher probability of being unwanted. > > I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but > hope to get that done in the weeks ahead. > > Is anyone else collecting data on NXDOMAIN, and able to share experience? > Due to terminology pedantry, I'm having trouble understanding this. Someone please check my math here: If I ask for MX records for example.com, NXDOMAIN comes back as the response's error code not if there's no MX record for that name, but rather if there are no records of any kind for that name. On the other hand, if there's no MX but there is an A or AAAA, I'm going to get a success error code (NOERROR), but with an answer count of 0. So I don't know what "detect NXDOMAIN" means: Your DNS reply either has that error code, or it doesn't. If instead you're trying to determine whether a name can receive mail, at least according to DNS data, it seems to me you query one record type (MX) and see if you get >0 answers, 0 answers, or NXDOMAIN. If you got NXDOMAIN, you're done; there's no way to route this message. If you got 0 answers, you should query A and/or AAAA and send there. If you got >0 answers, now you have to resolve the names you got to addresses; assuming at least one of those resolves, you have someplace to send the message. This is what RFC 5321 says to do. I don't think querying TXT would tell you anything more. What am I missing? -MSK --000000000000f68a6305bf437108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 5, 2021 at 2:02 PM Douglas Fo= ster <dougfoster.= emailstandards@gmail.com> wrote:

As a result of earlier discussions, I hav= e been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?


Due to terminology pedantry, I'm having trouble understanding th= is.=C2=A0 Someone please check my math here:

If I ask for= MX records for example.com, NXDOMAIN co= mes back as the response's error code not if there's no MX record f= or that name, but rather if there are no records of any kind for that name.= =C2=A0 On the other hand, if there's no MX but there is an A or AAAA, I= 'm going to get a success error code (NOERROR), but with an answer coun= t of 0.

So I don't know what "detect NXDO= MAIN" means: Your DNS reply either has that error code, or it doesn= 9;t.

If instead you're trying to determine whe= ther a name can receive mail, at least according to DNS data, it seems to m= e you query one record type (MX) and see if you get >0 answers, 0 answer= s, or NXDOMAIN.=C2=A0 If you got NXDOMAIN, you're done; there's no = way to route this message.=C2=A0 If you got 0 answers, you should query A a= nd/or AAAA and send there.=C2=A0 If you got >0 answers, now you have to = resolve the names you got to addresses; assuming at least one of those reso= lves, you have someplace to send the message.=C2=A0 This is what RFC 5321 s= ays to do.

I don't think querying TXT would tell you = anything more.

What am I missing?

-MSK
--000000000000f68a6305bf437108-- From nobody Mon Apr 5 18:57:44 2021 Return-Path: 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 4B5C03A31D4 for ; Mon, 5 Apr 2021 18:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 PnzqbU2quTzB for ; Mon, 5 Apr 2021 18:57:37 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 D6E1E3A31D2 for ; Mon, 5 Apr 2021 18:57:37 -0700 (PDT) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 1361vZKJ026849 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Apr 2021 20:57:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1617674256; bh=XIpXozbhARFySRD8Gc24raE++OIzOFTqrtiMFUNbmCk=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=S47PbI3ItLA9y2J8ws9vEbHydAXbRhzXo/pH2ikNSNXVYhGgDDnipwIAhx3kZgdA5 ACFy70Yy1y5omeAKAsouc5tWTHYJfVTjPC8hdu2N4BKxi3+r94pl3CRKgjVsxPa7LG QEx+IZziLVtLMoQbFOHHuFyAvgoMIpLsN7hnhGdc= To: dmarc@ietf.org References: From: Grant Taylor Organization: TNet Consulting Message-ID: <2470efe9-b620-c397-ca11-c26066305025@spamtrap.tnetconsulting.net> Date: Mon, 5 Apr 2021 19:57:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010105060105010203050401" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 01:57:42 -0000 This is a cryptographically signed message in MIME format. --------------ms010105060105010203050401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/5/21 4:08 PM, Todd Herr wrote: > It appears my phrasing was confusing, and for that I apologize. Mistakes happen every day ending in "y". Thank you for clarifying. > I did not require an MX record, per se; the requirement was that there = > be either an MX record or, failing that, an A/AAAA record. >=20 > Either one was sufficient, but if neither existed, then the mail was=20 > rejected. ACK That's more like what I was thinking was the norm. Thank you for=20 clarification ~> confirmation. --=20 Grant. . . . unix || die --------------ms010105060105010203050401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA/wgXwQl9mDHSg5enGHBeSMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTIwMTExNjAwMDAw MFoXDTIxMTExNjIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM6cGNMlSUFPM3zVw+ VgSslz2QRtMj+FerQ0DpmgbhUzqm5hMRe0hMA2OBf41HDAeOV0RKcLx2+HozHlyQST2xagOX xiv91aEXezh8bEBfnOI564Ej/JfusomfoM7ByVXcLp3K3fOssHos6IXiAD6WT+jcRs7Cg+Gl bYyoDLDLXw4i/N+YRcp3JrwT+4g/i//wAea1qTEd+ZnfcqtvCHaiJrr16xEpzuraLcmH5qtN /c+5kkRN3zpJvQvPX7fMBdxiSjb/cb070DC1RIO+THkhQqJ4bxHhrwcvC5RME0iwnSo52a/i FSNzciw/SM37F5tMTjDs+F6iUT85K2IWyGkpAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU9SQ1EWwdWU0yBrPcbiR81rwNThUwDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8v c2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5j b20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmww gYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEaZ3RheWxvckB0 bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBABWLZrz0NricNKP3jS03B7lH KNfBetFHWlaarCghIjhyA3yoXizPMP1wsY+ARMT22BKNVmLlP1CvDoLuEQbThvT5hRa7HPc2 2yVX6MkgSZByW2xrkhKGAIdtl+mELX27GZM+xe+k84OO1hA0Egyha2gg0UWlAiTGkIYjNLg0 6zg1QP7Bj4P/19hbi8Z9FFu38CztkgKZPSKMV3kPxZopa/mOWOQXxHcs03Ph/qnwj5HfkeWI WE7TARmmU7w8AoxEONC1tB6bsdX3M+4YVbgwgiihhiVGflHfGI4bgKkuN4sqesRnX8C9mvv5 o7dYJe4kKuv0ZeIj8x1Hh2PGvn7GuRgwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZP MA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEU MBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEu MCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODEx MDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExp bWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB /975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMa XqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpG EGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0 PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J 4K0AMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/ aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRo b3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRw Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVt MnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1G wmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrN xP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ 2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb5 33JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7 crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq 4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0 ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR 87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5Zgt wCLXgAIe5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg5enGHBeSMA0GCWCGSAFlAwQCAQUAoIIC VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MDYwMTU3 MzdaMC8GCSqGSIb3DQEJBDEiBCCj3gZte1wZfkxMatsoInrTIZtBbGh/Ct6exZDs1bDvHDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECED/CBfBCX2YMdKDl6cYcF5Iwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGW MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg 5enGHBeSMA0GCSqGSIb3DQEBAQUABIIBAAV0v/OLxPNCwZMcpHzWUpQBlq1CzwYQOsHAgJNM N8l5nwzYHSIcoEuGYpc9cxw0hk43TS5pd4yC0P2MW2cNeW7l+e3mWp0xaSaaq+vB/aOCZMi7 kwOlSpkj+WAqVcHO5apd/e68+9AD7Ohk8tsOeZAqGmwnd6o1ASrqZ4mANfK6WgkSEI5ONmUu LKhLHVvoTaCNMbswFCQavSZNnr5EY4QaY0GgcnSeD0vDdwRDcIWCN5xvnD7+ayArqjxdNq7O /8DyMajAmsOqacm7xtiR9mCDTdHyPBmhWtNSAtZfOnuFIu4VHzuOcSrLsAPdaITyIaC8Fmdl hTTTrw6zSel01dwAAAAAAAA= --------------ms010105060105010203050401-- From nobody Tue Apr 6 01:41:09 2021 Return-Path: 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 D8A8F3A16EE for ; Tue, 6 Apr 2021 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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 (1024-bit key) header.d=wordtothewise.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 nlq-Poxh1T4L for ; Tue, 6 Apr 2021 01:41:03 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC73A16F3 for ; Tue, 6 Apr 2021 01:41:03 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id DDD589F149 for ; Tue, 6 Apr 2021 01:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1617698462; bh=Y4BFSRzXROtsIBcQSC+vvHONiYZOUC8513FJFm4YRKQ=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Z12Ep1a/D0/mKx4f4Gry4fi1kJrEywloex1/hqPzPzCSI2cq4Vr/NwVFD+TpzgknK QLlr8gZW1p9IYhsTwtwURFoYUkSL1h6MuF+rj+JnSCqByStilJEIHEs/F6RVY20LMu lVx2VwMuqpG3RiHu3y30nqNpq+pAs3o0kyCmCWHI= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_3287C9D6-BFEC-476A-9B6D-4263ACBD0BF3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 6 Apr 2021 09:40:59 +0100 References: To: IETF DMARC WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 08:41:08 -0000 --Apple-Mail=_3287C9D6-BFEC-476A-9B6D-4263ACBD0BF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Apr 2021, at 22:46, Todd Herr = wrote: >=20 > On Mon, Apr 5, 2021 at 5:02 PM Douglas Foster = > wrote: > As a result of earlier discussions, I have been investigating NXDOMAIN = as an email filtering criteria. >=20 > One question from those discussions was the best way to detect = NXDOMAIN. I realized that I needed a query which specifically returns = NXDOMAIN as a result, not simply the absence of a particular result. = Additionally, a lookup on A/AAAA with results could represent either a = domain name with no host segment, or a host segment and a parent = domain.. Consequently, the best test seems to query for type=3DTXT, = match=3Ddomainname. >=20 > I have applied this rule to incoming RFC5322.Mail=46rom addresses and = found the test to be useful. For my mail stream, 20% of the messages = with SPF=3DNONE have this result because of NXDOMAIN. The percentages = were roughly equal whether evaluating unique domain names or unique = messages. =20 >=20 > While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the = message is probably unwanted, NXDOMAIN has a higher probability of being = unwanted. >=20 > I have not yet begun evaluating NXDOMAIN on the RFC5322.=46rom = address, but hope to get that done in the weeks ahead. =20 >=20 > Is anyone else collecting data on NXDOMAIN, and able to share = experience? >=20 >=20 > I can share experience... >=20 > Several jobs ago, when I was in position to set anti-spam policy for a = mid-sized US-based cable ISP, if the RFC5321.=46rom or RFC5322.=46rom = domain lacked both an MX record and an A/AAAA record, that was enough = for me to reject the mail on the grounds that I was unwilling to accept = anything to which the recipient could not reply. I don't recall any = complaints from my side of the transaction. >=20 > I'm not sure I'd make the same decision based on the lack of an SPF = record, especially for the RFC5322.=46rom domain, since SPF is keyed to = the RFC5321.=46rom domain (or the EHLO name), and so I have no = expectations that an SPF record will exist for the RFC5322.=46rom = domain. There is a huge amount of dis- and mis-information about SPF for the = 5322.from domain. Many, and I mean an embarrassingly high number of = =E2=80=98many=E2=80=99, ESPs actually suggest that their customers = publish include: _spf.espdomain.example in their 5322.from domain TXT = record. This eventually causes operational issues due to more than 10 = DNS lookups.=20 Some of this was done because the ESP folks don't understand the SPF = spec. But some of this was done because a large ISP decided to check SPF = records on the 5322.from domain and delivery would suffer if there was = no SPF.=20 Misapplying SPF to the 5322.from is a bad idea and only compounds = mistakes of the past.=20 > Even a lack of SPF for the RFC5321.=46rom domain doesn't, for me, = automatically rule out a message. I'd be more inclined to reject mail = where the SPF record ended in "+all" than I would where there was no SPF = record, because "+all" lands differently for me than does "no SPF record = published". Both say that the domain owner doesn't care about SPF, but = "+all" strikes me as overt disregard for SPF, while a lack of a record = might just signal less hostility.=20 I agree with the sentiment here. Lack of any SPF record, particularly = for small and non-bulk mail, simply means someone stood up a mailserver = (or started using a service) without fully setting it up. That could be = a mistake, or intentional, or malicious and experience tells us all of = those are possible. Contrast that with a +all record, where experience = tells us that is usually malicious. I actually found a +all in the wild = in the past few weeks. It was in the process of investigating a = client=E2=80=99s customer due to suspected spam. The +all was yet more = confirmation that the customer was a spammer (as if the swedish = hashbusting text and CAN SPAM violations weren=E2=80=99t enough).=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_3287C9D6-BFEC-476A-9B6D-4263ACBD0BF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5 Apr 2021, at 22:46, Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> = wrote:

On Mon, Apr = 5, 2021 at 5:02 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

As = a result of earlier discussions, I have been investigating NXDOMAIN as an email filtering criteria.

One = question from those discussions was the best way to detect NXDOMAIN.  I realized that I needed a query which = specifically returns NXDOMAIN as a result, not simply the absence = of a particular result.   Additionally, a lookup on A/AAAA = with results could represent either a domain name with no host segment, or a host segment and a parent domain..   = Consequently, the best test seems to query for type=3DTXT, match=3Ddomainname.

I = have applied this rule to incoming RFC5322.MailFrom addresses and found the test to be useful.  For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.  The percentages were roughly equal whether = evaluating unique domain names or unique = messages.  

While= both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, = NXDOMAIN has a higher probability of being unwanted.

I = have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.    =

Is = anyone else collecting data on NXDOMAIN, and able to share = experience?


I can share = experience...

Several = jobs ago, when I was in position to set anti-spam policy for a mid-sized = US-based cable ISP, if the RFC5321.=46rom or RFC5322.=46rom domain = lacked both an MX record and an A/AAAA record, that was enough for me to = reject the mail on the grounds that I was unwilling to accept anything = to which the recipient could not reply. I don't recall any complaints = from my side of the transaction.

I'm not = sure I'd make the same decision based on the lack of an SPF record, = especially for the RFC5322.=46rom domain, since SPF is keyed to the = RFC5321.=46rom domain (or the EHLO name), and so I have no expectations = that an SPF record will exist for the RFC5322.=46rom = domain.

There is a huge amount of dis- and mis-information = about SPF for the 5322.from domain. Many, and I mean an embarrassingly = high number of =E2=80=98many=E2=80=99, ESPs actually suggest that their = customers publish include: _spf.espdomain.example in their 5322.from = domain TXT record. This eventually causes operational issues due to more = than 10 DNS lookups. 

Some of = this was done because the ESP folks don't understand the SPF spec. But = some of this was done because a large ISP decided to check SPF records = on the 5322.from domain and delivery would suffer if there was no = SPF. 

Misapplying SPF to the = 5322.from is a bad idea and only compounds mistakes of the = past. 

Even a = lack of SPF for the RFC5321.=46rom domain doesn't, for me, automatically = rule out a message. I'd be more inclined to reject mail where the SPF = record ended in "+all" than I would where there was no SPF record, = because "+all" lands differently for me than does "no SPF record = published". Both say that the domain owner doesn't care about SPF, but = "+all" strikes me as overt disregard for SPF, while a lack of a record = might just signal less = hostility. 

I agree with the sentiment here. Lack of any SPF = record, particularly for small and non-bulk mail, simply means someone = stood up a mailserver (or started using a service) without fully setting = it up. That could be a mistake, or intentional, or malicious and = experience tells us all of those are possible. Contrast that with a +all = record, where experience tells us that is usually malicious. I actually = found a +all in the wild in the past few weeks. It was in the process of = investigating a client=E2=80=99s customer due to suspected spam. The = +all was yet more confirmation that the customer was a spammer (as if = the swedish hashbusting text and CAN SPAM violations weren=E2=80=99t = enough). 

laura 

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_3287C9D6-BFEC-476A-9B6D-4263ACBD0BF3-- From nobody Tue Apr 6 04:54:25 2021 Return-Path: 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 896183A1E1D for ; Tue, 6 Apr 2021 04:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Occeq7yGFg for ; Tue, 6 Apr 2021 04:54:14 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD22B3A1DFD for ; Tue, 6 Apr 2021 04:54:14 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id r8so4523500ual.9 for ; Tue, 06 Apr 2021 04:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9mf4a4bHwaXEZETHWFMPPSC9YfqVjlK6aLRHNE6eWQE=; b=JFkTKg3Sxuz/yPPwiUyQFrKjj5mj1KxK0IxoZwhrKhQfdxQ2nNIzEAwh+cogPYhnnA 23j6Wapz2in/jnLXGYjBUrEUnCgZEQtGvop6PNCDzAYWpub200AEeP0QuafcNYEGxc6N NGVwVQAl/JYTokdyHX0L33QnQzIe6vem6Wxah3d2x6yrIy4H1YJ/aNYbKZHfU3Y7Qh5g qJfGzVfBpim3fqLqjKM+uIHQpMnJ6OQkpkg9++Y6tXISBAJXWBzUeHdnoIaOaXijYtZK 1ObJEv7Wqq079Ykki2a1RV0Eqt/NJwK8EaFanB4whuOSl0+wuH4SKOpCsB0dTwDy3FVh E3AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9mf4a4bHwaXEZETHWFMPPSC9YfqVjlK6aLRHNE6eWQE=; b=EnfpQiluM72831LOnT2tMFHaPio6gY1ZKmSttJiT5u+fOkeU8GZejsFzKPrly9+ua9 Otwxmdbht2N2x+koNwo+c+wg42o4ULoT8tsSGRwR7XOEk+BWYDbuCMEVAkcG+zgYxqwn luKUP2ckIdifvlZamXbQg3B5eQ37kdqNzlVW37TtFdfA3pUjH8n/NINJ+2Ixa+LA4C1F 05trKM2Xtb/wI2Gw2IMV01zfq8B5n/wO+N+aNbchNiHJ1Ik72pAyYfWCPpLLhFa5sMhU uL4opkyKwqP3EIWw+1l+fwXhoqwtVVHrJKNR34Yr+TTHx0QceLnCsHW+v/OylSThTzdU SZlA== X-Gm-Message-State: AOAM530dZUQLOBsjhTwF+dNE2rjm8xyVePHhuUFdopy7+dCxYgCqiBfe rx/ZKhNXhoDwQD4geibmo2vnmxBhFv00tVjQm9E= X-Google-Smtp-Source: ABdhPJyGr0Hg7m5KQJQV2wAFF5ylWlnT+bqSWOtCm6GDLmLYIyQhZXSlwnqSuCcGGOAFIgam85QX7Ey4+Wd7zmaffEw= X-Received: by 2002:ab0:45ae:: with SMTP id u43mr41971uau.109.1617710052794; Tue, 06 Apr 2021 04:54:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Tue, 6 Apr 2021 07:54:09 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000be47205bf4c79fd" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 11:54:21 -0000 --0000000000000be47205bf4c79fd Content-Type: text/plain; charset="UTF-8" No typo. I was looking to do better than SPF NONE, and NXDOMAIN was the first thing that came to mind. If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with all the information needed to make a decision. (The sender is violating ICANN name registration policies). Ignoring NXDOMAIN and continuing to look for MX/A/AAAA is a waste of information and a waste of resources. But clearly, the norm in this group is to check MX/A/AAA because it seems likely to be a more powerful filter. I wonder if that is actually true. 1) A/AAAA is a pretty weak test, since many domains have A/AAAA records on the domain name for web purposes. 2) Existing domain names that are being used for attacks are likely to have an MX record, if for no other reason than updating a LetsEncrypt certificate. Will someone collect data on frequency that a domain fails MX/A/AAA when the domain exists? Additionally, the connection between mail sending (SPF) and mail receiving (MX/A/AAAA) seems tenuous to me. Well-run domains do not send automatic messages to unauthorized return paths, for fear of backscatter. Many domains seem to discard incoming automatic messages, either for fear of attack or because the reply is too hard to integrate into automated systems. I do respond to SPF NONE by applying a best-guess SPF policy which includes MX and A, and sometimes produces SPF PASS. But I no longer do that for non-existent domains. I can imagine collecting MX and A existence data while evaluating the default SPF policy, but I worry about the complexity of doing so, and doubt the benefit. Doing it as a separate step is easy enough, but adds unwanted overhead. Overall, we have these result partitions for domains with SPF NONE: 1) Domain does not exist, NXDOMAIN 2) Domain exists but MX/A/AAAA do not exist 3) Domain exists and MX/A/AAAA exist but do not validate the source IP 4) Domain exists and source IP can be validated with MX/A/AAAA, producing an inferred SPF PASS. I want to be convinced that result #2 is a non-trivial volume of messages. If #2 is a trivial volume, then there is no loss from combining it with #3, which makes the extra MX/A/AAAA test unnecessary Convince me. Doug. On Mon, Apr 5, 2021, 9:07 PM Murray S. Kucherawy wrote: > On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> As a result of earlier discussions, I have been investigating NXDOMAIN as >> an email filtering criteria. >> >> One question from those discussions was the best way to detect NXDOMAIN. >> I realized that I needed a query which specifically returns NXDOMAIN as a >> result, not simply the absence of a particular result. Additionally, a >> lookup on A/AAAA with results could represent either a domain name with no >> host segment, or a host segment and a parent domain.. Consequently, the >> best test seems to query for type=TXT, match=domainname. >> >> I have applied this rule to incoming RFC5322.MailFrom addresses and found >> the test to be useful. For my mail stream, 20% of the messages with >> SPF=NONE have this result because of NXDOMAIN. The percentages were >> roughly equal whether evaluating unique domain names or unique messages. >> >> While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is >> probably unwanted, NXDOMAIN has a higher probability of being unwanted. >> >> I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but >> hope to get that done in the weeks ahead. >> >> Is anyone else collecting data on NXDOMAIN, and able to share experience? >> > > Due to terminology pedantry, I'm having trouble understanding this. > Someone please check my math here: > > If I ask for MX records for example.com, NXDOMAIN comes back as the > response's error code not if there's no MX record for that name, but rather > if there are no records of any kind for that name. On the other hand, if > there's no MX but there is an A or AAAA, I'm going to get a success error > code (NOERROR), but with an answer count of 0. > > So I don't know what "detect NXDOMAIN" means: Your DNS reply either has > that error code, or it doesn't. > > If instead you're trying to determine whether a name can receive mail, at > least according to DNS data, it seems to me you query one record type (MX) > and see if you get >0 answers, 0 answers, or NXDOMAIN. If you got > NXDOMAIN, you're done; there's no way to route this message. If you got 0 > answers, you should query A and/or AAAA and send there. If you got >0 > answers, now you have to resolve the names you got to addresses; assuming > at least one of those resolves, you have someplace to send the message. > This is what RFC 5321 says to do. > > I don't think querying TXT would tell you anything more. > > What am I missing? > > -MSK > --0000000000000be47205bf4c79fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No typo.=C2=A0 =C2=A0I was looking to do better than SPF N= ONE, and NXDOMAIN was the first=C2=A0thing that came to mind.

If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop= with all the information needed to make a decision.=C2=A0 =C2=A0(The sende= r is violating ICANN name registration policies).=C2=A0 =C2=A0Ignoring NXDO= MAIN and continuing to look for MX/A/AAAA is a waste of information and a w= aste of resources.

But clearly, the norm in this g= roup is to check MX/A/AAA because it seems likely to be a more powerful fil= ter.=C2=A0 =C2=A0I wonder if that is actually true.=C2=A0 =C2=A0
= 1)=C2=A0 A/AAAA is a pretty weak test, since many domains=C2=A0have A/AAAA = records on the domain name for web purposes.=C2=A0 =C2=A0
2) Exis= ting domain names that are being used for attacks are likely to have an MX = record, if for no other reason than updating a LetsEncrypt certificate.=C2= =A0 =C2=A0
=C2=A0Will someone collect data on frequency that a do= main fails MX/A/AAA when the domain exists?

Ad= ditionally, the connection between mail sending (SPF) and mail receiving (M= X/A/AAAA) seems tenuous to me.=C2=A0 =C2=A0Well-run domains do not send aut= omatic messages to unauthorized return paths, for fear of backscatter.=C2= =A0 =C2=A0Many domains seem to discard incoming automatic messages, either = for fear of attack or because the reply is too hard to integrate into autom= ated systems.

I do respond to SPF NONE by applying= a best-guess SPF policy which includes MX and A, and sometimes produces SP= F PASS.=C2=A0 =C2=A0But I no longer do that for non-existent domains.
=

I can imagine collecting MX and A existence data while = evaluating the default SPF policy, but I worry about the complexity of doin= g so, and doubt the benefit.=C2=A0 =C2=A0Doing it as a separate step is eas= y enough, but adds unwanted overhead.

Overall, we = have these result partitions for domains with SPF NONE:
1) Domain= does not exist, NXDOMAIN
2) Domain exists but MX/A/AAAA do not e= xist
3) Domain exists and MX/A/AAAA exist but do not validate the= source IP
4) Domain exists and source IP can be validated with M= X/A/AAAA, producing an inferred SPF PASS.

I want t= o be convinced that result #2 is a non-trivial volume of messages.=C2=A0 = =C2=A0 If #2 is a trivial volume, then there is no loss from combining it w= ith #3, which makes the extra MX/A/AAAA test unnecessary

Convince me.

Doug.=C2=A0


On Mon, Apr 5, 2021, 9:07 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
=
On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:

As a result of earlier = discussions, I have been investigating NXDOMAIN as an email filtering criteria.

One question from those discussion= s was the best way to detect NXDOMAIN.=C2=A0 I realized that I needed a query which specifically = returns NXDOMAIN as a result,=C2=A0not simply the absence of a particular r= esult.=C2=A0=C2=A0 Additionally, a lookup on A/AAAA with results could repr= esent either a domain name with no host segment, or a host segment and a parent domain..=C2=A0=C2=A0 Consequently, = the best test seems to query for type=3DTXT, match=3Ddomainname.

I have applied this rule to incomi= ng RFC5322.MailFrom addresses and found the test to be useful.=C2=A0 For my mail stream, 20% of the messages with SPF=3DNONE have this result because of NXDOMAIN.=C2=A0 The percentages were roughly equal whether evalu= ating=C2=A0unique domain names or unique messages.=C2=A0=C2=A0

While both SPF=3DNONE and SPF=3DNXDOMAIN are indicators that the message is probably unwanted, NX= DOMAIN has a higher probability of being unwanted.

I have not yet begun evaluating NX= DOMAIN on the RFC5322.From address, but hope to get that done in the weeks ahead.=C2=A0=C2=A0=C2=A0

Is anyone else collecting data on = NXDOMAIN, and able to share experience?


Due to terminology pedantry, I'm having trouble understanding th= is.=C2=A0 Someone please check my math here:

If I ask for= MX records for example.com, NXDOMAIN comes back as the response's error c= ode not if there's no MX record for that name, but rather if there are = no records of any kind for that name.=C2=A0 On the other hand, if there'= ;s no MX but there is an A or AAAA, I'm going to get a success error co= de (NOERROR), but with an answer count of 0.

So I = don't know what "detect NXDOMAIN" means: Your DNS reply eithe= r has that error code, or it doesn't.

If inste= ad you're trying to determine whether a name can receive mail, at least= according to DNS data, it seems to me you query one record type (MX) and s= ee if you get >0 answers, 0 answers, or NXDOMAIN.=C2=A0 If you got NXDOM= AIN, you're done; there's no way to route this message.=C2=A0 If yo= u got 0 answers, you should query A and/or AAAA and send there.=C2=A0 If yo= u got >0 answers, now you have to resolve the names you got to addresses= ; assuming at least one of those resolves, you have someplace to send the m= essage.=C2=A0 This is what RFC 5321 says to do.

I don'= ;t think querying TXT would tell you anything more.

What am I missing?

-MSK
--0000000000000be47205bf4c79fd-- From nobody Tue Apr 6 10:58:47 2021 Return-Path: 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 4932B3A2A83 for ; Tue, 6 Apr 2021 10:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, 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=gmail.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 mylv9sTGCvSF for ; Tue, 6 Apr 2021 10:58:40 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C018B3A2A81 for ; Tue, 6 Apr 2021 10:58:40 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id u11so4896090uaw.2 for ; Tue, 06 Apr 2021 10:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qM7wQs5uNDZD5pvdHeVzCboc3/Bm6UCPbqP6rRqWyfE=; b=ocDh5p7mN10E5+DxYnuIHDQMajf5SLjPxGf7GKiVzk6OXfNbVBxvr5XnhU+dkJwKpe 8BfH1doGyADAqUvJCxGgeXS6qWVao3eGhmWr3+0+BdSCdh2yulzC4mpC1qmgkNRQrSuT QHzJEemkxV/YmSrXpY1PBG4SYzQZUolV/c3blVSSw0+61/NW5ms2DPYnoOoYIEvAolEc 8BuGlbNXrZm3DMWUBDNZDX+ZgB2puT4al9n3ZRXNlRPCjN7xUoDXycmjh/gkc/ohfOfw mLK7nS+zOe5tyci/bJeEUQhfVIV/VIdqAKH+8bepUEmCeDbqYhU/Wlmy3ZPkcreaW8O7 qzYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qM7wQs5uNDZD5pvdHeVzCboc3/Bm6UCPbqP6rRqWyfE=; b=nhv4nhnQdL3vfOu+HITyU7wjaVNB18HmeDtnG0R8HMtKDCN1wLsBe3pasGMhIq/90g Ofo010ZWJjrfyPG7TcSudys6doUg9SBe0VcBwmUPeeAgxQHPK01swB2ItpK+ABgOMWmS /P5584Pn93YtLeASFBnndMlet0ordsRuZvwmapz9ltGCn8uLJWrq8OpbqYSzKtYsG4dw sEBIe0y/R29gH83/zgRDKHx4xaZdPqZXudmWJBp2xEdvJKnv9bjMGrCYyxJQanonp4aw /dg3HSQbVggpEERyVk+QtfotRp9F3gNbTJmvxdsW9RJDjrHJQvoVZCf0AIsuIvoajRHY lExw== X-Gm-Message-State: AOAM531NpRDY8N7pkTsnPuVc2W4NyLdjhYmsm2MMnWA6x8kkSvodfbHL xw0d0Y/yazcBkZ7olXFlGqwSHjNvInOstjVAVcU= X-Google-Smtp-Source: ABdhPJwN+n44Oc3CRxs/6mJ0O9gOGz6f+YRTW4BeQh2SiSGl1SJBc8tzYWKSVZm52CRRi0OXrNIGqO72xOaJxSvfFsg= X-Received: by 2002:ab0:44c3:: with SMTP id n61mr17220337uan.47.1617731918153; Tue, 06 Apr 2021 10:58:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 6 Apr 2021 10:58:26 -0700 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000052cf6905bf5190ad" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 17:58:46 -0000 --00000000000052cf6905bf5190ad Content-Type: text/plain; charset="UTF-8" On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with > all the information needed to make a decision. (The sender is violating > ICANN name registration policies). Ignoring NXDOMAIN and continuing to > look for MX/A/AAAA is a waste of information and a waste of resources. > I agree. But clearly, the norm in this group is to check MX/A/AAA because it seems > likely to be a more powerful filter. I wonder if that is actually true. > In the context of the code doing the SPF evaluation, I don't think it is. If TXT returns NXDOMAIN for a name, so will any other type. That's the definition of NXDOMAIN; there are no data of any type for this name. See also RFC 8020. Fortunately, a properly functioning local nameserver will cache the answer and just repeat it when subsequent MX, A, or AAAA queries get issued, so the waste is relatively cheap. I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting "That name does not exist (rcode=NXDOMAIN)" differently from "That name exists, but there's no record of the type you requested (rcode=NOERROR, ancount=0)", which can result in some wasted time, but I expect the end result would be the same. 1) A/AAAA is a pretty weak test, since many domains have A/AAAA records on > the domain name for web purposes. > Independently of SPF, it's not a weak test since the standards allow exactly this kind of setup for a domain that wants to receive mail. Again, Section 5.1 of RFC 5321. I do respond to SPF NONE by applying a best-guess SPF policy which includes > MX and A, and sometimes produces SPF PASS. But I no longer do that for > non-existent domains. > "Best guess SPF" is discouraged. See http://www.open-spf.org/FAQ/Best_guess_record/. -MSK --00000000000052cf6905bf5190ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 6, 2021 at 4:54 AM Douglas Fo= ster <dougfoster.= emailstandards@gmail.com> wrote:
If the = SPF Policy lookup returns NXDOMAIN, then we are at a full stop with all the= information needed to make a decision.=C2=A0 =C2=A0(The sender is violatin= g ICANN name registration policies).=C2=A0 =C2=A0Ignoring NXDOMAIN and cont= inuing to look for MX/A/AAAA is a waste of information and a waste of resou= rces.

I agree.

= But clearly, the norm in this group is to check MX/A/AAA because it seems l= ikely to be a more powerful filter.=C2=A0 =C2=A0I wonder if that is actuall= y true.=C2=A0 =C2=A0

In the con= text of the code doing the SPF evaluation, I don't think it is.=C2=A0 I= f TXT returns NXDOMAIN for a name, so will any other type.=C2=A0 That's= the definition of NXDOMAIN; there are no data of any type for this name.= =C2=A0 See also RFC 8020.=C2=A0 Fortunately, a properly functioning local n= ameserver will cache the answer and just repeat it when subsequent MX, A, o= r AAAA queries get issued, so the waste is relatively cheap.

<= div>I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting &quo= t;That name does not exist (rcode=3DNXDOMAIN)" differently from "= That name exists, but there's no record of the type you requested (rcod= e=3DNOERROR, ancount=3D0)", which can result in some wasted time, but = I expect the end result would be the same.

1)=C2=A0 A/AAAA is a= pretty weak test, since many domains=C2=A0have A/AAAA records on the domai= n name for web purposes.=C2=A0 =C2=A0

Independently of SPF, it's not a weak test since the standards a= llow exactly this kind of setup for a domain that wants to receive mail.=C2= =A0 Again, Section 5.1 of RFC 5321.

I do respond to SPF NO= NE by applying a best-guess SPF policy which includes MX and A, and sometim= es produces SPF PASS.=C2=A0 =C2=A0But I no longer do that for non-existent = domains.

"Best guess SPF" i= s discouraged.=C2=A0 See http://www.open-spf.org/FAQ/Best_guess_record/.

=
-MSK
--00000000000052cf6905bf5190ad-- From nobody Wed Apr 7 05:04:40 2021 Return-Path: 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 04AD43A4348 for ; Wed, 7 Apr 2021 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, 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=gmail.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 PrtlDzDrj1C3 for ; Wed, 7 Apr 2021 05:04:33 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8D53A4344 for ; Wed, 7 Apr 2021 05:04:32 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id q4so4187715vsm.0 for ; Wed, 07 Apr 2021 05:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zx7/XzIfOn0FuqudZwXN21bTomYI8EqWIQW23AHZTQk=; b=rJ0Bqw2uMtSoIYPotC/aoy1BGmNu5KO8VfBeBPab0dAc0rTbry4/834u7f/U48+VvX sbP3sSETgVYnXfOZUG92uk3axUuXClOkX+qMSpFDz3yY+zGG5Jdt5wmPrBfzZSh0ydPm tN5t5mIW5WmQ7BHsM95bjXkNGdVOQF5UDg2qQ/1pq/C/SfRDRPmdt4N7QHGbrqX9mOEn w9+Ke/GtWMY7YaOUYo0xR+NCUvk7r843xfS8wpbq0uAPYSkf7T1MOakw7utUzYUCC3O4 OThsyn28zKDV2yRTiXqM0qYYpJvmizRStpl3PRypmrHe6HfxewXTKoS3YCJroh4PMRrx 3/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zx7/XzIfOn0FuqudZwXN21bTomYI8EqWIQW23AHZTQk=; b=F9/zb7Y4vwuPNqZ8fkDKS5iZmdl89ym+BdiSePSr3PpbwysrwdSr+Jgkp+LhRs1Hgn uuNEmjekafeNckNzyzsVp3u8Jx9otYJvdWdSoVjGyP9bitNySd8PLpFtdCL8SOVpuk6o nNnEUw8f2YhxPMX4KKxBnzHn5I7WLz9evCiDrt4ClCExYqRBHJTP0Ikwuv3P/goLj4kZ zd6j2l7JU192jN84SVg7gn8M4+gxj3gVGx/XT3btGu2eOKjDTYK/Wkpd2cO5ewV1pWCj QMP9e/Fh07jpY+68xaOKEkCMZj4v6Kj3TW8ZnxHleFl/iOgK4OCt01ZFVWURP/peConl 2k4g== X-Gm-Message-State: AOAM530X7y66U9+4mheyqgNDTYpLx9diNBcIFz0dTjMgg6ZLUN/4CX1r 3mICHH4xrYYLBEcs99GXVrp815XmQFiVzfGEBwNauF0w X-Google-Smtp-Source: ABdhPJy9kKG0VCbuYsf21cnVO2s1NW2yaD0ooL9Cclqs2OiB9nS5u555XjyOA8VrMIc5av655ahcxFfcaTTWfzzhPag= X-Received: by 2002:a05:6102:238f:: with SMTP id v15mr1493163vsr.45.1617797070821; Wed, 07 Apr 2021 05:04:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Wed, 7 Apr 2021 07:04:20 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b99af105bf60bbd6" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 12:04:38 -0000 --000000000000b99af105bf60bbd6 Content-Type: text/plain; charset="UTF-8" I am hearing that we have a defacto standard to check return-path using MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) senders should consider it mandatory. Additionally, and more importantly for this group, it is presumed to be equally applicable for validation of the RFC5322.From, even though that address is unrelated to the SMTP return-path. But because the test is not explicitly documented, some products (my vendors) do not implement it at all, leaving a protection gap. As best I can tell, return-path-check does not have a unique name, specified result status codes, or a specific SMTP reject result code. At the simplest level, possible results are PASS, FAIL, TEMPERROR and PERMERROR. A more complex result set would probably be desirable for A-R, to indicate which entity produced the pass, which address class was used for the match, whether the match also resolved to the Source IP, and the Source IP itself. Other specification details include clarifying whether the MX/A/AAA address result must match the Source IP address class (presumably yes), and whether the result list should test for and reject addresses that are in the Private, Multicast, or Reserved lists (probably optional) If DMARC is to be dependent on return-path-check and inter-dependent with ARC, then I do not see how we can avoid producing a formal specification for the test and integrating it into A-R, as a co-requisite to the DMARC specification. Doug Foster On Tue, Apr 6, 2021 at 12:58 PM Murray S. Kucherawy wrote: > On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop >> with all the information needed to make a decision. (The sender is >> violating ICANN name registration policies). Ignoring NXDOMAIN and >> continuing to look for MX/A/AAAA is a waste of information and a waste of >> resources. >> > > I agree. > > But clearly, the norm in this group is to check MX/A/AAA because it seems >> likely to be a more powerful filter. I wonder if that is actually true. >> > > In the context of the code doing the SPF evaluation, I don't think it is. > If TXT returns NXDOMAIN for a name, so will any other type. That's the > definition of NXDOMAIN; there are no data of any type for this name. See > also RFC 8020. Fortunately, a properly functioning local nameserver will > cache the answer and just repeat it when subsequent MX, A, or AAAA queries > get issued, so the waste is relatively cheap. > > I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting "That > name does not exist (rcode=NXDOMAIN)" differently from "That name exists, > but there's no record of the type you requested (rcode=NOERROR, > ancount=0)", which can result in some wasted time, but I expect the end > result would be the same. > > 1) A/AAAA is a pretty weak test, since many domains have A/AAAA records >> on the domain name for web purposes. >> > > Independently of SPF, it's not a weak test since the standards allow > exactly this kind of setup for a domain that wants to receive mail. Again, > Section 5.1 of RFC 5321. > > I do respond to SPF NONE by applying a best-guess SPF policy which >> includes MX and A, and sometimes produces SPF PASS. But I no longer do >> that for non-existent domains. >> > > "Best guess SPF" is discouraged. See > http://www.open-spf.org/FAQ/Best_guess_record/. > > -MSK > --000000000000b99af105bf60bbd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am hearing that we have a defacto=C2=A0standard to check= return-path using MX/A/AAAA.=C2=A0 It is implemented with sufficient bread= th,that (unlike SPF) senders should consider it mandatory.=C2=A0 =C2=A0 Add= itionally, and more importantly for this group, it is presumed=C2=A0to be e= qually applicable for validation of the RFC5322.From, even though that addr= ess is unrelated to the SMTP=C2=A0return-path.=C2=A0 But because the=C2=A0t= est is not explicitly documented, some products (my vendors) do not impleme= nt it at all, leaving a protection gap.=C2=A0 =C2=A0

As = best I can tell, return-path-check does not have a unique name, specified r= esult status codes, or a specific SMTP reject result code.=C2=A0 =C2=A0 At = the simplest level, possible results are PASS, FAIL, TEMPERROR and PERMERRO= R.=C2=A0 =C2=A0A more complex result set would probably be desirable for A-= R, to indicate which entity produced the pass, which address class was used= for the match, whether the match also resolved to the Source IP, and the S= ource IP itself.=C2=A0 =C2=A0 Other specification details include clarifyin= g whether the MX/A/AAA address result must match the Source IP address clas= s (presumably yes), and whether the result list should test for and reject = addresses that are in the Private, Multicast, or Reserved lists (probably o= ptional)

If DMARC is to be dependent on return-pat= h-check and inter-dependent with ARC, then I do not see how we can avoid pr= oducing a formal specification for the test and integrating it into A-R, as= a co-requisite to the DMARC specification.

Doug F= oster

On Tue, Apr 6, 2021 at 12:58 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster <dougfoster.emails= tandards@gmail.com> wrote:
If the SPF Po= licy lookup returns NXDOMAIN, then we are at a full stop with all the infor= mation needed to make a decision.=C2=A0 =C2=A0(The sender is violating ICAN= N name registration policies).=C2=A0 =C2=A0Ignoring NXDOMAIN and continuing= to look for MX/A/AAAA is a waste of information and a waste of resources.<= /div>

I agree.

But cl= early, the norm in this group is to check MX/A/AAA because it seems likely = to be a more powerful filter.=C2=A0 =C2=A0I wonder if that is actually true= .=C2=A0 =C2=A0

In the context o= f the code doing the SPF evaluation, I don't think it is.=C2=A0 If TXT = returns NXDOMAIN for a name, so will any other type.=C2=A0 That's the d= efinition of NXDOMAIN; there are no data of any type for this name.=C2=A0 S= ee also RFC 8020.=C2=A0 Fortunately, a properly functioning local nameserve= r will cache the answer and just repeat it when subsequent MX, A, or AAAA q= ueries get issued, so the waste is relatively cheap.

I im= agine some DNS APIs are ambiguous (i.e., lazy) about reporting "That n= ame does not exist (rcode=3DNXDOMAIN)" differently from "That nam= e exists, but there's no record of the type you requested (rcode=3DNOER= ROR, ancount=3D0)", which can result in some wasted time, but I expect= the end result would be the same.

1)=C2=A0 A/AAAA is a pretty we= ak test, since many domains=C2=A0have A/AAAA records on the domain name for= web purposes.=C2=A0 =C2=A0

Ind= ependently of SPF, it's not a weak test since the standards allow exact= ly this kind of setup for a domain that wants to receive mail.=C2=A0 Again,= Section 5.1 of RFC 5321.

I do respond to SPF NONE by appl= ying a best-guess SPF policy which includes MX and A, and sometimes produce= s SPF PASS.=C2=A0 =C2=A0But I no longer do that for non-existent domains.

"Best guess SPF" is discoura= ged.=C2=A0 See http://www.open-spf.org/FAQ/Best_guess_record/.
<= div>
-MSK
--000000000000b99af105bf60bbd6-- From nobody Wed Apr 7 07:50:29 2021 Return-Path: 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 B960C3A1B81 for ; Wed, 7 Apr 2021 07:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 ZiP-rBGP6_92 for ; Wed, 7 Apr 2021 07:50:22 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FB93A1B7F for ; Wed, 7 Apr 2021 07:50:22 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id g15so18954660qkl.4 for ; Wed, 07 Apr 2021 07:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XVE0M1m2rzAOtUfDxVK59GWB4J7aL22fxaiVdLMOkdo=; b=XXol3QxiUGHBbGie8/Du0RWHASNo/V1XXBaHcWpcSOnZRHYhvH+n3pLmPYXZ4RmH8e ALAi7PPd0D/1MYoVOJjX8HFXkAasj8b1fketr9va64+52wGZ1SgjUFEY6Fk9JqpcufN3 sE1BqwZLoIwYWd5gYzaOho+iABUDzqMk1zuRc19FUGjug3Xr8HnBfePYXcuxdzwlKCwm mO0Xks10wd+WNeBKBTsYMm+KdpUwzeqpALms4gWKdtIwa9fLpqPgKLyVvl2veQ0d0Vjz aZzdexXOIjiIuOHe1vy/3RtxY5z4T9qgzLrHm248T/sRtSxqg7oblym+zWHXXd33DnTJ 5Uqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XVE0M1m2rzAOtUfDxVK59GWB4J7aL22fxaiVdLMOkdo=; b=dWqfn97ukSo/vTJIvYZwgESTAIn3dk3IuQ2BEyrkJcXYoGuCXIsyldgkw/VubWpaBH m6pU96nJ3SgmUWEEh5lZA/5FtFR6hb4dcLPzxZcmLMy87lgtNxZYoURCYJ0LSwGnt+d9 Ei4Yg/1WT94atFqsZs6MaEm0Ac89DqqVq0g0U+/AbucU7awKZhoGSpfwpp+H4vZ6P8f+ ci5xccGeJ/y+LJowp944NsjlABUBNuLPVRrsjKM27qBg43yYlBo0F0YHUanhYoJp7bd8 rImfgd8P1CjoyNR9aLvcN1qWNeg/n7V9Q2q/wGdrMlAlC4QXwrdq7GYCCzRc4hA6BpQI O7XA== X-Gm-Message-State: AOAM533EEuwvPAp0XfF9jgxIAnp6nF6wWHBcE777Fmo6YHvO4m7EKu0/ F1jnt39p2MnELvOABF7YOHq3HFgQjXNqRaV/9Q2ChgbqK35Iqg== X-Google-Smtp-Source: ABdhPJzoJl1gH5VJfoQeb6lxev+azfFazUwJzxk1nmar5B7XqqGqSRgJ9jShbZ+z/Q8COPIB66EO9mVbEMKVKh1z52w= X-Received: by 2002:a05:620a:1585:: with SMTP id d5mr3600279qkk.325.1617807019508; Wed, 07 Apr 2021 07:50:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Wed, 7 Apr 2021 10:50:03 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b69c6905bf630c59" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 14:50:28 -0000 --000000000000b69c6905bf630c59 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 7, 2021 at 8:04 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > I am hearing that we have a defacto standard to check return-path using > MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) > senders should consider it mandatory. Additionally, and more importantly > for this group, it is presumed to be equally applicable for validation of > the RFC5322.From, even though that address is unrelated to the > SMTP return-path. But because the test is not explicitly documented, some > products (my vendors) do not implement it at all, leaving a protection > gap. > > As best I can tell, return-path-check does not have a unique name, > specified result status codes, or a specific SMTP reject result code. At > the simplest level, possible results are PASS, FAIL, TEMPERROR and > PERMERROR. A more complex result set would probably be desirable for A-R, > to indicate which entity produced the pass, which address class was used > for the match, whether the match also resolved to the Source IP, and the > Source IP itself. Other specification details include clarifying whether > the MX/A/AAA address result must match the Source IP address class > (presumably yes), and whether the result list should test for and reject > addresses that are in the Private, Multicast, or Reserved lists (probably > optional) > > If DMARC is to be dependent on return-path-check and inter-dependent with > ARC, then I do not see how we can avoid producing a formal specification > for the test and integrating it into A-R, as a co-requisite to the DMARC > specification. > > > I'm of the opinion that you're overthinking things, and that you're trying to bolt things onto DMARC that don't need to be bolted onto DMARC. The purpose of DMARC is simple. It attempts to establish the authenticity of the claimed identity of the RFC5322.From domain, and does this by requiring either an aligned pass verdict for SPF or an aligned pass verdict for DKIM. The results of DMARC validation checks usually lead to one of three paths: 1. If the domain is proven authentic through these checks, then I, as the receiver of the message, can reliably add this message to the set of data points that I maintain that make up the domain's reputation (for whatever that means) and I can reliably apply local policy rules to that message based on that domain's accumulated reputation. 2. If the domain publishes a DMARC policy and the message fails DMARC checks, I can use the policy record, if I choose, as input into the message handling decision that I ultimately make. 3. If the domain doesn't publish a DMARC policy record, then I've got less information to go on for the message, and so I'm likely to focus on the source IP's reputation, unless my own internal systems are so sophisticated and robust enough for me to track reputation data for unauthenticated traffic. We haven't yet reached a point in the ecosystem where "no auth, no entry" is in widespread adoption, and so lack of a DMARC record is not likely to be a reason to reject a message. DMARC is just a data point to add to other data points that ultimately determine what handling a given message will receive. At some sites, I'd posit that the majority of inbound messages never make it to the DMARC check stage, because the messages are rejected prior to the issuance of the DATA command. If I were still engaged in the operations side of email, especially at a mailbox provider, I personally would see no need to log anything about the results of the MX/A/AAAA check, whether it's done for RFC5321.From or RFC5322.From. The mail system would be constructed such that the fact that the message was accepted was in itself evidence that an MX and/or A/AAAA record existed for the domain; note that this probably wouldn't be the only acceptance criteria, but it would be one of them. While my decision to include this as an acceptance criteria may be a common one, I don't think it rises to the level of standard; I think it is better labeled a BCP. Also worth noting is that I haven't worked in email operations since 2010, long before RFC 7489 was published, but I was doing the MX and A/AAAA checks back then, so if there's interest in documenting the practice, it might be better documented in the latest updates to RFCs 5321 and 5322 and any associated applicability statements that the emailcore working group is doing. I think that requiring that the MX/A/AAAA address match the Source IP address class is perhaps a bridge too far; third-party ESPs employed by many larger senders aren't typically in the business of handling inbound mail for their customers, and so you're likely to see a lot of diversion, especially for checks done on RFC5322.From addresses. For example: washingtonpost.com. 43200 IN TXT "v=spf1 ip4:198.72.14.0/23 ip4: 192.72.255.0/24 ip4:54.156.98.51 ip4:54.210.51.17 include: spf.protection.outlook.com include:madgexjb.com include: spf-001a3c01.pphosted.com include:amazonses.com -all" washingtonpost.com. 3600 IN MX 10 mxa-001a3c01.gslb.pphosted.com. washingtonpost.com. 3600 IN MX 10 mxb-001a3c01.gslb.pphosted.com. As for the overall validity of the MX or A/AAAA record, specifically does it point to something that is reachable and willing to accept mail for the domain in question, that's what periodic inspection of one's own queues and bounce logs are for. If one notices that a significant amount of mail destined for a remote domain isn't leaving your platform, and troubleshooting doesn't rectify the problem, and it appears that the domain in question is one that's sending unwanted mail, one can always block the offending domain as a matter of local policy on the grounds that it's mail is unwanted and can't be responded to. Accepting mail that can't be replied to due to the remote site not answering isn't a problem that DMARC is designed to diagnose or solve, though. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000b69c6905bf630c59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 7, 2021 at 8:04 AM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
I am hearing that we= have a defacto=C2=A0standard to check return-path using MX/A/AAAA.=C2=A0 I= t is implemented with sufficient breadth,that (unlike SPF) senders should c= onsider it mandatory.=C2=A0 =C2=A0 Additionally, and more importantly for t= his group, it is presumed=C2=A0to be equally applicable for validation of t= he RFC5322.From, even though that address is unrelated to the SMTP=C2=A0ret= urn-path.=C2=A0 But because the=C2=A0test is not explicitly documented, som= e products (my vendors) do not implement it at all, leaving a protection ga= p.=C2=A0 =C2=A0

As best I can tell, return-path-check do= es not have a unique name, specified result status codes, or a specific SMT= P reject result code.=C2=A0 =C2=A0 At the simplest level, possible results = are PASS, FAIL, TEMPERROR and PERMERROR.=C2=A0 =C2=A0A more complex result = set would probably be desirable for A-R, to indicate which entity produced = the pass, which address class was used for the match, whether the match als= o resolved to the Source IP, and the Source IP itself.=C2=A0 =C2=A0 Other s= pecification details include clarifying whether the MX/A/AAA address result= must match the Source IP address class (presumably yes), and whether the r= esult list should test for and reject addresses that are in the Private, Mu= lticast, or Reserved lists (probably optional)

If = DMARC is to be dependent on return-path-check and inter-dependent with ARC,= then I do not see how we can avoid producing a formal specification for th= e test and integrating it into A-R, as a co-requisite to the DMARC specific= ation.



I'= ;m of the opinion that you're overthinking things, and that you're = trying to bolt things onto DMARC that don't need to be bolted onto DMAR= C.

The purpose of DMARC is simple. It attem= pts to establish the authenticity of the claimed identity of the RFC5322.Fr= om domain, and does this by requiring either an aligned pass verdict for SP= F or an aligned pass verdict for DKIM. The results of DMARC validation chec= ks usually lead to one of three paths:
  • If the domain is proven authentic through these checks, then I, as th= e receiver of the message, can reliably add this message to the set of data= points that I maintain that make up the domain's reputation (for whate= ver that means) and I can reliably apply local policy rules to that message= based on that domain's accumulated reputation.=C2=A0
  • If the do= main publishes a DMARC policy and the message fails DMARC checks, I can use= the policy record, if I choose, as input into the message handling decisio= n that I ultimately make.=C2=A0
  • If the domain doesn't publish a= DMARC policy record, then I've got less information to go on for the m= essage, and so I'm likely to focus on the source IP's reputation, u= nless my own internal systems are so sophisticated and robust enough for me= to track reputation data for unauthenticated traffic. We haven't yet r= eached a point in the ecosystem where "no auth, no entry" is in w= idespread adoption, and so lack of a DMARC record is not likely to be a rea= son to reject a message.
    • DMARC is just a data point to add to= other data points that ultimately determine what handling a given message = will receive. At some sites, I'd posit that the=C2=A0majority of inboun= d messages never make it to the DMARC check stage, because the messages are= rejected prior to the issuance of the DATA command.

    If I were still engaged in the operations side of email, especially at = a mailbox provider, I personally would see no need to log anything about th= e results of the MX/A/AAAA check, whether it's done for RFC5321.From or= RFC5322.From. The mail system would be constructed such that the fact that= the message was accepted was in itself evidence that an MX and/or A/AAAA r= ecord existed for the domain; note that this probably wouldn't be the o= nly acceptance criteria, but it would be one of them. While my decision to = include this as an acceptance criteria may be a common one, I don't thi= nk it rises to the level of standard; I think it is better labeled a BCP. A= lso worth noting is that I haven't worked in email operations since 201= 0, long before RFC 7489 was published, but I was doing the MX and A/AAAA ch= ecks back then, so if there's interest in documenting the practice, it = might be better documented in the latest updates to RFCs 5321 and 5322 and = any associated applicability statements that the emailcore working group is= doing.

    I think that requiring that the MX/A/AAAA address match the Sour= ce IP address class is perhaps a bridge too far; third-party ESPs employed = by many larger senders aren't typically in the business of handling inb= ound mail for their customers, and so you're likely to see a lot of div= ersion, especially for checks done on RFC5322.From addresses. For example:<= /div>
    <= br>

    washingtonpost.com. 43200 IN TXT "v=3Dspf1 ip4:198.72.14.0/23 ip4:192.72.255= .0/24 ip4:54.156.98.51 ip4:54.210.51.17 include:spf.protection.outlook.com include:madgexjb.com include:spf-001a3c01.pphosted.com include:amazonses.com -all"


    = washingtonpost.com. 3600 IN MX 10 mxa-001= a3c01.gslb.pphosted.com.

    washingtonpost.com. 3600 IN MX 10 mxb-001a3c01.gslb.pphosted.com.


    As for the o= verall validity of the MX or A/AAAA record, specifically does it point to s= omething that is reachable and willing to accept mail for the domain in que= stion, that's what periodic inspection of one's own queues and boun= ce logs are for. If one notices that a significant amount of mail destined = for a remote domain isn't leaving your platform, and troubleshooting do= esn't rectify the problem, and it appears that the domain in question i= s one that's sending unwanted mail, one can always block the offending = domain as a matter of local policy on the grounds that it's mail is unw= anted and can't be responded to. Accepting mail that can't be repli= ed to due to the remote site not answering isn't a problem that DMARC i= s designed to diagnose or solve, though.

    --

    Todd Herr | Sr. Technic= al Program Manager
    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 rece= ive 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 im= mediately notify the sender by replying to this email and then delete it fr= om your system.

    --000000000000b69c6905bf630c59-- From nobody Wed Apr 7 22:06:51 2021 Return-Path: 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 15B793A3987 for ; Wed, 7 Apr 2021 22:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNlmoGJAHpl6 for ; Wed, 7 Apr 2021 22:06:47 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D913A3986 for ; Wed, 7 Apr 2021 22:06:46 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id f11so231698vkl.9 for ; Wed, 07 Apr 2021 22:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d6U/HpwlcG+mJtxbz4klK2hxc7BujcOsrfeLjXQoTsk=; b=BPXtjR/yVlue0Yt8tvVsOOi97MCZrjjpUuvVBT2s7S2onVE+mN8SqmzG4R/REm2jIn lDzqIX7jGgmW4udDaWmEifYCQmBa5FpxApOuEk0oOFyGmXU5vfD5+Pc8C0GSZ/gr/oJx 2jJQp/7fCFQvxyYr39d5go6Nxq8o+58NoRscebIUhLlvjOrG44ZDn0kT3yFlJkJkVv3W cordlaVase1QpbnfkFX6AUj0NvYQTK/F5eo6oK4VNYFjdWaEvntovVFHccN0GMZR1r3Y 7c9wrri7J0WUKlnf2mexluYP6DbJc5MaUog8hhVdz0laQfxxctgApj/hnRELIOW1mCaj YhmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d6U/HpwlcG+mJtxbz4klK2hxc7BujcOsrfeLjXQoTsk=; b=fMe+onnqTbk5hnJ0FGYE9P2Zu59wZBWjMJnzFAJv3dkjsx0yVtix3LDtJ0kDxcCzNO ndmZ/VjFuOtJH3gPF8OpuB99z+eyWbRnQ1VZ6jcKEqAs/8SlcWfizXlSaRhxjhvLb6fo IuB7nmwiVtjmC2AkED6YVvWt3yhnyho4hR3VWT5CalWbQ9r8/a9lgY3dXjFg6Hgg5Tc7 OWYwPkdHFnVTrSEX3btp+7ttx7538DRjwjBLQa+5tzIp1i3EBuwABm0WraRJNZ9OI22N L8zRjB+4OM4n8zQ/xZJU9E/a/hIsnKR6qfh/Q5YgwQ5mNJJLO53dAl35sDO4USukiY5o xVuA== X-Gm-Message-State: AOAM531ExV+mF80QYy29bygtjZXhwMg1lvo+W+kloXvo33GnNjv/5fQN DsGpKXP6BASd8HF5RpBlXsQzRII4noJv+4GVSGs= X-Google-Smtp-Source: ABdhPJzpj2tE3Ld/j9KQ1CErmIWqgcdTNs88qIjU6UwGel+YA2yiJJ7SPfBHa0o/YN4CL3jJeW+xq2sdhNr2Gh0tC8s= X-Received: by 2002:a1f:5c88:: with SMTP id q130mr4628100vkb.14.1617858404602; Wed, 07 Apr 2021 22:06:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 7 Apr 2021 22:06:33 -0700 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000080d9ae05bf6f0362" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 05:06:49 -0000 --00000000000080d9ae05bf6f0362 Content-Type: text/plain; charset="UTF-8" Further to what Todd said: On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > I am hearing that we have a defacto standard to check return-path using > MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) > senders should consider it mandatory. Additionally, and more importantly > for this group, it is presumed to be equally applicable for validation of > the RFC5322.From, even though that address is unrelated to the > SMTP return-path. But because the test is not explicitly documented, some > products (my vendors) do not implement it at all, leaving a protection gap. > I think I'm confused about how this ties to DMARC. What you're describing is, I believe, a common anti-spam tactic that was in use even before SPF or DKIM were a thing. It probably still is, irrespective of those protocols. However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC had such a test, but it was removed because of too many false negatives. > If DMARC is to be dependent on return-path-check and inter-dependent with > ARC, then I do not see how we can avoid producing a formal specification > for the test and integrating it into A-R, as a co-requisite to the DMARC > specification. > How is DMARC dependent on a return path check? SPF is, but DMARC isn't. DMARC only cares what the SPF result was, and whether the domain it evaluated is aligned with the RFC5322.From domain. In fact, a DMARC filter could operate correctly with no knowledge of what the return path was, provided the A-R fields are correct and complete. Another perspective: If the RFC5322.From domain doesn't exist, it's not possible for a DMARC policy to be discovered for it, nor is it possible that SPF or DKIM will pass for it or align to it. Therefore, is such a domain even in scope here, much less a need to describe a way to test it? -MSK --00000000000080d9ae05bf6f0362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Further to what Todd said:

    On Wed, Apr 7, 2021 at = 5:04 AM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
    I am hearing tha= t we have a defacto=C2=A0standard to check return-path using MX/A/AAAA.=C2= =A0 It is implemented with sufficient breadth,that (unlike SPF) senders sho= uld consider it mandatory.=C2=A0 =C2=A0 Additionally, and more importantly = for this group, it is presumed=C2=A0to be equally applicable for validation= of the RFC5322.From, even though that address is unrelated to the SMTP=C2= =A0return-path.=C2=A0 But because the=C2=A0test is not explicitly documente= d, some products (my vendors) do not implement it at all, leaving a protect= ion gap.

    I think I'm confused abo= ut how this ties to DMARC.=C2=A0 What you're describing is, I believe, = a common anti-spam tactic that was in use even before SPF or DKIM were a th= ing.=C2=A0 It probably still is, irrespective of those protocols.

    However, RFC 7489's Appendix A.4 points out that e= arlier versions of DMARC had such a test, but it was removed because of too= many false negatives.
    =C2=A0
    If DMARC is to be dependent = on return-path-check and inter-dependent with ARC, then I do not see how we= can avoid producing a formal specification for the test and integrating it= into A-R, as a co-requisite to the DMARC specification.

    How is DMARC dependent on a return path check?=C2= =A0 SPF is, but DMARC isn't.=C2=A0 DMARC only cares what the SPF result= was, and whether the domain it evaluated is aligned with the RFC5322.From = domain.=C2=A0 In fact, a DMARC filter could operate correctly with no knowl= edge of what the return path was, provided the A-R fields are correct and c= omplete.

    Another perspective: If the RFC5322.F= rom domain doesn't exist, it's not possible for a DMARC policy to b= e discovered for it, nor is it possible that SPF or DKIM will pass for it o= r align to it.=C2=A0 Therefore, is such a domain even in scope here, much l= ess a need to describe a way to test it?

    -MSK
    <= /div>
    --00000000000080d9ae05bf6f0362-- From nobody Thu Apr 8 05:02:31 2021 Return-Path: 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 2B4083A1430 for ; Thu, 8 Apr 2021 05:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ-XQVBXYA1d for ; Thu, 8 Apr 2021 05:02:27 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28723A142F for ; Thu, 8 Apr 2021 05:02:27 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id k27so442748vki.2 for ; Thu, 08 Apr 2021 05:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mWggbpmcui4QQTokqrxnC+4e6hdbkdk6ggVsNK1cBD4=; b=ZmwG0NkXshF6RT8fDwRG2un/2WGRxSXEXfDdpVKMeSQZ0cwt/444EYtcLyBHWFwkju 4o3WjF5CI9JSW1y/5y+HoT8yZzjP26ad9L59vubuNA1O8zE+13m2OnObYufr+rvPf7N4 8NIfiXJWm2IfC5Ad3bLjfLVyRPQeO6jVtF5ZI7HT6MwJjDDYtWQ0Wh7gQ3eEtOBfixfa SZBTl1F/4HtNykuaTijBzmqzsJmdWlCrji/IXufGJRRGgCBHl0LLRf5cNKySy/XuAttT zEEWlAFzIGnFZFLmuZI/kxJapdXHN9nTWrGYkdlU0o3TxZBfxKYKDVUW9qjxi/jF/xMz ziBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mWggbpmcui4QQTokqrxnC+4e6hdbkdk6ggVsNK1cBD4=; b=RwQwu/yedjL1wGYhM6bwbkGc4ggnKJ0Ab8JYmPYQ2WuP/f/eqj5NAeoiFh+BV8LXoU GVuedx90q7q9vnJxv9DI+eQA++06hg8OKUBhYn61uJoJRIDgFTftaBYzf4I42vfpMus9 OJ0/Xi8vWrp/BvAxlwEMvS13mKonnNUxqmp79AKfOLDWN6kD0wLwomGCvrl9NJ+tnNes wswfqq55zrlze4x3koJex98XNEO+/Bftk52CjvmmhqlADT5GVoMBnBvvnAz5bvUyuTIi /d2ArUtI6ifVdMxCE5kovKK48F86ySbXjUMVy9iwbA4pQcyn6CzMxsZVF/UjzpILGuRm 4XWg== X-Gm-Message-State: AOAM530vXtVz1z+sqeMHKm2GakF85vkgZ+d0cPgRQSjLUY3fPn2nmosa 2ilnWutbQm2SxnLOlBJFET9msgenRCcJUwiK9G8= X-Google-Smtp-Source: ABdhPJyU6shXJdWUcHLAWI584p0YL0/W5/grFysC+ef9jmwsVpGSnjgIKM38XWcahxdSs8gG+mZ0NAUPSJlJbk3b+Gc= X-Received: by 2002:a1f:5504:: with SMTP id j4mr5207995vkb.7.1617883346002; Thu, 08 Apr 2021 05:02:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Thu, 8 Apr 2021 08:02:15 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000020674005bf74d230" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 12:02:30 -0000 --00000000000020674005bf74d230 Content-Type: text/plain; charset="UTF-8" NXDOMAIN and Return-Path-Check are two different ways of identifying non-existent domains. I believe NXDOMAIN to be the better one, but since the group seemed to be in love with return-path-check, I was willing to go there. Whichever one could solve the problem best, the issue for us is that the problem has not been solved. Prior to PSD for DMARC, the IETF role in sender authentication could be summarized as follows: "An attacker may seek to hide his own reputation and acquire a better one by impersonating another domain. This is of interest to IETF and has been addressed by the specifications for SPF and DMARC. An attacker may also seek to hide his own reputation and acquire a neutral one by impersonating a non-existent domain. This is of no interest to IETF.;" This dichotomy is hard to defend. It has been made worse by embracing PSD for DMARC. The statement must now be revised to say: "IETF is interested in attacks of the form 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks of the form 'nonexistentdomain.otherdomain.psd'. Todd's comments suggest that the whole issue of non-existent domains is a non-problem because everybody who matters is already well protected from non-existent domains, because they have implemented non-IETF tests such as return-path-check. If this were true, attackers would move on to other strategies and PSD for DMARC would have no advocates. When we start using ARC to accept results which cannot be independently tested, we need to know what tests were peformed. Since address rewrite can eliminate the ability to reproduce earlier tests for NXDOMAIN or Return-Path, it must be part of the ARC results. The success of ARC depends on having this information included, and the success of "new" DMARC has been tied to ARC. Non-existent domain usage is not a minor issue and not an issue that is already solved. It is the elephant in the room, and it needs to be addressed. Doug On Thu, Apr 8, 2021 at 1:06 AM Murray S. Kucherawy wrote: > Further to what Todd said: > > On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> I am hearing that we have a defacto standard to check return-path using >> MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) >> senders should consider it mandatory. Additionally, and more importantly >> for this group, it is presumed to be equally applicable for validation of >> the RFC5322.From, even though that address is unrelated to the >> SMTP return-path. But because the test is not explicitly documented, some >> products (my vendors) do not implement it at all, leaving a protection gap. >> > > I think I'm confused about how this ties to DMARC. What you're describing > is, I believe, a common anti-spam tactic that was in use even before SPF or > DKIM were a thing. It probably still is, irrespective of those protocols. > > However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC > had such a test, but it was removed because of too many false negatives. > > >> If DMARC is to be dependent on return-path-check and inter-dependent with >> ARC, then I do not see how we can avoid producing a formal specification >> for the test and integrating it into A-R, as a co-requisite to the DMARC >> specification. >> > > How is DMARC dependent on a return path check? SPF is, but DMARC isn't. > DMARC only cares what the SPF result was, and whether the domain it > evaluated is aligned with the RFC5322.From domain. In fact, a DMARC filter > could operate correctly with no knowledge of what the return path was, > provided the A-R fields are correct and complete. > > Another perspective: If the RFC5322.From domain doesn't exist, it's not > possible for a DMARC policy to be discovered for it, nor is it possible > that SPF or DKIM will pass for it or align to it. Therefore, is such a > domain even in scope here, much less a need to describe a way to test it? > > -MSK > --00000000000020674005bf74d230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    NXDOMAIN and Return-Path-Check are two different ways of i= dentifying non-existent domains.=C2=A0 =C2=A0 I believe=C2=A0NXDOMAIN to be= the better one, but since the group seemed to be in love with=C2=A0return-= path-check, I was willing to go there.=C2=A0 =C2=A0 Whichever one could sol= ve the problem best, the issue for us is that the problem has not been solv= ed.

    Prior to PSD for DMARC, the IETF role in sender auth= entication could be summarized as follows:

    "A= n attacker may seek to hide his own reputation and acquire a better one by = impersonating another domain.=C2=A0 This is of interest to IETF and has bee= n addressed=C2=A0by the specifications for SPF and DMARC.=C2=A0 An attacker= may also seek to hide his own reputation=C2=A0and acquire a neutral one by= impersonating a non-existent domain.=C2=A0 =C2=A0This is of no interest to= IETF.;"

    This dichotomy=C2=A0is hard to defen= d.=C2=A0 =C2=A0It has been made worse by embracing PSD for DMARC.=C2=A0 =C2= =A0The statement must now be revised to say:

    "= ;IETF is interested in attacks of the form 'otherdomain.nonexistentdoma= in.psd', but IETF is not interested in attacks of the form 'nonexis= tentdomain.otherdomain.psd'.

    Todd's=C2=A0c= omments suggest that the whole issue of non-existent domains is a non-probl= em because everybody who matters is already well protected from non-existen= t domains, because they have=C2=A0implemented non-IETF tests such as return= -path-check.=C2=A0 =C2=A0 If this were true, attackers would move on to oth= er strategies and PSD for DMARC would have no advocates.

    When we start using ARC to accept results which cannot be independen= tly tested, we need to know what tests were peformed.=C2=A0 =C2=A0Since add= ress rewrite can eliminate the ability to reproduce earlier tests for NXDOM= AIN or Return-Path, it=C2=A0must be=C2=A0part of the ARC results.=C2=A0 The= success of ARC depends on having this information included,=C2=A0and the s= uccess of "new" DMARC has been tied to ARC.=C2=A0 =C2=A0=C2=A0

    Non-existent domain usage is not a minor issue and n= ot an issue that is already solved.=C2=A0 =C2=A0It is the elephant in the r= oom, and it needs to be addressed.

    Doug
    =

    On Thu, Apr 8, 2021 at 1:06 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
    Furth= er to what Todd said:

    On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster <= do= ugfoster.emailstandards@gmail.com> wrote:
    I am hearing that we have= a defacto=C2=A0standard to check return-path using MX/A/AAAA.=C2=A0 It is = implemented with sufficient breadth,that (unlike SPF) senders should consid= er it mandatory.=C2=A0 =C2=A0 Additionally, and more importantly for this g= roup, it is presumed=C2=A0to be equally applicable for validation of the RF= C5322.From, even though that address is unrelated to the SMTP=C2=A0return-p= ath.=C2=A0 But because the=C2=A0test is not explicitly documented, some pro= ducts (my vendors) do not implement it at all, leaving a protection gap.

    I think I'm confused about how this= ties to DMARC.=C2=A0 What you're describing is, I believe, a common an= ti-spam tactic that was in use even before SPF or DKIM were a thing.=C2=A0 = It probably still is, irrespective of those protocols.

    <= /div>
    However, RFC 7489's Appendix A.4 points out that earlier vers= ions of DMARC had such a test, but it was removed because of too many false= negatives.
    =C2=A0
    If DMARC is to be dependent on return-p= ath-check and inter-dependent with ARC, then I do not see how we can avoid = producing a formal specification for the test and integrating it into A-R, = as a co-requisite to the DMARC specification.
    How is DMARC dependent on a return path check?=C2=A0 SPF is, b= ut DMARC isn't.=C2=A0 DMARC only cares what the SPF result was, and whe= ther the domain it evaluated is aligned with the RFC5322.From domain.=C2=A0= In fact, a DMARC filter could operate correctly with no knowledge of what = the return path was, provided the A-R fields are correct and complete.
    <= /div>

    Another perspective: If the RFC5322.From domain do= esn't exist, it's not possible for a DMARC policy to be discovered = for it, nor is it possible that SPF or DKIM will pass for it or align to it= .=C2=A0 Therefore, is such a domain even in scope here, much less a need to= describe a way to test it?

    -MSK
    --00000000000020674005bf74d230-- From nobody Thu Apr 8 08:44:50 2021 Return-Path: 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 902073A0B3F for ; Thu, 8 Apr 2021 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=drkurt.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 nu0a2vHAaCFc for ; Thu, 8 Apr 2021 08:44:45 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F333A0B17 for ; Thu, 8 Apr 2021 08:44:44 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id z9so2183785ilb.4 for ; Thu, 08 Apr 2021 08:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gzStcHKFDNqV9RPCFf7wIc4Pbp4NIb6Q7jJ8rMCliuU=; b=AgwTyyEjnldTt4rYvJLctEyO5WrGgKl6LxIJx45w2IbTobbUL0M42pVTdjTF+h/n/8 47wJ/WSpxEaYlZ0sPkmF373rUNDrCIb/aQk6+16S9YyNxt7jf0Kp58a9ZieWjTu/dhBb sBXfhvWXA6ojlpwgp6rO5EfXm2apnHxNZsz2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gzStcHKFDNqV9RPCFf7wIc4Pbp4NIb6Q7jJ8rMCliuU=; b=lk8Ri7BcZkzOv9tiqnR3PlE9iM4ecfw+lq5Qe2l2FqAjc9qMXZHfy6u33Pj4Ilzle9 m53QSEy+ukWS4DY1Oug+yDJ722HpooN1ErB+tfyQPsfAR9AOdWmnEEDI/lC1TivG4krb LMuMyuFaWULtpIHO2XrAMnGO470SiXcsMHi0ERbiMGwHUiyZWgIHX4SuU+5fTQVBJKuo FHCFvFeFSmv0QzMAUZIg2k1A0mrhIYprT09YXqjNAYNrT/1fLe4cwygFQedMmdQH4xPG LxIrqUWMM4bB5bsOvty0b6BfTatprHQ9yXqBqVMedJOmp3pjQIZZSLD1NoI8kgLTRMqX z3yg== X-Gm-Message-State: AOAM530tx6m3dECVsOLuuP9UOXtBnkyJYNCCMV6vWKOvz/UjRmT37Lya 44ccv6tniiy4SXTNvfqscH/WzLs3CcwLa5CIgVLmBw== X-Google-Smtp-Source: ABdhPJyVOq5InrjUX72c2JxOOLfDn8gSC60QCjQNhX2LuLyBiMPVsoKOoREDJk5XJ25zxwpeaLYROltbTExzvKQK2XE= X-Received: by 2002:a92:1950:: with SMTP id e16mr7750701ilm.120.1617896683348; Thu, 08 Apr 2021 08:44:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 8 Apr 2021 08:44:33 -0700 Message-ID: To: Douglas Foster Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000018417505bf77ed19" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 15:44:50 -0000 --00000000000018417505bf77ed19 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > > "IETF is interested in attacks of the form > 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks > of the form 'nonexistentdomain.otherdomain.psd'. > I don't understand your assertion here. Non-existent domains under existing org domains are already covered by the org-level DMARC policy assertion. 5322.From domain of nosuchdomain.example.com would be treated in accord with the policy for example.com. --Kurt --00000000000018417505bf77ed19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Apr 8, 2021 at 5:02 AM Douglas Fo= ster <dougfoster.= emailstandards@gmail.com> wrote:
    "IETF is interested in attacks of the form 'otherdoma= in.nonexistentdomain.psd', but IETF is not interested in attacks of the= form 'nonexistentdomain.otherdomain.psd'.
    =

    I don't understand your assertion here. Non-existen= t domains under existing org domains are already covered by the org-level D= MARC policy assertion. 5322.From domain of nosuchdomain.example.com would be treated in accord with th= e policy for example.com.

    =
    --Kurt=C2=A0
    --00000000000018417505bf77ed19-- From nobody Thu Apr 8 09:28:13 2021 Return-Path: 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 C1F813A10AA for ; Thu, 8 Apr 2021 09:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=iecc.com header.b=Bo/L/zvv; dkim=pass (2048-bit key) header.d=taugh.com header.b=a/PB3qRE 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 QVO2XkXgIDDJ for ; Thu, 8 Apr 2021 09:28:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) (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 77A213A10A9 for ; Thu, 8 Apr 2021 09:28:05 -0700 (PDT) Received: (qmail 51250 invoked from network); 8 Apr 2021 16:27:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c82d.606f2ef0.k2104; bh=ehYtRy2RTiDs95ivRV6On7HqDUZUJ2DotkCT9fZkxpo=; b=Bo/L/zvvHhp8nigN2du1BpGvutQHZ93NysBfV/7HhKT7C+6V21sQF10Ryp7//7pNQCpZM1H8CEhawy5qcdGdGbE+MdQLynqAViBczff1ebnXccXFJsGYpFwbIIv/6x3I4wLgCmGh8O4GcbKS323eA+NYs/zTrpJsW1fhHccsJBnnJUksvKPoRxg5j/p1rItls7fQMTyspWmg44vOq7pB4RT1IomU7FsakBZKli8F3kXiapCUxDFTF9KBcoZsQeJgG5fJKQBy10PVOgyhMnahw7zPSwwFGSv2r/0aTteyXgWql6IJx492RtAySth/YPvzMYnHY/6wHvhJq5Kmav33DA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c82d.606f2ef0.k2104; bh=ehYtRy2RTiDs95ivRV6On7HqDUZUJ2DotkCT9fZkxpo=; b=a/PB3qREAph5Ae1VegAkY8ScDtOjAHGjizhZM+DHwvAYtLnbqxrpj1oeJziZJP/so/h7OVHDXi291O7fry96S1SEVY+c0AQhs5FuBWc9Njje4SmlToQtSKaYKXBsbt0LGJojW73pTVi/onN8Z5313/8qw4a55bPiexIweHYeMUE599dwmD4L7YM5Hw/lyKyjGZDM/Mf659MHXPKpg3Lc+uAlS705CvEojyWOEBd9kghB/kzfLTJhlgsAxKvamfFXUuGwsdqwrvky4xc8D/QT9sDJxhZwLLsQinc0ZK/+vQOnmEz+4wg/yUFDvxnpJDJm9VOhiIF1u8efoTtq3/UHgQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Apr 2021 16:27:27 -0000 Received: by ary.qy (Postfix, from userid 501) id 4E51E7281766; Thu, 8 Apr 2021 12:27:26 -0400 (EDT) Date: 8 Apr 2021 12:27:26 -0400 Message-Id: <20210408162727.4E51E7281766@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 16:28:12 -0000 It appears that Kurt Andersen (b) said: >On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster < >dougfoster.emailstandards@gmail.com> wrote: > >> >> "IETF is interested in attacks of the form >> 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks >> of the form 'nonexistentdomain.otherdomain.psd'. > >I don't understand your assertion here. Non-existent domains under existing >org domains are already covered by the org-level DMARC policy assertion. >5322.From domain of nosuchdomain.example.com would be treated in accord >with the policy for example.com. I agree with Kurt here. Non-existent domains are routinely handled in other ways and are outside the scope of DMARC. R's, John From nobody Thu Apr 8 09:50:48 2021 Return-Path: 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 718B43A11CD for ; Thu, 8 Apr 2021 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=gmail.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 3FAtQVYVb8iZ for ; Thu, 8 Apr 2021 09:50:42 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FFC3A11CB for ; Thu, 8 Apr 2021 09:50:41 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id h20so1494275vsu.1 for ; Thu, 08 Apr 2021 09:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BcCmGxTMU15TgtbGJRFJjcvxfpOAp8VwczRMv0fwLyA=; b=IfAPAuzy+tUnLJFJ+BQNAdAQuyrmbGMlyW04H3x1T8diD3RIndrX5P1e8QaPEWIqgl qBs6KaMOiu7KLimJW3j0d9AICN5k2WGWMyaT7WSuqIx58t2MFQdPY5ljFyPBJb4FfUqk Zx1ks3Jud4MsuHNSc0rwXTLyI136R1uHQQWjL8WuOz7+E9CoQBQ15kHImW90YX5YCIkt QYKmJ7HLICwxIuesmOCmNnMmhzwomXbAwWTSF7HuLMTSBjInst4O3DOn8XW7vSJOS/xy 6WVOmxNsQ1XmOuegxYNkvHeZ5iFdA9ph9HfbVoxcXPeqm2msGHCcXq+XRfeRMYLRX0FH vE8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BcCmGxTMU15TgtbGJRFJjcvxfpOAp8VwczRMv0fwLyA=; b=HNsoB4CSmqRW1Gn2HqlnEMzIf05Do5bUmR2lEMRlqBlMM26oGpKdUJTCR4449evSu7 kFViY1pnNY7t+rVqoM2pEYH3U7vAL9ZuvcadDa109TvHJIGUbzfNz4h8RS6WUudm1KCr vTwPeSDgYmDSpRL3f6KfNn7F6Qt+FfbgNjFUGPap3uZI31yV1dtWlSOxMCXdQsaObKaV q+3w+t5j+qwViCqxNm60wIx+S8juBwE3Hre8/xVub5o/AG27xo+HTFaYUfcgzH17ixiH sP2gtslEzp27Lv+6SSRtgKID7MosnMPWNX1ql293fSalDxHAHXXuJn6Ta9vfH7KrX7Kl buaQ== X-Gm-Message-State: AOAM5333DOXSnV/ysRkXXKIaXBe5zzCDNClID6jZtKybE8AzsKBFyR68 w4X6stWQglX+njkKRHvBVlE28ayonoxn4VarYzs= X-Google-Smtp-Source: ABdhPJxkb6kmDBNVzLGYqj8XQxRy1ouE/tmObazQc7yo2GzuOjQEP/I98Ogsl5OKKIVeJ0Oq2mVpn2RDVUsXkPWYzjY= X-Received: by 2002:a05:6102:238f:: with SMTP id v15mr7455993vsr.45.1617900639172; Thu, 08 Apr 2021 09:50:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Thu, 8 Apr 2021 12:50:26 -0400 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e13d6b05bf78d8e5" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 16:50:47 -0000 --000000000000e13d6b05bf78d8e5 Content-Type: text/plain; charset="UTF-8" They are covered by accident if the domain has an enforceable policy. The reality is that NX status means tharmt the subdomain is not under the administrative control of any parent domain and therefore the presence or absence of a domain policy is irrelevant. Why is it problematic to document this risk, and indicate that when "No Policy detected" occurs, it is recommended to check whether the domain exists, and if it does not exist then local policy for nonexistent domains should be applied? On Thu, Apr 8, 2021, 11:44 AM Kurt Andersen (b) wrote: > On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> >> "IETF is interested in attacks of the form >> 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks >> of the form 'nonexistentdomain.otherdomain.psd'. >> > > I don't understand your assertion here. Non-existent domains under > existing org domains are already covered by the org-level DMARC policy > assertion. 5322.From domain of nosuchdomain.example.com would be treated > in accord with the policy for example.com. > > --Kurt > --000000000000e13d6b05bf78d8e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    They are covered by accident if the domain has an enforce= able policy.=C2=A0 =C2=A0The reality is that NX status means tharmt the sub= domain is not under the administrative control of any parent domain and the= refore the presence or absence of a domain policy is irrelevant.


    Why is it pr= oblematic to document this risk, and indicate that when "No Policy det= ected" occurs, it is recommended to check whether the domain exists, a= nd if it does not exist then local policy for nonexistent domains should be= applied?

    On Thu, Apr 8, 2021, 11:44 AM Kurt Andersen (b) <kboth@drk= urt.com> wrote:
    On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:=

    "IETF is interested i= n attacks of the form 'otherdomain.nonexistentdomain.psd', but IETF= is not interested in attacks of the form 'nonexistentdomain.otherdomai= n.psd'.

    I don't underst= and your assertion here. Non-existent domains under existing org domains ar= e already covered by the org-level DMARC policy assertion. 5322.From domain= of nosuchdomain.example.com would be treated in accor= d with the policy for example.com.

    --Kurt= =C2=A0
    --000000000000e13d6b05bf78d8e5-- From nobody Thu Apr 8 09:54:08 2021 Return-Path: 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 134403A11E3 for ; Thu, 8 Apr 2021 09:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEr_-7og8aIf for ; Thu, 8 Apr 2021 09:54:05 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B31E3A11E0 for ; Thu, 8 Apr 2021 09:54:05 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id f11so650253vkl.9 for ; Thu, 08 Apr 2021 09:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8G66hxJvO83LZAFu2/euUGwvPChIiJ7q5rbyYe1RSzk=; b=maDuWnFOP4qTMd/CQKRlIDY4IyQRUnMAukCb+d/sMngqk1LpnOeWUVyI9MBsg9lfHV Yil/pzNrkcmEDqWzUbY9SP+kpLl0q1Fb1+SFgrOchJw5DqYZJQKZy8yeI5t0GOsxLQn8 AFfoc4FPbuTwTWNcfe1c41LkDkfOvXXUcKSy9TJLXdh9aZUnTfZtvPt7awydU8oVILtS k0hUemyDsr97484+lHQqQ4G3RMpcY6OQhq0sS2FZeMA0hJ3z6kCgIF1vuTfCr6JjDmU5 S77ji5dqAqeUbGLV3IKk/e+wLfyUHaBliKC3vRSiXwd7lzTRRojbQuydQw8RdQL76Ei0 YDRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8G66hxJvO83LZAFu2/euUGwvPChIiJ7q5rbyYe1RSzk=; b=WkNdXT1xZ94dAzjBGRUWYHlWxa+Wg/K5mQ0h1oPTN6QuD2iSU2BaIw1CBQOAZgPJNd cdLrOn2c5iDjSy2ENzIZu+BmmUipkQ9x6WwEyS88dxgEJVHp6INu9Dqd0c22+yKi1Xmz Ndu1VfvCdh3jgvqFXWTDg49v4andSeukMnD2WcAcyXZ7ul81+oxFJxgWySeJxH3JGSaC W+jI2LXcuhpDpwgdY9xRz8YllKCwvz2WmLYTRNizVzg1gyiVSdd/Xjssi/o9sue2jJTy 3v6Xe+kTePZrGIw6JurscEpqHIFeb+fAtk5/aJO0vnSeAF7o/N6krOPu0mx4W+DnN9vg wPJA== X-Gm-Message-State: AOAM531rl6mWGKax+1OQ4sBOZKQZXyjuuBHp6y/qbH9Q6MCb9tGvSRaz awcdgAMA+4lNdfJH7hA4U6epG7ahBuSodr5ASb0= X-Google-Smtp-Source: ABdhPJw+tEI65onxuMLrv9DTQF59mxKYDh5ZXx74EbUac40bW2d0SRRpC72CY6/Mb32Ke7+clY7KPnZUzEjyRaJjAUY= X-Received: by 2002:a1f:9345:: with SMTP id v66mr7337614vkd.22.1617900843497; Thu, 08 Apr 2021 09:54:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 8 Apr 2021 09:53:52 -0700 Message-ID: To: Douglas Foster Cc: "Kurt Andersen (b)" , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000efdaa05bf78e53f" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 16:54:07 -0000 --0000000000000efdaa05bf78e53f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > Why is it problematic to document this risk, and indicate that when "No > Policy detected" occurs, it is recommended to check whether the domain > exists, and if it does not exist then local policy for nonexistent domains > should be applied? > Can you put together an example message exhibiting the properties you're talking about, and what DNS records are in play in that scenario? I still can't picture the problem you're trying to solve. -MSK --0000000000000efdaa05bf78e53f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Apr 8, 2021 at 9:50 AM = Douglas Foster <d= ougfoster.emailstandards@gmail.com> wrote:
    Why is it p= roblematic to document this risk, and indicate that when "No Policy de= tected" occurs, it is recommended to check whether the domain exists, = and if it does not exist then local policy for nonexistent domains should b= e applied?

    Can you put together= an example message exhibiting the properties you're talking about, and= what DNS records are in play in that scenario?

    I = still can't picture the problem you're trying to solve.
    <= br>
    -MSK
    --0000000000000efdaa05bf78e53f-- From nobody Thu Apr 8 11:29:59 2021 Return-Path: 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 6F8A83A1634 for ; Thu, 8 Apr 2021 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=KFtUwOZD; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZdpNzkpq 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 Y1T3DlxQMz8D for ; Thu, 8 Apr 2021 11:29:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0521A3A162B for ; Thu, 8 Apr 2021 11:29:51 -0700 (PDT) Received: (qmail 76086 invoked from network); 8 Apr 2021 18:29:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=12934.606f4b9d.k2104; bh=fo/dvsOeBa7fFsdZxJ2uKsXtAvbzDegbzbNIURJ9ASo=; b=KFtUwOZDMz92Fw4IHMZuxd3VkzfxQRUscIQJnu6MnXRPUvGr/3sxDbh8RPEZ2RrX7GiZmMdDAwH+DEYgcUuQTz87TGx+budlKm0A5zj4fREPWUl/SV24a8stfrP9Dejvlk10/zl3TO19eg4ENiR5u2YSsJ33PUvDi13kAkNAOAduMfgZKLNS1jat8oug1kiKnQAbTlmzMV1sWXEvMb8traelTwAyqvoceu0Mh+WlnJCTHCqhAWZ9XkAmSMYXCBEWkzn8vHcC8BFIa7w+tc29F1XOqjs0LGSI6vEemeJwk/NPij3si1sfu65wkoj5iOXK71lHx4Px6Ztm05OPxM34Qw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=12934.606f4b9d.k2104; bh=fo/dvsOeBa7fFsdZxJ2uKsXtAvbzDegbzbNIURJ9ASo=; b=ZdpNzkpqt7rRQkRoFDrs0rlgJ1Fk3kylp4Yc3dsIIxKCPb0MeHpomN4kJvn1Be2QXKketutcGKkheDAD3FlAVfOHSFs6Qr1AvkNgnj8mPjEhnYvt+/2VseppcgfI/cOkU8LQz6py66JDINsxYcX9YUgItVNHEufhrfZstS6ZyDNnGugZVp407OcoYOTxGHpGG5LGMTHIP2xfHF/JdfPSFyi5I5dtg9VWUWpP2jJoskBACB8jeMja6iggsFG1FBKoghvCCflEMgXEvpe2VnRIfliyOb24XpAdcetBnvLvHQkxl8obVKvvXYpddh7mdWKCPPVjYVOGK0HJmmL/XHK/Lw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Apr 2021 18:29:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 5E4AF7282ACE; Thu, 8 Apr 2021 14:29:47 -0400 (EDT) Date: 8 Apr 2021 14:29:47 -0400 Message-Id: <20210408182948.5E4AF7282ACE@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 18:29:57 -0000 It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster < >dougfoster.emailstandards@gmail.com> wrote: > >> Why is it problematic to document this risk, and indicate that when "No >> Policy detected" occurs, it is recommended to check whether the domain >> exists, and if it does not exist then local policy for nonexistent domains >> should be applied? >> > >Can you put together an example message exhibiting the properties you're >talking about, and what DNS records are in play in that scenario? > >I still can't picture the problem you're trying to solve. My question would be what does it have to do with DMARC. We already have policies for dealing with non-existent domains unrelated to DMARC. R's, John From nobody Thu Apr 8 13:20:35 2021 Return-Path: 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 67BD73A1B00 for ; Thu, 8 Apr 2021 13:20:34 -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, 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=jbsoft.nl 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 FIBHGGYkzbim for ; Thu, 8 Apr 2021 13:20:30 -0700 (PDT) Received: from alpha.jbsoft.nl (alpha.jbsoft.nl [83.137.149.52]) (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 D81373A1AFF for ; Thu, 8 Apr 2021 13:20:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alpha.jbsoft.nl (Postfix) with ESMTP id 648B327FE42E for ; Thu, 8 Apr 2021 22:20:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alpha.jbsoft.nl Received: from alpha.jbsoft.nl ([83.137.149.52]) by localhost (alpha.jbsoft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dYggJodMnDKi for ; Thu, 8 Apr 2021 22:20:21 +0200 (CEST) Received: from [IPv6:2001:9e0:8705:ed01:2d70:382d:9e3c:e5bb] (unknown [IPv6:2001:9e0:8705:ed01:2d70:382d:9e3c:e5bb]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by alpha.jbsoft.nl (Postfix) with ESMTPSA id 3F59B27FE196 for ; Thu, 8 Apr 2021 22:20:21 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alpha.jbsoft.nl 3F59B27FE196 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jbsoft.nl; s=201607; t=1617913221; bh=cicF3jwOy7N6vGflbMJhatV0sG0NXh7IqwQyDn3cu8U=; h=From:Subject:To:References:Date:In-Reply-To:From; b=RusYi0vFY1VrTa9nbimeeRzKDjEywtFgzk0PMgXzTon4T8+Bz3uuLafEPo/xoV9Vz uPxNfgi2MlqseH0x1WWem+B8YtTkocb0mxUaTVgI0PzTpicd/LS0YP3Ys2Zzyq41Sh zGQVfvFXPlW+QzK9x6ko1ltS7AOmo1xmjQX33n0Dsh0GwRuCogB+rrnp+aseH0+Eiy hPx8u65M8C+hYwyK2lGWQ6zFBEcTF2bGSKc/1gju7OI4/SuaAj8kUSjgjm5krTPrig dvu3n1AgUAoQbdHLhR4qv3TeiIYwhn03wgJ44Wf4gcvO6VFoTTHNnNKu3SiVwaAhnM Inug2uYV2SVfg== From: "Jan Bouwhuis (DMARC)" To: dmarc@ietf.org References: <20210408182948.5E4AF7282ACE@ary.qy> Message-ID: Date: Thu, 8 Apr 2021 22:20:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210408182948.5E4AF7282ACE@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 20:20:34 -0000 You are right, it is a common practice to check on PTR records (https://tools.ietf.org/html/rfc2505). Further for existing not mailing domains rfc7505 https://tools.ietf.org/html/rfc7505 should be used. Mail servers like postfix block connections by default when a null mx record is published. Regards, Jan Bouwhuis Op 8-4-2021 om 20:29 schreef John Levine: > It appears that Murray S. Kucherawy said: >> -=-=-=-=-=- >> >> On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster < >> dougfoster.emailstandards@gmail.com> wrote: >> >>> Why is it problematic to document this risk, and indicate that when "No >>> Policy detected" occurs, it is recommended to check whether the domain >>> exists, and if it does not exist then local policy for nonexistent >>> domains >>> should be applied? >>> >> Can you put together an example message exhibiting the properties you're >> talking about, and what DNS records are in play in that scenario? >> >> I still can't picture the problem you're trying to solve. > My question would be what does it have to do with DMARC. > > We already have policies for dealing with non-existent domains > unrelated to DMARC. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 8 13:49:52 2021 Return-Path: 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 550D53A1CB9 for ; Thu, 8 Apr 2021 13:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fJQWjOuF9IzA for ; Thu, 8 Apr 2021 13:49:39 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7F83A1C73 for ; Thu, 8 Apr 2021 13:49:38 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id u11so1148833uaw.2 for ; Thu, 08 Apr 2021 13:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=HpH4B/9c36rCY+fbBgdCz8ERlCvuPK3oWt94ic21PN4=; b=IHQhfUa6eVDNaYCe2skvLp7aQBE5du0/P5sn2b3GacmScYI5vHLuX8xdRxc1I8UD+S pPdDFMFgaW0ntI2/1LGDvU9Sx377i3NOcUqls9eKNRDIElwNk/RewesCgVwMB9AtbKlm vPpsENQxpVSQW14Jku/er+ZJ5cK7XKcbIHFGGd6mR+lXHCFvx1SLe0zQTD5AODauIQuY /Ftny+wkQrMe9bJjS3YxM1TGDQ1kLCN110avPACezCTQ+HqnTgBrey8Tv/XUONG49hWQ 4x73noIatD94OLGHhfdwGIjgaECkvrj36W25ICs74IvTZsIhLpK/nj/9RIuSmrCrbyY7 jxvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=HpH4B/9c36rCY+fbBgdCz8ERlCvuPK3oWt94ic21PN4=; b=DL08ygszLO/GqaLieKBovobxhcw1YGZH+z6RVGzr25ZYI+ODZSwtn69oD3g8G3eChG WrPJg3jEMCiiMlYrQC+70TGvzrPpki/toEbug50rP/023GwOMbpZL+EG++wTl2vunVt5 5hPeOqHOxAUmKB637tGDHs2TGy6vvsWhABV5Sr/PPlZRFf+Y3ECAKu6hVQwdg6EnIcgQ QQoutGY7kYnmoUdcif4oMBm/erIpKQlDHmQslpEairXnpqauzChvqSM2ZPqWeli3Dstm Cxh9Cvb7TPfQvMN/mdhfJO6FW8p0dtfPpOMnl99KUM999ed+dGX8FqQ6FOOBR5859Ctz tW6g== X-Gm-Message-State: AOAM533zVhAJWIydcrVBf2yfbZihT0iZJevNFLPyBYH7Zq2V87nzMVwY Nyo23OSzbYJAhCWVJ4PSVKACVW74v3JqyGIylVGyVChP5ko= X-Google-Smtp-Source: ABdhPJxoscf3oqDo8JYsQwdTK2Lq18QCRRTvSjtr1QwZ236EptT0sDfj/cgOUCIKed0Z77/ER541/JM3CtXSSC+rYqM= X-Received: by 2002:a9f:2069:: with SMTP id 96mr8987164uam.110.1617914977131; Thu, 08 Apr 2021 13:49:37 -0700 (PDT) MIME-Version: 1.0 References: <20210408182948.5E4AF7282ACE@ary.qy> In-Reply-To: <20210408182948.5E4AF7282ACE@ary.qy> From: Douglas Foster Date: Thu, 8 Apr 2021 16:49:26 -0400 Message-ID: Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007d1f9d05bf7c2ff8" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 20:49:51 -0000 --0000000000007d1f9d05bf7c2ff8 Content-Type: text/plain; charset="UTF-8" DNS Examples that Murray requested, which should also addresses John's question about relevance to DMARC: nslookup > set type=txt > _dmarc.junk.thisisjunk.com *** can't find _dmarc.junk.thisisjunk.com: Non-existent domain Domain has no DMARC policy. Is this because it chose not to deploy one, or because it does not exist? That answer requires a second query. > junk.credcontrol.com *** can't find junk.credcontrol.com: Non-existent domain The TXT query demonstrates that this is a non-existent domain, and therefore not under the full administrative control of any parent domain. The message is DMARC NOT_VERIFIED even if domain alignment occurs with a DKIM signature or SPF PASS. Since there is no domain-level policy record, disposition depends on local policy related to non-existent domains and this particular domain name. The organizational policy record may be useful if its requested action is more stringent than the local policy default action for non-existent domains. > junk.thisisjunk.com *** can't find junk.thisisjunk.com: Non-existent domain Domain has no DMARC policy. Is this because it chose not to deploy one, or because it does not exist? That answer requires a second query. >thisisjunk.com primary name server = ns1.dreamhost.com responsible mail addr = hostmaster.dreamhost.com serial = 2018071003 refresh = 19193 (5 hours 19 mins 53 secs) retry = 1800 (30 mins) expire = 1814400 (21 days) default TTL = 14400 (4 hours) The TXT query demonstrates that the domain exists. This is true whether the result returns data or NODATA, and in this case the result is NODATA. The message can be DMARC-verified using domain alignment to a DKIM Signature or SPF PASS. Doug Foster On Thu, Apr 8, 2021 at 2:30 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster < > >dougfoster.emailstandards@gmail.com> wrote: > > > >> Why is it problematic to document this risk, and indicate that when "No > >> Policy detected" occurs, it is recommended to check whether the domain > >> exists, and if it does not exist then local policy for nonexistent > domains > >> should be applied? > >> > > > >Can you put together an example message exhibiting the properties you're > >talking about, and what DNS records are in play in that scenario? > > > >I still can't picture the problem you're trying to solve. > > My question would be what does it have to do with DMARC. > > We already have policies for dealing with non-existent domains unrelated > to DMARC. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000007d1f9d05bf7c2ff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    DNS Examples that Murray requested, which should also addr= esses John's question about relevance to DMARC:

    nslookup
    <= div>> set type=3Dtxt

    > _dmarc.junk.thisisjunk.com
    *** <server> can't fi= nd _dmarc.junk.thisisjunk.com<= /a>: Non-existent domain
    Domain has no DMARC policy.
    Is= this because it chose not to deploy one, or because=C2=A0it does not exist= ?=C2=A0 =C2=A0That answer requires a second query.

    *** <ser= ver> can't find junk.credcon= trol.com: Non-existent domain
    The TXT=C2=A0query demo= nstrates that this is a non-existent domain,=C2=A0and therefore not under t= he full administrative=C2=A0control of any parent domain.=C2=A0=C2=A0
    =
    The message is DMARC NOT_VERIFIED even if domain alignment occurs with= a DKIM signature or SPF PASS.=C2=A0 Since there is no domain-level policy = record, disposition depends on local=C2=A0policy related to non-existent do= mains and this particular domain name.=C2=A0 =C2=A0 The organizational poli= cy record may be useful if its requested action is more stringent than the = local policy default action for non-existent domains.

    <= div>
    > junk.thisisjunk.com
    *** <ser= ver> can't find junk.thisisju= nk.com: Non-existent domain
    Domain has no DMARC policy.=
    Is this because it chose not to deploy one, or because=C2=A0it doe= s not exist?=C2=A0 =C2=A0That answer requires a second query.

    >thisisjunk.com<= /div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 primary name server =3D ns1.dreamhost.com
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 responsible mail addr =3D hostmaster.dreamhost.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 se= rial =C2=A0=3D 2018071003
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 refresh =3D= 19193 (5 hours 19 mins 53 secs)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 retr= y =C2=A0 =3D 1800 (30 mins)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 expire = =C2=A0=3D 1814400 (21 days)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 default T= TL =3D 14400 (4 hours)
    The TXT=C2=A0query demonstrat= es that the domain exists.=C2=A0 =C2=A0This is true whether the result retu= rns data or NODATA, and in this case the result is NODATA.
    The me= ssage can be DMARC-verified using domain alignment to a DKIM Signature or S= PF PASS.

    Doug Foster

    On Thu, A= pr 8, 2021 at 2:30 PM John Levine <jo= hnl@taugh.com> wrote:
    It appears that Murray S. Kucherawy=C2=A0 <superuser@gmail.com> said:<= br> >-=3D-=3D-=3D-=3D-=3D-
    >
    >On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster <
    >dougfoster.emailstandards@gmail.com> wrote:
    >
    >> Why is it problematic to document this risk, and indicate that whe= n "No
    >> Policy detected" occurs, it is recommended to check whether t= he domain
    >> exists, and if it does not exist then local policy for nonexistent= domains
    >> should be applied?
    >>
    >
    >Can you put together an example message exhibiting the properties you&#= 39;re
    >talking about, and what DNS records are in play in that scenario?
    >
    >I still can't picture the problem you're trying to solve.

    My question would be what does it have to do with DMARC.

    We already have policies for dealing with non-existent domains unrelated to= DMARC.

    R's,
    John

    _______________________________________________
    dmarc mailing list
    dmarc@ietf.org
    https://www.ietf.org/mailman/listinfo/dmarc
    --0000000000007d1f9d05bf7c2ff8-- From nobody Fri Apr 9 06:09:23 2021 Return-Path: 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 21CCE3A209E for ; Fri, 9 Apr 2021 06:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=valimail.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 IHNyv7N3BzQg for ; Fri, 9 Apr 2021 06:09:17 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B823A209B for ; Fri, 9 Apr 2021 06:09:17 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id b139so302949qkc.10 for ; Fri, 09 Apr 2021 06:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=anZ/AMLGn29OhevKuDu1hTkmY0KAH/VdAzg07iqzFuQ=; b=ctSQeOHleBqqAWyafRgfdY/tFyXb0I+TyU6BWoKOptq9ITbGSv4zfhlgdGmDR2NoKB ZK+HPZi4jprYLcXNpbS4x/Ess6rcx62Lk5ESUoVNqkHBk2PRmSNpAoiou8B+p5rJIyxC Htl6KqikElLmvyvANGs5sCUtS1LHT1GVjs7kNZPDtAcPjQdLL+gn6hdE8av5FuVY6XQC bDNJOn9kUd1q9EkQlQMwRkkyyKszfmFUgA+BNwcKJ64xd4nHFxBkAVpxyMJ16zL2cMsD iOop+oyxmM7a5WPbscCcEqdWvez+7sK3cV+zUUReSBAzc+jVHQyL0U45Uovft9KqI5GI ExpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=anZ/AMLGn29OhevKuDu1hTkmY0KAH/VdAzg07iqzFuQ=; b=fZ38h+Yl+JfgPvaFxDGa2cF+0dJGtnYrnnMLjYXjHfXykuZqAp9NFTUPaeYhbSmZQq 9Hje9hSEXHVwrUHLgDvWkTb/M5/PfwNAuDEMVjhkCEA8JWEY12UPa3kprTj8W3UqrklK EXyBm5aZPjUhJ8p3Dmg9Ho+xtNGs5tkebtYODNf4uvXKau8tMMq2R+J4dEuPqvI0zJjV Eixm57hMYMAA2sxFht36MmfdPdfes4Do+diqrgpzl4SRdybpZGcyTPAzdKeO5howEPgb e1DYB3YJF+bhrfQG+RkvI3os7IxBlTcesB2YwCIDFMCILZG0dKbL5O2QvXOhmn3BXRC6 6Gxg== X-Gm-Message-State: AOAM530GxcR9vmrK8qor8Fb6pLLPKPDlyS9tUxcC9kByR51HBonIsR7t L66EJqU0KMijKIIRN0+9PYutbdTI4Bpme8ay498rgqlOJdeIqw== X-Google-Smtp-Source: ABdhPJzNyVz0fII33UUcjaxpCxK+7VAVY0UQ48JMQfUpVQThJLmJZ/UuhtHteVFcd5/ccSRBzt8DPrJQE87GqX1b2v8= X-Received: by 2002:a05:620a:1388:: with SMTP id k8mr7318517qki.387.1617973754756; Fri, 09 Apr 2021 06:09:14 -0700 (PDT) MIME-Version: 1.0 References: <20210408182948.5E4AF7282ACE@ary.qy> In-Reply-To: From: Todd Herr Date: Fri, 9 Apr 2021 09:08:58 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e8923005bf89dec7" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:09:22 -0000 --000000000000e8923005bf89dec7 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > DNS Examples that Murray requested, which should also addresses John's > question about relevance to DMARC: > > nslookup > > set type=txt > > > > _dmarc.junk.thisisjunk.com > *** can't find _dmarc.junk.thisisjunk.com: Non-existent domain > > Domain has no DMARC policy. > Is this because it chose not to deploy one, or because it does not exist? > That answer requires a second query. > > > junk.credcontrol.com > *** can't find junk.credcontrol.com: Non-existent domain > > The TXT query demonstrates that this is a non-existent domain, and > therefore not under the full administrative control of any parent domain. > The message is DMARC NOT_VERIFIED even if domain alignment occurs with a > DKIM signature or SPF PASS. Since there is no domain-level policy record, > disposition depends on local policy related to non-existent domains and > this particular domain name. The organizational policy record may be > useful if its requested action is more stringent than the local policy > default action for non-existent domains. > > > junk.thisisjunk.com > *** can't find junk.thisisjunk.com: Non-existent domain > > Domain has no DMARC policy. > Is this because it chose not to deploy one, or because it does not exist? > That answer requires a second query. > > >thisisjunk.com > primary name server = ns1.dreamhost.com > responsible mail addr = hostmaster.dreamhost.com > serial = 2018071003 > refresh = 19193 (5 hours 19 mins 53 secs) > retry = 1800 (30 mins) > expire = 1814400 (21 days) > default TTL = 14400 (4 hours) > > The TXT query demonstrates that the domain exists. This is true whether > the result returns data or NODATA, and in this case the result is NODATA. > The message can be DMARC-verified using domain alignment to a DKIM > Signature or SPF PASS. > > Doug Foster > > > I think you may have a cut and paste error here: > junk.thisisjunk.com *** can't find junk.thisisjunk.com: Non-existent domain Domain has no DMARC policy. Is this because it chose not to deploy one, or because it does not exist? That answer requires a second query. The above isn't a query for a DMARC policy record. To your larger point though and your claim of a second query being required to determine if a domain exists if there is no published DMARC policy, I think you've got the order of the queries exactly backward. My expectation for any policy rules that are based on a domain's existing and/or a domain having published an MX or A/AAAA record is that such queries will be done *before* any attempt to suss out a DMARC policy record and perform DMARC validation checks, not after. For example: 1. Client connects to my server. At this point I know the source IP of the client, and so I can apply any policy rules I may have in place for the source IP, such as rejecting the connection due to the IP's being blocked, refusing the connection if the IP has no corresponding PTR record, refusing the connection if the PTR record matches a pattern of names from which I don't want to accept mail (such as the naming pattern being generic or indicating that it's dynamic space), perhaps throttling the connection based on a lack of FCrDNS for the IP or other rules based on local reputation data known about the IP. 2. If the connection is still open, the client issues a MAIL FROM command. At this point I now have a domain (RFC5321.From) and I can run checks to make sure the domain exists in the DNS and publishes either an MX or A/AAAA record and do any DNSBL lookups for the domain. I can also, if I wish, do the SPF check here and reject if there's a failure and the record ends in "-all". 3. If the connection is still open, the client issues one or more RCPT TO commands. I can answer "250 ok" or "550 5.1.1 user unknown" as appropriate. 4. If the client has exhausted its RCPT TO commands and has gotten "250 ok" in response to at least one of them, then it will issue a DATA command, and I can respond "ok" if I still potentially want to accept a message from this connection. 5. Client transmits the message, ends with "." 6. Before I reply with "ok", I will definitely do step 1 below, and might do either or both of steps 2 and 3: 1. Test for existence of the RFC5322.From domain in DNS and do any DNSBL lookups on the domain. 2. Run the message through an anti-spam filtering engine, if I'm the type to reject mail based on its content. If instead I'd just route it to the spam folder if the engine says it's spam, I may do this step at a layer closer to my message delivery/storage layer. 3. Do DMARC validation checks, if I'm the type to honor a domain's published policy and reject mail that fails DMARC checks if that's what the policy asks me to do. If instead I'm the type to apply a quarantine disposition to anything with p=reject or p=quarantine, I might accept the message so that the connection can be closed and I can do DMARC processing at a layer closer to my message delivery/storage layer. Now, I could be wrong here, but I've always viewed DNS queries as computationally cheaper than content scanning and DKIM hash validation (note that I'm going to do DKIM hash validation regardless of the existence of a DMARC policy record, but it's all a matter of where in my infrastructure I do the validation). DNS queries that allow me to make an immediate yes/no decision on message acceptance (IP or domain on block list, domain exists and has an MX or A/AAAA record) get done before DNS queries that might cause me to do more work. A DNS query for a DMARC record can result in additional work for me if the DMARC policy record exists, not just going through the validation steps but also recording the results in the data store that supports my reporting engine, so I'm going to do that one last, not first. But that's just me. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000e8923005bf89dec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
    DNS Examples that Mu= rray requested, which should also addresses John's question about relev= ance to DMARC:

    nslookup
    > set type=3Dtxt

    > _dmarc.junk.thisisjunk.com
    *** <server> can't find _dmarc.junk.this= isjunk.com: Non-existent domain
    Domain has no DMARC pol= icy.
    Is this because it chose not to deploy one, or because=C2=A0it doe= s not exist?=C2=A0 =C2=A0That answer requires a second query.
    *** <server> can't find junk.credcontrol.com: Non-exis= tent domain
    The TXT=C2=A0query demonstrates that this is = a non-existent domain,=C2=A0and therefore not under the full administrative= =C2=A0control of any parent domain.=C2=A0=C2=A0
    The message is DM= ARC NOT_VERIFIED even if domain alignment occurs with a DKIM signature or S= PF PASS.=C2=A0 Since there is no domain-level policy record, disposition de= pends on local=C2=A0policy related to non-existent domains and this particu= lar domain name.=C2=A0 =C2=A0 The organizational policy record may be usefu= l if its requested action is more stringent than the local policy default a= ction for non-existent domains.

    > junk.thisisjunk.com
    *** <= server> can't find junk.thisisjunk.com: Non-existent domain
    Domain= has no DMARC policy.
    Is this because it chose not to deploy one, o= r because=C2=A0it does not exist?=C2=A0 =C2=A0That answer requires a second= query.

    =C2=A0 =C2=A0 =C2=A0= =C2=A0 primary name server =3D ns1.dreamhost.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 res= ponsible mail addr =3D hostmaster.dreamhost.com
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 serial =C2=A0=3D 2018071003
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 refre= sh =3D 19193 (5 hours 19 mins 53 secs)
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 retry =C2=A0 =3D 1800 (30 mins)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 e= xpire =C2=A0=3D 1814400 (21 days)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 def= ault TTL =3D 14400 (4 hours)
    The TXT=C2=A0query demo= nstrates that the domain exists.=C2=A0 =C2=A0This is true whether the resul= t returns data or NODATA, and in this case the result is NODATA.
    = The message can be DMARC-verified using domain alignment to a DKIM Signatur= e or SPF PASS.

    Doug Foster


    I think you may have a cut and paste error here:

    >= junk.thisisjunk.c= om
    *** <server> can't find junk.thisisjunk.com: Non-exist= ent domain
    Domain has no DMARC policy.
    Is this because it chose not = to deploy one, or because=C2=A0it does not exist?=C2=A0 =C2=A0That answer r= equires a second query.

    The above i= sn't a query for a DMARC policy record.

    To your larger point though = and your claim of a second query being required to determine if a domain ex= ists if there is no published DMARC policy, I think you've got the orde= r of the queries exactly backward.

    My expectation for any policy rules = that are based on a domain's existing and/or a domain having published = an MX or A/AAAA record is that such queries will be done *before* any attem= pt to suss out a DMARC policy record and perform DMARC validation checks, n= ot after.

    For example:
    1. Client connects to my server. At this poin= t I know the source IP of the client, and so I can apply any policy rules I= may have in place for the source IP, such as rejecting the connection due = to the IP's being blocked, refusing the connection if the IP has no cor= responding PTR record, refusing the connection if the PTR record matches a = pattern of names from which I don't want to accept mail (such as the na= ming pattern being generic or indicating that it's dynamic space), perh= aps throttling the connection based on a lack of FCrDNS for the IP or other= rules based on local reputation data known about the IP.
    2. If the co= nnection is still open, the client issues a MAIL FROM command. At this poin= t I now have a domain (RFC5321.From) and I can run checks to make sure the = domain exists in the DNS and publishes either an MX or A/AAAA record and do= any=C2=A0DNSBL lookups for the domain. I can also, if I wish, do the SPF c= heck here and reject if there's a failure and the record ends in "= -all".
    3. If the connection is still open, the client issues one = or more RCPT TO commands. I can answer "250 ok" or "550 5.1.= 1 user unknown" as appropriate.
    4. If the client has exhausted it= s RCPT TO commands and has gotten "250 ok" in response to at leas= t one of them, then it will issue a DATA command, and I can respond "o= k" if I still potentially want to accept a message from this connectio= n.
    5. Client transmits the message, ends with "."
    6. Be= fore I reply with "ok", I will definitely do step 1 below, and mi= ght do either or both of steps 2 and 3:
      1. Test for existence of t= he RFC5322.From domain in DNS and do any DNSBL lookups on the domain.
        2. <= li>Run the message through an anti-spam filtering engine, if I'm the ty= pe to reject mail based on its content. If instead I'd just route it to= the spam folder if the engine says it's spam, I may do this step at a = layer closer to my message delivery/storage layer.
      2. Do DMARC validat= ion checks, if I'm the type to honor a domain's published policy an= d reject mail that fails DMARC checks if that's what the policy asks me= to do. If instead I'm the type to apply a quarantine disposition to an= ything with p=3Dreject or p=3Dquarantine, I might accept the message so tha= t the connection can be closed and I can do DMARC processing at a layer clo= ser to my message delivery/storage layer.
    Now, I could b= e wrong here, but I've always viewed DNS queries as computationally che= aper than content scanning and DKIM hash validation (note that I'm goin= g to do DKIM hash validation regardless of the existence of a DMARC policy = record, but it's all a matter of where in my infrastructure I do the va= lidation). DNS queries that allow me to make an immediate yes/no decision o= n message acceptance (IP or domain on block list, domain exists and has an = MX or A/AAAA record) get done before DNS queries that might cause me to do = more work. A DNS query for a DMARC record can result in additional work for= me if the DMARC policy record exists, not just going through the validatio= n steps but also recording the results in the data store that supports my r= eporting engine, so I'm going to do that one last, not first.

    But that's just me.

    --

    Todd Herr | S= r. Technical Program Manager
    m: 703.220.4153
    <= div style=3D"text-align:left">
    <= /span>

    T= his email and all data transmitted with it contains confidential and/or pro= prietary information intended solely for the use of individual(s) authorize= d to receive it. If you are not an intended and authorized recipient you ar= e hereby notified of any use, disclosure, copying or distribution of the in= formation included in this transmission is prohibited and may be unlawful. = Please immediately notify the sender by replying to this email and then del= ete it from your system.

    --000000000000e8923005bf89dec7-- From nobody Fri Apr 9 06:49:29 2021 Return-Path: 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 3B6343A21D6 for ; Fri, 9 Apr 2021 06:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, 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=gmail.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 gMs4k_BTSObd for ; Fri, 9 Apr 2021 06:49:23 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5343A21D4 for ; Fri, 9 Apr 2021 06:49:22 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id r20so1841557uam.6 for ; Fri, 09 Apr 2021 06:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UyeoonFpwrOyDDq7p8k/Nu8FEXCNVwa0NDTLCtnAoww=; b=ltvjgpYjKeYjQwQwvVeP2/unJvDMvx+8ypDFQJdqNf1M8t0L3fkT2cJ5Xm+v6UL6cH 7k34dHx+Ux6L5kK9po34/AewsV87dCn4+Nc6HMwqTzJWwPRFVJg2mPgi+8oVAs1C+uKq AIyXMDGudePDj4eZ/0HboVUMoiS6vROEWIdAJv1tzCIzj0mWMmMcOW40s7NfTh6qpVae LC6rYagXfkn42ecZ0D5k3x4Ayb/6/yaHQIttBg6feDm89VYByKknC1AVQQuYUH+ZtrNM sIknNfpeqWvfsNIsbqf8rzBRsqhlNcW3ZIOmLa5qNS3uWYv++3huJ4ZR3v45nSA2yLxl eh1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UyeoonFpwrOyDDq7p8k/Nu8FEXCNVwa0NDTLCtnAoww=; b=RWf6gwAY+aqQtnk/NO7VjLwr6P3E0641pAkeWDyzCgU4K9sbzrC2yWKUhsQvH3zwb4 qSdEerqu8AK2d3wBE2VZk2GNM/a6D7aeLixb+xHsjWGSSRmqYq6FAamztV53OEhi/HOR ANbOYCacsdwQVrR9YkY/3eah+zvZ60yeZQe0tujX2t55neNIt5qmWnijNaNOVl8NaSHm xO+AzOSfIlNT4tdiI2FR7Bu13zwaiDEPDDiKCzLBXdHxfy9ietD5NQqGgxepeh8ODGML CySiXNBz/TW8S9HybEgBKrhpKoQA5dgJJcr6AF+baH/+mebNZIrz7XwoLjfM2n25VR3m bZtw== X-Gm-Message-State: AOAM533tRUc8Z6WZarmfR0J/ubdWw+VWgxEKm+Cfu8Vn5lQWOYz4Wn1t p3vhdAp23WvXShAH/oQkajvaQ+SlvkNvsykR17rFdn2I X-Google-Smtp-Source: ABdhPJxPiNMUsS6eEe9j32tFr7v4au8859e18dvA6mZFpIXCnnihYeLmiOHVMnEMdlzJUluGw3Huky+pym1zgnkTAHQ= X-Received: by 2002:a9f:2c90:: with SMTP id w16mr10868970uaj.88.1617976160573; Fri, 09 Apr 2021 06:49:20 -0700 (PDT) MIME-Version: 1.0 References: <20210408182948.5E4AF7282ACE@ary.qy> In-Reply-To: From: Douglas Foster Date: Fri, 9 Apr 2021 09:49:08 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004e5c9a05bf8a6e27" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:49:28 -0000 --0000000000004e5c9a05bf8a6e27 Content-Type: text/plain; charset="UTF-8" I am happy to have the concept optimized. Your comments make sense to me. I just believe strongly that these documents teach implementers best practices and that this particular document is the time and place to begin teaching best practices around non-existent domains. It is swell that postfix is widely used and responds appropriately to non-existent domains But clearly we have a lot of implementers who need coaching. DF On Fri, Apr 9, 2021, 9:09 AM Todd Herr wrote: > On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> DNS Examples that Murray requested, which should also addresses John's >> question about relevance to DMARC: >> >> nslookup >> > set type=txt >> >> >> > _dmarc.junk.thisisjunk.com >> *** can't find _dmarc.junk.thisisjunk.com: Non-existent domain >> >> Domain has no DMARC policy. >> Is this because it chose not to deploy one, or because it does not >> exist? That answer requires a second query. >> >> > junk.credcontrol.com >> *** can't find junk.credcontrol.com: Non-existent domain >> >> The TXT query demonstrates that this is a non-existent domain, and >> therefore not under the full administrative control of any parent domain. >> The message is DMARC NOT_VERIFIED even if domain alignment occurs with a >> DKIM signature or SPF PASS. Since there is no domain-level policy record, >> disposition depends on local policy related to non-existent domains and >> this particular domain name. The organizational policy record may be >> useful if its requested action is more stringent than the local policy >> default action for non-existent domains. >> >> > junk.thisisjunk.com >> *** can't find junk.thisisjunk.com: Non-existent domain >> >> Domain has no DMARC policy. >> Is this because it chose not to deploy one, or because it does not >> exist? That answer requires a second query. >> >> >thisisjunk.com >> primary name server = ns1.dreamhost.com >> responsible mail addr = hostmaster.dreamhost.com >> serial = 2018071003 >> refresh = 19193 (5 hours 19 mins 53 secs) >> retry = 1800 (30 mins) >> expire = 1814400 (21 days) >> default TTL = 14400 (4 hours) >> >> The TXT query demonstrates that the domain exists. This is true whether >> the result returns data or NODATA, and in this case the result is NODATA. >> The message can be DMARC-verified using domain alignment to a DKIM >> Signature or SPF PASS. >> >> Doug Foster >> >> >> I think you may have a cut and paste error here: > > > junk.thisisjunk.com > > *** can't find junk.thisisjunk.com: Non-existent domain > > Domain has no DMARC policy. > Is this because it chose not to deploy one, or because it does not exist? > That answer requires a second query. > > > The above isn't a query for a DMARC policy record. > > To your larger point though and your claim of a second query being > required to determine if a domain exists if there is no published DMARC > policy, I think you've got the order of the queries exactly backward. > > My expectation for any policy rules that are based on a domain's existing > and/or a domain having published an MX or A/AAAA record is that such > queries will be done *before* any attempt to suss out a DMARC policy record > and perform DMARC validation checks, not after. > > For example: > > 1. Client connects to my server. At this point I know the source IP of > the client, and so I can apply any policy rules I may have in place for the > source IP, such as rejecting the connection due to the IP's being blocked, > refusing the connection if the IP has no corresponding PTR record, refusing > the connection if the PTR record matches a pattern of names from which I > don't want to accept mail (such as the naming pattern being generic or > indicating that it's dynamic space), perhaps throttling the connection > based on a lack of FCrDNS for the IP or other rules based on local > reputation data known about the IP. > 2. If the connection is still open, the client issues a MAIL FROM > command. At this point I now have a domain (RFC5321.From) and I can run > checks to make sure the domain exists in the DNS and publishes either an MX > or A/AAAA record and do any DNSBL lookups for the domain. I can also, if I > wish, do the SPF check here and reject if there's a failure and the record > ends in "-all". > 3. If the connection is still open, the client issues one or more RCPT > TO commands. I can answer "250 ok" or "550 5.1.1 user unknown" as > appropriate. > 4. If the client has exhausted its RCPT TO commands and has gotten > "250 ok" in response to at least one of them, then it will issue a DATA > command, and I can respond "ok" if I still potentially want to accept a > message from this connection. > 5. Client transmits the message, ends with "." > 6. Before I reply with "ok", I will definitely do step 1 below, and > might do either or both of steps 2 and 3: > 1. Test for existence of the RFC5322.From domain in DNS and do any > DNSBL lookups on the domain. > 2. Run the message through an anti-spam filtering engine, if I'm > the type to reject mail based on its content. If instead I'd just route it > to the spam folder if the engine says it's spam, I may do this step at a > layer closer to my message delivery/storage layer. > 3. Do DMARC validation checks, if I'm the type to honor a domain's > published policy and reject mail that fails DMARC checks if that's what the > policy asks me to do. If instead I'm the type to apply a quarantine > disposition to anything with p=reject or p=quarantine, I might accept the > message so that the connection can be closed and I can do DMARC processing > at a layer closer to my message delivery/storage layer. > > Now, I could be wrong here, but I've always viewed DNS queries as > computationally cheaper than content scanning and DKIM hash validation > (note that I'm going to do DKIM hash validation regardless of the existence > of a DMARC policy record, but it's all a matter of where in my > infrastructure I do the validation). DNS queries that allow me to make an > immediate yes/no decision on message acceptance (IP or domain on block > list, domain exists and has an MX or A/AAAA record) get done before DNS > queries that might cause me to do more work. A DNS query for a DMARC record > can result in additional work for me if the DMARC policy record exists, not > just going through the validation steps but also recording the results in > the data store that supports my reporting engine, so I'm going to do that > one last, not first. > > But that's just me. > > -- > > *Todd Herr* | Sr. Technical Program Manager > *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 > --0000000000004e5c9a05bf8a6e27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I am happy to have the concept optimized.=C2=A0 Your comm= ents make sense to me.

    =C2=A0 = I just believe strongly that these documents teach implementers best practi= ces and that this particular document is the time and place to begin teachi= ng best practices around non-existent domains.

    It is swell that postfix is widely used = and responds appropriately to non-existent domains=C2=A0 But clearly we hav= e a lot of implementers who need coaching.

    DF

    On Fri, Apr 9, 2021, 9:09 AM Todd He= rr <todd.herr=3D40valim= ail.com@dmarc.ietf.org> wrote:
    On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
    DNS Examples that Murray requested, which should also a= ddresses John's question about relevance to DMARC:

    nslook= up
    > set type=3Dtxt

    > _dmarc.junk.t= hisisjunk.com
    *** <server> can't find _dmarc.junk.t= hisisjunk.com: Non-existent domain
    Domain has no DMARC = policy.
    Is this because it chose not to deploy one, or because=C2=A0it = does not exist?=C2=A0 =C2=A0That answer requires a second query.
    *** <server> can't = find junk.credcontrol.com: Non-existent domain
    The = TXT=C2=A0query demonstrates that this is a non-existent domain,=C2=A0and th= erefore not under the full administrative=C2=A0control of any parent domain= .=C2=A0=C2=A0
    The message is DMARC NOT_VERIFIED even if domain al= ignment occurs with a DKIM signature or SPF PASS.=C2=A0 Since there is no d= omain-level policy record, disposition depends on local=C2=A0policy related= to non-existent domains and this particular domain name.=C2=A0 =C2=A0 The = organizational policy record may be useful if its requested action is more = stringent than the local policy default action for non-existent domains.

    > junk.thisisjunk.com
    *** <server> can&#= 39;t find junk.thisisjunk.com: Non-existent domain
    Dom= ain has no DMARC policy.
    Is this because it chose not to deploy one= , or because=C2=A0it does not exist?=C2=A0 =C2=A0That answer requires a sec= ond query.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 primary name server =3D ns1.dreamhost.com<= /div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 responsible mail addr =3D hostm= aster.dreamhost.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 serial =C2=A0= =3D 2018071003
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 refresh =3D 19193 (5 h= ours 19 mins 53 secs)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 retry =C2=A0 = =3D 1800 (30 mins)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 expire =C2=A0=3D 1= 814400 (21 days)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 default TTL =3D 1440= 0 (4 hours)
    The TXT=C2=A0query demonstrates that the= domain exists.=C2=A0 =C2=A0This is true whether the result returns data or= NODATA, and in this case the result is NODATA.
    The message can b= e DMARC-verified using domain alignment to a DKIM Signature or SPF PASS.

    Doug Foster


    I think you may have a cut and paste error here:

    >= junk.thisisjunk.com
    *** <server> can't fi= nd junk.thisisjunk.com: Non-existent domain
    Dom= ain has no DMARC policy.
    Is this because it chose not to deploy one, or because=C2=A0it doe= s not exist?=C2=A0 =C2=A0That answer requires a second query.
    <= /div>

    The above isn't a query for a DMARC policy r= ecord.

    To your larger point though and your claim of a second query bein= g required to determine if a domain exists if there is no published DMARC p= olicy, I think you've got the order of the queries exactly backward.
    My expectation for any policy rules that are based on a domain's exist= ing and/or a domain having published an MX or A/AAAA record is that such qu= eries will be done *before* any attempt to suss out a DMARC policy record a= nd perform DMARC validation checks, not after.

    For example:
    1. Clien= t connects to my server. At this point I know the source IP of the client, = and so I can apply any policy rules I may have in place for the source IP, = such as rejecting the connection due to the IP's being blocked, refusin= g the connection if the IP has no corresponding PTR record, refusing the co= nnection if the PTR record matches a pattern of names from which I don'= t want to accept mail (such as the naming pattern being generic or indicati= ng that it's dynamic space), perhaps throttling the connection based on= a lack of FCrDNS for the IP or other rules based on local reputation data = known about the IP.
    2. If the connection is still open, the client iss= ues a MAIL FROM command. At this point I now have a domain (RFC5321.From) a= nd I can run checks to make sure the domain exists in the DNS and publishes= either an MX or A/AAAA record and do any=C2=A0DNSBL lookups for the domain= . I can also, if I wish, do the SPF check here and reject if there's a = failure and the record ends in "-all".
    3. If the connection = is still open, the client issues one or more RCPT TO commands. I can answer= "250 ok" or "550 5.1.1 user unknown" as appropriate.
    4. If the client has exhausted its RCPT TO commands and has gotten &quo= t;250 ok" in response to at least one of them, then it will issue a DA= TA command, and I can respond "ok" if I still potentially want to= accept a message from this connection.
    5. Client transmits the messag= e, ends with "."
    6. Before I reply with "ok", I wi= ll definitely do step 1 below, and might do either or both of steps 2 and 3= :
      1. Test for existence of the RFC5322.From domain in DNS and do a= ny DNSBL lookups on the domain.
      2. Run the message through an anti-spa= m filtering engine, if I'm the type to reject mail based on its content= . If instead I'd just route it to the spam folder if the engine says it= 's spam, I may do this step at a layer closer to my message delivery/st= orage layer.
      3. Do DMARC validation checks, if I'm the type to hon= or a domain's published policy and reject mail that fails DMARC checks = if that's what the policy asks me to do. If instead I'm the type to= apply a quarantine disposition to anything with p=3Dreject or p=3Dquaranti= ne, I might accept the message so that the connection can be closed and I c= an do DMARC processing at a layer closer to my message delivery/storage lay= er.
    Now, I could be wrong here, but I've always view= ed DNS queries as computationally cheaper than content scanning and DKIM ha= sh validation (note that I'm going to do DKIM hash validation regardles= s of the existence of a DMARC policy record, but it's all a matter of w= here in my infrastructure I do the validation). DNS queries that allow me t= o make an immediate yes/no decision on message acceptance (IP or domain on = block list, domain exists and has an MX or A/AAAA record) get done before D= NS queries that might cause me to do more work. A DNS query for a DMARC rec= ord can result in additional work for me if the DMARC policy record exists,= not just going through the validation steps but also recording the results= in the data store that supports my reporting engine, so I'm going to d= o that one last, not first.

    But that's just me= .

    --

    Todd Herr | Sr. Technical Program Manager
    <= div style=3D"text-align:left">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 fo= r the use of individual(s) authorized to receive it. If you are not an inte= nded and authorized recipient you are hereby notified of any use, disclosur= e, 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.<= /p>

    _______________________________________________
    dmarc mailing list
    dmar= c@ietf.org
    https://www.ietf.org/mailman/listinfo/dmarc
    --0000000000004e5c9a05bf8a6e27-- From nobody Fri Apr 9 08:12:53 2021 Return-Path: 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 9B0F93A22F8 for ; Fri, 9 Apr 2021 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=valimail.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 pCuCkCkLXTvC for ; Fri, 9 Apr 2021 08:12:47 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BABB3A227E for ; Fri, 9 Apr 2021 08:12:47 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id o5so6177820qkb.0 for ; Fri, 09 Apr 2021 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R8Fj1K1xaNxAXm7ukiJC03Y0naHwfJu4cSvelA/Zjdk=; b=AdNlz3Yn/2WBzF4H4lzg1cpfpwc1a6JtJi53y2JcH6r7jIx7fGKTWrKyXxDLil7wju 21DKXG8QqoO7NvBkZm62Y3OWIEcCOETedO/pVmZamt4kHcFNXZMy+SuSyqWqtAAePhC8 I4H2/xoV29UDHzxK0khKAlpp/ikODpOl1QzCcNsi1q/MSgcwdX5dTKqDm+DzbrAXw6QN aOzY624+5SDz4Vi/SkRIToRuc/qBfsRRkGPm4tRTTAbSKBJTXbscebYaLakZ9FTjvvEE VE01HRu2iLtJhxTewtraAS6pP2CmUlQFxgFOX9qZPR3S1Gdl1J9dYTe7wW68xFh6gOEO b8Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R8Fj1K1xaNxAXm7ukiJC03Y0naHwfJu4cSvelA/Zjdk=; b=DEc+dqjhvidejBxqxmD7j+ZIsAQDoD2Q/9mLF+9R6vrbqozVukhPqhsiWU6qI/uYoQ wd2WudPutKU1O9WUDiCPBs7feBwnano6OtLvah4P3Vi3W5nuBk5sXKZjbbAAfw4rl1cs lb55huyod9yb368lRNtwMiU0/9xlbn/HBG5eS64xDut0eS5cJaEw6XxbErEeqZooJqEv 6W9KjNMqRF2oiGVaB1v/6jD+ETYfwWQAky0kbLPphK95spSwZboUWDGMCJmLO6oeDLfC B1yTajoALNZNWX7lmTN2O6YzV7OdExSgIg9czs5DJzKH0A8WuRAqgaEHMFaqbvxoYGEj 29BQ== X-Gm-Message-State: AOAM532ekHD4gtz34rWJYZUSLXVLew5cNtWqIITAak2ypo/vmdkMRku1 Wn8hM3o2AHyhPMN9vPMnYlVrzZtbtQY2HNWEbjXKZA== X-Google-Smtp-Source: ABdhPJy5niHThnvMFxKcf+4eIJsr+SWHKCqlsiPQ8zEgMxJv1b0Msw2f6Sx/qXmXtrCpWKE2uxlA4GCX7x6Zjn0u7tY= X-Received: by 2002:a05:620a:1388:: with SMTP id k8mr7912464qki.387.1617981165180; Fri, 09 Apr 2021 08:12:45 -0700 (PDT) MIME-Version: 1.0 References: <20210408182948.5E4AF7282ACE@ary.qy> In-Reply-To: From: Todd Herr Date: Fri, 9 Apr 2021 11:12:28 -0400 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009aad9f05bf8b9871" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:12:52 -0000 --0000000000009aad9f05bf8b9871 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 9, 2021 at 9:49 AM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > I am happy to have the concept optimized. Your comments make sense to me. > > I just believe strongly that these documents teach implementers best > practices and that this particular document is the time and place to begin > teaching best practices around non-existent domains. > > It is swell that postfix is widely used and responds appropriately to > non-existent domains But clearly we have a lot of implementers who need > coaching. > I don't dispute that documenting best practices is a thing to do; I just think that it's a thing for emailcore to do, not dmarc. Consider this paragraph from the charter for emailcore : The working group will also work on an Applicability Statement in parallel with 5321bis and 5322bis, to capture relationships to other documented and widely deployed work (recommended extensions, transport security and other issues from the UTA working group's output, and such) and current email practices. 5321bis and 5322bis will be submitted for publication before this document is finalized, and the "bis" documents will have priority for the working group's attention until they are finished. I don't see similar language in the charter for this group. -- *Todd Herr* | Sr. Technical Program Manager *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. --0000000000009aad9f05bf8b9871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I= am happy to have the concept optimized.=C2=A0 Your comments make sense to = me.

    =C2=A0 I just believe stro= ngly that these documents teach implementers best practices and that this p= articular document is the time and place to begin teaching best practices a= round non-existent domains.

    It is swell that postfix is widely used and responds approp= riately to non-existent domains=C2=A0 But clearly we have a lot of implemen= ters who need coaching.

    =
    I don&= #39;t dispute that documenting best practices is a thing to do; I just thin= k that it's a thing for emailcore to do, not dmarc.

    Consider this pa= ragraph from the charter for emailcore:

    The working group will als= o work on an Applicability Statement in
    parallel with 5321bis and 5322bis, to= capture relationships to other
    documented and widely deployed work (recommen= ded extensions, transport
    security and other issues from the UTA working grou= p's output, and such)
    and current email practices. 5321bis and 5322bis wi= ll be submitted for
    publication before this document is finalized, and the &q= uot;bis" documents
    will have priority for the working group's atte= ntion until they are
    finis= hed.

    I don't = see similar language in the charter for this group.

    --
    <= div dir=3D"ltr">

    Todd Herr | Sr. Technical Program Mana= ger
    m: 703.220.4153

    This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

    --0000000000009aad9f05bf8b9871-- From nobody Fri Apr 9 15:06:07 2021 Return-Path: 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 08A843A1396 for ; Fri, 9 Apr 2021 15:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=gmail.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 6VT2wnLSwoxl for ; Fri, 9 Apr 2021 15:06:01 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297F73A1395 for ; Fri, 9 Apr 2021 15:06:01 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id z23so1130365uan.8 for ; Fri, 09 Apr 2021 15:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D3QqbMLs3QlEhqZffL2KZ0jCFOuhpttUgzrpIP3L74o=; b=QhVJmjtPN29InrMKzPV0Co1Cav3PsX7gE9R1QdCDn0Xx/FYRts1FPQB8jnE7nwz+G3 3uCD7W1/bW8aaj26oiCCgXVJ7ODS0aVyDAJByHeUSbz4jYTFsMhF2F6QEvqHn6TyQoaH n1d9RCiScZK/d9WqFt6QlO06GhR5oYnMrmZMS+wzpCf5q2kdEnqLccnn+nsBDpOTsyWn o3pb0VyPnO9HoxM1Db5rFswjqDuRxGRxhA75tyQCB0V4+Lj3Q/M4qDV/GAZfrfKa2Czq x/zNK4zxkcims69BnOlMqswM2PsSj+E8pqYu3Z9JcoRm1gZ1i8+TlmN6mu44hUcZuljM Lvww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D3QqbMLs3QlEhqZffL2KZ0jCFOuhpttUgzrpIP3L74o=; b=PfbB/k4r12QhJWQdwvFVdRhSVfvJ0zLQXqWCTPtBFXC09QzEeFi14vPotUV4ztbdbX F5qJ0uo4fvMFi/tfJmzBmkGlOE66x+IYQxtmHKYQrSQGPsCZRBho/YuKaHtxm/BW2yQg Z3hAUN+4/nZvrD+u3jNamLDcd2Od3pvlGH4lAMi7e/ok/GTQ/t+ab3EUfuqX2gGFIaGe dTG57TNFwftKzYsdp4IlXaoHN99JTEonTNoML60oEkw3PT9yf/YFPnGlYlR6xqiGjDQ3 FKQoDw2j0CXIW67GlZ76Mj0zY+lWLV2US4Op9oHF7WFNb14v6ysTasOcyFXEnmGGaUMj H6BA== X-Gm-Message-State: AOAM530IpxyLpY4IucG4GIsTJQkA9J587U68sGcQ18BbfdjwqBP3Vwyh 0STh1P5JVMyY2OK2o0qegSJYcNt7sCes7mHuYQ+tmo0h X-Google-Smtp-Source: ABdhPJxRqjheSujd8BybCjIDCcFdxWJuLCQYs49IrnPt+BUg/rLHtHM2SXnfiAuIA3r3PUotxv3QXUY7I9Zkd0wSjdc= X-Received: by 2002:ab0:764f:: with SMTP id s15mr12003296uaq.104.1618005959173; Fri, 09 Apr 2021 15:05:59 -0700 (PDT) MIME-Version: 1.0 References: <20210408182948.5E4AF7282ACE@ary.qy> In-Reply-To: From: Douglas Foster Date: Fri, 9 Apr 2021 18:05:50 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000070e9bb05bf915e44" Archived-At: Subject: Re: [dmarc-ietf] NXDOMAIN X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 22:06:06 -0000 --00000000000070e9bb05bf915e44 Content-Type: text/plain; charset="UTF-8" I see no scope problem with language that states what alignments are not acceptable, but that is the role of the chairs and the design team. I shared what I thought was relevant and new information, and responded to the questions that were asked. I am going silent. On Fri, Apr 9, 2021 at 11:12 AM Todd Herr wrote: > On Fri, Apr 9, 2021 at 9:49 AM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> I am happy to have the concept optimized. Your comments make sense to me. >> >> I just believe strongly that these documents teach implementers best >> practices and that this particular document is the time and place to begin >> teaching best practices around non-existent domains. >> >> It is swell that postfix is widely used and responds appropriately to >> non-existent domains But clearly we have a lot of implementers who need >> coaching. >> > > I don't dispute that documenting best practices is a thing to do; I just > think that it's a thing for emailcore to do, not dmarc. > > Consider this paragraph from the charter for emailcore > : > > The working group will also work on an Applicability Statement in > parallel with 5321bis and 5322bis, to capture relationships to other > documented and widely deployed work (recommended extensions, transport > security and other issues from the UTA working group's output, and such) > and current email practices. 5321bis and 5322bis will be submitted for > publication before this document is finalized, and the "bis" documents > will have priority for the working group's attention until they are > finished. > > > I don't see similar language in the charter for this group. > > -- > > *Todd Herr* | Sr. Technical Program Manager > *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. > --00000000000070e9bb05bf915e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I see no scope problem with language that states what alig= nments are not acceptable, but that is the role of the chairs and the desig= n team.=C2=A0 =C2=A0=C2=A0

    I shared what I thought was r= elevant and new information,=C2=A0and responded to the questions that were = asked.=C2=A0 =C2=A0I am going silent.


    On Fri, Apr 9, 20= 21 at 11:12 AM Todd Herr <todd= .herr@valimail.com> wrote:
    On Fri, Apr 9, 2021 at 9:49 AM Douglas Foster <= ;d= ougfoster.emailstandards@gmail.com> wrote:
    <= div dir=3D"auto">I am happy to have the concept optimized.=C2=A0 Your comme= nts make sense to me.

    =C2=A0 I= just believe strongly that these documents teach implementers best practic= es and that this particular document is the time and place to begin teachin= g best practices around non-existent domains.

    It is swell that postfix is widely used a= nd responds appropriately to non-existent domains=C2=A0 But clearly we have= a lot of implementers who need coaching.

    I don't dispute that documenting best practices is a thing = to do; I just think that it's a thing for emailcore to do, not dmarc.
    Consider this paragraph from the charter for emailcore:

    =
    The working g= roup will also work on an Applicability Statement in
    parallel with 5321bis an= d 5322bis, to capture relationships to other
    documented and widely deployed w= ork (recommended extensions, transport
    security and other issues from the UTA= working group's output, and such)
    and current email practices. 5321bis a= nd 5322bis will be submitted for
    publication before this document is finalize= d, and the "bis" documents
    will have priority for the working group= 's attention until they are
    finished.=

    I don't see similar l= anguage in the charter for this group.

    --

    Todd He= rr | Sr. Technical Program Manager
    m: 70= 3.220.4153

    This email and all data transmitted wit= h it contains confidential and/or proprietary information intended solely f= or the use of individual(s) authorized to receive it. If you are not an int= ended and authorized recipient you are hereby notified of any use, disclosu= re, copying or distribution of the information included in this transmissio= n is prohibited and may be unlawful. Please immediately notify the sender b= y replying to this email and then delete it from your system.=

    --00000000000070e9bb05bf915e44-- From nobody Sun Apr 11 03:06:58 2021 Return-Path: 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 E00EA3A35E2 for ; Sun, 11 Apr 2021 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cS7QbmUr5twW for ; Sun, 11 Apr 2021 03:06:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 8BDBB3A35E1 for ; Sun, 11 Apr 2021 03:06:51 -0700 (PDT) Received: (qmail 94568 invoked by uid 100); 11 Apr 2021 10:00:09 -0000 Date: 11 Apr 2021 09:59:45 -0000 Message-ID: <20210411095945.94564.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 11 06:00:09 2021 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2021 10:06:57 -0000 Count | Bytes | Who ------------+----------------+------- 9 (28.1%) | 129131 (36.3%) | Douglas Foster 6 (18.8%) | 48543 (13.7%) | Murray S. Kucherawy 5 (15.6%) | 84459 (23.8%) | Todd Herr 4 (12.5%) | 17308 ( 4.9%) | John Levine 2 ( 6.2%) | 21049 ( 5.9%) | Grant Taylor 2 ( 6.2%) | 17465 ( 4.9%) | tjw ietf 1 ( 3.1%) | 23185 ( 6.5%) | Laura Atkins 1 ( 3.1%) | 6441 ( 1.8%) | Kurt Andersen (b) 1 ( 3.1%) | 5403 ( 1.5%) | Jan Bouwhuis (DMARC) 1 ( 3.1%) | 2266 ( 0.6%) | Dale Worley via Datatracker From nobody Mon Apr 12 15:25:16 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546E13A11EF; Mon, 12 Apr 2021 15:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <161826631429.14511.7031457134724901407@ietfa.amsl.com> Date: Mon, 12 Apr 2021 15:25:14 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-12.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 22:25:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Experimental DMARC Extension For Public Suffix Domains Authors : Scott Kitterman Tim Wicinski Filename : draft-ietf-dmarc-psd-12.txt Pages : 14 Date : 2021-04-12 Abstract: Domain-based Message Authentication, Reporting, and Conformance (DMARC) permits a domain-controlling organization to express domain- level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling. DMARC distinguishes the portion of a name that is a Public Suffix Domain (PSD), below which organizational domain names are created. The basic DMARC capability allows organizational domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs. Some implementations of DMARC consider a PSD to be ineligible for DMARC enforcement. This specification addresses that case. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-12 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 12 18:08:43 2021 Return-Path: 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 1672F3A19D7 for ; Mon, 12 Apr 2021 18:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, 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=gmail.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 05pCFLBPyRkK for ; Mon, 12 Apr 2021 18:08:32 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1A53A19C7 for ; Mon, 12 Apr 2021 18:08:31 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id b18so2516094vso.7 for ; Mon, 12 Apr 2021 18:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=B7NSJ2TkPN8B+jx7BYyxAQJh4wM8czZZ/P4rUf8GGPE=; b=Q9GHpGKdWYXSUukdnsTbl5P2jBqeGiLqi5ZYp2udmwVbH9pYAWVYfG7jdDVAnlUFGV wEIr5JrNuw1R44psqsKpIOQPgEAo5leoyew8T2tUvwSbCDwE/8ZQ4zodzdpQCSJZFKmn +FlP5m6hBnJmI8+QAJvXpsWi5kqIZqlkEwd63HehTGtsGDtZ+FwQ3JZvhNvQYflR9pet QHvPS5tUu5bJiRdQQm/27BCv/p3NyRpvvrVo2Lnsy5bmmOZRMiMflNsuF1ldZF1v81j9 rJDIPicnKucMYsf7krkWgwVUuEvnum7HbECxV/rIim0mqT7NhFWNdvHoZS5WHst18T1m Uhuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=B7NSJ2TkPN8B+jx7BYyxAQJh4wM8czZZ/P4rUf8GGPE=; b=cUVSSkMlvfxA8oT3iw30F8mJLLiLVl74ZyS1+M1fyQ3paSOFBtMooKQIV8FM9K7esj FMLQKV5olpMtOQjX8au60PPBUod35iyN+o5nS+FcKtuodiHkJNrX8YJ5/EDP0ddPnMEX 8byewQmue7RsO6w4QP496e2aH+UnxeJto3sssm2LDZxBZz5buVN5W/RS5YhYBmUgb5ah 2dfBaUGGKDkeNL8s7QeN6opmFOEvv2pnvaYHviqX/hUZXykdArZFLTfhwCT8Gp+/cg90 k/DUe4HTf8iFCOQ4eDrPeBrHTt7XHt6ZaowqedcjALKIfDg4m9ELpO3cjPpiqU66HMA+ HExA== X-Gm-Message-State: AOAM532S0YH93qWTRIkJvbo5y2tF4l04//mFqBdSg69aRjYFTLnYXkKR u46r08Z5SapRb9BwlzdWwIS//WLzYK1S1vTEqhtQbhIVxao= X-Google-Smtp-Source: ABdhPJwvAa3azyCov8M9ap48YUpwssTjlBrF6cSSnj+16DXAUVGRGQqzAeVHIG99y0MOEuqbNrvEj6r6UHSUKe0NJnY= X-Received: by 2002:a67:4c6:: with SMTP id 189mr22137585vse.0.1618276110447; Mon, 12 Apr 2021 18:08:30 -0700 (PDT) MIME-Version: 1.0 References: <161826631429.14511.7031457134724901407@ietfa.amsl.com> In-Reply-To: <161826631429.14511.7031457134724901407@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Mon, 12 Apr 2021 18:08:19 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b6376805bfd044f5" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-12.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 01:08:42 -0000 --000000000000b6376805bfd044f5 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 12, 2021 at 3:25 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Experimental DMARC Extension For Public Suffix > Domains > Authors : Scott Kitterman > Tim Wicinski > Filename : draft-ietf-dmarc-psd-12.txt > Pages : 14 > Date : 2021-04-12 > > Abstract: > Domain-based Message Authentication, Reporting, and Conformance > (DMARC) permits a domain-controlling organization to express domain- > level policies and preferences for message validation, disposition, > and reporting, which a mail-receiving organization can use to improve > mail handling. > > DMARC distinguishes the portion of a name that is a Public Suffix > Domain (PSD), below which organizational domain names are created. > The basic DMARC capability allows organizational domains to specify > policies that apply to their subdomains, but it does not give that > capability to PSDs. This document describes an extension to DMARC to > fully enable DMARC functionality for PSDs. > > Some implementations of DMARC consider a PSD to be ineligible for > DMARC enforcement. This specification addresses that case. > [...] > Thanks. This is now in IESG Evaluation and will probably make the next telechat (on the 22nd). -MSK --000000000000b6376805bfd044f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Mon, Apr 12, 2021 at 3:25 PM <internet-drafts@ietf.org> wro= te:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Experimental DMARC Extension For Public Suffix Domains
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Scot= t Kitterman
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tim Wicinski
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-psd-12.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-04-12

    Abstract:
    =C2=A0 =C2=A0Domain-based Message Authentication, Reporting, and Conformanc= e
    =C2=A0 =C2=A0(DMARC) permits a domain-controlling organization to express d= omain-
    =C2=A0 =C2=A0level policies and preferences for message validation, disposi= tion,
    =C2=A0 =C2=A0and reporting, which a mail-receiving organization can use to = improve
    =C2=A0 =C2=A0mail handling.

    =C2=A0 =C2=A0DMARC distinguishes the portion of a name that is a Public Suf= fix
    =C2=A0 =C2=A0Domain (PSD), below which organizational domain names are crea= ted.
    =C2=A0 =C2=A0The basic DMARC capability allows organizational domains to sp= ecify
    =C2=A0 =C2=A0policies that apply to their subdomains, but it does not give = that
    =C2=A0 =C2=A0capability to PSDs.=C2=A0 This document describes an extension= to DMARC to
    =C2=A0 =C2=A0fully enable DMARC functionality for PSDs.

    =C2=A0 =C2=A0Some implementations of DMARC consider a PSD to be ineligible = for
    =C2=A0 =C2=A0DMARC enforcement.=C2=A0 This specification addresses that cas= e.
    [...]

    Thanks.=C2=A0 This is now in IESG= Evaluation and will probably make the next telechat (on the 22nd).

    -MSK

    --000000000000b6376805bfd044f5-- From nobody Tue Apr 13 05:27:56 2021 Return-Path: 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 205F33A12B5 for ; Tue, 13 Apr 2021 05:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ftld.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 6Ax-Gvr339DT for ; Tue, 13 Apr 2021 05:27:49 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5023A138A for ; Tue, 13 Apr 2021 05:27:49 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id g18-20020a7bc4d20000b0290116042cfdd8so10573343wmk.4 for ; Tue, 13 Apr 2021 05:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uuj4FW/sBopigyLDKfDkwxhRcXImwQFIPvAuZAY0EYI=; b=5vL7v3AVoAMEDkImaMQ3XqVIOmZP+VXz9PAgf2OCdQ/N/+k+MFHCc9HwijwOBCQSMl bOgcb73hyISh3vBy9WB7gCQzLRSy13Ndlhs8uoQ18pdOa9geipnkGU+ZEHNax5pl355R tZ+7wflSJYbC0zkuuryLqrodXytljOfbddTLQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uuj4FW/sBopigyLDKfDkwxhRcXImwQFIPvAuZAY0EYI=; b=qBjb6BbnEYoPoszLPf3h3X/x6tIMJEwR1/31PS/a42BzqgVbLkv/lNNnncj100qThx vEa/IFLeWDFUuhbVfvfvg7CrSaxdTAYY17AafVqnx2/kpDsgsNHllsUIzIoVBlO7HRWB FP/RjSKYS5MPOm6H66rrW3rLfCBypDPv19iJKRUeUd5KiDGic9AY14itKGjsUavfRUrN CFK/dsVjdGQUMQudf0sYHoUHbGevKc1W0M3jDVRlEuSqkSuOMuiIgC/aRlGajBcnQF7G SSSdwX1y2DGIO6GjNPc3ZmnPD7B1Lm4jE2Ic60FUK8NClG8IecW36L4pnjdg9gZFxtFw hliA== X-Gm-Message-State: AOAM533x/V3LdJXddMmEdHqzAo1Vw0+GC63jUVDWogF6ECjFr87pA68i AuXJGC+5qWWaIy/5WBNYnloTFzETjsPBzodrSfJz8pWKGo4= X-Google-Smtp-Source: ABdhPJzMPOEpZM0b75+C29PRzK5hEkQfWSD8Uu0hKa0h7LHXB2kDhsIekb7CW8DkMekedxABxjwIJKkEUam5SEv9ez4= X-Received: by 2002:a1c:65c2:: with SMTP id z185mr3990171wmb.2.1618316860894; Tue, 13 Apr 2021 05:27:40 -0700 (PDT) MIME-Version: 1.0 References: <161826631429.14511.7031457134724901407@ietfa.amsl.com> In-Reply-To: <161826631429.14511.7031457134724901407@ietfa.amsl.com> From: Craig Schwartz Date: Tue, 13 Apr 2021 08:27:30 -0400 Message-ID: To: IETF DMARC WG Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000a0c2f505bfd9c1b0" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-12.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 12:27:54 -0000 --000000000000a0c2f505bfd9c1b0 Content-Type: text/plain; charset="UTF-8" It's good to see this work progressing. For the sake of clarity and transparency, .bank and .insurance are listed in Appendix B, Part 2, however fTLD Registry (the PSO) does not currently have permission from ICANN to add a DMARC record to the DNS of these PSDs. The purpose for kicking off this work in mid-2018 is to seek ICANN's approval to participate in this experiment and going to them with an RFC# will assist in advancing discussions with them. Thanks very much. Craig Schwartz Managing Director fTLD Registry Services - .BANK and .INSURANCE On Mon, Apr 12, 2021 at 6:25 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Experimental DMARC Extension For Public Suffix > Domains > Authors : Scott Kitterman > Tim Wicinski > Filename : draft-ietf-dmarc-psd-12.txt > Pages : 14 > Date : 2021-04-12 > > Abstract: > Domain-based Message Authentication, Reporting, and Conformance > (DMARC) permits a domain-controlling organization to express domain- > level policies and preferences for message validation, disposition, > and reporting, which a mail-receiving organization can use to improve > mail handling. > > DMARC distinguishes the portion of a name that is a Public Suffix > Domain (PSD), below which organizational domain names are created. > The basic DMARC capability allows organizational domains to specify > policies that apply to their subdomains, but it does not give that > capability to PSDs. This document describes an extension to DMARC to > fully enable DMARC functionality for PSDs. > > Some implementations of DMARC consider a PSD to be ineligible for > DMARC enforcement. This specification addresses that case. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-psd-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-12 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000a0c2f505bfd9c1b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It's good to see this work pr= ogressing. For the sake of clarity and transparency, .bank and .insurance a= re listed in Appendix B, Part 2, however fTLD Registry (the PSO) does not c= urrently have permission from ICANN to add a DMARC record to the DNS of the= se PSDs. The purpose for kicking off this work in mid-2018 is to seek ICANN= 's approval to participate in this experiment and going to them with an= RFC# will assist in advancing discussions with them.

    Thanks very much.= =C2=A0 =C2=A0

    Craig S= chwartz
    Managing Director
    fTLD Registry Services - .BANK and .INSURANCE
    <= div>



    <= /div>


    On Mon, Apr 12, 2021 at 6:25 PM <internet-drafts@ietf.org> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Experimental DMARC Extension For Public Suffix Domains
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Scot= t Kitterman
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tim Wicinski
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-psd-12.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-04-12

    Abstract:
    =C2=A0 =C2=A0Domain-based Message Authentication, Reporting, and Conformanc= e
    =C2=A0 =C2=A0(DMARC) permits a domain-controlling organization to express d= omain-
    =C2=A0 =C2=A0level policies and preferences for message validation, disposi= tion,
    =C2=A0 =C2=A0and reporting, which a mail-receiving organization can use to = improve
    =C2=A0 =C2=A0mail handling.

    =C2=A0 =C2=A0DMARC distinguishes the portion of a name that is a Public Suf= fix
    =C2=A0 =C2=A0Domain (PSD), below which organizational domain names are crea= ted.
    =C2=A0 =C2=A0The basic DMARC capability allows organizational domains to sp= ecify
    =C2=A0 =C2=A0policies that apply to their subdomains, but it does not give = that
    =C2=A0 =C2=A0capability to PSDs.=C2=A0 This document describes an extension= to DMARC to
    =C2=A0 =C2=A0fully enable DMARC functionality for PSDs.

    =C2=A0 =C2=A0Some implementations of DMARC consider a PSD to be ineligible = for
    =C2=A0 =C2=A0DMARC enforcement.=C2=A0 This specification addresses that cas= e.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-dm= arc-psd/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-dmarc-psd-= 12
    https://datatracker.ietf.org/doc/html/d= raft-ietf-dmarc-psd-12

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-dmarc-psd-12


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/


    _______________________________________________
    dmarc mailing list
    dmarc@ietf.org
    https://www.ietf.org/mailman/listinfo/dmarc
    --000000000000a0c2f505bfd9c1b0-- From nobody Wed Apr 14 01:44:44 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D753A1590; Wed, 14 Apr 2021 01:44:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <161838987873.7792.14994930450767048926@ietfa.amsl.com> Date: Wed, 14 Apr 2021 01:44:38 -0700 Archived-At: Subject: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 08:44:39 -0000 Lars Eggert has entered the following ballot position for draft-ietf-dmarc-psd-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3, paragraph 2, comment: > 3. PSD DMARC Updates to DMARC Requirements > > This document updates DMARC as follows: If I understand things correctly, this document specifies an experiment that - if successful - would lead to an update of RFC7489. It's therefore confusing to see the text in Section 3 that is written as if that update was already being brought into effect. I'd much prefer text that said things like "to participate in this experiment, implementations should do X or Y or Z and/or interpret Section foo of RFC7489 as bar", etc. Section 7.3, paragraph 1, comment: > 7.3. URIs It's unusual for an RFC to have reference sections other than for normative and informative references, because it's not clear what category references here would fall into. Also, I'll note that [psddmarc.org] was cited as an informative reference in that section, so why not this one? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 3.2, paragraph 3, nit: > to that of the "p" tag defined below. If the 'np' tag is absent, The document uses both single and double quotes throughput (above is an example), and it's not clear if this is deliberate (i.e., there is a meaning to this) or whether this is an editorial oversight that should be corrected. Section 6.1, paragraph 5, nit: > +----------+-----------+---------+-------------------------------+ > | Tag Name | Reference | Status | Description | > +----------+-----------+---------+-------------------------------+ > | np | this | current | Requested handling policy for | > | | document | | non-existent subdomains | > +----------+-----------+---------+-------------------------------+ > You should add an RFC Editor Note instructing them to replace "this document" with the RFC number of this document (to make sure they are aware of the action). Section 1, paragraph 2, nit: - DMARC ([RFC7489]) provides a mechanism for publishing organizational - - - + DMARC [RFC7489] provides a mechanism for publishing organizational Section 1, paragraph 3, nit: - found in Section 3.2 of the DMARC specification. Currently the + found in Section 3.2 of the DMARC specification. Currently, the + + Section 1, paragraph 4, nit: - In the basic DMARC model, PSDs are not organizational domains and are + In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains and are + +++++++++++++++++++++++ + Section 1.2, paragraph 7, nit: - handling policy for non-existent subdommains. This is provided - - + handling policy for non-existent subdomains. This is provided Section 1.2, paragraph 7, nit: - of requesting harsh policy treatment (e.g. reject) is lower. + of requesting harsh policy treatment (e.g., reject) is lower. + + Section 1.2, paragraph 8, nit: - (i.e. if a DMARC record were published for 'example', then mail from + (i.e., if a DMARC record were published for 'example', then mail from + + Section 2.7, paragraph 2, nit: - is a broader definition than that in NXDOMAIN [RFC8020]. - --------- + is a broader definition than that in [RFC8020]. Section 4.1, paragraph 7, nit: - not particpate in DMARC, any Feedback Reporting related to multi- + not participate in DMARC, any Feedback Reporting related to multi- + + "B.3.", paragraph 3, nit: - supposed to be the output domain of the regular PSL lookup, i.e. the + supposed to be the output domain of the regular PSL lookup, i.e., the + + From nobody Wed Apr 14 01:57:17 2021 Return-Path: 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 41FA33A168D; Wed, 14 Apr 2021 01:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=eggert.org 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 rnP4hziqmH2u; Wed, 14 Apr 2021 01:57:10 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A843A168F; Wed, 14 Apr 2021 01:57:09 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:58b8:dd01:5c90:2248] (unknown [IPv6:2a00:ac00:4000:400:58b8:dd01:5c90:2248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C188D600336; Wed, 14 Apr 2021 11:56:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1618390612; bh=JmSojSveaYD1vMlMRJ4V46n89O6ytVVbMys8NlujkL4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=DHx2MTI5/8YnOBySDlcoRoPtqxMCieJZr7zc+NXxQ5Xu7q3cKb04GKEeIXmtQePbs 3GHZ8FQ0qMie6vtW4jIUjiGZnnEQJu7gkahudXN8Y3fDOHyNlkJn9jswsbNwipjLLb tr3ToHPh557tMdULYSt0T6/2XHA29II3ggLzoaUc= From: Lars Eggert Message-Id: <7A75824F-C895-44BB-A773-9FCB5FCBEDD0@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_29730CD6-E009-4A05-91BD-9851B2525624"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 14 Apr 2021 11:56:52 +0300 In-Reply-To: <161766760964.377.5520471023381576197@ietfa.amsl.com> Cc: gen-art@ietf.org, last-call@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org To: Dale Worley References: <161766760964.377.5520471023381576197@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: C188D600336.A1A3B X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [dmarc-ietf] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-11 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 08:57:14 -0000 --Apple-Mail=_29730CD6-E009-4A05-91BD-9851B2525624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dale, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-4-6, at 3:06, Dale Worley via Datatracker = wrote: >=20 > Reviewer: Dale Worley > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: review-draft-ietf-dmarc-psd-08 > Reviewer: Dale R. Worley > Review Date: 2020-04-05 > IETF LC End Date: 2020-04-05 > IESG Telechat date: not known >=20 > Summary: >=20 > This draft is ready for publication as a Experimental RFC >=20 > The -11 version is far clearer (to the naive) than the -08 version. >=20 > [END] >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_29730CD6-E009-4A05-91BD-9851B2525624 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmB2rlQACgkQVLXDCb9w wVcqTQ//UI7rGpHTV2GkSRi+ujeFJVGIuqAjYl6+L3jckgV6uloA5nLh8d+IDyRI 6iLlPWU3I5LtNLJfb/pxENhN/XfTLvuW4usnrMSx3odC6eLPEqAYWJK1kpNwsrKi szYIay4+51pc+ab4WScVgoe21wwFGuSddLCiOUTubCW6YJ1Zi0NA2VeXoX236AR3 nCyP9M+jDwbuXrS+MWtI0PDglX5ElMfjWTIU7oEXLoNvmqECt+4arPPMI9FwySqP x045RBCFVIBV1JAyhx96WkuAdEirRq+BomhFdOo9m34wh+xwcItPauV4ihKgf7lj xPnf9J5WzZaNvZjy+rF0WkKrcrdEQ0LkGShJJ4btlr6Cy/pQFYRtXYTJkAzn8t3l tWykAkWqk4bA44fo4PMTLCIjZAJiUkXGJB4K6KYzu6SErrFd7vqlizESuOTuHM2w 2JraoDQ4cynGknaB0kRQ2+4jR6CaIFzId0rKfsMj4g6erTiN8kXBeVxJzaxFkIrw JgBRoWlTt5KKU+auJ6ZLrNm/ekbCYpvkvtUxZFiH7+N3Cfr81WdBubMUu4ODRmcN b05liWK8hTj4j9X9ZD4r/uTlRdB1jcVODSDYtDnKoxYxhl5SQY2Os4jsa2lUFp1g BM6ziAJT40gkcKgAOQDgMqjXJviNMwk+/cPcmASy+5q3eF3qEDQ= =ohUs -----END PGP SIGNATURE----- --Apple-Mail=_29730CD6-E009-4A05-91BD-9851B2525624-- From nobody Wed Apr 14 10:06:40 2021 Return-Path: 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 CB4CC3A17FB for ; Wed, 14 Apr 2021 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7-osBxdTr0e for ; Wed, 14 Apr 2021 10:06:33 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7903A17A1 for ; Wed, 14 Apr 2021 10:06:33 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id r8so6618319ual.9 for ; Wed, 14 Apr 2021 10:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cVG8JXspZZtwfU0/H+MdKP/aKs8bYdH2UyEnrZe++9A=; b=hqOfeDH0dZJRYHnMfAHQaGpcFSAZtJQRpiBkCQ5Cqx6DD6uLmgA7x77DemrPT0cxWS ZJInN02H/hGQs2IcJ0tGmh2APdjYsRDElSAnArA9aPqQocrFWOB63Jinw1jVMYR3zcIf XBhmJY01MWX+Hwa/rrz9tBPG7w5JLe6nj/Py6nEeIpHst75NuQD1pwPVmzTF9JnFAPnk SY1Lk4QGHjx1M9cOfGyejQXCDarFW7XMpRtaxYIGby8PjOW1XdP4VkQyY5rUT2/DUSLc Iwhhfy9m7kcKJMnQpXeMq1or3hO925yLjongdic3zb4Dg995vi2U4+1gC/dhcGrKzJRM 8/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cVG8JXspZZtwfU0/H+MdKP/aKs8bYdH2UyEnrZe++9A=; b=P5usxqREzv3FCJ3QfV4ZZWwSXKDKwhfEsRJ3BnJxsp0fF7unu8ihI06oZ14w6QTm8B 5+xHP5YBiecK08Qvuwk7f7HGTKcw6COopikqMPFDMY2JBz7eYJyyaqskd8Kk/Gvp/Yqd kjQAEu9d5vUAbgXji07j+l64cI/c++N+sFkJrjde7DBk114c9X7iXmHBmq/Qm85HgN9M yKA6qan6VOBKgaWlCQpqmgLMFHtjJfMJy256LuiC0XFyezSaRiAgOdDFq/SpMRH92wol /9bVh4g4hxVKbW9zj5CiojzX4taP/2BwP7juZiPuPl4cLa27dNQ6E6XfkG4ZkQyU0wmJ 2mbw== X-Gm-Message-State: AOAM532Pk+FxLj2vAhchgkHm0EThO0NtXTmhhE+LKGsJC6ebY2WBOVHB WD4ZdWHm4DD04VhqFZJr1VfdKld1/VxZa41Q1yX9ArDagFdhnw== X-Google-Smtp-Source: ABdhPJz9zSNp/DM/1vnOcqsIc/fvlpui/WLSDMUIRMmti1HH8j8/jqOHn8ERSi/o7jiJ1nqvyi5oKPSO/udxUNzxFAQ= X-Received: by 2002:ab0:2441:: with SMTP id g1mr11062757uan.76.1618419990645; Wed, 14 Apr 2021 10:06:30 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Wed, 14 Apr 2021 10:06:19 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a3cd6805bff1c4f7" Archived-At: Subject: [dmarc-ietf] Chair rotation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 17:06:39 -0000 --000000000000a3cd6805bff1c4f7 Content-Type: text/plain; charset="UTF-8" Colleagues, As Barry has stepped down from the IESG, he's available to re-engage in other roles. He has generously volunteered to invest time and energy in the DMARC WG to carry the torch once the design teams complete their work in the near future. With much gratitude to all of the current chairs for managing this working group, I will be rotating Alexey and Tim out so they can focus on other things with their limited time, and bringing in Barry. Alexey, I suspect, needs all available bandwidth for EMAILCORE. I know Tim is also a busy man with DNSOP. Seth, now free of the work that is EMAILCORE, will remain. Thank you once again, -MSK, your friendly neighborhood ART AD --000000000000a3cd6805bff1c4f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Colleagues,

    As Barry has stepped down from the= IESG, he's available to=20 re-engage in other roles.=C2=A0 He has generously volunteered to invest tim= e and energy in the DMARC WG to carry the t= orch once the design teams complete their work in the near future.

    With much gratitude to all of the current chairs for managing this working=20 group, I will be rotating Alexey and Tim out so they can focus on other things with their limited time, and bringing in Barry.=C2=A0 Alexey, I=20 suspect, needs all available bandwidth for EMAILCORE.=C2=A0 I know Tim is= =20 also a busy man with DNSOP.=C2=A0 Seth, now free of the work that is EMAILC= ORE, will=20 remain.

    Thank you once again,

    =
    -MSK, your friendly neighborhood ART AD
    --000000000000a3cd6805bff1c4f7-- From nobody Thu Apr 15 00:17:40 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A79E63A12FD; Thu, 15 Apr 2021 00:17:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161847105823.12240.11886353486421150693@ietfa.amsl.com> Date: Thu, 15 Apr 2021 00:17:38 -0700 Archived-At: Subject: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 07:17:39 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dmarc-psd-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is easy to read and specify an experiment, which could be useful. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Sections 1 and 3-- I share Lars' concern about the "update" in the last paragraph. -- Section 5.1 -- Editorial comment: why using a sub-section ? Let's 'glue' its contents to the first § of section 5. BTW, interesting read this section. == NITS == -- Section 2.2 -- Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr https://www.rfc-editor.org/materials/abbrev.expansion.txt -- Sections 2.2 ... 2.7 -- Mostly cosmetic but I would have preferred the usual presentation to introduce terminology, i.e., a list and not several sub-sections. From nobody Thu Apr 15 16:45:22 2021 Return-Path: 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 A10FE3A34B8; Thu, 15 Apr 2021 16:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=gmail.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 tHj2cgLvOF3s; Thu, 15 Apr 2021 16:45:16 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D123A34B6; Thu, 15 Apr 2021 16:45:15 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id c15so21673413ilj.1; Thu, 15 Apr 2021 16:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=of5/Qpp3otPM/ENd8na2UfHALUqlp1WgvCgLutlh63g=; b=vVRcKY5b5fSUNaucvUaoLaT5/Ags3w0hjueMnV2sL6VEeSD6UEp2MX00ZEt/xTHg/b uZpFL6wYDzOf7X7ljZQcSxbqY0+18TeoflUJk/ylsZL7un30JgI0xRVBukV+FhqM0MRz vLyxVfzTMoW4He7CTCFREnl4JWmg6MNM2qxqZLWVyGzMkcmLL5HfgGl9vDccDcAC7AYc mkYG3Xs+3uiIgw5U17bm/OFFshN3iteqxHat93YRolgcoUmRM+kaKR04OoyLBzrLNYPp j3VeLYNyGepwJHCmyhydauB6BOIz0g2YGr4bZ4Rr+xtT9IywBP2VZ8Nns5KYriY/M2ur 0QiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=of5/Qpp3otPM/ENd8na2UfHALUqlp1WgvCgLutlh63g=; b=VXJ5++L5oWOgMa3yjiJ1mpEhSuOUTlVJbKtQEPqXLqoCvNcg9NnESSW8b1c/rtD09u fm7lzLdpwtTXV28O6Pd0dWcDII9SVjAbVTIXGcCB1/V6NiLUm2NfngJ/a1YXiLdwo8l8 WcuyGuXwEJvrk0E0rfMLQL7Ff/suPNm0Ap+JS3jdNxa/e9uDYsCef1m1ehY7/GuDNPb7 QpbAcopWEJckkYQ1FsdGNeCOCiruWC1esEvlLRh75AtasOuaMJzwyFsd804IOgavnsOL ZDvThGNMVSi5z1/sfCUsmaH8MgCtGticMKtHL3Jc+weKjPP72Qxs1C3c1afQIlu3vdsW gI4w== X-Gm-Message-State: AOAM533lWhzWUqhfRCXe6Q3NEOwcDtuDPHYqVnnUBaNRwB/KtwBFZ7DR OX1ihrd5k+nV/HDY0DOMQjdsWBHDq7IkpXhIMZw= X-Google-Smtp-Source: ABdhPJxN+sVvegI+zu80lQadSicJyHvjlK69+e8dptPQYAecQ2/W1g2085/kBbzEDzu9sK4WFm0nGNoiwG3DHkscyK4= X-Received: by 2002:a05:6e02:1e08:: with SMTP id g8mr4799200ila.176.1618530312495; Thu, 15 Apr 2021 16:45:12 -0700 (PDT) MIME-Version: 1.0 References: <161838987873.7792.14994930450767048926@ietfa.amsl.com> In-Reply-To: <161838987873.7792.14994930450767048926@ietfa.amsl.com> From: Tim Wicinski Date: Thu, 15 Apr 2021 19:45:00 -0400 Message-ID: To: Lars Eggert Cc: The IESG , draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="00000000000055a5aa05c00b74d0" Archived-At: Subject: Re: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 23:45:21 -0000 --00000000000055a5aa05c00b74d0 Content-Type: text/plain; charset="UTF-8" Lars See below. Thanks for the comments On Wed, Apr 14, 2021 at 4:44 AM Lars Eggert via Datatracker < noreply@ietf.org> wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-dmarc-psd-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3, paragraph 2, comment: > > 3. PSD DMARC Updates to DMARC Requirements > > > > This document updates DMARC as follows: > > If I understand things correctly, this document specifies an experiment > that - > if successful - would lead to an update of RFC7489. It's therefore > confusing to > see the text in Section 3 that is written as if that update was already > being > brought into effect. I'd much prefer text that said things like "to > participate > in this experiment, implementations should do X or Y or Z and/or interpret > Section foo of RFC7489 as bar", etc. > > "To participate in this experiment, implementations should nterept RFC7489 as follows" > Section 7.3, paragraph 1, comment: > > 7.3. URIs This appears to be some artifact of the XML as the URI is listed in the Informative Reference section. > > It's unusual for an RFC to have reference sections other than for > normative and > informative references, because it's not clear what category references > here > would fall into. Also, I'll note that [psddmarc.org] was cited as an > informative > reference in that section, so why not this one? > > > ------------------------------------------------------------------------------- > All comments below are very minor change suggestions that you may choose to > incorporate in some way (or ignore), as you see fit. There is no need to > let me > know what you did with these suggestions. > > Section 3.2, paragraph 3, nit: > > to that of the "p" tag defined below. If the 'np' tag is absent, > > The document uses both single and double quotes throughput (above is an > example), and it's not clear if this is deliberate (i.e., there is a > meaning to > this) or whether this is an editorial oversight that should be corrected. > > I believe I've corrected all of these quote mismatches (that is, I've found all the single quoted mentions and have updated them to double quotes). > Section 6.1, paragraph 5, nit: > > +----------+-----------+---------+-------------------------------+ > > | Tag Name | Reference | Status | Description | > > +----------+-----------+---------+-------------------------------+ > > | np | this | current | Requested handling policy for | > > | | document | | non-existent subdomains | > > +----------+-----------+---------+-------------------------------+ > > > > You should add an RFC Editor Note instructing them to replace "this > document" > with the RFC number of this document (to make sure they are aware of the > action). > > Done > Section 1, paragraph 2, nit: > - DMARC ([RFC7489]) provides a mechanism for publishing organizational > - - - > + DMARC [RFC7489] provides a mechanism for publishing organizational > > Fixed > Section 1, paragraph 3, nit: > - found in Section 3.2 of the DMARC specification. Currently the > + found in Section 3.2 of the DMARC specification. Currently, the > + + > > Section 1, paragraph 4, nit: > - In the basic DMARC model, PSDs are not organizational domains and are > + In the basic DMARC model, Public Suffix Domains (PSDs) are not > organizational domains and are > + +++++++++++++++++++++++ + > > Fixed > Section 1.2, paragraph 7, nit: > - handling policy for non-existent subdommains. This is provided > - - > + handling policy for non-existent subdomains. This is provided > > Fixed > Section 1.2, paragraph 7, nit: > - of requesting harsh policy treatment (e.g. reject) is lower. > + of requesting harsh policy treatment (e.g., reject) is lower. > + + > > Section 1.2, paragraph 8, nit: > - (i.e. if a DMARC record were published for 'example', then mail from > + (i.e., if a DMARC record were published for 'example', then mail from > + + > > Fixed > Section 2.7, paragraph 2, nit: > - is a broader definition than that in NXDOMAIN [RFC8020]. > - --------- > + is a broader definition than that in [RFC8020]. > > Fixed > Section 4.1, paragraph 7, nit: > - not particpate in DMARC, any Feedback Reporting related to multi- > + not participate in DMARC, any Feedback Reporting related to multi- > + + > > Fixed > "B.3.", paragraph 3, nit: > - supposed to be the output domain of the regular PSL lookup, i.e. the > + supposed to be the output domain of the regular PSL lookup, i.e., the > + + > > Fixed --00000000000055a5aa05c00b74d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Lars

    See below. Thanks for the comments


    On Wed, Apr 14, 2021 at 4:44 AM Lars Eg= gert via Datatracker <noreply@ietf.o= rg> wrote:
    https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-dm= arc-psd/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Section 3, paragraph 2, comment:
    > 3.=C2=A0 PSD DMARC Updates to DMARC Requirements
    >
    >=C2=A0 =C2=A0 This document updates DMARC as follows:

    If I understand things correctly, this document specifies an experiment tha= t -
    if successful - would lead to an update of RFC7489. It's therefore conf= using to
    see the text in Section 3 that is written as if that update was already bei= ng
    brought into effect. I'd much prefer text that said things like "t= o participate
    in this experiment, implementations should do X or Y or Z and/or interpret<= br> Section foo of RFC7489 as bar", etc.

    =C2=A0
    "To participate in this experiment, = implementations should nterept RFC7489 as follows"

    <= div>=C2=A0
    Section 7.3, paragraph 1, comment:
    > 7.3.=C2=A0 URIs

    This appears to be some art= ifact of the XML as the URI is listed in the Informative
    Reference= section.
    =C2=A0
    =C2=A0

    It's unusual for an RFC to have reference sections other than for norma= tive and
    informative references, because it's not clear what category references= here
    would fall into. Also, I'll note that [psddmarc.org] was cited as an info= rmative
    reference in that section, so why not this one?

    ---------------------------------------------------------------------------= ----
    All comments below are very minor change suggestions that you may choose to=
    incorporate in some way (or ignore), as you see fit. There is no need to le= t me
    know what you did with these suggestions.

    Section 3.2, paragraph 3, nit:
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0to that of the "p" tag defined bel= ow.=C2=A0 If the 'np' tag is absent,

    The document uses both single and double quotes throughput (above is an
    example), and it's not clear if this is deliberate (i.e., there is a me= aning to
    this) or whether this is an editorial oversight that should be corrected.

    =C2=A0
    I believe I've cor= rected all of these quote mismatches (that is, I've found all the
    <= div>single quoted mentions and have updated them to double quotes).
    =C2=A0
    Section 6.1, paragraph 5, nit:
    >=C2=A0 =C2=A0 +----------+-----------+---------+-----------------------= --------+
    >=C2=A0 =C2=A0 | Tag Name | Reference | Status=C2=A0 | Description=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +----------+-----------+---------+-----------------------= --------+
    >=C2=A0 =C2=A0 | np=C2=A0 =C2=A0 =C2=A0 =C2=A0| this=C2=A0 =C2=A0 =C2=A0= | current | Requested handling policy for |
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | document=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| non-existent subdomains=C2=A0 =C2=A0 =C2= =A0 =C2=A0|
    >=C2=A0 =C2=A0 +----------+-----------+---------+-----------------------= --------+
    >

    You should add an RFC Editor Note instructing them to replace "this do= cument"
    with the RFC number of this document (to make sure they are aware of the action).


    Done
    =C2=A0
    Section 1, paragraph 2, nit:
    -=C2=A0 =C2=A0 DMARC ([RFC7489]) provides a mechanism for publishing organi= zational
    -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- +=C2=A0 =C2=A0 DMARC [RFC7489] provides a mechanism for publishing organiza= tional


    Fixed
    Section 1, paragraph 3, nit:
    -=C2=A0 =C2=A0 found in Section 3.2 of the DMARC specification.=C2=A0 Curre= ntly the
    +=C2=A0 =C2=A0 found in Section 3.2 of the DMARC specification.=C2=A0 Curre= ntly, the
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+

    Section 1, paragraph 4, nit:
    -=C2=A0 =C2=A0 In the basic DMARC model, PSDs are not organizational domain= s and are
    +=C2=A0 =C2=A0 In the basic DMARC model, Public Suffix Domains (PSDs) are n= ot organizational domains and are
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+++++++++++++++++++++++=C2=A0 =C2=A0+=


    Fixed
    Section 1.2, paragraph 7, nit:
    -=C2=A0 =C2=A0 handling policy for non-existent subdommains.=C2=A0 This is = provided
    -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-
    +=C2=A0 =C2=A0 handling policy for non-existent subdomains.=C2=A0 This is p= rovided


    Fixed
    Section 1.2, paragraph 7, nit:
    -=C2=A0 =C2=A0 of requesting harsh policy treatment (e.g. reject) is lower.=
    +=C2=A0 =C2=A0 of requesting harsh policy treatment (e.g., reject) is lower= .
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +

    Section 1.2, paragraph 8, nit:
    -=C2=A0 =C2=A0 (i.e. if a DMARC record were published for 'example'= , then mail from
    +=C2=A0 =C2=A0 (i.e., if a DMARC record were published for 'example'= ;, then mail from
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+


    Fixed

    =C2=A0
    Section 2.7, paragraph 2, nit:
    -=C2=A0 =C2=A0 is a broader definition than that in NXDOMAIN [RFC8020].
    -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= -------
    +=C2=A0 =C2=A0 is a broader definition than that in [RFC8020].

    Fixed
    =C2=A0
    Section 4.1, paragraph 7, nit:
    -=C2=A0 =C2=A0 not particpate in DMARC, any Feedback Reporting related to m= ulti-
    +=C2=A0 =C2=A0 not participate in DMARC, any Feedback Reporting related to = multi-
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

    Fixed
    =C2=A0
    "B.3.", paragraph 3, nit:
    -=C2=A0 =C2=A0 supposed to be the output domain of the regular PSL lookup, = i.e.=C2=A0 the
    +=C2=A0 =C2=A0 supposed to be the output domain of the regular PSL lookup, = i.e.,=C2=A0 the
    +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +


    Fixed
    --00000000000055a5aa05c00b74d0-- From nobody Thu Apr 15 16:50:02 2021 Return-Path: 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 318363A34DB; Thu, 15 Apr 2021 16:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=gmail.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 Y4kacnSeID4S; Thu, 15 Apr 2021 16:49:50 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CE33A34DA; Thu, 15 Apr 2021 16:49:49 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id b10so25965833iot.4; Thu, 15 Apr 2021 16:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lBfuOO1B9i705VJSpiEpMR7bTG8pTm8HnknKPl6DpI4=; b=tkouEqLTXbJHHnFIVPwXZZ0n0OfU09pnm0vEtIEtjYS1EAo/INxwUIFtXYeAGzoCH8 cSdRd+F0EmRVdgEHpiXVm0DtsZXc8+t8iMm4tt/Qt08MOhUeqvV7CH6MBsuDhRiUQqu9 z4HKmb1/meh5FWrBPHYnxcAPOg7GRX/JveEbKqQswlQw5E3GDlUNER9YGRxGW288uEaF 9GIUFuw8z1RbH4Cn1bqRJZwe+G5ltxDOq04w5p5MOwBE7kQn+5R9rD3FFmoLWQO46l3Q tJvJl3aomZZLn3rKW81lnIF9nwA2LHJzCEpj8Qb/Qs5mxR1Cvb4WKN+K/+MWo3UXL/c/ F3/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lBfuOO1B9i705VJSpiEpMR7bTG8pTm8HnknKPl6DpI4=; b=g/bYBjWvuKEVHrrXxILZJoRUT5KFyhxYXwJkNaeEjAVicHC3N8ajKBGRkTezNnpc9N V5d3f38+8b/iUEO0jKAj3CjPJjExf7nzzV6MeVNaL7IPNDlsWQZ4n8U3v55oiCTxQvgg 4qOIH1tbByAl1nVxVMFeR6HoDUumML6O/MIGymJwpExQxwolhRvrqRkMYok33/InRAm1 zt+RMq+W74+hBMm2vHJTTXPL1mpkb3tpBdzs85NEEtVx/8aoUW/BYQsavGOLxUTCuiLb rEngVsM5d4MLOrINGuSAfp8PKPiru9N5x/wvo0/5CN2TDZgsz3f5PH5JdCG30809ulnU 6TSQ== X-Gm-Message-State: AOAM533hLjk6kjMw0Gy4dsYDQ51MHkQHJDUInyD+JC4q5ymhX+9Xaowk iT9Vx7Hhg7wb6JUs4I9YIaXCMNHJCB0YghVIkFO8joLT X-Google-Smtp-Source: ABdhPJwBI80suFXdgG7Z5dXDZza1yQwm0CQs3a6XqRVes19U4VO1xY3BjJcU7dw4WnV5KQGyHxR3QnKgrWsovhiiFNw= X-Received: by 2002:a05:6602:3417:: with SMTP id n23mr1268177ioz.96.1618530588478; Thu, 15 Apr 2021 16:49:48 -0700 (PDT) MIME-Version: 1.0 References: <161847105823.12240.11886353486421150693@ietfa.amsl.com> In-Reply-To: <161847105823.12240.11886353486421150693@ietfa.amsl.com> From: Tim Wicinski Date: Thu, 15 Apr 2021 19:49:37 -0400 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000c8d10005c00b843d" Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 23:49:55 -0000 --000000000000c8d10005c00b843d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric On Thu, Apr 15, 2021 at 3:17 AM =C3=89ric Vyncke via Datatracker < noreply@ietf.org> wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dmarc-psd-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. It is easy to read and > specify > an experiment, which could be useful. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > > -- Sections 1 and 3-- > I share Lars' concern about the "update" in the last paragraph. > > -- Section 5.1 -- > Editorial comment: why using a sub-section ? Let's 'glue' its contents to > the > first =C2=A7 of section 5. BTW, interesting read this section. > > Section 5 is Security Considerations and has no subsections. Am I missing something? > =3D=3D NITS =3D=3D > > -- Section 2.2 -- > Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr > https://www.rfc-editor.org/materials/abbrev.expansion.txt > > Agreed, and fixed. > -- Sections 2.2 ... 2.7 -- > Mostly cosmetic but I would have preferred the usual presentation to > introduce > terminology, i.e., a list and not several sub-sections. > > Maybe we can make this a note for the RFC Editor ? tim --000000000000c8d10005c00b843d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Eric

    On Thu, Apr 15, 2021 at 3:17 AM =C3=89ric Vyn= cke via Datatracker <noreply@ietf.or= g> wrote:
    =C3=89ric Vyncke has entered the following ballot position for
    draft-ietf-dmarc-psd-12: No Objection

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-dm= arc-psd/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you for the work put into this document. It is easy to read and speci= fy
    an experiment, which could be useful.

    Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

    I hope that this helps to improve the document,

    Regards,

    -=C3=A9ric

    =3D=3D COMMENTS =3D=3D

    -- Sections 1 and 3--
    I share Lars' concern about the "update" in the last paragrap= h.

    -- Section 5.1 --
    Editorial comment: why using a sub-section ? Let's 'glue' its c= ontents to the
    first =C2=A7 of section 5. BTW, interesting read this section.


    Section 5 is Security Considerations and has no subsectio= ns. Am I missing something?
    =3D=3D NITS =3D=3D

    -- Section 2.2 --
    Unsure whether "Requests for Comment (RFC)" is really required ;-= ) cfr
    https://www.rfc-editor.org/materials/abbr= ev.expansion.txt


    Agreed, and fixed.=C2=A0
    -- Sections 2.2 ... 2.7 --
    Mostly cosmetic but I would have preferred the usual presentation to introd= uce
    terminology, i.e., a list and not several sub-sections.


    Maybe we can make this a note for the RFC Editor ?=C2=A0 =C2=A0

    tim

    --000000000000c8d10005c00b843d-- From nobody Thu Apr 15 22:43:18 2021 Return-Path: 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 4BA9A3A16CE; Thu, 15 Apr 2021 22:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LD0sHJsn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vpahLNeO 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 OmXmH0bdbgQe; Thu, 15 Apr 2021 22:43:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B308A3A16CD; Thu, 15 Apr 2021 22:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14307; q=dns/txt; s=iport; t=1618551789; x=1619761389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uIL+qdobLxGvDKP7xv5PdVV7CAIp3HBhwGvChNheaVw=; b=LD0sHJsnDGmo+pXQ1+8cR0ZvdGYZI3TZRi130AEuzQ7mlTWocX8DLmoJ akiop4Ii1R0YU6gki1Q2yyUxiDsxD6+2JQKBMe97VBGhMQ6wKWXjxsJ3B 1szReTXd6esCrWcSnez+7e8wUV/DUfIRaMdXnjsxyzm1H9OkDBxrIQ4+x I=; IronPort-PHdr: =?us-ascii?q?A9a23=3AX/+rNhMd+baTEu7/vkkl6nf3WUAX047cNxMJ6?= =?us-ascii?q?pchl7NFe7ii+JKnJkHE+PFxlzfhUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBT?= =?us-ascii?q?AQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aF?= =?us-ascii?q?hD2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNio?= =?us-ascii?q?iY=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AKyCUO69WTjs7+OLU/fhuk+Gacb1zdoIgy1?= =?us-ascii?q?knxilNYDRvWIixi92ukPMH1RX9lTYWXzUalcqdPbSbKEm8ybdc2qNUGbu5Rg?= =?us-ascii?q?HptC+TLI9k5Zb/2DGIIUPD38Zn/+Nbf6B6YeeeMXFTh8z3+RT9Nt4mzsWO/q?= =?us-ascii?q?zAv5ag815GZ2hRGsZdxi1+DRuWFVAzYQFAC4YwGpb03Ls4mxOLf3MLYsOnQk?= =?us-ascii?q?QURuSrnayLqLvKQz4jQyQm5g6HkC+y5NfBcySw8x8CX1p0sMwf2EfflQiR3N?= =?us-ascii?q?THj9iazVvm23bX/9BqnrLau6d+LeitruRQFTn2kAavY+1aKv2/lRQ4uvum5l?= =?us-ascii?q?pvsPSkmWZbA+1J53ncfn64rHLWsmGKultDmhySq2Owunftrdf0Qzg3EaN69P?= =?us-ascii?q?9kWyHE4EkttswU6tMs40ultoFaBR6FvCPx68mgbWATqmOIoGEvmeNWsnpHUY?= =?us-ascii?q?F2Us4pkaUj+ipuYfM9NRO/zLpiPPhlDcna6voTW0iddWrlsm5mx8HpdmgvHz?= =?us-ascii?q?+dK3Jy+fC94nxzpjRU3kEYzMsQkjMr75QmUaRJ4OzCL+BBiKxOdMkLdqhwbd?= =?us-ascii?q?1xA/efOyjoe1bhIWiSKVPoGOUsIHTWsaP6570z+aWMdIEXyoAx3LDMSklRu2?= =?us-ascii?q?J3W0+GM7zK4LR7tjT2BEmtVzXkzc9To7JjvKfnebbtOSqfDF80lc+tpOgeH9?= =?us-ascii?q?3bV/6/NIk+OY6lEULeXaJymyHuUZhbLncTFOcPvMwgZl6IqsXXbo3m39arNs?= =?us-ascii?q?r7Ff7IK3IJS2n/CnwMUHzYP8Nb9H2mXXf+nVzUU3PpcUrv4IJoHMHhjrEu4b?= =?us-ascii?q?lIErcJnhkeiFy/6M3OAyZFqLYKcEx3J66ilLi6q2mw9WPB9H5oJRJZE0ZQ7N?= =?us-ascii?q?zbIjd3jD5PF3mxXacIut2Zd2wX9mCAPAVDQ8TfFxMau0564rutL5ubxTkrDt?= =?us-ascii?q?WuNm7ytQpKmFu6C7Mn3oGT78bsfZ01Sqs8UKtqDAPRClheggBxslpObwcCW2?= =?us-ascii?q?7SHj7jkr+ekZQRHe3THuMM2zuDEIpxkzb/vV/ZjdwzTnEbNgTeIPK/sEILfX?= =?us-ascii?q?5ooXFft4UYm6GNnD6zL3BXupVJDHR8LEKNALxHCwyZYp5zgb6DQnArcU66wR?= =?us-ascii?q?qHlho0Zm3ms2IVi2CJF1zJRdj7RnxAp3tfzqHmtGlRS1zYVUdxZndm2LcNSF?= =?us-ascii?q?jusmpv0OONe6q423aQbFxH2e0GLDTZe1IpU3FT7sys2AXQkDiPEmhO/ORcAs?= =?us-ascii?q?XNSLskaL3dwXWrNcmBkrwHBeZd+NJ/OMnpqfJja5PSRyaFaDf5AfguwQqbuz?= =?us-ascii?q?IsPzR1smAtlZrTqVfYxXn92H40GvzJJlt6A7kdPtGH9mDhA/KFyo9wg95wve?= =?us-ascii?q?y+NAzKG5O74LCSaz5IMRXIp2GqC+kutJBPpKo38KJpAIOza0qA6FhXmBElaM?= =?us-ascii?q?vknkIXR6p2pLjHJ490ZsQXPyZU5EAgmtiDJFYi2zaGTdMWbBUolTvWLtmJ67?= =?us-ascii?q?3Hpf40DkqNqBD5NFOf/ydels21FBerxPofEeY9MG5WYE8z5DB+5+uEbZTXEx?= =?us-ascii?q?jveOdZ/la2W0XNPoN1WeyAA/EXoRl76d3TwLPSeCr8xQzKvTx0ZqhJ6H2qRM?= =?us-ascii?q?uuAASKXe5EmubKTmikk++v+oq0ijyyVD6wL0IfjodBfVYLbstChiI55bdHmh?= =?us-ascii?q?SaW+jyuAY9j1Ba4Tt7jVbj1Yit/XfDESh9QHnkq4QTWSMWL2OBgsvE+/WJzX?= =?us-ascii?q?jx4DBK3p/YCUdbF+s+beQ4X8zwNCdhKc8Zob6u8e4um014EWITM1I=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAAB+I3lg/4ENJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBfgcBAQsBgSIwKSgHd1o2MYRDg0gDhFlgiEklA4ovihiEdoE?= =?us-ascii?q?uFIERA1QLAQEBDQEBKAoCBAEBhFACF4FcAiU0CQ4CAwEBDAEBBQEBAQIBBgR?= =?us-ascii?q?xE4VQDYZEAQEBBCMdAQE3AQ8CAQgOAwMBAigDAgICHxEUBgMIAgQOBYJxAYF?= =?us-ascii?q?+VwMvAQ6hRAKKH3mBMoEBggQBAQaBR0GDLg0LghMDBoE5AYJ3hAkBAYJAhBI?= =?us-ascii?q?nHIFJQoETJwwQgl8+gQSBGkICAQKBKAESAUENCYJhNYIrgy4EIhkQBgJ/gQI?= =?us-ascii?q?CKEmQWYJzQodtngNbCoMMiWeNZQSFNgQfg06KfIYUkB6FEZIZiV6DF49RC4R?= =?us-ascii?q?WAgQCBAUCDgEBBoFUOmlYEQdwFTsqAYI+UBcCDo4fF4ENAQiCQ4UUhUVzAgE?= =?us-ascii?q?1AgYBCQEBAwkBe4wSAQE?= X-IronPort-AV: E=Sophos;i="5.82,226,1613433600"; d="scan'208,217";a="884914781" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2021 05:43:07 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 13G5h5AP016571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 16 Apr 2021 05:43:06 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 16 Apr 2021 00:43:04 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 16 Apr 2021 00:43:04 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 16 Apr 2021 00:43:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nB7lGHMEQNXyd1sEEVxiXJHQgj/6yYIajPSPiCuICxP070cTO+oSFNiKX7iVOh5pC3ps4LzLZ1YN4M0ZnQ/gmZkd+9AY83M5/l8zAn96JV2T+dzUwxVSscy4ZOEuzvCBMgZng37mIDnctiOkFaRaTF1hGD8b3PxgG6Kcog/bGntt4UoNgS77Yo0g1/CexvzlsgY39ZIYb2Ks6DuOoq9c/Z8gNn64wUi6MPJZVK76ZScMAY77BFQdf9JQn2Qmbl6TUHkk9DTq8VGRP/++Kv7iFAgWQKWDfnbYP3VkHbblj0eSVawKaocwycYU2q5u4ZIoaUL21jIJi4s7S1fNdjpYMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uIL+qdobLxGvDKP7xv5PdVV7CAIp3HBhwGvChNheaVw=; b=YO+4QPb1rIHH0g5qHnPnJt/jWQZ2fsWVorXf1Gtj9Zl9thXUMXnsndg0qvpu6myPgkhtA2x3aVw5AziTwaG3r/L2C6slz+jXuXMurjasMD51CRs1MM/Qk+txw6pGClCPC+DK3vUAxyXH8be+v32BPQUc+NRzaXjy8QDFHFb/tGF2gwlpjfxaYZpjWMPZQ3LUd1c7CaZf4GWcu/YQek7PNJBeNE9EUvdoV+/ljpfEpBBHVOq27kDPQMQaljh4VvwS034vEfzQT+9HwyU6pXCgxQW7u8pZB0gU6tyw50IHRXxMJOUoZSKEfYX3nEXAXQPim+SmN7dK4CSbmv+/BTCTJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uIL+qdobLxGvDKP7xv5PdVV7CAIp3HBhwGvChNheaVw=; b=vpahLNeOJ36OAqoK+X/+Dm8ceuDKXXG5PsjvVmY4Ov+4u+h/xAacLQPOHnP35Lt0xca4DrTo9cjz3nU2adUySn0rRYkEfvP5wUkiAU454vnp6hKiKZ17p8dsZFGOozNYPdSitrIIO53BPYe8z6P7ek36Tt7crgeXPF0Bn+Y9hOk= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5176.namprd11.prod.outlook.com (2603:10b6:510:3f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Fri, 16 Apr 2021 05:43:03 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Fri, 16 Apr 2021 05:43:03 +0000 From: "Eric Vyncke (evyncke)" To: Tim Wicinski CC: The IESG , "draft-ietf-dmarc-psd@ietf.org" , "dmarc-chairs@ietf.org" , IETF DMARC WG , Alexey Melnikov Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG1h?= =?utf-8?Q?rc-psd-12:_(with_COMMENT)?= Thread-Index: AQHXMlIOwfdptucStk2T6dhRp2KA26q2w50A Date: Fri, 16 Apr 2021 05:43:02 +0000 Message-ID: References: <161847105823.12240.11886353486421150693@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:a1fe:34db:f999:45ed] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ad53931-0c34-4f0e-6a6a-08d9009a80a6 x-ms-traffictypediagnostic: PH0PR11MB5176: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2r4QOvRtBWCfQ6GYszqhRwh56nRgOcXHEm/2HGh6dkO3u4qWfPwpGdgg5e7+KC48cnwuRPySyvB/yEzvtO7sDu97dZ+qDAFQCoWS9KzQaNgeqSMYSNhPd8USk+M1HI97QJkW/coXA29PrlqRxoVcnp/co3cioLM+rpUxFW5H2ad1JBVQnDMOXpkm1pt0KfD/cqsdrqX5kQh2ai68Ize9msTAAKw2bVK8C+dHN+SAK9l9Z+N8g8g4Yru+J4HXR3TeeN+8ZtEsb0K+hvH99/FSc42XRR7bAhcgLUpsPfzSu/kWWLTmVnsf1BURmqm7PQPGp9BMxwaV10ShH6+uDVkHGk2PJiRdqbyTCRSUbkJSw/nwDIBRGYoFlpECSBR8FnFosSb/L6zo3Ao005s787OlnyP6GJOfiEqzWiMWyxyREvR56cvuQysZT05Cg+Kw52zyWfQfJjK6sfe2DZhuKArSH0BBGLGPtb6mWHPfiH6bjajlHOFpI7hSbUtyTkQ5p7KFW7zaU3dyKfWmRQCthJD1+jeGUWllui8Ulzoq1DJrPm5qYyTMewiWO3Y1W5krKTiuhwLY/WND2G+0KU3m3xBomcdcClKNbzwnh+2ErFzQ4b+9hRr2kR4ZbPhGQwgEbMS5VmYg7FxEIQg0Uh73ooINkxDgoYpwsPxujIprIPJVnfNWYqcIAo1zTevUC4mosfMcmwg+G57wRMVRbdyavnYGtCcd3cU6XV4HyZBRWgfhnsY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(376002)(346002)(136003)(6506007)(21615005)(166002)(86362001)(54906003)(186003)(6486002)(36756003)(8936002)(66476007)(64756008)(53546011)(4326008)(66556008)(5660300002)(71200400001)(83380400001)(2616005)(33656002)(38100700002)(66446008)(6916009)(66574015)(2906002)(316002)(966005)(66946007)(224303003)(76116006)(91956017)(6512007)(122000001)(478600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NUEvcmU1T3R2UW9UV1cxNjFvOGQyREt2L3d3UTdLaWVvOXpPZ0I3SFV3Zzln?= =?utf-8?B?MXJGdTg3d29aRUorWEtvRkRZc0ZaWUoyUTNtWTZWV2RJWm9SN0hGdFNRUFN4?= =?utf-8?B?OW5HRmcvMUJxdExPYlJwbmVucnlZOUhIY0Zlam9nSkZpMk51MGlGYWxoVTNq?= =?utf-8?B?YkZWN0ZBZmFMVzNueVdWYjNwSldwdXpuSjBJbWhKbWxZTzFzWkN5R0kzQWgv?= =?utf-8?B?dEJXeFcyWG01ejZTMXJXalpCZXVhdEVSZno0ZFZyQngycyt0d1hGNk45S1VH?= =?utf-8?B?cUlHdDl2TGpEM25RQjFwR0tPYkxMU1F6NFlJZ05sUW5GMzJ0blpPMUt0YzB0?= =?utf-8?B?bFNJdVQ4YjFISGUxTW9wekU4TlVjWmhlcHpKbmVEZjJYUnJtUm5MWDM1THlm?= =?utf-8?B?QzZtN1hBSkx1YWFwMWlPalhGcjVCZVVBYUdkR21wQmVtcUw4MHZkaUJSOS9v?= =?utf-8?B?YXo1ZjhJb3RiTndhd0R1NUlaeFJleGkvRmRwQ3dnZEVPSWczMkw3ZDBiNDVo?= =?utf-8?B?WHZEWVoxQlhPWTdYOGJybFdkaGNFSXR5aGVxL3Nyb09aMkJ2cmM1THFJd3B1?= =?utf-8?B?L3JJMmxEWHQ5Mm96YWNIeXBqTEFrV3ZMNW9wR08yKzlMK28yYmFya0JCTytX?= =?utf-8?B?V082WFhJdTB6Y0V0ZDlTSHIzN2I0dVRjaHZhOTZ1M2xSZTFOTnlmYXFlRjYy?= =?utf-8?B?S2hGNnZwQzBpSkJqL2tqL0tJVzhUd3ZWREdsNkJWeWZYMHpmWERmcmJhVDF2?= =?utf-8?B?VFNHTHJ3NXd0UTQraldjVzZISGx0NmJsZVhLS0ZoUzRSa0R5NDJDN0RmS1k0?= =?utf-8?B?NVZHTVNLZHZVTmpFTlRqVlE4L09LSkhXcHg3VWpXTTBkRDRzdUtLdlFscHZx?= =?utf-8?B?V09qZlpmYW5NMUY2RW1DVFdITHN1K3ZGa2lZSG9Sa3ZsaUdCdWV1ZjJRcGh3?= =?utf-8?B?azUyaExBY2E1MDR2d2FnNzYvM3prUHZPTVBET3BHNkRJSjFjRFNxMEkzUSts?= =?utf-8?B?L0p0L3hWYVFybjNSbXdnSHErcU5za1dwTEZCbDBTMHArZmNhVHNpbzlnOWox?= =?utf-8?B?NWI5QmFwdjJzN1loTDZsR0lJLzVxUUhRdXV4bm91NTNmaVJRMjBlZDUxZnFo?= =?utf-8?B?am12YUppa3U3Vk1mY3g1aElqRkdTL1IvdTFhY0dBdmpRUEpOak1OQVdML1JM?= =?utf-8?B?ZXJlbUo1c21WTDFENEpKamtEZHdJeEdTa2hUam93ZEVwZ09KcWlia003V2Zo?= =?utf-8?B?NlFxWnVJQ2p5Vkx0WTNiZ3VydkM3ZUlrVE13WDFMZlRyanRnQkIvcVJNb3J0?= =?utf-8?B?MEVNK0RJY0cxbnJNdXdBajJmOTJPclZCNlErR3p1UEZ5OFFGVnFrMHIwMlJE?= =?utf-8?B?ZTlIVkpmK2xMMnA5dTc0RXF1Q25vUGFYRDNkRE1zSWE5MXEzcHpieGNWZmJT?= =?utf-8?B?MUxPeDFwN21kdHVkSjdrVHlnNGVXNlMzeE9TY1VjdEM4VFVoNVlFWmVOOE9E?= =?utf-8?B?Z0dIaUJ5OWovb1ZRMVJqMGR4LzdqRDRvcHJtS3Z4SUhaQ3kwd2hxYWJqVWUx?= =?utf-8?B?Qk1tbkJoYU5YaVh4NVMyeXFOOVBxRk1FR2FtQTQ2cS80OEtUTnVsUEZONFg2?= =?utf-8?B?VnRscGN3WFlPVnAzOUVGTTd2Qk1IT2ovUW9ISVZvblIydDArZjRQdHNGRzg5?= =?utf-8?B?Y2lMekJLbHZpWW1QWlZsSTR3bGhKdU1hdnJxN3B2YmlGQTdyUU5ESzdlbjhu?= =?utf-8?B?VXBTaE5RbXJrRzRJZC9PcUpZRTYwdDVPdkdIZWt4MWJOWEdRaTJYVmovVVVp?= =?utf-8?B?SlYwc2lYU3NIMUI0VVRFTm5US21rZEF5dkpJV1FreGVWQTc0T1JHTmtlOWVr?= =?utf-8?Q?UOxpq7aMRU5Zg?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C098F99CA00C46638B0FB5A4FC68BD16ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ad53931-0c34-4f0e-6a6a-08d9009a80a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 05:43:03.1734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6VBzYUi++XklIa12spBl85Lz+FV1b2pzUOO12JB7JZlSFZsLjkP5Yh6mujAa+07DdxLvbdT6YvYlm0Pe2aN5eQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5176 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 05:43:16 -0000 --_000_C098F99CA00C46638B0FB5A4FC68BD16ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcXVpY2sgcmVwbHkgYW5kIHRoZSB1cGRhdGVzIHRv IHRoZSBkb2N1bWVudC4NCg0KTXkgY29tbWVudCBvbiBzZWN0aW9uIDUuMSB3YXMgYWN0dWFsbHkg b24gc2VjdGlvbiA0LjEgLi4uIFNvcnJ5IGFib3V0IHRoZSBtaXgsIEkgc2hvdWxkIGRyaW5rIG1v cmUgY29mZmVlIGl0IHNlZW1zIDotbw0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQoNCkZyb206IFRp bSBXaWNpbnNraSA8dGp3LmlldGZAZ21haWwuY29tPg0KRGF0ZTogRnJpZGF5LCAxNiBBcHJpbCAy MDIxIGF0IDAxOjUwDQpUbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPg0KQ2M6IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgImRyYWZ0LWlldGYtZG1hcmMtcHNkQGlldGYub3JnIiA8 ZHJhZnQtaWV0Zi1kbWFyYy1wc2RAaWV0Zi5vcmc+LCAiZG1hcmMtY2hhaXJzQGlldGYub3JnIiA8 ZG1hcmMtY2hhaXJzQGlldGYub3JnPiwgSUVURiBETUFSQyBXRyA8ZG1hcmNAaWV0Zi5vcmc+LCBB bGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+DQpTdWJqZWN0OiBSZTog w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG1hcmMtcHNkLTEyOiAo d2l0aCBDT01NRU5UKQ0KDQpFcmljDQoNCk9uIFRodSwgQXByIDE1LCAyMDIxIGF0IDM6MTcgQU0g w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9y ZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1kbWFyYy1wc2QtMTI6IE5vIE9i amVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1hcmMt cHNkLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhh bmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBJdCBpcyBlYXN5IHRv IHJlYWQgYW5kIHNwZWNpZnkNCmFuIGV4cGVyaW1lbnQsIHdoaWNoIGNvdWxkIGJlIHVzZWZ1bC4N Cg0KUGxlYXNlIGZpbmQgYmVsb3cgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1 dCByZXBsaWVzIHdvdWxkIGJlDQphcHByZWNpYXRlZCksIGFuZCBzb21lIG5pdHMuDQoNCkkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQoNClJlZ2FyZHMsDQoN Ci3DqXJpYw0KDQo9PSBDT01NRU5UUyA9PQ0KDQotLSBTZWN0aW9ucyAxIGFuZCAzLS0NCkkgc2hh cmUgTGFycycgY29uY2VybiBhYm91dCB0aGUgInVwZGF0ZSIgaW4gdGhlIGxhc3QgcGFyYWdyYXBo Lg0KDQotLSBTZWN0aW9uIDUuMSAtLQ0KRWRpdG9yaWFsIGNvbW1lbnQ6IHdoeSB1c2luZyBhIHN1 Yi1zZWN0aW9uID8gTGV0J3MgJ2dsdWUnIGl0cyBjb250ZW50cyB0byB0aGUNCmZpcnN0IMKnIG9m IHNlY3Rpb24gNS4gQlRXLCBpbnRlcmVzdGluZyByZWFkIHRoaXMgc2VjdGlvbi4NCg0KU2VjdGlv biA1IGlzIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFuZCBoYXMgbm8gc3Vic2VjdGlvbnMuIEFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQo9PSBOSVRTID09DQoNCi0tIFNlY3Rpb24gMi4yIC0tDQpV bnN1cmUgd2hldGhlciAiUmVxdWVzdHMgZm9yIENvbW1lbnQgKFJGQykiIGlzIHJlYWxseSByZXF1 aXJlZCA7LSkgY2ZyDQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2 LmV4cGFuc2lvbi50eHQNCg0KQWdyZWVkLCBhbmQgZml4ZWQuDQotLSBTZWN0aW9ucyAyLjIgLi4u IDIuNyAtLQ0KTW9zdGx5IGNvc21ldGljIGJ1dCBJIHdvdWxkIGhhdmUgcHJlZmVycmVkIHRoZSB1 c3VhbCBwcmVzZW50YXRpb24gdG8gaW50cm9kdWNlDQp0ZXJtaW5vbG9neSwgaS5lLiwgYSBsaXN0 IGFuZCBub3Qgc2V2ZXJhbCBzdWItc2VjdGlvbnMuDQoNCk1heWJlIHdlIGNhbiBtYWtlIHRoaXMg YSBub3RlIGZvciB0aGUgUkZDIEVkaXRvciA/DQoNCnRpbQ0KDQo= --_000_C098F99CA00C46638B0FB5A4FC68BD16ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGltLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhhbmsgeW91IGZvciB5b3VyIHF1aWNrIHJlcGx5IGFuZCB0aGUgdXBkYXRlcyB0byB0 aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBjb21tZW50IG9uIHNlY3Rpb24gNS4x IHdhcyBhY3R1YWxseSBvbiBzZWN0aW9uIDQuMSAuLi4gU29ycnkgYWJvdXQgdGhlIG1peCwgSSBz aG91bGQgZHJpbmsgbW9yZSBjb2ZmZWUgaXQgc2VlbXMgOi1vPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlRpbSBXaWNpbnNraSAmbHQ7dGp3LmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5GcmlkYXksIDE2IEFwcmlsIDIwMjEgYXQgMDE6NTA8YnI+DQo8Yj5UbzogPC9i PkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlRo ZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1kbWFyYy1wc2RA aWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtZG1hcmMtcHNkQGlldGYub3JnJmd0OywgJnF1 b3Q7ZG1hcmMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtkbWFyYy1jaGFpcnNAaWV0Zi5vcmcm Z3Q7LCBJRVRGIERNQVJDIFdHICZsdDtkbWFyY0BpZXRmLm9yZyZndDssIEFsZXhleSBNZWxuaWtv diAmbHQ7YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWRtYXJjLXBzZC0x MjogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUaHUsIEFwciAxNSwgMjAyMSBhdCAz OjE3IEFNIMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpu b3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIu MHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQrDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KZHJhZnQtaWV0Zi1kbWFyYy1wc2QtMTI6 IE5vIE9iamVjdGlvbjxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz PGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0K UGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1hcmMtcHNkLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1hcmMtcHNk LzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQg aW50byB0aGlzIGRvY3VtZW50LiBJdCBpcyBlYXN5IHRvIHJlYWQgYW5kIHNwZWNpZnk8YnI+DQph biBleHBlcmltZW50LCB3aGljaCBjb3VsZCBiZSB1c2VmdWwuPGJyPg0KPGJyPg0KUGxlYXNlIGZp bmQgYmVsb3cgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1dCByZXBsaWVzIHdv dWxkIGJlPGJyPg0KYXBwcmVjaWF0ZWQpLCBhbmQgc29tZSBuaXRzLjxicj4NCjxicj4NCkkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQo8YnI+DQotw6lyaWM8YnI+DQo8YnI+DQo9PSBDT01NRU5UUyA9PTxicj4NCjxi cj4NCi0tIFNlY3Rpb25zIDEgYW5kIDMtLTxicj4NCkkgc2hhcmUgTGFycycgY29uY2VybiBhYm91 dCB0aGUgJnF1b3Q7dXBkYXRlJnF1b3Q7IGluIHRoZSBsYXN0IHBhcmFncmFwaC48YnI+DQo8YnI+ DQotLSBTZWN0aW9uIDUuMSAtLTxicj4NCkVkaXRvcmlhbCBjb21tZW50OiB3aHkgdXNpbmcgYSBz dWItc2VjdGlvbiA/IExldCdzICdnbHVlJyBpdHMgY29udGVudHMgdG8gdGhlPGJyPg0KZmlyc3Qg wqcgb2Ygc2VjdGlvbiA1LiBCVFcsIGludGVyZXN0aW5nIHJlYWQgdGhpcyBzZWN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TZWN0aW9uIDUg aXMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYW5kIGhhcyBubyBzdWJzZWN0aW9ucy4gQW0gSSBt aXNzaW5nIHNvbWV0aGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo9PSBOSVRTID09PGJyPg0KPGJyPg0KLS0gU2VjdGlvbiAyLjIgLS08YnI+DQpVbnN1cmUgd2hl dGhlciAmcXVvdDtSZXF1ZXN0cyBmb3IgQ29tbWVudCAoUkZDKSZxdW90OyBpcyByZWFsbHkgcmVx dWlyZWQgOy0pIGNmcjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21h dGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QWdyZWVkLCBhbmQg Zml4ZWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KLS0g U2VjdGlvbnMgMi4yIC4uLiAyLjcgLS08YnI+DQpNb3N0bHkgY29zbWV0aWMgYnV0IEkgd291bGQg aGF2ZSBwcmVmZXJyZWQgdGhlIHVzdWFsIHByZXNlbnRhdGlvbiB0byBpbnRyb2R1Y2U8YnI+DQp0 ZXJtaW5vbG9neSwgaS5lLiwgYSBsaXN0IGFuZCBub3Qgc2V2ZXJhbCBzdWItc2VjdGlvbnMuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1heWJlIHdl IGNhbiBtYWtlIHRoaXMgYSBub3RlIGZvciB0aGUgUkZDIEVkaXRvciA/Jm5ic3A7ICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aW08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C098F99CA00C46638B0FB5A4FC68BD16ciscocom_-- From nobody Sun Apr 18 03:00:20 2021 Return-Path: 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 62D0A3A0D5A for ; Sun, 18 Apr 2021 03:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sxYsnt1oauNE for ; Sun, 18 Apr 2021 03:00:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 92BE03A0D51 for ; Sun, 18 Apr 2021 03:00:10 -0700 (PDT) Received: (qmail 64435 invoked by uid 100); 18 Apr 2021 10:00:09 -0000 Date: 18 Apr 2021 09:59:44 -0000 Message-ID: <20210418095944.64419.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 18 06:00:08 2021 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 10:00:15 -0000 Count | Bytes | Who ------------+----------------+------- 2 (18.2%) | 32480 (28.8%) | Tim Wicinski 2 (18.2%) | 14484 (12.9%) | Murray S. Kucherawy 2 (18.2%) | 9818 ( 8.7%) | Lars Eggert via Datatracker 1 ( 9.1%) | 29970 (26.6%) | Eric Vyncke (evyncke) 1 ( 9.1%) | 13555 (12.0%) | Craig Schwartz 1 ( 9.1%) | 5886 ( 5.2%) | Lars Eggert 1 ( 9.1%) | 3434 ( 3.0%) | 1 ( 9.1%) | 3058 ( 2.7%) | John Levine From nobody Mon Apr 19 08:36:57 2021 Return-Path: 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 F12F63A35F4; Mon, 19 Apr 2021 08:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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_NONE=-0.0001, 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=gmail.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 CHF753hL7O0l; Mon, 19 Apr 2021 08:36:45 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500F83A36A1; Mon, 19 Apr 2021 08:36:31 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id a9so24450510ioc.8; Mon, 19 Apr 2021 08:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hst3uymJvbPLQm3i3c9tmfd2C0juAxrDrRLKyB/KSmQ=; b=A+Hwky+NJ0SziyFnpjYHRjY8aE5OH3tq4fuXdYLssGV1peiZA0ymZfwLW6TbmcZ5Ke PHUltnnXGxMPEh8hNwuMVj63CSHoMK0svQGNpr6ODdydCM0ChuzLZtmksvadzlAYJ36B jo9fVScyuurn4lh0yjc/bjorfmwiKArLNhCH+db2jqTi6nbxOhiRMyO+WCKkgIG2sz/x Fth1NIBXayzZ3q7qknkg6mfFZ8vaxTpUfC4YlZb0pAockGVFs4VhGAg9zf3UlC4FYPf4 7bCsRc2FSvPKHmuMOP3+pTEH4OSbWC0KgjJb2v7b6Aq18XzRx1mNjZKPAQnLeYoM1un3 ckSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hst3uymJvbPLQm3i3c9tmfd2C0juAxrDrRLKyB/KSmQ=; b=CGG+UlINhpPfotCSRzSHkrFMoVvrRl9bYSVaBls7n2eTwwyEoE3vxdJvmtRYhL60ns avH0JfvxCXeaE9uay4DstNXFbHLgXi+ZnJ5o0RuDKbI0zNsyM7rgq7l7Ee3v9mAtz7qt esVfLVJh5Su2CxNbjkGsAUOaSWIv31GyfGOpklnOVgaGtHRAq83mVVdZ1VvVhfnJbF/z 90ZGFsIILU33stHwLn2g0uFZKSdAqVhvrMRdapsQfZbjB8TyKK9rxSYX0W0uIw8q4qcn 7ycaEDSGol3JR6ufB5qJwIZ6CVxnjkBWarA5P/lGjsQ6A86Nt2/F94bPZIlvrpfyGPuF 9Vzg== X-Gm-Message-State: AOAM531nZmz9/QD3yVdz5YB5gR6u1oD4s9dJpT+oT0h8XuwOkspYyqc+ 5jdtIQ2AWmMzAkyphf2rmfVHXVhcHvhGkMtyWf8= X-Google-Smtp-Source: ABdhPJzt3qk1JEQt/2RdIAZGnX/HKsOGn/G73s4aSb7v9L5HZtt6MxNj+A3KX6jG0Bv807Fdq/y52Afed9NNo5cArG0= X-Received: by 2002:a02:4e45:: with SMTP id r66mr16717677jaa.137.1618846589865; Mon, 19 Apr 2021 08:36:29 -0700 (PDT) MIME-Version: 1.0 References: <161847105823.12240.11886353486421150693@ietfa.amsl.com> In-Reply-To: From: Tim Wicinski Date: Mon, 19 Apr 2021 11:36:19 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-dmarc-psd@ietf.org" , "dmarc-chairs@ietf.org" , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000ef517e05c05517ce" Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 15:36:50 -0000 --000000000000ef517e05c05517ce Content-Type: text/plain; charset="UTF-8" On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (evyncke) wrote: > Tim, > > > > Thank you for your quick reply and the updates to the document. > > > > My comment on section 5.1 was actually on section 4.1 ... Sorry about the > mix, I should drink more coffee it seems :-o > > > Ahh, I see what you are referring to. I think it was written as a subsection with the thought of adding this section to the Privacy Considerations section of the DMARC-bis document. Perhaps some wording to reflect this? "If this experiment is successful, this section should be incorporated into the Privacy Considerations section of DMARC-bis" ? tim --000000000000ef517e05c05517ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (= evyncke) <evyncke@cisco.com>= wrote:

    Tim,

    =C2=A0

    Thank you for your quick reply = and the updates to the document.

    =C2=A0

    My comment on section 5.1 was a= ctually on section 4.1 ... Sorry about the mix, I should drink more coffee = it seems :-o

    =C2=A0

    <= /div>

    Ahh, I see what you are referring to.=C2=A0 I think it w= as written as a subsection with the thought of adding this
    section to the Privacy C= onsiderations section of the DMARC-bis document.=C2=A0 =C2=A0Perhaps some w= ording to reflect this?
    "If this experiment is successful, this section should = be incorporated into the Privacy Considerations section
    of DMARC-bis" ?

    tim


    =

    --000000000000ef517e05c05517ce-- From nobody Mon Apr 19 09:52:05 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B43A3A86; Mon, 19 Apr 2021 09:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <161885112312.4942.10331763108529677724@ietfa.amsl.com> Date: Mon, 19 Apr 2021 09:52:03 -0700 Archived-At: Subject: [dmarc-ietf] Robert Wilton's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 16:52:04 -0000 Robert Wilton has entered the following ballot position for draft-ietf-dmarc-psd-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. A few minor clarifying comments that may help this document: o Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in [RFC7489]. They control all subdomains of the tree. These are effectively private domains, but listed in the current public suffix list. They are treated as Public for DMARC purposes. They require the same protections as DMARC Organizational Domains, but are currently unable to benefit from DMARC. I found this paragraph confusing. In "These are effectively private domains", it wasn't clear to me what "these" refers to. Is it the domains or the subdomains. Otherwise it says "these are effectively" twice, with two different descriptions. ​Perhaps, check if this paragraph can be reworded to make it clearer. ​These ​issues are not typically applicable to PSDs, since they (e.g., the ​".gov.example" used above) do not typically send mail. ​ I presume that this means that emails are not directly sent from @gov.example, rather than there is no mail below .gov.example. Perhaps worth clarifying? For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broader definition than that in NXDOMAIN [RFC8020]. I presume that this means that there is no response for any of A, AAAA and MX records, not that there is no response for a particular type of record. Should this be clarified? Although arguably it seems pretty obvious. Thanks, Rob From nobody Mon Apr 19 10:27:33 2021 Return-Path: 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 7F2B93A3BAA; Mon, 19 Apr 2021 10:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dYr6NVlz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jCfxvSDp 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 KiEV53WwuZOy; Mon, 19 Apr 2021 10:27:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DC43A3BA8; Mon, 19 Apr 2021 10:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10889; q=dns/txt; s=iport; t=1618853245; x=1620062845; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CAiaZlILV/xArpqpca4IV8qsOOLd+O5xuvISfvmMGho=; b=dYr6NVlz6x4lQSu9s0ODEGceGFReRTYRiQnvm8ftqwFXi9oMlDsJQZDm BFLk9A1K3PpWa4kTJahhU9dcBsoz02P69S11ZClUav1TRVQfW8iaXIMZA 5pZPKTftVvk2K45AfCSYTM8pz8yMWhZCa4pA1goJa/57iWSEULH6LH/oY M=; X-IPAS-Result: =?us-ascii?q?A0BYAABevH1g/5xdJa1aHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gcBAQsBgSIwKSgHd1o2MYRDg0gDhFlgiHADii+KGIR2gS6BJQNUCwEBAQ0BA?= =?us-ascii?q?TICBAEBhFACF4FdAiU0CQ4CAwEBAQMCAwEBAQEBBQEBAQIBBgRxE4VQDYZEA?= =?us-ascii?q?QEBBCMdAQE3AQ8CAQgOAwMBAigDAgICHxEUBgMIAgQOBYJxAYF+VwMvAZ8/A?= =?us-ascii?q?oofeYEygQGCBAEBBoUyDQuCEwmBOgGCd4QJAQGCQIQSJxyBSUKBEyccgl8+g?= =?us-ascii?q?QSBGoJEFoJhNoIrgy4EIhkcK4FOBJRCQodungRbCoMMkVuFdoU7BB+lAoUSn?= =?us-ascii?q?xSUMgIEAgQFAg4BAQaBVDqBWXAVGksBgj5QFwIOjh8XgQ0BCIJDil1zOAIGA?= =?us-ascii?q?QkBAQMJAXuMEwEB?= IronPort-PHdr: A9a23:rWKvXRQjYS5H1s9xwGFCt5Ygptpso0/LVj590bIulq5Of6K//p/rI E3Y47B3gUTUWZnAg9pLjuPXt+brXmlTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2X aEgHF9o9n22Kw5ZTcD5YVCBrXi77DpUERL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/J Rm7t0PfrM4T1IBjMa02jBDOpyggRg== IronPort-HdrOrdr: A9a23:vagu46n2EBPXg2IfWOx1QFr5ksrpDfNujmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8MZ Ka6NZOqTbIQwVoUu2QAH4ZU+/f4+DajZ6OW29GOzcLyimryQmp5rnzDgSC0n4lMw9n7L8+/Q H+4nfEz4q5tfXT8G6460by6NBslMLl2p9/AqW3+7QoAxHNrirtW4h7Qb2Fu1kO0aGSwXInis PFrRtlH+kb0QKqQkiPrRHg2xbt3V8VgheIozL18BiTw/DRfz40B9FMgohUaHLimjcdleth26 FG1X/xjeswMTr8nT/w79WNdxZmmlvcmwtbrccvjmdSWYZbVblJrYZ3xjItLL48GkvBmeQaOd grKPuZyOddcFucYXyclHJo2saQUnM6GQrDalQeu+SOugIm30xR/g89/ogyj30A/JUyR91v/O LfKJllk7lIU4s/cb99PuEcWsG6Y1a9Ay7kASa3GxDKBasHM3XCp9rc+7Mu/tynf5QO0d8UlI neVkhb8Uo/YVjnB8HL/JAjyGGJfEyNGRDWju1O7ZlwvbPxAJDxNzeYdVwom8y85/oFBMnWXO uyJYJWD/fvIXCGI/cP4yTOH71pbVUOWswcvdg2H3iUpNjQF4HsvuvHNPbfTYCdVwoMayfaOD 8uTTLzLMJP4gSAQXnjmiXcXHvrZwj69ZJ0G67K4vgLxOE2R9RxmzlQrW78ytCAKDVEvKBzVl B5OqnbnqSyonTz+33J4WVvMh9UFV1U/73kTnNPqWYxQgfJWIdGn+/aVXFZ3XOBKBM6ZdjRCh Rjq1N+/r/yM4ad3jk4C9WsMnuTinwaoH7ideZFpoSzoePePr8oBJcvX6J8UTjRHxtugABwtS NocwkfXHLSETvolISohJEZH/vkatF5mQunSPQk8k73hAG5n4UPTmFedyOyWcSX6DxeNgZ8tx lUyesjp5au3RyoMnAyhewkNkYkUhXmPJt2SCKfZItVnbj3fhpXVmniv03BtzgDPkz36k4Vmm vtaQqTdP2jOCsAhlloloD37VhzamKRO3hVV0k/m4h8GWPa00wDjNOjbrav0meXd1sJyvwcNj aAejcJPgZy3bmMpWyosSqZGW5jzpsjOfG1NsVRT5jDnnyqM4GGjqcAArtd+4tkLsnntqsRXf uYYBL9FkK1N8o5nwiUrG0iIi96tT0tlu7pwgTs6AGDrTQCKOuXJFRtXLcAJd6Aq2DiWvaTyZ 18ydY4p/G5PGm0atmIz8jsHnN+AwKWpW69VOczr59I+ao0qbtoBpHeFSLSy2sv5mR2EO7k0E cFBKhr6rHIPYFiO8QUZiJC51Is0NCCNlEivAD6CvI3FGtdwEPzLpeM+f7FuLAvCkqOqE/rNV 6T/zZU8v3FUyGAvIRqQJ4YMCBTcgwx+X5i9OSNe8nMEw2sbfhE50f/PXmncrNRIZL1V4k4v1 J/+ZWPkOCWfSajh1yVsjt/P65U82GoBcm1GxmBHOZU89q8fVSA65Hal/KbnXPyU3+8bU9dmI hOMUoXZc5HgiM5jII23jOpI5aH6n4Ngh9b+3V/ilXp2oK6+2/VEkFNLB3BjvxtLE1uG2nNid 6A7POR23v86iVUwJXPFE9feddVBtgbJ7KHWRtGOIwXp76n/60mnyRFblMvFgcH+UXA498= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,234,1613433600"; d="scan'208,217";a="684237618" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2021 17:27:24 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 13JHROdd005446 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 19 Apr 2021 17:27:24 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 19 Apr 2021 12:27:24 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 19 Apr 2021 12:27:23 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 19 Apr 2021 12:27:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J1oI9N7G9YGWizMBGjuU2+AKhmBjjekLFPprfBmXP6IVvnJgrHVf8iE/+XzCYumIHGlz7hUZHayPD6DbGziWYPQHakM0bsdyFmIkCy1/i13NHYHcg3JHyRL83N1oAO+Y3Ovtx6klx1x2hUWbhgYc1WfCy5GNlWbbzHo0vNkPYUr5vmQWy3UThdDg0Sn9JhuMf9lgH4KJsMTgwKpzaj0oafGC7v/bGAqImkNumFvRRs+KYNzWDBRXWnFLsOZJQz0ZbJvvc+MUooNRX8zWyY/TQsSfYpevBKUng10k/uxnu51GyglRWtmMoZdDgQ+f6LOHWBMG5cN2J0c3pZhF4LPIUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAiaZlILV/xArpqpca4IV8qsOOLd+O5xuvISfvmMGho=; b=KRsYzx0SktxslXwuoxUEgqMMxu5yzrC4PjLjt1zKOSjX8BCuvvCZ3WEaL6X0jIj1zOGgp5JvKOEo+82wMVjYb1DdPaq0hVWGYAFTitIgLvyYJXzUOouqGebyWl5V+4EmEWJwjo/n1vEMwM9Ji8hFGuZggdopL9I0C9i2VgVtgReKSCDueogg5RW1xutvVnRuVIEp09cIgdQtx3Nl3aRZ+vM/Ray/jRCOr+/XDNlgh5m7ACKoJ6CE2rlRhHnre00cUmjARwY6qMImeE5ar96N7coK9jzpahPqmIEPdJesAFFWmBxRSTttFiUgBTbiZZwvW+by3DL/WqmKYOPgWvheqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAiaZlILV/xArpqpca4IV8qsOOLd+O5xuvISfvmMGho=; b=jCfxvSDpnp3TFmbMFq8dyapzNSDZcCF637gKXEoS5BId4wIEIfo3/o0dSJo7pWxD5pMHnsu81QU+EXLtYvG7T4p6MFWZ0PRR07LZ/kSOOCBT3kv3uLekZNPEqXL30zZZ3Z3knTTOEqR/8J2uuBJrz8pT+eYM0qqzbdwk5gQZPbA= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5158.namprd11.prod.outlook.com (2603:10b6:510:3b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Mon, 19 Apr 2021 17:27:22 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Mon, 19 Apr 2021 17:27:22 +0000 From: "Eric Vyncke (evyncke)" To: Tim Wicinski CC: The IESG , "draft-ietf-dmarc-psd@ietf.org" , "dmarc-chairs@ietf.org" , IETF DMARC WG , Alexey Melnikov Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG1h?= =?utf-8?Q?rc-psd-12:_(with_COMMENT)?= Thread-Index: AQHXNTHPiielIxgEmE6uP69TIZIA/6q8OaYA Date: Mon, 19 Apr 2021 17:27:22 +0000 Message-ID: <747DD7A5-9B91-48DF-8E19-8BEF36608310@cisco.com> References: <161847105823.12240.11886353486421150693@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:4108:b7e0:ed19:cb0f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb4d3f06-d9d0-4995-64ab-08d90358647b x-ms-traffictypediagnostic: PH0PR11MB5158: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sGNLezZz2H00vqG3BRoMR4A6GPWd3mNZ7fRkJCApaBfTRu8XeauU7HGMyrFgAEusIpPoo3P8Ucl1gxnHbjAxiaTlnEEZV7VTYcJnokTp7hGsHTHoLUuDokggTa32K3dgr1wqAfLYoRDRCJb6D75i0g1wBqPTEWoN+Me+KM5pFR4cvAbXJEqt9s4daOMkoL5Zm3osuZH9URl/9HrdPl0ezFT2c+QFbRRE0t3SBA8KxsKWGu3yKmLUR7U042ZEsvpMeYAxRigktTOqh6o/kKH7T+Ok2C5cgVRIiIeR/Z0gqLGuqDIN+zb7y97hep0ZZBrlpdTpj/jy3FsxtwJROre7iV0ywT+4Gie2RQ3aD+fPpI30MY/nmfykPGoW9h52610m28HcxH1jym8BYj4kNtcJCReCzi76oBOmHeVTwUM9pZOz9LNHaI8zVszJY8y9hW2LIOZiM1vhAxzX6fJH/T0hZS85yI1uW2MnaGeveulGiMp+dYy5XuA14faDTywTLBaSIANbvS7YOebnUhXOwSdu/QUoHSTB9VeD1GJJ7HjjXMHNxMRXYfGyVGD86tooBerOx3o8ORH9H61MIL7q7CQrjhUomSvwJfnzPPoMKYWOhig9+9UYqoJGzrgDLdvHNwKixzvmyLBgLBH/R4S23nyZMf6BfsALacw8bX2RBl/OQ5s= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(366004)(376002)(396003)(6486002)(76116006)(53546011)(6512007)(5660300002)(6506007)(66946007)(33656002)(66476007)(64756008)(478600001)(91956017)(4326008)(36756003)(66556008)(2616005)(86362001)(224303003)(54906003)(83380400001)(2906002)(8936002)(6916009)(186003)(38100700002)(316002)(66446008)(122000001)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?YndRcTgzYk1MN1ZWYzU3UWROWWd2Znc3WmVTZTVhR0VKQWR2VC9TM2crT2ZW?= =?utf-8?B?bVg2RHBEaGlFWDh5UlRvRlhWOUIyU0RiSDRxQnRZRkt4ZDRPSkVSQ0ZXMGJs?= =?utf-8?B?dHU0SDNaTmRkL0pzbnhCVXdyaXFxbGo2TDRYT2lsQmNqc0l5c3QxWTNBcko4?= =?utf-8?B?MEV5SUJVMjJneXZZdkJPS0Nad0ZIUXFGcVpYR2RLVWtka0h2RWlOV0U3R0ZV?= =?utf-8?B?dGplMlpYWk9YVEluZUpCb3ZZQzhvR095b1YyT0JKRlFJaEhjeEgyNjZITFN4?= =?utf-8?B?dDhxbGV5TkVxenRiK3NxWCtDbDBwOHpQdS9pcjJoOCt4L01JUU1LUlZLeFJT?= =?utf-8?B?K2NwRUhTemx3SHJtVDJ4RUtSMld4bDkrTHZ2eFdlNFFXd2FKL1VKenlYajU3?= =?utf-8?B?S1BqVDRTRG9DYUZScFRBZk9IcW9mLzVrTUhLWnpsVktFUFNXSGNZZ2FuNnQy?= =?utf-8?B?VERvNmVvYkhKQTZwblNWY0gvTjMvNjJPTTM1bGk3b0lMWE9PanB2WkdZNE8v?= =?utf-8?B?cjhYSGhCL0o0SHNtQUE4S05Ec1NmUSs5RlJTWjRvM1VYblljWU1IZ2FjWDhy?= =?utf-8?B?NkdGLzU0aXQvSDMyV2FxbThMbjZTQ2xMVVdvUzhCVlMxbG84MldEME5kRTNw?= =?utf-8?B?SzRuWmROZGMxZjdoMDUyUG1RY0RQZGhwWmlnTXBVQ2dsTW5UbFZVWHlxMlZU?= =?utf-8?B?eWFBRUFpY3FWenNtSkRuT3ZBVk9Bd0J0eFhBdnd2NEhiWFZ0dVNYQUUwNUdt?= =?utf-8?B?STdNSXZxY2J3eUpxbFg0c3R3OXZtWGg4VDYyeTNIeStZS2lQSm9UMnRnOHdw?= =?utf-8?B?eitLVmRyOXF6T095R0pycmUwcWtxbHAyQVJiVGZOR0o4VXZMYStiS1lFQTVl?= =?utf-8?B?V0IveVE5MU9hcTZHSGpWTFE5L3FHUVV5RDg4ODJ4aXNIL0JZMzFYZTRWV3Fh?= =?utf-8?B?UDNvK0pRSUtPNi9YOXp1dDVCWFhXR09DUFlySzY5dERuTjZkcFQrdGFjV3Bi?= =?utf-8?B?SEFQcVdpcTdPVlZxR1lsVWF6YnQ2RWFpbDBFeWRnOEpXUVFTSG81UVJySDI4?= =?utf-8?B?MllPRFI0V3F2SWtrSEtQZXcrY1EyOFR4ZUxvb2h1b3VRYkt4YitkM3QyWUV4?= =?utf-8?B?bDVBR3J1cllDcDE5Ykl4RkN4dE94bTdBZGk0SWlCdnJOOHFWenhLMGc0QzR4?= =?utf-8?B?NGNwbFprOGQ3QmRVdnpXMEhtSnozL1dvWXdVR0RteFJxdXMrZ2p1bzU1SGls?= =?utf-8?B?RlpWaEF4VTZJWHVYWWxkam5USDRzSzRPR0hXUkxVc2NWbFFxaFYyMjRVZHZl?= =?utf-8?B?SUt4L1BVNFcvNk56bmwvc1Btbm9lRTVJbnFCUzFYdDA2ZjVuNE9iQVZ3REVL?= =?utf-8?B?TEQzamNEQjdWTmZENDVvODNGbDVBNzlxdjk0R2owQU9aWUo0emo1NHlhQzJk?= =?utf-8?B?QkZBUGpIdEpBcDdTSWU5am5JUjB3K2FKREdJS3VaeFBHS0RFRHh2UnZRNHFo?= =?utf-8?B?UUNQOFJ0WWdTT0tMSll5ZTJ1STBrR3A5SjYrQ042Tmh6YXl5OWNRVnJ5RWJL?= =?utf-8?B?VXBoQ29kVFMrQ0p2V3U0ZWs4WjE3OVZrdTJNbitkdUpkN3QwbEdFcWxCbDJN?= =?utf-8?B?ZGx1Ry8zbzJyemNoeVlmRUx0WHJ6QTZCdHlXdWlEZEZwc2xMYi94OFVSWlp5?= =?utf-8?B?S2dKU09kaElNdzhaV3RlUmZXT2xGRHdrOXNXQStHVjFZVDVRZmpXYlhoblAr?= =?utf-8?B?a3ZBZ2djNDVMR3J5MFh3djJGSVdNUzNUYkd4RmpSTDYrQWFDTXhpRmtVMktW?= =?utf-8?B?UHhMN1ZWQ3RWWllFL0ZSOGpVd1ZjZlBVWVBmOW9ncm1uL2s4Q25MT092YVZk?= =?utf-8?Q?e8JmcZP2pY0hO?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_747DD7A59B9148DF8E198BEF36608310ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb4d3f06-d9d0-4995-64ab-08d90358647b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 17:27:22.6115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O8b2ThDBdAq8z0344CGTVNDu/kglf5cEM5N6DSxZ9TOUixq9iLD2GOXpPSXy5s4CtsAx/DyukUDHOQxuwpjwsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5158 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 17:27:32 -0000 --_000_747DD7A59B9148DF8E198BEF36608310ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLA0KDQpXaHkgbm90ID8NCg0KT3IgZXZlbiBnb2luZyBzaW1wbGVyIGFuZCByZW1vdmluZyB0 aGUgc3ViLXNlY3Rpb24gdGl0bGUgKGtlZXBpbmcgdGhlIHRleHQgb2YgY291cnNlKQ0KDQpBcyB5 b3UgY2FuIGd1ZXNzLCB0aGlzIGlzIHB1cmVseSBjb3NtZXRpYywgc28sIGZlZWwgZnJlZSB0byBp Z25vcmUgbXkgc3VnZ2VzdGlvbg0KDQpLaW5kIHJlZ2FyZHMNCg0KLcOpcmljDQoNCkZyb206IFRp bSBXaWNpbnNraSA8dGp3LmlldGZAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCAxOSBBcHJpbCAy MDIxIGF0IDE3OjM2DQpUbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPg0KQ2M6IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgImRyYWZ0LWlldGYtZG1hcmMtcHNkQGlldGYub3JnIiA8 ZHJhZnQtaWV0Zi1kbWFyYy1wc2RAaWV0Zi5vcmc+LCAiZG1hcmMtY2hhaXJzQGlldGYub3JnIiA8 ZG1hcmMtY2hhaXJzQGlldGYub3JnPiwgSUVURiBETUFSQyBXRyA8ZG1hcmNAaWV0Zi5vcmc+LCBB bGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+DQpTdWJqZWN0OiBSZTog w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG1hcmMtcHNkLTEyOiAo d2l0aCBDT01NRU5UKQ0KDQoNCg0KT24gRnJpLCBBcHIgMTYsIDIwMjEgYXQgMTo0MyBBTSBFcmlj IFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPG1haWx0bzpldnluY2tlQGNpc2Nv LmNvbT4+IHdyb3RlOg0KVGltLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcXVpY2sgcmVwbHkgYW5k IHRoZSB1cGRhdGVzIHRvIHRoZSBkb2N1bWVudC4NCg0KTXkgY29tbWVudCBvbiBzZWN0aW9uIDUu MSB3YXMgYWN0dWFsbHkgb24gc2VjdGlvbiA0LjEgLi4uIFNvcnJ5IGFib3V0IHRoZSBtaXgsIEkg c2hvdWxkIGRyaW5rIG1vcmUgY29mZmVlIGl0IHNlZW1zIDotbw0KDQoNCkFoaCwgSSBzZWUgd2hh dCB5b3UgYXJlIHJlZmVycmluZyB0by4gIEkgdGhpbmsgaXQgd2FzIHdyaXR0ZW4gYXMgYSBzdWJz ZWN0aW9uIHdpdGggdGhlIHRob3VnaHQgb2YgYWRkaW5nIHRoaXMNCnNlY3Rpb24gdG8gdGhlIFBy aXZhY3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGUgRE1BUkMtYmlzIGRvY3VtZW50LiAg IFBlcmhhcHMgc29tZSB3b3JkaW5nIHRvIHJlZmxlY3QgdGhpcz8NCiJJZiB0aGlzIGV4cGVyaW1l bnQgaXMgc3VjY2Vzc2Z1bCwgdGhpcyBzZWN0aW9uIHNob3VsZCBiZSBpbmNvcnBvcmF0ZWQgaW50 byB0aGUgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uDQpvZiBETUFSQy1iaXMiID8NCg0K dGltDQoNCg0K --_000_747DD7A59B9148DF8E198BEF36608310ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <87649290312D5A4CB2DC5A8516DEC2A1@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGltLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+V2h5IG5vdCZuYnNwOz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9yIGV2ZW4gZ29pbmcgc2lt cGxlciBhbmQgcmVtb3ZpbmcgdGhlIHN1Yi1zZWN0aW9uIHRpdGxlIChrZWVwaW5nIHRoZSB0ZXh0 IG9mIGNvdXJzZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHlvdSBjYW4gZ3Vlc3MsIHRoaXMgaXMg cHVyZWx5IGNvc21ldGljLCBzbywgZmVlbCBmcmVlIHRvIGlnbm9yZSBteSBzdWdnZXN0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5LaW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi3DqXJpYzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5UaW0gV2ljaW5za2kgJmx0O3Rqdy5pZXRmQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCAxOSBBcHJpbCAyMDIxIGF0IDE3OjM2PGJyPg0K PGI+VG86IDwvYj5FcmljIFZ5bmNrZSAmbHQ7ZXZ5bmNrZUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5UaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYt ZG1hcmMtcHNkQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWRtYXJjLXBzZEBpZXRmLm9y ZyZndDssICZxdW90O2RtYXJjLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7ZG1hcmMtY2hhaXJz QGlldGYub3JnJmd0OywgSUVURiBETUFSQyBXRyAmbHQ7ZG1hcmNAaWV0Zi5vcmcmZ3Q7LCBBbGV4 ZXkgTWVsbmlrb3YgJmx0O2FsZXhleS5tZWxuaWtvdkBpc29kZS5jb20mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1k bWFyYy1wc2QtMTI6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmksIEFwciAx NiwgMjAyMSBhdCAxOjQzIEFNIEVyaWMgVnluY2tlIChldnluY2tlKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkZSIj5UaW0s PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+VGhhbmsgeW91IGZvciB5b3VyIHF1aWNrIHJlcGx5IGFuZCB0aGUgdXBkYXRlcyB0byB0 aGUgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+TXkgY29tbWVudCBvbiBzZWN0aW9uIDUuMSB3YXMgYWN0dWFs bHkgb24gc2VjdGlvbiA0LjEgLi4uIFNvcnJ5IGFib3V0IHRoZSBtaXgsIEkgc2hvdWxkIGRyaW5r IG1vcmUgY29mZmVlIGl0IHNlZW1zIDotbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkFoaCwgSSBzZWUgd2hhdCB5b3UgYXJlIHJlZmVycmluZyB0 by4mbmJzcDsgSSB0aGluayBpdCB3YXMgd3JpdHRlbiBhcyBhIHN1YnNlY3Rpb24gd2l0aCB0aGUg dGhvdWdodCBvZiBhZGRpbmcgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+c2VjdGlvbiB0byB0 aGUgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoZSBETUFSQy1iaXMgZG9jdW1l bnQuJm5ic3A7ICZuYnNwO1BlcmhhcHMgc29tZSB3b3JkaW5nIHRvIHJlZmxlY3QgdGhpcz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZxdW90O0lmIHRoaXMgZXhwZXJpbWVudCBpcyBzdWNjZXNzZnVs LCB0aGlzIHNlY3Rpb24gc2hvdWxkIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBQcml2YWN5IENv bnNpZGVyYXRpb25zIHNlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm9mIERNQVJDLWJpcyZx dW90OyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PnRpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_747DD7A59B9148DF8E198BEF36608310ciscocom_-- From nobody Mon Apr 19 11:03:33 2021 Return-Path: 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 A747A3A3D07; Mon, 19 Apr 2021 11:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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, 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=gmail.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 8drDcO5chvPG; Mon, 19 Apr 2021 11:03:23 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CFC3A3D03; Mon, 19 Apr 2021 11:03:22 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id l9so1427716ilh.10; Mon, 19 Apr 2021 11:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gy8STftYmJGJLQsbPpUWZoMPs/hJHsZ4s940Oypsik0=; b=Xt651ODK/Fmo++D1t6H3tCB4H4CrtvqfLu6OT+Q+EMsUcivm8zueNHZUGsR4gATLfe XG+S6gtxh00bUjmhea8UJteOXn1E3rZvUfwUJ7Xnc0Xz0ZcxGdnEeh53Vd5mQ3CXsDjC /Yt/xeR+PaXSnZG3YUrHecgvL9yAMY5nbMGnI2UxGTgbFhvuwQqo47SCsYSRps9z532J Pz1wmp5sODyTOcaDlsnq05dW4fZXkJWGhClsh5xuuU6q88vOIbLYi0365TDxFgVVTYa9 TMb4TVIivkyCloMtXjp8AqKk+y4ptduyytGXxKrgkS6fXx2qp9okJl9JEfhTIyeYGTlL 3Now== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gy8STftYmJGJLQsbPpUWZoMPs/hJHsZ4s940Oypsik0=; b=P6d18Cgkmii/1wL5dG/6HcpSJF8Bf6lF1C4xttL36SPxh8KLKoWn0+HVw3VARIRZH8 Y9usIR0XgqXEnTAmHvn1Fl3L4TN/vftIuT5PJG920vQxDbqRdP7NH4Hq9kKkt8yfdUjk S+tYgX79tizCzQngXTR7hA7Q6rmZ5ijjm+u0kQBVY/raFeSCfnK56z8krlUTcmamcXb8 BhNId9zp0TVaOzxOMz97/GdNStJhXvy7JvLADbpk1/ED4X5B3UE587ORCQlwG7JiwbTs ZN55UNLCv6bubQu6qnf2PRZIiR9SLQnTbZUGaTFmJluiUSqyIWOAiiYfu9eKUHdm+WML DeuA== X-Gm-Message-State: AOAM531D3OOEhtG5HmioljUHBm1LHVPMBxuTP2uA9aEUaqav2K9/Ofc6 dCF/RpQSzSJjE7J7SQiV8mfqSDOg4lrA+XxpJJA= X-Google-Smtp-Source: ABdhPJx9pnKdGokSxWda/wR/nqwk0NqDRez7QyrYeIt5QEpiYQt7PQU6QPGgL7xFeBigixISjw3iS0jdm4BXNHH26i0= X-Received: by 2002:a92:ce0e:: with SMTP id b14mr18306781ilo.283.1618855399534; Mon, 19 Apr 2021 11:03:19 -0700 (PDT) MIME-Version: 1.0 References: <161847105823.12240.11886353486421150693@ietfa.amsl.com> <747DD7A5-9B91-48DF-8E19-8BEF36608310@cisco.com> In-Reply-To: <747DD7A5-9B91-48DF-8E19-8BEF36608310@cisco.com> From: Tim Wicinski Date: Mon, 19 Apr 2021 14:03:08 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-dmarc-psd@ietf.org" , "dmarc-chairs@ietf.org" , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="00000000000008355f05c0572524" Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-psd-12=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 18:03:28 -0000 --00000000000008355f05c0572524 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric I agree that a section with one subsection is a bit too much. I'll add my text and see how it all looks. tim On Mon, Apr 19, 2021 at 1:27 PM Eric Vyncke (evyncke) wrote: > Tim, > > > > Why not ? > > > > Or even going simpler and removing the sub-section title (keeping the tex= t > of course) > > > > As you can guess, this is purely cosmetic, so, feel free to ignore my > suggestion > > > > Kind regards > > > > -=C3=A9ric > > > > *From: *Tim Wicinski > *Date: *Monday, 19 April 2021 at 17:36 > *To: *Eric Vyncke > *Cc: *The IESG , "draft-ietf-dmarc-psd@ietf.org" < > draft-ietf-dmarc-psd@ietf.org>, "dmarc-chairs@ietf.org" < > dmarc-chairs@ietf.org>, IETF DMARC WG , Alexey Melnikov < > alexey.melnikov@isode.com> > *Subject: *Re: =C3=89ric Vyncke's No Objection on draft-ietf-dmarc-psd-12= : > (with COMMENT) > > > > > > > > On Fri, Apr 16, 2021 at 1:43 AM Eric Vyncke (evyncke) > wrote: > > Tim, > > > > Thank you for your quick reply and the updates to the document. > > > > My comment on section 5.1 was actually on section 4.1 ... Sorry about the > mix, I should drink more coffee it seems :-o > > > > > > Ahh, I see what you are referring to. I think it was written as a > subsection with the thought of adding this > > section to the Privacy Considerations section of the DMARC-bis document. > Perhaps some wording to reflect this? > > "If this experiment is successful, this section should be incorporated > into the Privacy Considerations section > > of DMARC-bis" ? > > > > tim > > > > > --00000000000008355f05c0572524 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Eric
    <= br>
    I agr= ee that a section with one subsection is a bit too much.=C2=A0=C2=A0
    <= div class=3D"gmail_default" style=3D"font-family:monospace">I'll add my= text and see how it all looks.

    tim


    On Mon, Apr 19, 2021 at 1:27 PM Eric Vyncke (evynck= e) <evyncke@cisco.com> wrote= :

    Tim,

    =C2=A0

    Why not=C2=A0?

    =C2=A0

    Or even going simpler and remov= ing the sub-section title (keeping the text of course)=

    =C2=A0

    As you can guess, this is purel= y cosmetic, so, feel free to ignore my suggestion

    =C2=A0

    Kind regards

    =C2=A0

    -=C3=A9ric=

    =C2=A0

    From: Tim Wicinski <tjw.ietf@gmail.com&= gt;
    Date: Monday, 19 April 2021 at 17:36
    To: Eric Vyncke <evyncke@cisco.com>
    Cc: The IESG <= iesg@ietf.org>, "draft-ietf-dmarc-psd@ietf.org" <draft-ietf-dmarc-p= sd@ietf.org>, "dmarc-chairs@ietf.org" <dmarc-chairs@ietf.org>, IETF DMARC W= G <dmarc@ietf.org>, Alexey Melnikov <alexey.melnikov@isode.com>
    Subject: Re: =C3=89ric Vyncke's No Objection on draft-ietf-dmarc= -psd-12: (with COMMENT)

    =C2=A0

    =C2=A0

    =C2=A0

    On Fri, Apr 16, 2021 at 1= :43 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:

    Tim,

    =C2=A0

    Thank you for your quick reply and the updates to the = document.

    =C2=A0

    My comment on section 5.1 was actually on section 4.1 = ... Sorry about the mix, I should drink more coffee it seems :-o<= /u>

    =C2=A0

    =C2=A0

    Ahh, I see what you are referring to.=C2=A0 I th= ink it was written as a subsection with the thought of adding this

    section to the Privacy Considerations section of= the DMARC-bis document.=C2=A0 =C2=A0Perhaps some wording to reflect this?<= u>

    "If this experiment is successful, this sec= tion should be incorporated into the Privacy Considerations section<= u>

    of DMARC-bis" ?

    =C2=A0

    tim

    =C2=A0

    =C2=A0

    --00000000000008355f05c0572524-- From nobody Tue Apr 20 16:13:13 2021 Return-Path: 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 5C5853A22AB; Tue, 20 Apr 2021 16:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXl8OIWRVJBX; Tue, 20 Apr 2021 16:13:03 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492853A22A9; Tue, 20 Apr 2021 16:13:02 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id r5so25265999ilb.2; Tue, 20 Apr 2021 16:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UYH7RRSeaf2zrBEC7s1lgNX8Af8Exh7PMpNXPO71pR4=; b=NgxVqhYyssjUQqQ/flEbX1T2j/3mgC3VV5dsj7fLeCB/joCxzSOE1u7alHZ22Ha1Ha YwPhpx0zEGayXI//IU7FBAPecul8W7ZRd6mluv2rl83740R51ohjhdGWhcbGoyEMQAIo 1RxAtWwXS++QMfGDEdTjbGqXnxVzdHvFZhapbbJuE9+utxm4glLEwxuO5SgKB1iJRSik gZkltStkIK7c1H6RXC31V6/wl0roTwpC5vglf6PVGeyfgnEhKPEMPog+bDjGmtWmK+uQ NNZnxtYVdA5MOzlfDgSYCsMaDDxv86IWBq7tHcTO1OJQZUhT9gDRVZdESbQtdYtzZvlZ qLAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UYH7RRSeaf2zrBEC7s1lgNX8Af8Exh7PMpNXPO71pR4=; b=BSfG+3LxeGFrjwC8hPPNy2ee5uoj0g+yvDgd2HKLwTcUgODhb6aRMYJBMq24CoGyon dclXEu2cgcxw8+xWzKL5zAWfzNA9VYASnSaiwVE5rhZysQBQa0HISl73cpH3z8MnDoof rQ8/iTZmFs6sO3Gw37hYoJCEXFh9zgAVxzDq5lXNa86mXoewk0kUU15MyVr+DxZPUcXE dy6AIj2jfd1DctK8R3rxOJzAll2MDtJOZb+xegxpB61LjAAP/UG5v8QK5wyQEEXofniC hsTc2vcvPw0rUnzoMOWgCTaZk+rAwlOA+uCz1Z+TP6vB9qjqN3zjmjq521c0kpPCIbKq jqcQ== X-Gm-Message-State: AOAM533sAvK5N4kz0AO6zs+DINR5qK3NEvXr3KqCV3lpXzKf8dtW05dp c2+OjcJUBC+xuaw3jLPhgne2QmI99uz9f+8TT3548IMK4qg= X-Google-Smtp-Source: ABdhPJyrnwWR3+jhOCgfA0UGEMXeNE5CktKLc+ZQ7u/xE6swVpHDJlh3i+hUH7ye2HywDhP8dpPZOGasiam2trlAMDQ= X-Received: by 2002:a92:ce0e:: with SMTP id b14mr23140985ilo.283.1618960380045; Tue, 20 Apr 2021 16:13:00 -0700 (PDT) MIME-Version: 1.0 References: <161885112312.4942.10331763108529677724@ietfa.amsl.com> In-Reply-To: <161885112312.4942.10331763108529677724@ietfa.amsl.com> From: Tim Wicinski Date: Tue, 20 Apr 2021 19:12:49 -0400 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="0000000000005baf6d05c06f9609" Archived-At: Subject: Re: [dmarc-ietf] Robert Wilton's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 23:13:08 -0000 --0000000000005baf6d05c06f9609 Content-Type: text/plain; charset="UTF-8" Robert, On Mon, Apr 19, 2021 at 12:52 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-dmarc-psd-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document. A few minor clarifying comments that may help > this > document: > > o Branded PSDs (e.g., ".google"): These domains are effectively > Organizational Domains as discussed in [RFC7489]. They control > all subdomains of the tree. These are effectively private > domains, but listed in the current public suffix list. They are > treated as Public for DMARC purposes. They require the same > protections as DMARC Organizational Domains, but are currently > unable to benefit from DMARC. > > I found this paragraph confusing. In "These are effectively private > domains", > it wasn't clear to me what "these" refers to. Is it the domains or the > subdomains. Otherwise it says "these are effectively" twice, with two > different descriptions. Perhaps, check if this paragraph can be reworded > to > make it clearer. How about instead of "These are effectively private domains, but listed in the current public suffix list." to "Branded PSDs are private domains currently listing in the public suffix list." Would that work? > > These > issues are not typically applicable to PSDs, since they (e.g., the > ".gov.example" used above) do not typically send mail. > > I presume that this means that emails are not directly sent from > @gov.example, > rather than there is no mail below .gov.example. Perhaps worth clarifying? > Would this clarify things better? "These issues are not typically applicable to PSDs, since the PSD itself (e.g., the ".gov.example" used above) does not typically send mail. " > > For DMARC purposes, a non-existent domain is a domain for which there > is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This > is a broader definition than that in NXDOMAIN [RFC8020]. > > I presume that this means that there is no response for any of A, AAAA and > MX > records, not that there is no response for a particular type of record. > Should > this be clarified? Although arguably it seems pretty obvious. > > I think adding more here will muddy the waters. I am willing to be swayed. tim --0000000000005baf6d05c06f9609 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Robert,


    On Mon, Apr 19, 2021 at 12:52 PM Robert Wilton via Datatra= cker <noreply@ietf.org> wrote= :
    Robert Wilton = has entered the following ballot position for
    draft-ietf-dmarc-psd-12: No Objection

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
    for more information about DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-dm= arc-psd/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thanks for this document.=C2=A0 A few minor clarifying comments that may he= lp this
    document:

    =C2=A0 =C2=A0o=C2=A0 Branded PSDs (e.g., ".google"): These domain= s are effectively
    =C2=A0 =C2=A0 =C2=A0 Organizational Domains as discussed in [RFC7489].=C2= =A0 They control
    =C2=A0 =C2=A0 =C2=A0 all subdomains of the tree.=C2=A0 These are effectivel= y private
    =C2=A0 =C2=A0 =C2=A0 domains, but listed in the current public suffix list.= =C2=A0 They are
    =C2=A0 =C2=A0 =C2=A0 treated as Public for DMARC purposes.=C2=A0 They requi= re the same
    =C2=A0 =C2=A0 =C2=A0 protections as DMARC Organizational Domains, but are c= urrently
    =C2=A0 =C2=A0 =C2=A0 unable to benefit from DMARC.

    I found this paragraph confusing.=C2=A0 In "These are effectively priv= ate domains",
    it wasn't clear to me what "these" refers to.=C2=A0 Is it the= domains or the
    subdomains.=C2=A0 =C2=A0Otherwise it says "these are effectively"= twice, with two
    different descriptions.=C2=A0 Perhaps, check if this paragraph can be rewor= ded to
    make it clearer.

    How about instead of=C2=A0
    "These are ef= fectively private domains, but listed in the current public suffix list.&qu= ot; to=C2=A0
    "Branded PSDs are private domains currently listing in = the public suffix list."=C2=A0

    Would that work?=C2=A0<= /div>

    <= /font>


    =C2=A0 These
    =C2=A0 issues are not typically applicable to PSDs, since they (e.g., the =C2=A0 ".gov.example" used above) do not typically send mail.
    =C2=A0
    I presume that this means that emails are not directly sent from @gov.examp= le,
    rather than there is no mail below .gov.example.=C2=A0 Perhaps worth clarif= ying?

    Would this clarify things better?

    "These issues are not typically applicable= to PSDs, since the PSD itself (e.g., the ".gov.example" used abo= ve)
    does not typicall= y send mail.=C2=A0"
    =C2=A0

    =C2=A0 =C2=A0 For DMARC purposes, a non-existent domain is a domain for whi= ch there
    =C2=A0 =C2=A0is an NXDOMAIN or NODATA response for A, AAAA, and MX records.= =C2=A0 This
    =C2=A0 =C2=A0is a broader definition than that in NXDOMAIN [RFC8020].

    I presume that this means that there is no response for any of A, AAAA and = MX
    records, not that there is no response for a particular type of record.=C2= =A0 Should
    this be clarified? Although arguably it seems pretty obvious.

    =C2=A0
    I think adding more here will muddy the waters.=C2=A0 I = am willing to be swayed.=C2=A0

    tim


    =C2=A0
    --0000000000005baf6d05c06f9609-- From nobody Tue Apr 20 22:04:36 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7953A0E55; Tue, 20 Apr 2021 22:04:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161898146809.1659.6234265375858401838@ietfa.amsl.com> Date: Tue, 20 Apr 2021 22:04:28 -0700 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 05:04:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-psd-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There seems to be a bit of internal inconsistency in Appendix B.2: Names of PSDs participating in PSD DMARC must be registered this new registry. New entries are assigned only for PSDs that require use of DMARC. [...] These two sentences seem to be in conflict, since a PSD can participate in PSD DMARC without requiring use of DMARC for all its subdomains. The rest of the section is clear that the registry is only intended to be for PSDs that do require the use of DMARC for subdomains, so I expect that a minor tweak to the wording of "PSDs participating in PSD DMARC" would be an appropriate fix. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is generally in pretty good shape; my comments (and, to some extent, my discuss as well) are pretty minor points. Thanks to Sandra Murphy for the secdir review. I think there were some questions in there that are worth a response and possibly clarifications in the document. Section 1.2 It seems like the "branded PSD" and "multi-organization PSD" cases would benefit from a protocol-level indication and separate handling by message recipients. It seems likely that the newly defined np (in combination with the preexisting sp) provides the flexibility to describe the different cases, but it seems like it would be helpful to have some discussion in this document that relates these two cases to the actual protocol mechanisms used to achieve them. Section 3 As Lars and Éric already commented, I suggest using a phrasing that includes something like "this experiment" and maybe "proposes", since actually formally updating the DMARC specification would procedurally be a bit exciting. Section 3.2 np: Requested Mail Receiver policy for non-existent subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the I assume that "subdomains" here refers only to direct children (i.e., one additional label), not deeper in the hierarchy. It's not entirely clear to me whether all readers will do likewise, though... Section 3.3, 3.6 It sounds like this entire paragraph is appended to the section? In other subsections we are a bit more explicit about where the new text is going and what part is the new text. Section 4.1 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the Organizational Domain level) vice opt-in, which would be the more desirable characteristic. This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive. It might be worth making some statement about the applicability of PSD DMARC for such PSDs that do not mandate DMARC usage. (I guess the following paragraphs mostly play that role, though perhaps editorially tying them together more clearly is possible.) Or, in the vein of my comment on section 1.2, an explicit protocol mechanism could be introduced that limits the reporting to just the indicated (public suffix) domain and does not apply to subdomains. organizational PSDs MUST be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. Do we have examples of how the reporter might come to know this? Say ... Appendix B.2? Appendix A o Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN). [...] Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN. Appendix B.1 A sample stand-alone DNS query service is available at [psddmarc.org]. It was developed based on the contents suggested for "DNS query service" is so generic so as to be almost meaningless. Even if we defer usage instructions to the external site, we should probably say a bit more about what it is expected to do. From nobody Wed Apr 21 13:38:25 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E913A35DA; Wed, 21 Apr 2021 13:38:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <161903750425.31807.342722356317203484@ietfa.amsl.com> Date: Wed, 21 Apr 2021 13:38:24 -0700 Archived-At: Subject: [dmarc-ietf] Roman Danyliw's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 20:38:24 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dmarc-psd-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Sandra Murphy for the SECDIR review. Please review those proposed clarifying edits. ** Section 4.1 Due to the inherent Privacy and Security risks associated with PSD DMARC for Organizational Domains in multi-organization PSDs that do not particpate in DMARC, any Feedback Reporting related to multi- organizational PSDs MUST be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. Is there any guidance on how the reporter might know “that [the] PSO requires use of DMARC”. ** Section B.2. -- Please define the semantics of the “status” column and the expected/possible values -- Reconcile the differences between the initial values noted in this this document and those at http://psddmarc.org/registry.html: o the text in this section says “current” for the status column, but the html page has same values as set to “active” o the PSD names in the initial values of this document are of the form “.*”, but the html page has no leading dot (i.e., “.bank” vs. “bank”) From nobody Thu Apr 22 14:35:00 2021 Return-Path: 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 02D833A0E6A for ; Thu, 22 Apr 2021 14:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 Hj3ypZhHPNxx for ; Thu, 22 Apr 2021 14:34:53 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AEF3A0E6C for ; Thu, 22 Apr 2021 14:34:53 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id j8so12182549uak.2 for ; Thu, 22 Apr 2021 14:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YlKh87jn9f7Sj7bHZY2gxB3bb0Xhm42PrIzHQYZub2s=; b=ZViS8Zc/8+ndXHj9j2qrkYmA3TZpJK1KNJ46qHYw7EB3ZSC+gSDBV0JVG/iloHUek7 kTSuE1/j6F9SL/K3YdJfUrzMfDzdVBxEba9ahrdOJhNfZ0v27xA9g8Qj1aFfokZFEsr8 rgUpleWyytsyc13VDYxCYQVlNJ7HDA/tCJxgDemUloSQDKVe29zaNMssb2a05WRhfBLU t/rJzFBJb9gYHxbKfo+l0zXlqDIcB3uenV6OyVWNtx7z+7WOK79iGrS/cAEBaI1IBQsx nx4Qe4SJuTO4asGYsiCyXUZUE6PPmhTPthD3xX8iIhUHCEpx4vbtR6oFi2k+TJBgeu4W JbSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YlKh87jn9f7Sj7bHZY2gxB3bb0Xhm42PrIzHQYZub2s=; b=gJL3VSFMkXpxupho9Xm+1sgIRl4adTI0FUCeiUiGHWrtNJyU+dixR/PHhfmTMxxnsx 2XQ0s6C7xt2zhHqnylw5rNFuGVvKrg3SY3T/bAbjTBM1/CVzjXRm2k6tbS3qX50yWYSQ s7kLSYmWCAB8/aWKpdKQPefi/ZjfluVji+65bRY51Krx1zDduOJDiMCQKoRO74OgU95l vMZyS6sczwuJTzsQ/sBr5PJggbNLa1uIMq8sxPo3UHMmHkZNzrYga9pXXODwwIGtqkkO 4hOh4pVvVxX+Vlyjle+tc14J8BjFv68TbRfPByAfu1BbEuN+PyyTy4JzbhFWYfrAld7d RVgA== X-Gm-Message-State: AOAM532NGpl5ba32Yo/HPFT5+MVC5YvMIXcD6MjDAw21o8biW1OuH5fb Cyc7HTfwedcjuUzMjBc/rDKQlrUjIVi1dyJ00DXTAzWrHnw= X-Google-Smtp-Source: ABdhPJx1sVqp/gZiJ4Hxyd3VzxUm3zf7IufkvinxTKsEuaAqectd7E5Zy7lWIbesFkBFXVLdx3FxbsDDwRryaaLGQVc= X-Received: by 2002:ab0:2908:: with SMTP id v8mr736785uap.47.1619127291456; Thu, 22 Apr 2021 14:34:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Thu, 22 Apr 2021 14:34:40 -0700 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org, ART ADs Content-Type: multipart/alternative; boundary="0000000000000dc39b05c09673f3" Archived-At: Subject: Re: [dmarc-ietf] Announcement - DMARC bis Design Team X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 21:34:59 -0000 --0000000000000dc39b05c09673f3 Content-Type: text/plain; charset="UTF-8" All-- the design team have confirmed documents are nearly ready; expect updated I-Ds for discussion in the next day or so. Once the working group has had some time to digest the documents, in parallel with any immediate feedback, our next step is to schedule an Interim meeting. Look for an email about that next week. Thanks everyone for giving the design team time to power through all the open tickets. Seth, for the Chairs (old and new) On Fri, Feb 26, 2021 at 6:14 PM Seth Blank wrote: > On Mon, Feb 22, 2021 at 9:58 AM Seth Blank wrote: > >> >> 1. >> >> A moratorium is hereby imposed on creating tickets for this working >> group, effective at 5pm PT, Friday, February 26th. >> 2. >> >> The design team will have until 5pm PT, Friday, April 23rd, to work >> through all applicable tickets, and come to agreement on each to either >> modify DMARC bis documents (and make such modification) or reject the >> ticket, with the reason for rejection added to the ticket's comments. No >> tickets will be closed during this process, everything will be transparent >> for working group review after the design period. >> >> > Tickets are now officially frozen through April 23rd, while the design > team gets to work. > > Seth, for the Chairs > -- *Seth Blank* | VP, Product *e:* seth@valimail.com *p:* 415.273.8818 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. --0000000000000dc39b05c09673f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All-- the design team have confirmed documents are nearly = ready; expect updated I-Ds for discussion in the next day or so.

    Once the working group has had some time to digest the documents, = in parallel with any immediate feedback, our next step is to schedule an In= terim meeting. Look for an email about that next week.

    =
    Thanks everyone for giving the design team time to power through all t= he open tickets.

    Seth, for the Chairs (old and new= )

    On Fri, Feb 26, 2021 at 6:14 PM Seth Blank <seth@valimail.com> wrote:
    On Mon, = Feb 22, 2021 at 9:58 AM Seth Blank <seth@valimail.com> wrote:

    1. A moratorium is hereby impose= d on creating tickets for this working group, effective at 5pm PT, Friday, = February 26th.

    2. The design team will have until 5pm PT, Friday, April 23rd, to work thr= ough all applicable tickets, and come to agreement on each to either modify= DMARC bis documents (and make such modification) or reject the ticket, wit= h the reason for rejection added to the ticket's comments. No tickets w= ill be closed during this process, everything will be transparent for worki= ng group review after the design period.

    =

    Tickets are now official= ly frozen through April 23rd, while the design team gets to work.

    Seth, for the Chairs


    --

    Seth Blank | VP, Product
    p: 415.27= 3.8818

    This email and all data transmitted with= it contains confidential and/or proprietary information intended solely fo= r the use of individual(s) authorized to receive it. If you are not an inte= nded and authorized recipient you are hereby notified of any use, disclosur= e, 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.<= /p>

    --0000000000000dc39b05c09673f3-- From nobody Fri Apr 23 07:04:59 2021 Return-Path: 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 C5F2D3A0BCE for ; Fri, 23 Apr 2021 07:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 jWgNKJW4zmzk for ; Fri, 23 Apr 2021 07:04:53 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CB13A0BCA for ; Fri, 23 Apr 2021 07:04:52 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id u20so17484494qku.10 for ; Fri, 23 Apr 2021 07:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=AAOcxRD8PCVWye3Kl1v9JDDVY1mB9Zo3P+Td0vYIAbg=; b=CeuJDmXpQzlt8zbHDKW4/JHdNjtpEPgrgHngLeuHgIPWRfuZLT2uh77UKcqyrIBLLj vxbqUUA/Fk9QPXGHslIjBvCQavFUW4ZQCrkhYxP1x4UQayJNJCgFx/ruNsUVI7Okdh8/ +S0Yt6BbkTWf62bA4B9bY7Qv2WGEwGQsJg113xHlknV54931vR43NL4FLV0qmt8ou8U1 Poe+0IMDJJ6jvDq3SeowlGaJ/1b1DaSYFTCATf/OqbMsaF2yIJSaSlR9tOSnnecL1BMl uPtPFdgH3cqHvacrSny5HpAqZnhGI+OO8Bv+BIaajlXjfeg+E6yfA9XzmKYlRx6DGW2c gFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AAOcxRD8PCVWye3Kl1v9JDDVY1mB9Zo3P+Td0vYIAbg=; b=kL/FuqwyhU8NQdLtWc4Uyh8Ha4KmAALWByhoEHxjSqZudV1JFw92msOGBCyymxweDp qB8AAXA38wFqQLaLxZOE4KeDVXdQHk/kE2MtV9sq/3jJf8mpvtywlkUPJ7nFMNGOElWw wP6XtBfsqHZptSeD7cFKV3pv7CChpISqbhgiHDEzD4cvzTgu6jGyszH78JFrtK9z9M3A SNlOuWf+Wt+sTaIdkXZmNN8Fca/UgqIP+PVCDhnivlLuDwyt+R9+ryXEVBBdwktp9f0c KI9BrTifA/Ve2AaqQVwe6SGFSs4EkaiYtjtHmixgFXZN/enqxDmoVUfGX5mKrB7kgKJV x3kA== X-Gm-Message-State: AOAM532XhOxOAUV3K6sf4k8spl8c6QwDHCBKGC1snnRM9+2hTEAZ3skr tihxLnC3b6YEhJQ5pTCNjas2GSR4Ww+s8zuAqgLth8A97oe9xw== X-Google-Smtp-Source: ABdhPJyd36Pz2stK4Bq+LY42YKG+iciG5Y0FqCtZFsFYTPyntI+Fij+rnn2N5Jq0yg7WmjnjfQCP8ydIK3rxyNK2oT8= X-Received: by 2002:a05:620a:133b:: with SMTP id p27mr4376476qkj.387.1619186690527; Fri, 23 Apr 2021 07:04:50 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 23 Apr 2021 10:04:34 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000083cc6b05c0a4472f" Archived-At: Subject: [dmarc-ietf] Expectation Setting for draft-ietf-dmarc-dmarcbis-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 14:04:58 -0000 --00000000000083cc6b05c0a4472f Content-Type: text/plain; charset="UTF-8" Greetings. As Seth mentioned in a previous email, updated I-Ds for discussion will be updated in the next day or so. Prior to my uploading draft-ietf-dmarc-dmarcbis-01, I want to make sure that everyone understands what work has been done, what hasn't been done yet, and what the document's status is. First, and most importantly, *draft-ietf-dmarc-dmarcbis-01 is proposed text, nothing more, nothing less*. I fully expect that there will be lots of discussion about it, and multiple subsequent revisions produced between now and its (hopefully) eventual adoption sometime in the future. All changes between -00 and -01 (which should be obviously reflected in the 'rfcdiff' output function on datatracker) have as their genesis one or more tickets, and the source ticket for the change has been noted in the document. What this means is that throughout the document there are notations like this: _Ticket X_ (or _Tickets X, Y and Z_) One or more paragraphs of text that were either modified due to the ticket(s) mentioned or created due to that ticket.... All changes were also tracked in several other fashions: - Updates to the associated ticket in datatracker - Pull requests in github - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis - A temporary Appendix C noting changes that were made. The tickets in question for this rev that were worked during the design team period all currently have a status of 'infoneeded'. There is a custom report available in datatracker that will show just these tickets - https://trac.ietf.org/trac/dmarc/report/14 There are a number of tickets that have not yet been addressed, save perhaps for some comments added. We expect that they will be dealt with in time. Finally, a request... Going forward, in an attempt to make life easier on your editors, we ask that when starting a discussion thread for which some part of the document text is the topic, whether existing text or proposed new text, please include the relevant ticket number(s) in the subject line. If there isn't a relevant ticket, please open one before starting discussion. Having the ticket number in the subject line makes it much easier for editors to map discussions and their eventual rough consensus to document changes. Notification of document upload to datatracker will come later today. -- *Todd Herr* | Sr. Technical Program Manager *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. --00000000000083cc6b05c0a4472f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Greetings.

    As Seth mentioned in a=C2=A0previous email, update= d I-Ds for discussion will be updated in the next day or so.=C2=A0

    Prior= =C2=A0to my uploading draft-ietf-dmarc-dmarcbis-01, I want to make sure tha= t everyone understands what work has been done, what hasn't been done y= et, and what the document's status is.

    First, and most=C2=A0importan= tly,=C2=A0draft-ietf-dmarc-dmarcbis-01 is proposed text, nothing more, n= othing less. I fully expect that there will be lots of discussion about= it, and multiple subsequent revisions produced between now and its (hopefu= lly) eventual adoption sometime in the future.

    All changes between -00 a= nd -01 (which should be obviously reflected in the 'rfcdiff' output= function on datatracker) have as their genesis one or more tickets, and th= e source ticket for the change has been noted in the document. What this me= ans is that throughout the document there are notations like this:

    =
    _Ticket X_ (or _Tickets X, Y and Z_)

    One or = more paragraphs of text that were either modified due to the ticket(s) ment= ioned or created due to that ticket....

    <= div>All changes were also tracked in several other fashions:
    The tickets in question for this rev that were worked during the design te= am period all currently have a status of 'infoneeded'. There is a c= ustom report available in datatracker that will show just these tickets -= =C2=A0https://trac.i= etf.org/trac/dmarc/report/14

    There are a= number of tickets that have not yet been addressed, save perhaps for some = comments added. We expect that they will be dealt with in time.
    <= br>
    Finally, a request...

    Going forward,= in an attempt to make life easier on your editors, we ask that when starti= ng a discussion thread for which some part of the document text is the topi= c, whether existing text or proposed new text, please include the relevant = ticket number(s) in the subject line. If there isn't a relevant ticket,= please open one before starting discussion. Having the ticket number in th= e subject line makes it much easier for editors to map discussions and thei= r eventual rough consensus to document changes.

    No= tification of document upload to datatracker will come later today.

    --

    Todd Herr | Sr. Technical= Program Manager
    m: 703.220.4153

    =

    This email an= d all data transmitted with it contains confidential and/or proprietary inf= ormation intended solely for the use of individual(s) authorized to receive= it. If you are not an intended and authorized recipient you are hereby not= ified of any use, disclosure, copying or distribution of the information in= cluded in this transmission is prohibited and may be unlawful. Please immed= iately notify the sender by replying to this email and then delete it from = your system.

    --00000000000083cc6b05c0a4472f-- From nobody Fri Apr 23 07:37:29 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1FD3A0E14; Fri, 23 Apr 2021 07:37:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <161918864839.15077.6383260592803831556@ietfa.amsl.com> Date: Fri, 23 Apr 2021 07:37:28 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 14:37:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Authors : Todd M. Herr John Levine Filename : draft-ietf-dmarc-dmarcbis-01.txt Pages : 68 Date : 2021-04-23 Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. _Tickets 75, 80, 85, 96, and 108_ DMARC permits the owner of an email author's domain name to enable validation of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's severity of concern regarding failed validation, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFC 7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 23 11:21:03 2021 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A713F3A193B; Fri, 23 Apr 2021 11:21:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <161920206063.24889.14522893541582724606@ietfa.amsl.com> Date: Fri, 23 Apr 2021 11:21:00 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:21:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC Aggregate Reporting Author : Alex Brotman Filename : draft-ietf-dmarc-aggregate-reporting-02.txt Pages : 23 Date : 2021-04-23 Abstract: DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-aggregate-reporting-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 23 11:28:21 2021 Return-Path: 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 9C1153A1978 for ; Fri, 23 Apr 2021 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 1tpwS8KgUspY for ; Fri, 23 Apr 2021 11:28:14 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 AC3083A1971 for ; Fri, 23 Apr 2021 11:28:14 -0700 (PDT) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13NIR3XL016599 for ; Fri, 23 Apr 2021 14:28:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=4lKgBE0ODZ4Uw186u5oGgdLPS1V4Yq8+3brsc02PIqg=; b=Ab/SbIf4mMzS2uovHZSCtBiyr/GCrlobk+5cnleUa9TrA+DAqKhB0TnWWyBvClVP5xo2 xTsFb8nt9nrHEyxJgMb4Lx9LaA81ZFuOAIDlqnMJz63Oe0Mf7gvO/9m3QsnO+FAD2Nws d5iqHYpmhaOd8EDSnFVoGCPiXMIRUDRV47qBQ4FcATwpVA2OPT0IKj3n6ifGiKju5ZDM QLD0AmF/NkjkNVG2WmIq7mpILyV0tSW0jK7ntG2s1VYpqC6uTk+shTJUvDktYra/YI7c GMNIltV/uQymm6/JZ0JJXJxuNnkG5iKl8eu9aKieGVLCr9qe3lkRd9PInY0HaOBgcz03 3g== Received: from pacdcex55.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 383q08vhh4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 23 Apr 2021 14:28:13 -0400 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX55.cable.comcast.com (24.40.2.154) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 23 Apr 2021 14:28:11 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 23 Apr 2021 14:28:11 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 23 Apr 2021 14:28:17 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4710.namprd11.prod.outlook.com (2603:10b6:208:262::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Fri, 23 Apr 2021 18:28:11 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4042.023; Fri, 23 Apr 2021 18:28:11 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt Thread-Index: AQHXOG13oaE5gGjBMku1y+WqERkRzKrCah6g Date: Fri, 23 Apr 2021 18:28:10 +0000 Message-ID: References: <161920206063.24889.14522893541582724606@ietfa.amsl.com> In-Reply-To: <161920206063.24889.14522893541582724606@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:100:3979:b4f5:e7df:5bfb:8ae0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f86a0462-ad1f-4ecb-ec0f-08d906858cb3 x-ms-traffictypediagnostic: MN2PR11MB4710: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d1VfPsWrhV6saOMU5ETPlybkpxN8VPgbNgeI0IXNHMsAZzf9AAxlllk0rMGu7f1KWFF9wWJn0Yl2vJ0S/bETlE1yuht+/3w+4xBoC9HMONOSGatqxEF5wl7smFyNc3L3CPdvwiY2S9VcuJT54zh/vBQxKfkfIvAkUgNKYwHelmQjmdQJTqJXEMQIrL5XvsOaV1XGRsarKJDo7Q8I6AUlFCu2CTSLUpu7dVnNL8MiN8IZBHVviFKcKYBBA5xAEhnS68ObK+snBG7euY6bswdexLJccm9PEsPu8BFAhv0+OgSg+9o1zmcycMCEWQ5juBX0/bKnJpEmRCS/kCHX1Ape7u/t8q6hyatUG6ICpy4LXiZeU3lCIjV/ncUhXHpaW1fKeo6qOYE8S+u0EKS0LHC2Nz8LwKUH3SApdgWYx32HEiZ72AqPNkSUfMw1aWozpZ2xCqj6tt1JPVJx9DiOn2Sm4dasm59IitncA4g2ZqooSZ95lw76ETMblKszjo7P00zDB2AykePOZJYbnU3ATYrLdaGaq73XhyEh3tEP+hir722dj/do3aPI/ZzT6bNK6N8/4Ven+qiuHiNTRYuwbb5gg+/0K8+YySKWSUbsswPkQCTdUB5sLXJ69bQKMHVUYheWL7mbuokCavcYzRqTbNsZj2nqH5K1dpk5F5A+JEM8azoFFWySx2gDyv6WPDzxZijk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(33656002)(71200400001)(76116006)(8936002)(7696005)(6916009)(86362001)(2906002)(53546011)(316002)(6506007)(66476007)(966005)(122000001)(52536014)(66574015)(9686003)(186003)(38100700002)(66946007)(5660300002)(66556008)(478600001)(83380400001)(55016002)(8676002)(64756008)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?UgCx8a8BOD/qUZFwSPL7vFU5Th5WcHHYdW1FhJdX2FiQSMX/FOlmF4Coc1Vy?= =?us-ascii?Q?kSXZqfaQimdpw+pU5PmMQ6BuLEJwHcNABmAdWsEcEijsBERm0u58ea5amxba?= =?us-ascii?Q?IjpcTjOJ7ue4PFsIfDOyOlJ5kdZJZwUG9DCXBce/B9NlxWOB3mPHCL9Pi8KI?= =?us-ascii?Q?00N7g044ipXwvMNyVxa1exabKZO0kI/sCtizOjXGjsWyBQO4O99LSFGOSzWY?= =?us-ascii?Q?mkiP7m0Ozy4aDv1OmHspWqbzDcnqJNsUwtUTh7ESqYtk174ZXU6TpcLHbUwH?= =?us-ascii?Q?xABR6qDXcaYaSN22vA96R6Hf3v2dsU8cwSmNCRCUtcP/wRJQpu7g0CdQ3clr?= =?us-ascii?Q?wYHMvY7gQoBHwYkEbHZnyYMwTwbJvWAaFYRWNcysf1XuEM+l5mjJPXe+mdqV?= =?us-ascii?Q?o5/adQOsCgasYlhEAW0nTKMnrjMiInJDDhWJhD/QumVUBP3wnWkb4H8gEDfa?= =?us-ascii?Q?RV2JCjfC/y4LJQTwDO2zKggjPdO5vRuOu484UibP58SESbI4/YoAHbGd/G/Y?= =?us-ascii?Q?xKIByoAv611ajxhqVxGyosmgLcrb0LTzeTytq1ESlUtkx67oTEtKnrlB5cfx?= =?us-ascii?Q?+6Ch9OV+pryUVbnUoEEZLEwrSbWPaD3ehwkJ0Jnp8bU1dtdOLKXhAsb5g/ow?= =?us-ascii?Q?KxXq4u5etqKHfZh4UFIrHdW0CAOChfsifKg54/CNgN8YCQ9YRN/DLi8GCb9/?= =?us-ascii?Q?ALxNPugVbRkCMDXNm3s1M4uODwBnzcgowvG9cxjnfEJRClt59IUQ95UQNs/V?= =?us-ascii?Q?Ky8mfhmi8hZhnbUiB5fHanyl37gTGSJFXvnjB6/P8rk2qB9JRs8VSSxHEJJK?= =?us-ascii?Q?3emzvcOkMoWgrPvfEorL3LtQLDkuoXLTusRd4TOE1wQ2WGpWvAIAx88P8SbR?= =?us-ascii?Q?pWV9phuBLBnY/QSiNDUgNXQdPAFc4xTVscNedrcxq0gd9oHU4AMiHR4aTr0C?= =?us-ascii?Q?pGlfZQ4S8qJFXjIBNMX+1JV/NjSfmYc3scxkQRCxpaRqyn51jL1/1CDOzLiN?= =?us-ascii?Q?bHrX1GauB3ZFqBuHYvHmf0TMxRoG1DSJpaRZ3X4PtxRHwlKx87ZEgsgogUTk?= =?us-ascii?Q?vY5Zj2PIwh1AQ1qbpMN11PYPOEQbLc6pRie9ZFcnSIUhHc+i3/cfO5bhlWKW?= =?us-ascii?Q?JdBoetjEXONEgE7+o3adQY76RxWtuzJi294aklTCLXsy768O9LDVTx4X1NDX?= =?us-ascii?Q?x3MMNIWI1iRd4zE6IhFfDSIaad6b3iPKD0+UWZN2va2zoQ6gechBHFARlw5u?= =?us-ascii?Q?GhPTVB6m2wyRp8MWiRjU+UJMGfDnNRYVgsztA3B/eRvmqQntBk6FWxhW86bI?= =?us-ascii?Q?IhT7VKINcujAJ74OUNApGHGPGrZiM8tHcWv65Spm3A6JHWqgzW6/ufO86av9?= =?us-ascii?Q?xu3lKmL92w8vrO00lfTbIc0ljtBm?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l6ILXmKLWJF2LWiKJvnrxd4z6s8GsMrBFYa/4m2gs8Ip5kXR4tkVgWniRvE7tKoeaEwnvsmsM4YbFN1+HHZliJffcNbYOKL2bjAhDm+LFPPZpRxb4gBcEAoqnmuKiUNI2vU3sirAk0+gccroGlUXRIDUdMgKG82Uwqn9UujNNAs0AFtbBNUGRMu/Ersu4hLxPYEYAJ/IXrWywj1rR2y/zSWw8IxJfSxhvEbrNoSFSnPqa1IaLMx1bwPTzPrNGvdKYQViJgSj25hGDzYZ0fadv/CQljoHuaiqHI8dQvpJ4046d6o4eTQuHwjGcnFfRNAH/FAlbMC40oW3xhJvtrm75Q== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=64cnUDXP6dRNZIQFmtSCLugm8y7Qqc5+HKvvfb4ovm4=; b=LFLWpETpHp+ASge8UU4ng/8SrRnR/hHiZVMYTP3dQtGD5tU9Ng2+tbyQ7jGfScMPPdRh2lryqqmmCuT/+RAarXRWhnCjBUp5I+Rmr/fSQe/Xnzoq/CQzQDNjno1raAe8ato55VXk6mT/7fMksj4h5OgnaxqKQ6h9m5+m75fave2AhAdtsMF3JFA0TC+CIYSK85WFlLoFNePb/9PDDwv7JZbXp3V7mkwR4xuO/QR1VeL/MKLxvh58ZrTLy3yIJPB4HXOl7s6f22QXVMmvBSVJY4oMyfns6cGLnMbLJFo2fKAmhT+DEuzWOKo0D1xeZPVtRZLGuswMGMXK/yenGOKeuw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: f86a0462-ad1f-4ecb-ec0f-08d906858cb3 x-ms-exchange-crosstenant-originalarrivaltime: 23 Apr 2021 18:28:10.9725 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 6Z0OL2OGLL81XOEwBf0j8wrxbWT+Z/En0FjQiC1a42R7OwJLY2h6KJmgeOjabuevPaw1+UgdP3ENbqSknSZhVacF+kCic4JsPhQA7VQk5GQ= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4710 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-ORIG-GUID: n8w2aP2tmeAQYguFf4RnZRb4sbVs2WPp X-Proofpoint-GUID: n8w2aP2tmeAQYguFf4RnZRb4sbVs2WPp X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-23_07:2021-04-23, 2021-04-23 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:28:20 -0000 Hello folks, Below you'll see the details relating to the most recent iteration of the a= ggregate reporting document. I attempted to address as many tickets as I t= hought feasible. I would probably suggest that the core of changes were re= lating to explaining more about the format, more properly defining the repo= rt format, and extensions. There are a few other items that may need resol= ved, depending on feedback from these alterations. Thank you for your feed= back, and happy reading! https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-02.txt -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc On Behalf Of internet-drafts@ietf.or= g > Sent: Friday, April 23, 2021 2:21 PM > To: i-d-announce@ietf.org > Cc: dmarc@ietf.org > Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02= .txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : DMARC Aggregate Reporting > Author : Alex Brotman > Filename : draft-ietf-dmarc-aggregate-reporting-02.txt > Pages : 23 > Date : 2021-04-23 > > Abstract: > DMARC allows for domain holders to request aggregate reports from > receivers. This report is an XML document, and contains extensible > elements that allow for other types of data to be specified later. > The aggregate reports can be submitted to the domain holder's > specified destination as supported by the receiver. > > This document (along with others) obsoletes RFC7489. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc- > aggregate- > reporting/__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaW > gQDB55FiuC8137pI2qMKu6L5N_$ > > There are also htmlized versions available at: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc- > aggregate-reporting- > 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55 > FiuC8137pI2qMGEpytDa$ > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-i= etf- > dmarc-aggregate-reporting- > 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55 > FiuC8137pI2qMMR-T_gY$ > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f- > dmarc-aggregate-reporting- > 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55 > FiuC8137pI2qMJZqLFqL$ > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.com/v3/__ftp://ftp.ietf.org/internet- > drafts/__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQD > B55FiuC8137pI2qMJhtlMe4$ > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__= ;! > !CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55FiuC81 > 37pI2qMMU63FiT$ From nobody Sun Apr 25 03:00:19 2021 Return-Path: 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 B64063A134D for ; Sun, 25 Apr 2021 03:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XXZARsoUN789 for ; Sun, 25 Apr 2021 03:00:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CE06D3A1364 for ; Sun, 25 Apr 2021 03:00:08 -0700 (PDT) Received: (qmail 28592 invoked by uid 100); 25 Apr 2021 10:00:07 -0000 Date: 25 Apr 2021 09:59:43 -0000 Message-ID: <20210425095943.28570.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 25 06:00:07 2021 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2021 10:00:14 -0000 Count | Bytes | Who ------------+----------------+------- 3 (23.1%) | 35966 (29.0%) | Tim Wicinski 3 (23.1%) | 14055 (11.3%) | Robert Wilton via Datatracker 2 (15.4%) | 6160 ( 5.0%) | 1 ( 7.7%) | 25969 (20.9%) | Eric Vyncke (evyncke) 1 ( 7.7%) | 14508 (11.7%) | Brotman, Alex 1 ( 7.7%) | 13085 (10.5%) | Todd Herr 1 ( 7.7%) | 11484 ( 9.3%) | Seth Blank 1 ( 7.7%) | 2847 ( 2.3%) | John Levine From nobody Wed Apr 28 01:27:29 2021 Return-Path: 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 335A33A1FE9 for ; Wed, 28 Apr 2021 01:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=wander.science 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 UdkFXe0laNzL for ; Wed, 28 Apr 2021 01:27:22 -0700 (PDT) Received: from mail.swznet.de (cathay.swznet.de [IPv6:2a01:4f8:13b:2048::113]) (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 8488C3A1FE8 for ; Wed, 28 Apr 2021 01:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=cathay; h=Subject:Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jdyDI/EkTAyEmBEtcA0r/D9Bx1OQNeTl6TulSOqUQIo=; b=CMPrl3SVQ6XtHPFYT2n7onBHn8 OTVbe7//k0yEcTE8JqhTHuLciQvI7P+ImGbhJTAYBlJ723mMEsOvAqx95ustjebn2Dp8Xp6yfJoLh 809d/s8bpaU6pENsbXhPBPlee79gncFBZG4RF7YUPe7qlOZeTcqfr02I+xD8r0641e8D/efeqNJK4 pG2Z1Q7rk1qKlsEKQvJEITEVI3kv4gRKRmtDpj/dGI0TT0IhIHaxxuQesxQDeMSKPF021R10i+o7m q5WyMnjEhXQcyQ9wHBbymzISIkFjsXGxNY0k0RjMy1UvZEeuN5+L7dNueZpmjLTQHnHUGhHfQk0Fl TzK3yWDQ==; Received: from dynamic-2a01-0c22-b86d-ea00-149e-8735-e4ca-8fce.c22.pool.telefonica.de ([2a01:c22:b86d:ea00:149e:8735:e4ca:8fce]) by mail.swznet.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lbfXS-0005VP-If for dmarc@ietf.org; Wed, 28 Apr 2021 10:27:18 +0200 From: =?UTF-8?Q?Matth=c3=a4us_Wander?= To: dmarc@ietf.org Message-ID: Date: Wed, 28 Apr 2021 10:27:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:c22:b86d:ea00:149e:8735:e4ca:8fce X-SA-Exim-Mail-From: mail@wander.science X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on mail.swznet.de) Archived-At: Subject: [dmarc-ietf] Recipient domain in aggregate reports (#23) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 08:27:27 -0000 Hello everyone, I'm new to the party. I'd like to bring in some practical experience of working with DMARC rua reports. #23 introduces "receiving_domains" in the report metadata, justified by large infrastructures that host a large number of domains (e.g. Google). I think, this information would be more useful per-record rather than in the global metadata. As large infrastructures tend to include many different records in the report, the analyst needs a correlation between record and recipient domain. The section has an optional "envelope_to" already: > > minOccurs="0"/> Is there a benefit in the global "receiving_domains" over the per-record "envelope_to"? Most reporters don't include "envelope_to" (e.g. Google). This field could be made more prominent in the draft. The main body mentions "header_from" only, but neither "envelope_to" nor "envelope_from". Regards, Matt From nobody Wed Apr 28 05:34:39 2021 Return-Path: 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 B012D3A28C4 for ; Wed, 28 Apr 2021 05:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=valimail.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 M30hwSym0Jlb for ; Wed, 28 Apr 2021 05:34:34 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59223A28C0 for ; Wed, 28 Apr 2021 05:34:33 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id o1so4882350qta.1 for ; Wed, 28 Apr 2021 05:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PO4089PgFjx2YJKO9jqYHfwLldDPzqeaTLjuPnzkhoQ=; b=CL9FJt0xDq39Ib/b1bIYaVWGWzp3bEQCwefg9aD2ttmtmbM9CJpQblvfUKy/xjyFIA 0aTs57dFayeUtmt6t9jXnkXOE99KKmxf7HDHmlvreIha8vpvxieXtqVXZyhvc+i/doL+ tVsEPwU8sgHYgcsHoO0G6NY1PMexqiABxpIxa+BPZbpUYL8PdFVb8pFLNhM9+qd7CZsK C8T+9evP2MNswc8rDgNYAK8OUKLZQcAkCaZ10Okim0x81iYUwQEGpMabSDnSGKHRMWtN W/VUFXuQNWv7yoa+iM84eIgey9FRUun7TkWjlQEli7bi/dDEbbDPVU7DUig9iKPywoc0 L5Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PO4089PgFjx2YJKO9jqYHfwLldDPzqeaTLjuPnzkhoQ=; b=aAtydtHxavjkq7WCiVNrgVzfIpl34ILV0y3TV26ibBmY46jCs7bdKtM5UIv9BBcArK upXzSK7F3guTeapOJOf6unF5RzgTg9+wT/MAztVURAvP+QZR77HG+e7OmkOXavNipP/6 qJYlki7R1xtTQ3Sop2YatF6KW/huD/GtNeZtXfsinK6pyBgrgUjpHhe/rx8EGKUzaaNL 9xuP94zrLZ+Vj4RjJy4VrLRLfDyXonu6fj1/JsUa/OJFSj1k+CV5hBLRHwLbuxgo0usU qU32m1iZ8dShMkdCio396aDnZahvAaK1Y4CHQCHrROj5dqhKl2JOtkzNZJN0vW3c/lXR AFAQ== X-Gm-Message-State: AOAM530uVEqvBX+Bf3LcWRf+Tanbie6WDS6GGQuMgH1iOJb7IBvho7Y4 L5E1iZ9Sz4XWCE3/N6UPG7/3S6KMBFmJMBUCAeUPhvWeIGUEAQ== X-Google-Smtp-Source: ABdhPJyetQJwEGQm/bn6U/IiDLS9L3F/D2LkMmtJTI9dAf1ae1Wd+0gI2GlsKvBzKlSv7j5giIEG4XB7AWRhMzPyYAc= X-Received: by 2002:a05:622a:1353:: with SMTP id w19mr10532950qtk.220.1619613271778; Wed, 28 Apr 2021 05:34:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Wed, 28 Apr 2021 08:34:16 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bd03a505c107993d" Archived-At: Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 12:34:39 -0000 --000000000000bd03a505c107993d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies to Matt; I sent this originally only to him when I meant to send it to the list... On Wed, Apr 28, 2021 at 4:27 AM Matth=C3=A4us Wander wrote: > Hello everyone, > > I'm new to the party. I'd like to bring in some practical experience of > working with DMARC rua reports. > > #23 introduces "receiving_domains" in the report metadata, justified by > large infrastructures that host a large number of domains (e.g. Google). > > I think, this information would be more useful per-record rather than in > the global metadata. As large infrastructures tend to include many > different records in the report, the analyst needs a correlation between > record and recipient domain. > > The section has an optional "envelope_to" already: > > > > > minOccurs=3D"0"/> > > Is there a benefit in the global "receiving_domains" over the per-record > "envelope_to"? > > Most reporters don't include "envelope_to" (e.g. Google). This field > could be made more prominent in the draft. The main body mentions > "header_from" only, but neither "envelope_to" nor "envelope_from". > There is a hole in my understanding of this topic that I'm hoping someone can fill here, and that hole is this: I don't understand the value of reporting out receiving domains. The reason I don't understand it is because my expectation as a sender receiving a report about my sending domain would be that my DMARC validation results from a given receiving infrastructure would generally not vary across the different receiving domains, regardless of if there was one domain, ten domains, or ten thousand domains hosted by the reporting infrastructure. To extend my expectations further, unless I'm dedicating part of my infrastructure to sending solely to one and only one receiving site, I would expect my DMARC validation results to generally not vary across different reporting infrastructures. I'm declaring here that "DMARC validation results" are separate from "applied receiver handling policy" because as a sender I can only control the former; "DMARC validation results" means "whether or not SPF and/or DKIM passed and was aligned and consequently resulted in a DMARC pass or fail". If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly, receiving_domains, defined as the "List of domains which received messages for the domain in this report" I guess it could perhaps help me as a report consumer in the case where I receive a report from an previously unknown or unfamiliar to me reporter that hosts many domains, and if that's the use case, then perhaps the field ought to be amended to "List of the top $SMALL_NUMBER domains which received messages for the domain in this report" because as a report consumer I don't need to see 837 domains listed when realistically one or two will suffice. What is the value that I'm not seeing in reporting out receiving domains? --=20 *Todd Herr* | Sr. Technical Program Manager *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. --000000000000bd03a505c107993d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Apologies to Matt; I sent this originally only = to him when I meant to send it to the list...

    On Wed, Apr 28, 2021= at 4:27 AM Matth=C3=A4us Wander <mail=3D40wander.science@dmarc.ietf.org> wrote:
    Hello everyone,

    I'm new to the party. I'd like to bring in some practical experienc= e of
    working with DMARC rua reports.

    #23 introduces "receiving_domains" in the report metadata, justif= ied by
    large infrastructures that host a large number of domains (e.g. Google).
    I think, this information would be more useful per-record rather than in the global metadata. As large infrastructures tend to include many
    different records in the report, the analyst needs a correlation between record and recipient domain.

    The <identifiers> section has an optional "envelope_to" alr= eady:
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <!-- The envelope recipient domain. --&g= t;
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:element name=3D"envelope_to&quo= t; type=3D"xs:string"
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= inOccurs=3D"0"/>

    Is there a benefit in the global "receiving_domains" over the per= -record
    "envelope_to"?

    Most reporters don't include "envelope_to" (e.g. Google). Thi= s field
    could be made more prominent in the draft. The main body mentions
    "header_from" only, but neither "envelope_to" nor "= ;envelope_from".
    =C2=A0
    There is a hole in my= understanding of this topic that I'm hoping someone can fill here, and= that hole is this: I don't understand the value of reporting out recei= ving domains.

    The reason I don't understand it is because my expecta= tion as a sender receiving a report about my sending domain would be that m= y DMARC validation results from a given receiving infrastructure would gene= rally not vary across the different receiving domains, regardless of if the= re was one domain, ten domains, or ten thousand domains hosted by the repor= ting infrastructure. To extend my expectations further, unless I'm dedi= cating part of my infrastructure to sending solely to one and only one rece= iving site, I would expect my DMARC validation results to generally not var= y across different reporting infrastructures. I'm declaring here that &= quot;DMARC validation results" are separate from "applied receive= r handling policy" because as a sender I can only control the former; = "DMARC validation results" means "whether or not SPF and/or = DKIM passed and was aligned and consequently resulted in a DMARC pass or fa= il".

    If I'm reading=C2=A0draft= -ietf-dmarc-aggregate-reporting-02=C2=A0correctly, receiving_domains, defined as the &= quot;List of domains which received messages for the domain in this report&= quot; I guess it could perhaps help me as a report consumer in the case whe= re I receive a report from an previously unknown or unfamiliar to me report= er that hosts many domains, and if that's the use case, then perhaps th= e field ought to be amended to "List of the top $SMALL_NUMBER domains = which received messages for the domain in this report" because as a re= port consumer I don't need to see 837 domains listed when realistically= one or two will suffice.

    What is the value that I&#= 39;m not seeing in reporting out receiving domains?
    --

    Todd Herr | Sr. Technical Program Manager
    e: todd.herr@valimail.com
    <= /span>
    m: 703.220.4153

    This email and all data transmitted with it contains confidentia= l and/or proprietary information intended solely for the use of individual(= s) authorized to receive it. If you are not an intended and authorized reci= pient you are hereby notified of any use, disclosure, copying or distributi= on of the information included in this transmission is prohibited and may b= e unlawful. Please immediately notify the sender by replying to this email = and then delete it from your system.

    --000000000000bd03a505c107993d-- From nobody Wed Apr 28 05:57:15 2021 Return-Path: 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 75D833A0033; Wed, 28 Apr 2021 05:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=comcast.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 E8MasLLPVN_V; Wed, 28 Apr 2021 05:57:09 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 E05923A040C; Wed, 28 Apr 2021 05:57:08 -0700 (PDT) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13SCv4YO020690; Wed, 28 Apr 2021 08:57:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=GBhpCfEMvZijtXooT/8lotPckm0mTjZGMTIPAfQ4r3o=; b=VaaSap/Sjxn5K8uVkBFYduuICAzmigAao8+mwBi1inzMkQDIazUgO0ib7E5uUClcC+HQ +SgsMDBZwl8lbq4Y+/NCiKrCduxz+wmWmEibvgZYyBe1/Dl5QzGwyrQHQMv2aiSJ693H /pWls6gw3GO/zLMcAFEBjFZ6ZLjQaP10dCqwlXHnAzJ9WMSAY470LgR8M6PpkEtXSJsY HTCycrbWRxY/sgLxCyeYwjBdeSvM5XIzYFXOv42ExUgmile1XclyRdypZAxavNKOvG1q rRbSuFRmEW58SqaJVtvuPPvvKvlrlmwqiVoHza+0ZFuJEsbq3BUHlKOKz4c+hvd1ME7L QA== Received: from dlpemail-po-8p.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 386sc2cb2w-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Apr 2021 08:57:07 -0400 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4; Wed, 28 Apr 2021 06:57:02 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4 via Frontend Transport; Wed, 28 Apr 2021 06:57:01 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.176) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 28 Apr 2021 06:56:53 -0600 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL1PR11MB5335.namprd11.prod.outlook.com (2603:10b6:208:31b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Wed, 28 Apr 2021 12:56:52 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4065.026; Wed, 28 Apr 2021 12:56:52 +0000 From: "Brotman, Alex" To: Todd Herr , IETF DMARC WG Thread-Topic: [dmarc-ietf] Recipient domain in aggregate reports (#23) Thread-Index: AQHXPAheDLX4tYFQDk2HcDU/HwalU6rJ3YkAgAADluA= Date: Wed, 28 Apr 2021 12:56:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:103:e60:5dd:181b:49bb:8f5a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55761403-90e1-482f-0bb4-08d90a451861 x-ms-traffictypediagnostic: BL1PR11MB5335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1Bsmke1MxrMps3A6+HPwO109VeOZHlzzimNhRuYNEHYy5u6+tYBbJymvS0I6oLbjNfG4mBe5dt87W76dNyxGqIovnj75EKhRtvNxcd3BkYHyB+GPM0fW9FLKA3OI+SIbYHv1r8yRrrj2T7ZuwpFkyPDXG5fniGVgAg5iDcqWI1KWrBKrTdXSj5B5pXRsBkwn/jVXaUaPT8kNtM0SIzRUVXRcG9jB4UXcbH2iUStnIR/IMYAcP3GpPnvGQqrUGtulmQCn5tbYk+BNtKJELkU/kpAm57B3Xt9EJgNW9viDCL66uYeAuFCK5Qi/hXVZxfni6uOmkFdMtGfXF7jfkvW/XAXhaQNwKs0oZ+S9QhWiTfWbT+ioeVzCdNZuxJ4xKJwk5ymIjQfID1w+wdHRP+RLUu5PT39cfEcuBf05p2/NZFNWkTK3JZM1PrtBgKP3jKbfLvOJJc2SCzbmqb4HZHfl5QXrrQKRKxLxE7Ck98vRr2e0Zqh1cP21I4oLqzIL4nDMFYPZgL/8Zyb6gO3l30Y2t9WColVB6e5rPquDop5UBXCw9rFAxsBZV+eNlgglRdeM/tZb5S5zxV1GqNmByFlZTohHxYqxk3P85A8DvdtH2Bk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(84050400001)(38100700002)(122000001)(7696005)(6506007)(76116006)(66946007)(66556008)(71200400001)(8676002)(53546011)(66476007)(86362001)(66574015)(2906002)(66446008)(186003)(478600001)(316002)(9686003)(55016002)(110136005)(83380400001)(5660300002)(52536014)(33656002)(8936002)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?QkJkSVlUNXBPOURlNENEYnBabzFhRmRtOXlLUWFEVy9NbzhkYnNOd2FwRzgw?= =?utf-8?B?WUxIMytSTUJsaDRBYVZNSlZMaXlRc0JZbit0Z0t1dCtlZG5EbEFlTFo2aThq?= =?utf-8?B?ZjcrS2dpMGJ1VWRBNWlaWWdRZmRrT0J3SDVWK0M3NlRNRVVjV1FXaG13dXFM?= =?utf-8?B?ZjJpN0VSbkszaVUyZmY3Y0pobTZ1d2xEVE8vVTlVbjNNZlFuQUk1K0xlSHlS?= =?utf-8?B?RFVva3RjUlEvVjV4QVp2ZGdSckM0WXBLTUczSTQyQmlkTTkvOWkzYVVBbzlw?= =?utf-8?B?V2s5WCtUbnNseW91N0h2WE5kUDRKYytqREJ1dFUyZW5hNDU3b05BNkkzSzdk?= =?utf-8?B?Ky9tNy9Pa2JSS3lLWHVCVWY4MVlOcmFTaHoyY1pGQ1pHcUhjR2JlbUxDSi9X?= =?utf-8?B?MnVQa2puamZQQ25CZ2tERVF2K240Y0gvbm9DcDdiOTZpS2dWWWpxTk5kQzlR?= =?utf-8?B?YWNwUGNLTU55d2VNQ2JiRjZ6SlU3dUY0dUY5VExDSG5ESDRXRWpsam96aVgr?= =?utf-8?B?QmJ4M2dNYUhxa0sweWRZTFBJN1RWeVZEN3BxUEx4VWtaZkU1dzNjczJwT0FZ?= =?utf-8?B?aWk2WmFQQ0F1SXQ2Nkt3SjEyemtOQm9QUkRyRWxiRGFRZC9rRE9NdEE0YVNM?= =?utf-8?B?dTRkV0lFNnRrWEFUcEhPamR3S2lZeXIrQkhXVCtGcnZpNWZ6K2tlSmY1N21D?= =?utf-8?B?QVZTbUtGZzllT1B5d2V5UzlVRzE5Z3NUQmU0TWFhbUZVS2dFUXljTXNWVXBF?= =?utf-8?B?dHNIK1pjclMyMnR6YTNyOW5ldDE1OGtCditHOHBGaU5taFJibTRuRW9rbzE1?= =?utf-8?B?bE1HVzZyTVVUM2padE5lMEpsTnEzblorRk9qMkV2Y2FhY2w3T0IzcVFUelNG?= =?utf-8?B?YWhlckpWYUplaE5UUERyVm5NTHhNQVdWT1lleU9HMHFObnJoakZDNTF2NDFW?= =?utf-8?B?ejVjWlRqNHVYTmRZM3V1VVNKeTB5VmFxVzhmNTdnZU15S2tWaThEdnYwMEVV?= =?utf-8?B?R1RKYjkzYVdEZVBlZUQ2V1JaRGhWOHlpcy9TRjJ0bk1lT01WZ0JudkYzNXhW?= =?utf-8?B?RFltWWRVdlpxV0p5M2hUMXBZOGZkaFFZZmcvd0d3YWVmdkVvQWw0bEhYK2pY?= =?utf-8?B?a1hTTFE5dGlZWVJjWlg1Nnh3RFkvdzNlRHNzMjYvLzdlTWJOaGJtT0l4VS9Q?= =?utf-8?B?S3Erb0hxSUlRQzE3bm9lMnhJaDF6TkEvcGJvcXlQdVY1SGVqRE85YzBLWEps?= =?utf-8?B?Y2xRVnFhVnNZajhBRUFoWWhJSnE0RUxSWXFTc1NwUzg4R3ZaZENUak5WQUIr?= =?utf-8?B?aTc0THRseGJ1YllocGNQek9XbXp1RWtiUkR2OHZ4YSt6aGxrR00yTEVDS2Fl?= =?utf-8?B?bTluWUlBRmxPdDZlOGl4T05tMG9HMUx3dTFHMXJ6cHhOUU11bXlIdnh6bUpK?= =?utf-8?B?bW5DL29YbXRnWDNBRTYydzNrNkNPTytCMDYyeDVESERvTm9sOGN2VlFDRFBV?= =?utf-8?B?YzlLSW9IV2xwZjdZeElDbDFVSHcrWXVrQ0ZmQ0hUR1hBQjh6VXgxTzIxVEdQ?= =?utf-8?B?WHVJT1hJSGYxK09DMERBSVRkTENyRzlGd3FlNzNFVGdkY3hRaTh4M2FVM1J6?= =?utf-8?B?d0MrNFl2bDhKcTZqQnZEV1RNTGFtdi9Ta2VPeUFFUC84OHRrNXllWUM3S01j?= =?utf-8?B?Z2J4ODJvY1owM0pSMjRHSnlFRVZRY3gzektrZmthQ1JVbUZuejhJU2dsbkJ1?= =?utf-8?B?SjUvajh0b3REbGtsVkgxMTBOZjFjTXZIVDV4ZjFOSDRwUjZqdFdDSFRjSkdw?= =?utf-8?Q?J8vZ/71UW0LG3TqFHkIIwss1tEYHNy4wtMyBk=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C3aCxhUVP4iCsJ5LrSrrhhHa2mRsAj4hGo/Pqm9ePRMSz6Hy0v/hYkjJEeKct/IY6R/Lb/py7q7bWtwDsFSPrLnyRaOs4Bn8DcS5w0ZWrasK86wGy9d5aYg5lsxiobHSMVYopwLyfz0xpyoIA+hKFa2RzI8EVnG7brfCylBJA5Gh/vRYsGJ37hirI2vfx9mv7BFWG2/pV9wsGV/hDIqkmgui7fE2AKn3ziheIKIvio7G0x8XgtTKZhE99cv8hVgRGgm8YFqbpqPIkHEkVZh4sfiUGUktcym7cEWVBay7kvRH/lX1pgeliyUamAzyViMIMdmomzjZIWa+SVsYAZW/Yg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EORxK+T3u0F2xEEsKO+BxCb7SIVgVn/iDlInrMm93yo=; b=jbx2LMV4HbAnAHnPpWVEccOSyCb9kidtAVNHF41wN6ZD41V/neNtArPaxPKhM6Ae/TVL5CNTffPzesCxdA1kwuO3wrNlBtBFeDThv2drJBFhGH2ySrlTS5XOu24YNMXeA/ZnSaDHIt8ZR3j2njaFF8VqhFs0cUgZOvIfuvH8Lh85HCHxYGItzJOESZ9IcxuI2vdQcDWQfpjEVVJTZLTYRiiaKbEIXYnCuKkrlnp9am/ixkP1zyWmwHuOfHzRic0yArCoNlMv9n95TVAmChSF0zNtsQiJlaj7/ETSkY9HG9n/AW1syIt3STfI7c7diGqXHt4A5xZX3uphS3UCT7wa/Q== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 55761403-90e1-482f-0bb4-08d90a451861 x-ms-exchange-crosstenant-originalarrivaltime: 28 Apr 2021 12:56:52.6540 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: CQh3OCbeRyvdy15dLVbqB4gYgW6JniRBlfzRDiRr5SRjUadj4raEKkKM/94I2dCM6JKybK93N5PY5E+KaQRlPOubCwYX59ZY2znWV3WSMak= x-ms-exchange-transport-crosstenantheadersstamped: BL1PR11MB5335 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB435125AC4DC3D8B21BF290F3F7409MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWM X-Proofpoint-ORIG-GUID: nDPqnpgB_xXHycp0K5A9i_TzPoVEIddK X-Proofpoint-GUID: nDPqnpgB_xXHycp0K5A9i_TzPoVEIddK X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-28_06:2021-04-27, 2021-04-28 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 12:57:14 -0000 --_000_MN2PR11MB435125AC4DC3D8B21BF290F3F7409MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF0dCwNCg0KV2hpbGUsIHllcywgdGhlcmUgaXMgdGhlIGV4aXN0aW5nIGVudmVsb3BlX3RvLCB0 aGVyZSB3YXMgYSByZXF1ZXN0IHRvIGFkZCB0aGlzIHRvIHRoZSByZXBvcnQgZm9ybWF0ICh3aGlj aCBJIGJlbGlldmUgSSBkaWQgYXMgdGhlIHN1Ym1pdHRlciBkZXNpcmVkKS4gIEkgd291bGQgYXNz dW1lIHdl4oCZZCBoYXNoIGl0IG91dCBvbiB0aGUgbGlzdCBhbmQgcmVtb3ZlIG9uZSBvZiB0aGVt Lg0KDQpIb3dldmVyLCBmcm9tIGFuIG9wZXJhdG9yIHNpZGUgb2YgdGhpbmdzLCBJIHRlbmQgdG8g YWxpZ24gd2l0aCBUb2RkIG9uIHRoaXMuICBDb3VsZCBzb21lb25lIHByb3ZpZGUgYSByZWFsLXdv cmxkIGV4YW1wbGUgb2Ygd2hlcmUgcmVwb3J0aW5nIHRoZSBkZXN0aW5hdGlvbiBkb21haW4gYXNz aXN0ZWQgdGhlbSBpbiByZXNvbHZpbmcgYW4gaXNzdWU/DQoNCi0tDQpBbGV4IEJyb3RtYW4NClNy LiBFbmdpbmVlciwgQW50aS1BYnVzZSAmIE1lc3NhZ2luZyBQb2xpY3kNCkNvbWNhc3QNCg0KRnJv bTogZG1hcmMgPGRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb2RkIEhlcnIN ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjgsIDIwMjEgODozNCBBTQ0KVG86IElFVEYgRE1BUkMg V0cgPGRtYXJjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBSZWNpcGllbnQg ZG9tYWluIGluIGFnZ3JlZ2F0ZSByZXBvcnRzICgjMjMpDQoNCkFwb2xvZ2llcyB0byBNYXR0OyBJ IHNlbnQgdGhpcyBvcmlnaW5hbGx5IG9ubHkgdG8gaGltIHdoZW4gSSBtZWFudCB0byBzZW5kIGl0 IHRvIHRoZSBsaXN0Li4uDQoNCk9uIFdlZCwgQXByIDI4LCAyMDIxIGF0IDQ6MjcgQU0gTWF0dGjD pHVzIFdhbmRlciA8bWFpbD00MHdhbmRlci5zY2llbmNlQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MHdhbmRlci5zY2llbmNlQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIZWxsbyBldmVyeW9uZSwN Cg0KSSdtIG5ldyB0byB0aGUgcGFydHkuIEknZCBsaWtlIHRvIGJyaW5nIGluIHNvbWUgcHJhY3Rp Y2FsIGV4cGVyaWVuY2Ugb2YNCndvcmtpbmcgd2l0aCBETUFSQyBydWEgcmVwb3J0cy4NCg0KIzIz IGludHJvZHVjZXMgInJlY2VpdmluZ19kb21haW5zIiBpbiB0aGUgcmVwb3J0IG1ldGFkYXRhLCBq dXN0aWZpZWQgYnkNCmxhcmdlIGluZnJhc3RydWN0dXJlcyB0aGF0IGhvc3QgYSBsYXJnZSBudW1i ZXIgb2YgZG9tYWlucyAoZS5nLiBHb29nbGUpLg0KDQpJIHRoaW5rLCB0aGlzIGluZm9ybWF0aW9u IHdvdWxkIGJlIG1vcmUgdXNlZnVsIHBlci1yZWNvcmQgcmF0aGVyIHRoYW4gaW4NCnRoZSBnbG9i YWwgbWV0YWRhdGEuIEFzIGxhcmdlIGluZnJhc3RydWN0dXJlcyB0ZW5kIHRvIGluY2x1ZGUgbWFu eQ0KZGlmZmVyZW50IHJlY29yZHMgaW4gdGhlIHJlcG9ydCwgdGhlIGFuYWx5c3QgbmVlZHMgYSBj b3JyZWxhdGlvbiBiZXR3ZWVuDQpyZWNvcmQgYW5kIHJlY2lwaWVudCBkb21haW4uDQoNClRoZSA8 aWRlbnRpZmllcnM+IHNlY3Rpb24gaGFzIGFuIG9wdGlvbmFsICJlbnZlbG9wZV90byIgYWxyZWFk eToNCj4gICAgICAgIDwhLS0gVGhlIGVudmVsb3BlIHJlY2lwaWVudCBkb21haW4uIC0tPg0KPiAg ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZW52ZWxvcGVfdG8iIHR5cGU9InhzOnN0cmluZyINCj4g ICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0KDQpJcyB0aGVyZSBhIGJlbmVmaXQg aW4gdGhlIGdsb2JhbCAicmVjZWl2aW5nX2RvbWFpbnMiIG92ZXIgdGhlIHBlci1yZWNvcmQNCiJl bnZlbG9wZV90byI/DQoNCk1vc3QgcmVwb3J0ZXJzIGRvbid0IGluY2x1ZGUgImVudmVsb3BlX3Rv IiAoZS5nLiBHb29nbGUpLiBUaGlzIGZpZWxkDQpjb3VsZCBiZSBtYWRlIG1vcmUgcHJvbWluZW50 IGluIHRoZSBkcmFmdC4gVGhlIG1haW4gYm9keSBtZW50aW9ucw0KImhlYWRlcl9mcm9tIiBvbmx5 LCBidXQgbmVpdGhlciAiZW52ZWxvcGVfdG8iIG5vciAiZW52ZWxvcGVfZnJvbSIuDQoNClRoZXJl IGlzIGEgaG9sZSBpbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgdG9waWMgdGhhdCBJJ20gaG9w aW5nIHNvbWVvbmUgY2FuIGZpbGwgaGVyZSwgYW5kIHRoYXQgaG9sZSBpcyB0aGlzOiBJIGRvbid0 IHVuZGVyc3RhbmQgdGhlIHZhbHVlIG9mIHJlcG9ydGluZyBvdXQgcmVjZWl2aW5nIGRvbWFpbnMu DQoNClRoZSByZWFzb24gSSBkb24ndCB1bmRlcnN0YW5kIGl0IGlzIGJlY2F1c2UgbXkgZXhwZWN0 YXRpb24gYXMgYSBzZW5kZXIgcmVjZWl2aW5nIGEgcmVwb3J0IGFib3V0IG15IHNlbmRpbmcgZG9t YWluIHdvdWxkIGJlIHRoYXQgbXkgRE1BUkMgdmFsaWRhdGlvbiByZXN1bHRzIGZyb20gYSBnaXZl biByZWNlaXZpbmcgaW5mcmFzdHJ1Y3R1cmUgd291bGQgZ2VuZXJhbGx5IG5vdCB2YXJ5IGFjcm9z cyB0aGUgZGlmZmVyZW50IHJlY2VpdmluZyBkb21haW5zLCByZWdhcmRsZXNzIG9mIGlmIHRoZXJl IHdhcyBvbmUgZG9tYWluLCB0ZW4gZG9tYWlucywgb3IgdGVuIHRob3VzYW5kIGRvbWFpbnMgaG9z dGVkIGJ5IHRoZSByZXBvcnRpbmcgaW5mcmFzdHJ1Y3R1cmUuIFRvIGV4dGVuZCBteSBleHBlY3Rh dGlvbnMgZnVydGhlciwgdW5sZXNzIEknbSBkZWRpY2F0aW5nIHBhcnQgb2YgbXkgaW5mcmFzdHJ1 Y3R1cmUgdG8gc2VuZGluZyBzb2xlbHkgdG8gb25lIGFuZCBvbmx5IG9uZSByZWNlaXZpbmcgc2l0 ZSwgSSB3b3VsZCBleHBlY3QgbXkgRE1BUkMgdmFsaWRhdGlvbiByZXN1bHRzIHRvIGdlbmVyYWxs eSBub3QgdmFyeSBhY3Jvc3MgZGlmZmVyZW50IHJlcG9ydGluZyBpbmZyYXN0cnVjdHVyZXMuIEkn bSBkZWNsYXJpbmcgaGVyZSB0aGF0ICJETUFSQyB2YWxpZGF0aW9uIHJlc3VsdHMiIGFyZSBzZXBh cmF0ZSBmcm9tICJhcHBsaWVkIHJlY2VpdmVyIGhhbmRsaW5nIHBvbGljeSIgYmVjYXVzZSBhcyBh IHNlbmRlciBJIGNhbiBvbmx5IGNvbnRyb2wgdGhlIGZvcm1lcjsgIkRNQVJDIHZhbGlkYXRpb24g cmVzdWx0cyIgbWVhbnMgIndoZXRoZXIgb3Igbm90IFNQRiBhbmQvb3IgREtJTSBwYXNzZWQgYW5k IHdhcyBhbGlnbmVkIGFuZCBjb25zZXF1ZW50bHkgcmVzdWx0ZWQgaW4gYSBETUFSQyBwYXNzIG9y IGZhaWwiLg0KDQpJZiBJJ20gcmVhZGluZyBkcmFmdC1pZXRmLWRtYXJjLWFnZ3JlZ2F0ZS1yZXBv cnRpbmctMDIgY29ycmVjdGx5LCByZWNlaXZpbmdfZG9tYWlucywgZGVmaW5lZCBhcyB0aGUgIkxp c3Qgb2YgZG9tYWlucyB3aGljaCByZWNlaXZlZCBtZXNzYWdlcyBmb3IgdGhlIGRvbWFpbiBpbiB0 aGlzIHJlcG9ydCIgSSBndWVzcyBpdCBjb3VsZCBwZXJoYXBzIGhlbHAgbWUgYXMgYSByZXBvcnQg Y29uc3VtZXIgaW4gdGhlIGNhc2Ugd2hlcmUgSSByZWNlaXZlIGEgcmVwb3J0IGZyb20gYW4gcHJl dmlvdXNseSB1bmtub3duIG9yIHVuZmFtaWxpYXIgdG8gbWUgcmVwb3J0ZXIgdGhhdCBob3N0cyBt YW55IGRvbWFpbnMsIGFuZCBpZiB0aGF0J3MgdGhlIHVzZSBjYXNlLCB0aGVuIHBlcmhhcHMgdGhl IGZpZWxkIG91Z2h0IHRvIGJlIGFtZW5kZWQgdG8gIkxpc3Qgb2YgdGhlIHRvcCAkU01BTExfTlVN QkVSIGRvbWFpbnMgd2hpY2ggcmVjZWl2ZWQgbWVzc2FnZXMgZm9yIHRoZSBkb21haW4gaW4gdGhp cyByZXBvcnQiIGJlY2F1c2UgYXMgYSByZXBvcnQgY29uc3VtZXIgSSBkb24ndCBuZWVkIHRvIHNl ZSA4MzcgZG9tYWlucyBsaXN0ZWQgd2hlbiByZWFsaXN0aWNhbGx5IG9uZSBvciB0d28gd2lsbCBz dWZmaWNlLg0KDQpXaGF0IGlzIHRoZSB2YWx1ZSB0aGF0IEknbSBub3Qgc2VlaW5nIGluIHJlcG9y dGluZyBvdXQgcmVjZWl2aW5nIGRvbWFpbnM/DQotLQ0KVG9kZCBIZXJyIHwgU3IuIFRlY2huaWNh bCBQcm9ncmFtIE1hbmFnZXINCmU6IHRvZGQuaGVyckB2YWxpbWFpbC5jb208bWFpbHRvOnRvZGQu aGVyckB2YWxpbWFpbC5jb20+DQptOiA3MDMuMjIwLjQxNTMNCg0KDQpUaGlzIGVtYWlsIGFuZCBh bGwgZGF0YSB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3Ig cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGlu ZGl2aWR1YWwocykgYXV0aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCBhbmQgYXV0aG9yaXplZCByZWNpcGllbnQgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg b2YgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhlIGlu Zm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gUGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5 IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwgYW5kIHRoZW4gZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0uDQo= --_000_MN2PR11MB435125AC4DC3D8B21BF290F3F7409MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsZGVmYXVsdA0KCXttc28tc3R5bGUt bmFtZTpnbWFpbF9kZWZhdWx0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hdHQsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldoaWxlLCB5ZXMsIHRoZXJlIGlzIHRoZSBleGlzdGluZyBlbnZlbG9wZV90bywg dGhlcmUgd2FzIGEgcmVxdWVzdCB0byBhZGQgdGhpcyB0byB0aGUgcmVwb3J0IGZvcm1hdCAod2hp Y2ggSSBiZWxpZXZlIEkgZGlkIGFzIHRoZSBzdWJtaXR0ZXIgZGVzaXJlZCkuJm5ic3A7IEkgd291 bGQgYXNzdW1lIHdl4oCZZCBoYXNoIGl0IG91dCBvbiB0aGUgbGlzdCBhbmQgcmVtb3ZlIG9uZSBv ZiB0aGVtLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGZyb20gYW4g b3BlcmF0b3Igc2lkZSBvZiB0aGluZ3MsIEkgdGVuZCB0byBhbGlnbiB3aXRoIFRvZGQgb24gdGhp cy4mbmJzcDsgQ291bGQgc29tZW9uZSBwcm92aWRlIGEgcmVhbC13b3JsZCBleGFtcGxlIG9mIHdo ZXJlIHJlcG9ydGluZyB0aGUgZGVzdGluYXRpb24gZG9tYWluIGFzc2lzdGVkIHRoZW0gaW4gcmVz b2x2aW5nIGFuIGlzc3VlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxleCBCcm90bWFuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Tci4gRW5naW5lZXIsIEFudGktQWJ1c2UgJmFtcDsgTWVzc2FnaW5n IFBvbGljeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tY2FzdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBkbWFyYyAmbHQ7ZG1hcmMtYm91bmNl c0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClRvZGQgSGVycjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI4LCAyMDIxIDg6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+ IElFVEYgRE1BUkMgV0cgJmx0O2RtYXJjQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2RtYXJjLWlldGZdIFJlY2lwaWVudCBkb21haW4gaW4gYWdncmVnYXRlIHJlcG9ydHMg KCMyMyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+QXBvbG9naWVzIHRvIE1hdHQ7IEkgc2VudCB0aGlzIG9yaWdpbmFsbHkgb25seSB0 byBoaW0gd2hlbiBJIG1lYW50IHRvIHNlbmQgaXQgdG8gdGhlIGxpc3QuLi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg QXByIDI4LCAyMDIxIGF0IDQ6MjcgQU0gTWF0dGjDpHVzIFdhbmRlciAmbHQ7bWFpbD08YSBocmVm PSJtYWlsdG86NDB3YW5kZXIuc2NpZW5jZUBkbWFyYy5pZXRmLm9yZyI+NDB3YW5kZXIuc2NpZW5j ZUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gZXZlcnlvbmUsPGJyPg0KPGJy Pg0KSSdtIG5ldyB0byB0aGUgcGFydHkuIEknZCBsaWtlIHRvIGJyaW5nIGluIHNvbWUgcHJhY3Rp Y2FsIGV4cGVyaWVuY2Ugb2Y8YnI+DQp3b3JraW5nIHdpdGggRE1BUkMgcnVhIHJlcG9ydHMuPGJy Pg0KPGJyPg0KIzIzIGludHJvZHVjZXMgJnF1b3Q7cmVjZWl2aW5nX2RvbWFpbnMmcXVvdDsgaW4g dGhlIHJlcG9ydCBtZXRhZGF0YSwganVzdGlmaWVkIGJ5PGJyPg0KbGFyZ2UgaW5mcmFzdHJ1Y3R1 cmVzIHRoYXQgaG9zdCBhIGxhcmdlIG51bWJlciBvZiBkb21haW5zIChlLmcuIEdvb2dsZSkuPGJy Pg0KPGJyPg0KSSB0aGluaywgdGhpcyBpbmZvcm1hdGlvbiB3b3VsZCBiZSBtb3JlIHVzZWZ1bCBw ZXItcmVjb3JkIHJhdGhlciB0aGFuIGluPGJyPg0KdGhlIGdsb2JhbCBtZXRhZGF0YS4gQXMgbGFy Z2UgaW5mcmFzdHJ1Y3R1cmVzIHRlbmQgdG8gaW5jbHVkZSBtYW55PGJyPg0KZGlmZmVyZW50IHJl Y29yZHMgaW4gdGhlIHJlcG9ydCwgdGhlIGFuYWx5c3QgbmVlZHMgYSBjb3JyZWxhdGlvbiBiZXR3 ZWVuPGJyPg0KcmVjb3JkIGFuZCByZWNpcGllbnQgZG9tYWluLjxicj4NCjxicj4NClRoZSAmbHQ7 aWRlbnRpZmllcnMmZ3Q7IHNlY3Rpb24gaGFzIGFuIG9wdGlvbmFsICZxdW90O2VudmVsb3BlX3Rv JnF1b3Q7IGFscmVhZHk6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 IS0tIFRoZSBlbnZlbG9wZSByZWNpcGllbnQgZG9tYWluLiAtLSZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt4czplbGVtZW50IG5hbWU9JnF1b3Q7ZW52ZWxvcGVf dG8mcXVvdDsgdHlwZT0mcXVvdDt4czpzdHJpbmcmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IG1pbk9jY3Vycz0mcXVvdDswJnF1b3Q7LyZndDs8YnI+DQo8YnI+DQpJcyB0aGVyZSBhIGJlbmVm aXQgaW4gdGhlIGdsb2JhbCAmcXVvdDtyZWNlaXZpbmdfZG9tYWlucyZxdW90OyBvdmVyIHRoZSBw ZXItcmVjb3JkPGJyPg0KJnF1b3Q7ZW52ZWxvcGVfdG8mcXVvdDs/PGJyPg0KPGJyPg0KTW9zdCBy ZXBvcnRlcnMgZG9uJ3QgaW5jbHVkZSAmcXVvdDtlbnZlbG9wZV90byZxdW90OyAoZS5nLiBHb29n bGUpLiBUaGlzIGZpZWxkPGJyPg0KY291bGQgYmUgbWFkZSBtb3JlIHByb21pbmVudCBpbiB0aGUg ZHJhZnQuIFRoZSBtYWluIGJvZHkgbWVudGlvbnM8YnI+DQomcXVvdDtoZWFkZXJfZnJvbSZxdW90 OyBvbmx5LCBidXQgbmVpdGhlciAmcXVvdDtlbnZlbG9wZV90byZxdW90OyBub3IgJnF1b3Q7ZW52 ZWxvcGVfZnJvbSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlIGlzIGEgaG9sZSBpbiBteSB1bmRlcnN0 YW5kaW5nIG9mIHRoaXMgdG9waWMgdGhhdCBJJ20gaG9waW5nIHNvbWVvbmUgY2FuIGZpbGwgaGVy ZSwgYW5kIHRoYXQgaG9sZSBpcyB0aGlzOiBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHZhbHVlIG9m IHJlcG9ydGluZyBvdXQgcmVjZWl2aW5nIGRvbWFpbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByZWFzb24gSSBk b24ndCB1bmRlcnN0YW5kIGl0IGlzIGJlY2F1c2UgbXkgZXhwZWN0YXRpb24gYXMgYSBzZW5kZXIg cmVjZWl2aW5nIGEgcmVwb3J0IGFib3V0IG15IHNlbmRpbmcgZG9tYWluIHdvdWxkIGJlIHRoYXQg bXkgRE1BUkMgdmFsaWRhdGlvbiByZXN1bHRzIGZyb20gYSBnaXZlbiByZWNlaXZpbmcgaW5mcmFz dHJ1Y3R1cmUNCiB3b3VsZCBnZW5lcmFsbHkgbm90IHZhcnkgYWNyb3NzIHRoZSBkaWZmZXJlbnQg cmVjZWl2aW5nIGRvbWFpbnMsIHJlZ2FyZGxlc3Mgb2YgaWYgdGhlcmUgd2FzIG9uZSBkb21haW4s IHRlbiBkb21haW5zLCBvciB0ZW4gdGhvdXNhbmQgZG9tYWlucyBob3N0ZWQgYnkgdGhlIHJlcG9y dGluZyBpbmZyYXN0cnVjdHVyZS4gVG8gZXh0ZW5kIG15IGV4cGVjdGF0aW9ucyBmdXJ0aGVyLCB1 bmxlc3MgSSdtIGRlZGljYXRpbmcgcGFydCBvZiBteSBpbmZyYXN0cnVjdHVyZQ0KIHRvIHNlbmRp bmcgc29sZWx5IHRvIG9uZSBhbmQgb25seSBvbmUgcmVjZWl2aW5nIHNpdGUsIEkgd291bGQgZXhw ZWN0IG15IERNQVJDIHZhbGlkYXRpb24gcmVzdWx0cyB0byBnZW5lcmFsbHkgbm90IHZhcnkgYWNy b3NzIGRpZmZlcmVudCByZXBvcnRpbmcgaW5mcmFzdHJ1Y3R1cmVzLiBJJ20gZGVjbGFyaW5nIGhl cmUgdGhhdCAmcXVvdDtETUFSQyB2YWxpZGF0aW9uIHJlc3VsdHMmcXVvdDsgYXJlIHNlcGFyYXRl IGZyb20gJnF1b3Q7YXBwbGllZCByZWNlaXZlciBoYW5kbGluZw0KIHBvbGljeSZxdW90OyBiZWNh dXNlIGFzIGEgc2VuZGVyIEkgY2FuIG9ubHkgY29udHJvbCB0aGUgZm9ybWVyOyAmcXVvdDtETUFS QyB2YWxpZGF0aW9uIHJlc3VsdHMmcXVvdDsgbWVhbnMgJnF1b3Q7d2hldGhlciBvciBub3QgU1BG IGFuZC9vciBES0lNIHBhc3NlZCBhbmQgd2FzIGFsaWduZWQgYW5kIGNvbnNlcXVlbnRseSByZXN1 bHRlZCBpbiBhIERNQVJDIHBhc3Mgb3IgZmFpbCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+SWYgSSdtIHJlYWRp bmcmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmRyYWZ0LWlldGYtZG1hcmMtYWdncmVn YXRlLXJlcG9ydGluZy0wMjxzcGFuIGNsYXNzPSJnbWFpbGRlZmF1bHQiPiZuYnNwO2NvcnJlY3Rs eSwgcmVjZWl2aW5nX2RvbWFpbnMsIGRlZmluZWQgYXMgdGhlICZxdW90O0xpc3Qgb2YgZG9tYWlu cyB3aGljaCByZWNlaXZlZCBtZXNzYWdlcw0KIGZvciB0aGUgZG9tYWluIGluIHRoaXMgcmVwb3J0 JnF1b3Q7IEkgZ3Vlc3MgaXQgY291bGQgcGVyaGFwcyBoZWxwIG1lIGFzIGEgcmVwb3J0IGNvbnN1 bWVyIGluIHRoZSBjYXNlIHdoZXJlIEkgcmVjZWl2ZSBhIHJlcG9ydCBmcm9tIGFuIHByZXZpb3Vz bHkgdW5rbm93biBvciB1bmZhbWlsaWFyIHRvIG1lIHJlcG9ydGVyIHRoYXQgaG9zdHMgbWFueSBk b21haW5zLCBhbmQgaWYgdGhhdCdzIHRoZSB1c2UgY2FzZSwgdGhlbiBwZXJoYXBzIHRoZSBmaWVs ZCBvdWdodA0KIHRvIGJlIGFtZW5kZWQgdG8gJnF1b3Q7TGlzdCBvZiB0aGUgdG9wICRTTUFMTF9O VU1CRVIgZG9tYWlucyB3aGljaCByZWNlaXZlZCBtZXNzYWdlcyBmb3IgdGhlIGRvbWFpbiBpbiB0 aGlzIHJlcG9ydCZxdW90OyBiZWNhdXNlIGFzIGEgcmVwb3J0IGNvbnN1bWVyIEkgZG9uJ3QgbmVl ZCB0byBzZWUgODM3IGRvbWFpbnMgbGlzdGVkIHdoZW4gcmVhbGlzdGljYWxseSBvbmUgb3IgdHdv IHdpbGwgc3VmZmljZS48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XaGF0IGlz IHRoZSB2YWx1ZSB0aGF0IEknbSBub3Qgc2VlaW5nIGluIHJlcG9ydGluZyBvdXQgcmVjZWl2aW5n IGRvbWFpbnM/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VG9kZCBIZXJyPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj4gfCBTci4gVGVjaG5pY2FsIFByb2dyYW0gTWFuYWdlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmU6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzp0b2RkLmhlcnJAdmFsaW1h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9kZC5oZXJyQHZhbGltYWlsLmNvbTwvYT4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5tOjwvYj4g NzAzLjIyMC40MTUzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47YmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPlRoaXMgZW1haWwgYW5kIGFsbCBkYXRh IHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgaW5kaXZpZHVh bChzKSBhdXRob3JpemVkDQogdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgYW5kIGF1dGhvcml6ZWQgcmVjaXBpZW50IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIG9mIGFu eSB1c2UsIGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBpbmZvcm1h dGlvbiBpbmNsdWRlZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcm9oaWJpdGVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuIFBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlcg0KIGJ5IHJl cGx5aW5nIHRvIHRoaXMgZW1haWwgYW5kIHRoZW4gZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB435125AC4DC3D8B21BF290F3F7409MN2PR11MB4351namp_-- From nobody Wed Apr 28 18:22:02 2021 Return-Path: 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 D34A53A285E for ; Wed, 28 Apr 2021 18:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=gmail.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 LZOQl7aTczo7 for ; Wed, 28 Apr 2021 18:21:57 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B063A285C for ; Wed, 28 Apr 2021 18:21:57 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id e25so34992326oii.2 for ; Wed, 28 Apr 2021 18:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tgcau1h4F6cd/V1KzNKqvvbO+5Q+hRnYWLopqM++JGM=; b=fLFC4i7Ab4rwg9ldiM+Ou+Tz6aT4z9PK39hZaoEqKgG8U7C8QMsd9n08b3PqumdjfZ 7dXrrW4JeZIYBpaoqI/cvCLI9tCMVjud/lfahSPYDAtsbZQWrUSrE/qMVUf6gUgLGVLb 744bcQEG2MC9L2ErNSvU52HUyExE7ab+FTxfc7eesB9ocHA3TU7C1NvQ+GG+Z7GcqReB zFIGC3Ws9V1QI1vFruq8zwxftJ9p7flzpnOKlkWKlNOaW+czXMqeCj3L2LjEYi7AhcIi aOpfARGL/aV76iViMlR0DGKUB+2dl9755OICclm/u7/PtUOkx5WyJF8DAj7F4NLHT6mA v0mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tgcau1h4F6cd/V1KzNKqvvbO+5Q+hRnYWLopqM++JGM=; b=T7gKefRuVq+6+nWcmI1G5zdXxN2+0FaLSn0IcItqk3mGwMR7N0f1uSvYahpUkxYLUe BqdPW3Xkux5DJctquT1nfCNtdXCx+EcsxBgt3MJlFhpWOsqTJoTPbCgRmoHgI7upV0jO Y+OnnuwMPHUAkIRH5FMJq3D4FrMFg+p2E1XT7LFJnAr0MUmszm1ZMr2a+jLNdCI5tkj7 cp4inLdIWzhMxqHmySFcsYa0eFZ7cs1O6tx3AwBTejkFGR5O0ooBiiLQrRfETwEdtPd+ g3XJ+j8QM+WCrnc0Hl0eAuqwioReAH542dimvVmG+oeB6TwAa7T0hborpP200boXyOZ/ 09dA== X-Gm-Message-State: AOAM532235/udmdd+2WT/aamJS8DfkGXo1PImJKU49pEUoBYQxhAx81d NWwJcxRFNWL+BqBTrNea1ml3povQ51Ndj40wfNn6aVrF X-Google-Smtp-Source: ABdhPJwebgSh9opIGikS4+0maDowQ1jPvfU9HhYc0hQbMdjNyZDrxhJHlw6IvN2D+7HWuGe3oEfXwkD3+qyutXMl7tw= X-Received: by 2002:aca:bb0b:: with SMTP id l11mr5009851oif.146.1619659315597; Wed, 28 Apr 2021 18:21:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Foster Date: Wed, 28 Apr 2021 21:21:45 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000029d60105c1125292" Archived-At: Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 01:22:02 -0000 --00000000000029d60105c1125292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand that additional detail might make the reporting effort unacceptable to the big organizations that are creating them, and this reason alone may prevent alternatives. It seems that the potential uses for reports are: - Identifying and fixing my own infrastructure problems - Celebrating when the reports show that I have no new infrastructure problems. - Celebrating when malicious impersonators are blocked. - Learning about non-malicious impersonators that must be tolerated. - Identifying delivery problems that warrant a conversation with the recipient organization. I cannot successfully call a recipient help desk and ask them why they are blocking my messages. Instead, I need a message recipient to call his help desk and ask why he is not getting my messages, and that subscriber might be happy to be asked for assistance Navigating from a server IP address to a known subscriber might be no easy feat, while navigating from a server IP and target domain to that subscriber would be easier. In short, what are the expected uses of the RUA reports? Are there any intended purposes other than fixing my own infrastructure configuration? On Wed, Apr 28, 2021 at 8:34 AM Todd Herr wrote: > Apologies to Matt; I sent this originally only to him when I meant to sen= d > it to the list... > > On Wed, Apr 28, 2021 at 4:27 AM Matth=C3=A4us Wander 40wander.science@dmarc.ietf.org> wrote: > >> Hello everyone, >> >> I'm new to the party. I'd like to bring in some practical experience of >> working with DMARC rua reports. >> >> #23 introduces "receiving_domains" in the report metadata, justified by >> large infrastructures that host a large number of domains (e.g. Google). >> >> I think, this information would be more useful per-record rather than in >> the global metadata. As large infrastructures tend to include many >> different records in the report, the analyst needs a correlation between >> record and recipient domain. >> >> The section has an optional "envelope_to" already: >> > >> > > > minOccurs=3D"0"/> >> >> Is there a benefit in the global "receiving_domains" over the per-record >> "envelope_to"? >> >> Most reporters don't include "envelope_to" (e.g. Google). This field >> could be made more prominent in the draft. The main body mentions >> "header_from" only, but neither "envelope_to" nor "envelope_from". >> > > There is a hole in my understanding of this topic that I'm hoping someone > can fill here, and that hole is this: I don't understand the value of > reporting out receiving domains. > > The reason I don't understand it is because my expectation as a sender > receiving a report about my sending domain would be that my DMARC > validation results from a given receiving infrastructure would generally > not vary across the different receiving domains, regardless of if there w= as > one domain, ten domains, or ten thousand domains hosted by the reporting > infrastructure. To extend my expectations further, unless I'm dedicating > part of my infrastructure to sending solely to one and only one receiving > site, I would expect my DMARC validation results to generally not vary > across different reporting infrastructures. I'm declaring here that "DMAR= C > validation results" are separate from "applied receiver handling policy" > because as a sender I can only control the former; "DMARC validation > results" means "whether or not SPF and/or DKIM passed and was aligned and > consequently resulted in a DMARC pass or fail". > > If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly, > receiving_domains, defined as the "List of domains which received message= s > for the domain in this report" I guess it could perhaps help me as a repo= rt > consumer in the case where I receive a report from an previously unknown = or > unfamiliar to me reporter that hosts many domains, and if that's the use > case, then perhaps the field ought to be amended to "List of the top > $SMALL_NUMBER domains which received messages for the domain in this > report" because as a report consumer I don't need to see 837 domains list= ed > when realistically one or two will suffice. > > What is the value that I'm not seeing in reporting out receiving domains? > -- > > *Todd Herr* | Sr. Technical Program Manager > *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 prohibit= ed > 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 > --00000000000029d60105c1125292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I understand that additional detail might make the reporti= ng effort unacceptable to the big organizations that are creating them, and= this reason alone may prevent alternatives.

    It seems th= at the potential uses for reports are:
    - Identifying and fixing m= y own infrastructure problems
    - Celebrating when the reports show= that I have no new infrastructure problems.
    - Celebrating when m= alicious impersonators are blocked.
    - Learning about non-maliciou= s impersonators that must be tolerated.
    - Identifying delivery pr= oblems that warrant a conversation with the recipient organization.

    I cannot successfully call a recipient help desk and ask = them why they are blocking my messages.=C2=A0 =C2=A0Instead, I need a messa= ge recipient to call his help desk and ask why he is not getting my message= s, and that subscriber might be happy to be asked for assistance=C2=A0 =C2= =A0 Navigating from a server IP address to a known subscriber might be no e= asy feat, while navigating from a server IP and target domain to that subsc= riber would be easier.=C2=A0 =C2=A0=C2=A0

    In short= , what are the expected uses of the RUA reports?=C2=A0 =C2=A0Are there any = intended purposes other than fixing my own infrastructure configuration?

    On Wed, Apr 28, 2021 at 8:34 AM Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> wr= ote:
    Apologies to Matt; I sent this originally only to him when= I meant to send it to the list...

    On Wed, Apr 28, 2021 at 4:27 AM= Matth=C3=A4us Wander <mail=3D40wander.science@dmarc.ietf.org> wrote:
    Hello everyone,
    I'm new to the party. I'd like to bring in some practical experienc= e of
    working with DMARC rua reports.

    #23 introduces "receiving_domains" in the report metadata, justif= ied by
    large infrastructures that host a large number of domains (e.g. Google).
    I think, this information would be more useful per-record rather than in the global metadata. As large infrastructures tend to include many
    different records in the report, the analyst needs a correlation between record and recipient domain.

    The <identifiers> section has an optional "envelope_to" alr= eady:
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <!-- The envelope recipient domain. --&g= t;
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <xs:element name=3D"envelope_to&quo= t; type=3D"xs:string"
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m= inOccurs=3D"0"/>

    Is there a benefit in the global "receiving_domains" over the per= -record
    "envelope_to"?

    Most reporters don't include "envelope_to" (e.g. Google). Thi= s field
    could be made more prominent in the draft. The main body mentions
    "header_from" only, but neither "envelope_to" nor "= ;envelope_from".
    =C2=A0
    There is a hole in my= understanding of this topic that I'm hoping someone can fill here, and= that hole is this: I don't understand the value of reporting out recei= ving domains.

    The reason I don't understand it is because my expecta= tion as a sender receiving a report about my sending domain would be that m= y DMARC validation results from a given receiving infrastructure would gene= rally not vary across the different receiving domains, regardless of if the= re was one domain, ten domains, or ten thousand domains hosted by the repor= ting infrastructure. To extend my expectations further, unless I'm dedi= cating part of my infrastructure to sending solely to one and only one rece= iving site, I would expect my DMARC validation results to generally not var= y across different reporting infrastructures. I'm declaring here that &= quot;DMARC validation results" are separate from "applied receive= r handling policy" because as a sender I can only control the former; = "DMARC validation results" means "whether or not SPF and/or = DKIM passed and was aligned and consequently resulted in a DMARC pass or fa= il".

    If I'm reading=C2=A0draft= -ietf-dmarc-aggregate-reporting-02=C2=A0correctly, receiving_domains, defined as the &= quot;List of domains which received messages for the domain in this report&= quot; I guess it could perhaps help me as a report consumer in the case whe= re I receive a report from an previously unknown or unfamiliar to me report= er that hosts many domains, and if that's the use case, then perhaps th= e field ought to be amended to "List of the top $SMALL_NUMBER domains = which received messages for the domain in this report" because as a re= port consumer I don't need to see 837 domains listed when realistically= one or two will suffice.

    What is the value that I&#= 39;m not seeing in reporting out receiving domains?
    --

    Todd Herr | Sr. Technical Pro= gram Manager
    = m: 703.220.4153

    This email and al= l data transmitted with it contains confidential and/or proprietary informa= tion intended solely for the use of individual(s) authorized to receive it.= If you are not an intended and authorized recipient you are hereby notifie= d of any use, disclosure, copying or distribution of the information includ= ed in this transmission is prohibited and may be unlawful. Please immediate= ly 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
    --00000000000029d60105c1125292-- From nobody Thu Apr 29 05:44:30 2021 Return-Path: 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 49DFD3A3D63 for ; Thu, 29 Apr 2021 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=valimail.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 dWK9K919TkzG for ; Thu, 29 Apr 2021 05:44:23 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7333A3D65 for ; Thu, 29 Apr 2021 05:44:23 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id d19so31225485qkk.12 for ; Thu, 29 Apr 2021 05:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=c2w3Uf9ZIHkMz7KKaOmiGMJyvAuAaybxqVItZYoGsbw=; b=b1Wn5Wu+AamPf9ptno8YG2aJFH7hD7hd9flZUcy88vy4wnP5yv/NtsCzWeZfS4OH0h iXKWxN9hujDsbqw2XAw9jlmyWzEREQswMKTP8pHsQpixC6NqciAYeGmJa/OQXUGsfiW2 n+L96V5a/ERaHhlASOXanI4hkx/eBsQWIo0nzD+7s7wzhzADrpD4+A0QbH9JZQwnrR73 wiTrntdSSE0uwPXS+NtLmxD1FoEWh9DGTqObWlpEBDz0p4hsqYN0PpvV2pu10wn8KZ75 udwzA5baY+uJBAo+4vS/7JcxIw9eCVcuDl7bS2c64YDP9KHAPmHOyZBChrnAzuePusw+ yuew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c2w3Uf9ZIHkMz7KKaOmiGMJyvAuAaybxqVItZYoGsbw=; b=lfQklBeVtBJTf27UgwsoT5E3an5TKmPJPRr/9JgrL3k5ww18m6vOZidwlPDVY79r/f TdJf9FbkgATGzYzlAquSF+bfwcYyH1RtrMOxivrps+gBNgeA0C9QR83GxD3uoNG3X4Up m3Ul+otRRk6AncnrzMoE0DRsdqFnyTDWMpj5rnw3Rogf4IWqvKK+usw6fokCQqizsYA8 BbzCWhV+J/w4oe/9kPyLPMmNoTBF66SlNnJOL1gRNoiFRYaeFFj7nzYciOjt1Jt3cPpl rm22XGENNsW0Ayzpa/DEbsml3aoAJarwbRx+Lj2aP70Ym90Zjg1Sh3sfWc4wNSP6PhVC 0UFQ== X-Gm-Message-State: AOAM531FEvuIzSga5ou2g/oq/ZPji3x3ZE/rM1INDSuBRmCtX8xqng/n HKWRz+lT14or+cIz0HnMBsPtyrb+b9tRPhU62s3scoKf95Q= X-Google-Smtp-Source: ABdhPJz2/TcvwNgLFyzAnjSLESJeEUZEFcjPR55EVDK73PZz9NkQ9PQY8TOpv6GpkQ5Xv39LPHV/iXwb3YlH/ePH8tY= X-Received: by 2002:a05:620a:204b:: with SMTP id d11mr33547615qka.456.1619700261104; Thu, 29 Apr 2021 05:44:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Thu, 29 Apr 2021 08:44:05 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b4c14b05c11bdac9" Archived-At: Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 12:44:28 -0000 --000000000000b4c14b05c11bdac9 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 28, 2021 at 9:22 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > I understand that additional detail might make the reporting effort > unacceptable to the big organizations that are creating them, and this > reason alone may prevent alternatives. > > It seems that the potential uses for reports are: > - Identifying and fixing my own infrastructure problems > - Celebrating when the reports show that I have no new infrastructure > problems. > - Celebrating when malicious impersonators are blocked. > - Learning about non-malicious impersonators that must be tolerated. > - Identifying delivery problems that warrant a conversation with the > recipient organization. > I believe all of those things are already possible with the aggregate report as it is now, with no need to list the recipient domains. For any set of X domains hosted at provider Y, I would expect DMARC validation results (i.e., pass or fail) to be consistent across all X domains at that provider. > > I cannot successfully call a recipient help desk and ask them why they are > blocking my messages. Instead, I need a message recipient to call his > help desk and ask why he is not getting my messages, and that subscriber > might be happy to be asked for assistance Navigating from a server IP > address to a known subscriber might be no easy feat, while navigating from > a server IP and target domain to that subscriber would be easier. > I read this and I perceive that you are assuming that DMARC failures will be the only reason for mail to be rejected, and that all mail that passes DMARC checks will be accepted. Neither of those assumptions are necessarily true, and many if not most delivery problems will be independent of DMARC. DMARC allows for reliable association of an identity and its accumulated reputation with a mail message, and it's that accumulated reputation that will drive whether or not the message is delivered. > > > In short, what are the expected uses of the RUA reports? Are there any > intended purposes other than fixing my own infrastructure configuration? > Regardless of what the original intent of the aggregate reports might've been, for all practical purposes they're only valuable for auditing one's own authentication practices and configuration, in my opinion. It's actually a perhaps underappreciated feature of DMARC, in that one can use DMARC at p=none to conduct a full and complete audit simply by consuming aggregate reports over time and addressing problems with one's own mail streams that the reports might show. Once enough time has passed and the report consumer is sure that all of its mail streams have been reported upon and are properly authenticating, the domain owner can publish a more strict policy (p=quarantine or p=reject) if it so chooses. For authentication failures shown in the reports that are the result of mail the domain owner did not send, I haven't yet met an abuse desk that will act on anything other than headers (assuming that they'll act at all), so it's not actionable data. The value in this subset of the data really lies in seeing that such mail ends up failing to reach its destination once the domain owner changes its policy to something stronger than p=none and report generators start to honor that policy. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000b4c14b05c11bdac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Apr 28, 2021 at 9:22 PM Douglas Foster <dougfoster.emailstandards@gmail.com<= /a>> wrote:
    I understand that a= dditional detail might make the reporting effort unacceptable to the big or= ganizations that are creating them, and this reason alone may prevent alter= natives.

    It seems that the potential uses for reports ar= e:
    - Identifying and fixing my own infrastructure problems
    <= div>- Celebrating when the reports show that I have no new infrastructure p= roblems.
    - Celebrating when malicious impersonators are blocked.<= /div>
    - Learning about non-malicious impersonators that must be tolerat= ed.
    - Identifying delivery problems that warrant a conversation w= ith the recipient organization.

    I believe = all of those things are already possible with the aggregate report as it is= now, with no need to list the recipient domains. For any set of X domains = hosted at provider Y, I would expect DMARC validation results (i.e., pass o= r fail) to be consistent across all X domains at that provider.

    I cannot successfully call a recipient help desk and ask them why the= y are blocking my messages.=C2=A0 =C2=A0Instead, I need a message recipient= to call his help desk and ask why he is not getting my messages, and that = subscriber might be happy to be asked for assistance=C2=A0 =C2=A0 Navigatin= g from a server IP address to a known subscriber might be no easy feat, whi= le navigating from a server IP and target domain to that subscriber would b= e easier.=C2=A0

    I read this and I perceiv= e that you are=C2=A0assuming that DMARC failures will be the only reason fo= r mail to be rejected, and that all mail that passes DMARC checks will be a= ccepted. Neither of those assumptions are necessarily true, and many if not= most delivery problems will be independent of DMARC. DMARC allows for reli= able association of an identity and its accumulated reputation with a mail = message, and it's that accumulated reputation that will drive whether o= r not the message is delivered.
    =C2=A0=C2=A0

    In = short, what are the expected uses of the RUA reports?=C2=A0 =C2=A0Are there= any intended purposes other than fixing my own infrastructure configuratio= n?

    Regardless of what the original intent = of the aggregate reports might've been, for all practical purposes they= 're only valuable for auditing one's own authentication practices a= nd configuration, in my opinion. It's actually a perhaps underappreciat= ed feature of DMARC, in that one can use DMARC at p=3Dnone to conduct a ful= l and complete audit simply by consuming aggregate reports over time and ad= dressing problems with one's own mail streams that the reports might sh= ow. Once enough time has passed and the report consumer is sure that all of= its mail streams have been reported upon and are properly authenticating, = the domain owner can publish a more strict policy (p=3Dquarantine or p=3Dre= ject) if it so chooses. For authentication failures shown in the reports th= at are the result of mail the domain owner did not send, I haven't yet = met an abuse desk that will act on anything other than headers (assuming th= at they'll act at all), so it's not actionable data. The value in t= his subset of the data really lies in seeing that such mail ends up failing= to reach its destination once the domain owner changes its policy to somet= hing stronger than p=3Dnone and report generators start to honor that polic= y.


    --

    Todd Herr | Sr. Technical Progra= m Manager
    m:<= /b> 703.220.4153

    This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

    --000000000000b4c14b05c11bdac9-- From nobody Thu Apr 29 09:22:57 2021 Return-Path: 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 CB9EC3A41D7 for ; Thu, 29 Apr 2021 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXIEnZYUZ8Jh for ; Thu, 29 Apr 2021 09:22:54 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFC63A41D4 for ; Thu, 29 Apr 2021 09:22:54 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id 92-20020a9d02e50000b029028fcc3d2c9eso39372594otl.0 for ; Thu, 29 Apr 2021 09:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tRCrAFRTp6KrTAHCYkuZW/xW0hN/y3+psbQBeIjnbvc=; b=q1r5QywqOYnvg/JQEPKmK4oR2ldXcwB+69MAgpS6iZbjHhKRDABNwrXRLCc5uB7ctn nafxPBMR65aFOMjXLjdlxYnTC73k7hZkY41Q1A6WRC/z76KDB9904JF5QAWocHRF7bDy 2Vx8zyN4sAZs2gAYUisMwpFEuQ1UEfjDbLT2a9stDx3HOdyQoddOg8K+W6xEpvLtVvi7 uI0HAotla+iLogAJvH42HGteLYNKZfNxtLyLXOoxrvSwhPybe40UvmjNa91ny9JuibBp 6z7EmG4x5OOodzAVyaR5vdiIWTNMC+YaAs6PFaxaSJnel2TEccCbu8FpWRBZMIE9zkIf Yscw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tRCrAFRTp6KrTAHCYkuZW/xW0hN/y3+psbQBeIjnbvc=; b=QZqQGSEgWMARniYPxZ+MRJAQZFi0O7q9+stxRLVdOb7U1AZeKMpTgXBdmQ0lql6ATe lkDC+OOeaYAnHLzv/B15fxrHBV6Z/QfB92vAUiR/Z769O1THdnd2GkB5kbuzno8AmnOm 6NMt3EEHtAQ0qQe7N2Y81wU4Bd+BrSOSj2p6y3I7UuMsfjTOM0o7tZGhsb2GqMmX4Hhx RtssoLtOIYXTrAbU+eHqkhVEeJb6lMGkbwCZi8hnG95lFNQmcg2E2vd/6Wu6dsLYywKK ynOkxlNaTfLOuBvZwmoDQn2Vtat0hCjd3A2jQFSddE3G2wQYiW224FYS6t+yfvyY2+1x yDjQ== X-Gm-Message-State: AOAM530JEflCb6vKg4hBiHMpZt7pTcxo12cZyF9OhGxZAsAMl+fdadc3 dOBFkQ1QLqu9dwg6UJ5EpW9nDBob82z0em+++x5TLOgA X-Google-Smtp-Source: ABdhPJwueQszGPfgcKgh7Zvcy3e/jmwjGxPCqLwntAS8ufdFIS4AggEGgwQgvfRxNJrJf7zvI/z7pSpfd1owdUfDTBo= X-Received: by 2002:a9d:30b:: with SMTP id 11mr165050otv.298.1619713372434; Thu, 29 Apr 2021 09:22:52 -0700 (PDT) MIME-Version: 1.0 From: Douglas Foster Date: Thu, 29 Apr 2021 12:22:42 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000033b2d505c11ee834" Archived-At: Subject: [dmarc-ietf] Ticket #60 - definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 16:22:56 -0000 --00000000000033b2d505c11ee834 Content-Type: text/plain; charset="UTF-8" There is much to like about the new document. Thank you to the design team for your good work. For the NP policy, the MX/A/AAA test lacks the precise definition that I would expect to be required for a standards-track document. Does another document have language that we can use or reference? Additionally, it needs language to explain why this is the appropriate test for separating between the SP policy and the NP policy. --00000000000033b2d505c11ee834 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    There is much to like about the new document.=C2=A0 = =C2=A0Thank you to the design team for your good work.

    = For the NP policy, the MX/A/AAA test lacks the precise definition that I wo= uld expect to be required for a standards-track document.=C2=A0 =C2=A0Does = another document have language that we can use or reference?

    =
    Additionally, it needs language to explain why this is the appropriate= test for separating between the SP policy and the NP policy.
    =C2=A0
    --00000000000033b2d505c11ee834-- From nobody Thu Apr 29 13:52:47 2021 Return-Path: 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 AE04C3A0E32 for ; Thu, 29 Apr 2021 13:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=valimail.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 MXvzlJEoNlPv for ; Thu, 29 Apr 2021 13:52:42 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71D53A0E31 for ; Thu, 29 Apr 2021 13:52:41 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id o1so8598038qta.1 for ; Thu, 29 Apr 2021 13:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IF0ZYYiFQH+Am1gLME3RsdpfNwP+VmXDvLHkLXdQnp8=; b=XMCUkQe5oq1fRPfCdJo5eO3Ypg7Y7s6/dmOxyffGvItOt0gBzy2ftHnhpfy1cxVOS4 DUdQq/o1JlyglTZktNc8pQVWIWRt5/Tht3spmwMMtwrRZKJs+cfP36za8NrioIJ+sKKQ 16rrEeYtOjh+nvMFaiVJSxnDdOto0NJ3fZbrrIfz9KHRJqjJc01GiiQw8zeIXsRlX7vr 0lY4P3+zVO9jRyveybVg/bc1g6CsYhh9eLkTJlOOtqFr1mzM0FsJ4Vw2xK7wFvOamGBi AEplTUPq54EQhXkvuSaS6GEobGXhLFLc2KFo/V2XdiUjMD9t3D0pAFc0xQHgzkjRFw+U Qq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IF0ZYYiFQH+Am1gLME3RsdpfNwP+VmXDvLHkLXdQnp8=; b=XU02tIe7B28WEYEZzNmIBp/FgZkzrNtl8iHc13j9ZeAzjknNE2/O4UYg3immB9XMii xW7QFVPTGHXpPfWn3I+wL1dRTUDG3K7I4ADlW0x+Hb9BhGzqu5nca1bWew6mjCHpB0IG 9J9x7+gglXslkHIlX63zN2Qw0qlg6OrOAJzkI0f/g7BHQt1IbXVXHPah1zPfAYRdmnxR dDa1srPjCCadnoYR3ekYbi1S4cXITvA2myRnZYbGwmyWYPRyr5OEIOyL4gylt7lsD3Zk FbUkBmeXxZQNygs81+oixL/eHJnC6tXNuz6gRarLVKqTpP5NqqpjZUj3ZFJT89E+jxTN odjQ== X-Gm-Message-State: AOAM531nT597jQywStK49exrKgi70aBjt6S0TNSBsgaxtFqqr8BRMNa6 FqcE+Hy/7GTJuNW0SUzGv108ouWl3XV75uBKuJFjU5h6C7kWrw== X-Google-Smtp-Source: ABdhPJwVIGRCz7CKm7fR2yEdTf69R1vUTDFH/iPSnfcCj++ybupltGVvvKKrchxlglbjHuYvU2QEG0k1cNPCUdeaWhg= X-Received: by 2002:a05:622a:1353:: with SMTP id w19mr1316263qtk.220.1619729558218; Thu, 29 Apr 2021 13:52:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Thu, 29 Apr 2021 16:52:22 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f3489605c122ac07" Archived-At: Subject: Re: [dmarc-ietf] Ticket #60 - definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 20:52:47 -0000 --000000000000f3489605c122ac07 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 29, 2021 at 12:23 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > There is much to like about the new document. Thank you to the design > team for your good work. > > For the NP policy, the MX/A/AAA test lacks the precise definition that I > would expect to be required for a standards-track document. Does another > document have language that we can use or reference? > > Additionally, it needs language to explain why this is the appropriate > test for separating between the SP policy and the NP policy. > > The proposed language in draft-ietf-dmarc-dmarcbis-01 regarding the np tag came from draft-ietf-dmarc-psd-12, specifically section 3.2 of that document . This is also detailed in ticket 108 Ticket 60 is currently associated with the aggregate reporting document, but 'np' doesn't appear in that document, so perhaps ticket 60 needs to be re-assigned to the DMARCbis base spec. Either way, it doesn't appear that ticket 60 has been worked on yet. Feel free to propose additional language modifications either in one of the two tickets on in this thread. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000f3489605c122ac07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Apr 29, 2021 at 12:23 PM Douglas Foster <dougfoster.emailstandards@gmail.com= > wrote:
    There is much= to like about the new document.=C2=A0 =C2=A0Thank you to the design team f= or your good work.

    For the NP policy, the MX/A/AAA test= lacks the precise definition that I would expect to be required for a stan= dards-track document.=C2=A0 =C2=A0Does another document have language that = we can use or reference?

    Additionally, it needs language= to explain why this is the appropriate test for separating between the SP = policy and the NP policy.
    =C2=A0
    The proposed language in draft-ietf-dmarc-dmarcbis-01 regarding the np tag= came from=C2=A0draft-ietf-dmarc-psd-12, specifically section 3.2 of that document<= /a>. This is also detailed in=C2=A0ticket 108

    Ticket 60 is currently associated with t= he aggregate reporting document, but 'np' doesn't appear in tha= t document, so perhaps ticket 60 needs to be re-assigned to the DMARCbis ba= se spec. Either=C2=A0way, it doesn't appear that ticket 60 has been wor= ked on yet.

    Feel free to propose additional language modifications eithe= r in one of the two tickets on in this thread.

    --=

    Todd Herr | Sr. Technical Program Manager
    m: 703.220.4153

    This email and all data transmitted with it contains confidential and/or p= roprietary information intended solely for the use of individual(s) authori= zed 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 d= elete it from your system.

    --000000000000f3489605c122ac07-- From nobody Thu Apr 29 18:29:02 2021 Return-Path: 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 892593A1BA1 for ; Thu, 29 Apr 2021 18:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUEifj2eRyJ6 for ; Thu, 29 Apr 2021 18:28:59 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F367E3A1BA0 for ; Thu, 29 Apr 2021 18:28:58 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id y14-20020a056830208eb02902a1c9fa4c64so26622837otq.9 for ; Thu, 29 Apr 2021 18:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PFoMP8J5KrW0k9Uhaf6ZHm85ZxpDT3n9Xzz3pux791U=; b=nGayQxuj3olaR6vtZdHr4HfcuuJPAcxE6ZsL8Hfp0EleXgxG1qcE24PgntcSb3i1MW oxlPngkX8BPUh2qR5wglEoU2oGWKnFEMhXITdfMjFFEYIkH0Nhlz//e5tQPyxmEfLXj2 Yil5+2oO4NrjZ97XIwFdVrPjFSGrdG1wtf0cXIuYwcjAQAn/U7EIcVT4Y1QmahbUff+4 FCwJKo/NuifB7Mo0i7V2UV0SiYcdVuFcEoFH1hyT1A25SjofaBfDwX54EZutB6yHMLZ8 ytk3hWrLfsdVu64cNy6zJUkb9/nFNNIDxRnLpFsDEBvjOBk20NGyMHb6rgk+lX3vuLZp bXjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PFoMP8J5KrW0k9Uhaf6ZHm85ZxpDT3n9Xzz3pux791U=; b=kXt7xjr+mUPqbCncs5sKlG8Xj6dBzZ0ZkTMvp3E2nKgH2Sti53JnWjQewhYxo1fSLs bfwqdyClGSE3nnb/lafqq/xjGQL7lZFS97Dd3oW292WIK3kkso92arlu7t8HGbAWZ0z7 2YwaYfmXdpp66EhivbSHOx/JvnPJxqy7wLtFEPG5R8FgMZJn/IZ96aBHn2NUIb2RKCaS 5F+U/LkeqIDN1iQmRpVHkOGLWkcTp6tonAM0dfj/LVKPsFfh0U3FuGCL6yzwy5VR6lUE Pj7yFrdtHoj0mK/6Z4Kl5d+cOw5TLyCPtyutzEE43+TQKI6ExfEyw92Am7xEGlfRz4LQ isRA== X-Gm-Message-State: AOAM530ECvq/EFsjd+g18HZKA72ff7HXAymKs4mD9L50YqaMETyoMJHZ IgmKqbqU1Xtw5HNDMq0gVam3Dx/Rt8GXx3x4/2aU4sqCWC8= X-Google-Smtp-Source: ABdhPJxqCUclj0pkc1wBBiRx1JTQcOL0F2UbtczIhwq9unl5plrpoluzEExHHE2mhNRpGdaX7d0rib3xolDuksVWdjw= X-Received: by 2002:a9d:666:: with SMTP id 93mr1735534otn.284.1619746136584; Thu, 29 Apr 2021 18:28:56 -0700 (PDT) MIME-Version: 1.0 From: Douglas Foster Date: Thu, 29 Apr 2021 21:28:47 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000018f41d05c126897c" Archived-At: Subject: [dmarc-ietf] Ticket #108 - Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 01:29:01 -0000 --00000000000018f41d05c126897c Content-Type: text/plain; charset="UTF-8" I suspected that the current language is the best that we have, but it is far from an algorithm. Below are the algorithm details that I would expect should be addressed. The dilemma - If we mandate more detailed checks, we add complexity which hurts throughput. - If we take no position, we hinder interoperability. - If we say MUST NOT check, we provide guidance about how to defeat the test with false positives. For MX lookup: Is the condition satisfied if at least one MX record exists, or do we need to examine contents? If we examine contents, do we only look at host name formats, or do we resolve it to an IP address? If we resolve to an IP address, do we check for non-routable addresses (loopback, private, multicast)? If we resolve to an IP address, and all of the returned addresses are in a different address space than the source IP, is the condition satisfactory or failed? If failed, do we proceed to the A lookup or stop? For A/AAAA lookup The A/AAAA test will generate a lot of false positives. Do we accept that DMARC-publishing domains will still be using Implicit MX, or do we create an expectation, for purposes of this test, that DMARC-publishing domains will use only MX records? Do we check just the address space that matches the source IP, or both IPv4 and IPv6? Do we check the returned IP for non-routable addresses? For an A record that is not equal to a DNS domain: Do we check the host name to determine whether it is a domain name or a host record within a parent domain? If the host name is determined to be a host record within a parent domain, is the domain DMARC policy determined by the host name (which will produce No Policy Found) or is the DMARC policy lookup applied to the parent domain of the host record? --00000000000018f41d05c126897c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I suspected that the current language is the best that we = have, but it is far from an algorithm.=C2=A0=C2=A0
    Below are the algori= thm details that I would expect should be addressed.=C2=A0=C2=A0
    =
    The dilemma
    - If we mandate more detailed checks, = we add complexity which hurts throughput.=C2=A0=C2=A0
    - If we take no = position, we hinder interoperability.
    - If we say MUST NOT c= heck, we provide guidance about how to defeat the test with false positives= .=C2=A0 =C2=A0

    For MX lookup:
    Is th= e condition satisfied if at least one MX record exists, or do we need to ex= amine contents?
    If we examine contents, do we only look at host n= ame formats, or do we resolve it to an IP address?
    If we resolve = to an IP address, do we check for non-routable addresses=C2=A0(loopback, pr= ivate, multicast)?
    If we resolve to an IP address, and all of the= returned addresses are in a different address space than the source IP, is= the condition satisfactory or failed?=C2=A0 =C2=A0If failed, do we proceed= to the A lookup or stop?

    For A/AAAA lookup
    <= div>The A/AAAA test will generate a lot of false positives.=C2=A0 =C2=A0Do = we accept that DMARC-publishing domains will still be using Implicit MX, or= do we create an expectation, for purposes of this test, that DMARC-publish= ing domains will use only MX records?
    Do we check just the addres= s space that matches the source IP, or both IPv4 and IPv6?
    Do we = check the returned IP for non-routable addresses?

    <= div>For an A record that is not equal to a DNS domain:
    Do we chec= k the host name to determine whether it is a domain name or a=C2=A0host rec= ord within a parent domain?
    If the host name is determ= ined to be a host record within a parent domain, is the domain DMARC policy= determined by the host name (which will produce No Policy Found) or is the= DMARC policy lookup applied to the parent domain of the host record?


    --00000000000018f41d05c126897c--