From nobody Tue May 7 19:10:53 2019 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 99E0312002E; Tue, 7 May 2019 19:10:51 -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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155728145158.24534.10112720017814447505@ietfa.amsl.com> Date: Tue, 07 May 2019 19:10:51 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 08 May 2019 02:10:52 -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 (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-03.txt Pages : 11 Date : 2019-05-07 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-03 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 Tue May 7 19:16:09 2019 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 9DCB412007A for ; Tue, 7 May 2019 19:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=0rHr/vFz; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jWOdKw1j 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 b81h4xNm86Ze for ; Tue, 7 May 2019 19:16:06 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4BD12002E for ; Tue, 7 May 2019 19:16:05 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 98F7EF807BE for ; Tue, 7 May 2019 22:16:04 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1557281764; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=XdUyFT5dYcfIytSUzHsF1GWiBN2ANFGduCL2MxdBCbw=; b=0rHr/vFz8KzPV/VepX8YYbp549R9tQrGcDMvu3CcSgIsuMTXkpb1RiRF Sp/BOOAJwigNNnKPbJk44jG29RsfBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1557281764; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=XdUyFT5dYcfIytSUzHsF1GWiBN2ANFGduCL2MxdBCbw=; b=jWOdKw1jg/i5gDS8oKI2zkfrSKwMLzHw+Tgtv6gjnB+3IFdnh9saVUpu WOXB7TZiYLdqDre+tuisFf7bO4OPQRga5aDDg26DkKcuKHA/oht2ZM51tJ FYTVCTTRnI8s7C7JRA3MthyfevvzewmYTbDOr2vicl2BcfFVQepaLesBYH OPJRUL0fNSJ+jxxDfdYJSAufMv8s8ATYM2ygt18or/0O2MVmcC2D4PXOXR 3zX4VR5b60hvHMwZZCwxklqs4YlczOlNFTQIIMnktQwR++J6Qm7M6QTGem MOuGKlT5OimiuNHWZryGENZTXjkhGGKT6RB+yCmotGRv8ErTEn2E3Q== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 534BAF80718 for ; Tue, 7 May 2019 22:16:04 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 07 May 2019 22:16:03 -0400 Message-ID: <2699063.PiBShnsfcX@l5580> In-Reply-To: <155728145158.24534.10112720017814447505@ietfa.amsl.com> References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 08 May 2019 02:16:08 -0000 On Tuesday, May 7, 2019 10:10:51 PM EDT internet-drafts@ietf.org 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 : DMARC (Domain-based Message Authentication, > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > Author : Scott Kitterman > Filename : draft-ietf-dmarc-psd-03.txt > Pages : 11 > Date : 2019-05-07 Significant changes from -02: Based on offline feedback: Added a paragraph on PSD exact domain match issues. Added a clear MUST NOT for [RFC7489] Section 7.3 Failure Reports Finished Appendices: Added more text to Appendix B about support for the experiment available from psddmarc.org. Added Appendix C to track implementations. If anyone else has an implementation that's not listed, please let me know and I'll add it. Other than that, I think it's about done. Scott K From nobody Tue May 7 19:30:48 2019 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 0E09D12007A for ; Tue, 7 May 2019 19:30:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=sethblank-com.20150623.gappssmtp.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 leanvR8KJpPI for ; Tue, 7 May 2019 19:30:43 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 AC6A112002E for ; Tue, 7 May 2019 19:30:43 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id 66so7557123otq.0 for ; Tue, 07 May 2019 19:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=42b8ogwCHO/e2AkjTs7p9TQJcq6oXqiVZD1ASKvcNp8=; b=fofCxqlgP9el1+NT8Qa5ignFiFmSaqn1wGVAh0gMMhF5gQYhTABI/qcyAqeV3KMPoQ 6/4T7EXv8NFdM5l9eGtEKlRrMaOb0pLwslKtm9mj+QUSzTaZ7NLB/HdVbiS61q9D1Fv2 JPBy9nslIBBbNKkoLK69nHK3vQdGJDbC10jzxEmP510kjz6ZCsaN0x9PoLpLcVh+Q8F/ bb/U0kAmtg87o1sWyAqbwvZFC39T8vC5BDyv2d9VEI5h5Qn6sY2mu6jNHZugdFXLe/gf TvnwkVmD+wuhanN/mYv6NR7GpBCns8dFo6w2FFsv/mP/JCXmIxQZaVbSR02b5/MTAxqj jT1g== 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=42b8ogwCHO/e2AkjTs7p9TQJcq6oXqiVZD1ASKvcNp8=; b=brVX8nRgTQPtrfhJZAmPfOtRlO8BpGDaBv7dLfoPeIT8ptgk7TrIGPh6IlU3KIiGvO /D+L1adjBjuVytDLHqB0sBb3oBkZHVBeq+c4fV+7MwS9T3yAQbajwwIu/XfmUWarUult 41G83EG733qv4n2w0oZt3LIaKWWQDackKGN7MrjxYuwBAf/A61z/Q4dkh0q+wth5+NTY IeN0bRZiDywop8ysK6tWTBPzZY/1d8tJCKatnVnc1x3sZATmyY23ViEe5f7QYMJ2UaBy PIs86D9bsUte+/gr26CKi8XRd1HoZalU14zVaNOl3cWHPs8W/Cj4LnqIdIZrbfKUPdOP EEJA== X-Gm-Message-State: APjAAAXXYhEUZecnNDY8Gss2AXP1m8o5uA9qfgw36fmKGNe8qCzFmFXZ C5WyqdSkgOfupBrnRtHe+uB42Y9RDgZYC3hGLM96Zs8DbQU= X-Google-Smtp-Source: APXvYqwhWs5f+rdrr8PS93NBuxUcy9qqk4QlCCRmPelacvrsr6V/hQhYi/ZJYwSGFM+RxdX20A2VRDb4s8lXAC4A1lI= X-Received: by 2002:a9d:6013:: with SMTP id h19mr6206698otj.215.1557282642662; Tue, 07 May 2019 19:30:42 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <2699063.PiBShnsfcX@l5580> In-Reply-To: <2699063.PiBShnsfcX@l5580> From: Seth Blank Date: Tue, 7 May 2019 19:30:25 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bb2f900588571e8a" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 08 May 2019 02:30:47 -0000 --000000000000bb2f900588571e8a Content-Type: text/plain; charset="UTF-8" Thanks, Scott! To me (as an individual) this seems ready for last call. A few items: 1. In the new paragraph in section 1 clarifying requirements, you have an open parens that is never closed. 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would mean .example couldn't receive failure reports the way example.com does. For something like .bank or .com, this is a feature. But for a .google, this is a bug. I really think this MUST NOT is, while well advised, delving into policy and not interop. I really think the guidance in 4.1 is the best way to approach this. Speaking of which, with the normative MUST NOT that's been added, now 4.1 no longer makes any sense. My recommendation would be to roll this change back, and perhaps replace it with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless you really really know what you're doing." 3. psddmarc.org - I think we need a brief paragraph outlining the experiment, and in it need to explicitly call out that a permanent solution needs to be determined for answering the "what's a PSD" question - which may or may not be psddmarc.org. Thanks again! Seth On Tue, May 7, 2019 at 7:16 PM Scott Kitterman wrote: > On Tuesday, May 7, 2019 10:10:51 PM EDT internet-drafts@ietf.org 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 : DMARC (Domain-based Message Authentication, > > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > > Author : Scott Kitterman > > Filename : draft-ietf-dmarc-psd-03.txt > > Pages : 11 > > Date : 2019-05-07 > > Significant changes from -02: > > Based on offline feedback: > > Added a paragraph on PSD exact domain match issues. > Added a clear MUST NOT for [RFC7489] Section 7.3 Failure Reports > > Finished Appendices: > > Added more text to Appendix B about support for the experiment available > from > psddmarc.org. > Added Appendix C to track implementations. > > If anyone else has an implementation that's not listed, please let me know > and > I'll add it. > > Other than that, I think it's about done. > > Scott K > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000bb2f900588571e8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Scott!

To me (as an individual)= this seems ready for last call.

A few items:
<= div>
1. In the new paragraph in section 1 clarifying requirem= ents, you have an open parens that is never closed.

2. In Section 3.5, I'm concerned with the normative MUST NOT. This wo= uld mean .example couldn't receive failure reports the way example.com does. For something like .bank or .com, = this is a feature. But for a .google, this is a bug. I really think this MU= ST NOT is, while well advised, delving into policy and not interop.

I really think the guidance in 4.1 is the best way to app= roach this.

Speaking of which, with the normative = MUST NOT that's been added, now 4.1 no longer makes any sense.

My recommendation would be to roll this change back, and p= erhaps replace it with a reference to 4.1 and a "if you're a PSD, = don't ask for RUF unless you really really know what you're doing.&= quot;

3. psddmarc.= org - I think we need a brief paragraph outlining the experiment, and i= n it need to explicitly call out that a permanent solution needs to be dete= rmined for answering the "what's a PSD" question - which may = or may not be psddmarc.org.
=

Thanks again!

Seth
=
On Tue= , May 7, 2019 at 7:16 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Tuesday, May 7, 2019 10:10:51 PM EDT internet-drafts@ie= tf.org 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.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: DMARC (Domain-based Message Authentication,
> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)=
> Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scott Kitterman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dmarc-psd-03.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-05-07

Significant changes from -02:

Based on offline feedback:

Added a paragraph on PSD exact domain match issues.
Added a clear MUST NOT for [RFC7489] Section 7.3 Failure Reports

Finished Appendices:

Added more text to Appendix B about support for the experiment available fr= om
psddma= rc.org.
Added Appendix C to track implementations.

If anyone else has an implementation that's not listed, please let me k= now and
I'll add it.

Other than that, I think it's about done.

Scott K



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000bb2f900588571e8a-- From nobody Thu May 9 09:39:28 2019 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 1E7DF12006B for ; Thu, 9 May 2019 09:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=/mc9lDz9; dkim=pass (2048-bit key) header.d=kitterman.com header.b=pWuB2y4/ 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 uwHXBKYdtz1y for ; Thu, 9 May 2019 09:39:25 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823F312016A for ; Thu, 9 May 2019 09:39:15 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 39676F8074A for ; Thu, 9 May 2019 12:39:14 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1557419954; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=HdNVemkGC8x0lkJtY5lXZfTNV4tWERkYbm1vBYLHmWs=; b=/mc9lDz9PLDf1/XbQZC5MY+jOTcESgF8XdyZDTpGMWvQXBzvMo+i+KyT NZp5Drrvqb/LC+YvN6nLD8JmNjpRCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1557419954; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=HdNVemkGC8x0lkJtY5lXZfTNV4tWERkYbm1vBYLHmWs=; b=pWuB2y4/wBGWnT0uPlxiQZdHEhk2lxeot/FA/p1iVcSMXE+1KCsX5qwd QHdtE+bDQyBSrQvRqqQLpnC4sZ6yiFPUGRvOZ+lGmYTRbFp0Ih1v+Ula8i 3XkKtQ/ljJ6GgAeN7zIfcWoctGoSas4gM8F7Z6DJ74d7uhWJormm1Sc9xL arVPHVzK0W5NkQ4jOXZsMsjkV8erWf+vgzeBptesPhxr7pxF0x09qRWqft DuFLN8EkMuTfENwmFUmtT6wOCEDPizIyd8SNybLlltPuI3DtxzIe9mhvhg fm2knr6H56YRwV1h0ueHhcvMYuVw5gLAZ+z8PI0XISms5GOdRleqOA== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 05D03F80721 for ; Thu, 9 May 2019 12:39:13 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 09 May 2019 12:39:13 -0400 Message-ID: <12992594.LUNhQVcRDa@l5580> In-Reply-To: References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <2699063.PiBShnsfcX@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Thu, 09 May 2019 16:39:27 -0000 On Tuesday, May 7, 2019 10:30:25 PM EDT Seth Blank wrote: > Thanks, Scott! > > To me (as an individual) this seems ready for last call. > > A few items: > > 1. In the new paragraph in section 1 clarifying requirements, you have an > open parens that is never closed. Fixed locally for the next revision. > 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would > mean .example couldn't receive failure reports the way example.com does. > For something like .bank or .com, this is a feature. But for a .google, > this is a bug. I really think this MUST NOT is, while well advised, delving > into policy and not interop. In theory, I agree, but in practice, I think the new MUST NOT is a great change to promote implementation simplicity. Recall that the failure reports we are discussing are not commonly sent even for regular DMARC due to privacy concerns, so there's almost no loss of feedback as a practical matter defining it this way. Consider what implementers would have to do in the alternative. In order to treat failure reports differently for single and multi-organizational PSDs, one would need to know which is which. While some, like .google are relatively obvious, other are much less so. It is much better to give clear guidance than to be handwavy. > I really think the guidance in 4.1 is the best way to approach this. > > Speaking of which, with the normative MUST NOT that's been added, now 4.1 > no longer makes any sense. Only if you assume that there are no privacy risks associated with aggregate reports, which I don't believe is accurate. I certainly wrote 4.1 on the assumption that it was mostly about aggregate reports, since failure reports are not commonly sent. > My recommendation would be to roll this change back, and perhaps replace it > with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless > you really really know what you're doing." I disagree. That puts the (potential) fox in charge of the hen house. > 3. psddmarc.org - I think we need a brief paragraph outlining the > experiment, and in it need to explicitly call out that a permanent solution > needs to be determined for answering the "what's a PSD" question - which > may or may not be psddmarc.org. I thought I'd done that in Appendix A. Please review and provide specific recommendations as I don't really know how to address this general comment. Other than the typo, I'm going to leave my local copy as is while we wait and see what others think. Scott K From nobody Thu May 9 10:35:49 2019 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 7617E12006A for ; Thu, 9 May 2019 10:35:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 C3Id4GOsPUAe for ; Thu, 9 May 2019 10:35:46 -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 2ABB612003E for ; Thu, 9 May 2019 10:35:46 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id 143so2545586oii.4 for ; Thu, 09 May 2019 10:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1XS9KSDBdB0vJYfJMmAdbBDgVJy+wcMRFrT05bTZoxI=; b=KfFOwxQkldF4B8sebwROplyRITZHd6lq3tMhUThJTb2miwIxlHGEqbK64PVUVvns1m G4p3d5kqcb5Qe/q5UFOhkMfOZ9lamCZfKhqjlevT2xNiYcn6M3BYl3lrid2GrwW+ylQD jtBfF/FR3Z4YTJ+wBFYStExAhvemxLObXBtYa61XeSiU9cusLKbpxiexMOBKYHoJZ1lX 5ZPIoYdaafc+1nOiLjkdcSXg1r+9CgGZevgSXVxHdyaxbxqxGrQMmIKVnSsNBVagSH4+ GmAbGztTVwVoiv/McQc4zc7Umul2Gu3ezxjZB/SW5M6VhOUekRglZhxt7M67MMbPwHRd mAGA== 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=1XS9KSDBdB0vJYfJMmAdbBDgVJy+wcMRFrT05bTZoxI=; b=Zg8U7N87Ae/qGpHRpsk29JTeq2reJdDCwfCwT+gyAlgo0UTsslAGHIc/i6DlAMUAY3 uBCkM7GdkvqFJrbZatRj8zygWymx7PVI4Q3QLzD2yWw26YL/iNMCAiw73I7R3tp21lfT JnzhWE6SCJjNnSx8L8a69+/SIO10hEoX+frzp2h5s22LtIdpwATmHcjVA0fnmgzXQn+D ixBeviNCDK2HOTJKsiK15cGIexcuMGm+79MIViylSi7j7yDxWcecbvYkUnNq+N9eVXzB rChqVvpsiTOCtcuTswGORKs8ri9hAjQGTKNOCxX//sb+btswKlNUIurILxj+PwJiZT0K p6pA== X-Gm-Message-State: APjAAAUA5zuRZ4Lp2bRkZaggh+kdI7fv07+Y4tZtf1tWoLSOj1QXdczI OSHlvf8miMnGFQcrsnQUwKRX8BE3K+ekdA1b8DnGDw+HtQU= X-Google-Smtp-Source: APXvYqxCdBSGHofpdXPduZEXaAWaKGvpxM1ZSRBBGssXXKIaaNQXAgDF0DhFKVnuToFaOOOeu2s2iZlPRSCA3WPCsn0= X-Received: by 2002:aca:378a:: with SMTP id e132mr2146524oia.171.1557423344715; Thu, 09 May 2019 10:35:44 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <2699063.PiBShnsfcX@l5580> <12992594.LUNhQVcRDa@l5580> In-Reply-To: <12992594.LUNhQVcRDa@l5580> From: Seth Blank Date: Thu, 9 May 2019 10:35:28 -0700 Message-ID: To: IETF DMARC WG Cc: Scott Kitterman Content-Type: multipart/alternative; boundary="0000000000003a2639058877e1ba" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Thu, 09 May 2019 17:35:48 -0000 --0000000000003a2639058877e1ba Content-Type: text/plain; charset="UTF-8" On Thu, May 9, 2019 at 9:39 AM Scott Kitterman wrote: > In theory, I agree, but in practice, I think the new MUST NOT is a great > change to promote implementation simplicity. This increases complexity. With this normative requirement, we're adding a third lookup that behaves differently than the previous two. This complicates the experiment and solidifies a (good) policy consideration normatively. > > Speaking of which, with the normative MUST NOT that's been added, now 4.1 > > no longer makes any sense. > > Only if you assume that there are no privacy risks associated with > aggregate > reports, which I don't believe is accurate. I certainly wrote 4.1 on the > assumption that it was mostly about aggregate reports, since failure > reports > are not commonly sent. > The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD. I thought I'd done that in Appendix A. Please review and provide specific > recommendations as I don't really know how to address this general comment. > You're absolutely right, you did. I do, however, think there's more to the PSD experiment than just deciding where a PSD list should live - the crucial bit is if this actually addresses and demonstrates value (i.e. stops spoofed email) for the use cases discussed in Section 1. --0000000000003a2639058877e1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 9, 2019 at 9:39 AM Scott Kitt= erman <sklist@kitterman.com&= gt; wrote:
In theory, I agree, but in practice, I think the new = MUST NOT is a great
change to promote implementation simplicity.

This increases complexity. With this normative requirement, we're add= ing a third lookup that behaves differently than the previous two. This com= plicates the experiment and solidifies a (good) policy consideration normat= ively.
=C2=A0
> Speaking of which, with the normative MUST NOT that's been add= ed, now 4.1
> no longer makes any sense.

Only if you assume that there are no privacy risks associated with aggregat= e
reports, which I don't believe is accurate.=C2=A0 I certainly wrote 4.1= on the
assumption that it was mostly about aggregate reports, since failure report= s
are not commonly sent.

The first bullet= of 4.1 is incorrect if RUF is MUST NOT for PSD.

I thought I'd done that in = Appendix A.=C2=A0 Please review and provide specific
recommendations as I don't really know how to address this general comm= ent.

You're absolutely right, you d= id.

I do, however, think there's more to the P= SD experiment than just deciding where a PSD list should live - the crucial= bit is if this actually addresses and demonstrates value (i.e. stops spoof= ed email) for the use cases discussed in Section 1.
--0000000000003a2639058877e1ba-- From nobody Thu May 9 14:24:01 2019 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 4CF331200FA for ; Thu, 9 May 2019 14:24:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 TjZztcVxrgDI for ; Thu, 9 May 2019 14:23:57 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 79D1A12016F for ; Thu, 9 May 2019 14:23:24 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id y25so3017110oih.11 for ; Thu, 09 May 2019 14:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VHcaRVnVIAmhir/vuWj09fGEJK8NmAGwHqHTvfpokfg=; b=Mgt7g2HwVR1og1NEzWNsHOU7k/dE9SAYEx61Bts9XmPcQHahv4Odw5bTqF5aHZw4Lh eqqg/Kq//PSxLtjYQzlCVThKnOKDlkQkLzhlmoceb2yTGnb9OQ+mVu2pbZdfkZhRd4N4 gGAeor98UPe7qPAHRcAnJrsrg/bob0u+4exbnGecbGSp/O4fE5/jthK+4VuO8pEsX75+ nRasLR5iUjkAvRdVBsDWMIIp0w2wmc2nT8Y/99qd26/Ycn4zTNZKR7BudKNHs+cgb5/K t8zHV3zFjb3IkBpbh77n85InSb+7LS5k4YHAJCZ14/m+u2kf/Jt+2pgiO4fJ2EdKXiCm rfFw== 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=VHcaRVnVIAmhir/vuWj09fGEJK8NmAGwHqHTvfpokfg=; b=mBdwSdvP7I4pqx02eNXC18p+Es04Etz9ouBnltQXK16lKaEFH2V5sDadyqzZ29H/y/ 8TIs2RKSHFLN5JYXdkmvN4HEssB+zNjGQX7IJVA1lypHfsUxaW0PGYAfD5JnLDqLCdaX deoxLYKyWeEJx+7PvpUR3aI6aS72FwxEqZA8oX8BfVUWKLipXvD4O/BiyShfcKSYS5O9 cofSm4ouXNcqq5WUcy7k0Krp5XsphUcTLJeMpOq33Zdjgw/U64fDyfJTmdZgDCG+whid 0AMuPRzm5zlhD84ATE7OpKBbDkhmebTkbX2vCKnG2UYDNX7UzsWATsdOkciIqUuucDNT jIyw== X-Gm-Message-State: APjAAAWQvD5qDf41o/kXFVGQ2HaC3lGTzDf4oLgoGsvKe8DOUeE8YTL0 9hdiEXkZ4sQ4DjUAFjrrQnaJMY1T9+C8YKCvXdHAIsTXrpGRug== X-Google-Smtp-Source: APXvYqyZm1AbAZGKIkHKNIeY1hWPBKktCn4oyGWormQaxhLNGsbKkHTyH2eL+IsZs3cxfa2E2Nqtt2EDJllaz49A1WI= X-Received: by 2002:aca:5344:: with SMTP id h65mr2897056oib.157.1557437003409; Thu, 09 May 2019 14:23:23 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Thu, 9 May 2019 14:23:07 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000059492205887b0fc7" Archived-At: Subject: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization 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, 09 May 2019 21:24:00 -0000 --00000000000059492205887b0fc7 Content-Type: text/plain; charset="UTF-8" With the group officially in Phase III of the DMARC WG charter, our work is now to explicitly review and refine the DMARC specification, with the goal of generating a standards track document. The draft-ietf-dmarc-psd experiment is part of this process, as is the conversation about defining proper ARC reporting XML for DMARC reports. This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you believe should be officially discussed as part of the DMARCbis process. Please start a separate thread for each item you have. I'll make sure all are properly in the issue tracker and get addressed. Please send in your items no later than *Friday, May 24th*. After this point, we'll be focusing on progressing the DMARCbis process, not gathering new issues. Below are a list of nits already in the datatracker. I'll be kicking off threads for several other issues I'm aware of shortly. Thanks everyone! Seth, as Secretary Active issues for DMARCbis in the data tracker: - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1 - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2 - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2 - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4 - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 - Fuzzy normative language around filenames: https://trac.ietf.org/trac/dmarc/ticket/6 - ABNF for dmarc-record is slightly wrong: https://trac.ietf.org/trac/dmarc/ticket/7 - Perverse incentives to use p!=none & pct=0: https://trac.ietf.org/trac/dmarc/ticket/22 - objection to maintaining registry for all participating public suffixes: https://trac.ietf.org/trac/dmarc/ticket/24 - Link to "URI" reference broken in several sections: https://trac.ietf.org/trac/dmarc/ticket/25 --00000000000059492205887b0fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With the group officially in Phase III of the DMARC WG cha= rter, our work is now to explicitly review and refine the DMARC specificati= on, with the goal of generating a standards track document.

The draf= t-ietf-dmarc-psd experiment is part of this process, as is the conversation= about defining proper ARC reporting XML for DMARC reports.

This ema= il is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you b= elieve should be officially discussed as part of the DMARCbis process. Plea= se start a separate thread for each item you have. I'll make sure all a= re properly in the issue tracker and get addressed.

Please send in y= our items no later than *Friday, May 24th*. After this point, we'll be = focusing on progressing the DMARCbis process, not gathering new issues.
=
Below are a list of nits already in the datatracker. I'll be kickin= g off threads for several other issues I'm aware of shortly.

Tha= nks everyone!

Seth, as Secretary

Active issues for DMARCbis i= n the data tracker:
- SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1
- Fl= ow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2
- Two tiny nits in 6.6.2= and 6.6.3: https://t= rac.ietf.org/trac/dmarc/ticket/2
- Definition of "fo" para= meter: https://trac.i= etf.org/trac/dmarc/ticket/4
- Definition of "pct" paramete= r: https://trac.ietf.= org/trac/dmarc/ticket/5
- Fuzzy normative language around filenames:= https://trac.ietf.or= g/trac/dmarc/ticket/6
- ABNF for dmarc-record is slightly wrong: https://trac.ietf.org/tr= ac/dmarc/ticket/7
- Perverse incentives to use p!=3Dnone & pct= =3D0: https://trac.i= etf.org/trac/dmarc/ticket/22
- objection to maintaining registry for= all participating public suffixes: https://trac.ietf.org/trac/dmarc/ticket/24
- Link to= "URI" reference broken in several sections: https://trac.ietf.org/trac/dmarc/ticket/= 25
--00000000000059492205887b0fc7-- From nobody Thu May 9 15:03:20 2019 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 5A3E6120128 for ; Thu, 9 May 2019 15:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=zeXaUxIZ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FSEr9CfN 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 Tm59QkQ1i6SY for ; Thu, 9 May 2019 15:03:17 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA7B12008A for ; Thu, 9 May 2019 15:03:17 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id E4B57F8074A for ; Thu, 9 May 2019 18:03:14 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1557439394; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5vuQere448l87zkiN5aCO5ffWk0sKXapEceBeQKyJZ4=; b=zeXaUxIZ29L95zJkR+xCObglDn1Pz3jIm+Sh77a1Ki5+FF5GxWOsSRWy oMc+iyUsbDBDstoliV9RdzWZXKQZBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1557439394; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5vuQere448l87zkiN5aCO5ffWk0sKXapEceBeQKyJZ4=; b=FSEr9CfN/pgkL4q2GzEvbkDs/8xylJqJzxGYokgwdTlXb9O+U3X5MLeM ZZJQsPj/0j4w1eslcehDhfKmyS7vIxWNlY10dNISzpnjvsHtkbiNFL+bdp 5UXmyaejB/NqJ/Bj86lUI4qL4advd/7tQd6TLce+dKt32RlGMUyAwYEEM2 putyiWpeRbfw2NKsLLwZXjcbZQg8uN6+eD3qvWJu5pHl888e2QDEbogldw e6pkddc4NUekTBzsG1cC3BsKdFMj6namulMCE+/nEd4IJvzhJCortwxyr/ jQHtrRXPiPZTYVmVppGLADiB3ZyJA8L25Hlbix7ez8enPnSj+YabOg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id ACB9AF80721 for ; Thu, 9 May 2019 18:03:14 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 09 May 2019 18:03:14 -0400 Message-ID: <1694180.CbOjR3XESQ@l5580> In-Reply-To: References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <12992594.LUNhQVcRDa@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Thu, 09 May 2019 22:03:20 -0000 On Thursday, May 9, 2019 1:35:28 PM EDT Seth Blank wrote: > On Thu, May 9, 2019 at 9:39 AM Scott Kitterman wrote: > > In theory, I agree, but in practice, I think the new MUST NOT is a great > > change to promote implementation simplicity. > > This increases complexity. With this normative requirement, we're adding a > third lookup that behaves differently than the previous two. This > complicates the experiment and solidifies a (good) policy consideration > normatively. Either way there's a consideration. If there's no MUST NOT, then any entity that does failure reporting needs to consider if they should do it for PSDs and if so, which ones. That's a question that, at best, has a squishy answer. If the MUST NOT is present, it's a straightforward processing change to not apply failure reporting if you got the result from a PSD lookup. Either way, entities that don't do failure reporting now, won't be affected (which is almost everyone). The changes to add PSD DMARC to an existing DMARC implementation are not complex, but they are required. A clean implementation requirement while you're updating related code it, IMO, much easier to deal with than vague policy guidance. > > > Speaking of which, with the normative MUST NOT that's been added, now > > > 4.1 > > > no longer makes any sense. > > > > Only if you assume that there are no privacy risks associated with > > aggregate > > reports, which I don't believe is accurate. I certainly wrote 4.1 on the > > assumption that it was mostly about aggregate reports, since failure > > reports > > are not commonly sent. > > The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD. I agree a small change is needed. If we leave it the way it is (with the MUST NOT), then it would be appropriate to add that the MUST NOT requirement fully mitigates the privacy concern as it relates to RUF. > > I thought I'd done that in Appendix A. Please review and provide specific > > > recommendations as I don't really know how to address this general > > comment. > > You're absolutely right, you did. > > I do, however, think there's more to the PSD experiment than just deciding > where a PSD list should live - the crucial bit is if this actually > addresses and demonstrates value (i.e. stops spoofed email) for the use > cases discussed in Section 1. I don't think so. We know technically that it can do so. There is no technical question in that regard, so nothing to experiment over. Will people use it isn't really the proper basis for an IETF experiment. The IETF publishes non-experimental RFCs all the time without any particular data to suggest the RFC will get implemented and deployed. I think how to get the privacy issue mitigation correct is the only technical issue that needs experimentation, but I may have missed something. Scott K From nobody Thu May 9 16:17:20 2019 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 0577E1200DF for ; Thu, 9 May 2019 16:17:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 jvIeKiWGNThi for ; Thu, 9 May 2019 16:17:16 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 580A91200DE for ; Thu, 9 May 2019 16:17:16 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id y10so3205780oia.8 for ; Thu, 09 May 2019 16:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=93OSlys9kEv2/YuEQYlvYsBmDrfb9If1u6PmOBpWiyQ=; b=Lcesu8k9BD/KMlglSYihFGNH62S4hK7i3Keo+Z6OS6rRrtc/5NCbLHRLDMYXxwn7sM jtxVwRkUfuT10m5+EuXuRyIhwYGS7wglAlk/vJ5U7DjY9eB9/3k9r3cXIOtTFZjeeNgi sYJO0RFZkWY0ju28d7pul6tgkEhw1OsKAhLr61RiETS9OODY7cTOtxHrIxzfPoDbLagA T6VPZ0qQhyq9t253ys+6V1pwqaR1BkbYn1kO3UvDBEJDj+bf3x23UN5q0KBWJbk6AC1v CnDGye7AsuKcy/v5yQNpu9R2vh14inu54k2f4scKrFoPItuS96dP/PJhOeNhVd4pBEvd t5/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; bh=93OSlys9kEv2/YuEQYlvYsBmDrfb9If1u6PmOBpWiyQ=; b=DHHcJC9C5XiJ56156F4kJba1PDR7/iN7izocOaDKfn46DyAfof9mBJZ/hAzQjD+KsZ spi9Z0DXSY19RayACHsPdprfYZktYJ+X8hjQJtumYUK33yCvDgXlsa4yYL1qr/9089Af gFraP7ezImNnebjXYqXpLDY3cxWDb+8ZQQaP1jJPkddg14dkVgW4QA+s7O7tAAP+P9NB uPhtTGbfw/jf9zKQZz+fpf/4NbESXicgOCgF/egHtNMuhofMs2BnTEkE+rmWymzPAJ/9 dN2Jf1jLctg1je4MiL+q5JVi4Sk/WDVqMdjU5vhmp5psgaZx4rlGtP3kSrYkKro79pIj k17w== X-Gm-Message-State: APjAAAV9bzSur5HejbWcq4GqigWuWfWjOM3xeBvobAPsfFrkQbS1jHRO 59kd9S5j2qGgTrQKDj2IxAsTjblVD7S8FefCA1h9UCVmLT4= X-Google-Smtp-Source: APXvYqzbuD9YaHKU30hKbsEc1bzswCuoCmxxqQfwU05JT9xdJhbdR1ZXiwvndOz1xiWCdjzTutDhNVSh4AIPSzYkFWE= X-Received: by 2002:aca:e8c5:: with SMTP id f188mr3087479oih.132.1557443835346; Thu, 09 May 2019 16:17:15 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <12992594.LUNhQVcRDa@l5580> <1694180.CbOjR3XESQ@l5580> In-Reply-To: <1694180.CbOjR3XESQ@l5580> From: Seth Blank Date: Thu, 9 May 2019 16:16:58 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000905fbd05887ca61c" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Thu, 09 May 2019 23:17:19 -0000 --000000000000905fbd05887ca61c Content-Type: text/plain; charset="UTF-8" On Thu, May 9, 2019 at 3:03 PM Scott Kitterman wrote: > If there's no MUST NOT, then any entity that does failure reporting needs > to > consider if they should do it for PSDs and if so, which ones. That's a > question that, at best, has a squishy answer. > I don't agree. It's up to the PSO, not the system generating reports, to determine which type of reports are wanted. The proposed registry is the control of who can even make a decision like this. If there were no registry and PSD functionality were open to all, then this would be a more concerning case. But the entire point of DMARC is that a receiving system doesn't need to guess - it's up to the domain owner to publish their policy. This flips that distinction on its head and says it's no longer up to the domain owner. To reiterate: This normative MUST NOT is a mistake from many different angles, as it: 1) codifies a policy decision that doesn't affect interoperability 2) adds complexity because reporting against the third lookup is now different than reporting for the other lookups 3) doesn't apply for all use cases (specifically, it would prevent .com from gathering RUF data, but also prevents .google from operating in the same manner as google.com) 4) reverses a key value of DMARC: giving control of policy to domain owners I strongly agree that RUF is potentially problematic here, and it would be better off if no one got it, but I really believe that's a policy decision for a domain owner / PSO (and a policy decision for who is allowed in a registry of PSOs), not something that should be normative in the spec. Seth --000000000000905fbd05887ca61c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 9, 2019 at 3:03 PM Scott Kitt= erman <sklist@kitterman.com&= gt; wrote:
If there's no MUST NOT, then any entity that does= failure reporting needs to
consider if they should do it for PSDs and if so, which ones.=C2=A0 That= 9;s a
question that, at best, has a squishy answer.

I don't agree. It's up to the PSO, not the system generating= reports, to determine which type of reports are wanted. The proposed regis= try is the control of who can even make a decision like this. If there were= no registry and PSD functionality were open to all, then this would be a m= ore concerning case.

But the entire point of DMARC= is that a receiving system doesn't need to guess - it's up to the = domain owner to publish their policy. This flips that distinction on its he= ad and says it's no longer up to the domain owner.

=
To reiterate:

This normative MUST NOT is a mi= stake from many different angles, as it:
1) codifies a policy dec= ision that doesn't affect interoperability
2) adds complexity= because reporting against the third lookup is now different than reporting= for the other lookups
3) doesn't apply for all use cases (sp= ecifically, it would prevent .com from gathering RUF data, but also prevent= s .google from operating in the same manner as google.com)
4) reverses a key value of DMARC: giving contro= l of policy to domain owners

I strongly agree that= RUF is potentially problematic here, and it would be better off if no one = got it, but I really believe that's a policy decision for a domain owne= r / PSO (and a policy decision for who is allowed in a registry of PSOs), n= ot something that should be normative in the spec.

Seth
--000000000000905fbd05887ca61c-- From nobody Fri May 10 04:06:46 2019 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 63EB612004E for ; Fri, 10 May 2019 04:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 Hyq6NeE9ur6r for ; Fri, 10 May 2019 04:06:41 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 67960120026 for ; Fri, 10 May 2019 04:06:41 -0700 (PDT) Authentication-Results: mail.aegee.org/x4AB6c1Q002306; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1557486398; i=dkim+MSA-tls@aegee.org; r=y; bh=fdy/O1BtCcJm1PpnUJ9nxq5cdrDEMdSOhFTtoOSWMBc=; h=Subject:From:To:Date:In-Reply-To:References; b=EHO6bYQSYBRQIBPQrq5KWZJe5cH8jvEok42GjX0JMxqWZ9Ajd1JGtGIWGVGAM2RUk dqD0irIAGmHo5M9MIsPapProDCs/WVDAoBfNYnyx3zBi80qY5zIN4p33OGcdXrXWvN RHB6jwc2lKYWNLuNb0p6NmRkadmaBYSmMT6ChaNydkVGR1aP3Qm6HQ2rih/n347anb Dohncv/dPp1tbiOvXpp4W/bLFS8A6RUmrg0JcXcJLVyvm+1ElfmShQ9Up9MVhR+mcp P276bP7w+0ifaS2gtn1TWbL+FHcXVNlc5h31QNWFIxWMuSxU+j6iquCJTrC6oFc2j+ JcPQgTs9rMPtE/psRIwZi/7g4nC8q5lNjUr2YGorCloyEmgW2V3NVrIJUTV0UpA34J rtODBXgmMIsFsjWIlQVILnXYmoT8UPXOx6gC3Qh1nl2Soq0hp3t9aVVyysI9wuKTBc yMUOtYErIEg5CcYbDHH9tiBXMVINnVIU1IEIOh+iqRy25CyA9oAWd9HGhfPdUG9ej3 76z9PS6TjLExH5b3kA7TAto3Ryis/ZS2G6SwP5Z6Wu8n93/u0l2mg9yUcrQnk8iQWP 0zgTereiZjeQvNOofshxcUvdYbLghHqfDUbm87+JtjpADjuT9HYLbGqkZP4HiM86dU x/vCguqBwM16nsI31wqt9peU= Authentication-Results: mail.aegee.org/x4AB6c1Q002306; dkim=none Received: from Tylan (eduroam-PAT.sit.fraunhofer.de [141.12.129.132]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x4AB6c1Q002306 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 10 May 2019 11:06:38 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Seth Blank , IETF DMARC WG Date: Fri, 10 May 2019 11:06:37 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization 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, 10 May 2019 11:06:45 -0000 Hello Seth, > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 The original email is https://mailarchive.ietf.org/arch/msg/dmarc/fRogXZnH2H9IEQyf_UXPx1_KLvE, which references section 5.3 of https://tools.ietf.org/html/draft-kucherawy-dmarc-base-09#section-5.3, which today https://tools.ietf.org/html/rfc7489#section-6.3 (Section 6.3 of RFC 7487). This might be also related to https://trac.ietf.org/trac/dmarc/ticket/22 , but it does not contain the word “testing” as purpose. My concerns: For the purpose of running a test system, one wants to receive all reports, individual or aggregate, whenever a problem appears. "p=quarantine; pct=1" would send a report whenever a problem appears, but has as side effect, that some bad emails (1%) will be quaratined. This test system is supposed to do MLM rewritings, just as normal NON-test system will do, in order to test the whole delivery chain. The combination to have a system, that just sends (individual or aggregate) reports on failures, which does not impact anyhow mail delivery, is “p=quarantine; pct=0;”. Currently it is not defined, what that last policy shall mean and there is not policy that just sends reports, but otherwise 100% delivers the emails properly. So "p=reject; pct=0;" just fits. Now, I do not recall if "p=none;", with or without pct does sends reports… ----- RFC 6651 defines r=y to send a report whenever a DKIM-Signature fails. When a MLM rewrites a mail, and changes From:, DMARC for the new email does validate, however the untouched DKIM-Signature fails. The current recommendation is to generate a report for the failed signature. This report is useless and distracts from useful reports. The report is useless, because the MLM intentionally broko the DKIM signature and there is nothing the sender of the email can do and also there is no way how this report can be tackled. So for DMARC to function fluently, there shall be no distracting DKIM reports. Whether this is DKIM or DMARC domain does not matter. The topic was discussed at ietf-dkim@ietf.org (https://mailarchive.ietf.org/arch/browse/ietf-dkim/) in Augist - October 2018. Regards Дилян On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote: > With the group officially in Phase III of the DMARC WG charter, our work is now to explicitly review and refine the DMARC specification, with the goal of generating a standards track document. > > The draft-ietf-dmarc-psd experiment is part of this process, as is the conversation about defining proper ARC reporting XML for DMARC reports. > > This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you believe should be officially discussed as part of the DMARCbis process. Please start a separate thread for each item you have. I'll make sure all are properly in the issue tracker and get addressed. > > Please send in your items no later than *Friday, May 24th*. After this point, we'll be focusing on progressing the DMARCbis process, not gathering new issues. > > Below are a list of nits already in the datatracker. I'll be kicking off threads for several other issues I'm aware of shortly. > > Thanks everyone! > > Seth, as Secretary > > Active issues for DMARCbis in the data tracker: > - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1 > - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2 > - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2 > - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4 > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 > - Fuzzy normative language around filenames: https://trac.ietf.org/trac/dmarc/ticket/6 > - ABNF for dmarc-record is slightly wrong: https://trac.ietf.org/trac/dmarc/ticket/7 > - Perverse incentives to use p!=none & pct=0: https://trac.ietf.org/trac/dmarc/ticket/22 > - objection to maintaining registry for all participating public suffixes: https://trac.ietf.org/trac/dmarc/ticket/24 > - Link to "URI" reference broken in several sections: https://trac.ietf.org/trac/dmarc/ticket/25 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed May 15 03:17:31 2019 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 6318C1202A4 for ; Wed, 15 May 2019 03:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIkzltFuPy7F for ; Wed, 15 May 2019 03:17:27 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505721202BB for ; Wed, 15 May 2019 03:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1557915444; bh=5bRtmSu985eKts4NGpskyGZrjanScWwhQGCiwoJYSvY=; l=2081; h=To:References:From:Date:In-Reply-To; b=CBLwf5qGmu54ahN41jN8i0wzPLpK+UmQz7Iuj1wh6+5H0HkG+v79PMkK/5yFavP5T fo/COBjSQter6NRTgpt8vQNj2DazRO/HMpopi4zgAdFc/HUrGAatXd7VjRcV3hhXgB qfRNC62H0RxfqHKBZzxLl1U/ysL4+Mw8nb3YWlCsPyZ+h9h6KZPA1X2kBZVuD Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 15 May 2019 12:17:24 +0200 id 00000000005DC077.000000005CDBE734.00007B0F To: dmarc@ietf.org References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <12992594.LUNhQVcRDa@l5580> <1694180.CbOjR3XESQ@l5580> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 15 May 2019 12:17:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 15 May 2019 10:17:30 -0000 On Fri 10/May/2019 01:16:58 +0200 Seth Blank wrote: > > To reiterate: > > This normative MUST NOT is a mistake from many different angles, as it: > 1) codifies a policy decision that doesn't affect interoperability > 2) adds complexity because reporting against the third lookup is now different > than reporting for the other lookups > 3) doesn't apply for all use cases (specifically, it would prevent .com from > gathering RUF data, but also prevents .google from operating in the same manner > as google.com ) > 4) reverses a key value of DMARC: giving control of policy to domain owners > > I strongly agree that RUF is potentially problematic here, and it would be > better off if no one got it, but I really believe that's a policy decision for > a domain owner / PSO (and a policy decision for who is allowed in a registry of > PSOs), not something that should be normative in the spec. In part I agree. However, RUF is potentially problematic in general. Whether and how to honor RUF requests deserves a better discussion in the DMARC specification. I certainly wouldn't send a non-redacted failure report to an unknown domain. That said, I agree that control of PSDs should be given to PSOs, by the same logic of bullet (4) above. On Thu 09/May/2019 18:39:13 +0200 Scott Kitterman wrote: > > I disagree. That puts the (potential) fox in charge of the hen house. > It is true that we cannot trust the generic domain owner. However, PSOs are somewhat more constrained by policies and contracts. In addition, their public DNS records are quite easy to check. Perhaps we could concede a little bit of trust to those foxes? In addition to Seth's "if you're a PSD, don't ask for RUF", I'd propose that multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage SHOULD publish a blank DMARC record, that is policy=none, no ruf, no rua. PSOs that violate those recommendations would not do so in a concealed or unanticipated way, but as an integral part of their legalities. Best Ale -- From nobody Wed May 15 04:24:33 2019 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 CEDE6120091 for ; Wed, 15 May 2019 04:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=7Tf15eGP; dkim=pass (2048-bit key) header.d=kitterman.com header.b=WjaxkDGd 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 BG6SsIgL8Uvu for ; Wed, 15 May 2019 04:24:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A533120047 for ; Wed, 15 May 2019 04:24:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id C69D4F80041 for ; Wed, 15 May 2019 07:23:00 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1557919380; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Sl9Wxi0KFqgGNELUysaiEhq2E7UZRe29qeWgX/1nFW0=; b=7Tf15eGP4C/0hz4VR99llRYU6/TN7Ls2B06Y7Ssy84QTPGBfKBXVdB/O 0KCHbygQVhvM0vxIsFEl42DJD9uHDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1557919380; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Sl9Wxi0KFqgGNELUysaiEhq2E7UZRe29qeWgX/1nFW0=; b=WjaxkDGd48WpkhmeZvt8F44TC8u1ZDyE9ShUrKVmtxh+Gg1ixKJPR6mA J19XSCeYgXrfNx7EvsmzxuH9hQBjE4fkK1v1wCIxhois5P6BMNiaKPet/o zwT9aUxlDFBXmuNJjBx+jn/XbhyUn9F74Utxa9/S2tEVzXmxm2kUxjodfS QNapBwFWBqQJ2qT5M1Lkzs+LG5aOq5FrKWnJwfEngyYTG4MH05AQjIgm2f ZmrGpjwZVWDnZcBTliaRxBelBbzwlL6R8o48fKLpqMiikHqjP+Cm6/ej6d 5JWJTzV5y/pvl/QwLw55O2HKhWBwf9+WvoVb6ZxHWISjgJDKMoMFhw== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 93CEFF8003E for ; Wed, 15 May 2019 07:23:00 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 15 May 2019 07:22:59 -0400 Message-ID: <3063446.ceL4kMytFt@l5580> In-Reply-To: References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 15 May 2019 11:24:32 -0000 On Wednesday, May 15, 2019 6:17:24 AM EDT Alessandro Vesely wrote: > On Fri 10/May/2019 01:16:58 +0200 Seth Blank wrote: > > To reiterate: > > > > This normative MUST NOT is a mistake from many different angles, as it: > > 1) codifies a policy decision that doesn't affect interoperability > > 2) adds complexity because reporting against the third lookup is now > > different than reporting for the other lookups > > 3) doesn't apply for all use cases (specifically, it would prevent .com > > from gathering RUF data, but also prevents .google from operating in the > > same manner as google.com ) > > 4) reverses a key value of DMARC: giving control of policy to domain > > owners > > > > I strongly agree that RUF is potentially problematic here, and it would be > > better off if no one got it, but I really believe that's a policy decision > > for a domain owner / PSO (and a policy decision for who is allowed in a > > registry of PSOs), not something that should be normative in the spec. > > In part I agree. However, RUF is potentially problematic in general. > Whether and how to honor RUF requests deserves a better discussion in the > DMARC specification. I certainly wouldn't send a non-redacted failure > report to an unknown domain. > > That said, I agree that control of PSDs should be given to PSOs, by the same > logic of bullet (4) above. > > On Thu 09/May/2019 18:39:13 +0200 Scott Kitterman wrote: > > I disagree. That puts the (potential) fox in charge of the hen house. > > It is true that we cannot trust the generic domain owner. However, PSOs are > somewhat more constrained by policies and contracts. In addition, their > public DNS records are quite easy to check. Perhaps we could concede a > little bit of trust to those foxes? > > In addition to Seth's "if you're a PSD, don't ask for RUF", I'd propose that > multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage > SHOULD publish a blank DMARC record, that is policy=none, no ruf, no rua. > PSOs that violate those recommendations would not do so in a concealed or > unanticipated way, but as an integral part of their legalities. There are multiple types of entities running PSDs under multiple sets of rules. I don't think it's nearly that simple. Transparency only helps moderate bad behavior where there are alternatives. Scott K > > Best > Ale From nobody Wed May 15 08:04:50 2019 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 011001200FB for ; Wed, 15 May 2019 08:04:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 gk4RdKyGwHZZ for ; Wed, 15 May 2019 08:04:46 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 B353C120099 for ; Wed, 15 May 2019 08:04:45 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id g18so267943otj.11 for ; Wed, 15 May 2019 08:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8keX/EVxzWuWdxFj7/Uf32tuT99CCK1pdlSaPT4WHbA=; b=ilYX7MnOgOJ0PfmjsxfRJtRWDjVaRBwqutEhyAD9itD6++HgAcnaZzBzAq2QyArFYL 5b9vAXXUmFAuliDaBaYcgpzNQtLYVTR34ImKNYO+g4j28uXK4A0BqQNqHK+llte6VmKc 9inNqpzvI3YRSmmB4ZoH6UMsXPEKemafu6w8MQGl82n/cCAZgEhKneb3pYNi3in6iiK9 9w7IRvCFhyLoX+M7eVekg9jkIPFX91/BRBd06GMkiI6WAjQNx7WXA+Mg/6Lzictbh78V jB/lcZDSOBWJq+xrtkOFUiMcnvKNjmmGmQxEfkawXk8sIi/iOPQu4hIYi5olO6gZwcd4 +2QA== 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=8keX/EVxzWuWdxFj7/Uf32tuT99CCK1pdlSaPT4WHbA=; b=MLyr6b4uWLu01gvohLkQpEJEAcr2pvTDCsUX0fP2XeQWqqqkCkTTNAYZqDlA1fi9eL SHLniIQKKjdJnsgBAWJUmVntqNQRW7n7YbPdWLtuepm14C+WCdis86JI8K++VPan1dRO UVlPe5p05ltK2CBa4kyKfCipo676OsLbARxR/OLmcrem/kZaDbaENi/Bbfg4zvL0uOG9 XCgsw8BORvH83lS33p4mUS+v2BS9noJMxICEF3OQzSpazc2SdQTcu8tJ3tsiNEXXGfn+ au0DiubOvHQrfRjgqazHhmPHWCcXuyZUx7niJ8gaUmE1XWl4ADirRg0eOHCAtYkwTx8p sYsw== X-Gm-Message-State: APjAAAUrzlpmtWlCWQniB4882Rs9iMSt17FCzGM6xhgA0wvVgtsNX5l0 2RDyfusG6I3B0LzhtNyfEx8Dbd30hNrCWhk/ioTpWg45cw0= X-Google-Smtp-Source: APXvYqwf2I4RoJwdPGsEaaMhfNOX4ayrmuRthlcjkCtmckbxFpJID5iT4Ibb+3jMzqMoFmzaxCkiiKeNEMTOaky5g1U= X-Received: by 2002:a9d:6548:: with SMTP id q8mr1777326otl.132.1557932684586; Wed, 15 May 2019 08:04:44 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <3063446.ceL4kMytFt@l5580> In-Reply-To: <3063446.ceL4kMytFt@l5580> From: Seth Blank Date: Wed, 15 May 2019 08:04:28 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003fedb80588ee78d2" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Wed, 15 May 2019 15:04:48 -0000 --0000000000003fedb80588ee78d2 Content-Type: text/plain; charset="UTF-8" On Wed, May 15, 2019 at 4:24 AM Scott Kitterman wrote: > There are multiple types of entities running PSDs under multiple sets of > rules. I don't think it's nearly that simple. Transparency only helps > moderate bad behavior where there are alternatives. > Agreed. Which is why I think litigating behavior of failure reports is a separate matter for the working group, and we shouldn't shim new normative behavior into the PSD draft. That said - I'm still unclear if anyone agrees with me or if I'm the lone person concerned about this, in which case I'll gladly shut up. Regardless, I believe this document is ready for WGLC and we should proceed with it. Seth --0000000000003fedb80588ee78d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 15, 2019 at 4:24 AM Scott Kit= terman <sklist@kitterman.com= > wrote:
There are multiple types of entities running PSDs un= der multiple sets of
rules.=C2=A0 I don't think it's nearly that simple.=C2=A0 Transpare= ncy only helps
moderate bad behavior where there are alternatives.
Agreed. Which is why I think litigating behavior of failure re= ports is a separate matter for the working group, and we shouldn't shim= new normative behavior into the PSD draft.

That s= aid - I'm still unclear if anyone agrees with me or if I'm the lone= person concerned about this, in which case I'll gladly shut up. Regard= less, I believe this document is ready for WGLC and we should proceed with = it.

Seth
=C2=A0
--0000000000003fedb80588ee78d2-- From btv1==038c6b43ae9==fosterd@bayviewphysicians.com Wed May 15 07:10:02 2019 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 EE37A1200E0 for ; Wed, 15 May 2019 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 LU9jM3UDb-yP for ; Wed, 15 May 2019 07:10:00 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B49C12008C for ; Wed, 15 May 2019 07:10:00 -0700 (PDT) X-ASG-Debug-ID: 1557929398-11fa3116c876920001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id b3eWKl6Hfm0oVmq8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 15 May 2019 10:09:58 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=VHik2L4R7ghc3urkqQfCO4zXWa4W0lYu05t7jzQT+4U=; b=PpkMm1k5WZCA4exIzErJzgIUCQ1Zhud6wBfTAdomDokN1687TdEq+Z5xK48IpNZyD jJsPTAsbWST5AaPSAXlKvyBKnxG3oTYeE7AzL6tEFD1WtgmykQeYGhSSfC/Nbu4ul dB4jWXdS77qbsPRGbWBlmGzpjeMZ3kx2tI24ONTc4= Received: from MSA189 (MSA-189.BayviewPhysicians.com [192.168.2.186]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 15 May 2019 10:09:49 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.186 To: "'Dave Crocker'" , "'IETF DMARC WG'" References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> In-Reply-To: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> Date: Wed, 15 May 2019 10:09:49 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DNS library queries for DKIM and DMARC records? Message-ID: <000401d50b27$dbb5c310$93214930$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGE87zGQqFmYF+UdAorhwgBp28/zacMXB7g X-Exim-Id: 000401d50b27$dbb5c310$93214930$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1557929398 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2838 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? 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, 15 May 2019 15:26:57 -0000 I have recently begun evaluating my incoming traffic for DKIM status, and I suspect the results are relevant to your question. These results are based on 768 unique domains, on signed messages, received over a few adjacent days. Messages that were blocked for any reason are excluded from the analysis. (I am not blocking based on DKIM status). 22 2.9% have DKIM signatures but fail verification 100% 15 2.0% have some DKIM verification failures 7 0.9% have 100% rejection due to DNS record syntax errors 1 0.1% have some rejections due to DNS record syntax errors 10 1.3% have 100% DKIM TXT lookup failures 1 0.1% have some DKIM TXT lookup failures --- ---- 57 7.3% have DKIM problems This failure rate is much higher than I would have expected. When DKIM verification failures are detected, several possibilities must be considered: - an error exists in the signature generation algorithm at the source system - modification or addition of a signed header during transit - an error exists in the signature verification algorithm at the receiving system We receive very little indirect mail, so I believe that forwarding is not a significant contributor to these problems. For this type of debugging, it would be helpful if the receiving system logged the message exactly as it was used for signature verification. This would permit independent verification using a tool such as the message header checker at MxToolbox.com. For the devices that I manage, this is not the case. Some of the devices do not log the full message at all. The one that does full logging only logs the message as it is relayed outbound. My research also exposed a probable data-related bug on one mail server, which causes it to generate incorrect signatures on a small percentage of our outbound traffic. I will be working with the vendor on that. Doug Foster -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, April 10, 2019 3:37 PM To: IETF DMARC WG Subject: [dmarc-ietf] DNS library queries for DKIM and DMARC records? Folks, Howdy. I'm trying to get a bit of education about reality. Always dangerous, but I've no choice... For the software you know about, how are queries to the DNS performed, to obtain the TXT records associated with DKIM and/or DMARC? I'm trying to understand the breadth and limitations of returned information that is filtered or passed by the code that is actually in use. Which libraries and which calls from those libraries. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu May 16 07:06:34 2019 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 8E9781200EC for ; Thu, 16 May 2019 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=oracle.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 O_tdpO-yW_eJ for ; Thu, 16 May 2019 07:06:30 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 280EF12008F for ; Thu, 16 May 2019 07:06:30 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4GDs0AI090765; Thu, 16 May 2019 14:06:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=yM07u5c65TKjkjQAdWKZAfpGbGHfDEIw/b9u+9WgFbM=; b=nDKMFLQ6Xc+4dFCrWgILols9pPKkYeh3RwEx8FubogjU0Zcmvvw5k6m7TkfFqs2bHnZT aRNrcV7BaNXuBg7tCJ2UmE2Cr3x4VYcwWKPX0CcBCYpS1ucTkGBj6MM+buL0J2ZSIrk4 YrUtaBIQ+8m63h1WZqyo3AbYvTpRs0G3ZXOD9w5aYgBIkK2khKKLd9wJP1yCjjEpUKCD seqR24dMx5XgDlL/ksC5SOjHORpLfLRFYvoMhFTWEiL/dgwULFgOm2bLuKrG+o4kjL2E RQEOOMo6JDF5hi1ps0PMxC+A723AUewyNTciHh1U8c8KUKdC9YitUHWKIOogdri0XUAr mg== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2sdntu3p9j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 May 2019 14:06:25 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4GE6Fbt070642; Thu, 16 May 2019 14:06:25 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2sgkx43q60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 May 2019 14:06:24 +0000 Received: from abhmp0022.oracle.com (abhmp0022.oracle.com [141.146.116.28]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4GE6NS2009903; Thu, 16 May 2019 14:06:23 GMT Received: from [10.39.240.74] (/10.39.240.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 May 2019 14:06:23 +0000 From: "Chris Newman" To: "Doug Foster" Cc: "Dave Crocker" , "IETF DMARC WG" Date: Thu, 16 May 2019 10:06:18 -0400 X-Mailer: MailMate (1.12.4r5594) Message-ID: <49301D00-1881-4A86-B7E5-AC0B6272B34B@oracle.com> In-Reply-To: <000401d50b27$dbb5c310$93214930$@bayviewphysicians.com> References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> <000401d50b27$dbb5c310$93214930$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9258 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160092 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9258 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160092 Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? 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, 16 May 2019 14:06:33 -0000 If you're doing this analysis, I think it may be helpful to the = community if you share test vector messages. Data variations that = trigger a bug in one implementation might cause issues with other = implementations and thus may be helpful as a public test vector to = improve overall implementation quality. - Chris On 15 May 2019, at 10:09, Doug Foster wrote: > I have recently begun evaluating my incoming traffic for DKIM status, = > and I > suspect the results are relevant to your question. > > These results are based on 768 unique domains, on signed messages, = > received > over a few adjacent days. Messages that were blocked for any reason = > are > excluded from the analysis. (I am not blocking based on DKIM status). > > 22 2.9% have DKIM signatures but fail verification 100% > 15 2.0% have some DKIM verification failures > > 7 0.9% have 100% rejection due to DNS record syntax errors > 1 0.1% have some rejections due to DNS record syntax errors > > 10 1.3% have 100% DKIM TXT lookup failures > 1 0.1% have some DKIM TXT lookup failures > --- ---- > 57 7.3% have DKIM problems > > This failure rate is much higher than I would have expected. > > When DKIM verification failures are detected, several possibilities = > must be > considered: > - an error exists in the signature generation algorithm at the source = > system > - modification or addition of a signed header during transit > - an error exists in the signature verification algorithm at the = > receiving > system > > We receive very little indirect mail, so I believe that forwarding is = > not a > significant contributor to these problems. > > For this type of debugging, it would be helpful if the receiving = > system > logged the message exactly as it was used for signature verification. = > This > would permit independent verification using a tool such as the message > header checker at MxToolbox.com. For the devices that I manage, this = > is > not the case. Some of the devices do not log the full message at = > all. The > one that does full logging only logs the message as it is relayed = > outbound. > > My research also exposed a probable data-related bug on one mail = > server, > which causes it to generate incorrect signatures on a small percentage = > of > our outbound traffic. I will be working with the vendor on that. > > Doug Foster > > > > > > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker > Sent: Wednesday, April 10, 2019 3:37 PM > To: IETF DMARC WG > Subject: [dmarc-ietf] DNS library queries for DKIM and DMARC records? > > Folks, > > Howdy. > > I'm trying to get a bit of education about reality. Always dangerous, = > but > I've no choice... > > > For the software you know about, how are queries to the DNS performed, > to obtain the TXT records associated with DKIM and/or DMARC? > > I'm trying to understand the breadth and limitations of returned > information that is filtered or passed by the code that is actually in > use. Which libraries and which calls from those libraries. > > > Thanks. > > d/ > > -- = > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_dmarc&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DgrA_44LyxvKqiGT= JiOi4rnAkWUvPWq5Awl5rt-CqST0&s=3DPGbGkqcDa8b82pmdZS8i0mfVHJnKbSANGptAyHze= Etc&e=3D > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_dmarc&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DgrA_44LyxvKqiGT= JiOi4rnAkWUvPWq5Awl5rt-CqST0&s=3DPGbGkqcDa8b82pmdZS8i0mfVHJnKbSANGptAyHze= Etc&e=3D From nobody Sun May 19 22:32:12 2019 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 AF6C312006A for ; Sun, 19 May 2019 22:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 A3jebrRHVkEF for ; Sun, 19 May 2019 22:32:08 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 77A85120041 for ; Sun, 19 May 2019 22:32:08 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id v18so9314209lfi.1 for ; Sun, 19 May 2019 22:32:08 -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=pZK4++LUBAvfq/V9hSe4kPetf+1ZoNwZfuHyHm/6fZU=; b=TjjSd8jMMG9eYTIQpx01rez/cvjKpGF1ajPiQJ8ihg25zYCOlVV5Z0pAbCEyHAOzsX oLEoRUptptvL2IZ6i8QO4R/PhO9MJIK9blkCGZE9vPh4qESGXg8O2K3PuH4NFCkuhu4S dgFW9G+xqicjsyVZGFxixUChcQmCAD2C1fnqKGRVa5oe+TOuXRBjvkTmQcZHwfG5k7mg EpWI7eYLzmVO9qa7GCB1ET4VscPdtGhFlIR0LUUxb/mVMXD/nuS6DoeKolbYTHWsgOmi fJsFQ4Hy3dCG1M+tem/U0Fz62W3h29+0RLfoVF8uucN/cnWg/uwqGziUyAeRJpSRXKoF cMBQ== 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=pZK4++LUBAvfq/V9hSe4kPetf+1ZoNwZfuHyHm/6fZU=; b=sviKVIXzneSU6GC6lPa3nHoG74FT5nIIlKsqrud0BJSi57+s98p+O39i07FO7SYAvd jME7NDjpnh6vZ8XJMgXSWxFkGPr6Mubc+qxUQ9ctJIhn9elJ8BvFIXPuDdYrT4g5I88N PUcJrlZhuJtRIR2iF2iWVwn2ZpiiDkw485hJS7o7Z8wyvPM9NXCwnOP94gxj6tWvh0KW wzdptpsDCwhFTtMGrOHXa0pUCtJt0aSlZ3uTyaoMiM+day0EFwQTnPLozS5oo22MTKdO YRh+PFiiPNk6eB+Xx1uwwkUTBNW0ZPETHclZ34LOBFUtpqFXDie72kLpSYDvaW5C25K0 tNCw== X-Gm-Message-State: APjAAAWSA3R63OpG4RboA6r3fmMZKOg/RRDYSNLnwu610jfT/7pCdxrI gigS4TIQUwgaDJSnp0dgpbCyP8Pg+GR5UHu4MAs= X-Google-Smtp-Source: APXvYqyblvsEnSRzUMeOxju2oYJQ33nwKC/mr/D6jbQd6usBwLRguZxUGkX3bQ5pHibRD3isrx1bw5HrJX/j/CMhArI= X-Received: by 2002:ac2:5935:: with SMTP id v21mr24705810lfi.117.1558330326609; Sun, 19 May 2019 22:32:06 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <2699063.PiBShnsfcX@l5580> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 19 May 2019 22:31:53 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008f739e05894b0dca" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Mon, 20 May 2019 05:32:11 -0000 --0000000000008f739e05894b0dca Content-Type: text/plain; charset="UTF-8" Hatless: On Tue, May 7, 2019 at 7:30 PM Seth Blank wrote: > 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would > mean .example couldn't receive failure reports the way example.com does. > For something like .bank or .com, this is a feature. But for a .google, > this is a bug. I really think this MUST NOT is, while well advised, delving > into policy and not interop. > I've read Scott's replies to this as well. The question I have is whether we have consensus to include this change, but that's hard to gauge when there's been so few names offering comments. I'm partial to using MUST NOT only where it goes to interoperability, so I'm inclined to agree with Seth. However, I've been nudged away from that position on this in the past, i.e., that it can be used to encourage best practices and there's ample precedent for such. Still, given other replies on the topic, especially the presence of "unless you know what you're doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT with an explanation of why, and in what circumstances one would deviate from that advice. There are aspects of the discussion in this thread that would be valuable to implementers (summarized, of course). I'm also inclined to agree with Seth on his points of complexity, and on moving contrary to DMARC's tenets. Having said all of that, I'm not firmly resisting given that the plan is to send this up as Experimental, as its deployment and results could usefully inform our choices with respect to standards track DMARC. While you all stew on that, I owe the group a top-down review of it and the start of a shepherd write-up, so I'll do both this week. -MSK --0000000000008f739e05894b0dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hatless:

On Tue, May 7, 2019 at 7:30 PM Seth Blank <seth@sethblank.com> wrote:
2. In Section 3.5, I'm concerned with the normative MUST NOT. This= would mean .example couldn't receive failure reports the way example.com does. For somethi= ng like .bank or .com, this is a feature. But for a .google, this is a bug.= I really think this MUST NOT is, while well advised, delving into policy a= nd not interop.

I've read Scott&#= 39;s replies to this as well.=C2=A0 The question I have is whether we have = consensus to include this change, but that's hard to gauge when there&#= 39;s been so few names offering comments.

I'm partial= to using MUST NOT only where it goes to interoperability, so I'm incli= ned to agree with Seth.=C2=A0 However, I've been nudged away from that = position on this in the past, i.e., that it can be used to encourage best p= ractices and there's ample precedent for such.=C2=A0 Still, given other= replies on the topic, especially the presence of "unless you know wha= t you're doing" in some of the dialog, I'm wondering why this = isn't a SHOULD NOT with an explanation of why, and in what circumstance= s one would deviate from that advice.=C2=A0 There are aspects of the discus= sion in this thread that would be valuable to implementers (summarized, of = course).

I'm also inclined to agree with Seth on hi= s points of complexity, and on moving contrary to DMARC's tenets.
=

Having said all of that, I'm not firmly resisting g= iven that the plan is to send this up as Experimental, as its deployment an= d results could usefully inform our choices with respect to standards track= DMARC.
While you all stew on that, I owe the group a top-down re=
view of it and the start of a shepherd write-up, so I'll do both this w=
eek.
-MSK
--0000000000008f739e05894b0dca-- From nobody Mon May 20 01:39:54 2019 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 DF6FE120157 for ; Mon, 20 May 2019 01:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tip4e7JSRMlW for ; Mon, 20 May 2019 01:39:51 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 012F2120154 for ; Mon, 20 May 2019 01:39:50 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id t5so10720360wmh.3 for ; Mon, 20 May 2019 01:39:50 -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=Q2wmgk7FOmWq/98z0jKo4ux8Y7vQQiacXmR3W6n4qaM=; b=mCpa48vj9aBOy1AZZgmdoCcjrBZ411QVLvNvHOrEkyE6og2RtMWD/Yr2uoFfZyQy0e Lo/O4Ko3ybdV1WwT0HYGtv1DYhblnKuLWEu9C5V3Kjl/xW4AhaaEh+TrK8nwDIDT+RIa QsbQjSXSjKU88ybw8SGdw+bHcxzv1fuGghZXZZOx129+rVxh3epIGz0Do95YrImEZfLS kHkLh1lGMnL8LQnOZG4xRwoz8olP8eOZG3ccXdPN/p0fsphrROfJp25UWhTTeLxyWO0U JVgi2LTuZG2RTwqnDbhk6iLRL6YVDN34yFyitk3e75DCKsCVJk+mrjMEGQxXt4ivxoT7 MZow== 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=Q2wmgk7FOmWq/98z0jKo4ux8Y7vQQiacXmR3W6n4qaM=; b=PNZ13ypSzpn2SedMPNEncVKFcperoa6EmryyKha5/w5TwRBtuT9SZn4J378ucoHWU6 dhlUS/h/feWV8S3TlZNgf2bw6twsOMA4kdhOj6T0dYVQSvtilZ+3xk5fOLZk8JBfgi02 syRAHbaSgljgjWTQaPcyek6rxMq/DrhEcAEu0t7WE91OFa5EaQifvb2NUSmWraVvq9sY eP4EpyMDdGXacI/qVKuZ7f/IqmfmVOupAcbP0mwuk7Alrif4DleaOfnaqpnyq3pCg2lj 8Rvmen1SKonK6t/bhbkUpiOsAiPtE9Nhbl7XrBCHQY1DMMdcjjnLmNoFpj3aif3CuP/F zDhQ== X-Gm-Message-State: APjAAAWYyypNLSbtSrEa1z0BRbm5qCPuOtX9bqQAQhY+x5ndRvDfoQCt eoMbNqjErmIjOxM+doNeh4/DTXfAJu/YYAypnhI= X-Google-Smtp-Source: APXvYqw1nKAcasABT9QENTVBTsNvNEWIQBCbIwtSfZTm9SSCpZozhMB7mrT3aHJeTB1UCyqkEnrOR4/3C6I9fqjmV9Y= X-Received: by 2002:a1c:a815:: with SMTP id r21mr17130919wme.66.1558341589559; Mon, 20 May 2019 01:39:49 -0700 (PDT) MIME-Version: 1.0 References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <2699063.PiBShnsfcX@l5580> In-Reply-To: From: Dotzero Date: Mon, 20 May 2019 04:39:39 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e26c2605894dac56" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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: Mon, 20 May 2019 08:39:53 -0000 --000000000000e26c2605894dac56 Content-Type: text/plain; charset="UTF-8" I also lean towards Seth's perspective. Additional comments in-line. On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy wrote: > Hatless: > > On Tue, May 7, 2019 at 7:30 PM Seth Blank wrote: > >> 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would >> mean .example couldn't receive failure reports the way example.com does. >> For something like .bank or .com, this is a feature. But for a .google, >> this is a bug. I really think this MUST NOT is, while well advised, delving >> into policy and not interop. >> > > I've read Scott's replies to this as well. The question I have is whether > we have consensus to include this change, but that's hard to gauge when > there's been so few names offering comments. > > I'm partial to using MUST NOT only where it goes to interoperability, so > I'm inclined to agree with Seth. However, I've been nudged away from that > position on this in the past, i.e., that it can be used to encourage best > practices and there's ample precedent for such. Still, given other replies > on the topic, especially the presence of "unless you know what you're > doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT > with an explanation of why, and in what circumstances one would deviate > from that advice. There are aspects of the discussion in this thread that > would be valuable to implementers (summarized, of course). > I agree with avoiding MUST NOT in this case for the reasons given (policy vs interoperability). I think SHOULD NOT with explanation of why might be acceptable. > > I'm also inclined to agree with Seth on his points of complexity, and on > moving contrary to DMARC's tenets. > > Having said all of that, I'm not firmly resisting given that the plan is > to send this up as Experimental, as its deployment and results could > usefully inform our choices with respect to standards track DMARC. > > > Michael Hammer --000000000000e26c2605894dac56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also lean towards Seth's perspective. Additional com= ments in-line.


On Mon, May 20, 2019 at 1:32 AM Murray S= . Kucherawy <superuser@gmail.com<= /a>> wrote:

2. In Section 3.5, I'm concerned with th= e normative MUST NOT. This would mean .example couldn't receive failure= reports the way example.c= om does. For something like .bank or .com, this is a feature. But for a= .google, this is a bug. I really think this MUST NOT is, while well advise= d, delving into policy and not interop.

I've read Scott's replies to this as well.=C2=A0 The question I = have is whether we have consensus to include this change, but that's ha= rd to gauge when there's been so few names offering comments.

I'm partial to using MUST NOT only where it goes to interopera= bility, so I'm inclined to agree with Seth.=C2=A0 However, I've bee= n nudged away from that position on this in the past, i.e., that it can be = used to encourage best practices and there's ample precedent for such.= =C2=A0 Still, given other replies on the topic, especially the presence of = "unless you know what you're doing" in some of the dialog, I&= #39;m wondering why this isn't a SHOULD NOT with an explanation of why,= and in what circumstances one would deviate from that advice.=C2=A0 There = are aspects of the discussion in this thread that would be valuable to impl= ementers (summarized, of course).

I agree with avoiding MUST NOT in this case for the reasons given = (policy vs interoperability). I think SHOULD NOT with explanation of why mi= ght be acceptable.

I'm also inclined to agree with Seth on his po= ints of complexity, and on moving contrary to DMARC's tenets.

Having said all of that, I'm not firmly resisting given= that the plan is to send this up as Experimental, as its deployment and re= sults could usefully inform our choices with respect to standards track DMA= RC.
<=
br>

Michael Hammer=C2=A0<= /div>
--000000000000e26c2605894dac56-- From nobody Mon May 20 21:40:18 2019 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 B8F2412011C for ; Mon, 20 May 2019 21:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=7vRfw5ml; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CCjG2aeo 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 lQK6o2REY0SH for ; Mon, 20 May 2019 21:40:13 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826DD12004B for ; Mon, 20 May 2019 21:40:13 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 66E61F8080B for ; Tue, 21 May 2019 00:40:12 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1558413612; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nghFTBU7TT0LSkRZp+Ck0VpraqrDEEgUumyj8FLJUIA=; b=7vRfw5mlbtR/3qffVOJ65jfGp23rKsnihdmITiIJLNbVwRLzMsBx/tHg 9ec0Xs1O3zLMPB2haVfArfYUcW6zCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1558413612; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nghFTBU7TT0LSkRZp+Ck0VpraqrDEEgUumyj8FLJUIA=; b=CCjG2aeoDS2lNgtqHuEadoSxw+Ig7BEdGu3902LLMK8gr8DLuN2j0Pl3 dYhteAYrYFHh/J8MFhCHit6hR7pNBbKCZTyn4Nun1z34Yn/05e6epWqrgX x7IipjTjHGP5EVW5/uuJnWEjNGzFH+zYbbxBSWgd85+Hr+DrFivtArHEXg qgUPXN2DJu897znfNkWENwjkP+B4xoLIDe3ksSUgdjXDFGrUUR/n4BU22P bD6w3jh8OVsUGrllu3/KN9cnM1bmSEhQ8pt1uCQk45RI9y7zNNAanbzIk4 LqR3wGyzo5AtrU50HbX5qJqHYeo7PbD/HfwuLIm0634Ogbwdqer1tQ== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 3354FF800DE for ; Tue, 21 May 2019 00:40:12 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 21 May 2019 00:40:11 -0400 Message-ID: <389606103.N89IVunuJi@l5580> In-Reply-To: References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.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, 21 May 2019 04:40:16 -0000 On Monday, May 20, 2019 4:39:39 AM EDT Dotzero wrote: > I also lean towards Seth's perspective. Additional comments in-line. > > > On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy > > wrote: > > Hatless: > > > > On Tue, May 7, 2019 at 7:30 PM Seth Blank wrote: > >> 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would > >> mean .example couldn't receive failure reports the way example.com does. > >> For something like .bank or .com, this is a feature. But for a .google, > >> this is a bug. I really think this MUST NOT is, while well advised, > >> delving > >> into policy and not interop. > > > > I've read Scott's replies to this as well. The question I have is whether > > we have consensus to include this change, but that's hard to gauge when > > there's been so few names offering comments. > > > > I'm partial to using MUST NOT only where it goes to interoperability, so > > I'm inclined to agree with Seth. However, I've been nudged away from that > > position on this in the past, i.e., that it can be used to encourage best > > practices and there's ample precedent for such. Still, given other > > replies > > on the topic, especially the presence of "unless you know what you're > > doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT > > with an explanation of why, and in what circumstances one would deviate > > from that advice. There are aspects of the discussion in this thread that > > would be valuable to implementers (summarized, of course). > > I agree with avoiding MUST NOT in this case for the reasons given (policy > vs interoperability). I think SHOULD NOT with explanation of why might be > acceptable. > > > I'm also inclined to agree with Seth on his points of complexity, and on > > moving contrary to DMARC's tenets. > > > > Having said all of that, I'm not firmly resisting given that the plan is > > to send this up as Experimental, as its deployment and results could > > usefully inform our choices with respect to standards track DMARC. > > Michael Hammer Having read the feedback from a number of people, I am inclined to revert the MUST NOT that I added in the last revision. "Don't unless you know what you are doing" pretty generally applies to RUF, so I can see it being reasonable to not special case it here. I'll wait to see if anyone else has any other changes we should make before posting an updated draft. Scott K From nobody Thu May 23 13:36:02 2019 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 49CD512012A for ; Thu, 23 May 2019 13:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 f2pBa__ogmya for ; Thu, 23 May 2019 13:35:59 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 4F980120033 for ; Thu, 23 May 2019 13:35:59 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4NKZr4i029750 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 23 May 2019 13:35:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558643758; bh=MPdhp3AxGjYqG1hJ1HMZMKaiBcMZUysX5H8IWiaXX5o=; h=To:From:Subject:Date; b=Z5w2W5lXt1AMJ34dRbmtJwoB5VYOa90iDabd320zWZYLWHsvSOuiopX0J+915pkD1 Q5XYgWMUwHsZodeUzSW2Y696UpxGF8c8pfpPoTCsPeB11TZ6tN+YrPSxRAEgAjp2VZ unQHxVVe9dWiEyuAdb0AzJuF9nF0yRnuMswBZH/c= To: "dmarc@ietf.org" From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> Date: Thu, 23 May 2019 13:35:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 23 May 2019 20:36:01 -0000 In response to Seth Blank's call for issues of 9 May 2019: DMARC contains what are really two distinct mechanisms, a reporting mechanism and a policy mechanism. The policy mechanism is largely a request to the verifier about what to do in the event that a message is received that does not comply with policy. There are domains that would like to receive reports, but whose usage of mail doesn't make it useful to express a policy. Conversely, there are domains that want to express a policy but aren't interested in reports. I'd like to advocate that DMARC be split up into two different documents dealing with reporting and policy separately. If it's useful to have a separate document that defines what it means to be "DMARC-compliant" that is referenced by both, that would be OK. There was a similar situation with MTA-STS which had both a policy and a reporting mechanism, and that was broken into two standards-track RFCs: RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport Security). I consider this to be a relevant precedent. -Jim From nobody Thu May 23 15:52:18 2019 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 B3B4512006B for ; Thu, 23 May 2019 15:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gTvhwa7/; dkim=pass (1536-bit key) header.d=taugh.com header.b=TeLti11t 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 e-xwyKCSPMQB for ; Thu, 23 May 2019 15:52:16 -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 CEBDC120058 for ; Thu, 23 May 2019 15:52:15 -0700 (PDT) Received: (qmail 5207 invoked from network); 23 May 2019 22:52:14 -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; s=1453.5ce7241e.k1905; i=johnl-iecc.com@submit.iecc.com; bh=sdn7dKkHUY9mZ5YZl8Xs33f4acDuvs1PB9HcLiJI38c=; b=gTvhwa7/fEJtdhxGxWyu8Cac7O631HC//8wiRRC0w4MDlI69libwGf1T4/A693VlpJwq9DPxN01GMp8eRDQKYGctUyBk6IA+JykMNRpGY+kW+ATc2AZK2Si+8Cs/GbeZNZgLEwE0mve0OfZyX0KBV9LGxiF3WQVcL0BDrb4aHV2faWLV8hAQXqtDE/1SUA6IuUO/eGKjRaj4BFTfkZbWx8yvT+92zBoXWjJnhAfNIsWP0ojJUPHLHmydFQ62SL3i 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; s=1453.5ce7241e.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=sdn7dKkHUY9mZ5YZl8Xs33f4acDuvs1PB9HcLiJI38c=; b=TeLti11tocQZrCaX8aDKTJGreQZDJ5Vqj4QXfr3BLb3eTkkec5EgdAKMIwGYM/qEuq6sxI7+uXDbbKf0+ywwowcZucfUCPHWRSoWUNbY41CSPqQ51z/U96jWzyL01J8aEgNPKVzZXBOQIjXAXg7eRw0A9ntcHxQFCM7Fz6abDgn6DtdUhrPYK1uL5OGJlfjreFq1OD0XH672CYuxBQJqDQv7CBKfZmMtaImENUTZmWDs2Eg+iEiP8kdv03JMEDCI Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 23 May 2019 22:52:14 -0000 Received: by ary.qy (Postfix, from userid 501) id C214620147B780; Thu, 23 May 2019 18:52:13 -0400 (EDT) Date: 23 May 2019 18:52:13 -0400 Message-Id: <20190523225213.C214620147B780@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: fenton@bluepopcorn.net In-Reply-To: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 23 May 2019 22:52:18 -0000 In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> you write: >There are domains that would like to receive reports, but whose usage of >mail doesn't make it useful to express a policy. Conversely, there are >domains that want to express a policy but aren't interested in reports. >I'd like to advocate that DMARC be split up into two different documents >dealing with reporting and policy separately. If it's useful to have a >separate document that defines what it means to be "DMARC-compliant" >that is referenced by both, that would be OK. Given that we already have one document, I would be very strongly opposed to this. It's fine to fix things that are wrong, but trying to restructure it retroactively will inevitably lead to accidental incompatibilities. R's, John From nobody Thu May 23 18:03:43 2019 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 940C21201D1 for ; Thu, 23 May 2019 18:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=YgqWpfkg; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=n+ABbOqs 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 ITndTzU5m1w9 for ; Thu, 23 May 2019 18:03:39 -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 E156B1201C9 for ; Thu, 23 May 2019 18:03:38 -0700 (PDT) Received: (qmail 33135 invoked by uid 100); 24 May 2019 01:03:36 -0000 Date: 24 May 2019 01:03:36 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:cleverness; s=8167.5ce742e8.k1905; i=news@user.iecc.com; bh=iMGyl+Sz3WjZE3tizGKZVNOtJ+XMKeE3gEUDV6+RCF4=; b=YgqWpfkgM3JcYgmLZFe6ymUDeyPkZj1UOtQcS+oaSapJWTLkI1YzBZaEINwfQKUgv/MhYNVFGvFMQOYJQSOlQAkSsXKOIYLYo7Em38UB7EDaE88YF9doHIfYNQ91xpBIUXlhO94uSijdB/csCMkjyqT04UYawqXEmmAvymyH37cMcCqynETB6HrKQoL0Z9HG+xshKJSWY+NRnrhwcKIBqvL3dEx3F2BSD8sSpTY6RHzKJX8YeFAXo9Y+mbvy81g/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:cleverness; s=8167.5ce742e8.k1905; olt=news@user.iecc.com; bh=iMGyl+Sz3WjZE3tizGKZVNOtJ+XMKeE3gEUDV6+RCF4=; b=n+ABbOqsJgiGISaevDwB/sFxt7D8O7dhsPbDOI4XQS+ePTkxXcgZOuAWPh0OMjh5W7kkk/giODuju1vLVwSczjp5M66Ac3haKXUdoALcn8EX1mwdszQ/zoJET319wnQHSYLgkJLNXusqq7DeLO7jOJvcYkzy64rRZGGiV4x1djQxjsrMndse5u4c/p+KODwuGuXmGPHyRmmsi+ZmXU098D8L0jBFo8UFFbzcrCqLkj/9cx37fDfI+GCm0AdySOfT Organization: Taughannock Networks References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> <20190523225213.C214620147B780@ary.qy> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 01:03:42 -0000 In article <20190523225213.C214620147B780@ary.qy>, John Levine wrote: >In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> you write: >>There are domains that would like to receive reports, but whose usage of >>mail doesn't make it useful to express a policy. Conversely, there are >>domains that want to express a policy but aren't interested in reports. >>I'd like to advocate that DMARC be split up into two different documents >>dealing with reporting and policy separately. If it's useful to have a >>separate document that defines what it means to be "DMARC-compliant" >>that is referenced by both, that would be OK. > >Given that we already have one document, I would be very strongly >opposed to this. It's fine to fix things that are wrong, but trying >to restructure it retroactively will inevitably lead to accidental >incompatibilities. On the other hand, if you want to write separate non-normative tutorials for the reporting part and the policy part, sure, go ahead. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 23 22:01:29 2019 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 21039120100 for ; Thu, 23 May 2019 22:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bluepopcorn.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 HB4XXypeqfxy for ; Thu, 23 May 2019 22:01:26 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E43A51200FD for ; Thu, 23 May 2019 22:01:25 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4300:2290:b9f0:773a:b56c:b679]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4O51Njn003740 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 May 2019 22:01:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558674085; bh=dYCwVjGcnHoTf6YcYsb3TpAnw79sUTTz6tVnamll5ZQ=; h=Subject:To:References:From:Date:In-Reply-To; b=HXKwwxEdL6RgPXO+BlJNzR3rcreV1JLiS/E7F3KVjtLOLu5foyfKjmZcgzvSIWGud kMKBxr4zyA0Fkshx4x4sOeMaC4S7YoKfK1XRb/TIJL4+gNL8jncc6C9CjoYK0XgpmO HFgvOGRUHkWHOi5ViNcBmSsYpi2Gk9sAyS7+mx8A= To: John Levine , dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: Date: Thu, 23 May 2019 22:01:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190523225213.C214620147B780@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 05:01:28 -0000 On 5/23/19 3:52 PM, John Levine wrote: > In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> you write: >> There are domains that would like to receive reports, but whose usage of >> mail doesn't make it useful to express a policy. Conversely, there are >> domains that want to express a policy but aren't interested in reports. >> I'd like to advocate that DMARC be split up into two different documents >> dealing with reporting and policy separately. If it's useful to have a >> separate document that defines what it means to be "DMARC-compliant" >> that is referenced by both, that would be OK. > Given that we already have one document, I would be very strongly > opposed to this. It's fine to fix things that are wrong, but trying > to restructure it retroactively will inevitably lead to accidental > incompatibilities. MTA-STS and TLSRPT started out as one document as well, and separated quite cleanly IMO. I'm not sure what kind of incompatibilities you think might be created. -Jim From nobody Fri May 24 06:03:01 2019 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 CE9BF120092 for ; Fri, 24 May 2019 06:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WLgeq_OwnECG for ; Fri, 24 May 2019 06:02:58 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 4AC7912003F for ; Fri, 24 May 2019 06:02:58 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id w144so6936928oie.12 for ; Fri, 24 May 2019 06:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7osbCzNwd14kcmE3Y+J+R6UXrWHEYFsicSv7Dne9pSw=; b=W1/3Ah1n7K4rm+kBeLvAYSLhk4nsYT3iuq0m7LPY+VpaU+/H805rBvW11LcUXft6rI Q9GEOwmInn3GzjX5B7tFUtt8ImFbFPCNqMvELwfo4qeDsCSMYpaKG7/1ckLUpr+OmeuP Mx61k8LA+rdSCVrKZmj1rOFlUhxHuzzn0aeTffdHZ+XUkUQTG44e/r0KEunkXBpxsRpv lSWlC3A/zVbyNHOipqTFr6evBVRg2aSTKtkeKTJEy+b3Wv/t2fORRgNxLiEBJyrEtxBd +Rg0ZDIoUZZaLg+l6U29fe5uh/0d9+qGHvN4fK7BXGvt++d9D7RHiiE9picdzv/ZqDNN N/1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7osbCzNwd14kcmE3Y+J+R6UXrWHEYFsicSv7Dne9pSw=; b=QvMEW6el8khD3jSs6Xv9e7P/LkBoZNlJnADXM1GSuHNqhwyLInM9T2LwqEjokOYaoc ppnGWOfYnYE8bn1IQNsKdwiOJeS1wDPeX931Ol+v0fI3ny3igdwg+xzkZOhZJ1XusEbd NlZ5hIlh/6/h+QGmecNWeW6tHUmB2Cwkl7bloaQnkB+3DsfNZzsc8pkks/YjOd181R2C xkpQumcq96Vz6AS5sqth3fvrVvNoZKrQSkXekTk/cuxQ/hRLMOt7BWeQH8/gIsYEQcSE 4L1XloxefgPdNBYYXw7O7izTvVdeZHNJBFt1C6qsLxaPaogjEsi7vD9Avpfz6Q87o4rn bAzA== X-Gm-Message-State: APjAAAUWO+PiW6sGnYp2Q+xR2ofB5N1XFmZnMOJ508yL93WurHISFpc/ gZVp4NuZ4glchAqsLpz1hm+IK1Mmp4I= X-Google-Smtp-Source: APXvYqzNYS5RkYJhbtU0IqbDqDAE7rTpjTH9wfTP7SRhdxMDACPPpIDB5OiRTUYHJOUhFTxRmWzrTw== X-Received: by 2002:aca:e68f:: with SMTP id d137mr3043854oih.14.1558702977179; Fri, 24 May 2019 06:02:57 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:75bc:959f:2a1d:49e3? ([2600:1700:a3a0:4c80:75bc:959f:2a1d:49e3]) by smtp.gmail.com with ESMTPSA id d69sm934552oib.36.2019.05.24.06.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 06:02:54 -0700 (PDT) To: Jim Fenton , "dmarc@ietf.org" References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> From: Dave Crocker Message-ID: Date: Fri, 24 May 2019 06:02:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 13:03:00 -0000 On 5/23/2019 1:35 PM, Jim Fenton wrote: > There are domains that would like to receive reports, but whose usage of > mail doesn't make it useful to express a policy. Conversely, there are > domains that want to express a policy but aren't interested in reports. > I'd like to advocate that DMARC be split up into two different documents > dealing with reporting and policy separately. If it's useful to have a > separate document that defines what it means to be "DMARC-compliant" > that is referenced by both, that would be OK. I'm not clear what technical or operational problem you are trying to solve. That is, you seem to be proposing a document split without any technical changes. Yes? While separating or joining segments of specification makes a difference, you haven't described what actual usage issues there have been that warrant the effort to split this document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 24 07:19:54 2019 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 C705C1202F2 for ; Fri, 24 May 2019 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=gU81rIQ8; dkim=pass (2048-bit key) header.d=kitterman.com header.b=gHFF0eI3 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 XqMeyAMx8Or1 for ; Fri, 24 May 2019 07:19:49 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBBC120019 for ; Fri, 24 May 2019 07:19:49 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 286C7F80758; Fri, 24 May 2019 10:19:18 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1558707558; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=B7UOw3sy8KmPEGec3y+WesOD3wKqmMSkiqNfiY8A26A=; b=gU81rIQ8uKWgSTES5joqzD2GDOF1/fl4ga5P2aeIVTgzcaR7g/V0Pynz 1W4izr/KwgXN/6ryWUxSMf297hncAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1558707558; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=B7UOw3sy8KmPEGec3y+WesOD3wKqmMSkiqNfiY8A26A=; b=gHFF0eI3wxX9m19KCYrAHUDKpcRCqV79BlDagVfEBNw+G8dj2ffXBpkH BQWjdSOb925enO0TD7VHKZ+/524qmKimklkmI95iYALLjp55XxGxCe1C+9 GZ1UV1arMjq/G0cHW8OeoTYt6A/6CqQy4reMNG29aSc+PSMN0OK4TlwT+T aHVOsO9oSFfUNHBsymy1FdGjRdVWLnqMin2qeLq+QpPRQpkCo/3WJqpV9Z wxa8wgN8jZUkOUtLXmqgrr4wIkp1v3PZzOt8s317U97ZX3kJniCeLkIuri jgcDinsirg+cfPpZQk/OM4AbI0YR0AMoMqxFprnPKV+WyGG70yHcfw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id E8C4DF80208; Fri, 24 May 2019 10:19:17 -0400 (EDT) Date: Fri, 24 May 2019 14:19:16 +0000 In-Reply-To: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "dmarc@ietf.org" From: Scott Kitterman Message-ID: <9A6E67D5-A1EA-4998-AD83-21F70BDF5E85@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 14:19:52 -0000 On May 23, 2019 8:35:47 PM UTC, Jim Fenton wrot= e: >In response to Seth Blank's call for issues of 9 May 2019: > >DMARC contains what are really two distinct mechanisms, a reporting >mechanism and a policy mechanism=2E The policy mechanism is largely a >request to the verifier about what to do in the event that a message is >received that does not comply with policy=2E > >There are domains that would like to receive reports, but whose usage >of >mail doesn't make it useful to express a policy=2E Conversely, there are >domains that want to express a policy but aren't interested in reports=2E >I'd like to advocate that DMARC be split up into two different >documents >dealing with reporting and policy separately=2E If it's useful to have a >separate document that defines what it means to be "DMARC-compliant" >that is referenced by both, that would be OK=2E > >There was a similar situation with MTA-STS which had both a policy and >a >reporting mechanism, and that was broken into two standards-track RFCs: >RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport >Security)=2E I consider this to be a relevant precedent=2E What do you see as the potential advantage of your proposal? There isn't really a DMARC without expressing a policy=2E One may choose = to have a policy of none, but it's still there=2E In the immortal words of= Rush: "If you choose not to decide You still have made a choice"=2E I can see where it might make things a little easier if we were starting f= rom scratch, but we aren't=2E Scott K From nobody Fri May 24 07:37:58 2019 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 BFC5C12031D for ; Fri, 24 May 2019 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nJp3w+Og; dkim=pass (1536-bit key) header.d=taugh.com header.b=U7nGKozY 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 frrsKlSgdtcg for ; Fri, 24 May 2019 07:37:54 -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 4EA4A12031C for ; Fri, 24 May 2019 07:37:54 -0700 (PDT) Received: (qmail 48800 invoked from network); 24 May 2019 14:37:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=be9d.5ce801bf.k1905; i=johnl-iecc.com@submit.iecc.com; bh=HbfHmPnRcHCmzMo3a/J97+cHZgTnuQhNuA6T7gEOn5w=; b=nJp3w+OgZAYE/h058TMZeNCqINYViG62Bh1CPqvQ6ER0N/SrOALH3v+vZUYWflkBi7qSsvxBGPjYz/XYXYiwvbE1qiczx9/lqp/GGmVAeJSZPf5do2OtyI8BFr0+hcqVpIa9lbG5k6Y3zT+aGEjzhPbSOrMFmlK6g3IiN+otjpYzPygCoNhusr03iQmCbfcDUqW2r5dw9ktoZ4QOYAT7VwtVfnY9RSHW6llqcZ1QIYaPZDRFQu2qllJQBPk55G0c DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=be9d.5ce801bf.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=HbfHmPnRcHCmzMo3a/J97+cHZgTnuQhNuA6T7gEOn5w=; b=U7nGKozYn5AJVufpkErxUTxBONZJ9uP2TW71O46Gccz+mGIaOls9QUwwH1ljXCXoXPwnm9KNLno7ESy/Z5btTbZeicQRtqabTuJmrGFb7p5T7r0RToGP8t64SfBwAHc5P7vxEvScC3Oif2RXJmxPztmNmFiu3bVbUyCQLaM1F/q5ynz9hIP5M+YxA3ukiGfYIWjO3HNQJJ+DFGRCJhGkJsBuBIEihHlZcv6GBjPMkNe9Wjox5YwI8VfBqpbgsiBk Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 24 May 2019 14:37:51 -0000 Date: 24 May 2019 10:37:50 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: References: <20190523225213.C214620147B780@ary.qy> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 14:37:57 -0000 > MTA-STS and TLSRPT started out as one document as well, and separated > quite cleanly IMO. I'm not sure what kind of incompatibilities you think > might be created. That's because they separated before they were published, so there was nothing to be incompatible with. If I knew what would break when reorganizing and rewriting a document into pieces, I could fix it, but since I don't, and nobody else does, let's not go there. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 24 07:42:28 2019 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 7FE3B12033A for ; Fri, 24 May 2019 07:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=IHrRKLNa; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=pEvLkGby 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 OFkLsARiesl0 for ; Fri, 24 May 2019 07:42:24 -0700 (PDT) Received: from mail.winserver.com (unknown [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B8120330 for ; Fri, 24 May 2019 07:42:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4910; t=1558708941; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=AV9c8xbqTi9dnVNg++2KLEOlny4=; b=IHrRKLNaMbQJwzakRKm6s66kdN/StG0AM1CPi2XNm8swTZeO7gL8bk91WKkIjX 7Opo56pif8uM//N1FaXNeCA2A01NZ1nPfGBoKiLem1DZBskXoQgeXQ9hq4UbCJtP gpthQrE4+E6SQHrZUBLiWwFVT7kbVSEFwu52riy9DVA58= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 24 May 2019 10:42:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 3796366542.1.4116; Fri, 24 May 2019 10:42:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4910; t=1558708780; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kQXNPE3 mw1mygfG/m1VGXXz5PvxLr4+Mg1Pw/4y7XBU=; b=pEvLkGbysyIeGieRvEdRjlD He++8hZlPqJo7kYeYVyAcBiXzqFfAgCvnNrzafL21dMDTHaPMhMUfn03x03Ipv37 AKPfNmTWIqaqtDxYgK+iX7AUjEifzGy2D1UYDqicXwGlJi2t7R0qrQXeEFHhD12P upxd1eeTogvV6cn5XMU4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 24 May 2019 10:39:40 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1073635582.9.215596; Fri, 24 May 2019 10:39:39 -0400 Message-ID: <5CE802D0.2070703@isdg.net> Date: Fri, 24 May 2019 10:42:24 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> In-Reply-To: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 14:42:27 -0000 On 5/23/2019 4:35 PM, Jim Fenton wrote: > In response to Seth Blank's call for issues of 9 May 2019: > > DMARC contains what are really two distinct mechanisms, a reporting > mechanism and a policy mechanism. The policy mechanism is largely a > request to the verifier about what to do in the event that a message is > received that does not comply with policy. > > There are domains that would like to receive reports, but whose usage of > mail doesn't make it useful to express a policy. Conversely, there are > domains that want to express a policy but aren't interested in reports. > I'd like to advocate that DMARC be split up into two different documents > dealing with reporting and policy separately. If it's useful to have a > separate document that defines what it means to be "DMARC-compliant" > that is referenced by both, that would be OK. > > There was a similar situation with MTA-STS which had both a policy and a > reporting mechanism, and that was broken into two standards-track RFCs: > RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport > Security). I consider this to be a relevant precedent. Hi Jim. +1. I agree with the split, if it helps with the focusing of completing a Proposed Standard (PS) DKIM-POLICY framework that includes codification for the Author Domain Lookup method, clarification for alignment and most important, finally recognizing extended 3rd party authorization policies and protocol add-on capabilities. I always felt reporting offered little payoff, added lots of overhead to the process, in particular more complex coding requirements, i.e. you really don't need JSON, XML, etc layers to do a simple DNS DKIM policy check, and there was a high potential for abuse. In my 2006 DSAP (DKIM Signature Authorization Protocol) proposal, a reporting option was offered but it was made clear it can be abused, so it should be limited. (https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16) As you recall, the the past DKIM WG did the same with DKIM when it was decided to split the proposed standard's inherent POLICY model (SSP) component into two Proposed Standard DKIM Working Group work item documents; DKIM-BASE and DKIM-POLICY. SSP was replaced with ADSP with reduced policies, ironically, the 3rd party policies were removed -- deemed too complex. It focused on the principle 1st party domain policy, neglecting the 3rd party domain signature and how they should be evaluated. Nonetheless, the split was a success in allowing us to finished DKIM-BASE. But the negatives in the split, as some (including myself) with split concerns had predicted might happen, a lost of interest in finishing the Proposed Standard DKIM Policy work, coupled with a mis-directed attention (wishy future) with reputation methods, eventually, DKIM Policy would be abandoned. I think we lost the interest of many policy advocates during this time, in particular when there was a resistance towards recognizing the "ADID" (Author Domain IDentity) and not including it as part of the into the DKIM-base "Assessment" model. So can the same happen if DMARC reporting was split from a PS DMARC-bis work? IMO, yes, it could happen. I personally do not have any interest in reporting in its current form. I have all received reports gated into a NNTP newsgroup for private viewing. I don't see any consistency and value from them. So that item that can be done -- more consistency. It can discuss XML/JSON viewers, ad-hoc reporting methods to help with with labeling patterns. I believe ARC will also need be part of the reporting as well. This can be very complex but also highly subjective design ideas. They can be discussed separately and independent of a straight forward DKIM author domain policy framework. Finally, the key issue remains, to this day, over 12-15 years, the dearth of 3rd party authorization concepts. That is where the fuzziness remains. To me, this is what DMARC-bis has to help finish. The "Authorized Third Party Signature" (ATPS) model need to be recognized and put into the DKIM-POLICY framework, allowing it to get endorsed and explored at small to high deployment scenarios. We have allowed the brush back by the "Big Guy" (who can't seem to figure it out) deter the possible benefits for all other smaller scales. That is what happen before just to do 1st party and ADSP paid the price only to be replaced later with Super ADSP - DMARC. So they were wrong with ADSP, they are probably wrong with ATPS as well. As a smaller organization with a well defined set of domains, well-defined network usage of where my domains are used. Some are exclusive, very private, some are used in mailing list, like here. I know who is allowed to sign mail on my behalf. That is all defined in published DKIM+ADSP/DMARC+ATPS DNS records. -- HLS From nobody Fri May 24 08:05:00 2019 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 0C4FC1200D8 for ; Fri, 24 May 2019 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KG7M_UC9rCVf for ; Fri, 24 May 2019 08:04:55 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 5255A1202FF for ; Fri, 24 May 2019 08:04:41 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id r76so3480620lja.12 for ; Fri, 24 May 2019 08:04: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=8+Sno0Z6YFCMpv3FWTJ5Gx4yumuRuDGl+Hcls4E9BkQ=; b=usBJHDNVluwa2MIZXmjiuuQ7IBcE6XlzK62IIv9vvrsnHUbTWTNxtjQ1OjlOAR2r8z GZTFc+chr0QBem6dkKj/nI265L6fSIlyY5YDcbRSgTuvO7DyBEB6KFt69Gy2+W8jaI1T ta3aMESxXcfCU8OdaGrN7VDL1QCaRyG/FiB9pturQy9vX3+cSUacELfItpNs5xAwFFik e6NsuP30qIma5WaE9P1rb1uN4XCB638gN1hEO4rpnxt0xu6hXkDVOHda78pJRVmeS1iH aVi8z1vCgkYMUfvWbXHBbtSzpaHK8j9MHf0Q4Dc9xnvOnWEh8FJvakYA5dm6c1mXXynK SDTA== 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=8+Sno0Z6YFCMpv3FWTJ5Gx4yumuRuDGl+Hcls4E9BkQ=; b=laY2RoOtrGSnMWvHEpTFw7GrL8qDT2RLJfXokw9OnyYBOlbQz+T9q20rBcnHlGuT+C /oa67ELh+gwrjSuCsXRF0YVPR+Y/jAQokboP9VK+OW4PUImrKwPgmeHWK4LDiGvY6d9/ ZVXcjAp8Go2qfN482VgeMD89WB5tS7mcsyL/54zvOVhjMFv/c12ex2GRT0dPRwTpJIcn 43nIdDshS4+vHvd9OVU8JN1XiFadUqoQCl1nrR7Uc+EzMSjWW6o7W4+SyzQM1CZgtcN6 nI7Y/9Smegj3OnLutjUy/QvTmDai/GHfExi8d3YRENg3g6YLv7nzjOt8GgfHUKFz8h4G 2ezA== X-Gm-Message-State: APjAAAWtOs7VVYL7RnCNn2e2ust8I+0sLRNwBiLrPVWi32Mk2UblAs6o qZVyNmoEOlzu+sH+WiEoVVqkZTl69etE5DJ1NoQ= X-Google-Smtp-Source: APXvYqxqxPUDR1Zy1MNtbY2MZ4qAL0eDyIv+KG6mgUbraKuCkUZBtVMe1vsS2ssJesAEVmCZZZMhXUr4naj31teoEnU= X-Received: by 2002:a2e:129b:: with SMTP id 27mr21865865ljs.104.1558710279531; Fri, 24 May 2019 08:04:39 -0700 (PDT) MIME-Version: 1.0 References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> In-Reply-To: From: "Peter M. Goldstein" Date: Fri, 24 May 2019 08:04:28 -0700 Message-ID: To: Dave Crocker Cc: Jim Fenton , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000084f6380589a38400" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 15:04:58 -0000 --00000000000084f6380589a38400 Content-Type: text/plain; charset="UTF-8" Agree with Dave here. There's no actual usage issues that are being addressed that merit the split (and the work involved). If you want to receive reports, but not have receivers enforce a policy, set 'p=none' and a rua. If you want to set a policy but not receive reports, set 'p=' and an empty rua. I don't see why that's considered confusing or problematic. It's also worth noting that the the precedent isn't an actual operational precedent yet. There's only one major receiver who is sending SMTP TLS reports, and if you follow RFC 8460 to the letter you will not actually receive them. Unless you implement the DNS records described in RFC 8461, you don't get any reports. As someone who recently dealt with this, and had a back and forth with the receiver, I can personally attest that this was very confusing. The first data point from operational deployment seems to indicate that splitting RFC 8460/8461 may have been a mistake. It's either confusing for the implementing receiver (they are doing something they shouldn't be doing) or for the domain owner (RFC 8460 isn't enough to get reports by themselves). Best, Peter On Fri, May 24, 2019 at 6:03 AM Dave Crocker wrote: > On 5/23/2019 1:35 PM, Jim Fenton wrote: > > There are domains that would like to receive reports, but whose usage of > > mail doesn't make it useful to express a policy. Conversely, there are > > domains that want to express a policy but aren't interested in reports. > > I'd like to advocate that DMARC be split up into two different documents > > dealing with reporting and policy separately. If it's useful to have a > > separate document that defines what it means to be "DMARC-compliant" > > that is referenced by both, that would be OK. > > > I'm not clear what technical or operational problem you are trying to > solve. That is, you seem to be proposing a document split without any > technical changes. Yes? > > While separating or joining segments of specification makes a > difference, you haven't described what actual usage issues there have > been that warrant the effort to split this document. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000084f6380589a38400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with Dave here.

There's no ac= tual usage issues that are being addressed that merit the split (and the wo= rk involved).=C2=A0 If you want to receive reports, but not have receivers = enforce a policy, set 'p=3Dnone' and a rua.=C2=A0 If you want to se= t a policy but not receive reports, set 'p=3D<policy>' and an= empty rua.=C2=A0 I don't see why that's considered confusing or pr= oblematic.

It's also worth noting that the the prece= dent isn't an actual operational precedent yet.=C2=A0 There's only = one major receiver who is sending SMTP TLS reports, and if you follow RFC 8= 460 to the letter you will not actually receive them.=C2=A0 Unless you impl= ement the DNS records described in RFC 8461, you don't get any reports.= =C2=A0 As someone who recently dealt with this, and had a back and forth wi= th the receiver, I can personally attest that this was very confusing.=C2= =A0 The first data point from operational deployment seems to indicate that= splitting RFC 8460/8461 may have been a mistake.=C2=A0 It's either con= fusing for the implementing receiver (they are doing something they shouldn= 't be doing) or for the domain owner (RFC 8460 isn't enough to get = reports by themselves).

Best,

=
Peter



On Fri, May 24, 201= 9 at 6:03 AM Dave Crocker <dcrocke= r@gmail.com> wrote:
On 5/23/2019 1:35 PM, Jim Fenton wrote:
> There are domains that would like to receive reports, but whose usage = of
> mail doesn't make it useful to express a policy. Conversely, there= are
> domains that want to express a policy but aren't interested in rep= orts.
> I'd like to advocate that DMARC be split up into two different doc= uments
> dealing with reporting and policy separately. If it's useful to ha= ve a
> separate document that defines what it means to be "DMARC-complia= nt"
> that is referenced by both, that would be OK.


I'm not clear what technical or operational problem you are trying to <= br> solve.=C2=A0 That is, you seem to be proposing a document split without any=
technical changes.=C2=A0 Yes?

While separating or joining segments of specification makes a
difference, you haven't described what actual usage issues there have <= br> been that warrant the effort to split this document.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000084f6380589a38400-- From nobody Fri May 24 08:26:13 2019 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 8D26D1200C7 for ; Fri, 24 May 2019 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ie7qW8wcEaXp for ; Fri, 24 May 2019 08:26:09 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 0C1B6120052 for ; Fri, 24 May 2019 08:26:09 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id f8so10467756wrt.1 for ; Fri, 24 May 2019 08:26:08 -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=py7arCK2j/cf+tE8IrDWJ3llvB4FLsxHCqAkBWKhNns=; b=AbvBTBovCcnLnQgK2kZltuRUyYOwwd/dNeN4r8Mp324TatuOOVtDDD1ed1nbh7ur96 eOeaKrEm2UOn+HiZQJuJvZ8qOchYRzNZ8LEjUQ3VUEy5HTAMxjYj2OxQrA3wGClrRUuA sYzCXW6r1bUWQMGI3sgu6qT95/YLs/7LuOXZA2cUz+yDqJMtNj+I5qLYfcgoLoCHb743 xIagix33+5ZX+IHQqpih0brlETZ/wo95nrei9iKLZgU0b6pYL5vKpAqUQxf3MYj1DXeF 5KrfU9WiM6/WA57DbiS896I/JhtEF4k05auWrLiUbdaehuUiDNSDAMNrJVN0X5WwA2Qg uklg== 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=py7arCK2j/cf+tE8IrDWJ3llvB4FLsxHCqAkBWKhNns=; b=rp2HUdH2ML/hIWKxDzDNsbxkDQLU+HId/Q9VY4M9mTqexPy5VdAbi9PPGmw1j5dQSJ +I3aGZTgmKe6gO8lNQ01S9NHEKcGNhnDNiIhIR/PA4wNwZbxmYCVNZC0Boal4/XQj2qQ KnjsjyatoMKeBIdcDy3YoHBF750XWFsMY8eZFp3qO9voznfciVizgrVWIkHhZ1BM61Br gOPeCxffG/NWbMT3s4CTyAtjnv2hLDIm6cJBYAkEnIsVL1eTC9/U6Nrp1/4MX68Q9HxM PMZBOxH2UODmx3p9vHmR+DluP3CYpiL3t16lhOyakXw5NdLhU/in/ya7oEAyZRXrDrUd AKOw== X-Gm-Message-State: APjAAAVFMK0vuCqcmTK5C6sSdcwERgkg3PtJbsYtAKkpr3G/qW94rFED qcBcRH7AgPzNRwVZggugQuRlRkOrPuhxRQKkIB2kig== X-Google-Smtp-Source: APXvYqzQ6WyB/JUG4U8imwZXUXNGqLMe6qSwbgc8PA1gzMYYUU15HE6rpL8aOMuOinVR+DF8dX13sOo3+tk9SswGkf0= X-Received: by 2002:a5d:45c6:: with SMTP id b6mr7104392wrs.229.1558711567358; Fri, 24 May 2019 08:26:07 -0700 (PDT) MIME-Version: 1.0 References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> <9A6E67D5-A1EA-4998-AD83-21F70BDF5E85@kitterman.com> In-Reply-To: <9A6E67D5-A1EA-4998-AD83-21F70BDF5E85@kitterman.com> From: Dotzero Date: Fri, 24 May 2019 11:25:55 -0400 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047a0dd0589a3d1a3" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 15:26:12 -0000 --00000000000047a0dd0589a3d1a3 Content-Type: text/plain; charset="UTF-8" Scott expresses it perfectly. +1 There is no compelling reason being given for the split. Absent a compelling reason, this should not be pursued. Michael Hammer On Fri, May 24, 2019 at 10:20 AM Scott Kitterman wrote: > > > On May 23, 2019 8:35:47 PM UTC, Jim Fenton wrote: > >In response to Seth Blank's call for issues of 9 May 2019: > > > >DMARC contains what are really two distinct mechanisms, a reporting > >mechanism and a policy mechanism. The policy mechanism is largely a > >request to the verifier about what to do in the event that a message is > >received that does not comply with policy. > > > >There are domains that would like to receive reports, but whose usage > >of > >mail doesn't make it useful to express a policy. Conversely, there are > >domains that want to express a policy but aren't interested in reports. > >I'd like to advocate that DMARC be split up into two different > >documents > >dealing with reporting and policy separately. If it's useful to have a > >separate document that defines what it means to be "DMARC-compliant" > >that is referenced by both, that would be OK. > > > >There was a similar situation with MTA-STS which had both a policy and > >a > >reporting mechanism, and that was broken into two standards-track RFCs: > >RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport > >Security). I consider this to be a relevant precedent. > > What do you see as the potential advantage of your proposal? > > There isn't really a DMARC without expressing a policy. One may choose to > have a policy of none, but it's still there. In the immortal words of Rush: > > "If you choose not to decide > You still have made a choice". > > I can see where it might make things a little easier if we were starting > from scratch, but we aren't. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000047a0dd0589a3d1a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Scott expresses it perfectly. +1=C2=A0= There is no compelling reason being given for the split. Absent a compelli= ng reason, this should not be pursued.

Michael Ham= mer

On Fri, May 24, 2019 at 10:20 AM Scott Kitterman <sklist@kitterman.com> wrote:


On May 23, 2019 8:35:47 PM UTC, Jim Fenton <fenton@bluepopcorn.net> wrote:
>In response to Seth Blank's call for issues of 9 May 2019:
>
>DMARC contains what are really two distinct mechanisms, a reporting
>mechanism and a policy mechanism. The policy mechanism is largely a
>request to the verifier about what to do in the event that a message is=
>received that does not comply with policy.
>
>There are domains that would like to receive reports, but whose usage >of
>mail doesn't make it useful to express a policy. Conversely, there = are
>domains that want to express a policy but aren't interested in repo= rts.
>I'd like to advocate that DMARC be split up into two different
>documents
>dealing with reporting and policy separately. If it's useful to hav= e a
>separate document that defines what it means to be "DMARC-complian= t"
>that is referenced by both, that would be OK.
>
>There was a similar situation with MTA-STS which had both a policy and<= br> >a
>reporting mechanism, and that was broken into two standards-track RFCs:=
>RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport >Security). I consider this to be a relevant precedent.

What do you see as the potential advantage of your proposal?

There isn't really a DMARC without expressing a policy.=C2=A0 One may c= hoose to have a policy of none, but it's still there.=C2=A0 In the immo= rtal words of Rush:

"If you choose not to decide
You still have made a choice".

I can see where it might make things a little easier if we were starting fr= om scratch, but we aren't.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000047a0dd0589a3d1a3-- From nobody Fri May 24 10:16:21 2019 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 2833C120072 for ; Fri, 24 May 2019 10:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzcva3VCWSr3 for ; Fri, 24 May 2019 10:16:18 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B24120026 for ; Fri, 24 May 2019 10:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1558718175; bh=MzRqecso2Gwe9R/U9DIVtXTl6h4KTGv/s+RSNjYhzG8=; l=179; h=To:References:From:Date:In-Reply-To; b=DgigUxd1n9ayyuypp5eSiFt/a2QKlGCkF3dTzqnmNjLj+oQAuPEmWLS73FOg5H9D7 4OXoyEQT0z0R026yKCg3TYxV9JgSH3cDS9ZJPTOJM2Xm3KCF5yo5UrFsLa4wFnMrBp w8T3ksUhm+v9nbKeyN/+Sh1yoMTxvLqRr7O7KDT+rAHQIW3/3XJpSwlWsZJpI Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 24 May 2019 19:16:15 +0200 id 00000000005DC03D.000000005CE826DF.0000419D To: dmarc@ietf.org References: <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Fri, 24 May 2019 19:16:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 17:16:20 -0000 On Fri 24/May/2019 17:04:28 +0200 Peter M. Goldstein wrote: > I can personally attest that this [splitting] was very confusing. +1. Let's not split, please. Best Ale From nobody Fri May 24 10:36:00 2019 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 DC658120125 for ; Fri, 24 May 2019 10:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 Ff4z318QXwCt for ; Fri, 24 May 2019 10:35:57 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 839FA120059 for ; Fri, 24 May 2019 10:35:57 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4OHZtJK014527 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 May 2019 10:35:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558719357; bh=9yCIGbfVpvGoAlIvoaCNl+9oEXs0SX8MgGGWWkCa4a0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=B8V3Pv1PMduKwRGLsbfhxHb3pcRQ23O3Kf21q8Xzg5uzUfSGum92wVkAgy9F+oWlb K1xLb9IA2kprbAg5wrSKAlTCRUmlo0PLSo2ngBjyG3zqXlRnUebhUcYcaT7TR7lfoC cytKv67qZ1qONALfUV2/C5CLZMfeGOvn72KJX1CY= To: John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> Date: Fri, 24 May 2019 10:35:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 17:35:59 -0000 On 5/24/19 7:37 AM, John R Levine wrote: >> MTA-STS and TLSRPT started out as one document as well, and separated >> quite cleanly IMO. I'm not sure what kind of incompatibilities you thi= nk >> might be created. > > That's because they separated before they were published, so there was > nothing to be incompatible with.=C2=A0 If I knew what would break when > reorganizing and rewriting a document into pieces, I could fix it, but > since I don't, and nobody else does, let's not go there. I hope this isn't devolving into a "we can't make any changes, because it might break something" argument. If that's the case, there isn't anything for IETF to do. But I can understand not wanting to make changes without seeing clear benefit. Here are the benefits I see: 1. When an MTA product says that it "supports DMARC", does that mean that it has to support both policy and reporting? RFC 7489 Section 8 seems to say so. Implementation of reporting introduces significant complexity (aggregation of data into reports, provisions to verify authorization of external destinations, etc.). This seems like it would be a significant barrier to support of the policy piece of DMARC. Or have all of the relevant MTAs already implemented this? 2. Along similar lines, I get confused when I hear that x% of {some set of domains} has "deployed DMARC". What does that mean? Have they asserted a particular policy? Are they generating reports? Both? Either? Perhaps there is a marketing benefit to leaving this fuzzy, but I'm an engineer and I want to know what the statistics mean. -Jim From nobody Fri May 24 10:55:55 2019 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 A2B71120125 for ; Fri, 24 May 2019 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JRkXhkec8Lqg for ; Fri, 24 May 2019 10:55:52 -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 EF958120059 for ; Fri, 24 May 2019 10:55:51 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id w19so6393035vsw.8 for ; Fri, 24 May 2019 10:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EGTilHyHVqm98a4GDtZEbPLOy8ZkFyBOQb0rC9ZT3Ko=; b=vRjAKv6a18LJKxdGu+V8mr+TeNmYRfTjzo9/N/4qXqggY2kYxwYEDAkcrI1NbcmWxq /dAuGbUTkmZwrJ0POh2IKBfwic6Hmhd9DUgH4EaXJgOtJHjHkHkrHdZEIxnvqVlp0dLf LJwnfOHcP0c0JotY7MnRQ1siTHBXS1r5PQgapFHWrSCzYJHT/TeSeENuUmIDq5vWtx7W oWJysTX7JhC1c0sUV6IAniO4zahYKX5heNVWkFfNtlFghf8gAB7t1oprEviPvFHzO3zt mckGT5djxfNWalv8qkpeqjh9xncP5WqogONtV70eKx4AEbtrpuialr6oH+4Nq+ll+bup 4tJg== 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=EGTilHyHVqm98a4GDtZEbPLOy8ZkFyBOQb0rC9ZT3Ko=; b=JyRjXn0TJ91xiU1Ph54emEF1b5EdGG5IxeQzX6GGyUIULSE8tfCmPDm4+wJ8ZNmjYP mQnLPCWWb9SJsm6gzvwwI3HxrCwcJ2nF4e9KExI4LrCvekoAYp8pw8E8cb4PWoEo5iOT qujDESJ34H8tlw16KF/+QGkuMAJelyfspKuDf5kSxGW1mlUHELaxRCK9Z6vLpdAeTaVP C3SUq8mmanVs5xGac/hpaZVniWZYmEO+qOAImpNTX/v3OcfXn77VolvEzaxYEYEld9Z6 +SssEdMIL0Or6g+ZxQetAb4uR2Qysu9cMMdDpxqkKJ03suO2g1bexGHMnxUU4wKi6NUt O/cg== X-Gm-Message-State: APjAAAUg1Dhs67Eue8pC876XLcgePCeeXQx/B9o7CKoIHX/CaOC2kCO8 D5DqPdeg2PJrkIAqcrP1Jsy6h2RoLXlZ4wiSILfsZFQ= X-Google-Smtp-Source: APXvYqyXOgiM1iTgPXvLDRp1oG5aNgtXSNGRO2xnB6N5q0Mc/JuZ609qHU5dxhqQHecT1ZcYN5IkcFT60SYMIZEENR8= X-Received: by 2002:a67:ca9a:: with SMTP id a26mr24508244vsl.92.1558720550363; Fri, 24 May 2019 10:55:50 -0700 (PDT) MIME-Version: 1.0 References: <20190523225213.C214620147B780@ary.qy> In-Reply-To: From: Brandon Long Date: Fri, 24 May 2019 10:55:36 -0700 Message-ID: To: Jim Fenton Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b6290b0589a5e8de" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 17:55:54 -0000 --000000000000b6290b0589a5e8de Content-Type: text/plain; charset="UTF-8" On Thu, May 23, 2019 at 10:01 PM Jim Fenton wrote: > On 5/23/19 3:52 PM, John Levine wrote: > > In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> you > write: > >> There are domains that would like to receive reports, but whose usage of > >> mail doesn't make it useful to express a policy. Conversely, there are > >> domains that want to express a policy but aren't interested in reports. > >> I'd like to advocate that DMARC be split up into two different documents > >> dealing with reporting and policy separately. If it's useful to have a > >> separate document that defines what it means to be "DMARC-compliant" > >> that is referenced by both, that would be OK. > > Given that we already have one document, I would be very strongly > > opposed to this. It's fine to fix things that are wrong, but trying > > to restructure it retroactively will inevitably lead to accidental > > incompatibilities. > > > MTA-STS and TLSRPT started out as one document as well, and separated > quite cleanly IMO. I'm not sure what kind of incompatibilities you think > might be created. > Does TLSRPT support both MTA-STS and DANE? I would think that provides a logical reason to separate them that doesn't exist for DMARC. Brandon --000000000000b6290b0589a5e8de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 23, 2019 at 10:01 PM Jim = Fenton <fenton@bluepopcorn.net= > wrote:
= On 5/23/19 3:52 PM, John Levine wrote:
> In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@blu= epopcorn.net> you write:
>> There are domains that would like to receive reports, but whose us= age of
>> mail doesn't make it useful to express a policy. Conversely, t= here are
>> domains that want to express a policy but aren't interested in= reports.
>> I'd like to advocate that DMARC be split up into two different= documents
>> dealing with reporting and policy separately. If it's useful t= o have a
>> separate document that defines what it means to be "DMARC-com= pliant"
>> that is referenced by both, that would be OK.
> Given that we already have one document, I would be very strongly
> opposed to this.=C2=A0 It's fine to fix things that are wrong, but= trying
> to restructure it retroactively will inevitably lead to accidental
> incompatibilities.


MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you thin= k
might be created.

Does TLSRPT support b= oth MTA-STS and DANE?=C2=A0 I would think that provides a logical
reason to separate them that doesn't exist for DMARC.

Brandon=C2=A0
--000000000000b6290b0589a5e8de-- From nobody Fri May 24 11:06:51 2019 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 8BF9B120159 for ; Fri, 24 May 2019 11:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=uniregistry.link 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 Q5HoKgV6CZTS for ; Fri, 24 May 2019 11:06:47 -0700 (PDT) Received: from a.mx.uniregistry.net (a.mx.uniregistry.net [64.96.177.8]) (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 5F7D1120141 for ; Fri, 24 May 2019 11:06:47 -0700 (PDT) Abuse: Forward to abuse@uniregistry.com with full headers X-Virus-Scanned: Content filter at a.mx.uniregistry.net Powered-By: https://www.uniregistry.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.link; s=bravo; t=1558721204; bh=BsZiVhiaT2b0pPJ1+/foQYRpS0M/zWIGkfyD180mlig=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=j6a8co2vc0OqzwiB/mWfEmEMZWZHgLR8TFWfbeRrO4xC2nOut33jDce3MuBe4Vo19 mVjBBv2+2AvcBSkXhWXaPTsy9zlc5Mh5ujKy//AEWIEZEOnQCxowl+ulGHgeeP3PVi 0z7r8cX6AS6PuOGn1o3jjj5OepbGVz6Z1d5eHU61Ooshrm5qQeOquOXrwhgGufXN5/ 9NzKshxdYemig2oe4iR6rMGdDfwu1YDXkXzkp2knCm5wuDIPcbYiRRDq7NrV+IGZkC 1nTLB7s2vBqi2OBybZNlwv4dAieT7pWywmRkAfmPxrED62fqxxiPZN9HpwndBgtur5 YjcHBjOBVi55w== Received: from [64.96.148.105] (v148-105.dyn.sna3.uniregistry.net [64.96.148.105] (may be forged)) (authenticated bits=0) by a.mx.uniregistry.net (8.15.2/8.15.2/Debian-8) with ESMTPSA id x4OI6h5M014979 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 May 2019 18:06:44 GMT From: "Luis =?utf-8?q?Mu=C3=B1oz?=" To: "Brandon Long" Cc: "Jim Fenton" , "IETF DMARC WG" , "John Levine" Date: Fri, 24 May 2019 11:06:43 -0700 X-Mailer: MailMate (1.12.5r5632) Message-ID: <13623F97-FCDC-41A1-A285-40716A1C6E5A@uniregistry.link> In-Reply-To: References: <20190523225213.C214620147B780@ary.qy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_68EE5662-965D-4743-B8D7-1590BAB892D6_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 18:06:49 -0000 --=_MailMate_68EE5662-965D-4743-B8D7-1590BAB892D6_= Content-Type: text/plain; charset=utf-8; markup=markdown Content-Transfer-Encoding: 8bit On 24 May 2019, at 10:55, Brandon Long wrote: > Does TLSRPT support both MTA-STS and DANE? I would think that provides a > logical > reason to separate them that doesn't exist for DMARC. My reading of RFC-8460 says it does: Recipient domains may also use the mechanisms defined by MTA-STS [RFC8461] or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains. Best regards -- Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 400 Spectrum Center Drive Suite 1660 Irvine, CA 926128 Office +1 949 706 2300 x 4242 lem@uniregistry.link --=_MailMate_68EE5662-965D-4743-B8D7-1590BAB892D6_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 24 May 2019, at 10:55, Brandon Long wrote:

Does TLSRPT support both MTA-= STS and DANE? I would think that provides a
logical
reason to separate them that doesn't exist for DMARC.

My reading of RFC-8460 says it does:

Recipient domains may also use the mechanisms defined = by MTA-STS
[RFC8461] or DANE [RFC6698] to publish additional encryption and
authentication requirements; this document defines a mechanism for
= sending domains that are compatible with MTA-STS or DANE to share
success and failure statistics with recipient domains.

Best regards

--

Luis Mu=C3=B1oz
Director, Registry Operations
____________________________

3D=

400 Spectrum Center Drive Suite 1660
Irvine, CA 92618

= Office +1 949 706 2300 x 4242
= lem@uniregistry.li= nk

=
--=_MailMate_68EE5662-965D-4743-B8D7-1590BAB892D6_=-- From nobody Fri May 24 11:08:40 2019 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 2A5AC120141 for ; Fri, 24 May 2019 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=bluepopcorn.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 zSbW9s6Un0hi for ; Fri, 24 May 2019 11:08:37 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 34EE4120125 for ; Fri, 24 May 2019 11:08:37 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4OI8Vdp014913 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 May 2019 11:08:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558721313; bh=qSTsEVK2E+oISfmgiSiN8TtP/yvm+l5NH2IJPkqzhcM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UGBqEhnprGpRbtpfz4pJZqNCN75gxH2BpP120W3QwraNBxv2iXd+i+pgg32ewYC1k +goiQTC8KVXfftqVGBOXhxXdrgXZb4pxRXmsyJ5dT1ZmTAzWKRK9QVMWZ9s0LJPQgj Mg9JV/+qLiE0qf6GBOQc4B5/C3nZ7sxup7wCx140= To: Brandon Long Cc: John Levine , IETF DMARC WG References: <20190523225213.C214620147B780@ary.qy> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: <5be3bd59-cb43-a3e3-fa40-168a4b09f36c@bluepopcorn.net> Date: Fri, 24 May 2019 11:08:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4D19AFA84DB824A039ADB482" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 24 May 2019 18:08:39 -0000 This is a multi-part message in MIME format. --------------4D19AFA84DB824A039ADB482 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/24/19 10:55 AM, Brandon Long wrote: > > > On Thu, May 23, 2019 at 10:01 PM Jim Fenton > wrote: > > On 5/23/19 3:52 PM, John Levine wrote: > > In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net > > you > write: > >> There are domains that would like to receive reports, but whose > usage of > >> mail doesn't make it useful to express a policy. Conversely, > there are > >> domains that want to express a policy but aren't interested in > reports. > >> I'd like to advocate that DMARC be split up into two different > documents > >> dealing with reporting and policy separately. If it's useful to > have a > >> separate document that defines what it means to be > "DMARC-compliant" > >> that is referenced by both, that would be OK. > > Given that we already have one document, I would be very strongly > > opposed to this.  It's fine to fix things that are wrong, but trying > > to restructure it retroactively will inevitably lead to accidental > > incompatibilities. > > > MTA-STS and TLSRPT started out as one document as well, and separated > quite cleanly IMO. I'm not sure what kind of incompatibilities you > think > might be created. > > > Does TLSRPT support both MTA-STS and DANE?  I would think that > provides a logical > reason to separate them that doesn't exist for DMARC. TLSRPT does support both MTA-STS and DANE, but the same logical reason probably exists for domains that want to generate or receive reports but do not want to publish or honor policy assertions. Although I will admit that publishing an MTA-STS policy is considerably more involved than with DMARC. -Jim --------------4D19AFA84DB824A039ADB482 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/24/19 10:55 AM, Brandon Long wrote:


On Thu, May 23, 2019 at 10:01 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
On 5/23/19 3:52 PM, John Levine wrote:
> In article <5c2fc1da-ae7c-2efe-fda3-47855d61ade6@bluepopcorn.net> you write:
>> There are domains that would like to receive reports, but whose usage of
>> mail doesn't make it useful to express a policy. Conversely, there are
>> domains that want to express a policy but aren't interested in reports.
>> I'd like to advocate that DMARC be split up into two different documents
>> dealing with reporting and policy separately. If it's useful to have a
>> separate document that defines what it means to be "DMARC-compliant"
>> that is referenced by both, that would be OK.
> Given that we already have one document, I would be very strongly
> opposed to this.  It's fine to fix things that are wrong, but trying
> to restructure it retroactively will inevitably lead to accidental
> incompatibilities.


MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you think
might be created.

Does TLSRPT support both MTA-STS and DANE?  I would think that provides a logical
reason to separate them that doesn't exist for DMARC.


TLSRPT does support both MTA-STS and DANE, but the same logical reason probably exists for domains that want to generate or receive reports but do not want to publish or honor policy assertions. Although I will admit that publishing an MTA-STS policy is considerably more involved than with DMARC.

-Jim


--------------4D19AFA84DB824A039ADB482-- From nobody Fri May 24 11:25:39 2019 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 17FB512008F for ; Fri, 24 May 2019 11:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Rfsv583G; dkim=pass (1536-bit key) header.d=taugh.com header.b=Te1726Ll 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 pnjiQ8rhAJYG for ; Fri, 24 May 2019 11:25:36 -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 CCC4312004B for ; Fri, 24 May 2019 11:25:35 -0700 (PDT) Received: (qmail 3042 invoked from network); 24 May 2019 18:25:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=be0.5ce8371e.k1905; i=johnl-iecc.com@submit.iecc.com; bh=nqSfxrQNQ8LvcMsgS74RV2K27puB5RHdCSwP3kOzp8U=; b=Rfsv583G5tmqjpqiRs5dwEAHSa0Tv8Q2sqppoaD4ZUEoE+9j+tIHU7nbPG1vuWGkZR7GeRuAQL57X1HZoULepvmpl30SFTl1agLHQsviKq1UCH+pnZOdG96Ok8m8v9vtfceO9I8/GlbuLZujXHsNX2lU9172S9IDNoCPN+RHk6we5Z5u37/sHzWDBTMc/fSX5Z5xLEhFhxg7bg1bxtXSHATS+xYY5tbm28q45YIHoW45do7cFDHjGHZXZ7tY6mwE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=be0.5ce8371e.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=nqSfxrQNQ8LvcMsgS74RV2K27puB5RHdCSwP3kOzp8U=; b=Te1726LlNdKYmFNMk8t3z/O6rApq+CEQ6J3zuL3Yr2V4NnLFaOAlMSmZ6/vqVbsrTLhmmehNHNaCZQzfmTDkmREnKIBdbIh9Umd+m11pB9EgVhmdL8FM6pI7s3hJGbP4EJv+1/C/U8vCKEBZH96ul4CBGO0kD7Rdt+MHpBwXJokR9LZyZ7UYCWH2jyzyHTZT8fKt3KecgxqwWVMiXrsq3XnsC3X7hlSkOfDvTj3ihDqNLz++c4rvJEXEWY3yglft Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 24 May 2019 18:25:33 -0000 Date: 24 May 2019 14:25:33 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 24 May 2019 18:25:38 -0000 On Fri, 24 May 2019, Jim Fenton wrote: > I hope this isn't devolving into a "we can't make any changes, because > it might break something" argument. I don't think so, but we also have a tradition of minimizing the changes to what's needed. Look at RFCs 2821 and 5321 for example, where they deliberately left the section numbering and most of the language alone and fit the changes into the existing structure. > 1. When an MTA product says that it "supports DMARC", does that mean > that it has to support both policy and reporting? ... > 2. Along similar lines, I get confused when I hear that x% of {some set > of domains} has "deployed DMARC". What does that mean? ... Deploying DMARC seems to mean any subset of these: 1a. Publish a DMARC record 1b. Publish a DMARC record with a restrictive policy 2a. Evaluate DMARC status of incoming messages 2b. Use that status to manage message disposition 3. Collect reports 4a. Send aggregate reports 4b. Send failure reports It is my impression that most domains that have "deployed DMARC" have done 1b and 3. I've done 1a, 2a, 3, and a very small amount of 2b. Only a few sites do 4a and even fewer do 4b. I'm getting the impression that what we need is a non-normative deployment guide, not as part of the spec. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 24 11:39:46 2019 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 3EAA612004B for ; Fri, 24 May 2019 11:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 eY3T_eheRMxR for ; Fri, 24 May 2019 11:39:43 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 30FBA1202EA for ; Fri, 24 May 2019 11:39:42 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4OIde3I015318 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 May 2019 11:39:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558723181; bh=0ZH2Ng7sFskRd3upa5RJH8M676w2KBbrSy6sd6HEzcs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kIiNmFkSPwSf4GyHdDXzkuAKTClM8CUE/6yOUfboIFSHFosC9/B4pLcPvAW81tlOS PvtPv8972rx63he2fvrR3VZcHd2nsJn43qdTSFv2Cj88ghgXbZGUV/wE69c20xW10L gwjLMlQid75GVfGhIBqPPZQZ7QlQ7Ealfc7KqbWs= To: John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> Date: Fri, 24 May 2019 11:39:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 24 May 2019 18:39:45 -0000 On 5/24/19 11:25 AM, John R Levine wrote: > On Fri, 24 May 2019, Jim Fenton wrote: >> I hope this isn't devolving into a "we can't make any changes, because= >> it might break something" argument. > > I don't think so, but we also have a tradition of minimizing the > changes to what's needed.=C2=A0 Look at RFCs 2821 and 5321 for example,= > where they deliberately left the section numbering and most of the > language alone and fit the changes into the existing structure. I consider that to be a different situation because both were Standards Track. This is situation where we are starting with an Informational RFC, although granted it has more deployment experience than many things that go to Standards Track. > >> 1. When an MTA product says that it "supports DMARC", does that mean >> that it has to support both policy and reporting? ... > >> 2. Along similar lines, I get confused when I hear that x% of {some se= t >> of domains} has "deployed DMARC". What does that mean? ... > > Deploying DMARC seems to mean any subset of these: > > 1a.=C2=A0 Publish a DMARC record > 1b.=C2=A0 Publish a DMARC record with a restrictive policy > 2a.=C2=A0 Evaluate DMARC status of incoming messages > 2b.=C2=A0 Use that status to manage message disposition > 3.=C2=A0=C2=A0 Collect reports > 4a.=C2=A0 Send aggregate reports > 4b.=C2=A0 Send failure reports > > It is my impression that most domains that have "deployed DMARC" have > done 1b and 3.=C2=A0 I've done 1a, 2a, 3, and a very small amount of 2b= =2E=C2=A0 > Only a few sites do 4a and even fewer do 4b. > > I'm getting the impression that what we need is a non-normative > deployment guide, not as part of the spec. Although Section 8 of the spec currently has normative requirements for implementations. Yes, that's different from deployment but having those requirements to implement something that isn't deployed much (4a specifically) seems unnecessarily burdensome. -Jim From nobody Fri May 24 11:42:23 2019 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 167091202EA for ; Fri, 24 May 2019 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=t+SZq0ZR; dkim=pass (1536-bit key) header.d=taugh.com header.b=vQWp/kKW 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 ltL1xsIO4yTA for ; Fri, 24 May 2019 11:42:19 -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 236B512004B for ; Fri, 24 May 2019 11:42:19 -0700 (PDT) Received: (qmail 7236 invoked from network); 24 May 2019 18:42:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1c41.5ce83b07.k1905; i=johnl-iecc.com@submit.iecc.com; bh=wTBJUeSoT80IFRNfJDw8XCEktlgu2HYfft1gn5UJRbA=; b=t+SZq0ZRo4Hv+VVPF74mUHhW7pEB9ncorfqu6X71qVMj+rr/9cSZYjM0cW76hovrAfcv+hDZx8reL4xt+810owevyf0U7k7y2FGFAyzfAyWaFLjMUGWC1JhjEQb3peHbj1l6y8T1HoGW/qs1MedMIJgYsH8rm7iXOX3e8tHTGY7XftLZiPBqPNJLWBl2e2/atpAAhOmdO3fjv90OrepPd+sMoYg5tEglppHWH0+jFp5mz4bwEWwzwr/If8G3OiV/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1c41.5ce83b07.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=wTBJUeSoT80IFRNfJDw8XCEktlgu2HYfft1gn5UJRbA=; b=vQWp/kKWmZzKtpqzAHXJFRgsr66Q56UBe2Z0vncLFJyE+XR2kTasrOp1IYN3Nmg5DSEmmlqyP7glYP4CKSeENrkiZXwHpcGeaY5HayICNKmJFpL7+kqxv5OJPRptcPwIQtV8e3ZZyqmGzJ8ok0FY4mJk/KHxdYJVm2EcxOH1rJtfupUASIwhHNZV92AMSGn6QPm3yYH8PahJHqyIAF3nyqjP2NS06yzJqhL3xAJc3TNK+F/WGk7zptNmfUwQFxNs Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 24 May 2019 18:42:14 -0000 Date: 24 May 2019 14:42:14 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 24 May 2019 18:42:21 -0000 >> I'm getting the impression that what we need is a non-normative >> deployment guide, not as part of the spec. > > Although Section 8 of the spec currently has normative requirements for > implementations. Yes, that's different from deployment but having those > requirements to implement something that isn't deployed much (4a > specifically) seems unnecessarily burdensome. Taking out stuff that people don't actually do or marking it as optional seems like a reasonable change to the next version of the spec. But I still think a non-normative deployment guide would help people. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat May 25 11:36:03 2019 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 056151200EC for ; Sat, 25 May 2019 11:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 xX1UsmbrPOxN for ; Sat, 25 May 2019 11:36:00 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 EDC66120086 for ; Sat, 25 May 2019 11:35:59 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4PIZudm014630 for ; Sat, 25 May 2019 18:35:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558809356; i=dkim+sm-localhost@aegee.org; r=y; bh=jI1bcXmnqAzqxUDwe6Qo5NdPEotggewUqF/8tnZXRNE=; h=Date:From:To:Subject; b=hbS+06QRIREXfwMnoQ/daCxuBzA48JzjjWFIYgzZiZNXc0H/c64DUsWw5Ca5Anmns DJozjnLM2yrfMqOGPe3bIdAOr0Leohv500RZQUpLHOX0UH9WsNFrQwULCGBioFfNaR oaa42d+r+k1RexgEF6VTuEf1KjCbJtxpylxx+IN1qKlH2UUnWZIn3u+hYvRyQAO7Z2 pRbJYJp8Bs46k6T4m7StOx/OxZxJr/z25erdIrhGc+AywrPYLSUH3mQn6g/xHW8naZ pYoQqd6Ksa/i5gefT7aDXI/DlkfsGm3XIBf+CmIxrQ2PHrPXLZHvkpUL4RRwjlTdg8 lXUUdJ817wrqcaqTK8L3KPFV8CepbJsTv22OdIS2x3COqvYpUEB02GnWv19ouZ3urk /vORREsZTonct3Yqf5GIngj1zUnwycWgPi6243kguWpEH/xXEOlqRBZ0dmQ7pMZ0wl uBXUEcV05WOCPTNeO+GUETWh2kEW2xD0WCmrxmNag/H8TG2vaaKNAZgnoWTH5AUXaJ XZ+MOQRc9ANo9tgZUymkYP3YMoBCr6DtABv8kODVDIuWsx18QYNMdHQOIAJBEB+bdC 9ect3QAbJGJE/ZTIqeNZsHNoG+OYp3IK3RPnT4uvvX9W0A+IpirGMfmSgrLpvfL5GB W/7AxFr5hTEQKAW/VnO3NIuw= Authentication-Results: mail.aegee.org/x4PIZudm014630; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Sat, 25 May 2019 18:35:56 +0000 Date: Sat, 25 May 2019 18:35:56 +0000 Message-ID: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> From: Dilyan Palauzov To: dmarc@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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: Sat, 25 May 2019 18:36:02 -0000 Hello, is there already any recommendation from IETF to send DMARC message-specific failure individual (non-aggregate) reports with FROM:<> (or NOTIFY=NEVER)? Consider this scenario: an email from a domain, with DMARC policy “p=reject; ruf=postmaster@domain” fails validation. A message-specific report is sent to postmaster@domain. The report is bounced (or there is any reply on it) and the reply is again From: that domain and does not validate DMARC. In turn a new message-specific report is sent and this loop ends, when some disk gets full. With FROM:<> or NOTIFY=NEVER there would be no such loop. Note, that DMARC aggregate reports do not have this problem. Regards Дилян From btv1==048afe71f87==fosterd@bayviewphysicians.com Sat May 25 12:43:11 2019 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 0D382120096 for ; Sat, 25 May 2019 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 tbUZd8Qd_iJd for ; Sat, 25 May 2019 12:43:09 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EE1120021 for ; Sat, 25 May 2019 12:43:08 -0700 (PDT) X-ASG-Debug-ID: 1558813386-11fa3116c81a5aa0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id WgxZthJYvz4eAjhB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 25 May 2019 15:43:06 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=xknvgjwCx6DrcYRZPN3ZamXdls0W0B0djyRgicfnlWE=; b=mNNLC3kZKOS8F+O5NWRB3l3olKmOuCkYxX2+E+0L1z+nEIpQvCsdPNMmbOm30tMS+ 91x7B4ldbs7TJmb+adOyoQdSGi6goEcqRJEL3mbfMSaccB6+/zd0veNaOmvEywE4f i6zVWoeorLI2+A5PS15IO14e8lpqb6nDPkmLQ835I= Received: by webmail.bayviewphysicians.com via HTTP; Sat, 25 May 2019 15:42:57 -0400 From: "Douglas E. Foster" To: Date: Sat, 25 May 2019 15:42:57 -0400 X-ASG-Orig-Subj: Improving feedback using additional status codes Reply-To: fosterd@bayviewphysicians.com Message-ID: <1ee3bd2ebd204746a0d0641e186ca8a8@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=1fe53739a78e4e45b7b0b47bfca05dde X-Originating-IP: [192.168.1.239] X-Exim-Id: 1ee3bd2ebd204746a0d0641e186ca8a8 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1558813386 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 6138 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: [dmarc-ietf] Improving feedback using additional status codes 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: Sat, 25 May 2019 19:49:13 -0000 This is a multipart message in MIME format. --1fe53739a78e4e45b7b0b47bfca05dde Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The genius of DMARC, as compared to DKIM and SPF alone, is the feedback component. Unfortunately, sender authentication remains challenged by these issues: Limited deployment of DMARC feedback between senders and receivers. Significant levels of SPF and DKIM validation errors, on legitimate mail, even when indirect mail is not involved. Handling false positives becomes a significant obstacle to implementation of Sender Authentication by receivers. When the sender has not implemented DMARC, the recipient has difficulty communicating with the sender about Sender Authentication problems. Finding a knowledgeable employee is difficult and time consuming, so it will rarely be attempted. (And I have tried it.) I propose two improvements to deal with this issue. The first is to define another feedback mechanism using message reception status code. The second is intended to reduce DKIM verification errors, and will be posted later. PROPOSAL When a recipient detects an SPF or DKIM problem, it can provide immediate feedback to the sender with message status codes. I think these are a complete list of the conditions which would need a result status defined. The approach should be entirely upward-compatible with the existing infrastructure. Message Success with SPF warning Accepted despite SPF=NONE & Source IP not in MX list Accepted despite SPF=NEUTRAL Accepted despite SPF=SOFTFAIL Accepted despite SPF=FAIL Accepted despite SPF TempError Accepted despite SPF PermError Message PermFail because of SPF Rejected because of SPF=NONE & Source IP not in MX list Rejected because of SPF=NEUTRAL Rejected because of SPF=SOFTFAIL Rejected because of SPF=FAIL Rejected because of SPF TempError Rejected because of SPF PermError Message TempFail because of SPF TempFail due to SPF TempError Message accepted despite DKIM Accepted despite DKIM PermError Accepted despite DKIM TempError Message PermFail because of DKIM (not recommended) Rejected because of DKIM PermError Rejected because of DKIM TempError Message TempFail because of DKIM TempFail because of DKIM TempFail Since DMARC evaluation is based on SPF and DKIM evaluated together, the above codes would seem applicable even with DMARC enforcement. I think these additional codes should be sufficient: DMARC PermError (invalid policy record) DMARC TempError (problem retrieving policy record.) Is this reasonable? Doug Foster --1fe53739a78e4e45b7b0b47bfca05dde Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
The genius of DMARC, as compared to DKIM and SPF alone, is the feedbac= k component.   Unfortunately, sender authentication remains chall= enged by these issues:
  • Limited deployment of DMARC feedback between senders and receivers.  
  • Significant levels of SPF and DKIM validation errors, on legitimate ma= il, even when indirect mail is not involved.  Handling false positives= becomes a significant obstacle to implementation of Sender Authentication = by receivers.
     
  • When the sender has not implemented DMARC, the recipient has difficult= y communicating with the sender about Sender Authentication problems. =  Finding a knowledgeable employee is difficult and time consuming, so= it will rarely be attempted.  (And I have tried it.)
I propose two improvements to deal with this issue.  The first is= to define another feedback mechanism using message reception status code.&= nbsp;  The second is intended to reduce DKIM verification errors, and = will be posted later.
 
PROPOSAL
 
When a recipient detects an SPF or DKIM problem, it can provide immedi= ate feedback to the sender with message status codes.  I think these a= re a complete list of the conditions which would need a result status defin= ed.   The approach should be entirely upward-compatible with the = existing infrastructure.
 
Message Success with SPF warning
  • Accepted despite SPF=3DNONE & Source IP not in MX list
  • Accepted despite SPF=3DNEUTRAL
  • Accepted despite SPF=3DSOFTFAIL
  • Accepted despite SPF=3DFAIL
  • Accepted despite SPF TempError
  • Accepted despite SPF PermError
Message PermFail because of SPF
  • Rejected because of SPF=3DNONE & Source IP not in MX list
  • Rejected because of SPF=3DNEUTRAL
  • Rejected because of SPF=3DSOFTFAIL
  • Rejected because of SPF=3DFAIL
  • Rejected because of SPF TempError
  • Rejected because of SPF PermError
Message TempFail because of SPF
  • TempFail due to SPF TempError
 
Message accepted despite DKIM
  • Accepted despite DKIM PermError
  • Accepted despite DKIM TempError
Message PermFail because of DKIM (not recommended)
  • Rejected because of DKIM PermError
  • Rejected because of DKIM TempError
Message TempFail because of DKIM
  • TempFail because of DKIM TempFail
 
Since DMARC evaluation is based on SPF and DKIM evaluated together, th= e above codes would seem applicable even with DMARC enforcement.  &nbs= p;I think these additional codes should be sufficient:
  • DMARC PermError (invalid policy record)
  • DMARC TempError (problem retrieving policy record.)
Is this reasonable?
 
Doug Foster
 
 
 --1fe53739a78e4e45b7b0b47bfca05dde-- From nobody Sat May 25 13:53:22 2019 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 67F02120130 for ; Sat, 25 May 2019 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 E0qk3-NsvpUk for ; Sat, 25 May 2019 13:53:18 -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 B6E1812012E for ; Sat, 25 May 2019 13:53:18 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id r10so11713469otd.4 for ; Sat, 25 May 2019 13:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hT9WceKd71rMV7dIg2aE6GPs1w2oNWumCtcsnuJ4l2M=; b=ltXczS3IVTyax8ZvcCKOcdTb8rw67Yrwio32LPxhJzQXmgIbYdrLlT5cD8XpNrTVwx gNlwN/vKufPEo+VHPHHqotn/nhjYIirNtXPjDrM3HVVx6+964XvnQMn+dnYIXDNIBuJ2 CJRUg8g15VqWFPQlAvS57aGnrPZsMc5DUE0b5Z4kZdmG5I0L3C0Ky/DJ4Imd3zMdizNl lhukx76nfLS+Y6FFIp7KytFYp5+RVpB1XzPK0zPw35xge3zibkFefIX7qxKoknu7nY/j KP4Yr+qI1BCFcoF7F55Zyq5G/kSLEpQ2fzZNeCF7kYCK8z49DSe1q+rC/XXL1doN0ohB rBSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hT9WceKd71rMV7dIg2aE6GPs1w2oNWumCtcsnuJ4l2M=; b=YYtfyNBfRLSiZbLFTfV0W4ODkNqk1uzR25xUxTFJFWz9TvY8pSzxm49TmHa4DHaTCs wI+2u0CTPr3JvVFnmHen91ixux3fCq9S8/4eFjCRWkIc/9f2oMCt51aM0RVrmwXF2f1e 56rnSts9PeXTgElStUf22gIDTaQVhq5A8InqP3e6KL0hgWbpNtY+EGL2bdnqGtGguqJM Lf/NC/FqyPkxkZi2RLcHa4U1enlCQ/gzle1g4vRh3ipSeUCk4Ja58zh988twZsy0iIs1 wVDraHyxn/Rqy2g/g5G4s7E0PbyGZ5GLU53dLLamatXvwyrFGCpk0cxrt4XHZCUJZ1Td e1Ww== X-Gm-Message-State: APjAAAUBkIvVyys+s+RyM3NjFkJRKRcCVIwx7a3rynRLXZwgGX3KJKQh UxlW6vagEomyzNb2yPre9AKcsAWr4Ds= X-Google-Smtp-Source: APXvYqz5vxwi45Y4gUX25kSdWe5s3ORvrPBqArW2oiCfl9eEWUnGN+c6EckxtEAqD97AtBf8nRHSOw== X-Received: by 2002:a9d:7d13:: with SMTP id v19mr45814135otn.234.1558817597425; Sat, 25 May 2019 13:53:17 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:9015:bdb5:7e75:4574? ([2600:1700:a3a0:4c80:9015:bdb5:7e75:4574]) by smtp.gmail.com with ESMTPSA id 59sm2493033otq.8.2019.05.25.13.53.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 13:53:16 -0700 (PDT) To: Jim Fenton , John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> From: Dave Crocker Message-ID: <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> Date: Sat, 25 May 2019 13:53:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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: Sat, 25 May 2019 20:53:20 -0000 On 5/24/2019 10:35 AM, Jim Fenton wrote: > I hope this isn't devolving into a "we can't make any changes, because > it might break something" argument. We are quite a long ways from that. In fact we are in the "please make a case for their being a serious problem that needs fixing" argument, combined with the "please explain how the proposed solution will fix the serious problem" argument. > 1. When an MTA product says that it "supports DMARC", does that mean That's a generic issue that applies to many circumstances. And since there is no standard meaning for "supports x", it has marketing utility, not technical. That's not going to get fixed in this wg. > that it has to support both policy and reporting? RFC 7489 Section 8 There are multiple opportunities for ambiguity. Another is: Does it mean publishing or interpreting? Splitting the documents doesn't solve any of this. > 2. Along similar lines, I get confused when I hear that x% of {some set > of domains} has "deployed DMARC". What does that mean? Have they Ultimately, you are asking marketing questions, not technical ones. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat May 25 14:30:39 2019 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 8E0CE12011C for ; Sat, 25 May 2019 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UtDmKhap; dkim=pass (1536-bit key) header.d=taugh.com header.b=RqEuf7R+ 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 wBqxxqEGIAn5 for ; Sat, 25 May 2019 14:30:35 -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 7B3A11200F3 for ; Sat, 25 May 2019 14:30:35 -0700 (PDT) Received: (qmail 20195 invoked from network); 25 May 2019 21:30:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4ee0.5ce9b3f9.k1905; i=johnl-iecc.com@submit.iecc.com; bh=F2P/BpnthA002i5sNRdhyn6Ri9dwdiTNPjbb4ulm0QQ=; b=UtDmKhapw39LI5Lc+LZCN7pii/YVL8IoePX3iP4N3KWaUdunFmPMmIm8T+qmnWxr+JldHR9PoLwLFbhwvyhK2ldvmoX1MoUgbu+GlI3E2TYb1eIbUh1jpDA9LqmpSvdzk0NwN9CQH3n+ojUmC13djwQwEhoIAYov3/KpNVo3h4hFaAxMpm5R3aqUl/cuGDrPYzXJYBfTlm9DecKq+RZhgi0HS/iDmlJ5gew8sXs18BrYH1E3kdDubo3sEqeqZRbf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4ee0.5ce9b3f9.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=F2P/BpnthA002i5sNRdhyn6Ri9dwdiTNPjbb4ulm0QQ=; b=RqEuf7R+0OBjNNhf3UfOg7giJSPiQSpit9p37R8npNDzvHHMbKiBcQm1Qw0NTf5zMceLmvOH7O113vBTxpsJUlttees9vHMxp+YbtiUPgLlshXIuxT+XXQ5T7VyJFP2HepGgeojeE1tS5I8bun0d0bu9w4mCsyp5LoQ4XDCcenWWpmaATDi4VLJI9jG+3MUILjF8ifZ8UVItzlnNQ2Ar2mnizGCJRGhuc6D5aBDuvTS+l4NsBGOPBfYhrgtXpMAZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 25 May 2019 21:30:33 -0000 Date: 25 May 2019 17:30:33 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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: Sat, 25 May 2019 21:30:38 -0000 On Sat, 25 May 2019, Dave Crocker wrote: >> 2. Along similar lines, I get confused when I hear that x% of {some set >> of domains} has "deployed DMARC". What does that mean? Have they > > Ultimately, you are asking marketing questions, not technical ones. Right. It's easy enough to imagine soemone handing out Official DMARC Compliance certificates, but that someone sure wouldn't be the IETF. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat May 25 14:53:25 2019 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 3DAEC120120 for ; Sat, 25 May 2019 14:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dGLNFCpb; dkim=pass (1536-bit key) header.d=taugh.com header.b=T/7oRLxO 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 SZg2R2YkZ4Oo for ; Sat, 25 May 2019 14:53:20 -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 87DA312011D for ; Sat, 25 May 2019 14:53:20 -0700 (PDT) Received: (qmail 24663 invoked from network); 25 May 2019 21:53:18 -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; s=6055.5ce9b94e.k1905; i=johnl-iecc.com@submit.iecc.com; bh=ECUAkO6LzZPVYhFaMaRulMxhymTU+K7VvVijujwytgg=; b=dGLNFCpbf+OQchywuf3Gx/vh+5lLYk71d0APPdsUDeq1UqaRIaAbiUnqqU9gkKvwuBTn9HKSBXVNMkvneEtZhi7exy0dxc1pHfWMJ/hnTtuZdGYPbDvR4VSRDLTzfcjesQKk4SSMoDvydX/NgAQZwiAjFX6JK9zl0JWCJPCgyjvWLRIG/HPPEVaWmUKVychOSNafUs/BRa6E7jkj9pVZCzAqmDiXD+phAOwQ8yKzwGAtDC8xODqMAx27HTccrfud 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; s=6055.5ce9b94e.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=ECUAkO6LzZPVYhFaMaRulMxhymTU+K7VvVijujwytgg=; b=T/7oRLxOfumbTLbcqld7AIBAL2pEqoRDKngmYkSnkGbHon3N5rFWIPrCAGSLbgzmblmETxIVgGG/5tAGOh2t0V2i2RdTahn3xwrUcm9/2GvFjJSdowQur5iUkTS+MFGG3NPHOPORGFx/9aPDRxZHvIRdJTB1JrU49WWkKIb+i+qY2LaA3U6gcHC918355q2yrl+Bt4YLaJF3jvbXzPGE1BakFqbVEGNGhHtlzJKBodw6I7zKUkaVIeyeA2FGrTcw Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 25 May 2019 21:53:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 1580620149E52F; Sat, 25 May 2019 17:53:17 -0400 (EDT) Date: 25 May 2019 17:53:17 -0400 Message-Id: <20190525215318.1580620149E52F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org In-Reply-To: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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: Sat, 25 May 2019 21:53:23 -0000 In article <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> you write: >Consider this scenario: an email from a domain, with DMARC policy >“p=reject; ruf=postmaster@domain” fails validation. A >message-specific report is sent to postmaster@domain. The report is >bounced (or there is any reply on it) and the reply is again From: >that domain and does not validate DMARC. In turn a new >message-specific report is sent and this loop ends, when some disk >gets full. With FROM:<> or NOTIFY=NEVER there would be no such loop. The trickle of failure reports I get are from addresses like these: forensicdmarc@seznam.cz mailnull@segv.crash.com dmarc-noreply@linkedin.com opendmarc@hamartun.priv.no prvs=1020be0dc4=noreply@manthorp.com I would expect that any mail sent to those addresses is unlikely to provoke a failure report, no matter how mangled it is when it arrives. We've had failure reports for almost seven years and I don't ever recall someone getting into a mail loop so it's not a problem in practice. From nobody Sat May 25 14:56:02 2019 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 1690F120045 for ; Sat, 25 May 2019 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GorO8E3P; dkim=pass (1536-bit key) header.d=taugh.com header.b=mkzMPTuj 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 ES8hnVua4EzI for ; Sat, 25 May 2019 14:55:59 -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 3E60112002F for ; Sat, 25 May 2019 14:55:59 -0700 (PDT) Received: (qmail 25106 invoked from network); 25 May 2019 21:55:58 -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; s=620f.5ce9b9ee.k1905; i=johnl-iecc.com@submit.iecc.com; bh=dO1Ik0AH1MMOtG1SsWAh4QqkIVZlMpkT2nSGZAQtur0=; b=GorO8E3PhQKUcHjN7tfev66yuIUqPZ4q+wUrq64Hmzi8aooHrgnO8ij1g1ffcBov7jvj0xbSSHYoiWu1A6s8YW+j1YuOTJGyZyYwTCnmhbxc6Lh4Gsq262ttu/2AjOv4afZrqi6PjfwQJyOgk5R5xCyEtS3ulneui1hIrt0C7Qwenm0NfFd9svrSug5tnJznFlHVX5hWGC99+jNhr7ekNFj4NQhv4pG41/F/5D+lATk/mjYYOgVg8WUTk7638h3j 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; s=620f.5ce9b9ee.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=dO1Ik0AH1MMOtG1SsWAh4QqkIVZlMpkT2nSGZAQtur0=; b=mkzMPTujJZKCQMsrwrUW/qoh6RCpLftVF0+mrjpJ4zGe0XjuKhdB/cLzCT+vOp8LtY14nMZficCYxe/ouBfSzB7xA3qMYBhkDcNJ6rmxxGtIyAFoZklV9hQDyvCuppJk0d4GtbGYkJ7sjAbPt72ORQlu3oX77BdbBGmbbEfKgGyzfYXKxGR/JrNeeyAH5K7m1aDtLppuonHfpgFuzhIaH37xT6m3KSTieioI/zibJAtsF2wNEmtDDNmzGnGVo8z7 Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 25 May 2019 21:55:58 -0000 Received: by ary.qy (Postfix, from userid 501) id BAB0020149E572; Sat, 25 May 2019 17:55:57 -0400 (EDT) Date: 25 May 2019 17:55:57 -0400 Message-Id: <20190525215557.BAB0020149E572@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1ee3bd2ebd204746a0d0641e186ca8a8@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Improving feedback using additional status codes 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: Sat, 25 May 2019 21:56:01 -0000 In article <1ee3bd2ebd204746a0d0641e186ca8a8@bayviewphysicians.com> you write: > PROPOSAL > > When a recipient detects an SPF or DKIM problem, it can provide immediate >feedback to the sender with message status codes. No. If people want status reports, they'll ask for them. On the other hand, if I were a spammer, I would think your proposal was great because it makes it a lot easier to probe and figure out how your spam filtering works. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat May 25 22:10:06 2019 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 32A62120020 for ; Sat, 25 May 2019 22:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 F7JNv8MSA7EZ for ; Sat, 25 May 2019 22:10:02 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 39C78120058 for ; Sat, 25 May 2019 22:10:01 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4Q59wt0017814 for ; Sun, 26 May 2019 05:09:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558847399; i=dkim+sm-localhost@aegee.org; r=y; bh=APyrTdCI9SqRj9l5gbweVMTqN7tDN7DlxD+gEetG6Tc=; h=Date:From:To:Subject:References:In-Reply-To; b=d8LjLXI8cgBNUjHeN8tI/DMUpq0tL8LkeLuGGtz9fSzr3udQTKhF72DT6eoevm9QB wlHvsCKc+0gpmCGDXbZS7i+p7Q79YORZNUxgDAVJcqj2WWwYi0Q9x+u4/EndhQg6V1 dn1d5SrLnyfjK4FD7E3a/Lf7u+e7LlLmwWb8vPAzDg6/u3aNYR7+qpvUNOwvquUtKB l1AnWElXtLdppIcog6lGY4lyMl2vuGoRYLOqaS9OfY3gROuiPyuXLfCWGsvBeGNMaB cgsOiv5I5blSY735RHxtPAA1QE2XE9A1lJohbk6E07Y1YlieUr7+lCb0olU6GLENzt ClycVwZ51sQM8dt4tnTzr/xA4hkp5+NRDKkde2uixhxZrn+AkWHZiuapbENOLCGXib lScewRsC9JyVU6zqNb8v7yytPaIaY9ZMCKfmURkWySwkm0QNCvFgA2hG4wziym8N1c HWNfIgWjZUiW/Z/ylH4iqL6xXFuED79rQgDCDlO0pgspoZcuOPl8MTXUZ71smyPyr2 79Xl7R3LVoGmsIHD/V0IHMLMV1qldOMHiTq1odtAeaMcrQsuLQsav3WDnmQx1iFVNm OtYXk4/uOrIwCyiocEiMKY9MijgSRtnlSnAgFTXpp9Vm16XtK7IpHi7lr1sASv9av4 DbaXb7KB3Bx7rNAX8hyt2TQE= Authentication-Results: mail.aegee.org/x4Q59wt0017814; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Sun, 26 May 2019 05:09:58 +0000 Date: Sun, 26 May 2019 05:09:58 +0000 Message-ID: <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> From: Dilyan Palauzov To: dmarc@ietf.org References: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> <20190525215318.1580620149E52F@ary.qy> In-Reply-To: <20190525215318.1580620149E52F@ary.qy> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 05:10:05 -0000 Hello John, in case of modernwebsite.pl: DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@modernwebsite.pl; ruf=mailto:postmaster@modernwebsite.pl; aspf=s;adkim=s;" Emails to postmaster@modernwebsite.pl are answered with “Undelivered Mail Returned to Sender”. The answers do not align to the DMARC policy reject, so a new message-specific failure repot is sent. The loop happens, when you do send failure reports, not just receiving such. Regards Дилян ----- Message from John Levine --------- Date: 25 May 2019 17:53:17 -0400 From: John Levine Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org > In article > <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> you > write: >> Consider this scenario: an email from a domain, with DMARC policy >> “p=reject; ruf=postmaster@domain” fails validation. A >> message-specific report is sent to postmaster@domain. The report is >> bounced (or there is any reply on it) and the reply is again From: >> that domain and does not validate DMARC. In turn a new >> message-specific report is sent and this loop ends, when some disk >> gets full. With FROM:<> or NOTIFY=NEVER there would be no such loop. > > The trickle of failure reports I get are from addresses like these: > > forensicdmarc@seznam.cz > mailnull@segv.crash.com > dmarc-noreply@linkedin.com > opendmarc@hamartun.priv.no > prvs=1020be0dc4=noreply@manthorp.com > > I would expect that any mail sent to those addresses is unlikely to > provoke a failure report, no matter how mangled it is when it arrives. > > We've had failure reports for almost seven years and I don't ever > recall someone getting into a mail loop so it's not a problem in > practice. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ----- End message from John Levine ----- From nobody Sat May 25 22:20:57 2019 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 2C1EE12006D for ; Sat, 25 May 2019 22:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pFc-PFlAN-xg for ; Sat, 25 May 2019 22:20:51 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26: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 C38F312008C for ; Sat, 25 May 2019 22:20:51 -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 x4Q5Kmic030976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 26 May 2019 00:20:50 -0500 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x4Q5Kmic030976 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1558848050; cv=none; b=L9ODoKWEoWErbLElCMF0K5aEsGQm4dwB3PfZzLr9/juDsPJs2aQuAbMU9VerZ4xkgG3jqw/cFKDxLzEPXfkeioUxECjrvIngclQAL9Kz5ZaFqx98KIxxBa7FmSc7pHmwNvdRTF+DDs+9BnesvyUrX/JLFHQ0g5CvrWJa0IVIqK4= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1558848050; c=relaxed/simple; bh=lJchDzhTnTd5Wg51Hw9U3nLuxr6DftwhvXvSQPWsEcg=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=547kuSd5J/m4nQASXaFVd1NQDh2P/xxu/3kZn7w8CEd13DOghodydWYPaWB6o+D4yVXXtrHcDcVrDemDOG1ZKtxorkjuU5LDSKpKTAvq/6ROMIAmzyD0TVDuWF0L56fk5pCi0RURwYMlcRkwunH4Ep93rzM25ilrCN5+43Z04E4= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1558848050; bh=lJchDzhTnTd5Wg51Hw9U3nLuxr6DftwhvXvSQPWsEcg=; 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=uO/Gp0k3aEPtRHjQSHWgHKyA2TvnHam2AlirDT3CpPHuuX2yAuNZwgA3KJU0L4dbG oFf4aQushA4ctsluRcw/n4gPgY2i7VAIU4tXEwhiwi2uy2NVkWa9QT8aBj36mvgZbH OfA9FMd5o360PTLwa6XOTekFHlRbqSmo8sv9Cr2o= To: dmarc@ietf.org References: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> <20190525215318.1580620149E52F@ary.qy> <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> From: Grant Taylor Organization: TNet Consulting Message-ID: <26760626-b3f2-b8cd-f31f-d78b487db35c@spamtrap.tnetconsulting.net> Date: Sat, 25 May 2019 23:20:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070508030104030305000803" Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 05:20:55 -0000 This is a cryptographically signed message in MIME format. --------------ms070508030104030305000803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/25/19 11:09 PM, Dilyan Palauzov wrote: > Emails to postmaster@modernwebsite.pl are answered with =E2=80=9CUndeli= vered=20 > Mail Returned to Sender=E2=80=9D.=C2=A0 The answers do not align to the= DMARC policy=20 > reject, so a new message-specific failure repot is sent. Are the reports that you are sending being accepted at SMTP time and=20 then bounced after the fact? That sounds like (what I think is) a misconfiguration on their end. As such, I'm less inclined to think that modifying DMARC is the proper=20 thing. Especially if this is a rare occurrence (as in a very select=20 candidate). --=20 Grant. . . . unix || die --------------ms070508030104030305000803 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 Cy4wggVAMIIEKKADAgECAhEA01fiRe1k2R6LEQCcImIMYTANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgxMTE4MDAw MDAwWhcNMTkxMTE4MjM1OTU5WjArMSkwJwYJKoZIhvcNAQkBFhpndGF5bG9yQHRuZXRjb25z dWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANgOhvncDgc4KAlD +pyhFpw6wCfeERlSOAXowjdTjlOR2zcIgzL0TM9A+hkSv2wsVh6fn6VvHGxKrLemReiGd7fQ 15Y9J/pxKOmShkw9DDtFsa18ozydp95X2IuzY8Z2JukxouqrfpSH4fOrrHLkOgvlFG4xaQHW 0KB8xUP5DFWyyZM5QCdq278GSJ5pUd+B6qmzwHESNF6syyvgLppXkFatLTz8pWf6eEngDA0Y 3fQ3Q2gnbgpryRhVQMa1GjQJ7LDroUGQhX2zBWePW+sShiTwo8jADYKsbgSGtvZ/42A8zxyg s9YZMHQoCeeuLNuX/MBp9rCTl5nlzP3jGWQTC5ECAwEAAaOCAfAwggHsMB8GA1UdIwQYMBaA FIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQg2PeEKxHWd4FaHe0T+gqAOWkC1jAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t b2RvY2EuY29tMCUGA1UdEQQeMByBGmd0YXlsb3JAdG5ldGNvbnN1bHRpbmcubmV0MA0GCSqG SIb3DQEBCwUAA4IBAQCPxlHHG57PA5GUYlQuC8VHB7TcMQeEJKnB/S+bamyrck4vpIEaF9rG EM+OnAQsJzSkSVHD2707jxh1ng0jrsH2+F9qNGTpCksXo0fMqm4tf28Ag092+CZ5sfdjVZ4E ELG4xNhFZF9/aFaAY7RIeJ89Vvn6s6BnKsaAPjVB/sO+5gIm0BIeoVauq71ue6jS7o2Jn94o BuAhjuh34gk/Wxzcku96MLmEwCY63GWWKVRYbqrDhqROmnQPdyrDYrU8uD0vb4SAdpSKfRqO DrerlQgX3euyYqcnVJSA8Ec+NdiJrGKXW76C7DrTi7IxDgjIHL+DPyFgtj+p6wYOEkYJwKtp MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBS U0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpY PpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP 1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5 LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy 1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0 dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJ CAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/h k6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWl nhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNm NppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tU U1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR 6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ 16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8ao rYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5 v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIxggQ4MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDTV+JF7WTZHosRAJwiYgxhMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MjYwNTIwNTBaMC8GCSqG SIb3DQEJBDEiBCD+xaFGsj4mxoblr+jEMyDrH8DuvGRf3XfOz7i4U0KcZTBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEE AYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0 ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYD VQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA01fiRe1k2R6LEQCcImIMYTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA01fiRe1k2R6LEQCcImIM YTANBgkqhkiG9w0BAQEFAASCAQAPdFssOzXgeLLTG04UXPnBZl3F/R8X6DmbJluJcIWxdwTJ 1RF9Jg/u81Uq332mHl5Tc1b3fXPHKsEZhsO5vQ0hB3QOG1FerjN76L6I/4rNQJRIXct+cciw lD7Psf/CFyjn6f8OfmPFe/vFeym667eM5DIBstS7fhTlSpf5lU7qpH6lfN0GG/l1UyhIN27i JJNcVLKzuS5IwPTnZUvNKPwQsBFhNMpT3bR0+sh2+Y+wKxOoC6znogPmTgDwkm3ONk9w7/KP B9JLaHI5bAoqTSUzazLFYpRPZRWuiLse2O6KmXIF5B/yBNoPrLHVoz53OlWYgJnxxQ706oSd nf7h4AYfAAAAAAAA --------------ms070508030104030305000803-- From nobody Sat May 25 22:28:45 2019 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 0087012011B for ; Sat, 25 May 2019 22:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 AjyV86hFbcm5 for ; Sat, 25 May 2019 22:28:42 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 7E1B4120115 for ; Sat, 25 May 2019 22:28:42 -0700 (PDT) Authentication-Results: mail.aegee.org/x4Q5Sbk5020002; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558848519; i=dkim+MSA-tls@aegee.org; r=y; bh=gLJSK2uLty806SMzQ2YpI2M1zmkAC867Iu051dZpWFs=; h=Date:In-Reply-To:References:Subject:To:From; b=EUm2qx83UR1+3FuuynPUeGfUht44EDEf06/CTwLMzN0g/JBRTd/iFB9mV+bqE5l2Y xmKZgzKLzsGiE5e4Vi1Yg7ubxItyyuTnoPVG/v4OhbwHnOu+B7Eg9Hyp/sF8R9VWzB GAAntKonI9la0sMqKcdiuXx1OsLYThL3FrcUGI/q3sza2IQOmGLWtPDAn0Lkx9KXKs SPdQNeqdGOwaa29D9ic+yIex9vGOBoecQd5hbIVttXtrVNmoZTn40PlHQBTPRLBeyE slx9LCysUxJeJ0zNH/suPYXklluJ4uiSrzy2bK6Rl0f0ZxolAaj2LKBworxfDDEBf3 oq0OOkV4xlz4JZaB2jv5eZoX2KRVBit/BmlHMKfvTnm7DTF3BBVlBArFKpHz6YOfCV QxgnfTk6EL7QXnI93alSwx3ccU0ObRqj8IhASt5kEMKOZer6IIOS5WiR+q0glujYR8 XYUaCNKXK0YT/As8mSGffOzLwp7yMwXxQU5HW5wihQSle9iwmqLyljF6olUxMm0UhY 51BLD5/OpxcvVtp+C7LUATw7njjyEcBTDGWMk8iz/etZhP/dlK2fizCJYCli6xjVZw ahaFJxr4pu5rrxHS7Ycnvm3QCb7keY/CaoMIZhcCPBNSIRRbJxLE3ZTuOXeXuSE7LA tv7l2UM3Q1ilJvtpYAlKpivc= Authentication-Results: mail.aegee.org/x4Q5Sbk5020002; dkim=none Received: from [192.168.1.101] (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x4Q5Sbk5020002 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 26 May 2019 05:28:38 GMT Date: Sun, 26 May 2019 08:28:29 +0300 User-Agent: K-9 Mail for Android In-Reply-To: <26760626-b3f2-b8cd-f31f-d78b487db35c@spamtrap.tnetconsulting.net> References: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> <20190525215318.1580620149E52F@ary.qy> <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> <26760626-b3f2-b8cd-f31f-d78b487db35c@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2FW1RKNTTT5RSLW73UWL8R4DIC1M8B" Content-Transfer-Encoding: 7bit To: dmarc@ietf.org From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Message-ID: <115E2CD4-AF67-4A8D-85BA-567BA74D34A4@aegee.org> X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 05:28:44 -0000 ------2FW1RKNTTT5RSLW73UWL8R4DIC1M8B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Grant, it is a misconfiguration, but it still creates a mail loop for the site, t= hat is not misconfigured=2E To what I can say the emails are accepted at SMTP time and then bounced=2E I not asking to modify DMARC, but to recommend sending message-specific, = individual failure reports FROM: <>, in order to be protected from =E2=80= =9Cmisconfiguration attacks=E2=80=9D=2E Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On May 26, 2019 8:20:50 AM GMT+03:00, Grant Taylor wrote: >On 5/25/19 11:09 PM, Dilyan Palauzov wrote: >> Emails to postmaster@modernwebsite=2Epl are answered with =E2=80=9CUnde= livered=20 >> Mail Returned to Sender=E2=80=9D=2E=C2=A0 The answers do not align to t= he DMARC >policy=20 >> reject, so a new message-specific failure repot is sent=2E > >Are the reports that you are sending being accepted at SMTP time and=20 >then bounced after the fact? > >That sounds like (what I think is) a misconfiguration on their end=2E > >As such, I'm less inclined to think that modifying DMARC is the proper=20 >thing=2E Especially if this is a rare occurrence (as in a very select=20 >candidate)=2E > > > >--=20 >Grant=2E =2E =2E =2E >unix || die ------2FW1RKNTTT5RSLW73UWL8R4DIC1M8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Grant,

it is a misconfiguration, but = it still creates a mail loop for the site, that is not misconfigured=2E
=
To what I can say the emails are accepted at SMTP time and then bounced= =2E

I not asking to modify DMARC, but to recommend sending message-= specific, individual failure reports FROM: <>, in order to be protect= ed from =E2=80=9Cmisconfiguration attacks=E2=80=9D=2E

Regards
= =D0=94=D0=B8=D0=BB=D1=8F=D0=BD

On May 26,= 2019 8:20:50 AM GMT+03:00, Grant Taylor <gtaylor=3D40tnetconsulting=2En= et@dmarc=2Eietf=2Eorg> wrote:
On 5/25/19 11:09 PM, Dilyan Palauzov wrote:
Emails to postmaster@modernwebs=
ite=2Epl are answered with =E2=80=9CUndelivered 
Mail Returned to Sender=
=E2=80=9D=2E  The answers do not align to the DMARC policy 
reject,=
 so a new message-specific failure repot is sent=2E

Are= the reports that you are sending being accepted at SMTP time and
then = bounced after the fact?

That sounds like (what I think is) a misconf= iguration on their end=2E

As such, I'm less inclined to think that m= odifying DMARC is the proper
thing=2E Especially if this is a rare occ= urrence (as in a very select
candidate)=2E


------2FW1RKNTTT5RSLW73UWL8R4DIC1M8B-- From nobody Sat May 25 23:27:47 2019 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 B87A2120099 for ; Sat, 25 May 2019 23:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 1lMWRGoVF6cG for ; Sat, 25 May 2019 23:27:44 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 C7F1A120048 for ; Sat, 25 May 2019 23:27:43 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4Q6Rbp9017615; Sun, 26 May 2019 06:27:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558852058; i=dkim+sm-localhost@aegee.org; r=y; bh=jQkqRwpM07V3Awu8dKhrVtsAzuaWZigpfzyc3/ZJtTQ=; h=Date:From:To:Cc:Subject:In-Reply-To; b=QnownvTD7K9nuLdFD3AaOiYoYQyFB2z2IaaIZKypsXE9wOzLcSDgMg3E1EksWBUs0 +NVhomRJdCkRqeCE9ZcETRw7eI9j5G/p64j04Ih+lX7V1qaXHhBZedK9k5F2qscnM/ K9RkolXZEnjmTFQjZVaxvmG9DpEJwkBt+ws7u76oPkMDai0cpkVc2LjrpAjqlsUHIq XV94pWMb7xxmuu8a3v/BO1XBb1k1DUQQpHt08zJaoqZVG0Yj98AxIZZK8PdcrW1iGm zphgF414HJHXJIKDAR76Dkwvi1FQW1B5cLv8Zh75A54lnUB79z5mciZHbLZgbDx4IN cyc71o9k9gHFcdqVXR1OrE/TAb9onll9bZjfvl5yPWIQeYnNunOaxniiQmZ/x+86AT Mx8Uj7LRP92vsoR8BYecyH7hDhB6CbnqQPX48ilO1Da9iSmf1wRTE5mYGu1hOumL53 DqDXLcoBrcniKhZyYB1Y0RU1kv7YpaWclHrIBHRGPLKFa5QrxNIN26praNmHTWo0OI C1uc2d57PBLRyjzIZpbbLsw67SxRbBNl9P/dvtlmDg58IrMSHKlCoic38Yblkd+/hy ZWhk60nr9J9rNWTc82pZJFVxHMMXP6fwQdUe74Vy+pxH1vq0ZYdXT2Tf61AbQgZeI6 Vc0CBzTopbW17azb5KCIESUw= Authentication-Results: mail.aegee.org/x4Q6Rbp9017615; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Sun, 26 May 2019 06:27:37 +0000 Date: Sun, 26 May 2019 06:27:37 +0000 Message-ID: <20190526062737.Horde.9pyk978ud1nkcO9wThyPbab@webmail.aegee.org> From: Dilyan Palauzov To: "Douglas E. Foster" Cc: dmarc@ietf.org In-Reply-To: <1ee3bd2ebd204746a0d0641e186ca8a8@bayviewphysicians.com> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Improving feedback using additional status codes 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, 26 May 2019 06:27:46 -0000 Hello Douglas, RFC 7372 describes these status codes. To my knowledge these are not used. SPF helps on DMARC with MTAs, which cannot include DKIM signature under circumstances (e.g in bounces). In all othercases SPF does not provide added value to DKIM. If you want errors about failed DKIM validation, remove the SPF records, set DMARC policy reject and scan your logs for rejected messages to see on which messages DMARC/DKIM have failed. Regards Дилян ----- Message from "Douglas E. Foster" --------- Date: Sat, 25 May 2019 15:42:57 -0400 From: "Douglas E. Foster" Reply-To: fosterd@bayviewphysicians.com Subject: [dmarc-ietf] Improving feedback using additional status codes To: dmarc@ietf.org > The genius of DMARC, as compared to DKIM and SPF alone, is the feedback > component. Unfortunately, sender authentication remains challenged by > these issues: > Limited deployment of DMARC feedback between senders and receivers. > Significant levels of SPF and DKIM validation errors, on legitimate > mail, even when indirect mail is not involved. Handling false positives > becomes a significant obstacle to implementation of Sender Authentication > by receivers. > When the sender has not implemented DMARC, the recipient has difficulty > communicating with the sender about Sender Authentication problems. > Finding a knowledgeable employee is difficult and time consuming, so it > will rarely be attempted. (And I have tried it.) > I propose two improvements to deal with this issue. The first is to > define another feedback mechanism using message reception status code. > The second is intended to reduce DKIM verification errors, and will be > posted later. > > PROPOSAL > > When a recipient detects an SPF or DKIM problem, it can provide immediate > feedback to the sender with message status codes. I think these are a > complete list of the conditions which would need a result status defined. > The approach should be entirely upward-compatible with the existing > infrastructure. > > Message Success with SPF warning > Accepted despite SPF=NONE & Source IP not in MX list Accepted despite > SPF=NEUTRAL Accepted despite SPF=SOFTFAIL Accepted despite SPF=FAIL > Accepted despite SPF TempError Accepted despite SPF PermError > Message PermFail because of SPF > Rejected because of SPF=NONE & Source IP not in MX list Rejected > because of SPF=NEUTRAL Rejected because of SPF=SOFTFAIL Rejected because > of SPF=FAIL Rejected because of SPF TempError Rejected because of SPF > PermError > Message TempFail because of SPF > TempFail due to SPF TempError > > Message accepted despite DKIM > Accepted despite DKIM PermError Accepted despite DKIM TempError > Message PermFail because of DKIM (not recommended) > Rejected because of DKIM PermError Rejected because of DKIM TempError > Message TempFail because of DKIM > TempFail because of DKIM TempFail > > Since DMARC evaluation is based on SPF and DKIM evaluated together, the > above codes would seem applicable even with DMARC enforcement. I think > these additional codes should be sufficient: > DMARC PermError (invalid policy record) DMARC TempError (problem > retrieving policy record.) > Is this reasonable? > > Doug Foster ----- End message from "Douglas E. Foster" ----- From btv1==0498d9d9e55==fosterd@bayviewphysicians.com Sun May 26 05:22:37 2019 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 ABCA012006E for ; Sun, 26 May 2019 05:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 GBPovdH5qSmk for ; Sun, 26 May 2019 05:22:35 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1265120020 for ; Sun, 26 May 2019 05:22:35 -0700 (PDT) X-ASG-Debug-ID: 1558873353-11fa3116c81aaf90001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id pHOfAjjNtPALcW9Q (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 26 May 2019 08:22:33 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=ys5nqNV0zB4jagJhOMunop6R468ITpo2V4eHkJOMOuU=; b=RzaShgr3QMt8b7ZkIcmW2Pxn6iXzTB0tMXmgyhhroeHGpD7/p8TBt/k8fitKTcrez oZe8Ts69HDFtwKRCNeUCVUNRnVX9/NQx2lnGPOas9e6o3WboZdhuaK4Q7rYkqWQjp xfBSH5RmIsHkEUY7p8KpwRVRlhzSa4gVXPLvmwxQ8= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 26 May 2019 08:22:25 -0400 From: "Douglas E. Foster" To: Date: Sun, 26 May 2019 08:22:25 -0400 X-ASG-Orig-Subj: Debugging and preventing DKIM failures- suggestion Reply-To: fosterd@bayviewphysicians.com Message-ID: <433a2fcbcab9452d8ca4b3ac99dc5b71@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ecf6790311b34b3f8ac2d72534e92b5a X-Originating-IP: [192.168.71.218] X-Exim-Id: 433a2fcbcab9452d8ca4b3ac99dc5b71 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1558873353 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5660 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 26 May 2019 12:23:26 -0000 This is a multipart message in MIME format. --ecf6790311b34b3f8ac2d72534e92b5a Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Problem DKIM verification failures are difficult to debug because the recipient cannot detect where the problem occurred or why. Proposed Solutions 1) Identify the point of failure It would seem helpful to support a DKIM trace record that a device can use to indicate that it detected a DKIM failure. I am suggesting a header of the form "DKIM-InputFail", followed by the contents of the signature header that could not be verified. This puts an upper bound on the location of the problem. (Once the failure is documented, it should not be repeated by downstream servers.) A downstream MTA is still free to evaluate the original signature. For example, an intermediate MTA may have reported the failure incorrectly because of a software bug. 2) Recover from Subject header changes that break signatures. One expected cause of DKIM verification errors is Subject header modification, either by spam filters or by list servers. These types of changes can also be mitigated by trace headers. If a device makes a change to the subject, it should add headers for "Subject-AsReceived" and "Subject-AsSent". Any downstream system can then reconstruct which header text was in place when any signature was applied, regardless of how many Subject header changes occur during transmission. Downstream servers would also have the option of restoring the Subject header to its original value. This would be appropriate when the Subject was tagged by the spam filter upon arrival to an administrative domain, and then is auto-forwarded to a different administrative domain. If the outbound MTA restores the original subject, it increases the likelihood that the message will be accepted downstream. The concept could be applied to other headers. For example, I have seen messages with DKIM failures because an auto-forward server replaced the internal Message-ID with one of its own. I don't know if there are legitimate reasons for intermediate MTAs to tamper with other headers. --ecf6790311b34b3f8ac2d72534e92b5a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
 
Problem
 
DKIM verification failures are diffi= cult to debug because the recipient cannot detect where the problem occurre= d or why.
 
Proposed Solutions
 
1) Identify the point of failure
 
It would seem helpful to support a D= KIM trace record that a device can use to indicate that it detected a DKIM = failure.  I am suggesting a header of the form "DKIM-InputFail&qu= ot;, followed by the contents of the signature header that could not be ver= ified.  This puts an upper bound on the location of the problem. = (Once the failure is documented, it should not be repeated by downstream s= ervers.)
 
A downstream MTA is still free to ev= aluate the original signature.   For example, an intermediate MTA= may have reported the failure incorrectly because of a software bug. =  
 
2) Recover from Subject header chang= es that break signatures.
 
One expected cause of DKIM verificat= ion errors is Subject header modification, either by spam filters or by lis= t servers.   These types of changes can also be mitigated by trac= e headers.   If a device makes a change to the subject, it should= add headers for "Subject-AsReceived" and "Subject-AsSent&qu= ot;.  Any downstream system can then reconstruct which header text was= in place when any signature was applied, regardless of how many Subject he= ader changes occur during transmission.
 
Downstream servers would also have t= he option of restoring the Subject header to its original value.  &nbs= p;This would be appropriate when the Subject was tagged by the spam filter = upon arrival to an administrative domain, and then is auto-forwarded t= o a different administrative domain.   If the outbound MTA r= estores the original subject, it increases the likelihood that the message = will be accepted downstream.  
 
The concept could be applied to othe= r headers.   For example, I have seen messages with DKIM failures= because an auto-forward server replaced the internal Message-ID with = one of its own.   I don't know if there are legitimate reasons fo= r intermediate MTAs to tamper with other headers.
 
 
 
--ecf6790311b34b3f8ac2d72534e92b5a-- From nobody Sun May 26 06:22:54 2019 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 07DE112006B for ; Sun, 26 May 2019 06:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 LmDsRfPVshEk for ; Sun, 26 May 2019 06:22:50 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 38DFD120020 for ; Sun, 26 May 2019 06:22:49 -0700 (PDT) Authentication-Results: mail.aegee.org/x4QDMgn9019771; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558876965; i=dkim+MSA-tls@aegee.org; r=y; bh=g8u2psBoa3l0Rka5na5dfGJZGRny/hBvfXClGctskPs=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=XsKuK3wH2aVpas/DaKMYocjIK290WFO6u6cVqSGpVmtDSM7IQduesKszIqqUjzJqe 0U87pO6qSGzobXZLRJz2cJ55BxH+2K0ekhjB6Px3Dvo/MhcSwX2OI3XuDhenCmmqy+ alcKJkz29KDLfNEp5IM8VCPTIUL8omkqcYEcmEXtKWCUbzcj+qPZWH9gPQQXWa+ixw +CWRem9kyKU+UyA6LROgk6TgPGpdPCAafLjsu1zYfJ+G9/9U+Ieami1NERO/OubzWb kIO+zsLjnh5v8LWDSaU1bMJBfA321Bc6SBvTAzDh6xtNlJFJctSJGpUMtQul3W14f2 mG9BL2iOv2Y5R3vMD6TJOvEIdNGhCYG4w+Yh+Tq5oEQ6x4n5fZ11xkqD3hsBn3Hfla oFixiMuwuzhdTm8T9S3rvokZcHiHu3UM3gpIUczJXyZZ2ILt0R/w9wkf5Z3f74rXEu FiFssSy8Q4HljcHncGhypP3OozvE9azx8iChBBz2pv6ptj9aQrT3XCfWOXm2DGkRJM xu3V9sp/tacG+7sokDMgmvyR9L+cdSrmuWQC+h22mIf0xTUXhiHJ8Hjszu/efXBym4 +bp2CJf+Kz4BS1S0B3tIODAgthRVPAzL0xqHgceYvIvqP65ZcGnEQpINiY1+fA4CoI Q79imw4pN257gYvUGVHS/6GI= Authentication-Results: mail.aegee.org/x4QDMgn9019771; dkim=none Received: from [192.168.78.125] (90-154-194-202.ip.btc-net.bg [90.154.194.202]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x4QDMgn9019771 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 May 2019 13:22:43 GMT Date: Sun, 26 May 2019 16:22:40 +0300 User-Agent: K-9 Mail for Android In-Reply-To: <433a2fcbcab9452d8ca4b3ac99dc5b71@bayviewphysicians.com> References: <433a2fcbcab9452d8ca4b3ac99dc5b71@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2Q1AXCA6PYE5HQCLSYY64MF1VJTNVA" Content-Transfer-Encoding: 7bit To: fosterd@bayviewphysicians.com CC: dmarc@ietf.org From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Message-ID: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 26 May 2019 13:22:53 -0000 ------2Q1AXCA6PYE5HQCLSYY64MF1VJTNVA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Douglas, 1) Check the Authentication-Results header=2E An implementation could put = there additional information as comment=2E A downstream MTA will reevaluate= the DKIM-Signature anyway, if it does nkt trust the previous hop=2E Common= case: aliases to random servers=2E 2) Check ARC, https://tools=2Eietf=2Eorg/wg/dmarc/ =2E 3) To fix the origin of a bad dkim signature problem the sender has to be = notified about the inconsistencies so that the sender can take actions and = correct the signing process, asuming the problem is not on verifier=E2=80= =99s side=2E Propagating and logging the mismatched signature does not help= correcting the source of the problem=2E Part of the DKIM magic is the volume of papers one has to read in order to= understand it, and fix whenever something goes wrong=2E Here come other em= ail protocols: submit, mta-sts, dane for smtp, dmarc, https://starttls-ever= ywhere=2Eorg/, wrong certificate purpose =E2=80=A6 and you end having very = few people being able to understand and correct a problem, even when all th= e necessary informarion can be extracted from logs or error reports=2E If y= ou cannot run different dkim verifiers towards a single dkim-signature with= corresponding message, and if the sender repeatedly does not answer on ema= ils, no further normative text helps you=2E By the way, why writing you directly earlier today I got as reply '=E2=80= =9Creason: 550 Sender IP reverse lookup rejected=E2=80=9D? Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On May 26, 2019 3:22:25 PM GMT+03:00, "Douglas E=2E Foster" wrote: >=20 > Problem > =20 >DKIM verification failures are difficult to debug because the recipient > >cannot detect where the problem occurred or why=2E > =20 > Proposed Solutions > =20 > 1) Identify the point of failure > =20 >It would seem helpful to support a DKIM trace record that a device can >use=20 >to indicate that it detected a DKIM failure=2E I am suggesting a header >of=20 >the form "DKIM-InputFail", followed by the contents of the signature >header=20 >that could not be verified=2E This puts an upper bound on the location >of=20 >the problem=2E (Once the failure is documented, it should not be >repeated by=20 >downstream servers=2E) > =20 >A downstream MTA is still free to evaluate the original signature=2E =20 >For=20 >example, an intermediate MTA may have reported the failure incorrectly=20 >because of a software bug=2E =20 > =20 > 2) Recover from Subject header changes that break signatures=2E > =20 > One expected cause of DKIM verification errors is Subject header=20 >modification, either by spam filters or by list servers=2E These types >of=20 >changes can also be mitigated by trace headers=2E If a device makes a= =20 >change to the subject, it should add headers for "Subject-AsReceived" >and=20 >"Subject-AsSent"=2E Any downstream system can then reconstruct which >header=20 >text was in place when any signature was applied, regardless of how >many=20 >Subject header changes occur during transmission=2E > =20 >Downstream servers would also have the option of restoring the Subject=20 >header to its original value=2E This would be appropriate when the >Subject=20 >was tagged by the spam filter upon arrival to an administrative domain, >and=20 >then is auto-forwarded to a different administrative domain=2E If the= =20 >outbound MTA restores the original subject, it increases the likelihood > >that the message will be accepted downstream=2E =20 > =20 >The concept could be applied to other headers=2E For example, I have >seen=20 >messages with DKIM failures because an auto-forward server replaced the > >internal Message-ID with one of its own=2E I don't know if there are=20 >legitimate reasons for intermediate MTAs to tamper with other headers=2E > =20 > =20 > > =20 ------2Q1AXCA6PYE5HQCLSYY64MF1VJTNVA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Douglas,

1) Check the Authentication-= Results header=2E An implementation could put there additional information = as comment=2E A downstream MTA will reevaluate the DKIM-Signature anyway, i= f it does nkt trust the previous hop=2E Common case: aliases to random serv= ers=2E

2) Check ARC, https://tools=2Eietf=2Eorg/wg/dmarc/ =2E

3) To fix the origin = of a bad dkim signature problem the sender has to be notified about the inc= onsistencies so that the sender can take actions and correct the signing pr= ocess, asuming the problem is not on verifier=E2=80=99s side=2E Propagating= and logging the mismatched signature does not help correcting the source o= f the problem=2E

Part of the DKIM magic is the volume of papers one = has to read in order to understand it, and fix whenever something goes wron= g=2E Here come other email protocols: submit, mta-sts, dane for smtp, dmarc= , https://starttls-everywhe= re=2Eorg/, wrong certificate purpose =E2=80=A6 and you end having very = few people being able to understand and correct a problem, even when all th= e necessary informarion can be extracted from logs or error reports=2E If y= ou cannot run different dkim verifiers towards a single dkim-signature with= corresponding message, and if the sender repeatedly does not answer on ema= ils, no further normative text helps you=2E

By the way, why writing = you directly earlier today I got as reply '=E2=80=9Creason: 550 Sender IP r= everse lookup rejected=E2=80=9D?

Regards
=D0=94=D0=B8=D0=BB=D1= =8F=D0=BD

On May 26, 2019 3:22:25 PM GMT+= 03:00, "Douglas E=2E Foster" <fosterd@bayviewphysicians=2Ecom> wrote:=
 
Problem
 
DKIM verification failures are diff= icult to debug because the recipient cannot detect where the problem occurr= ed or why=2E
 
Proposed Solutions
 
1) Identify the point of failure
 
It would seem helpful to support a = DKIM trace record that a device can use to indicate that it detected a DKIM= failure=2E  I am suggesting a header of the form "DKIM-InputFail", fo= llowed by the contents of the signature header that could not be verified= =2E  This puts an upper bound on the location of the problem=2E  = (Once the failure is documented, it should not be repeated by downstream se= rvers=2E)
 
A downstream MTA is still free to e= valuate the original signature=2E   For example, an intermediate = MTA may have reported the failure incorrectly because of a software bug=2E&= nbsp;  
 
2) Recover from Subject header chan= ges that break signatures=2E
 
One expected cause of DKIM verifica= tion errors is Subject header modification, either by spam filters or by li= st servers=2E   These types of changes can also be mitigated by t= race headers=2E   If a device makes a change to the subject, it s= hould add headers for "Subject-AsReceived" and "Subject-AsSent"=2E  An= y downstream system can then reconstruct which header text was in place whe= n any signature was applied, regardless of how many Subject header changes = occur during transmission=2E
 
Downstream servers would also have = the option of restoring the Subject header to its original value=2E  &= nbsp;This would be appropriate when the Subject was tagged by the spam filt= er upon arrival to an administrative domain, and then is auto-forwarde= d to a different administrative domain=2E   If the outbound = MTA restores the original subject, it increases the likelihood that the mes= sage will be accepted downstream=2E  
 
The concept could be applied to oth= er headers=2E   For example, I have seen messages with DKIM failu= res because an auto-forward server replaced the internal Message-ID wi= th one of its own=2E   I don't know if there are legitimate reaso= ns for intermediate MTAs to tamper with other headers=2E
 
 
 
------2Q1AXCA6PYE5HQCLSYY64MF1VJTNVA-- From nobody Sun May 26 07:44:45 2019 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 BF8C6120135 for ; Sun, 26 May 2019 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bpmdalxG; dkim=pass (1536-bit key) header.d=taugh.com header.b=KPSHgA76 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 S5AaNs3ArKEW for ; Sun, 26 May 2019 07:44:42 -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 03E3D120043 for ; Sun, 26 May 2019 07:44:41 -0700 (PDT) Received: (qmail 94825 invoked from network); 26 May 2019 14:44:40 -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; s=17267.5ceaa658.k1905; i=johnl-iecc.com@submit.iecc.com; bh=cdqmoAPh1TuD30miI7JFvaSYOMd62ughSpu9zIA40Ws=; b=bpmdalxGo0usOjKEEZBqiXtj5UYSu9O5f+6cGQlb39BMqSDX3FIx7hQFBc1+Q033wRT2FF6YSN6Oqtum/m0cYxw2uwvaE2QpR08rkGUiZtHfp85aBVxtiL14svHjaJZUo7+RCqvZl17+CY1hb7NN99Mcv3goUalgy6l5gR6QarRM6sTilVnYGEQPQMUJ4wDVfRSGIyau6WSkg8uq4s385gTLsPhpvj2JNQVvuqxRCWnwRaVi0/CfRbwUmFCIg37s 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; s=17267.5ceaa658.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=cdqmoAPh1TuD30miI7JFvaSYOMd62ughSpu9zIA40Ws=; b=KPSHgA76IkR9ohkobCpgD+0THMDyR0C4Lf/bhS7qbiGleF7tLfJkaQurBnmr601SDS/iO6lC5t4+Vb+ezpWtVHQ6G6TJBY2fIaDk1HukHDbZt0MVsIdg+Ka6hjEDM2+Hvh4KevVkCaRWrxY70FW/GOXG0ObxJpyGeEVO07gv0+NRXCscP9RfiJQGQF9VBFn3vHB0zq2JMVnEQyJQaxVxS2+FWWQ0ryyF91z/w/jvzQXdxS4QOLCUgmSJG2BpxF36 Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 26 May 2019 14:44:40 -0000 Received: by ary.qy (Postfix, from userid 501) id C059D2014A0B4D; Sun, 26 May 2019 10:44:39 -0400 (EDT) Date: 26 May 2019 10:44:39 -0400 Message-Id: <20190526144439.C059D2014A0B4D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org In-Reply-To: <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 14:44:44 -0000 In article <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> you write: >Hello John, > >in case of modernwebsite.pl: > >DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100; >rua=mailto:postmaster@modernwebsite.pl; >ruf=mailto:postmaster@modernwebsite.pl; aspf=s;adkim=s;" > >Emails to postmaster@modernwebsite.pl are answered with “Undelivered >Mail Returned to Sender”. The answers do not align to the DMARC >policy reject, so a new message-specific failure repot is sent. Just out of curiosity, where do the reports come from? I see their SPF record says "mx a". From nobody Sun May 26 07:46:14 2019 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 970BB120135 for ; Sun, 26 May 2019 07:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dnlyjR8k; dkim=pass (1536-bit key) header.d=taugh.com header.b=nvh5X0nu 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 xPOAmWVaKDC1 for ; Sun, 26 May 2019 07:46:12 -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 E2F21120043 for ; Sun, 26 May 2019 07:46:11 -0700 (PDT) Received: (qmail 95106 invoked from network); 26 May 2019 14:46:11 -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; s=17380.5ceaa6b3.k1905; i=johnl-iecc.com@submit.iecc.com; bh=SQMys9UMDL6XQeJ+JTBUzutnPAa0iJQRselM20ZFJos=; b=dnlyjR8kPG2KGMBABQc7usS014zJ3WVw/Z5NmX5j+3WFUKMCWEP1P11o0645y0zeQ90BLm3gAR/FStB3ScbCw/Rlngosb8ZGkwzqDm8HAmuQ7Y37c7aAI+fmA/QifWR6JtHwFvepEBYC3Ujs+pitBAIuLgtytQw99JIN++UamgIQgveSQBomwKrk1PUIgV0TCQRv+l9xCmkUP2FiO83xrBExM9oiiwEs/Cqwgj/HRFHKh/Xwm42C6bwI0elP0iDI 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; s=17380.5ceaa6b3.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=SQMys9UMDL6XQeJ+JTBUzutnPAa0iJQRselM20ZFJos=; b=nvh5X0nus45+5+08tXM7+ZxjWalnodTM0QbBvBthYvMZiIuVguButiiHQA+uvLDwb2u/cjiLlemi6QR4stxfh+szbPz9bKT0r8RzSC1OyPdzp4j2gvWRAVYFYsRQ98LbWTWQ6kSoHG81UxJQuI3yZErTR+aiY87VLfh5rM27/3hUDpDMQzwgREmBtyHFgQdEykPEU0S1Efdth+Hs2W8ZekUC5tv8Vf4BmaE8uXNWLV0xXEOeiuKZBGe8jOTAF8FA Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 26 May 2019 14:46:10 -0000 Received: by ary.qy (Postfix, from userid 501) id 706282014A0BB0; Sun, 26 May 2019 10:46:09 -0400 (EDT) Date: 26 May 2019 10:46:09 -0400 Message-Id: <20190526144610.706282014A0BB0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org In-Reply-To: <115E2CD4-AF67-4A8D-85BA-567BA74D34A4@aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 14:46:14 -0000 In article <115E2CD4-AF67-4A8D-85BA-567BA74D34A4@aegee.org> you write: >-=-=-=-=-=- > >Hello Grant, > >it is a misconfiguration, but it still creates a mail loop for the site, that is not misconfigured. > >To what I can say the emails are accepted at SMTP time and then bounced. > >I not asking to modify DMARC, but to recommend sending message-specific, individual failure reports FROM: <>, in >order to be protected from “misconfiguration attacks”. Given that we've seen one report loop in seven years, my inclination would be to suggest that you simply blackhole whatever IP their bounces are coming from and leave it at that. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun May 26 07:48:53 2019 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 78873120135 for ; Sun, 26 May 2019 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=vMlh4VU7; dkim=pass (1536-bit key) header.d=taugh.com header.b=3zl3IFru 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 ndGws7oRtkRr for ; Sun, 26 May 2019 07:48:49 -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 9EFFF120043 for ; Sun, 26 May 2019 07:48:49 -0700 (PDT) Received: (qmail 95532 invoked from network); 26 May 2019 14:48:48 -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; s=17528.5ceaa750.k1905; i=johnl-iecc.com@submit.iecc.com; bh=v/ya4HKGEcRkjP0IoK2IJ6mRamUHXiWFUNWslyfa+Gc=; b=vMlh4VU7e1KoKDWQ2Y+561CdrD+7+04GkTrb++XP/X46NWnVPBsDBqlKEXm1SKY6iki8pWw42496WflNnTcOQJBhjm7eUNBdtEM8n++IORl4/CpV7sFo4MU+oqZmIU6wTzx5fg3oSJbhCvfpD9fGs4vAqrFdHBkoOkKFNaqIEKLa9AW4j6O6rQQrhVh6KmvNv97MkqOijUa+ph8WRXAX3p0mInktpr1Wc/41bhhpAvH/qw3d5wS6jQdQWxnuDOfI 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; s=17528.5ceaa750.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=v/ya4HKGEcRkjP0IoK2IJ6mRamUHXiWFUNWslyfa+Gc=; b=3zl3IFruFFR3c8xI5fyxDUZnbZ8HzbzEjd+jM9K9lUiakBCX6pctC8+jHK5G2FAqyPibPvEwQ29mn1Rpy3G2/29u+anBpYhVq0Sdu0K/OjnUQT1OcR+BsTDv/8XBGyQe+w/GbVnmkImH4qqH/ytfNkAdzBI0BNbHh1EzZDM+DT/k8pMsOP8bYvMJ2/PD/KJIXuS3qqariFsvs9KgEsdHTgQoA/t2bgpN7vICvxOGRwgZX3TyuU4NwMLmc5d0djGl Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 26 May 2019 14:48:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 08A772014A0BF4; Sun, 26 May 2019 10:48:47 -0400 (EDT) Date: 26 May 2019 10:48:47 -0400 Message-Id: <20190526144848.08A772014A0BF4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org In-Reply-To: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 26 May 2019 14:48:52 -0000 In article <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> you write: >-=-=-=-=-=- > >Hello Douglas, > >1) Check the Authentication-Results header. An implementation could put there additional information as comment. A >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust the previous hop. Common case: aliases >to random servers. That would be my suggestion. You can put whatever you want into comments in the A-R header. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun May 26 07:51:34 2019 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 CB608120043 for ; Sun, 26 May 2019 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LU1mtNnr; dkim=pass (1536-bit key) header.d=taugh.com header.b=BwOfpyKp 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 1OySPWqi8Xma for ; Sun, 26 May 2019 07:51:31 -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 1B775120135 for ; Sun, 26 May 2019 07:51:31 -0700 (PDT) Received: (qmail 96071 invoked from network); 26 May 2019 14:51:29 -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; s=1773d.5ceaa7f1.k1905; i=johnl-iecc.com@submit.iecc.com; bh=pi+skv9MftnVaKNd1d46V5KPLyCFB6UfzUfGY/u8mP4=; b=LU1mtNnrNH9Z5sr/OYMU9v6XO/jVOfUoB650ZiA6Zf8SepK8jRUFmYIO6SPI8uqVQi9V6dUHc9AQEuzMDXKgcec96+r3vcfP7tckZK6eSRHitT+S0XX2NnoBs5ynbhkjNQGDSlLbeXvBGDYejkxC7asg3TuUYLqydbbLsfrGxwxQSxuRATf4yM9h5tXGxI8v/WwjsgeXID3FjLm8AuHd+gSaYmMT4nHBYuIHyCHyYUbiOtQOPyGeKAg0vtH0bHmq 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; s=1773d.5ceaa7f1.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=pi+skv9MftnVaKNd1d46V5KPLyCFB6UfzUfGY/u8mP4=; b=BwOfpyKpJoaSw1TyMYFi+h+aSnwIsc14/JKAj31gJUP2grafThMtVzrho8Crs+Z5oipPGnC31BPRTRfOWw1D3xKX1o8e7GnvbaHMqPe3bksGTwRWy9UkNlXYbqkwtPxvtPFxtp+dl8ZacgK5ijJYWMYjEcCQPrvOt4QTboDgp9ZieU4t1knk5FMAiqDUKKLMc/GhM8bBpbgmRso3+ghx/IziG9mpN+P9pgPoX1yMiwh9cpJYNahZbdHevsyU//V+ Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 26 May 2019 14:51:29 -0000 Received: by ary.qy (Postfix, from userid 501) id 253B22014A0C33; Sun, 26 May 2019 10:51:28 -0400 (EDT) Date: 26 May 2019 10:51:28 -0400 Message-Id: <20190526145129.253B22014A0C33@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <433a2fcbcab9452d8ca4b3ac99dc5b71@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 26 May 2019 14:51:33 -0000 In article <433a2fcbcab9452d8ca4b3ac99dc5b71@bayviewphysicians.com> you write: > 2) Recover from Subject header changes that break signatures. This idea has come up, let us say, once or twice before. If you're trying to undo what mailing list software does and reconstruct the signature, that is a rathole of no return. Also keep in mind that malicious parties can change the signature, too, and there's no way I know of to tell a malicious rewrite from a benign one. ARC is designed to deal with this situation. Take a look. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun May 26 09:15:33 2019 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 B80DC1201A1 for ; Sun, 26 May 2019 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zaPAhXDpMZNb for ; Sun, 26 May 2019 09:15:29 -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 29BE0120090 for ; Sun, 26 May 2019 09:15:29 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id t5so13479072wmh.3 for ; Sun, 26 May 2019 09:15:29 -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=Kgdv0XymMf7evx9z2zyw8LJLJGSglTNMO6pkch7x10I=; b=kez8tFQ6qYJ+zkJRLDN3GBZJXfDWvzb1XBAoobrIBDjxcQuSRoFadGlgdf8HblVKKC 7WJHv+TZ6qCo4zzKoFtwX2kDMmh2z6Q2Je5RDa1Jwea/ywXxVweOzeRW3EC3EpcE85Wl vDOxfAwQTOrYIU+iIEq74KwKPxOG54kXfDRf2V6rWLG/L2QAEwoxQ4rfUx6KBMNS52wX wwnDa7RSoTCUwe3qXI34vA5hkbHA/c6mn58dj+jcORte8Z8cT/ex5JE18F+jKs4vqyJa nI9iWvLZ2acpl9f/Vd/JtIZbePs5KJVIuhmixM8epcH8/Ozh7LalAhkbfckQsdOjiOwO Eqfg== 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=Kgdv0XymMf7evx9z2zyw8LJLJGSglTNMO6pkch7x10I=; b=ffBthiaNksj4jEYjOofi6WvLunW6zTJFu4FFJyuNR5XaVBt2Xb5mFFA6RAxYdyVGtf fK2xLtr9MuJYj6RijfEtFYUGFz4Ihrxy8KuYTvEjPIAida+z0vGAl0tPx1eQDgM9eKRv HQpUF2xsya9dJcwMmIrtA9WUF3bvsEVtLy50gMCQ63as+8vAbBrs0GdDPZmZCIirjdVR Y8WUGXaPwSGciHm9XzYRwutFb4ACGyle0rlJBbv39+I9jnh4VuLtucxAJIwm5km5VJOk JEgFCzu+W/Q37nqPx5qwqndo9tZVvqKnaczOpbDX5D8edp6p6krroENHR03SP8GZ8zDP Gx+w== X-Gm-Message-State: APjAAAXobGNtBIwpAPOaPDwYVfRZJLlygYiElo4t2SpTtFGH/6ktxWVd MJy41mT/LnOSa9wyhcKK00R3hC9coPRAFEFxk4T9dQ== X-Google-Smtp-Source: APXvYqzqDeErlgHj1Ky2Y5Ri3a21dDJPBJoaIaVtPBZE+S/KziBZUSRpHLmTFF25JQnCz3JRjGwHR7+ngU+VwMiPGho= X-Received: by 2002:a05:600c:2116:: with SMTP id u22mr6818472wml.58.1558887327676; Sun, 26 May 2019 09:15:27 -0700 (PDT) MIME-Version: 1.0 References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> In-Reply-To: <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> From: Dotzero Date: Sun, 26 May 2019 12:15:16 -0400 Message-ID: To: Jim Fenton Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006946ab0589ccbdc3" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 26 May 2019 16:15:32 -0000 --0000000000006946ab0589ccbdc3 Content-Type: text/plain; charset="UTF-8" See below. On Fri, May 24, 2019 at 2:39 PM Jim Fenton wrote: > On 5/24/19 11:25 AM, John R Levine wrote: > > On Fri, 24 May 2019, Jim Fenton wrote: > >> I hope this isn't devolving into a "we can't make any changes, because > >> it might break something" argument. > > > > I don't think so, but we also have a tradition of minimizing the > > changes to what's needed. Look at RFCs 2821 and 5321 for example, > > where they deliberately left the section numbering and most of the > > language alone and fit the changes into the existing structure. > > > I consider that to be a different situation because both were Standards > Track. This is situation where we are starting with an Informational > RFC, although granted it has more deployment experience than many things > that go to Standards Track. > > > > >> 1. When an MTA product says that it "supports DMARC", does that mean > >> that it has to support both policy and reporting? ... > > > >> 2. Along similar lines, I get confused when I hear that x% of {some set > >> of domains} has "deployed DMARC". What does that mean? ... > > > > Deploying DMARC seems to mean any subset of these: > > > > 1a. Publish a DMARC record > > 1b. Publish a DMARC record with a restrictive policy > > 2a. Evaluate DMARC status of incoming messages > > 2b. Use that status to manage message disposition > > 3. Collect reports > > 4a. Send aggregate reports > > 4b. Send failure reports > > > > It is my impression that most domains that have "deployed DMARC" have > > done 1b and 3. I've done 1a, 2a, 3, and a very small amount of 2b. > > Only a few sites do 4a and even fewer do 4b. > > > > I'm getting the impression that what we need is a non-normative > > deployment guide, not as part of the spec. > > > Although Section 8 of the spec currently has normative requirements for > implementations. Yes, that's different from deployment but having those > requirements to implement something that isn't deployed much (4a > specifically) seems unnecessarily burdensome. > > I think you are underestimating the deployment. Many receiving/validating > organizations have privacy concerns about promiscuously disseminating > reports. As a result, these organizations limit reports to senders with > which they have either direct contractual relationships or intermediaries > with which they have contractual relationships. Personally I would prefer > to see more and better reporting but I recognize the issues involved. It's > important to recognize that senders publishing DMARC records are indicating > their policy preferences to receivers which choose to validate for DMARC. > Receivers which choose to validate DMARC are not required to provide > records in response to sender requests. I know that reporting is valuable > for senders and to the extent possible we should be finding ways to > encourage and support reporting. > Michael Hammer > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000006946ab0589ccbdc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
See below.

On Fri, May 24, 2019 at 2:39 PM= Jim Fenton <fenton@bluepopcor= n.net> wrote:
On 5/24/19 11:25 AM, John R = Levine wrote:
> On Fri, 24 May 2019, Jim Fenton wrote:
>> I hope this isn't devolving into a "we can't make any= changes, because
>> it might break something" argument.
>
> I don't think so, but we also have a tradition of minimizing the > changes to what's needed.=C2=A0 Look at RFCs 2821 and 5321 for exa= mple,
> where they deliberately left the section numbering and most of the
> language alone and fit the changes into the existing structure.


I consider that to be a different situation because both were Standards
Track. This is situation where we are starting with an Informational
RFC, although granted it has more deployment experience than many things that go to Standards Track.

>
>> 1. When an MTA product says that it "supports DMARC", do= es that mean
>> that it has to support both policy and reporting? ...
>
>> 2. Along similar lines, I get confused when I hear that x% of {som= e set
>> of domains} has "deployed DMARC". What does that mean? .= ..
>
> Deploying DMARC seems to mean any subset of these:
>
> 1a.=C2=A0 Publish a DMARC record
> 1b.=C2=A0 Publish a DMARC record with a restrictive policy
> 2a.=C2=A0 Evaluate DMARC status of incoming messages
> 2b.=C2=A0 Use that status to manage message disposition
> 3.=C2=A0=C2=A0 Collect reports
> 4a.=C2=A0 Send aggregate reports
> 4b.=C2=A0 Send failure reports
>
> It is my impression that most domains that have "deployed DMARC&q= uot; have
> done 1b and 3.=C2=A0 I've done 1a, 2a, 3, and a very small amount = of 2b.=C2=A0
> Only a few sites do 4a and even fewer do 4b.
>
> I'm getting the impression that what we need is a non-normative > deployment guide, not as part of the spec.


Although Section 8 of the spec currently has normative requirements for
implementations. Yes, that's different from deployment but having those=
requirements to implement something that isn't deployed much (4a
specifically) seems unnecessarily burdensome.

I think you are underestimating the deployment. Many receiving/validati= ng organizations have privacy concerns about promiscuously disseminating re= ports. As a result, these organizations limit reports to senders with which= they have either direct contractual relationships or intermediaries with w= hich they have contractual relationships. Personally I would prefer to see = more and better reporting but I recognize the issues involved. It's imp= ortant to recognize that senders publishing DMARC records are indicating th= eir policy preferences to receivers which choose to validate for DMARC. Rec= eivers which choose to validate DMARC are not required to provide records i= n response to sender requests. I know that reporting is valuable for sender= s and to the extent possible we should be finding ways to encourage and sup= port reporting.

Michael Hammer=C2=A0

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000006946ab0589ccbdc3-- From nobody Sun May 26 09:53:22 2019 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 974BC1200D5 for ; Sun, 26 May 2019 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Me1L+q+R; dkim=pass (1536-bit key) header.d=taugh.com header.b=CyaPM/V/ 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 52dGTx5eTmCt for ; Sun, 26 May 2019 09:53:18 -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 6449E1200CD for ; Sun, 26 May 2019 09:53:18 -0700 (PDT) Received: (qmail 23523 invoked from network); 26 May 2019 16:53:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5be1.5ceac47c.k1905; i=johnl-iecc.com@submit.iecc.com; bh=ySeJG6GZk+zCYW4jkTHrkRapfCEtjPTpP9Htj68C/Ew=; b=Me1L+q+R9l5BpLweWgJnYP43Dzi8AME2EBRtBv48tL1DK77/I9xaKCOtEPN2ctEGVhCxFCCwKW5Gu2c11UjcT63O/CpTq/YLmK6wyEf0Vxa0Svi8kHieotQ/IW2ceX6Bwteg6fY8Y230egD0A104/nFcKodHd862LQN1tMx90lvSP7VouRADqwqm1Kl+kL1kdeVV3hV2sIGy5HZRbc/yVKRMdBgRrDy/PLxpSEGETBd8UgC7u4a5I0KOXwkfyNaz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5be1.5ceac47c.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=ySeJG6GZk+zCYW4jkTHrkRapfCEtjPTpP9Htj68C/Ew=; b=CyaPM/V/rauRzW8zSQgr0d9hBtbWor+7HJH3fzhyCm6BnGyCu3VoXnTD0nt+HEBTrtYmHiQLNfac38Dbqaxylb7F5U0/u+uiG9mzVl+edkeq4a2YesnwZccA2TzQYJ50hLG4uzMGbnKdENgdayosgSyVu38knAhePyLruHBwXIFC/tI5shBV+N6ag+pN7NYWWOIIKmkosC8IRYYNDvmsT+6MeAxP/yDhTsn2ZPa9eXzE5WXGtJwc1SDK0OczL1C4 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 26 May 2019 16:53:16 -0000 Date: 26 May 2019 12:53:15 -0400 Message-ID: From: "John R Levine" To: "Dotzero" Cc: "IETF DMARC WG" In-Reply-To: References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <4e4a59d7-e652-48f1-feb1-09d948c3eb04@bluepopcorn.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 26 May 2019 16:53:21 -0000 On Sun, 26 May 2019, Dotzero wrote: >>> Deploying DMARC seems to mean any subset of these: >>> >>> 1a. Publish a DMARC record >>> 1b. Publish a DMARC record with a restrictive policy >>> 2a. Evaluate DMARC status of incoming messages >>> 2b. Use that status to manage message disposition >>> 3. Collect reports >>> 4a. Send aggregate reports >>> 4b. Send failure reports >> I think you are underestimating the deployment. Many receiving/validating >> organizations have privacy concerns about promiscuously disseminating >> reports. As a result, these organizations limit reports to senders with >> which they have either direct contractual relationships or intermediaries >> with which they have contractual relationships. Personally I would prefer >> to see more and better reporting but I recognize the issues involved. It's >> important to recognize that senders publishing DMARC records are indicating >> their policy preferences to receivers which choose to validate for DMARC. >> Receivers which choose to validate DMARC are not required to provide >> records in response to sender requests. I know that reporting is valuable >> for senders and to the extent possible we should be finding ways to >> encourage and support reporting. Still sounds like a deployment guide would be useful, no? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun May 26 12:01:04 2019 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 E14EE1200FE for ; Sun, 26 May 2019 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 mo2BeH4CzY-1 for ; Sun, 26 May 2019 12:00:59 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 CF0E31200FB for ; Sun, 26 May 2019 12:00:58 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4QJ0ueN019839; Sun, 26 May 2019 19:00:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558897256; i=dkim+sm-localhost@aegee.org; r=y; bh=P+POL1E+J0Y+kdM0WcuHMMMGCp9Ro5uRarCBxi1B/9w=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZjqTNz/0/V2mw9fZWFnpjMSqYHXlhvvvy1ko1802DOFmgDP2sTVH8g6kYPfo2506O 3icHOMuHN3vZ41vv1Ge1Rn6pvODipEn17viB6KI3jJOZOs/Z6A+SSodQQj0OcPQnnS uubaqThLM0gjbsBwJrf01AE8BKlzJOHR9rs1c/iRX4cs/AWuC/kQlk98A2QehEx3jg gZsfzSV1OlzRGE/IEfdigNVci06ovJcbSvBJOnVANXJKeKidsz5afY+otoPiKYlEK5 mcRKIBNnCcW0K3nMyiklC/OhUWfX6PUoByrK5kO9vbnlQ98UXC0Mixz1l0BT1uzFwc oDQcSRLtZFgIqeLBDlYO5K6b1lkrZuosbmn/+YcYL+VTn+Y+54PwxbS+ZVcmaEaIFY MMSFCLoS7EoZEOHGOTye9clWiuWmtQLosafrJrQYMaFKqGlT9EjhQ/Wmlgan3jpquZ xdkIvVtDsQPNQSUnuN3zlVR9/wBPMOlmqcSExhG2EbuB5bWqMpGM/xC6CgqV1jCdzH NkzgQc+CGwBcPq+NAfiGfcVFF/hDdxz2q8kxzo3FvPNNFKyrzgQhWz4w8C35qSt89H pD9w+Q/A+JyshIOXXWrnFrunrSibkmcVmnFb+BpnukvLBLnJzfOao7RgKCKcvTR5re j/gkJjajz6XtQQcafMjQIh/M= Authentication-Results: mail.aegee.org/x4QJ0ueN019839; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Sun, 26 May 2019 19:00:56 +0000 Date: Sun, 26 May 2019 19:00:56 +0000 Message-ID: <20190526190056.Horde.eosw0oHN3SdnNASHChwrn88@webmail.aegee.org> From: Dilyan Palauzov To: John Levine Cc: dmarc@ietf.org References: <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> <20190526144439.C059D2014A0B4D@ary.qy> In-Reply-To: <20190526144439.C059D2014A0B4D@ary.qy> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 19:01:02 -0000 Hello John, at SMTP level the server communicates EHLO mail.modernwebsite.pl and ENVFROM:<>. There is no TXT record for mail.modernwebsite.pl so SPF fails and cannot align. The email itself contains “From: MAILER-DAEMON@modernwebsite.pl (Mail Delivery System)” without DKIM signature. ⇒ DMARC validation fails. You can give it a try and send yourself a message to “postmaster@modernwebsite.pl”, the answer will be (expanded from ): unknown user: "template" Unfortunately I had another loop back in September 2018. I do not remember the details. Given that this can happen again to somebody else, it is better to have recommendation sending the message-specific reports with FROM:<> or NOTIFY=NEVER, or at least some text elaborating on the attack. Regards Дилян ----- Message from John Levine --------- Date: 26 May 2019 10:44:39 -0400 From: John Levine Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org > In article > <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> you > write: >> Hello John, >> >> in case of modernwebsite.pl: >> >> DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100; >> rua=mailto:postmaster@modernwebsite.pl; >> ruf=mailto:postmaster@modernwebsite.pl; aspf=s;adkim=s;" >> >> Emails to postmaster@modernwebsite.pl are answered with “Undelivered >> Mail Returned to Sender”. The answers do not align to the DMARC >> policy reject, so a new message-specific failure repot is sent. > > Just out of curiosity, where do the reports come from? I see their > SPF record says "mx a". > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ----- End message from John Levine ----- From nobody Sun May 26 14:27:04 2019 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 B7E041200A1 for ; Sun, 26 May 2019 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sapienti-sat.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 75xAKNxwV2e1 for ; Sun, 26 May 2019 14:27:01 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [IPv6:2a01:4f8:221:43c5::2]) (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 D5E91120131 for ; Sun, 26 May 2019 14:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:to:subject:subject; s= dkim20170413; t=1558906017; bh=nFETcuSxLtLKPtHue91u/o9gn1sNfsb4p ojclShdNqg=; b=wGzaFXSVyOR5jEKe7pS9uwgI3EPvZz/qmGHBawVcb7ZruG6hG NqI4pCMfFZu5v9Bgoqee3gOmoV4r1cE3hK4L9y7k9BaHNLii/Ai7qxdvcrDTJ3ua 5yIxG/UyyLf0mb1Go8/vzs2oL+C6tdp2XS1Z8Vqe8D2ODGHjh8nhaS053H0BJ5eI DW6koFpBVpG6bi3/EPx9mnAO8WTemyaDVtTz+bjvFr6fO1sMVC+N0dkWXAjaPZEr iypfxOKZQOYmvBMXdqtQ3hrhYCYKNiDBFGZlrUf+azxWo2r1FhPIng/6VPvCG1Ch SPZfPGNsZm1QBY73Ux4P6AUQ0LWIM36ImPG6g== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2001:470:6d:e38::100] (boot0.home.sapienti-sat.org [IPv6:2001:470:6d:e38::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id 2344133E00D5 for ; Sun, 26 May 2019 23:26:57 +0200 (CEST) To: dmarc@ietf.org References: <20190525215318.1580620149E52F@ary.qy> From: Juri Haberland Openpgp: preference=signencrypt Autocrypt: addr=juri@sapienti-sat.org; prefer-encrypt=mutual; keydata= mQGiBEpkkU0RBACvs80AZxmG2dlbE8uFuRtWaGbvdlTKzwn4s37Sc98yNzDr57btydCdasf8 OvctyUrngCuC/JmBDw9MpNVVRJ2lLOSi7r5JgjXSbpeW95UKUnQk2m/+nRkNPrKY0FXhP4VE 04lmV3vb0cKpi3Iuceuc4U/PkwlbfzvMCqMJp/zGGwCgqnxsnNu+MOEPB1zum0pT1ZmZptEE AJkzjTYdnt4zarO0K8Yk9BMy39puGMuW6HD4MiN1DfkqH9RYe7qh6L8DasmSed/TlVNpsH+y fdhwD/9f+8Ifc1vpFjgcm9mEmJqyjpQTKG9oQE1KpcnHXKwG/Gr/lXrQbgiiungc+d18tafN yAKQfmkKIDqFVmKPjlOJHWYN7qlKA/0R3/6RyerO84hsLt6jFWeOm/9KEh6WfnoooDQhAq7M sFjCNUoF32x/hpabB9MqF6vcl/Ka8Dmdj95Ae10K9MD5L7TNaWkL7FepFptcCkHonLQQM4E2 vDAJtyyKUaQiOPw80oEOMISXzQD78Vbg6Q9nmsmkpuSAUVTqUksTTwtnNrQmSnVyaSBIYWJl cmxhbmQgPGp1cmlAc2FwaWVudGktc2F0Lm9yZz6IYAQTEQIAIAUCSmSRTQIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheAAAoJED9MVq+NNYZCRlAAn38ddF0pjwOZR0VyoIe4UpfpZV5fAKCO o87TVyYoBYwru4hunuVMOpXgG7kCDQRKZJFTEAgAoBRVOPPgl3foNLJn+C8QnuExrwKdeguE 5l2lSw3Fummo9CQCN72gYrqMNksFeIcoWAWclm/8bA551KWum8g2TjTA7NuVdIvzahr8MFGi oBNktr1GLAJ2SNpzyUA3fICIJqXdUdlvnjk4olQE6ACylbxDT+2x5HVzvhxw1fvz4c4JRvnP J1q2/LMu6sgBta6cgVTzYzBvxf1JyjbHsFKZSJZ+3JO3AO5y40XbU+EZVT60ChbU8GCJEVer 2RFlYfYSdniSxgQPuYVxZsfXgQlv0xQ3QTTDLU9jpJJX4EfwfWaio01X3l8QqIBtVpu07ZXI klOJk1QXC3HDIhAt/uGdVwAEDQgAmK0fEhrg/HY2Zs2VXIkWViS8I68sAw/GRGAsif0pkHTx dQ2oEZYMK1bNW7VFBphby554hUAmvwcCCUso0INqiw0sXs6ZARL3nT6QPc3uU0jMFpg1cWHf yElUopAR0S0kxVfShE3fNKOnizTPcRboCLOVZzuM1BxVO55Dkc9fPX1zik9hzJjbG4bzEqNG cg7+EY0YqeEVFccyRXsjvFRTl4ckvCMhsyqGwE8AnwFOYJXqfbLjEDSBngblniWTEjZ47t5p rN6sri7+sWIUaybzdINKGZMijndTVccMtRvbbx62+0dRoxUV2GIrNcCOvQ7e5Q4/vL8okoK9 MZMUWQnUeYhJBBgRAgAJBQJKZJFTAhsMAAoJED9MVq+NNYZCX74An2lQsova+seE0su7vK2y GGyRrnQdAJ9nvrSrslx2qcHkRycgYoFozVkRsw== Message-ID: <30e0f076-cd4e-ee88-6a7f-8923c4978963@sapienti-sat.org> Date: Sun, 26 May 2019 23:26:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190525215318.1580620149E52F@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 26 May 2019 21:27:02 -0000 On 25/05/2019 23:53, John Levine wrote: > We've had failure reports for almost seven years and I don't ever > recall someone getting into a mail loop so it's not a problem in > practice. I had at least two or three mail loops caused by failure reports sent to some small sites (as my is) and that was the reason for me to stop sending failure reports. Just my 2 cents, Juri From nobody Sun May 26 21:46:46 2019 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 5D08A120114 for ; Sun, 26 May 2019 21:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=G36v3eW1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=HMYsWo4V 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 031h_okegd74 for ; Sun, 26 May 2019 21:46:42 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532461200EB for ; Sun, 26 May 2019 21:46:42 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 56B3EF80820; Mon, 27 May 2019 00:46:40 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1558932400; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=zMlJv6quWS9RoO8D0Ojw74d5mCyspCYhZ2zdGT/ZLE8=; b=G36v3eW1sDfk0hUS2pnzpWEP2MxfVK/wA9bHrpDA+lwkfUh7sjRzEBuA Iiaxj+LEN3Ki1yn5LrCfcd4bg1s8CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1558932400; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=zMlJv6quWS9RoO8D0Ojw74d5mCyspCYhZ2zdGT/ZLE8=; b=HMYsWo4VfiguR2t5K7YfIEvFxsfxDIxcfMrgPXN6FFXY37KfB/ATixHi OFbdI9nG5Xhfu+6Q9Plg6wXWxJ4UHkAVH5jowOTLL6LBfvsLzAWgvhoL+2 8jaL5wdBXUwEA1V1+vj1IGdLtF2n65zaCrYiqzR3IbV2Mgsv/ymNHstLdM MiZg3esbTRyDvQMPgKK2hGtuUU8XnOiBjl0q6WYkRfTZDB5dz0EBNU3VVN JYLAVPdKdCqlxhwvBo68gTr25Wdnu7sMnsCCeIgCSOWqn7o/tLrYGVxSjH Y3M2MkRw1AjcWYwwOXNFhSzZspuEbH3GJhTrhk4iO+r0IOciWxcKUQ== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 1D598F8074A; Mon, 27 May 2019 00:46:40 -0400 (EDT) Date: Mon, 27 May 2019 04:46:38 +0000 In-Reply-To: <20190526190056.Horde.eosw0oHN3SdnNASHChwrn88@webmail.aegee.org> References: <20190526050958.Horde.6VaAxRZKGLqyeJ4Uov0vrXR@webmail.aegee.org> <20190526144439.C059D2014A0B4D@ary.qy> <20190526190056.Horde.eosw0oHN3SdnNASHChwrn88@webmail.aegee.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <08EEA97F-F915-4DC1-A88D-FD7CEB71533B@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 27 May 2019 04:46:44 -0000 They should publish an SPF record for mail=2Emodernwebsite=2Epl=2E Publish= ing SPF to support HELO checks has been recommended since before RFC 4408= =2E I'm pretty sure that avoids the problem=2E You'd get an SPF pass and = it would align=2E Scott K On May 26, 2019 7:00:56 PM UTC, Dilyan Palauzov wrote: >Hello John, > >at SMTP level the server communicates EHLO mail=2Emodernwebsite=2Epl and = =20 >ENVFROM:<>=2E There is no TXT record for so SPF =20 >fails and cannot align=2E > >The email itself contains =E2=80=9CFrom: MAILER-DAEMON@modernwebsite=2Epl= (Mail =20 >Delivery System)=E2=80=9D without DKIM signature=2E =E2=87=92 DMARC valid= ation fails=2E > >You can give it a try and send yourself a message to =20 >=E2=80=9Cpostmaster@modernwebsite=2Epl=E2=80=9D, the answer will be > (expanded from >): > unknown user: "template" > >Unfortunately I had another loop back in September 2018=2E I do not =20 >remember the details=2E Given that this can happen again to somebody =20 >else, it is better to have recommendation sending the message-specific=20 > >reports with FROM:<> or NOTIFY=3DNEVER, or at least some text =20 >elaborating on the attack=2E > >Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > > >----- Message from John Levine --------- > Date: 26 May 2019 10:44:39 -0400 > From: John Levine >Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC =20 >message-specific failure reports FROM:<> ? > To: dmarc@ietf=2Eorg > Cc: Dilyan=2EPalauzov@aegee=2Eorg > > >> In article =20 >> <20190526050958=2EHorde=2E6VaAxRZKGLqyeJ4Uov0vrXR@webmail=2Eaegee=2Eorg= > you=20 > >> write: >>> Hello John, >>> >>> in case of modernwebsite=2Epl: >>> >>> DNS TXT _dmarc=2Emodernwebsite=2Epl is "v=3DDMARC1; p=3Dreject; pct=3D= 100; >>> rua=3Dmailto:postmaster@modernwebsite=2Epl; >>> ruf=3Dmailto:postmaster@modernwebsite=2Epl; aspf=3Ds;adkim=3Ds;" >>> >>> Emails to postmaster@modernwebsite=2Epl are answered with =E2=80=9CUnd= elivered >>> Mail Returned to Sender=E2=80=9D=2E The answers do not align to the D= MARC >>> policy reject, so a new message-specific failure repot is sent=2E >> >> Just out of curiosity, where do the reports come from? I see their >> SPF record says "mx a"=2E >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc > > >----- End message from John Levine ----- > > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc From nobody Mon May 27 10:23:54 2019 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 C95AB120006 for ; Mon, 27 May 2019 10:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 seojxfv_LDbi for ; Mon, 27 May 2019 10:23:51 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 6068E120043 for ; Mon, 27 May 2019 10:23:51 -0700 (PDT) Received: from [IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd] ([IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4RHNleq031322 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 May 2019 10:23:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558977829; bh=kG3s3ycQCRvD78oMtt2wxC1wMljOkvuwSg6iKwYvgJI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jzgikz/Kkx65O0tPZIpFg5LqAISiI1XVNZUXUVofbQf7fOm7kfMMAJcltj7HFMIoC ST9V/SLZnUVMki75NUYnz+hQH/qr/d8NBzc3JHuJbjqO3Ey25JvkXg9sJJ4NOZ7Jbx bWoXxQJXOZybrAXGthPvomx+ZvFvckTCKLnZ/c5A= To: Dave Crocker , John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> From: Jim Fenton Message-ID: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> Date: Mon, 27 May 2019 10:23:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 17:23:53 -0000 On 5/25/19 1:53 PM, Dave Crocker wrote: > > Ultimately, you are asking marketing questions, not technical ones. OK, so let me ask a technical question: What is the technical justification for the requirements in Section 8? For other protocols, there are mandatory-to-implement requirements (RFC 6376 section 3.3 for example) that exist in order to ensure interoperability between senders and receivers. But implementation of DMARC policy and DMARC reporting can separately be useful without the other. Aren't the requirements in Section 8, which effectively say "you need to do this and this to call yourself a DMARC implementation" really a marketing, not a technical consideration? Does this belong in the spec? -Jim From nobody Mon May 27 11:20:08 2019 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 9E71712008A for ; Mon, 27 May 2019 11:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 842wTMl3LmuH for ; Mon, 27 May 2019 11:20:05 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 1CC0112001B for ; Mon, 27 May 2019 11:20:04 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4RIJvHk022973; Mon, 27 May 2019 18:19:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1558981197; i=dkim+sm-localhost@aegee.org; r=y; bh=4AAzbfP8RPFKIRteV6VooM8n3Kt5LTTdPiEXZQIIO3A=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=NjzKF1IkwPcrOuOct3z2IvGGunLDM34tiNdtm725Y8lAtMtUOEKRq/8+Pj5YYvvpC gpTeW1qY17ECn6E6i01JI7VfVLczObA67SY9aSOeztOhFowDqBD72q3u6vtKKhzpyB 5oHk/P1qh4AMXuIssFS591hbA2hFs9I3RnJjQctMbz47Ta2mkb9cRBzPh61YI9Zk3p s0AVasI4vigWhEseeUb41ftMn0S6rerleV7VNyfNhQ+8KWKLqwMjM/xeYaM5zi4IOW 9zY1Pufv2TcMGFS/qNcsxoDE6WzycpBMM1jgApLhs4IeVNpoBMfiU83gQYYFY9bF73 1gCahsOreyt2me4wM2lgl2ICJ5i7JCPiz+/sqPfATq09zfJqDA2OyM/8reKskVe5EX Y/xGJQ+2TIEOOp4MiNTHbYAjHqzbnUcc8DMPICDiexS0nyUkzpMoA/STSpxaokc0bF KOX3Gf2kBliJVYpY3J0Z14GkHQDZdC6iGlGRfyVT+Ianqcz16Gibx+gWuRVfbRCFBR RP93zC8CYb+gjse6aTFQC2gSxak/jcGWc219DmHFxRhnn/T4YUx92THHyOjuZ0cJz+ RzruWnLY8Om3toWCMIKwgp+S2+Bps/knDuuSaJqlP4lMljXsUGy6UdhkPmAoz/F9bG n/hY2IQCqQ1y1YiJ8ck0ST1I= Authentication-Results: mail.aegee.org/x4RIJvHk022973; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Mon, 27 May 2019 18:19:57 +0000 Date: Mon, 27 May 2019 18:19:57 +0000 Message-ID: <20190527181957.Horde.ERQnFG0Wm3s5gJcNB6IU7Zs@webmail.aegee.org> From: Dilyan Palauzov To: Jim Fenton Cc: Dave Crocker , John R Levine , dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> In-Reply-To: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 18:20:08 -0000 Hello Jim, Do you want to split yourself reporiting and policy and create two separate documents, or do you know somebody wiliing to perform the separation? I cannot imagine why shall one want to read and understand only reporting or only policy and thus I do net understand for which target group will be these separated documents. The current documents are suitable to achieve their aim. (Well, to contradict myself, I would like to read and understand all the RFCs, so a single RFC containing all current RFCs would be enough, but obviously, I cannot read and understand such RFC). if you implement DMARC filtering on incoming emails you get less spam. If you implement DMARC filtenig on outgoing emails (say publish policy p=reject), you deploy DKIM and then some trust/reputation can be built in the DKIM domain, similar to IP reputation, so that your future emails are more likely to be delivered, at least in theory. You do not have interest to name this magic anyhow, you have interest on getting less spam and higher deliveribility of your emails. You do not have to implement section 8 in order to achive the aforementioned goals. When filtering incoming emails, obviously, without having to articulate this explicilty, you have to follow section 6.6. To verify that your DMARC works as expected, the reports mentioned in section 8 are a nice mean. You can call your product a DMARC implementation even if it does not do DKIM signing/verifying correctly. Why do my mails for johnl@taugh.com get rejected, unless I send them over the MLM? A propos “Is there any recommendation to send DMARC message-specific failure reports FROM:<>”: * Scott, the purpose of such a recommendation is to have a system, which does not cause mail loops, ending with stored copies of 60 000 sent reports. If that site published TXT record for mail.modernwebsite.pl, it does not ensure that in half an year I will not enter another mail loop (half an year ago I had a similar one). * I do sent now my reports ENV FROM:<> and from the correspondence so far neither somebody said that there is such a recommendation already, nor that such a recommendadion is bad. The purpose of the <>-recommendation is to prevent others falling in such a mail loop trap. Under this circumstances I put the case under “Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization”. Regards Дилян ----- Message from Jim Fenton --------- Date: Mon, 27 May 2019 10:23:42 -0700 From: Jim Fenton Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy To: Dave Crocker , John R Levine Cc: dmarc@ietf.org > On 5/25/19 1:53 PM, Dave Crocker wrote: >> >> Ultimately, you are asking marketing questions, not technical ones. > > > OK, so let me ask a technical question: What is the technical > justification for the requirements in Section 8? For other > protocols, there are mandatory-to-implement requirements (RFC 6376 > section 3.3 for example) that exist in order to ensure > interoperability between senders and receivers. But implementation > of DMARC policy and DMARC reporting can separately be useful without > the other. > > Aren't the requirements in Section 8, which effectively say "you > need to do this and this to call yourself a DMARC implementation" > really a marketing, not a technical consideration? Does this belong > in the spec? > > -Jim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ----- End message from Jim Fenton ----- From nobody Mon May 27 11:20:59 2019 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 6AAC1120043 for ; Mon, 27 May 2019 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DiBTBzWi; dkim=pass (1536-bit key) header.d=taugh.com header.b=ibHR+Wdv 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 RJCPpL4QQiqO for ; Mon, 27 May 2019 11:20:55 -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 A072512001B for ; Mon, 27 May 2019 11:20:55 -0700 (PDT) Received: (qmail 28464 invoked from network); 27 May 2019 18:20:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6f2d.5cec2a85.k1905; i=johnl-iecc.com@submit.iecc.com; bh=9BPQ7MGR+VEt8rH1ruiQSPXFAqK8ODY49r8Qucj/eK4=; b=DiBTBzWiWmFBYP8cm1e6xY8WwXaWorh3oqFDMzJnlOFZ/ZNND9I+aRI0PbX6G0Y6Xf/8tyBJG7fcMiM9NdK7JsL8u3mV0jJ6tVrmsopKBykRyr/sRBVivnenubpxaOMKf8v30y42qmypiPBcDywnqZtqwBiv3DjVue3kJ4SfeU8N35fE3liWDDchujeoGmjdp/eescyBIUhIdX3jrSoizQbX8HiZEkzwZr4rPWlndN9W7VXPTpHHoZlALL47urIi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6f2d.5cec2a85.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=9BPQ7MGR+VEt8rH1ruiQSPXFAqK8ODY49r8Qucj/eK4=; b=ibHR+Wdvuz+NXqOh6a56uoBDD1cuKosQnM6yTXh398/Ypmufev+7ghPF/Rs4iBLV4odNliTHKJq4mmtiD72bURoDz9ttWrbJx7rj5nL+Ue+t1tQp52gdPEOrfHVUVaq8NVJ4KfTYabKLqZcHKwT8OKF8tC3BXVEAYPL+iah015DnjObyozk3r7AAUKSNftWlPTPFbvfyLeqcAICNCFfuOdlkJuasR/ghj9eVhEPJn/bW8uE69jsKTSMGZA+vb0Vs Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2019 18:20:53 -0000 Date: 27 May 2019 14:20:52 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 18:20:57 -0000 > Aren't the requirements in Section 8, which effectively say "you need to do > this and this to call yourself a DMARC implementation" really a marketing, > not a technical consideration? Does this belong in the spec? I agree that it'd makes sense to remove it, or rewrite it to say it's about identifying what you're doing, not about compliance. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 27 11:25:21 2019 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 9C40E12009E for ; Mon, 27 May 2019 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 dQJmHZyI9ROU for ; Mon, 27 May 2019 11:25:19 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 3792B120041 for ; Mon, 27 May 2019 11:25:19 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id t187so12451894oie.10 for ; Mon, 27 May 2019 11:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tTvSm61Ms6YG64Bs8TbEGLMPS4SrNP8jlUP8tGD+/5g=; b=AJ7rAwvhX43ib4hPWS+bqVyxB/X9vCwmSTP5OrgJRwoScDszbRu4QJVIvrIASBfH3u AfWsBjNcHpsnzTD65fRpaaLRqT7vpSw0jwHmLLSWBXh9dsBhx4lT9q15KyJX4MRTMetz hKaTKFMQ4YLIxj+I1tqwqE7cosDS68SPai2Q3MUzmrxZxhnj0J5A1BjB5ERrUcNz7gDC 0NVUa/wmfjnu5YTagoNLAVl7IkkoTYZk4uMgNeyEJ97FLzKXpYJg5TYUG862oBAmoVkD S5q+oEC4JpUTRUYC10gXYwJWTC/5Z3PlxXzBxjqWPkmFvcYmHE8qexL9+M1KZhM2ribC NopA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tTvSm61Ms6YG64Bs8TbEGLMPS4SrNP8jlUP8tGD+/5g=; b=EPUv8+0ta5lghl/sLjW8Ru8+L3mViUFj+R4fbHZCLPTfjSlDSP3zb4G4u+NLRj2m8I dAAuJ66W3C7HZC4IKnUgowomNum2Rd4l+lP+Tu40T3MFalidJXdNjsGJEdSZP5NOAx7D dB0vwD//5s79JYenr8iiaL7up58eDHIkSBW0OTmVt+fPNK0tXi1XhBw+GRmoMhb5VS5C OK9brbwUE7/pWs8rr7eay13qHt2E3va1E9KLaeMb/+Wn2MCqV2aZxUfxNuGdIvSrScH0 Bj8pXJWJnik+5lRhW6tgKIFxPrXuSUjuWJ2kU2hWwNISN0JZz4wUPg+EiCEfp7an/l3h 3trw== X-Gm-Message-State: APjAAAXGe6uZ6yjhgZqFrsWTvXaSCjHEvx+QrvmNSVT6EuRUQy4M1GKN thIwITbQf7UGVRUPW//NisWZrLRRVek= X-Google-Smtp-Source: APXvYqzrwhrJdD971Ms19s7Ei9v+0ym63A7YuTo2kkuidBRxe6enLoNrUgvkv5FcvURzVaPkSCw72A== X-Received: by 2002:aca:7549:: with SMTP id q70mr216542oic.58.1558981517639; Mon, 27 May 2019 11:25:17 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:cb:6602:ff02:8d00? ([2600:1700:a3a0:4c80:cb:6602:ff02:8d00]) by smtp.gmail.com with ESMTPSA id 62sm4396425oid.35.2019.05.27.11.25.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 11:25:16 -0700 (PDT) To: Jim Fenton , John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> From: Dave Crocker Message-ID: Date: Mon, 27 May 2019 11:25:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 18:25:21 -0000 On 5/27/2019 10:23 AM, Jim Fenton wrote: > On 5/25/19 1:53 PM, Dave Crocker wrote: >> >> Ultimately, you are asking marketing questions, not technical ones. > > > OK, so let me ask a technical question: What is the technical > justification for the requirements in Section 8? For other protocols, A section like that typically seeks to establish a basis for minimum capability of usable implementations. It sets expectations for capabilities and limits. An amusing bit about this particular one is that, in spite of having the word "requirements' in the section title, none of the content language is normative. > there are mandatory-to-implement requirements (RFC 6376 section 3.3 for > example) that exist in order to ensure interoperability between senders > and receivers. But implementation of DMARC policy and DMARC reporting > can separately be useful without the other. I don't understand how your last sentence, here, applies to the subject Section 8. > Aren't the requirements in Section 8, which effectively say "you need to > do this and this to call yourself a DMARC implementation" really a > marketing, not a technical consideration? Does this belong in the spec? "to call yourself" is a perspective neither offered nor implied by the section. A marketing goal might choose to use it for that purpose, but there's nothing in the language or substance of the section suggesting that use or designed for that use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon May 27 12:13:39 2019 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 6F1D4120043 for ; Mon, 27 May 2019 12:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nvq8qH8y; dkim=pass (1536-bit key) header.d=taugh.com header.b=pMXhQWGN 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 LiKZHbEiNusU for ; Mon, 27 May 2019 12:13:35 -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 8570812001A for ; Mon, 27 May 2019 12:13:35 -0700 (PDT) Received: (qmail 38547 invoked from network); 27 May 2019 19:13:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9690.5cec36dd.k1905; i=johnl-iecc.com@submit.iecc.com; bh=3dfTvJB/eplRhpl6Rx//pLNNWdZga1Ug+fuj8ndbzA0=; b=nvq8qH8y23udolQetjB3+vlf4/sAKtvVrxP80dJCRh62NNg0EdNMwXwUReiowrK/4IyV+XVX660bhPTLgnm3rijLFJRTp6/j0OIg9Yyv9+XvuVxXpsBppHbJSqzqOYHHcP08IMyZCHpxYVlc/8MYMChIiS+lQwp0M2JZI3duiVTMmOG9603HrYtwFDNtI582VKPzFgmdXIWTHPBU+mcCuX6gL7C/hZn2/wEyZQjNPU3Uu8w3ryBNBvwlXfoft47p DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9690.5cec36dd.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=3dfTvJB/eplRhpl6Rx//pLNNWdZga1Ug+fuj8ndbzA0=; b=pMXhQWGNplG0/5swyuXyxI7gj4l2k9wcOcEn2AYbxp+TBVF6C+hTgbT/O8ttWQ7hG7CZ3NCprXjdg4QXP2we7iBwzC9Ql02OHzYmHL8QyRsLh7S//l+/tBe6CIiweqf2gME+0Wng0f0FiultvUGiZRdIH+Mifrb6PV+HBW5jKZ1umsyFChG6rjZES2fNEpi3v8kghS9LPHUDhLp/hNqx1cpbm5psnL7vFsfR3WVezNbeALqAJQ1qdnE9b+wdWYqM Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2019 19:13:33 -0000 Date: 27 May 2019 15:13:33 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 19:13:38 -0000 >> On 5/25/19 1:53 PM, Dave Crocker wrote: > A section like that typically seeks to establish a basis for minimum > capability of usable implementations. It sets expectations for capabilities > and limits. An amusing bit about this particular one is that, in spite of > having the word "requirements' in the section title, none of the content > language is normative. It's certainly confusing. I understand what the list of items is but I don't understand what anyone is supposed to do about them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 27 12:21:57 2019 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 9FB5012009E for ; Mon, 27 May 2019 12:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=jGZXKeD2; dkim=pass (1536-bit key) header.d=taugh.com header.b=xpzaD1P2 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 yXgUZCgpI_FH for ; Mon, 27 May 2019 12:21: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 4ED55120043 for ; Mon, 27 May 2019 12:21:52 -0700 (PDT) Received: (qmail 40425 invoked from network); 27 May 2019 19:21:50 -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; s=9de7.5cec38ce.k1905; i=johnl-iecc.com@submit.iecc.com; bh=kip6uL1jHwZzMDZ/xaboZFu3Yh+pNVAojCoXnOHvtbs=; b=jGZXKeD2v2P880WJdaPZVj3p2FTVy87OF94TGIiwZjYPXYQtS6eGqGVFsVx5Yscm/GB/GTjvG19gB5qwwVgtB2TqjCDh3dyY6RCh5dMhlwDPnReX2YJk9sHZr06Sod2IwZ9ONYBMBXew1EnMbbhAhw69pF+d16QeN0ISce6Sml6j5LEOLfuoNr80Jyk1EHezXrUFyK31n8le+kO9NdtzIySEnbcscQOpQ4sbetgpO2cHw0PoxghUfOKCUey4COPb 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; s=9de7.5cec38ce.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=kip6uL1jHwZzMDZ/xaboZFu3Yh+pNVAojCoXnOHvtbs=; b=xpzaD1P2oYrOv0B4bNCG3cS/eYlUB8xaJRXa/sMwZnB02SyJc/TeGsBQKFsJwQL0UoiIG7AqyxhURbgTbn+bXUpPjxF3zhU3wzcpucUb7jczT/aOIuCHrYXM1/wSLjcV8egCygaUnJmhJpaAKBmwl1MN7x/OUlq6KACPSCdxoS0o6ve30/ZIZIpZFVXWC2auoaZrfHJVfbPcrU2/p3yTdzNySaiBCZii1xwV1itoDnGueAgNOtylOugV63ZjW6Eu Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 27 May 2019 19:21:50 -0000 Received: by ary.qy (Postfix, from userid 501) id 079992014AD8E9; Mon, 27 May 2019 15:21:49 -0400 (EDT) Date: 27 May 2019 15:21:49 -0400 Message-Id: <20190527192150.079992014AD8E9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: Dilyan.Palauzov@aegee.org In-Reply-To: <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] mail loops, Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? 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, 27 May 2019 19:21:55 -0000 In article <20190525183556.Horde.zvg1bNsYbvs_enKZPKjlhVV@webmail.aegee.org> you write: >Consider this scenario: an email from a domain, with DMARC policy >“p=reject; ruf=postmaster@domain” fails validation. A >message-specific report is sent to postmaster@domain. The report is >bounced (or there is any reply on it) and the reply is again From: >that domain and does not validate DMARC. On further consideration, I was reminded about all the mail loops I had to deal with back when I was running autoresponders. What I discovered is that there is nothing you can put in your messages which will prevent mail loops, since there will always be someone at the other end that will respond anyway. What you have to do is rate limit. For example, if you see that you've sent more than five failure reports in an hour to a particular address, don't send any more reports to that address during the next hour, even if mail comes in that would get a report. You can tune the time period and threshhold, but so long as the time period is longer than a cycle of the mail loop, they don't matter much. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 27 12:23:00 2019 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 7CAE91200B9 for ; Mon, 27 May 2019 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=GkEX1k0g; dkim=pass (1536-bit key) header.d=taugh.com header.b=iHYRWLtu 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 3udqEbQxl7Wv for ; Mon, 27 May 2019 12:22:56 -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 9A221120043 for ; Mon, 27 May 2019 12:22:56 -0700 (PDT) Received: (qmail 40848 invoked from network); 27 May 2019 19:22:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=9f8c.5cec390f.k1905; i=johnl-iecc.com@submit.iecc.com; bh=Gg4uG1eFfGfM7NrcM8Lc5KNWg9AtmEtApxR5GPJ7IgQ=; b=GkEX1k0gCWcKTnabFRgitQLOu9kXH7IgE2T8r9ueO7r9YYLRs/OAI/mIfMSDkkmjMVSXV4IGZRCuP7IjS3dZ+4Y3laFdhTGcy+ujRu5OLU+cV6HsJmpufKjQ2YIYdT2/6cElvxi/mQj69NQBTro0u6W/szDLAfCFJESIQS4bBLXynCYKiCxdR+mgywjf16tFhvD12hgb7vY8JYV4YYjldzy87l6x+lrlEnCBMxXoRfuIQKdOHqiytOBCJM4/QgxR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=9f8c.5cec390f.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=Gg4uG1eFfGfM7NrcM8Lc5KNWg9AtmEtApxR5GPJ7IgQ=; b=iHYRWLtuwsr8d2F0J2WijKatGP5yWq18yuvKYVMbGVMGEEdZxqv7S6RSnL0mNbPd6swGPyEH3bCDiE9+CzVAXfdSKwtWlr17DEKo1W3cSf2dHR3Hkk/FgZukQPwaAHQ/LZNACgmQIvpvrW8v/knky+ff3qfojnP+wzWP40DphLyx2DX6xsMGdDV9265ds9vZ8ahbsgttstZxTtWxIvFl6Ee16NtrjtAaW/2U5FZHPah8vt2CaFAE5qduo6aoLDnh Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 27 May 2019 19:22:55 -0000 Received: by ary.qy (Postfix, from userid 501) id 2DEAA2014AD91A; Mon, 27 May 2019 15:22:54 -0400 (EDT) Date: 27 May 2019 15:22:54 -0400 Message-Id: <20190527192255.2DEAA2014AD91A@ary.qy> From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] DMARCbis issue: failure report mail loops 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, 27 May 2019 19:22:59 -0000 Apropos recent discussions, we could recommend that failure reports be rate limited per recipient both to break loops and to deter indirect mail bombing. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 27 12:32:08 2019 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 A5EC81200B9 for ; Mon, 27 May 2019 12:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=UhVzCKcU; dkim=pass (1536-bit key) header.d=taugh.com header.b=IoL5B/7y 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 2HsLVEZaNtsy for ; Mon, 27 May 2019 12:32:06 -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 18BEC120094 for ; Mon, 27 May 2019 12:32:06 -0700 (PDT) Received: (qmail 43011 invoked from network); 27 May 2019 19:32:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a801.5cec3b33.k1905; i=johnl-iecc.com@submit.iecc.com; bh=cO+ApSbUs7G+RMIMJ903lZC/mQNFMdpZpCCeqKENoV4=; b=UhVzCKcUxc6tqpKU6P7ANFButvi+3jdIKggE8jFMmKd1TcoRpgEBkFth0QTRAXFlYbTbksYVTqwZMubV5T3BC7d8S47U5n9OgSphV7AmIk+Bcd9hyo7VnxgNoKAzRpDPAeIl+Er2DNPLYuJ0TmRGbP5O89mtz+DktXuY53snpEvf3qn5ehp0Imvwpl5h2eF0oEOnYDPodS0I8Ja2tPwUvICGFPT39Tq2EBgALSaqeefiK9ItMa0yUxRaMm/Rfyl2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a801.5cec3b33.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=cO+ApSbUs7G+RMIMJ903lZC/mQNFMdpZpCCeqKENoV4=; b=IoL5B/7yeuT1RG72hAkqbp+3i+CaDvSHxMZxVN7w7GMiGOUDZ02mOsJogYuQyoouvHXitF8wxusU20JLr/vouVyDQClCp7BMgPU1OXWSrVRCz0rBJ9dHEnWEc4oE89P3ZLyHPdiIfPeFTAL5fVrojDn3AH63omNoeksYsDfqaST4stlNppIMUogfQ/KT7fYnneOqxDxmb1AVk0Z7lcZ3S8fPh/raf2EAm83AVO5KO5HVOz7RwFXNQSFGv5RVM9qD Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 27 May 2019 19:32:03 -0000 Received: by ary.qy (Postfix, from userid 501) id 4B74F2014AD9CA; Mon, 27 May 2019 15:32:02 -0400 (EDT) Date: 27 May 2019 15:32:02 -0400 Message-Id: <20190527193203.4B74F2014AD9CA@ary.qy> From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 27 May 2019 19:32:08 -0000 Section 6.3 says that ruf and rua tags can take any URI, but only define the meaning of a mailto: URI. Either it should define some other URI schemes or it should say that only mailto: URIs are valid. Back in the olden days there was an http or https scheme that we took out because it was ill specified, and nobody but me had tried to implement it. If people are interested in an https PUT scheme it would be easy enough to define one, but only if someone says they want to use it. For large reports it could be somewhat faster than mailto both because the report body isn't base64 encoded and the report goes straight to the https server and doesn't get relayed as mail does. From nobody Mon May 27 12:48:47 2019 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 3B8141200B2 for ; Mon, 27 May 2019 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 d9MgoXZIrGdV for ; Mon, 27 May 2019 12:48:44 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 BE45112003F for ; Mon, 27 May 2019 12:48:44 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id r7so15693014otn.6 for ; Mon, 27 May 2019 12:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=m6DTSeIyZ4Hf0geZjXNziOdqrMFuffEW/uW7tHgqqeI=; b=d9eht37AI4Jbj98Gb2Q0X9oePkZ9kCMFXezrqSlXI3/aw5f+9xwUw3kmCK0Ck4vy52 tvNITcaGgNdAaFquJi5mv7QqQFdRmyh726iSywdueGfvzLWaOjk9QIMEY/lBKmpj5tj0 UvAKFflX4WDa03D8rx0yPdmEqqUPjqXmLR5BZHQDy28T4gWpWQCxu5BumvdScT2yfHbS q3rqvGPffFedPeHSi3uCiibvw7BDumTZIphh/JH8opd1yH0uwgpem/ZLIbdxZdMvxvMr ozRWui32X3yHwMA+FIOfleEqx4niMwEzaYrU9VIK0EI6S+EVMlnt+M4dKcWiA/jKyE8h n6XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m6DTSeIyZ4Hf0geZjXNziOdqrMFuffEW/uW7tHgqqeI=; b=n/3GFsAGdq0wgF3r2KElijj2175YJkPFZLJzuj+mG8TkUDZx4l2Nk6h16xZj0s0I3t FLKcVzrmCOLausj9pxJJb59/u9TN5cDZuqL7a+kmHiceep6IvfPURJQWcyoXQDtFNUeA oR7FBLYdK22sIW70LZ3oNkDgrk792Qb+8bdDolkhLInuKFX12M4JgitCUSiZ0ob6Nx9o hUjq3q8w2euyCtTbW2K6GRw9rFGPeJlAynO4COHkF9oyJ9eScts7Qaowy5c5O7R53PVB ZKQV4qKG6ern099rZJfMEK4T77BqwNgx0H+C3eLrJZMsspeKt6bnyaOcUdsFPpmuHQ/z WubQ== X-Gm-Message-State: APjAAAXU1vIdmOge/2+vPQO96Z9mwVzq/AhEl2PNCbHLf19L7wBATot9 i4XBypovhLe0M5B6C25T6PcsvLWMRlY= X-Google-Smtp-Source: APXvYqzCUCdM17x/6VPM2vJmRQ3MX2bp/EQHW3VuS//3WCwKSQm1jwGcEsilOMWvvTdswWzHwJXHGQ== X-Received: by 2002:a9d:77d9:: with SMTP id w25mr36725245otl.366.1558986523456; Mon, 27 May 2019 12:48:43 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:cb:6602:ff02:8d00? ([2600:1700:a3a0:4c80:cb:6602:ff02:8d00]) by smtp.gmail.com with ESMTPSA id b2sm4069228otp.78.2019.05.27.12.48.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 12:48:42 -0700 (PDT) To: John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> From: Dave Crocker Message-ID: Date: Mon, 27 May 2019 12:48:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 19:48:46 -0000 On 5/27/2019 12:13 PM, John R Levine wrote: > It's certainly confusing.  I understand what the list of items is but I > don't understand what anyone is supposed to do about them. I'm not claiming it's a wonderful section. Merely that something like it isn't that unusual. The usual intent is to help people with expectations about basic capabilities or capacity. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon May 27 13:15:21 2019 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 46B1C120157 for ; Mon, 27 May 2019 13:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 8r-c76GPof5F for ; Mon, 27 May 2019 13:15:17 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E1FDE1200F1 for ; Mon, 27 May 2019 13:15:17 -0700 (PDT) Received: from [IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd] ([IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4RKFEd5000822 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 May 2019 13:15:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558988116; bh=7iJRUybYWnbSyWPU43BwYm0S4STkVvUjAOUSI1NMiN0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RJG8OnTTJ8Tw8fRbP26cdos7Z5WopgjehphR6DLQjHYH5ljk3ud92VigND4pa+dJb THYu6lhRuFWo17aMoYIZOGAtv+vtFVZ8RY4K3b1ptku4IRDfpuPaguwv/Ax9xwVP97 ILVdDPYl2uYd5Uk8IXiv85GMOvz0llf5EjifIlXg= To: Dave Crocker , John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Mon, 27 May 2019 13:15:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 20:15:19 -0000 On 5/27/19 11:25 AM, Dave Crocker wrote: > On 5/27/2019 10:23 AM, Jim Fenton wrote: >> On 5/25/19 1:53 PM, Dave Crocker wrote: >>> >>> Ultimately, you are asking marketing questions, not technical ones. >> >> >> OK, so let me ask a technical question: What is the technical >> justification for the requirements in Section 8? For other protocols, > > A section like that typically seeks to establish a basis for minimum > capability of usable implementations.  It sets expectations for > capabilities and limits.  An amusing bit about this particular one is > that, in spite of having the word "requirements' in the section title, > none of the content language is normative. I hadn't noticed the lack of normative language in this section. In that case I would propose removing it because it does not serve any purpose and because it might mislead others who, as I did, misinterpreted the word "requirements" in the section title. -Jim From nobody Mon May 27 13:16:07 2019 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 337E912014F for ; Mon, 27 May 2019 13:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 hSygLrzHaIbw for ; Mon, 27 May 2019 13:16:05 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 DFFE51200C7 for ; Mon, 27 May 2019 13:16:04 -0700 (PDT) Received: from [IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd] ([IPv6:2601:647:4300:2290:62a4:4cff:fe65:83dd]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4RKBqeP000804 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 May 2019 13:11:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1558987914; bh=ZWsx10zkZxlECLZsZaqbDUJPjf9LyZ41GIZ4hOmTIgQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=IpKQfZr7dQYkgtwAe2dvzmjsH5JfwoM2cfQm39aUFtoqrkq118Dt48OdG1Xku3xSF fbhhcZCB4Oi5a3HuFdFA+8nfMFjLxBCFHGkeTmlEeUM3pzh0SU95cyW85sl/9p1TLi SZk/UVavRszvbdEILZu5mlb31s6lokkaEF4GpZiM= To: Dilyan Palauzov Cc: Dave Crocker , John R Levine , dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <789c58b1-7b45-3af0-dd1b-aca0c415db02@gmail.com> <5f12bf4f-ce25-c2d8-7cab-10eb41182eac@bluepopcorn.net> <20190527181957.Horde.ERQnFG0Wm3s5gJcNB6IU7Zs@webmail.aegee.org> From: Jim Fenton Message-ID: Date: Mon, 27 May 2019 13:11:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190527181957.Horde.ERQnFG0Wm3s5gJcNB6IU7Zs@webmail.aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 27 May 2019 20:16:06 -0000 On 5/27/19 11:19 AM, Dilyan Palauzov wrote: > Hello Jim, > > Do you want to split yourself reporiting and policy and create two > separate documents, or do you know somebody wiliing to perform the > separation?  I cannot imagine why shall one want to read and > understand only reporting or only policy and thus I do net understand > for which target group will be these separated documents. The current > documents are suitable to achieve their aim.  (Well, to contradict > myself, I would like to read and understand all the RFCs, so a single > RFC containing all current RFCs would be enough, but obviously, I > cannot read and understand such RFC). Dilyan, I didn't follow the latter portion of your message entirely, but yes, I think I understand the problems that DMARC filtering and reporting are intended to solve. To your initial question, unless a bunch of other people speak up in favor of the split I'm proposing, it won't have WG consensus so we don't need to consider who does the editorial work involved. -Jim From nobody Mon May 27 15:53:19 2019 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 1F561120025; Mon, 27 May 2019 15:53:17 -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: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155899759708.543.16777184314234317178@ietfa.amsl.com> Date: Mon, 27 May 2019 15:53:17 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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, 27 May 2019 22:53:17 -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 (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-04.txt Pages : 11 Date : 2019-05-27 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-04 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 May 27 15:59:46 2019 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 70D54120026 for ; Mon, 27 May 2019 15:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=146hNcDn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=PhSoj39d 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 qbVD9CpA_7Gi for ; Mon, 27 May 2019 15:59:43 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E29120019 for ; Mon, 27 May 2019 15:59:43 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id EAB4FF80721 for ; Mon, 27 May 2019 18:59:11 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1558997951; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aFXp1SYPGcCBuDA/IMxmT6+QpMQuEfzWIA6TzSFHL4M=; b=146hNcDnflQYQXmEXHWaL6jFqCwO1QGHHQYWiP2MCqJWaELkT9Jw96Bg 4EP55N6hwKDBTgAP0rg+OvXzHdZRBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1558997951; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aFXp1SYPGcCBuDA/IMxmT6+QpMQuEfzWIA6TzSFHL4M=; b=PhSoj39dqS+NgqaY4qHRV+2rAu78dzvcuuCJOY/kUx7RZryayJEWvwQ+ s72zt5B/ybxW0JaS2FRLTHmzRBveRgmTwvjRqT8D9cSNRzSDbA+ISpa0Kl IWybmM5+v4qfUyQY41ICMAsuTEnkLBMY13/vb5s7hK1I33sS9gLST4CJqX 56ZYwK64wPRZZM9DC/34K73/m4fL3WD2YOhCuLv+dd2Zhcrn6rKY2T6zXD TYXghmfk3TsqFvEMctQSQam/fuv/rBQZceWnX87yGW+GySpJqLICb7yGhr 8+BIqq2baLNyOlmeG9rlwNI3qIIcQ2IxiwBPCQ/FXDAETykS1Pms4w== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id B6E7EF8071F for ; Mon, 27 May 2019 18:59:11 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 27 May 2019 18:59:11 -0400 Message-ID: <2350589.KE7Alnpban@l5580> In-Reply-To: <155899759708.543.16777184314234317178@ietfa.amsl.com> References: <155899759708.543.16777184314234317178@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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: Mon, 27 May 2019 22:59:45 -0000 On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org 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 : DMARC (Domain-based Message Authentication, > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > Author : Scott Kitterman > Filename : draft-ietf-dmarc-psd-04.txt > Pages : 11 > Date : 2019-05-27 There isn't much to this update. It corrects one typo and reverts the RUF MUST NOT as discussed on the list. As far as I'm aware there are no other pending issues in the WG with the draft. Scott K From nobody Mon May 27 16:22:49 2019 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 AE6D4120077 for ; Mon, 27 May 2019 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=jhcloos.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 yBiK0lmztXRG for ; Mon, 27 May 2019 16:22:46 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [192.40.56.151]) (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 59B35120019 for ; Mon, 27 May 2019 16:22:46 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id D5B4A1E329; Mon, 27 May 2019 23:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1558999364; bh=lw+5GAEhdzj7AWbOYoXQyQmq3JFMhbBPkZlUjHz9xmM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ErhzPNgDghk4H//PmOTiYJ/hPLbMUhIKQOOjQjbcHOBMIWwYFk575RyWQ8bWjkPj0 g88MAuYxQ3mfHWT3jSCYYjSVPK37rwe6Wvy/WFXWjgq3UUGHdHlv6jtA7poh16Yl7j cIykWtxtKblBD++7HFaPZyn6bYhM567p8xrDBZzAxLSzF19KgC8OAnehehgP7M4Eck k3yoQfir82eYJsrCZNJlRxnqS61Pv6k2eJunXiY8DisYXscaMmYdtfEpgQ+d/MjYsC oYxqLDzPZrbVKEtRv/6G4c1cvhsGkLmBUzallu3n02IyPSU8FHrqaB3zZajb4UVgrF SRB/x3lRSwPaw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 590AA24F66; Mon, 27 May 2019 23:22:38 +0000 (UTC) From: James Cloos To: dmarc@ietf.org Cc: John Levine In-Reply-To: <20190527193203.4B74F2014AD9CA@ary.qy> (John Levine's message of "27 May 2019 15:32:02 -0400") References: <20190527193203.4B74F2014AD9CA@ary.qy> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2019 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 27 May 2019 19:22:38 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 27 May 2019 23:22:48 -0000 >>>>> "JL" == John Levine writes: JL> implement it. If people are interested in an https PUT scheme it JL> would be easy enough to define one, I find that the http POST scheme for TLSRPT works very well. It wouldn't hurt to have such a scheme for dmarc, too. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon May 27 17:08:25 2019 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 5747A12007A for ; Mon, 27 May 2019 17:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 nIYqJ3qL1ZPm for ; Mon, 27 May 2019 17:08:21 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 1D89C12002E for ; Mon, 27 May 2019 17:08:21 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id r10so16131392otd.4 for ; Mon, 27 May 2019 17:08:21 -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=SySBrgjveKddZQ6Oi0+YM9xVDq2xmGzVRh6i2Bd2DYQ=; b=Gnc6VYwvongT66k0bzsIVpYRc0/D7LLQiD77gy0SOFZaZnZx1/XVD+lzh1ScwVQ6al DZZQnDthPE3EtHGNBzYe5PaO0BTY2Y7uZMNL89dmZUDjkzItMhPkKf37Kx6hsdczwbNP 8I1piEvv73cXo297ItjjBcp4Okoai31JMrmTwFBkW6FgutWWUBY+Qm55PM0gG4HZiYt3 U69QiM2z1m0JWubk6XbfOVJS189tST8FhXZ6ZETbTqRM7ajcTX3C7UUVTuswmq5FrCbc acITuL9bSYUV9TZKFOqiMOQ/YW6uL20ST62M5V5P8Y+xFhI8Lo2VS141xH+JorIhN29A vBtA== 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=SySBrgjveKddZQ6Oi0+YM9xVDq2xmGzVRh6i2Bd2DYQ=; b=VajkINxo64WE0DNAFydcI3KYOV1AL2RApr4TccjaTwjaHcRmUZdwmIBUbR2yl/GJtX LV3y8YnAlaLTzPRIpULoaPCkz7O5J3t32QC9LJJyxiNKm82AUbuaKS6eNrYTob354TK0 GunQbi1R5WZHTFrSVw3kIfcWbTnhWhT37VXhAhrkA3li0DRdmrpLwrORxt3zi50VujRz RLIRlR8TSNRne5IuYy+jmu+BhgXJZ3cJhwo5huLx8QDMbkIR+AL2yb6WRexTxiwqkf1i A8WHeaydkEOUi9HnzD9R/O7MaT+brKCz3buQa0kyMx+Jktbbj58/rN1BqPDqTspQfGfP 4NfQ== X-Gm-Message-State: APjAAAVxUtYhVGbXJgl7efqN7oGZaeC5qfjqOZav0X7bakrErWb1K43o DLY7lILh8RTvUGOMR3eBoOfC2ApWVnyfMYAJUn9rSmUk X-Google-Smtp-Source: APXvYqyHCBjmiwubmPVk3aWcoMU3MGDulqnH1mpN8GOAdtAwtNE38gAKb6YnPPXLR9G70lTWZv9aVK/t+KQJmBsHSGA= X-Received: by 2002:a9d:69d9:: with SMTP id v25mr180763oto.4.1559002100377; Mon, 27 May 2019 17:08:20 -0700 (PDT) MIME-Version: 1.0 References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> In-Reply-To: <2350589.KE7Alnpban@l5580> From: Tim Wicinski Date: Mon, 27 May 2019 20:08:09 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000065ad750589e776e9" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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, 28 May 2019 00:08:23 -0000 --00000000000065ad750589e776e9 Content-Type: text/plain; charset="UTF-8" Oh, Thanks Scott! The chairs were chatting about this a week ago. I'm going to reconfirm, but look forward a WGLC coming this week. Tim On Mon, May 27, 2019 at 6:59 PM Scott Kitterman wrote: > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org 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 : DMARC (Domain-based Message Authentication, > > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > > Author : Scott Kitterman > > Filename : draft-ietf-dmarc-psd-04.txt > > Pages : 11 > > Date : 2019-05-27 > > There isn't much to this update. It corrects one typo and reverts the RUF > MUST NOT as discussed on the list. As far as I'm aware there are no other > pending issues in the WG with the draft. > > Scott K > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000065ad750589e776e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, Thanks Scott!

The chairs were chatt= ing about this a week ago.=C2=A0 I'm going to reconfirm, but =C2=A0look= forward a WGLC coming this week.=C2=A0

Tim
<= div>

On Mon, May 27, 2019 at 6:59 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org = 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.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: DMARC (Domain-based Message Authentication,
> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)=
> Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scott Kitterman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dmarc-psd-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-05-27

There isn't much to this update.=C2=A0 It corrects one typo and reverts= the RUF
MUST NOT as discussed on the list.=C2=A0 As far as I'm aware there are = no other
pending issues in the WG with the draft.

Scott K



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000065ad750589e776e9-- From nobody Mon May 27 19:50:54 2019 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 6723F120116 for ; Mon, 27 May 2019 19:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=HfdB5OE4; dkim=pass (1536-bit key) header.d=taugh.com header.b=hq5TGfze 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 X4FBSWdG2WvW for ; Mon, 27 May 2019 19:50:41 -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 6CD84120147 for ; Mon, 27 May 2019 19:50:41 -0700 (PDT) Received: (qmail 63702 invoked from network); 28 May 2019 02:50:39 -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; s=f8d4.5ceca1ff.k1905; i=johnl-iecc.com@submit.iecc.com; bh=NDAxK1n0iOSZBrX8XwMtqzXrpNjnKYwo7vVYoLjaxLk=; b=HfdB5OE4t/xH5HoCkgzzeerqU0IhHBMpFu6gmc8GaC7rPTr9amcUEk2zyk0fFXgb0V7D+ugRo0RSgwmbDmTT9K8X2C4UiyFi/QqVsNJr84a8eK1GzE9VdDf2UbymNJT3PY1ZBh0oL+iPmeB5/GE1B+0vjbGuDTMrZoY2w/XocGA238wwSAEgzu4QRS2Qwc+a/GbOuroWmPN3YFnbmfrS0Cz7e8J0pzf+kTU9rR2QZaijsC1+lVSFu2p2gMQ1KBea 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; s=f8d4.5ceca1ff.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=NDAxK1n0iOSZBrX8XwMtqzXrpNjnKYwo7vVYoLjaxLk=; b=hq5TGfzeJeb0UASUz9dXv8Q5dC13UYyDlHvw/pgABD1M2QIT4napcbr4kZfE6TZ41miN8xgmLNDgcCjaUSotBaDikv95kVDTfBlgjoeyxdLw5e2+KqL4rY63bInBQ+uSk5881jMudvyseP6l/U6X1kIyPeHEB6tf5tcABkTnMxAGV7LjiW21YKkpvc9uR3+h+roHmm2z9DibLsjD9syIYuts7Ps0tZh1i+ugbST/S3rgViRvV7+yC0Eui0lxkEES Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 28 May 2019 02:50:39 -0000 Received: by ary.qy (Postfix, from userid 501) id 0D5272014B0A62; Mon, 27 May 2019 22:50:38 -0400 (EDT) Date: 27 May 2019 22:50:38 -0400 Message-Id: <20190528025039.0D5272014B0A62@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: cloos@jhcloos.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 28 May 2019 02:50:53 -0000 In article you write: >>>>>> "JL" == John Levine writes: > >JL> implement it. If people are interested in an https PUT scheme it >JL> would be easy enough to define one, > >I find that the http POST scheme for TLSRPT works very well. It looks straightforward enough. Do people actually use it? From nobody Tue May 28 01:40:05 2019 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 2C9861201AA for ; Tue, 28 May 2019 01:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC8NOzUBqSGu for ; Tue, 28 May 2019 01:40:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86FD120086 for ; Tue, 28 May 2019 01:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1559032798; bh=LYllCuvTW6548XJbPWezISJKvWBEY5fVjWOsilEiyVc=; l=9311; h=To:References:From:Date:In-Reply-To; b=A9viRz8N4ns8Nw+AIwYJD3YJtwoW2IYB9whcmsf8SKKMcn3HnXAK164fWx0mOIIFK vvx9R9LIvionARThkNX57faguMyxDVHBkfSyIrynAEtchABlgAf/Z+m8bloYILaAtH RBTjSIaeqeHmM5PVKFnF+tO+K2MzXrH7bu9JJYfcXb9cWB1ei+j1PH1z8ZAhv Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 28 May 2019 10:39:58 +0200 id 00000000005DC084.000000005CECF3DE.00005266 To: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <384aaed3-414f-5d1b-0d20-90a5f25597f2@tana.it> Date: Tue, 28 May 2019 10:39:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------87C1AA9A9D509CF860FEA729" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 28 May 2019 08:40:04 -0000 This is a multi-part message in MIME format. --------------87C1AA9A9D509CF860FEA729 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On Fri 24/May/2019 20:25:33 +0200 John R Levine wrote: > > Deploying DMARC seems to mean any subset of these: > > 1a.  Publish a DMARC record > 1b.  Publish a DMARC record with a restrictive policy > 2a.  Evaluate DMARC status of incoming messages > 2b.  Use that status to manage message disposition > 3.   Collect reports > 4a.  Send aggregate reports > 4b.  Send failure reports Nice one! That analysis should make it to some implementation guide. I'd suggest an addition, though: 3a. Receive and possibly read records 3b. Collect them I only do 3a, let me attach an example. (It also exemplifies 4a, but the htmlizer is the same.) I look at sent or received reports occasionally. They are automatically deleted after some time. I never happened to need to process them as a collection. If I did, I guess I should reset the accumulated results when the relevant DMARC/DKIM/SPF records change. I hope the implementation guide will explain this. > It is my impression that most domains that have "deployed DMARC" have done 1b > and 3.  I've done 1a, 2a, 3, and a very small amount of 2b.  Only a few sites > do 4a and even fewer do 4b. > > I'm getting the impression that what we need is a non-normative deployment > guide, not as part of the spec. +1. Recall that the current spec is formally non-normative (which might explain the lack of normative language in Section 8). If we have to split, I'd suggest to split into a normative and a non-normative part, where the latter is an implementation guide. IMHO: 4a is needed to evaluate the effect of policies, otherwise the protocol is blind. Best Ale -- --------------87C1AA9A9D509CF860FEA729 Content-Type: application/x-extension-eml; name="Report domain: taugh.com Submitter: tana.it.eml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Report domain: taugh.com Submitter: tana.it.eml" UmV0dXJuLVBhdGg6IDxkbWFyYy1ib3VuY2VAdGFuYS5pdD4NClJlY2VpdmVkOiBmcm9tIGxv Y2FsaG9zdCAobG9jYWxob3N0IFsxMjcuMC4wLjFdKQ0KICAodWlkIDExNykNCiAgYnkgd21h aWwudGFuYS5pdCB3aXRoIGxvY2FsOyBUdWUsIDI4IE1heSAyMDE5IDAyOjQyOjA3ICswMjAw DQogIGlkIDAwMDAwMDAwMDA1REMwQjIuMDAwMDAwMDA1Q0VDODNERi4wMDAwMDIyMg0KREtJ TS1TaWduYXR1cmU6IHY9MTsgYT1yc2Etc2hhMjU2OyBjPXJlbGF4ZWQvcmVsYXhlZDsgZD10 YW5hLml0OyBzPWRlbHRhOw0KCXQ9MTU1OTAwNDEyNzsgYmg9dVo0YTBqcU03QXgvS3YyL1Ar VzdpcDBEWk9iM1p3WWoxL2tzY3l3VjBKcz07DQoJbD0xMDE5OyBoPUZyb206VG86RGF0ZTsN CgliPUI5Y1pzR3g1NksrVHBMOENHQVZYN1hMNS9BK1ZRUWd3MlIwYktVc3hhWWlWZWRWUmgw QWVsdzNOcUc5Q1hNWmdDDQoJIEoweEtRMGRCdGxSbnFCcDJpN055Q05Mc0tZc2dOVE9rdDla Q1ROMG9sV2ltMnEyUDlGZDFib3JXTjJkVy9MVGFxcg0KCSBhVVVKbmhBN0liNmVsOW1hekNB VkJERmJmYStDL1ZtK05DMUFUTWdiQmhyMGVEby9wSVYwZUdka1BZVllzDQpBdXRoZW50aWNh dGlvbi1SZXN1bHRzOiB0YW5hLml0OyBhdXRoPXBhc3MgKGRldGFpbHMgb21pdHRlZCkNCkZy b206IHBvc3RtYXN0ZXJAbm9sb29wLnRhbmEuaXQNClRvOiBkbWFyYy1hQGFidXNlLm5ldA0K RGF0ZTogVHVlLCAyOCBNYXkgMjAxOSAwMjo0MjowNyArMDIwMA0KU3ViamVjdDogUmVwb3J0 IGRvbWFpbjogdGF1Z2guY29tIFN1Ym1pdHRlcjogdGFuYS5pdA0KTWVzc2FnZS1JZDogZjc4 MWNkZmE2OTI3NGI1MzkyODcwYzUwYjUxYmIxM2VAdGFuYS5pdA0KTUlNRS1WZXJzaW9uOiAx LjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT0iPV8xXzE1NTkw MDQxMjdfNTY4Ig0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdA0KDQpUaGlzIGlz IGEgTUlNRS1mb3JtYXR0ZWQgbWVzc2FnZS4gIElmIHlvdSBzZWUgdGhpcyB0ZXh0IGl0IG1l YW5zIHRoYXQgeW91cg0KRS1tYWlsIHNvZnR3YXJlIGRvZXMgbm90IHN1cHBvcnQgTUlNRS1m b3JtYXR0ZWQgbWVzc2FnZXMuDQoNCi0tPV8xXzE1NTkwMDQxMjdfNTY4DQpDb250ZW50LVR5 cGU6IHRleHQvaHRtbDsgY2hhcnNldD11dGYtOA0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGlu ZzogN2JpdA0KDQo8P3htbCB2ZXJzaW9uPSIxLjAiPz4NCjwhRE9DVFlQRSBodG1sIFBVQkxJ QyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25hbC8vRU4iICJodHRwOi8vd3d3 LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4NCjxodG1s IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczpkYXRlPSJodHRw Oi8vZXhzbHQub3JnL2RhdGVzLWFuZC10aW1lcyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIC8+PHRp dGxlPg0KCQkJCUZlZWRiYWNrIGZyb20NCgkJCQl0YW5hLml0PC90aXRsZT48c3R5bGUgdHlw ZT0idGV4dC9jc3MiIGlkPSJpbnRlcm5hbC1zdHlsZSI+DQoJCQkJCWJvZHkgew0KCQkJCQkJ Zm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7DQoJCQkJCQljb2xv cjogIzAwMzMwMDsNCgkJCQkJCWJhY2tncm91bmQtY29sb3I6ICNmZmNjNjY7DQoJCQkJCX0N CgkJCQkJdGFibGUsIHAgew0KCQkJCQkJbWFyZ2luOiAxZW07DQoJCQkJCQlwYWRkaW5nOiA0 cHQ7DQoJCQkJCQliYWNrZ3JvdW5kLWNvbG9yOiAjZmZlZWFhOw0KCQkJCQkJYm9yZGVyOiAz cHQgc29saWQgIzc3NjYzMzsgDQoJCQkJCX0NCgkJCQkJdGQsIHRoIHsNCgkJCQkJCW1hcmdp bjogMnB0Ow0KCQkJCQkJcGFkZGluZzogMnB0Ow0KCQkJCQkJYm9yZGVyOiAxcHQgc29saWQg Izc3NjYzMzsgDQoJCQkJCX0NCgkJCQkJLnBhc3Mgew0KCQkJCQkJYmFja2dyb3VuZC1jb2xv cjogIzExYmIwMDsNCgkJCQkJfQ0KCQkJCQkuZmFpbCB7DQoJCQkJCQliYWNrZ3JvdW5kLWNv bG9yOiAjY2MwMDAwOw0KCQkJCQl9DQoJCQkJCS5ka2ltcG9saWN5IHsNCgkJCQkJCWJhY2tn cm91bmQtY29sb3I6ICNmZmZmNjY7DQoJCQkJCX0NCgkJCQkJLmVycm9yIHsNCgkJCQkJCWJh Y2tncm91bmQtY29sb3I6ICNiYmFhYWE7DQoJCQkJCQlmb250LXdlaWdodDogYm9sZDsNCgkJ CQkJfQ0KCQkJCQkuc29mdGZhaWwgew0KCQkJCQkJYmFja2dyb3VuZC1jb2xvcjogI2ZmODg2 NjsNCgkJCQkJfQ0KCQkJCQkucmVqZWN0IHsNCgkJCQkJCWJhY2tncm91bmQtY29sb3I6ICNj YzAwMDA7DQoJCQkJCX0NCgkJCQkJLnF1YXJhbnRpbmUgew0KCQkJCQkJYmFja2dyb3VuZC1j b2xvcjogI2ZmODg2NjsNCgkJCQkJfQ0KCQkJCQkubm9ybWFsIHsNCgkJCQkJfQ0KCQkJCQku ZmllbGQgew0KCQkJCQkJZm9udC13ZWlnaHQ6IGJvbGQ7DQoJCQkJCX0NCgkJCQk8L3N0eWxl PjwvaGVhZD48Ym9keT48aDE+DQoJCQkJRmVlZGJhY2sgZnJvbQ0KCQkJCXRhbmEuaXQ8L2gx PjxwPjxzcGFuIGNsYXNzPSJmaWVsZCI+SWQ6IDwvc3Bhbj5mNzgxY2RmYTY5Mjc0YjUzOTI4 NzBjNTBiNTFiYjEzZTsgPHNwYW4gY2xhc3M9ImZpZWxkIj5iZWdpbjogPC9zcGFuPjIwMTkt MDUtMjdUMDA6MDA6MDBaOyA8c3BhbiBjbGFzcz0iZmllbGQiPmVuZDogPC9zcGFuPjIwMTkt MDUtMjhUMDA6MDA6MDBaPGJyIC8+PHNwYW4gY2xhc3M9ImZpZWxkIj5Eb21haW46IDwvc3Bh bj50YXVnaC5jb207IDxzcGFuIGNsYXNzPSJmaWVsZCI+REtJTTogPC9zcGFuPnJlbGF4ZWQ7 IDxzcGFuIGNsYXNzPSJmaWVsZCI+U1BGOiA8L3NwYW4+cmVsYXhlZDsgPHNwYW4gY2xhc3M9 ImZpZWxkIj5wb2xpY3kgcHVibGlzaGVkOiA8L3NwYW4+bm9uZSAgPC9wPjx0YWJsZT48dHI+ PHRoPg0KCQkJCQkJCVJlbGF5aW5nIElQDQoJCQkJCQk8L3RoPjx0aD4NCgkJCQkJCQltZXNz YWdlIGNvdW50DQoJCQkJCQk8L3RoPjx0aD4NCgkJCQkJCQlyZWFzb24gYW5kIGRpc3Bvc2l0 aW9uDQoJCQkJCQk8L3RoPjx0aD4NCgkJCQkJCQlGcm9tIGhlYWRlcg0KCQkJCQkJCTxiciAv Pg0KCQkJCQkJCShvcHQuIGVudmVsb3BlKQ0KCQkJCQkJPC90aD48dGg+DQoJCQkJCQkJU1BG DQoJCQkJCQk8L3RoPjx0aD4NCgkJCQkJCQkJREtJTQ0KCQkJCQkJCTwvdGg+PHRoPg0KCQkJ CQkJCQkJMm5kIERLSU0NCgkJCQkJCQkJPC90aD48dGg+DQoJCQkJCQkJCQkJM3JkIERLSU0N CgkJCQkJCQkJCTwvdGg+PC90cj4NCgkJCQkJPHRyPjx0ZD48YSBocmVmPSJodHRwOi8vd3d3 LnRhbmEuaXQvbG9va3VwLnBocD9ob3N0PTQuMzEuMTk4LjQ0Ij40LjMxLjE5OC40NDwvYT48 L3RkPjx0ZCBhbGlnbj0icmlnaHQiPjU8L3RkPjx0ZCBjbGFzcz0ibm9ybWFsIj48L3RkPjx0 ZD50YXVnaC5jb208L3RkPjx0ZCBjbGFzcz0icGFzcyI+aWV0Zi5vcmcgPC90ZD48dGQgY2xh c3M9ImZhaWwiPnRhdWdoLmNvbSA8L3RkPjx0ZCBjbGFzcz0icGFzcyI+aWV0Zi5vcmcgPC90 ZD48dGQgY2xhc3M9ImZhaWwiPmllY2MuY29tIDwvdGQ+PC90cj4NCgkJPC90YWJsZT48cD48 Yj48dT5MZWdlbmQ8L3U+PGJyIC8+DQoJCQkJCWRpc3Bvc2l0aW9uOiA8L2I+PHNwYW4gY2xh c3M9InF1YXJhbnRpbmUiPnF1YXJhbnRpbmU8L3NwYW4+LA0KCQkJCQk8c3BhbiBjbGFzcz0i cmVqZWN0Ij5yZWplY3Q8L3NwYW4+LjxiciAvPjxiPnNwZjogPC9iPjxzcGFuIGNsYXNzPSJw YXNzIj5wYXNzPC9zcGFuPiwNCgkJCQkJPHNwYW4gY2xhc3M9ImZhaWwiPmZhaWw8L3NwYW4+ LA0KCQkJCQk8c3BhbiBjbGFzcz0ic29mdGZhaWwiPnNvZnRmYWlsPC9zcGFuPiwNCgkJCQkJ PHNwYW4gY2xhc3M9ImVycm9yIj50ZW1wZXJyb3Igb3IgcGVybWVycm9yPC9zcGFuPi48YnIg Lz48Yj5ka2ltOiA8L2I+PHNwYW4gY2xhc3M9InBhc3MiPnBhc3M8L3NwYW4+LA0KCQkJCQk8 c3BhbiBjbGFzcz0iZmFpbCI+ZmFpbDwvc3Bhbj4sDQoJCQkJCTxzcGFuIGNsYXNzPSJka2lt cG9saWN5Ij5wb2xpY3k8L3NwYW4+Lg0KCQkJCTwvcD48L2JvZHk+PC9odG1sPg0KDQotLT1f MV8xNTU5MDA0MTI3XzU2OA0KTUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVs dGlwYXJ0L21peGVkOyBib3VuZGFyeT1CQl9fZjc4MWNkZmE2OTI3NGI1MzkyODcwYzUwYjUx YmIxM2UNCg0KDQotLUJCX19mNzgxY2RmYTY5Mjc0YjUzOTI4NzBjNTBiNTFiYjEzZQ0KQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpDQoNCg0KLS1CQl9fZjc4 MWNkZmE2OTI3NGI1MzkyODcwYzUwYjUxYmIxM2UNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRp b24vZ3ppcA0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp c3Bvc2l0aW9uOiBhdHRhY2htZW50Ow0KCWZpbGVuYW1lPSJub2xvb3AudGFuYS5pdCF0YXVn aC5jb20hMTU1ODkxNTIwMCExNTU5MDAxNjAwIWY3ODFjZGZhNjkyNzRiNTM5Mjg3MGM1MGI1 MWJiMTNlLnhtbC5neiINCg0KSDRzSUFkK0Q3RndBLzUxVXkyNmpNQlJkcDE4UlpUK0FrOUNB NUxwZHpSZE0xOGlZQzdHS0g3Sk5PL1AzNDFjVFdrV1YybFh3dWRmbg0KY1gwVi9QaFh6TnRY TUpZcitiQkRSYlhiZ21ScTRISjYyRDMvK2YycjJXMGZ5UjBlQVlhZXNoZHl0OEVHdERLdUUr RG9RQjMxMEFZcg0KTTNXU0NpQ09TbHB3aDhzTEVzb2dLSitKVnRZSmFoMllKNmxtcFhSeDZV NE5vVFd6ODRHTXB3YXhZYVQzN2Y1MDdPdER1MjlPRmF1cg0KdmtaOWp3NkF5MnR2dU9uTlFH ZW9uS0xtQnZjd2NVbFFYVGN0cXZkVmhjdUV4Q0xJSVpUYXFrTDNvUlRPZ2FUOHdIS1JXSVhG V3MyYw0KL2V2MDBzL2NuaUdMSzU5QSt2akxkQzZZRXA0b0lhRkloeGN1aU1GbCtvaVExV05F d204QU5KRksra3c2eXQ3UThKTmh5aVExbzk1Uw0KREtzV3c2RGptaHlMQXlwUTJ4VEhJeTZ2 Y094aWFwR08xTGhNSHhITEN2Qks1OFZIanJ3aEI3ZittYmp6KzVBTnJaSGNFMEtNL3NGOA0K TWVjSlZueVFCT1pJMXhnZlJQeE1rM3ZNQjVDT2o5eXZYK28vQXgzQWRLTlJZajNKTlJ3SlBs M0VkSEhuem9CZFpwZVpWcjYrZXBtNA0KYitGYWRwNFB5ZnlGNHdZYkJ6Y1dmc1Z2azJscTdi ZklHUHVocy9kUi85U1laMkJLQXhGaHVQN2w0aUdKdkM5bStXbTY0WDVhUkZ4ZQ0KL3hiK0F4 NG1UYkZLQkFBQQ0KDQotLUJCX19mNzgxY2RmYTY5Mjc0YjUzOTI4NzBjNTBiNTFiYjEzZS0t DQoNCi0tPV8xXzE1NTkwMDQxMjdfNTY4LS0NCg== --------------87C1AA9A9D509CF860FEA729-- From nobody Tue May 28 05:17:44 2019 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 2E9531200D7 for ; Tue, 28 May 2019 05:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 6hrJN7sZRHEI for ; Tue, 28 May 2019 05:17:39 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 3CA72120165 for ; Tue, 28 May 2019 05:17:39 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id h11so3513570itf.5 for ; Tue, 28 May 2019 05:17:39 -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=WKDuBvFA9F/aIL3pVjN70B/igVAAboucM+CmWyIhiog=; b=WZIkMhNQa8e0Wigcx1CStErDHOOZM90O/+0Ua4kLX5S9AHzaq/zAexbOoH9I/K+VFM 4g3ifrfdVKSLKZhN5RKunCWCK/Urg5wqGeWLbO/SZAqg8o+iT4KRRlb7hc1VJmvmLPps mvPPGfdJiS5AiC3eREoSigLaXYIdfg7q9j/A4= 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=WKDuBvFA9F/aIL3pVjN70B/igVAAboucM+CmWyIhiog=; b=ftRTOfSICbh+5DsQMBQocxJ5NdWJXLMVMl5x/m9QqmJCTJ0TA/q9b3Zg5kJFrjZvap F8+6zsGXF/Vqa2piWAj1wl5Tmra2dLVRZGL/b+aZh/0A3dUETlSwWap7841M5JYMU+T/ P0wKpyOJ6yqjNgAXqA75NH07xCaEsdpme+xQ5Fk/hTj7wcrpegCLj/439ZvunyD8zBs4 ZPfK89/kveDg8ZtU9eWEZe3AbqBPEn65Xi3la/X8Ar4q4LtEx3UcOmhAgFc8pHuk3R67 Qrf+S1ircf9s6tSV5EYV9Q31VulflbKXgpPwkKdcXOPzcrO56TJ+473+pNI3iEbeixb0 8vPQ== X-Gm-Message-State: APjAAAVZSQYkNifZxbWumfsEy827u6GmYeZC6LQzxoHksEvFWei812W8 qnvOkisAYi84yYUBqrPtF9nbcRVlmTf4l9vXnFtYE2xukGM= X-Google-Smtp-Source: APXvYqx5IAezm7O2987lhm1/GTto1Us6QAqMx8VUVlaUxviE2vDH+xf+zYk8aHpXdffR3sQfv+DGg6A40jAHt6+9Urk= X-Received: by 2002:a24:2254:: with SMTP id o81mr2726495ito.19.1559045858197; Tue, 28 May 2019 05:17:38 -0700 (PDT) MIME-Version: 1.0 References: <155899759708.543.16777184314234317178@ietfa.amsl.com> In-Reply-To: <155899759708.543.16777184314234317178@ietfa.amsl.com> From: Craig Schwartz Date: Tue, 28 May 2019 08:17:20 -0400 Message-ID: To: dmarc@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000009112df0589f1a6f0" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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, 28 May 2019 12:17:42 -0000 --0000000000009112df0589f1a6f0 Content-Type: text/plain; charset="UTF-8" I've reviewed the draft. We plan to implement this as soon as possible (for .bank and .insurance) and would like to see this get to WG last call shortly. Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Office: +1 202 589 2532 Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com On Mon, May 27, 2019 at 6:53 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 : DMARC (Domain-based Message Authentication, > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > Author : Scott Kitterman > Filename : draft-ietf-dmarc-psd-04.txt > Pages : 11 > Date : 2019-05-27 > > Abstract: > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. DMARC policies can be > applied at the individual domain level or for a set of domains at the > organizational level. The design of DMARC precludes grouping > policies for a set of domains above the organizational level, such as > TLDs (Top Level Domains). These types of domains (which are not all > at the top level of the DNS tree) can be collectively referred to as > Public Suffix Domains (PSDs). For the subset of PSDs that require > DMARC usage, this memo describes an extension to DMARC to enable > DMARC functionality for such domains. > > > 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-04 > > > 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 > --0000000000009112df0589f1a6f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've= reviewed the draft.=C2=A0=C2=A0We plan to implement this as soon as possible (for .bank= and=C2=A0
.insurance) and would lik= e to see this get to WG last call shortly.=C2=A0=C2=A0

Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .= INSURANCE
Office: +1 20= 2 589 2532
Mobile: = +1 202 236 1154
Skype: = craig-schwartz




<= /div>


On Mon, May 27,= 2019 at 6:53 PM <internet-d= rafts@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:= DMARC (Domain-based Message Authentication, Reporting, and Conformance) Ex= tension For PSDs (Public Suffix Domains)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scot= t Kitterman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-psd-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-05-27

Abstract:
=C2=A0 =C2=A0DMARC (Domain-based Message Authentication, Reporting, and
=C2=A0 =C2=A0Conformance) is a scalable mechanism by which a mail-originati= ng
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.=C2=A0 DMARC pol= icies can be
=C2=A0 =C2=A0applied at the individual domain level or for a set of domains= at the
=C2=A0 =C2=A0organizational level.=C2=A0 The design of DMARC precludes grou= ping
=C2=A0 =C2=A0policies for a set of domains above the organizational level, = such as
=C2=A0 =C2=A0TLDs (Top Level Domains).=C2=A0 These types of domains (which = are not all
=C2=A0 =C2=A0at the top level of the DNS tree) can be collectively referred= to as
=C2=A0 =C2=A0Public Suffix Domains (PSDs).=C2=A0 For the subset of PSDs tha= t require
=C2=A0 =C2=A0DMARC usage, this memo describes an extension to DMARC to enab= le
=C2=A0 =C2=A0DMARC functionality for such domains.


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-= 04
https://datatracker.ietf.org/doc/html/d= raft-ietf-dmarc-psd-04

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


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
--0000000000009112df0589f1a6f0-- From nobody Tue May 28 08:22:19 2019 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 13793120173 for ; Tue, 28 May 2019 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1536-bit key) header.d=iecc.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 1rKmPAjyRZYG for ; Tue, 28 May 2019 08:22:15 -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 B86351200D6 for ; Tue, 28 May 2019 08:22:14 -0700 (PDT) Received: (qmail 91697 invoked from network); 28 May 2019 15:22:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1662e.5ced5224.k1905; i=johnl-iecc.com@submit.iecc.com; bh=wfnboyXT8f6kxtRqKbqtdNR8prQGdtShY6Vnt3lI3VI=; b=dMWmp6xF/VhHSOFhDDyH8PX20CN2TJCeX2nPEnAMdUaI8MYEhZitkoAtJpbqbFGNDKOqL8Ai6xQkSf5BMY1MvKSeIIaWTCcq7eiQYIbNlN96tFcTpdilyD+uAcqxb69ov1iBVBDBXsVX4VDRSh0FDmXnH/25XwOV+TF4khw7JV6oTzD6t4ZUTTZfGCW6u1GxDhy8UBJJa1PcDT0zErer+LxJozRzP2bZ32MHGiK6zLvv+cWW4p943peBv2/SihpB Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 May 2019 15:22:12 -0000 Date: 28 May 2019 11:22:11 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" Cc: dmarc@ietf.org In-Reply-To: <384aaed3-414f-5d1b-0d20-90a5f25597f2@tana.it> References: <20190523225213.C214620147B780@ary.qy> <280824a0-536b-91f1-8072-f7d1cf3051aa@bluepopcorn.net> <384aaed3-414f-5d1b-0d20-90a5f25597f2@tana.it> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-190567311-1559056932=:67418" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: what is DMARC ? 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, 28 May 2019 15:22:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-190567311-1559056932=:67418 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> Deploying DMARC seems to mean any subset of these: >> >> 1a.  Publish a DMARC record >> 1b.  Publish a DMARC record with a restrictive policy >> 2a.  Evaluate DMARC status of incoming messages >> 2b.  Use that status to manage message disposition >> 3.   Collect reports >> 4a.  Send aggregate reports >> 4b.  Send failure reports > > > Nice one! That analysis should make it to some implementation guide. I'd > suggest an addition, though: > > 3a. Receive and possibly read records > 3b. Collect them As far as DMARC is concerned, once you've published rua or ruf and receive the reports, DMARC is done. Some people just put them in a mailbox, some pick out basic bits and put them in a database, some do elaborate analyses, but none of that has anything to do with DMARC compliance. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-190567311-1559056932=:67418-- From nobody Tue May 28 14:00:47 2019 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 A9F211200BA for ; Tue, 28 May 2019 14:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=jhcloos.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 YBeZCME43aSf for ; Tue, 28 May 2019 14:00:44 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [192.40.56.151]) (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 46F9612003F for ; Tue, 28 May 2019 14:00:44 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2070E2086D; Tue, 28 May 2019 21:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1559077243; bh=C6kLlZQkbzkCq6eNFgxaLk7MIrm3KumD4q64UNL+fZ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=l4DibU15GlE+l4pBj8kH5yWpukxWoDpDCmiFAZnnI2gJQ4AdkhQKem/oXaTGqyCNq /8xHr08GDti0J6gtd/FDqM9moD1BxWjYOXyFyuQp2hAYG/GAZ4TaZOP5ci1fUoJOGT v++ZaprSi7nvIsTbkIshevo7T2YiZT/VPOvLV5SYnBfgNQEqTWptuBT+k2+R9WU/T0 jt+1B5mh/DZfg4rGQvI90rxHogiEuS8rMqwZXwboX300PZmqw9oYghecIgDOgGc9rY 4FvGcTW7U4+rVQ6iZvniYWUp6f3xiPeRURAzJvR7PXRDNsMwiyh0YZ+a+NcJsoT6mr 2XuMdG0us75KQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id A08B424F74; Tue, 28 May 2019 21:00:36 +0000 (UTC) From: James Cloos To: dmarc@ietf.org Cc: John Levine In-Reply-To: <20190528025039.0D5272014B0A62@ary.qy> (John Levine's message of "27 May 2019 22:50:38 -0400") References: <20190528025039.0D5272014B0A62@ary.qy> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2019 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 28 May 2019 17:00:36 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 28 May 2019 21:00:46 -0000 >>>>> "JL" == John Levine writes: JC>> I find that the http POST scheme for TLSRPT works very well. JL> It looks straightforward enough. Do people actually use it? I've only received TLSRPT POSTs from Googlebot/2.1, but I got the impression that I wasn't the only one to use v=TLSRPTv1;rua=https:... -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed May 29 10:01:21 2019 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 48FDB120136 for ; Wed, 29 May 2019 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 OJwR2rXsT25O for ; Wed, 29 May 2019 10:01:18 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 DFF6D12002F for ; Wed, 29 May 2019 10:01:18 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4300:2290:a4d8:3398:c9b6:6198]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4TH1G5c003127 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 May 2019 10:01:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1559149278; bh=V3E82R1GiGNesYdsRf9ReblrvKsrY7Q+ZtCkfDozgcE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lu1Q3440Kbt0aDdnMylAJObFwUxqheJOz0UGjMzF3sW9HjTnYOnT3TLHUoP4XC5tp vKwceiOLLA6vLibL+59Gx5TNriUaZjOVWQ/7MTpkJDH/yXK0DkXBlCfWLw0NbAo7A9 J4x+5jFYY8yAsOsMvPZyYjfOGL3BZOx8rz8RdP0c= To: John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: Date: Wed, 29 May 2019 10:01:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 29 May 2019 17:01:20 -0000 One more point on this: On 5/24/19 7:37 AM, John R Levine wrote: > > That's because they separated before they were published, so there was > nothing to be incompatible with.=C2=A0 If I knew what would break when > reorganizing and rewriting a document into pieces, I could fix it, but > since I don't, and nobody else does, let's not go there. You seem to be suggesting that the standards-track DMARCbis should be different because an informational, non-WG RFC has already been published. From a process standpoint that's bad; standards-track RFCs should go through exactly the same process regardless of whether or not they were previously published as Informational. -Jim From nobody Wed May 29 10:13:45 2019 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 951DB1201A0 for ; Wed, 29 May 2019 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=X0cdjon3; dkim=pass (1536-bit key) header.d=taugh.com header.b=wb+EfUdn 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 LVoHjiSu3OKE for ; Wed, 29 May 2019 10:13:41 -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 5490D1201A3 for ; Wed, 29 May 2019 10:13:27 -0700 (PDT) Received: (qmail 51317 invoked from network); 29 May 2019 17:13:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c872.5ceebdb4.k1905; i=johnl-iecc.com@submit.iecc.com; bh=sKHmArPX6JW9riq+F+PVRkVNxvlx/NrQCh1luC7Nxuw=; b=X0cdjon3FTqKd5oxlaJlTZjiBe1NR/wQxIYmHdKCPF16j6HD+L4titaMV7FVBM/t66H43kWpk2jK9SxDNf+thoe51oCTvxxjZAm/BeonXsjMdd0OQQ9OPRzgFp+rd/p7p1ftnVNdsAie3kFWgIH0DPQUigMQx56k98WqZGg4QGj5iSZXD+aD48AWM+4UrW/vzy81zBuTxq2eGZqvwJS7aII3YMSnOtzgR2jmlRjlRbFHa7nqtk0Tn65LYsJCLlkb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c872.5ceebdb4.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=sKHmArPX6JW9riq+F+PVRkVNxvlx/NrQCh1luC7Nxuw=; b=wb+EfUdnpt6O40Y0bDamoYbxovTlYE3TDX4wxyCal+qlJ86nud4t894KVm1Gw7STC5Abh811NDoKcp1HJeOkNIWcKIsJixwssAN0/to0clv4vkjDVs7D3qF8AAji+JIZGtYGlIfwgMV59JoUc1TErCpTFo1LA4vDXtV/vbNfsyVoTmc3tNLlt0E2Vnvb7Oh3Ibwy2ghgVJGtqIRIeVfPnxiVMR//qt3kLy5TLZZI34JnUGQoTlemtgCQK+WuezmP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 29 May 2019 17:13:23 -0000 Date: 29 May 2019 13:13:23 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dmarc@ietf.org In-Reply-To: References: <20190523225213.C214620147B780@ary.qy> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 29 May 2019 17:13:44 -0000 > You seem to be suggesting that the standards-track DMARCbis should be > different because an informational, non-WG RFC has already been > published. From a process standpoint that's bad; standards-track RFCs > should go through exactly the same process regardless of whether or not > they were previously published as Informational. As far as I can tell your proposal to break the document in two has gotten no support at all. Can we stop now? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 29 10:49:40 2019 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 21CCB120227 for ; Wed, 29 May 2019 10:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 tes4hczRZElP for ; Wed, 29 May 2019 10:49:37 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 350D01201E0 for ; Wed, 29 May 2019 10:49:35 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4300:2290:a4d8:3398:c9b6:6198]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x4THnYZO003712 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 May 2019 10:49:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1559152175; bh=V90RJtE8//HajASAovqkw0oYcrYroVnwuV/Ezu3Akuc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=MRVAlpuyRsShLQ+GMVlmxxQQy0lK3mQO5ey2GBBW4fi7C04nRrL0oq4Al57Ylook1 y8uapjCdwBa7eNcgPnt+rA6ND+RnwRr7qxmNCGlv6LzT1G0vSDqBAduO4uc3Q2U5o0 JIoqAeW3jiQXEb+LFWAstjJAfsCVBFb4E2p9zes0= To: John R Levine Cc: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: Date: Wed, 29 May 2019 10:49:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 29 May 2019 17:49:39 -0000 On 5/29/19 10:13 AM, John R Levine wrote: >> You seem to be suggesting that the standards-track DMARCbis should be >> different because an informational, non-WG RFC has already been >> published. From a process standpoint that's bad; standards-track RFCs >> should go through exactly the same process regardless of whether or not >> they were previously published as Informational. > > As far as I can tell your proposal to break the document in two has > gotten no support at all.  Can we stop now? > This was about a broader process issue and not specifically about splitting the document into parts (I should have changed the subject line). But yes, we can stop talking about the document split. From nobody Wed May 29 11:19:58 2019 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 888E11200B3 for ; Wed, 29 May 2019 11:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPVebESAGncV for ; Wed, 29 May 2019 11:19:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A992C12004F for ; Wed, 29 May 2019 11:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1559153992; bh=ha6Hbqi3t6qgRZNMNceIyyv2qqr5jQmacr/wQLP8k88=; l=1410; h=To:References:From:Date:In-Reply-To; b=CmbB8dqeaq54q8qUbjIWpL7cAJzkderJMW3TzpKqEsYDgKiHZZiUWdSiE+9n+LUCX V0KkVgdKndrKZxwg5tUCnVf8fIy/dUDrN0slQ+GVdLeDPaflysOg78Ms0RDIdjTpft njHtVDeE/0cKTfvcxLDbR78knXiDdZKECLik9Jkg2LJ8XwliBAUOX85pmKDUh Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 29 May 2019 20:19:52 +0200 id 00000000005DC079.000000005CEECD48.0000277E To: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 29 May 2019 20:19:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 29 May 2019 18:19:58 -0000 On Wed 29/May/2019 19:01:11 +0200 Jim Fenton wrote: > One more point on this: > > On 5/24/19 7:37 AM, John R Levine wrote: >> >> That's because they separated before they were published, so there was >> nothing to be incompatible with.  If I knew what would break when >> reorganizing and rewriting a document into pieces, I could fix it, but >> since I don't, and nobody else does, let's not go there. > > > You seem to be suggesting that the standards-track DMARCbis should be > different because an informational, non-WG RFC has already been > published. From a process standpoint that's bad; standards-track RFCs > should go through exactly the same process regardless of whether or not > they were previously published as Informational. Albeit rfc7489 is informational, it is meant to be a spec. So structural changes to the document, however useful to first-time readers, would be a nightmare for those who have already implemented DMARC and are checking what has changed. It would also disrupt many references, thereby invalidating a large part of the literature. A new companion rfc (or a new appendix, or a rewriting of Section 8) meant as an implementation guide could host discussions about the points 1a... 4b listed upthread. It should recount the most useful tips we collected thus far, rather than trying to establish normative duties, IMHO. Best Ale -- From nobody Wed May 29 14:54:39 2019 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 4BF0E120134 for ; Wed, 29 May 2019 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=OpZT7osZ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=RV4KppKZ 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 sVqNHFBhCF5v for ; Wed, 29 May 2019 14:54:35 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 27694120096 for ; Wed, 29 May 2019 14:54:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=794; t=1559166869; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=bAFuzpD8Yl2BNJP7VmSB2Sf3Oz8=; b=OpZT7osZyH/eQA8YIBRocPYBRoOGbLHnywauh1sCRaC3FkVgYqioB830Btpmg9 bc5hMxkQNqxO8LVnZB8GX0UPbqA1DBzNK+pXBBBNxk2Fm9jZrlId/glFPlfp0Fs/ FOG5JEWC6R8W7HFD6Htdm2eIByA70FIqX+KrhPpRwLb/o= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 29 May 2019 17:54:29 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 4254288835.58212.3356; Wed, 29 May 2019 17:54:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=794; t=1559166698; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qw/E7LI M5QhAmdCN/okp3Hj6PmvwJDR+HLv9jNu8ZFg=; b=RV4KppKZBHM5A7E+Bz6ih/U LmQioEsc1rpKkFmsjbYQ0HoM9OdCZVTyYYTxMnH5SomJ+Syf7JFAA7AI9XZBlsBC eyyDpNK6chPoF/JmOHbML7FUnrV/WbEXfsIPQxBjIqePGZ1Y8Jdky9oDvzMHOwM2 Md5y4KwX53XzHFjfSRsw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 29 May 2019 17:51:38 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1531554020.9.276472; Wed, 29 May 2019 17:51:38 -0400 Message-ID: <5CEEFF97.8010104@isdg.net> Date: Wed, 29 May 2019 17:54:31 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20190523225213.C214620147B780@ary.qy> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 29 May 2019 21:54:37 -0000 On 5/29/2019 1:13 PM, John R Levine wrote: >> You seem to be suggesting that the standards-track DMARCbis should be >> different because an informational, non-WG RFC has already been >> published. From a process standpoint that's bad; standards-track RFCs >> should go through exactly the same process regardless of whether or not >> they were previously published as Informational. > > As far as I can tell your proposal to break the document in two has > gotten no support at all. Can we stop now? "No support at all?" For the record, I support the "split." But I won't care it is remains. I just think it will complicate a specification and extend the future work of completing a DKIM Policy Model proposed standard which is in need of a tremendous amount of work. -- HLS From nobody Thu May 30 09:06:24 2019 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 7A1CF12010C for ; Thu, 30 May 2019 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 yLMWXGaLXsjB for ; Thu, 30 May 2019 09:06:21 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100114.outbound.protection.outlook.com [40.107.10.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35798120058 for ; Thu, 30 May 2019 09:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LFmCSNSOcFd+UYrM777ENSLA5/Yym4Aibn+eU9DGYPU=; b=WqaE5zBtDoJa6vDU/3UQ98j/Q/xVIk1L66f1VNGho7cDwBGJYexJBNBhsBrixvCW1MC2Xg98WTLPIwvWtIBp/2VBW8Qr/js0FCOTJRlaOqj2rqad5FXulfiFrtHl0XQrFwU/Y9/OHIUAwRorfMLEBLdql2iubbTzRojz8j7+2nw= Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM (20.176.156.23) by LO2P123MB1710.GBRP123.PROD.OUTLOOK.COM (20.176.154.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.17; Thu, 30 May 2019 16:06:18 +0000 Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::fc74:1f4:86dc:24de]) by LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::fc74:1f4:86dc:24de%7]) with mapi id 15.20.1922.021; Thu, 30 May 2019 16:06:18 +0000 From: Richard C To: "dmarc@ietf.org" Thread-Topic: DMARC PSD and non-existent subdomains Thread-Index: AdUW/jphmQ6IwLIpSlOVp/KM9LEwVA== Date: Thu, 30 May 2019 16:06:18 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Richard.C@ncsc.gov.uk; x-originating-ip: [51.140.78.31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 038070da-517c-4106-1abc-08d6e518c00d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB1710; x-ms-traffictypediagnostic: LO2P123MB1710: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(39850400004)(366004)(189003)(199004)(51874003)(71200400001)(2351001)(66556008)(6436002)(64756008)(66446008)(66946007)(75922002)(81156014)(66476007)(5660300002)(73956011)(74482002)(86362001)(3846002)(6116002)(790700001)(2501003)(66066001)(52536014)(71190400001)(316002)(7696005)(81166006)(2906002)(26005)(25786009)(33656002)(478600001)(72206003)(8676002)(14444005)(1730700003)(256004)(68736007)(14454004)(76116006)(186003)(6916009)(6506007)(102836004)(9326002)(53936002)(7736002)(55236004)(99286004)(8936002)(74316002)(55016002)(476003)(9686003)(54896002)(6306002)(5640700003)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB1710; H:LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AJyfA3xFx3aFOF3MMvNb2Zv3aalaXkAfRoI+R1PytGKUMvZlyP3jSJn7eCXjlBrMDtfKsJfFiNnzaUFiNRBgG55vbM5ABzT+PIqJUg8WEVk5cA+paYeyHmSABpgn9q/rqCl9H2txbMLT0BXVNG9PwiMcsIf2gCfnTcQqWJw0X1Tke2PpjY9+jbNxxoBnhJdJsfkwDoWMIrdTonz6BwvpNdhO03oNm1VBjwchojD4xtKmuhOO0NIgZq195xIeFhNP2mgcWCk0g87UMrDku5umWfhOzQ/dVHztewN8Xd8qmHoTHC6N9oYTRo32tAo+5Img/0oTmxxiAl6HxWC6vPw0KxVnN5BYMIMVGr0B2g6bkn7Ajmae1Y2Gte/Pr70JfeRYFEP11X6KvPSTqouIA1KpQPOnFbpv+kLDR1uzm1+HrAA= Content-Type: multipart/alternative; boundary="_000_LO2P123MB2334F6DE24EFE7FF43DEDB39AD180LO2P123MB2334GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 038070da-517c-4106-1abc-08d6e518c00d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2019 16:06:18.1794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: richard49955@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1710 Archived-At: Subject: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 30 May 2019 16:06:23 -0000 --_000_LO2P123MB2334F6DE24EFE7FF43DEDB39AD180LO2P123MB2334GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello At the National Cyber Security Centre in the UK we're supportive of the PSD= DMARC initiative. However, we currently have one problem that would hamper= its applicability to our use case: We essentially have the need to express= different subdomain policies to existing and non-existing domains. In our = case for the gov.uk PSD we'd like to be able to set a 'reject' policy for n= on-existent subdomains to prevent delivery of email from them whilst not in= terfering with authentication of email for the legitimate subdomains. Why? Well, whilst we have a programme of work to get domain owners under go= v.uk to implement DMARC and other standards, it will take some of them time= , and we don't want to inadvertently break mail delivery for the organisati= ons that have e.g. implemented SPF but not DMARC. But on the flipside, we a= lso know that non-existent domains under gov.uk are being spoofed for phish= ing, so we want to publish a policy of 'reject' on those and receive report= ing about them. What would be the best way to incorporate this requirement? Thanks in advance Richard Crowther, NCSC This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LO2P123MB2334F6DE24EFE7FF43DEDB39AD180LO2P123MB2334GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

At the National Cyber Security Centre in the UK we'r= e supportive of the PSD DMARC initiative. However, we currently have one pr= oblem that would hamper its applicability to our use case: We essentially h= ave the need to express different subdomain policies to existing and non-existing domains. In our case for t= he gov.uk PSD we’d like to be able to set a ‘reject’ poli= cy for non-existent subdomains to prevent delivery of email from them whils= t not interfering with authentication of email for the legitimate subdomains.

 

Why? Well, whilst we have a programme of work to get= domain owners under gov.uk to implement DMARC and other standards, it will= take some of them time, and we don't want to inadvertently break mail deli= very for the organisations that have e.g. implemented SPF but not DMARC. But on the flipside, we also know that= non-existent domains under gov.uk are being spoofed for phishing, so we wa= nt to publish a policy of 'reject' on those and receive reporting about the= m.

 

What would be the best way to incorporate this requi= rement?

 

Thanks in advance

 

 

Richard C= rowther, NCSC

 

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LO2P123MB2334F6DE24EFE7FF43DEDB39AD180LO2P123MB2334GBRP_-- From nobody Thu May 30 11:06:33 2019 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 9959E12029D; Thu, 30 May 2019 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 SXcanapUfYUH; Thu, 30 May 2019 11:06:23 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 5207F120291; Thu, 30 May 2019 11:06:23 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id a10so3749702ljf.6; Thu, 30 May 2019 11:06:23 -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=9HhA9m/darhWEDON/aaFVasWO2n37jX4jYBE/596WD8=; b=tZ5VIok3PI2qLtFwCWTJ8Pt+D8vty23N9q77qv1E0V2nAZZEilHI/7ZvYjdbDHLE6v SVH51hdA3IHPNHHAI1cJ7kRR5IeuKyNFnlJ2+lk+Z8dFjDBT6TtecOoZIWaGrtAEsZ9s RytJ6CuEjkCz39aYKQfETG4A8NiqseJcbdR20eV5Ct6qrhkB3F9NxpVMMX0J6Z3ELeV4 M8jOsVFCOnwDWUbzw3zpOP0FaeQbY/UTyDz2ZCb0IpNlCzXwLxFgmh12/VEH+G0yentl o+QMa4bKOqril3jBKW2YYqkCha8eSpDw/x3AvVdZJwF2kfwH6CoIX7fza8fjRW9RcWv0 Xajg== 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=9HhA9m/darhWEDON/aaFVasWO2n37jX4jYBE/596WD8=; b=CmQjk0pLx2+/dC7OtUJuuKlUXKjtZczLSz888GNxDglj3SOIGiXYqmGJBKLyAMo390 mmhd1TdRtrofmGVUkohm1y85krvc1Bj93MslHhUGj+PBa4UysRkQIVEhvy9q3ad3y3d4 /xGJO57cOMZqo4/7PiZbk1pnPcv8lc0ACSww8VtnGEZP7l3UubB0oEyaDTDvBaPNAg6i TCz2bIqorCAsTLJy7EHmb2e2YyVdp/pq+1J831BNkoVtGVxwrszRKq9gebAreRhEM+UO 0b0NybBZJENeEGo4jOc7Rvx+PTchHQfSRv9pbsqIbqK9i+h++QEg/Ch28m7hB4cHdPaw 2NgQ== X-Gm-Message-State: APjAAAUz2E8W0aVCGvQeEG7Ggk1N4kZT4JQ3TMILmYfSelY7m7ZhRL8K B5jTg4AJS6E88kzCyTlseKWb0xjR39xgOTICR4PD2g== X-Google-Smtp-Source: APXvYqx0CVbnNE/BsBRk7930TgZXLdTVE25BJ1V6gik8eh/mOxHsx7ox8D1UGlAoe2JI7X3zEnPwjC7wFyYOnfQXmpA= X-Received: by 2002:a2e:9cd5:: with SMTP id g21mr2637682ljj.39.1559239581388; Thu, 30 May 2019 11:06:21 -0700 (PDT) MIME-Version: 1.0 References: <155899759708.543.16777184314234317178@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 30 May 2019 11:06:09 -0700 Message-ID: To: Craig Schwartz Cc: IETF DMARC WG , i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e5c30058a1ec1ec" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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: Thu, 30 May 2019 18:06:31 -0000 --0000000000005e5c30058a1ec1ec Content-Type: text/plain; charset="UTF-8" I'll initiate WGLC before the weekend. I have some feedback from outside the WG that I will forward, but it's not serious enough to block starting WGLC. On Tue, May 28, 2019 at 5:17 AM Craig Schwartz wrote: > I've reviewed the draft. We plan to implement this as soon as possible > (for .bank and > .insurance) and would like to see this get to WG last call shortly. > > Craig Schwartz > Managing Director > fTLD Registry Services | .BANK & .INSURANCE > Office: +1 202 589 2532 > Mobile: +1 202 236 1154 > Skype: craig-schwartz > www.fTLD.com > > > > > > > On Mon, May 27, 2019 at 6:53 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 : DMARC (Domain-based Message Authentication, >> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) >> Author : Scott Kitterman >> Filename : draft-ietf-dmarc-psd-04.txt >> Pages : 11 >> Date : 2019-05-27 >> >> Abstract: >> DMARC (Domain-based Message Authentication, Reporting, and >> Conformance) is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for >> message validation, disposition, and reporting, that a mail-receiving >> organization can use to improve mail handling. DMARC policies can be >> applied at the individual domain level or for a set of domains at the >> organizational level. The design of DMARC precludes grouping >> policies for a set of domains above the organizational level, such as >> TLDs (Top Level Domains). These types of domains (which are not all >> at the top level of the DNS tree) can be collectively referred to as >> Public Suffix Domains (PSDs). For the subset of PSDs that require >> DMARC usage, this memo describes an extension to DMARC to enable >> DMARC functionality for such domains. >> >> >> 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-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-04 >> >> >> 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 >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005e5c30058a1ec1ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll initiate WGLC before the weekend.=C2=A0 I have so= me feedback from outside the WG that I will forward, but it's not serio= us enough to block starting WGLC.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 28, 2019 at 5:17 AM Craig = Schwartz <craig=3D40ftld.co= m@dmarc.ietf.org> wrote:
I've reviewed the draft.=C2=A0=C2=A0We plan to implement this as soon as pos= sible (for .bank and=C2=A0
.insuranc= e) and would like to see this get to WG last call shortly.=C2=A0=C2= =A0

Craig Schwartz
Managing Director
fTLD Registry Services | .BA= NK & .INSURANCE
Off= ice: +1 202 589 2532
Skype: craig-schwartz
www.fTLD.com=



<= /div>

=
On Mon= , May 27, 2019 at 6:53 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:= DMARC (Domain-based Message Authentication, Reporting, and Conformance) Ex= tension For PSDs (Public Suffix Domains)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scot= t Kitterman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-psd-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-05-27

Abstract:
=C2=A0 =C2=A0DMARC (Domain-based Message Authentication, Reporting, and
=C2=A0 =C2=A0Conformance) is a scalable mechanism by which a mail-originati= ng
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.=C2=A0 DMARC pol= icies can be
=C2=A0 =C2=A0applied at the individual domain level or for a set of domains= at the
=C2=A0 =C2=A0organizational level.=C2=A0 The design of DMARC precludes grou= ping
=C2=A0 =C2=A0policies for a set of domains above the organizational level, = such as
=C2=A0 =C2=A0TLDs (Top Level Domains).=C2=A0 These types of domains (which = are not all
=C2=A0 =C2=A0at the top level of the DNS tree) can be collectively referred= to as
=C2=A0 =C2=A0Public Suffix Domains (PSDs).=C2=A0 For the subset of PSDs tha= t require
=C2=A0 =C2=A0DMARC usage, this memo describes an extension to DMARC to enab= le
=C2=A0 =C2=A0DMARC functionality for such domains.


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-= 04
https://datatracker.ietf.org/doc/html/d= raft-ietf-dmarc-psd-04

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


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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000005e5c30058a1ec1ec-- From nobody Thu May 30 11:13:54 2019 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 CE5A4120274 for ; Thu, 30 May 2019 11:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 LTvLieJZFzmD for ; Thu, 30 May 2019 11:13:52 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 E30E0120266 for ; Thu, 30 May 2019 11:13:51 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id z5so6974106lji.10 for ; Thu, 30 May 2019 11:13:51 -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=kNgOzsmwJyMVGFnNNjiN8o+PjXXGRM/FD8KAnQdyXuM=; b=JM8tj2YUrTTWfrxCe52KXMQPPjoGNdeCQvGyMXyr2OeWowh+TYLdJRy16AnuzM44t3 qTMnr7wqgfA7D/fsuDezz1vQUySsBB2BKs+aAVYiHue/r0dwk81uAjJbmp68tkZYJ/bk WJ6le1CNoamKjlHqT4lFsio335Y5yRcHqf4AP288eAKT5GmtQLO9lvOLZlUBvH3c5Tu7 1vSDj3tZa5A4DxQIDJRkGfItdfMDYjtB3kcp/UUHvlM0KfNEHueoGNwY0FZ06jqPcD// s+uxcC1ECj8dlOW/g1hw713p6Q3tUKVGtzGlZwc5T5UPWDrJ4w+hf2BoiAnNgKCk5M4d G6+w== 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=kNgOzsmwJyMVGFnNNjiN8o+PjXXGRM/FD8KAnQdyXuM=; b=bdOtkDCupelf+RPa9K/VaZHInrjjiZ0n3KnR0BwmqzCw0tepL8i1sHHrJRVuNvrSUa Bhf3HXAg31i0gU1jtWDi1ksUs8cxRCnzr1XbRjQ+wJmtEzHQ2vs6jMVv1P5EgS+hUdlX C5xQ1FJypQl7qre7AB5jXKZv/XvS0t9IDEQ3Ol4dR0KQrBpxKpjVK4oylAFlkMM9YB3r RQ1E05L6VtVj8yGI9J8/4ws6/RxxxdYxVGhPwRBoBloxoRv31ljjsbPGwz0rsmYQpBKn DWlM1Xto1KNFGSiPC4y39SDN61Aq8jE6zBIYzP8b9wMRF7aTMpEjDBfPqJL8qbpu1KiV JJSQ== X-Gm-Message-State: APjAAAXdNgTAMnAozUIQrDSY79GJgmMawupXn9xiNBxmx5kfLb3Kv1xU yMl0dUBD1H7fAN0GbMfCPZtSFpwERCr45kem4egXNQ== X-Google-Smtp-Source: APXvYqxZMrX3rX6U5L+NqMpDcA7dEks0U7608lcbr8sEV4rdJDYgB3TZLfKkmmYKsK0tL4oErpXWFefGl/qu47F+Ysg= X-Received: by 2002:a2e:730c:: with SMTP id o12mr2957749ljc.61.1559240030073; Thu, 30 May 2019 11:13:50 -0700 (PDT) MIME-Version: 1.0 References: <20190523225213.C214620147B780@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 30 May 2019 11:13:37 -0700 Message-ID: To: John R Levine Cc: Jim Fenton , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001cb708058a1edcd4" Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 30 May 2019 18:13:54 -0000 --0000000000001cb708058a1edcd4 Content-Type: text/plain; charset="UTF-8" On Wed, May 29, 2019 at 10:13 AM John R Levine wrote: > As far as I can tell your proposal to break the document in two has > gotten no support at all. Can we stop now? > What's on topic for the group and what isn't is the purview of the co-chairs and the charter. Let's please not stifle discussions before they die on their own absent chair action to the contrary. -MSK, from the floor --0000000000001cb708058a1edcd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2019 at 10:13 AM John R L= evine <johnl@taugh.com> wrote:=
As far as I can tell your proposal to break the document in two= has
gotten no support at all.=C2=A0 Can we stop now?

<= /div>
What's on topic for the group and what isn't is the purvi= ew of the co-chairs and the charter.=C2=A0 Let's please not stifle disc= ussions before they die on their own absent chair action to the contrary.

-MSK, from the floor
--0000000000001cb708058a1edcd4-- From nobody Thu May 30 11:21:02 2019 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 485C71200FD for ; Thu, 30 May 2019 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 5O44uQt0FQVS for ; Thu, 30 May 2019 11:20:55 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 BA6B8120165 for ; Thu, 30 May 2019 11:20:54 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id a9so4375320lff.7 for ; Thu, 30 May 2019 11:20:54 -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=9LQpS4y+wDZEvTd8UAK0sIK3kCO9g7G/Xz8HYdf2/B4=; b=CLij4dioZu9ryUSOEZT3LZBf8Hw2C6T7ts3zmA8isT1czA/KEu/3TuLp6GeiBOZIh6 KZzns7jY5JWENKf36vnQh7mJAeWF/0VmSm9LkAqblNnfqHyuX+uZLIHiZ9PNC2ocpeii N/0mpy70KC+ayZi2JYK/T8coomfg8PutJg1gZd/qLdRhsR8cUTBuyYBZc72FqCli9h1o e+MGKLv3SwA77cIJzl+kC4cs9h3zrChHr1TkGZYDbrOYN4jIxINOP+0VHZlzgpx3f4HO Z54sfhzXn/Xj0D2bYGKA+Pn3x/QNi6NhgcCOjWVXvKsvtf0zaQTmWoFPglb75imS5dl6 TDzw== 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=9LQpS4y+wDZEvTd8UAK0sIK3kCO9g7G/Xz8HYdf2/B4=; b=KWbcnlzM6gk5RBDaarPjb9OeIUkso5juya5kVxjM1czLPH7RyKNFqMXWuPPl8AAVMF s8JF3OfjuudNs548cVAI8bo/GeE87JI+MJ6elAsIIyGROWVmiYdwiOSHEwzeEyng9yi2 y0Lhp0PcMZtNQlyre3SsG19I8otWcNJ9dhYD9hn80MFGj0vC76xyTjKrCBbqi0qCrAq7 R2417EYdjvvHoHUmqRjfyCnjINOnv6rAlxkE9PHcS3UXyBwAGtEYLHi5ErMNhwHzYYQR IHXPX7lxZxRHTETDOIy7KjYfv53DUBZda6QHXJ7VJFdQpFSjbEowPQ/qdOUKd4tpFGJY 1nog== X-Gm-Message-State: APjAAAXdnFBWIn16J3u6ZU3waWZVWx/Bq8Ll5D6OEr39lS+/tHowpPC0 rlWknTSaFAyFGVaIgfiOKXCGEEgRE3EATKVoNS0= X-Google-Smtp-Source: APXvYqzByL4JBv+nym62Os7aGv8vomqUqscg/42pt25tK9PhHhB4FLTZkWtkH0hVM6FdFEypRViXlzAwruz2wWQHmrk= X-Received: by 2002:ac2:46f9:: with SMTP id q25mr3154495lfo.181.1559240452932; Thu, 30 May 2019 11:20:52 -0700 (PDT) MIME-Version: 1.0 References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> In-Reply-To: <20190526144848.08A772014A0BF4@ary.qy> From: "Murray S. Kucherawy" Date: Thu, 30 May 2019 11:20:41 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Content-Type: multipart/alternative; boundary="000000000000510903058a1ef54f" Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 30 May 2019 18:20:56 -0000 --000000000000510903058a1ef54f Content-Type: text/plain; charset="UTF-8" On Sun, May 26, 2019 at 7:49 AM John Levine wrote: > In article <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> you write: > >-=-=-=-=-=- > > > >Hello Douglas, > > > >1) Check the Authentication-Results header. An implementation could put > there additional information as comment. A > >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt > trust the previous hop. Common case: aliases > >to random servers. > > That would be my suggestion. You can put whatever you want into comments > in the A-R header. > At one point in the early DKIM days we were discussing a way to have DKIM verifiers return enough information to signers to indicate what the mutation was that invalidated a message. This was supremely useful in the early days of DKIM when we were just figuring out how to interoperate; if I keep a copy of the the canonicalized header and body of something outbound, and then on receipt you find the signature doesn't validate, then you send me the canonicalized header and body you saw, and I get to diff them to see what mutation broke the signature. We ended up with RFC6651 and the ones to which it references. OpenDKIM implements this, but I don't think any other implementation does, so its use is obviously very limited. And as John said, there have been numerous proposals over the years of ways to annotate a message with what "standard" mutations were done so that at verification time the receiver could decide which mutations it was willing to forgive, but the community showed no interest in such complexities. -MSK --000000000000510903058a1ef54f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, May 26, 2019 at 7:49 AM John Levi= ne <johnl@taugh.com> wrote:
In article <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aeg= ee.org> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>Hello Douglas,
>
>1) Check the Authentication-Results header. An implementation could put= there additional information as comment. A
>downstream MTA will reevaluate the DKIM-Signature anyway, if it does nk= t trust the previous hop. Common case: aliases
>to random servers.

That would be my suggestion.=C2=A0 You can put whatever you want into comme= nts in the A-R header.

At one point in = the early DKIM days we were discussing a way to have DKIM verifiers return = enough information to signers to indicate what the mutation was that invali= dated a message.=C2=A0 This was supremely useful in the early days of DKIM = when we were just figuring out how to interoperate; if I keep a copy of the= the canonicalized header and body of something outbound, and then on recei= pt you find the signature doesn't validate, then you send me the canoni= calized header and body you saw, and I get to diff them to see what mutatio= n broke the signature.

We ended up with RFC6651 and the ones to whic= h it references.=C2=A0 OpenDKIM implements this, but I don't think any = other implementation does, so its use is obviously very limited.

And as John said, there have been numerous proposals over the years= of ways to annotate a message with what "standard" mutations wer= e done so that at verification time the receiver could decide which mutatio= ns it was willing to forgive, but the community showed no interest in such = complexities.

-MSK
--000000000000510903058a1ef54f-- From nobody Thu May 30 14:18:54 2019 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 72FF012016E for ; Thu, 30 May 2019 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1536-bit key) header.d=iecc.com header.b=K0Gb3ZQP; dkim=pass (1536-bit key) header.d=taugh.com header.b=GtU6koK3 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 xu35O5j9wmSb for ; Thu, 30 May 2019 14:18:50 -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 1448A1200E3 for ; Thu, 30 May 2019 14:18:49 -0700 (PDT) Received: (qmail 28868 invoked from network); 30 May 2019 21:18:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=70c0.5cf048b8.k1905; i=johnl-iecc.com@submit.iecc.com; bh=wkSy/Db9w2AXspF2/3SUNqrGfXTr5ulG+13boC2cFgE=; b=K0Gb3ZQPar8J9Q5nF+JPTwh9syjAEhntSfbPnjb1uGhJWCLM+UbM/w6OpEGW2KCyjBd9S/v4hsVCZ/+ik57F2tEgbOybob8mqL3AWg9OduGdjTXPRTK0lXvanNe0Tb9fuk+mKWN8utV3CFIYHprT4w3OW6b1r11pjkBsVX0CO6NYjM6VeltsaNNpWByvYspjlj4dPaBzpRIZuT9JSgeL0cHQ58DRoxVIQiD+wUMzdket1FZtk8myhDU2CBlZNZ7C DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=70c0.5cf048b8.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=wkSy/Db9w2AXspF2/3SUNqrGfXTr5ulG+13boC2cFgE=; b=GtU6koK3LD75PxqFwDP04Zixxa/ufsUNXCv4A0QuVuMqdOd7u1bMavczb8VR/KxH5WT+MkF43OuhbU/VArAK9xPlHE1R+dtuBO4NJwVBsxJUlhMIUtdPcrjx1fDEo8n7ekSBVTH9NzCFy2BYtDcx31BgmK4sjPBBVgWQSCLOu780sbfZCxXqCp7wL7buf2YWgbUujYprCj06X/tDksYrxGh2LUDEV4dXFlLM5hRmtoUdrOKpXuYfAjHfM38fJ36v Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 30 May 2019 21:18:47 -0000 Date: 30 May 2019 17:18:47 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 30 May 2019 21:18:53 -0000 > And as John said, there have been numerous proposals over the years of ways > to annotate a message with what "standard" mutations were done so that at > verification time the receiver could decide which mutations it was willing > to forgive, but the community showed no interest in such complexities. It is my impression that the proponents of this idea tended not to be very familiar with mailing list software and imagined that most mutations were simple, like adding a subject tag or a text footer. Those happen, but they are the very tip of the iceberg. Modern list managers add, delete, and reorder MIME parts, flatten HTML into text, and a huge list of other things that no mutuation catalog could plausibly describe. That's one of the reasons that ARC doesn't try to say what's changed, just what the authentication results were before and after. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 30 16:43:55 2019 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 C04B4120259 for ; Thu, 30 May 2019 16:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=sethblank-com.20150623.gappssmtp.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 Vobbi2CaWjCR for ; Thu, 30 May 2019 16:43:45 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 8476412022A for ; Thu, 30 May 2019 16:43:45 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id 18so5577450oij.5 for ; Thu, 30 May 2019 16:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LeirxyNAo/ZEPag35yJPRRRGzKXwgTpReo+L1V6Icg0=; b=BpzNr9EYeTgdSvTuR12w72mgHbgHn53pxLBHjweKaW9Xb5zbzYPWY21DSL46tP+SL3 X+1evI4Dylbl8zHqKR5gM05om2x/AZdlB4/ZqAdQ5V8+8qHJdZLGxDsXoEwqKDNSui9d yl2odgNo+Y4RtIWd9K8arkA2UkWpfnFU3f66Tm9d2Xcs4VRkZfT76WrK0zcNpNzzW0cs qQDo0488qe4Gd5EiAm6ToPtcyxZhJWZWrLkBuX7FTcP/9LoGYU+MgJvrSSQPB8I8fAKA G8pdsCalROahqgvDb66Eqh6hBZUOL/utvaDOKYapBbygmzAbUG1+N8Ly6YTvi9xIHxb8 WGbQ== 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=LeirxyNAo/ZEPag35yJPRRRGzKXwgTpReo+L1V6Icg0=; b=l7+KWoc3siKJFa1V/uoMXEjIP1+yLOkpneQADrfDs5Xj3Bctf/o0aQN5sP3NzupRSe yri/rFF06QeoXUwykho6ccpAl7VEgcpJ7Fs9as80870lKsPLqna0hZpk5mDZon1c+u2G cubqG0XMPYmPFFjNIzEn/+YnxFVWLsKfR92h07PDYdOh1EFNvYuo8LjyG+92cS5uymkX x9LtNAa+nMGmUgtw9ixMfDi6yxkbbmDTVv7d2f0GOdnY9FqSQ4ERFnYqztfrb6mBovLW Y6Ok9RrmiRdOVZqkBIX7clyGUXRmmaPUyFTZeXEdRvxOJJbyE4BQf4I+LU4sS+nM0rqg OT2A== X-Gm-Message-State: APjAAAURnul5pfFguXv3aEX01jtI+d6AZ9DVOaKUEjkpaf14RgqoGTjB wybhqnF/z+YXPjrXXsi1VeCmbvwCXc2Yz/aplVfx5OfJPS0= X-Google-Smtp-Source: APXvYqxk0eRycw5FlFYwvK3cWPJ1xbtgF/B00iYYVAnlMzhWL4qHRTMiJlI/NGKrq7Nc1zIv67gacIV/uvhJRH8iyMQ= X-Received: by 2002:aca:e005:: with SMTP id x5mr3984409oig.144.1559259824652; Thu, 30 May 2019 16:43:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Thu, 30 May 2019 16:43:28 -0700 Message-ID: To: Richard C Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f618ac058a237799" Archived-At: Subject: Re: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 30 May 2019 23:43:54 -0000 --000000000000f618ac058a237799 Content-Type: text/plain; charset="UTF-8" On Thu, May 30, 2019 at 9:06 AM Richard C wrote: > What would be the best way to incorporate this requirement? > The simplest possible way to address this use case is just to make sure those existing but currently non-compliant domains just have a bare p=none record. Then they'll never fall back to the gov.uk record. There's no risk to inadvertently breaking mail here. It it remotely realistic for you to offer this guidance? If you're already saying that p=reject is required, how painful is it to advertise that any domain without a DMARC record will get p=reject by default unless it explicitly puts p=none in? Seth --000000000000f618ac058a237799 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2019 at 9:06 AM Richard C= <Richard.C=3D40ncsc.gov= .uk@dmarc.ietf.org> wrote:

What would be the best way to incorporate this requi= rement?


The simplest possib= le way to address this use case is just to make sure those existing but cur= rently non-compliant domains just have a bare p=3Dnone record. Then they= 9;ll never fall back to the gov.uk record. Th= ere's no risk to inadvertently breaking mail here.

It it remotely realistic for you to offer this guidance? If you= 9;re already saying that p=3Dreject is required, how painful is it to adver= tise that any domain without a DMARC record will get p=3Dreject by default = unless it explicitly puts p=3Dnone in?

Seth
<= div>
--000000000000f618ac058a237799-- From btv1==05408f7c171==fosterd@bayviewphysicians.com Thu May 30 19:49:15 2019 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 AAFE21200C1 for ; Thu, 30 May 2019 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=bayviewphysicians.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 1QKXAQBZT7ZL for ; Thu, 30 May 2019 19:49:14 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C645120019 for ; Thu, 30 May 2019 19:49:14 -0700 (PDT) X-ASG-Debug-ID: 1559270952-11fa3116c826baa0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 6iiDxODVZtHaOiv5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 30 May 2019 22:49:12 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=p9SeoAo2Gg0m7HcVXIDZ6icsUzyrmTBUbvR1rjFetes=; b=I0SFzaLsST31bamHB3jgZa+ub7U48obw5cOHHIeSCaSLBTvT0Gy3rniX7JvMZ7cGj Uf9TIH35vIpQSdBPx9DrjPxO5iYb1rEvYQ1FQLqlf+uu2p66C/KjjR7NYYm1NwszB aKPOgraI4PDrXCtJwnkLjgpMtr5jz+nSRzCXKGOMo= Received: by webmail.bayviewphysicians.com via HTTP; Thu, 30 May 2019 22:49:03 -0400 From: "Douglas E. Foster" To: "Murray S. Kucherawy" , "John R Levine" CC: "IETF DMARC WG" Date: Thu, 30 May 2019 22:49:03 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=7d96ac98f2624210b8af02af44a58890 X-Originating-IP: [192.168.1.239] In-Reply-To: References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> X-Exim-Id: c559a331d90b49eba5b5f6e35ff4774a X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559270952 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5003 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 02:50:39 -0000 This is a multipart message in MIME format. --7d96ac98f2624210b8af02af44a58890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you for the education The IETF list processor seems to be an illustration of your point. It invalidates the orginal sender's signature Then it adds an ietf.org signature Then the message is relayed internally within a single IETF server, where the IETF signature is invalidated. The the message is signed a second time with an valid IETF signature I rather hoped that IETF would be the poster-boy for list processing done correctly. Why is the message manipulation that you describe necessary or acceptable? Deeply puzzled, Doug Foster ---------------------------------------- From: "John R Levine" Sent: Thursday, May 30, 2019 5:19 PM To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion > And as John said, there have been numerous proposals over the years of ways > to annotate a message with what "standard" mutations were done so that at > verification time the receiver could decide which mutations it was willing > to forgive, but the community showed no interest in such complexities. It is my impression that the proponents of this idea tended not to be very familiar with mailing list software and imagined that most mutations were simple, like adding a subject tag or a text footer. Those happen, but they are the very tip of the iceberg. Modern list managers add, delete, and reorder MIME parts, flatten HTML into text, and a huge list of other things that no mutuation catalog could plausibly describe. That's one of the reasons that ARC doesn't try to say what's changed, just what the authentication results were before and after. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --7d96ac98f2624210b8af02af44a58890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Thank you for the education The IETF list processor seems to= be an illustration of your point.
  • It invalidates the orginal sender's signature
  • Then it adds an ietf.org signature
  • Then the message is relayed internally within a single IETF serve= r, where the IETF signature is invalidated.
  • The the message is signed a second time with an valid IETF signature
I rather hoped that IETF would be the poster-boy for list processing d= one correctly.  Why is the message manipulation that you describe=  necessary or acceptable?
 
Deeply puzzled,
 
Doug Foster
 
 
 
From: "John R Levine" <johnl@taugh.com>
Sent: Thursday, May 30, 2019 5:19 PM
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "IETF DMARC WG" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- su= ggestion
 
> And as John said, there have been numerous proposals over the years of= ways
> to annotate a message with what "standard" mutations were do= ne so that at
> verification time the receiver could decide which mutations it was wil= ling
> to forgive, but the community showed no interest in such complexities.=

It is my impression that the proponents of this idea tended not to be very<= br /> familiar with mailing list software and imagined that most mutations were simple, like adding a subject tag or a text footer. Those happen, but
they are the very tip of the iceberg. Modern list managers add, delete,
and reorder MIME parts, flatten HTML into text, and a huge list of other things that no mutuation catalog could plausibly describe.

That's one of the reasons that ARC doesn't try to say what's changed, just<= br /> what the authentication results were before and after.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 
 --7d96ac98f2624210b8af02af44a58890-- From nobody Thu May 30 21:41:38 2019 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 F28ED1200A4 for ; Thu, 30 May 2019 21:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 vHoDDVwA_SES for ; Thu, 30 May 2019 21:41:35 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 1308F120004 for ; Thu, 30 May 2019 21:41:35 -0700 (PDT) Received: from [192.168.0.123] (94-21-223-16.pool.digikabel.hu [94.21.223.16]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4V4halc008283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 May 2019 21:43:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559277819; bh=5nX5BP0tLHw+lxcjG1954F25/u8pSnfV+m3H5EqoW6U=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=d7Udrzjz3VwlgWigput3J2DaMySPPhnVJ2zlv3ozDmFTq3mp3QWtOyBDcuWJ7qcPW RoLMDaitougwu4qMd908wsoBp3/RkVFeJgWOZ9D/ZRW3EiSBAMvI89mgqJxKLRL1tZ iitGLRH5CM9fQsZCXpx/aoeJnW/qroFtngHpS8LI= To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> Date: Thu, 30 May 2019 21:41:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 04:41:37 -0000 On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > I rather hoped that IETF would be the poster-boy for list processing > done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 31 03:59:41 2019 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 E89EB12001B for ; Fri, 31 May 2019 03:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=bayviewphysicians.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 Lwi12tVJmDB6 for ; Fri, 31 May 2019 03:59:35 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CBA12007C for ; Fri, 31 May 2019 03:59:34 -0700 (PDT) X-ASG-Debug-ID: 1559300373-11fa3116c8270d60001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id TMO1dlusCKabSb3b (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 31 May 2019 06:59:33 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=gyM/0NivmA8uSBtakqgFcIcZ72/9ezj2HIsxyoACEYE=; b=eTmR0K4rXrwhsYJr3HmspnODHhyO7rzKBowze13Ho4piUVGia/wS9mzoHAYzPKleT NQO+5Vyv+ZXCDb64355c5ggygQnuR3L/XqtJN2ZPiip3cWVBWczaln46BRd6drL79 mhwTjCPQqI/pKpVsZKkChpcBfBaMmjgFX/PUXxK2A= Received: by webmail.bayviewphysicians.com via HTTP; Fri, 31 May 2019 06:59:24 -0400 From: "Douglas E. Foster" To: CC: "IETF DMARC WG" Date: Fri, 31 May 2019 06:59:24 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=b2e7211659294a7abe6c0f3285845de8 X-Originating-IP: [192.168.1.239] In-Reply-To: <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> X-Exim-Id: f5106924930f41c5bd83a709e4307f8b X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559300373 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10039 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 10:59:38 -0000 This is a multipart message in MIME format. --b2e7211659294a7abe6c0f3285845de8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I cannot speak to IETF consensus, since I am new to that process and I seem to be an outlier already. Agency and signatures are well understood legal concepts. 3000 years ago, people sealed their letters with a signet ring stamped in warm clay. Signing technologies have changed in that time, but the principle has not. A courier is responsible for keeping the signed and sealed part of a message unaltered. Envelope marks are acceptable. A digital signature is supposed to provide non-repudiation. If I submit a signed message to a list processor, and the list processor voids the signature, it has given me verifiable repudiation, the opposite of what either sender or receiver want. A closed group on a single server can use whatever rules they choose to implement in that community. For example, a web forum operates on the rules of the forum operator. However, an open group using the email infrastructure has to work within the infrastructure it uses. In the email infrastructure, the recipient has to deal with fraud, and any recipient accommodation to "harmless" fraud facilitates the people who are doing "harmful" fraud to that recipient. There are some obvious use-cases for MTA changes to a message, and we would do well to document and address them. The first that comes to mind is MTA comment fields. - A list processor wants to add a comment indicating something about the list that sent it. - A spam filter wants to add a tag indicating that the message is suspicious, but not sufficiently suspicious to be blocked. IETF would do well to specify a mechanism for MTAs to add information which MUAs present to the user, while identifiying that that the information came from the MTA rather than the original sender. Another use-case is related to body sections. IETF only forwards plain text, while most email solutions send messages in HTML+Text. I assume that IETF also drops attachments. DKIM cannot handle this because it hashes the entire body. A signature system that signed each section individually would allow sections to be dropped, with notification to the user, without breaking the signatures on the other MIME types. DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding, so DMARC said that the two techniques should be evaluated together. I am realizing that if SPF is invalidated, DKIM is probably invalidated as well, so we have no usable sender authentication technology. This may explain why so many products that I have examined lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and DMARC. It seems that email needs something like "DNS Flag Day", where major players announce a date after which certain behaviors that will no longer be tolerated. But as others have said, IETF is not that organization, and the organization may not exist. More discouraged than ever, Doug Foster ---------------------------------------- From: "Dave Crocker" Sent: Friday, May 31, 2019 12:41 AM To: fosterd@bayviewphysicians.com Cc: "IETF DMARC WG" Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > I rather hoped that IETF would be the poster-boy for list processing > done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --b2e7211659294a7abe6c0f3285845de8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
I cannot speak to IETF consensus, since I am new to that process and I= seem to be an  outlier already.
 
Agency and signatures are well understood legal concepts.   = 3000 years ago, people sealed their letters with a signet ring stamped in w= arm clay.   Signing technologies have changed in that time, but t= he principle has not.   A courier is responsible for keeping= the signed and sealed part of a message unaltered.   Envelo= pe marks are acceptable.
 
A digital signature is supposed to provide non-repudiation.  = ;If I submit a signed message to a list processor, and the list processor v= oids the signature, it has given me verifiable repudiation, the opposite of= what either sender or receiver want.   
 
A closed group on a single server can use whatever rules they choose t= o implement in that community.  For example, a web forum operates= on the rules of the forum operator.   However, an open group usi= ng the email infrastructure has to work within the infrastructure it u= ses.   In the email infrastructure, the recipient has to deal wit= h fraud, and any recipient accommodation to "harmless" fraud faci= litates the people who are doing "harmful" fraud to that recipien= t.
 
There are some obvious use-cases for MTA changes to a message, and we = would do well to document and address them.
 
The first that comes to mind is MTA comment fields.
- A list processor wants to add a comment indicating something about t= he list that sent it.
- A spam filter wants to add a tag indicating that the message is susp= icious, but not sufficiently suspicious to be blocked.
 
IETF would do well to specify a mechanism for MTAs to add information = which MUAs present to the user, while identifiying that that the informatio= n came from the MTA rather than the original sender.
 
Another use-case is related to body sections.   IETF only fo= rwards plain text, while most email solutions send messages in HTML+Text.&n= bsp;  I assume that IETF also drops attachments.   DKIM= cannot handle this because it hashes the entire body.   A signat= ure system that signed each section individually would allow sections = to be dropped, with notification to the user, without breaking the signatur= es on the other MIME types.
 
DKIM was supposed to provide sender authentication when SPF was invali= dated by forwarding, so DMARC said that the two techniques should be evalua= ted together.   I am realizing that if SPF is invalidated, DKIM i= s probably invalidated as well, so we have no usable sender authentication = technology.   This may explain why so many products that I have e= xamined lack support for DMARC or lack good exception mechanisms for S= PF, DKIM, and DMARC.
 
It seems that email needs something like "DNS Flag Day", whe= re major players announce a date after which certain behaviors that will no= longer be tolerated.   But as others have said, IETF is not that= organization, and the organization may not exist.
 
More discouraged than ever,
 
Doug Foster
 
 
 
 
 
 
 
 
From: "Dave Crocker" <dhc@dcrocker.net>
Sent: Friday, May 31, 2019 12:41 AM
To: fosterd@bayviewphysicians.com
Cc: "IETF DMARC WG" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- su= ggestion
 
On 5/30/2019 7:49 PM, Douglas E. Foster wrote:
> I rather hoped that IETF would be the poster-boy for list processing > done correctly.

"Correctly"?

A message to a list is 'delivered' to the list. As in, it goes to the
specified addresse... the list. A message from a list has been
re-posted by the list.

There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or
direct the behaviors of a list processor.

Different groups want and probably need different behaviors by a list
processor. Periodic efforts to create such constraints have failed.

So while it would certainly make things easier to have list processors
behave in a simple, consistent manner, there's ample evidence that ain't gonna happen.

If you can link the 'correctly' you are suggesting, to some documented,
community consensus, please cite it.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
 
 --b2e7211659294a7abe6c0f3285845de8-- From nobody Fri May 31 04:47:33 2019 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 C95F11200A1 for ; Fri, 31 May 2019 04:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 eLEq5hrwdniU for ; Fri, 31 May 2019 04:47:29 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 8D26A120044 for ; Fri, 31 May 2019 04:47:29 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id n21so722804vsp.12 for ; Fri, 31 May 2019 04:47:29 -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=d/xVMBLfdJyzdgbRv+X3McyX+wjKpW3pGZ3d/kly0WA=; b=Lgif8hRzFY+YGgbDpzj56gunTpTF+JiCgdzKwqWwxYiZnpeKUkWfc1eFcXhMpb45NS 5PuOJYCNxllPzSHBZb3ArEiMLHEtYPiL1vFdbnbHVIU7LE8c9vf42HCl2wPSnM+hiAg3 kNsMauLPF1QZckeSPy/B1guCHvQa7t9wytAGyl5ljQ0MIuAdLVlW2lTWjGdpeocmsxsY srreYwhwxq7e/uuLvHeYbKjkxVTCDpxOKVibKZXSI15k3TQWZ59ZwBjQag8J6t2PYu+0 qCTTMlRqJncPMDaXr2Mp8us85Y49h6WFyZLaC2XJdwlD992lHJM/gklgkl2yT3C2ykT4 4sDA== 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=d/xVMBLfdJyzdgbRv+X3McyX+wjKpW3pGZ3d/kly0WA=; b=LpLTXECdfYBcwOf4rqm5gJG2cQQCN8cd5z7MNJuBFVZgDVe7lWPWe7ambo+TlQeURp i+Tq98IO3u0jXVELtsWjf5xPAe0pdofWkrJYZj081wOYil+BMldDPsMJn7LP4lqpRtU6 K1WbWoDjxnzuGc+L3/RZH8ifEOUAThKIizQk6CtDMjsaPAtu7tsKWfmfkd7qMruuc2if i7JoGNONf54vBTgeq2UrRjNuOvZWIaJjoIAyqQsk8EiOeRzu05ZNp7ER83UOuHd7kyUI 7NdYYzCv+OCcVnevTkqJyYZ4ARpKzP++iLVZXEO2Kk81zMi6WgTNhcNTVVEhx1v7C10k 1hzQ== X-Gm-Message-State: APjAAAVreqdTqvH3V4WFT8Vc+6y/pZB/Hdg1a0GMXiznF2uIYew3CBkE W2zQXJTzXDdMGFGW1HRPnMxVYNFYt8zucXyMMuw= X-Google-Smtp-Source: APXvYqwVxRVEvXhms+rymhL8nVE+2I4dkpKQd0YAkLdQ8KSQl8rn7sL7rjup5XtsWcTnGq6bDiqv4Jsq8oEic85PPl0= X-Received: by 2002:a67:c508:: with SMTP id e8mr5022230vsk.18.1559303248530; Fri, 31 May 2019 04:47:28 -0700 (PDT) MIME-Version: 1.0 References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> In-Reply-To: From: Dotzero Date: Fri, 31 May 2019 07:47:15 -0400 Message-ID: To: fosterd@bayviewphysicians.com Cc: Dave CROCKER , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000039d086058a2d940f" Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 11:47:32 -0000 --00000000000039d086058a2d940f Content-Type: text/plain; charset="UTF-8" On Fri, May 31, 2019 at 6:59 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > I cannot speak to IETF consensus, since I am new to that process and I > seem to be an outlier already. > Perhaps the onus is on you to take the time to understand IETF and it's processes before demanding changes. Just a thought. > > Agency and signatures are well understood legal concepts. 3000 years > ago, people sealed their letters with a signet ring stamped in warm clay. > Signing technologies have changed in that time, but the principle has > not. A courier is responsible for keeping the signed and sealed part of a > message unaltered. Envelope marks are acceptable. > > Perhaps you should go back and read the history and purpose of DKIM. > A digital signature is supposed to provide non-repudiation. If I submit a > signed message to a list processor, and the list processor voids the > signature, it has given me verifiable repudiation, the opposite of what > either sender or receiver want. > Non-repudiation is not the purpose of DKIM signing. The purpose was (and is) to provide a mechanism for mailbox providers to evaluate whether an email message was authorized by a particular domain. > > A closed group on a single server can use whatever rules they choose to > implement in that community. For example, a web forum operates on the > rules of the forum operator. However, an open group using the email > infrastructure has to work within the infrastructure it uses. In the > email infrastructure, the recipient has to deal with fraud, and any > recipient accommodation to "harmless" fraud facilitates the people who are > doing "harmful" fraud to that recipient. > You are certainly entitled to your opinion. > > There are some obvious use-cases for MTA changes to a message, and we > would do well to document and address them. > Perhaps the you part of "we" should submit an Internet Draft undertaking the work you want done. > > The first that comes to mind is MTA comment fields. > - A list processor wants to add a comment indicating something about the > list that sent it. > - A spam filter wants to add a tag indicating that the message is > suspicious, but not sufficiently suspicious to be blocked. > > IETF would do well to specify a mechanism for MTAs to add information > which MUAs present to the user, while identifiying that that the > information came from the MTA rather than the original sender. > > Another use-case is related to body sections. IETF only forwards plain > text, while most email solutions send messages in HTML+Text. I assume > that IETF also drops attachments. DKIM cannot handle this because it > hashes the entire body. A signature system that signed each section > individually would allow sections to be dropped, with notification to the > user, without breaking the signatures on the other MIME types. > > DKIM was supposed to provide sender authentication when SPF was > invalidated by forwarding, so DMARC said that the two techniques should be > evaluated together. I am realizing that if SPF is invalidated, DKIM is > probably invalidated as well, so we have no usable sender authentication > technology. This may explain why so many products that I have examined > lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and > DMARC. > Can you please show us the documentation that supports your assertion that " DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding"? When I read the DKIM RFC I find nothing to support your assertion. DKIM was the result of the merging of Internet Identified Mail (IIM) and Domain Keys (DK) proposals. Quite a few of us were around at the time it happened. These things happened in parallel to SPF and not as a "fix" to SPF. Thank you for your creative attempt to rewrite history. > > It seems that email needs something like "DNS Flag Day", where major > players announce a date after which certain behaviors that will no longer > be tolerated. But as others have said, IETF is not that organization, and > the organization may not exist. > > Thank you for your proposal. To channel a long time participant, I invoke King Canute. If you believe major players should take a particular action in unison then perhaps you should be reaching out to those major players. (Side note to major players, no need to thank me for pointing this out) > More discouraged than ever, > Hope springs eternal. Michael Hammer > --00000000000039d086058a2d940f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 31, 2019= at 6:59 AM Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
<= div>I cannot speak to IETF consensus, since I am new to that process and I = seem to be an=C2=A0 outlier already.

Perhaps the onus is on you to take the time to understand=C2=A0 IETF= and it's processes before demanding changes. Just a thought.
=C2=A0
Agency and signatures are well understood legal concepts.=C2=A0 =C2=A0= 3000 years ago, people sealed their letters with a signet ring stamped in w= arm clay.=C2=A0 =C2=A0Signing technologies have changed in that time, but t= he principle has not.=C2=A0 =C2=A0A courier is=C2=A0responsible for keeping= the signed and sealed part of a message=C2=A0unaltered.=C2=A0 =C2=A0Envelo= pe marks are acceptable.
=C2=A0

Perhaps you should= go back and read the history and purpose of DKIM.
=C2=A0
A digital signature is supposed to provide non-repudiation.=C2=A0=C2= =A0If I submit a signed message to a list processor, and the list processor= voids the signature, it has given me verifiable repudiation, the opposite = of what either sender or receiver want.=C2=A0 =C2=A0

Non-repudiation is not the purpose of DKIM signing. = The purpose was (and is) to provide a mechanism for mailbox providers to ev= aluate whether an email message was authorized by a particular domain.
=C2=A0
=C2=A0
A closed group on a single server can use whatever rules they choose t= o implement in that community.=C2=A0 For example, a=C2=A0web forum operates= on the rules of the forum operator.=C2=A0 =C2=A0However, an open group usi= ng the email infrastructure has to work within the=C2=A0infrastructure it u= ses.=C2=A0 =C2=A0In the email infrastructure, the recipient has to deal wit= h fraud, and any recipient accommodation to "harmless" fraud faci= litates the people who are doing "harmful" fraud to that recipien= t.

You are certainly entitled = to your opinion.=C2=A0
=C2=A0
There are some obvious use-cases for MTA changes to a message, and we = would do well to document and address them.
<= br>
Perhaps the you part of "we" should submit an Inter= net Draft undertaking the work you want done.=C2=A0
=
=C2=A0
The first that comes to mind is MTA comment fields.
- A list processor wants to add a comment indicating something about t= he list that sent it.
- A spam filter wants to add a tag indicating that the message is susp= icious, but not sufficiently suspicious to be blocked.
=C2=A0
IETF would do well to specify a mechanism for MTAs to add informatio= n which MUAs present to the user, while identifiying that that the informat= ion came from the MTA rather than the original sender.
=C2=A0
Another use-case is related to body sections.=C2=A0 =C2=A0IETF only fo= rwards plain text, while most email solutions send messages in HTML+Text.= =C2=A0 =C2=A0I assume that IETF=C2=A0also drops attachments.=C2=A0 =C2=A0DK= IM cannot handle this because it hashes the entire body.=C2=A0 =C2=A0A sign= ature system that signed=C2=A0each section individually would allow section= s to be dropped, with notification to the user, without breaking the signat= ures on the other MIME types.
=C2=A0
DKIM was supposed to provide sender authentication when SPF was invali= dated by forwarding, so DMARC said that the two techniques should be evalua= ted together.=C2=A0 =C2=A0I am realizing that if SPF is invalidated, DKIM i= s probably invalidated as well, so we have no usable sender authentication = technology.=C2=A0 =C2=A0This may explain why so many products that I have e= xamined lack support for DMARC or=C2=A0lack good exception mechanisms for S= PF, DKIM, and DMARC.

Can you p= lease show us the documentation that supports your assertion that "=C2= =A0DKIM was supposed to provide sender a= uthentication when SPF was invalidated by forwarding"? When I read the= DKIM RFC I find nothing to support your assertion. DKIM was the result of = the merging of Internet Identified Mail (IIM) and Domain Keys (DK) proposal= s. Quite a few of us were around at the time it happened. These things happ= ened in parallel to SPF and not as a "fix" to SPF. Thank you for = your creative attempt to rewrite history.
=C2=A0
It seems that email needs something like "DNS Flag Day", whe= re major players announce a date after which certain behaviors that will no= longer be tolerated.=C2=A0 =C2=A0But as others have said, IETF is not that= organization, and the organization may not exist.
=C2=A0
Thank you for your proposal. To c= hannel a long time participant, I invoke King Canute. If you believe major = players should take a particular action in unison then perhaps you should b= e reaching out to those major players. (Side note to major players, no need= to thank me for pointing this out)
=C2=A0
=
More discouraged than ever,

Hope springs eternal.

Michael Hammer
<= /div> --00000000000039d086058a2d940f-- From nobody Fri May 31 05:08:39 2019 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 618BB12004A for ; Fri, 31 May 2019 05:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 rEPyld-2Qm6V for ; Fri, 31 May 2019 05:08:37 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDAF120025 for ; Fri, 31 May 2019 05:08:37 -0700 (PDT) X-ASG-Debug-ID: 1559304513-11fa3116c8272b30001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id kyhDBntOkt1XqCxC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 31 May 2019 08:08:33 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=e4qCfsoQKIuEZQS6e5gKvzx0XAcoUiZt5uu6RWyNILk=; b=kryMT8jVB4+U7mSsYvy6yu8WNeEI/qk9ko8PJ9DFDdlbK5X+X54YjMu3DcynL9AH0 oDqE+/JnpBAByjBLIayOT0zOBTA8tIe/FpbhM0KWyAHTpSmlnWJvwFvBL3rRJVCy0 xZwGlJ3z5i3boTTX+zMlf33kVKlby7R45tRBFKBlI= Received: from MSA189 (MSA-189.BayviewPhysicians.com [192.168.2.84]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Fri, 31 May 2019 08:08:24 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.84 To: Cc: "'IETF DMARC WG'" References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> In-Reply-To: <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> Date: Fri, 31 May 2019 08:08:24 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion Message-ID: <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF2mfqORIHUWCy6HmaK1O5k8iTDrgGyYov2AbxNhOEBudfH3QGFoGkCAkJaXHum+pi+0A== X-Exim-Id: 000001d517a9$8c4f5960$a4ee0c20$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559304513 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 1971 X-Barracuda-BRTS-Status: 0 Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 12:08:38 -0000 Tactically, what I meant was "IETF should be able to ensure that IETF messages are only released with verifiable IETF signatures". This would mean that either the first signature is not applied, the message is not altered after the first signature is applied, or the first signature is removed after the message is altered. The current configuration leaves open the suspicion that IETF has rogue software operating in its environment. I am aware that the DKIM specification says to treat an unverifiable signature as a non-signature. This is not a sufficient reason to release your own organization's signatures onto the internet when you can or should know that they will fail validation. Doug Foster -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Friday, May 31, 2019 12:41 AM To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > I rather hoped that IETF would be the poster-boy for list processing > done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 31 06:02:32 2019 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 638FD12009C for ; Fri, 31 May 2019 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WxPbTLOY; dkim=pass (1536-bit key) header.d=taugh.com header.b=31cWssuu 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 yA0y1Acr72DG for ; Fri, 31 May 2019 06:02:28 -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 4E18E1200CD for ; Fri, 31 May 2019 06:02:28 -0700 (PDT) Received: (qmail 54070 invoked from network); 31 May 2019 13:02:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d334.5cf125e2.k1905; i=johnl-iecc.com@submit.iecc.com; bh=4OgxtuEw4rjXAlnfny0Ej6RjtYWXHb9W3hdB/VEy8N0=; b=WxPbTLOYh5PhznjtiB/Lopd2YmLrdfrkxp5jlVMl8+Y9zyyvX5YpsYmXXPNI/AJEr/wdUbZjEa6VqDyJ1q2xcCx28lgxj8gdTVsbMP3KIykakofbcXBqL0mqY4pPRey58riSxbMSe8CRNANXLus6DtOKLZu68Hi5zYRQnvukI/iOkLgQ/geYVft47kErO85nt+F6PPQfm0NHBMpAU31RBc3xnHX142nVvzCmXyvKOj+NaWINfGQLGKjbFjJvDniI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d334.5cf125e2.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=4OgxtuEw4rjXAlnfny0Ej6RjtYWXHb9W3hdB/VEy8N0=; b=31cWssuu+U3a5P8rsEIotm56jhMmHg/q9mbsIun+7BHAayb7yc+xX5QvGBXnPmzzsFfKAiD9f+RpOiF+nQgL1MbemaF5j6fzKoBn+X0jfJcIyUCZr9+juktZiLNDh8wBHhZRpBLCT9bc8qagZFe8l9Pqf0SA9xYrjwOYxFRs+oHNPptQNuuMuz6EBVCCkabsDn2Pb8KwFHwDMPfU3+wvNhidbb8RqJgEFl1/afHL/6AelsCzol0GPVmS5I4TAD98 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 May 2019 13:02:26 -0000 Date: 31 May 2019 09:02:26 -0400 Message-ID: From: "John R Levine" To: "Douglas E. Foster" Cc: "IETF DMARC WG" In-Reply-To: References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 13:02:30 -0000 > Thank you for the education The IETF list processor seems to be an > illustration of your point. > It invalidates the orginal sender's signature Then it adds an ietf.org > signature Then the message is relayed internally within a single IETF > server, where the IETF signature is invalidated. The the message is signed > a second time with an valid IETF signature > I rather hoped that IETF would be the poster-boy for list processing done > correctly. Why is the message manipulation that you describe necessary or > acceptable? That's completely backwards. Mailing lists have been around for 30 years and were doing what they do long before anyone thought of mail authentication like SPF, DKIM, or DMARC. SPF and DKIM on their own work fine with lists -- a list puts its own envelope address and its own DKIM signature on outgoing mail which a receipient can use. DMARC egregiously fails to handle them and was never intended for mail that goes through lists, but that's a story that's been told plenty of times already. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 31 06:40:08 2019 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 A3C0E12009C for ; Fri, 31 May 2019 06:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 jH-q8zDGXdxo for ; Fri, 31 May 2019 06:40:05 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 53828120075 for ; Fri, 31 May 2019 06:40:05 -0700 (PDT) Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4VDg7r4016373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2019 06:42:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559310130; bh=BSXc/BKrEPmUpq+yu3Vd1ZAoQxW+yZZythWlzsWd2rY=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=Ubr5EX3hRtbL+egImXmEOI2hm8HXs/257OHWNTZYgR+oYF1an4OszQ36nCmqQ3rs/ BohY6sFvd4DRtF4KG7Dq8DKeeG+B7BTScOBv5zPyUUX2xL7KbG86DvAS6y33TYph+I O1ewBBoRb6RmBGSXyBONpiXNJaoueu3oX3+D3GcQ= To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: Date: Fri, 31 May 2019 15:39:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 13:40:07 -0000 On 5/31/2019 3:59 AM, Douglas E. Foster wrote: > Agency and signatures are well understood legal concepts. 3000 years The signature at issue here is done with DKIM. Are you sure you are clear about the what the agency is it vets and what the scope of use for that vetting is? I suspect you are assuming a different type and scope of authentication than DKIM is intended to perform. It's not that your goal is unreasonable -- and indeed, s/mime and openpgp seeks to perform it -- it's that DKIM wasn't designed to do that. DKIM was designed for use during tranfer to the point of delivery. For this discussion, that means to the list processor (mailbox) > ago, people sealed their letters with a signet ring stamped in warm > clay. Signing technologies have changed in that time, but the > principle has not. A courier isresponsible for keeping the signed and Please note my earlier point about delivery and re-posting. That implies a role for list processing that is considerably more than a courier's. > sealed part of a messageunaltered. Envelope marks are acceptable. > A digital signature is supposed to provide non-repudiation.If I submit DKIM is a transfer-level signature. That is, really, MTA-MTA (or, really, MTA-MDA). A list processor is an MUA-level actor. (cf, RFC 5598.) > There are some obvious use-cases for MTA changes to a message, and we > would do well to document and address them. Perhaps, but that's not at issue here. > The first that comes to mind is MTA comment fields. Huh? > - A spam filter wants to add a tag indicating that the message is > suspicious, but not sufficiently suspicious to be blocked. > IETF would do well to specify a mechanism for MTAs to add information > which MUAs present to the user, while identifiying that that the > information came from the MTA rather than the original sender. You mean like adding a header field, outside of the ones signed by DKIM? That's already permitted. It's one of the reasons that the signer gets to decide what header fields to cover. However, it looks as if you think presenting such information to users will be useful. It won't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 31 06:44:19 2019 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 C13961200F3 for ; Fri, 31 May 2019 06:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 OeoQjYgvky10 for ; Fri, 31 May 2019 06:44:13 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 7D3D9120276 for ; Fri, 31 May 2019 06:44:13 -0700 (PDT) Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4VDkDCP016847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2019 06:46:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559310375; bh=QHSXPwPCRWbYS/5OZ1QTaGZ9D3PWfACLXOkh0EnnoyY=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=SNKWeE5y1WcrhACRvh39+wDOCGKkQtciDSVECqmYhwL1W4tOwpodqjjXnAcoXastF 0EQxaqUKZy5Qco52iAKngJwPRtB7DNYd1cJSOZ1/h1ogpUCxXUYjB0BtzNXCjlTm5w eOBlymHwAqidZxJQThfZBaBzzz7hVpImBKARM4og= To: Dotzero , fosterd@bayviewphysicians.com Cc: IETF DMARC WG References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: <1af46ba0-e9c6-5185-e910-4a8937cbd1aa@dcrocker.net> Date: Fri, 31 May 2019 15:44:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 13:44:18 -0000 On 5/31/2019 4:47 AM, Dotzero wrote: > Non-repudiation is not the purpose of DKIM signing. The purpose was (and > is) to provide a mechanism for mailbox providers to evaluate whether an > email message was authorized by a particular domain. Nit-picking time. I'd apologize for indulging, but I'm not really sorry: Even "authorized" is too strong a label for what DKIM officially does. "Touched" is more in line with what the spec defines, although "took some responsibility for" is a more ponderous way of saying that. Specific sites have DKIM usage policies based on much stronger semantics, but that's outside the DKIM specification. Hence, no one down the handling sequence can rely on just the specification and know of that stricter semantic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 31 06:50:31 2019 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 BA1E612002E for ; Fri, 31 May 2019 06:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.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 Vpt3VH5CKsl8 for ; Fri, 31 May 2019 06:50:29 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 A4251120025 for ; Fri, 31 May 2019 06:50:29 -0700 (PDT) Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4VDqWCA017622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2019 06:52:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559310755; bh=fTMYAaru9mIhsKIr6iNzh5iwjWl5PboW6B/k6xuIKtg=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=I9Um0GQrWOoeMwotB7LQWDOfaHUMTAJQGo4r9QwoRM7EMLMhsEd+efE3SCqZ4uOeb XKWvU/k07bcebkAWx/eViBomPfKheE6NN3FtvqGOcrIPSpApJn+Mv+dVtvv5Qrb+eE 0nXwBVscVa5zuy/e7jutWRTSTRw+UcE/pgMAi4Lo= To: Doug Foster Cc: "'IETF DMARC WG'" References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: Date: Fri, 31 May 2019 15:50:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 13:50:31 -0000 On 5/31/2019 5:08 AM, Doug Foster wrote: > Tactically, what I meant was "IETF should be able to ensure that IETF > messages are only released with verifiable IETF signatures". I'm not exactly sure what the above sentence means, in terms of technical details. So while the language all sounds fine, its meaning is far more ambiguous that I suspect you intended. In any event, are you aware of the recent work on ARC? For some case(s) of what you might mean, above, that's it's goal. > This would mean that either the first signature is not applied, the message > is not altered after the first signature is applied, or the first signature > is removed after the message is altered. The current configuration leaves > open the suspicion that IETF has rogue software operating in its A message from the IETF list processor has an ietf.org DKIM signature. How does that support your concern? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 31 06:50:48 2019 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 EBFFA12004F for ; Fri, 31 May 2019 06:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=QLuLXbmE; dkim=pass (1536-bit key) header.d=taugh.com header.b=CCoaMCF3 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 PxCSeGpjx3LN for ; Fri, 31 May 2019 06:50:44 -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 0FEEA1200DB for ; Fri, 31 May 2019 06:50:43 -0700 (PDT) Received: (qmail 68266 invoked from network); 31 May 2019 13:50:41 -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; s=10aa6.5cf13131.k1905; i=johnl-iecc.com@submit.iecc.com; bh=wNRzFxaLKkJcNaV6euhSYAVmZ8F8alaYKlOq+CI2hNU=; b=QLuLXbmE1ZD8XXNwtJhpS2o+T/RyRoDQD0RuBB3Nn2v05Zxmb21YWAZtt2t3AR9SLdb+l/q+Rm94RT/FJcWgeKjibiwHEHKeN4UjieUnhAcRbxCs5JjteL6R1m0sVSeE4UAb3GEm2dvJPQKeTsuRoOn9NjNAHXy2VxL+ZSQLk93/F0iEiAS7WZ9n6KaU6jRYTSRGAB0WwOKdsx7kCzqNCTjpHAdwRc3nmeE4s36+Jssrml+vEmkmLB+pi0XJwUtH 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; s=10aa6.5cf13131.k1905; olt=johnl-iecc.com@submit.iecc.com; bh=wNRzFxaLKkJcNaV6euhSYAVmZ8F8alaYKlOq+CI2hNU=; b=CCoaMCF39x1AvQ/959vKAJNRo6H95uPMjlYzEKjYrpfpzoLOP9N2iqAl/M+72WKMVZNuUn/wmUAbl7RlCFuG7gRiQTqTizK1522LqPX1iz+yOZvv7YCJGt/r2NBhMkzOu3SZ0RFwur3+pCrDPNCvt/u0sT5HDHWqKwqgGKUYujWm3jsZwRn5G6CWTrFZjyTEGPKCHCqahg86nD0Okpvlvg65NKtaUTfIfQyN/5CLr3gH04IY/pg4OOc250KtwRjs Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 31 May 2019 13:50:41 -0000 Received: by ary.qy (Postfix, from userid 501) id DE8FB2014DA9DA; Fri, 31 May 2019 09:50:40 -0400 (EDT) Date: 31 May 2019 09:50:40 -0400 Message-Id: <20190531135040.DE8FB2014DA9DA@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 13:50:46 -0000 In article <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> you write: > I am aware that the DKIM specification says to treat an >unverifiable signature as a non-signature. This is not a sufficient reason >to release your own organization's signatures onto the internet when you can >or should know that they will fail validation. Not to belabor the obvious, but the spec says what it says even if you personally wish it said something else. The way to make systems interoperate is to implement the actual spec. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 31 07:03:38 2019 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 3C4CC120025 for ; Fri, 31 May 2019 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jTNu8cmV; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=cgd1yvKS 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 HdKLcRGu_Duw for ; Fri, 31 May 2019 07:03:32 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id CFCE112006F for ; Fri, 31 May 2019 07:03:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7515; t=1559311408; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=avLvaFZz/zxEvdlk5EfB9Qq/ZxQ=; b=jTNu8cmVWA603y3BhM/Rsv3oJ2B81WvMaR0yazmrm3W0mTW7tiZqvoGtzSY2Is O9+dW+CoFqpBHTkIigOZHVB3AjuscLERi9YQbkrScbDOa47uOdKX+9iIq5gRzasv WJIMHYPKejfzdeYPbEfYamgNUHmikDDdYeuc1CuYlAg+w= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 10:03:28 -0400 Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_SELECTOR_DNS_PERM_FAILURE) header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 103848868.58212.4256; Fri, 31 May 2019 10:03:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7515; t=1559311221; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OBRfXKu 44ck1i3ZMvsfRWVmiN6YZLnBw9t/0tYpEQC4=; b=cgd1yvKSPjCaUqPzDC49Q1k jqos53365/W+F0zdMmLmdx0ksx93YB9QXwVk1zjOhzhjKepZeYzt8J1puTu8jBcQ oohZ/SLbtiV/Ggyuh4HyJx60ScMUEuj7/q6yiT83Ar4TRn8CImmYu71AwbPnwXqq u7NQpnZvSwzn59DDX5RA= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 10:00:21 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1676077223.9.169128; Fri, 31 May 2019 10:00:21 -0400 Message-ID: <5CF13428.5000204@isdg.net> Date: Fri, 31 May 2019 10:03:20 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Doug Foster CC: 'IETF DMARC WG' References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> In-Reply-To: <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 14:03:36 -0000 On 5/31/2019 8:08 AM, Doug Foster wrote:> >Tactically, what I meant was "IETF should be able to ensure that IETF > messages are only released with verifiable IETF signatures". > > This would mean that either the first signature is not applied, the message > is not altered after the first signature is applied, or the first signature > is removed after the message is altered. The current configuration leaves > open the suspicion that IETF has rogue software operating in its > environment. I am aware that the DKIM specification says to treat an > unverifiable signature as a non-signature. This is not a sufficient reason > to release your own organization's signatures onto the internet when you can > or should know that they will fail validation. If I may. In principle, I agree the IETF should be the "poster-boy" of the technologies and methods it helps engineer. Unfortunately, it is an ideal concept but not always practical nor possible to implement the proposals. In fact, with DKIM, there is a standard base but with the DKIM POLICY model, there is no standard. DMARC is not a proposed standard. It is an Informational Status document, meaning, it really has no "power." You can try to throw "the book" at someone's face for non-compliance and will throw it right back saying "its not a standard. I don't have to follow it." So that is one thing that needs to be corrected. There is only one simple reason why DMARC was introduced as an Informational Status guide. Under this status, it would not have to go through IETF engineering and review process. There was a period a few years back where this Info Status method was used to "fast track" documents. If DMARC was introduced as a proposed standard, it would of, undoubtedly, had a rough time getting endorsed, especially since the IETF was just told to abandoned ADSP for problems DMARC never resolved. DMARC came after many years with earlier versions of DKIM Policy proposed methods with many heated discussions between Policy Model advocates and Non-Policy Trust Model advocates. History of DKIM Policy (as I lived it): Before DKIM, there was Domainkeys (DKEYS) and DKEYS introduced the powerful concept of Signature Policy with the "o=" tag: o = Outbound Signing policy ("-" means that this domain signs all email, "~" is the default and means that this domain may sign some email with DomainKeys). So you had two Policy options: o=- Exclusive Signing. Mail is always signed. o=~ Neutral, Maybe you signed, maybe you didn't. This was a powerful new concept and many people, the news rags, got really excited about it because for the first time, we had a deterministic method to reject mail based on a published rules by the domain on what to expect. SPF offered this too via the hard -ALL fail policy which was catching on with more domains using -ALL. I expected the same would happen with DKIM Policy. In fact, DKEYS was viewed as a replacement for SPF because SPF had the "Node IP Transition" problem in multi-hops. With Domain Signature Policies, ideally, we could avoid the SPF IP problem. If the domain said "My Mail MUST be signed by Me" and the mail was in fact, not signed or was invalid, then the receiver had a new gained power and permission by the domain to reject/filter mail with no questions asked. In other words, it was no longer censorship. We were given the legal power to reject based on what the DOMAIN publicly published. SPF and DKIM Policy were the only protocols to offer this to mail developers. But what about 3rd party signatures? What if other domains signed on your behalf? What about List serves? Can we publish some rules about 3rd party signers? Following DKEYS lead, DKIM was introduced with extended "o=" policies called SSP (Sender Signature Policies or Practices). After much WG discussions, they were summarized: DKIM-SSP/WG Proposed Policies o=- STRONG (1s party signature required, 3rd party allowed?) o=~ NEUTRAL (signature optional, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=? WEAK (signature optional, no 3rd party) o=. NEVER (no mail expected) o=^ USER One of the questions with DKEYS "o=-" was if it supported a 3rd party signature. Did the domain expect it to be routed via middle ware with additional signatures? The tag "o=!: was introduced to clear up that question, making it an exclusive, restrictive signing practice. But we also worked on how we can authorize a 3rd party and that was where little agreement could be reached. We could not agree on what the ser Policy (o=^) would be. How will that lower granularity of authorization work? How would we deterministically trust a list server resigning a message that will break the 1st party signature? This complexity is the reason early DKIM drafts was split into DKIM-BASE and DKIM-POLICY using SSP, but SSP was replaced with ADSP which reduced the policies to just: DKIM=DISCARDABLE DKIM=ALL effectively attempting to remove the 3rd party signature issues. Unfortunately, while it tried to get systems to ignore the 3rd party question, the reality was when a list submission occurred, the receivers would reject the invalid signatures and now the process of unsubscribing list members when the distribution failed at the receivers. We didn't see occured with ADSP but we knew it can happen. Not many receivers, if any, were yet supporting or honoring ADSP and certainly none of the List Servers supported policy. So it did what it always did. This was the main reason ADSP, a Proposed Standard, was abandoned. But ironically, DMARC replaced ADSP as an informational status document for avoid the IETF engineering process. It did not address the ADSP problem. I think people wanted the reporting part of it to learn the reasons and locations of failure/rejects. But DMARC, as we all well know, has the same problem and once receivers began to honor it and domains began to use DMARC p=reject, we began to see the problems we always expected could happen and it did - big time when Yahoo.com published the DMARC p=reject policy. Nonetheless, DMARC took off. The reason why it took off was because since day one, since DomainKeys invented it, we could not remove that powerful concept of Exclusive DKIM Policy Signature models where we have a permissible mechanism to reject/discard mail. That is a powerful concept and it only has a problem with the 3rd party signatures that we have refused to tackle in earnest. Stepping back to the 3rd party authorization design need. There is/was a 3rd party signature authorization proposal called ATPS (Authorized Third Party Signature). This is a simple mechanism that allowed you to published which 3rd party domains are allowed to sign on your behalf. My package supports ADSP+ATPS and now DMARC+ATPS. ATPS works. You can create records using these wizards: http://www.winserver.com/public/wcadsp http://www.winserver.com/public/wcdmarc So there you go. Short history as I lived it. I've been involved with this whole thing since day one. I am firm believer in the DKIM POLICY model. The concept is too strong and "it's scary" as one prominent person here once put it, and I think one day, we will finally figure it out. I just hope we don't waste too much time with ARC. Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com -- HLS From nobody Fri May 31 08:02:26 2019 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 C99AD1201E3 for ; Fri, 31 May 2019 08:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=la09Q0E8; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QrP6Jg6Z 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 CjBoSuwt7X9U for ; Fri, 31 May 2019 08:02:17 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDEA12026A for ; Fri, 31 May 2019 08:02:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4133; t=1559314933; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7etUV/W81ChCS7noh9YnVtUlSno=; b=la09Q0E8he1ko6IdCNUlNoiF+C8WJBkMZdKnV4IyZy4AinkoED5lNvHywPPCiY AeVG64Pst79www0V75n9pglExWWj/ufMFOBOssY/d4Pic4LLb21n5cVA5D8dvhyJ SJBptwGAcT0JtL+cvUFMa0GkIyk0pfoq+26pq8LnPit/Q= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 11:02:13 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 107383898.58212.1500; Fri, 31 May 2019 11:02:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4133; t=1559314756; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0rtiydh dXnp60RoP/KodDg9mcv+K80RIRTonw/f0wyk=; b=QrP6Jg6ZnjEWEzlshjgb9n2 0k2Z8xsgSdDtDxXNqI6vKSDWbznY1MedMYzjv3P53IIJ/DWcBnRNbYlQBNGhLLMs loO2f0zWfpVUWrJNRsuS1pIZgwOWqlMXCzcyBx3LoTz0YGm5GkOD5vGRZZUmACAP HJZojY/z9f6RSf5PD79A= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 10:59:16 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1679611582.9.252400; Fri, 31 May 2019 10:59:15 -0400 Message-ID: <5CF141F6.7030000@isdg.net> Date: Fri, 31 May 2019 11:02:14 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 15:02:24 -0000 On 5/31/2019 6:59 AM, Douglas E. Foster wrote: > DKIM was supposed to provide sender authentication when SPF was > invalidated by forwarding, so DMARC said that the two techniques > should be evaluated together. Unfortunately, DMARC did not have a policy that offered that output. SPF >> FAIL DMARC >> PASS? Overall, DMARC failed to cover all the possible scenarios of mixed signatures. To cover all aspects, the DKIM POLICY model has to offer 3rd party signature conditions. In the DSAP proposal, it highlighted this as the broader possible options: https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2 +-----------------------------------------------------------------+ | op= | 3p= | Domain Policy Semantics | |=================================================================| | empty | empty | No mail expected | |-----------------------------------------------------------------| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-----------------------------------------------------------------| | always | never | OP signature expected | | always | always | Both parties expected | | always | optional | OP expected, 3P may sign | |-----------------------------------------------------------------| | optional | never | Only OP signing expected | | optional | always | OP expected, 3P expected | | optional | optional | Both parties may sign. | +-----------------------------------------------------------------+ That covered all possible combinations. We actually wrote an IETF functional spec regarding Sender Signing Policies: rfc5016 Requirements for a DKIM Signing Practices Protocol https://tools.ietf.org/html/rfc5016 Abstract DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD). But then something happen as this document was being completed -- list administrators got scared that DKIM Policy was gaining tractions and stepping into their market toes. After all, we had "30 years" of legacy list operations, we did not want DKIM Policy interfering with the broad range of established list distribution operations. So this RFC5016 "Blocker" was written at the last minute to preempt it from happening: Section 5.3, Item 10 https://tools.ietf.org/html/rfc5016#section-5.3 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. That was basically, a "Don't step on my turf!!" requirement. It also meant "Local Policy Always Prevail" regardless of what a Domain published which is always the case anyway. Does not need to be stated. But overall, this is what help demote SSP, ADSP, ATPS and DKIM policy in general. ADSP was abandoned. But no one can kill a good idea, the proof of concept was too powerful, hence it returned as DMARC but as an informational status document to avoid the IETF mch higher review process. I have no idea how a high overhead, complex ARC will resolve this problem unless it comes with a 3rd party signature concept with an extended DMARC "arc=y" tag: arc=y If the 1st party signature failed, then authorize the XYZ domains using ARC seals to promote a failure to a pass. How would you specify the 'authorization" of XYZ domains and do so at scale? -- HLS From nobody Fri May 31 08:16:28 2019 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 E2BBF120052 for ; Fri, 31 May 2019 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=otoh.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 TOrFpw_Dq138 for ; Fri, 31 May 2019 08:16:24 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4610312002E for ; Fri, 31 May 2019 08:16:24 -0700 (PDT) Received: from [100.80.205.135] (177.sub-174-214-3.myvzw.com [174.214.3.177]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id 7E4DD109D8; Fri, 31 May 2019 15:16:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1559315778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8EVo/jaMk4lzHgBXYnVsiMQxMcoozda6KlzLJhQ29T8=; b=TScGGKyiPjkXLylIx7HtELdTe/yctSudCuzJhP6FBPuN/jDKjvZqmexmYucBRDdUvB3jVL lP173uf56oDJN2doHa2vLr09ws+eTvFCFrGPq4WuUOSi75X5StBKWbso4an7GFrAO2AqBD OnpKnzhylUyPNrM31i+JbGXg1PIyeG0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (16E227) In-Reply-To: <5CF141F6.7030000@isdg.net> Date: Fri, 31 May 2019 08:16:16 -0700 Cc: dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <189794E3-5C3A-4A5F-B4C0-A64842FD4625@otoh.org> References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <5CF141F6.7030000@isdg.net> To: hsantos@isdg.net Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 15:16:27 -0000 RFC 7960 has an extensive discussion of mail flows that modify mail (as well= as other cases that are problematic for DMARC). Mailing lists are not the o= nly case, and, as John has pointed out, reformatting and part stripping are t= hings that happen in mail flows.=20 Elizabeth=20 > On May 31, 2019, at 8:02 AM, Hector Santos wrote: >=20 >> On 5/31/2019 6:59 AM, Douglas E. Foster wrote: >>=20 >> DKIM was supposed to provide sender authentication when SPF was >> invalidated by forwarding, so DMARC said that the two techniques >> should be evaluated together. >=20 > Unfortunately, DMARC did not have a policy that offered that output. >=20 > SPF >> FAIL > DMARC >> PASS? >=20 > Overall, DMARC failed to cover all the possible scenarios of mixed signatu= res. >=20 > To cover all aspects, the DKIM POLICY model has to offer 3rd party signatu= re conditions. In the DSAP proposal, it highlighted this as the broader po= ssible options: >=20 > https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2 >=20 > +-----------------------------------------------------------------+ > | op=3D | 3p=3D | Domain Policy Semantics |= > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| > | empty | empty | No mail expected | > |-----------------------------------------------------------------| > | never | never | No signing expected | > | never | always | Only 3P signing expected | > | never | optional | Only 3P signing optional | > |-----------------------------------------------------------------| > | always | never | OP signature expected | > | always | always | Both parties expected | > | always | optional | OP expected, 3P may sign | > |-----------------------------------------------------------------| > | optional | never | Only OP signing expected | > | optional | always | OP expected, 3P expected | > | optional | optional | Both parties may sign. | > +-----------------------------------------------------------------+ >=20 > That covered all possible combinations. >=20 > We actually wrote an IETF functional spec regarding Sender Signing Policie= s: >=20 > rfc5016 Requirements for a DKIM Signing Practices Protocol > https://tools.ietf.org/html/rfc5016 >=20 > Abstract >=20 > DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism > for domains to assert responsibility for the messages they handle. A > related mechanism will allow an administrator to publish various > statements about their DKIM signing practices. This document defines > requirements for this mechanism, distinguishing between those that > must be satisfied (MUST), and those that are highly desirable > (SHOULD). >=20 >=20 > But then something happen as this document was being completed -- list adm= inistrators got scared that DKIM Policy was gaining tractions and stepping i= nto their market toes. After all, we had "30 years" of legacy list operatio= ns, we did not want DKIM Policy interfering with the broad range of establis= hed list distribution operations. So this RFC5016 "Blocker" was written at t= he last minute to preempt it from happening: >=20 > Section 5.3, Item 10 > https://tools.ietf.org/html/rfc5016#section-5.3 >=20 > 10. SSP MUST NOT provide a mechanism that impugns the existence of > non-first party signatures in a message. A corollary of this > requirement is that the protocol MUST NOT link practices of first > party signers with the practices of third party signers. >=20 > INFORMATIVE NOTE: the main thrust of this requirement is that > practices should only be published for that which the publisher > has control, and should not meddle in what is ultimately the > local policy of the receiver. >=20 >=20 > That was basically, a "Don't step on my turf!!" requirement. It also meant= "Local Policy Always Prevail" regardless of what a Domain published which i= s always the case anyway. Does not need to be stated. But overall, this is w= hat help demote SSP, ADSP, ATPS and DKIM policy in general. ADSP was abando= ned. >=20 > But no one can kill a good idea, the proof of concept was too powerful, h= ence it returned as DMARC but as an informational status document to avoid t= he IETF mch higher review process. >=20 > I have no idea how a high overhead, complex ARC will resolve this problem u= nless > it comes with a 3rd party signature concept with an extended DMARC "arc=3D= y" tag: >=20 > arc=3Dy If the 1st party signature failed, then authorize the XYZ > domains using ARC seals to promote a failure to a pass. >=20 > How would you specify the 'authorization" of XYZ domains and do so at scal= e? >=20 > --=20 > HLS >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri May 31 08:46:27 2019 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 65D3912013A for ; Fri, 31 May 2019 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=QP4zYTq7; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Ce9EoQui 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 7q0lhbqgeDzc for ; Fri, 31 May 2019 08:46:22 -0700 (PDT) Received: from mail.winserver.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 35161120147 for ; Fri, 31 May 2019 08:46:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6318; t=1559317574; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=m1CFn5Fll25APvelJ9CY+lm28hc=; b=QP4zYTq76j6MEPJ6/yFj0IdVYj/E8qFJpaYi05/pjo6iq/S6R+kqG+8sVDSLga 5o/pQ/pmr5DvSjg8jcjFJ4F/jQ7EQcTPPopvDf09GspPVeXRxPfmydwJFKCZHsD+ Atj5gnHFDUnV4aLqcBOFAw0HSxnrm1s7fUgCXcIZmJn34= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 11:46:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 110024012.58212.4484; Fri, 31 May 2019 11:46:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6318; t=1559317396; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GRqIt7v QsTQIrFZ0iA8g2GwqkN+iWcl6TVYx2hGgohU=; b=Ce9EoQuiuxbUDy2C/2C154w HcfBS5PlXIW07D1lpF6/Gm+wrUprA6E1X3NC5l9UVycrVsShdqIktw/yO0GJ10W/ FOgkwHIknVVlFzjO5HasxKENhWo/6ofheF8y2Yq6ZzBbjkgM9KJ2n30LmkIwCBde AtyEEy95Tc0sfZAXTArM= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Fri, 31 May 2019 11:43:16 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1682251801.9.291380; Fri, 31 May 2019 11:43:15 -0400 Message-ID: <5CF14C46.4040100@isdg.net> Date: Fri, 31 May 2019 11:46:14 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <5CF141F6.7030000@isdg.net> <189794E3-5C3A-4A5F-B4C0-A64842FD4625@otoh.org> In-Reply-To: <189794E3-5C3A-4A5F-B4C0-A64842FD4625@otoh.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 15:46:26 -0000 Yes, RFC 7960 summarized/gathered what was already well known. We also have a List Server product, for practically "30 years," too and I am very aware of how mail flows works. One problem is the fallacy that we didn't want to change software. Well, I was ready to do so, and did, and only until others were force to do so, other list servers began to do the 5322.From rewriting thing. Not my preference to be tampering with the author address, I do recognize it helped address the issue. The better rand more logical alternative (imo) is for the list to: - Deny Restrictive Domains in the name of security, both for subscriptions and submissions into a list. Finally, in my opinion, extended policy designs need to be revisited as an simplified alternative to the experimental status, a high overhead, expensive ARC design which really doesn't promise anything, yet, other than record what kind of failures happened. I can't find convincing ARC design logic that suggest this will help address the unauthorized 3rd party resigner problem unless as I suggested, it comes with an extended DMARC tag that gives receivers the "authority" to check the "ARCness" of a failed DKIM message. Even though, I would only like to do so with authorized domains I trust. On 5/31/2019 11:16 AM, Elizabeth Zwicky wrote: > > RFC 7960 has an extensive discussion of mail flows that modify mail (as well as other cases that are problematic for DMARC). Mailing lists are not the only case, and, as John has pointed out, reformatting and part stripping are things that happen in mail flows. > > Elizabeth > >> On May 31, 2019, at 8:02 AM, Hector Santos wrote: >> >>> On 5/31/2019 6:59 AM, Douglas E. Foster wrote: >>> >>> DKIM was supposed to provide sender authentication when SPF was >>> invalidated by forwarding, so DMARC said that the two techniques >>> should be evaluated together. >> >> Unfortunately, DMARC did not have a policy that offered that output. >> >> SPF >> FAIL >> DMARC >> PASS? >> >> Overall, DMARC failed to cover all the possible scenarios of mixed signatures. >> >> To cover all aspects, the DKIM POLICY model has to offer 3rd party signature conditions. In the DSAP proposal, it highlighted this as the broader possible options: >> >> https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2 >> >> +-----------------------------------------------------------------+ >> | op= | 3p= | Domain Policy Semantics | >> |=================================================================| >> | empty | empty | No mail expected | >> |-----------------------------------------------------------------| >> | never | never | No signing expected | >> | never | always | Only 3P signing expected | >> | never | optional | Only 3P signing optional | >> |-----------------------------------------------------------------| >> | always | never | OP signature expected | >> | always | always | Both parties expected | >> | always | optional | OP expected, 3P may sign | >> |-----------------------------------------------------------------| >> | optional | never | Only OP signing expected | >> | optional | always | OP expected, 3P expected | >> | optional | optional | Both parties may sign. | >> +-----------------------------------------------------------------+ >> >> That covered all possible combinations. >> >> We actually wrote an IETF functional spec regarding Sender Signing Policies: >> >> rfc5016 Requirements for a DKIM Signing Practices Protocol >> https://tools.ietf.org/html/rfc5016 >> >> Abstract >> >> DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism >> for domains to assert responsibility for the messages they handle. A >> related mechanism will allow an administrator to publish various >> statements about their DKIM signing practices. This document defines >> requirements for this mechanism, distinguishing between those that >> must be satisfied (MUST), and those that are highly desirable >> (SHOULD). >> >> >> But then something happen as this document was being completed -- list administrators got scared that DKIM Policy was gaining tractions and stepping into their market toes. After all, we had "30 years" of legacy list operations, we did not want DKIM Policy interfering with the broad range of established list distribution operations. So this RFC5016 "Blocker" was written at the last minute to preempt it from happening: >> >> Section 5.3, Item 10 >> https://tools.ietf.org/html/rfc5016#section-5.3 >> >> 10. SSP MUST NOT provide a mechanism that impugns the existence of >> non-first party signatures in a message. A corollary of this >> requirement is that the protocol MUST NOT link practices of first >> party signers with the practices of third party signers. >> >> INFORMATIVE NOTE: the main thrust of this requirement is that >> practices should only be published for that which the publisher >> has control, and should not meddle in what is ultimately the >> local policy of the receiver. >> >> >> That was basically, a "Don't step on my turf!!" requirement. It also meant "Local Policy Always Prevail" regardless of what a Domain published which is always the case anyway. Does not need to be stated. But overall, this is what help demote SSP, ADSP, ATPS and DKIM policy in general. ADSP was abandoned. >> >> But no one can kill a good idea, the proof of concept was too powerful, hence it returned as DMARC but as an informational status document to avoid the IETF mch higher review process. >> >> I have no idea how a high overhead, complex ARC will resolve this problem unless >> it comes with a 3rd party signature concept with an extended DMARC "arc=y" tag: >> >> arc=y If the 1st party signature failed, then authorize the XYZ >> domains using ARC seals to promote a failure to a pass. >> >> How would you specify the 'authorization" of XYZ domains and do so at scale? >> >> -- >> HLS >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- HLS From nobody Fri May 31 10:34:25 2019 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 A8289120346 for ; Fri, 31 May 2019 10:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=KYQoO4a6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=6ZuuBwQg 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 mKwWG2lar9qq for ; Fri, 31 May 2019 10:34:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DF7120352 for ; Fri, 31 May 2019 10:34:12 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7DD0D210DC; Fri, 31 May 2019 13:34:11 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Fri, 31 May 2019 13:34:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=5Uy8CtT8YVxeGMQuUfSZys/T0I7d h4Mr28YVLfIUy3o=; b=KYQoO4a6n5vilEbbYDr3494T9CgVzTeV3udrkQdbjFH2 Q9gjMSwpkZuN/nRl2nTZhdO8u00gi71JF51aV1+Y8zwzMbwreRfS2hZ2MnCsSmF7 XPAdbKKZrOHCZAWYE6wzvCbRsu0tvwKH5v4k4JfV5ciffeqqZp5i0pO241cTnEsT xh63WWKzfuvd+RR611dcXbWNGKYcGrbt0xpq46h7wTWSHFWSFCTmOUUEbAb15VJ8 Rq5/dUYlYPZsmf0FN3ohWbaOyY3N4G6ojlM47j41GMNOb9Db7w5YWDMDf+SrvYFu 3m8DtxYvnTOBEEy5cZH9+fbTIBQm7pwLaFVq8IohAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5Uy8Ct T8YVxeGMQuUfSZys/T0I7dh4Mr28YVLfIUy3o=; b=6ZuuBwQgUbAEDEW3AsM1U+ BeCWQqQHD7vSsVuMmFCZgos2sRCWQWw1H4oC2WidWh14hPD7EyVl7FCGHDYq1s9Z M7Z60itwn8SGc1ex6swFUdTDYku2s3E6DzBaB8/vKUHsJ6MlMG/kqQeJ78esIUqB Tpz9b+T7RpO8MRQyr+u1xf/QU9o60Y3ab44oP/7R2B/xvOxCXlq2r1yaeHcMe8xm 54VKqvvHWpmkmfpz/V/Z6zh7p68i1p4pSe5ivrl3g4XRmYK3+F/BI8NDuCqQRLMx /uc6MrV7YkGGeGX6CGJFWHUs415Vt560YV36kiEF8xKQ1LJ1LK+5ktvtlTh8wH6w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefuddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfufht rghnucfmrghlihhstghhfdcuoehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtg gvrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgpdgssghifidrnhgvthenucfr rghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorh gtvgdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE70B1400A0; Fri, 31 May 2019 13:34:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <5f121135-7ae9-4219-aacf-fac253ecad08@www.fastmail.com> In-Reply-To: References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> Date: Fri, 31 May 2019 13:34:08 -0400 From: "Stan Kalisch" To: "Douglas E. Foster" Cc: "IETF DMARC WG" Content-Type: multipart/alternative; boundary=55f07ef4e38d4018ac744db198136f97 Archived-At: Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion 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, 31 May 2019 17:34:24 -0000 --55f07ef4e38d4018ac744db198136f97 Content-Type: text/plain On Fri, May 31, 2019, at 6:59 AM, Douglas E. Foster wrote: > I cannot speak to IETF consensus, since I am new to that process and I seem to be an outlier already. > > Agency and signatures are well understood legal concepts. 3000 years ago, people sealed their letters with a signet ring stamped in warm clay. Signing technologies have changed in that time, but the principle has not. It would probably behoove you not to lecture experts in Internet messaging about 3000 years of history on a public mailing list. I'm just saying. Thanks, Stan > > A courier is responsible for keeping the signed and sealed part of a message unaltered. Envelope marks are acceptable. > > A digital signature is supposed to provide non-repudiation. If I submit a signed message to a list processor, and the list processor voids the signature, it has given me verifiable repudiation, the opposite of what either sender or receiver want. > > A closed group on a single server can use whatever rules they choose to implement in that community. For example, a web forum operates on the rules of the forum operator. However, an open group using the email infrastructure has to work within the infrastructure it uses. In the email infrastructure, the recipient has to deal with fraud, and any recipient accommodation to "harmless" fraud facilitates the people who are doing "harmful" fraud to that recipient. > > There are some obvious use-cases for MTA changes to a message, and we would do well to document and address them. > > The first that comes to mind is MTA comment fields. > - A list processor wants to add a comment indicating something about the list that sent it. > - A spam filter wants to add a tag indicating that the message is suspicious, but not sufficiently suspicious to be blocked. > > IETF would do well to specify a mechanism for MTAs to add information which MUAs present to the user, while identifiying that that the information came from the MTA rather than the original sender. > > Another use-case is related to body sections. IETF only forwards plain text, while most email solutions send messages in HTML+Text. I assume that IETF also drops attachments. DKIM cannot handle this because it hashes the entire body. A signature system that signed each section individually would allow sections to be dropped, with notification to the user, without breaking the signatures on the other MIME types. > > DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding, so DMARC said that the two techniques should be evaluated together. I am realizing that if SPF is invalidated, DKIM is probably invalidated as well, so we have no usable sender authentication technology. This may explain why so many products that I have examined lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and DMARC. > > It seems that email needs something like "DNS Flag Day", where major players announce a date after which certain behaviors that will no longer be tolerated. But as others have said, IETF is not that organization, and the organization may not exist. > > More discouraged than ever, > > Doug Foster > > > > > > > > > > *From*: "Dave Crocker" > *Sent*: Friday, May 31, 2019 12:41 AM > *To*: fosterd@bayviewphysicians.com > *Cc*: "IETF DMARC WG" > *Subject*: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion > > On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > > I rather hoped that IETF would be the poster-boy for list processing > > done correctly. > > "Correctly"? > > A message to a list is 'delivered' to the list. As in, it goes to the > specified addresse... the list. A message from a list has been > re-posted by the list. > > There are no constraints on the changes that are permitted to a message, > before it is re-posted. There are no specifications that limit or > direct the behaviors of a list processor. > > Different groups want and probably need different behaviors by a list > processor. Periodic efforts to create such constraints have failed. > > So while it would certainly make things easier to have list processors > behave in a simple, consistent manner, there's ample evidence that ain't > gonna happen. > > If you can link the 'correctly' you are suggesting, to some documented, > community consensus, please cite it. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --55f07ef4e38d4018ac744db198136f97 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2019, at 6:59 AM, Douglas E. Foster wrote:=
I cannot speak to IETF consensus, since I am ne= w to that process and I seem to be an  outlier already.
 
Agency and signatures are well understood legal = concepts.   3000 years ago, people sealed their letters with a= signet ring stamped in warm clay.   Signing technologies have= changed in that time, but the principle has not.

It would probably behoove you not to lecture experts= in Internet messaging about 3000 years of history on a public mailing l= ist.  I'm just saying.
<= br>

Thanks,
Stan


A courie= r is responsible for keeping the signed and sealed part of a messag= e unaltered.   Envelope marks are acceptable.
 
A digital signature is supposed to provide non-r= epudiation.  If I submit a signed message to a list processor,= and the list processor voids the signature, it has given me verifiable = repudiation, the opposite of what either sender or receiver want.  =  
 
A closed group on a single ser= ver can use whatever rules they choose to implement in that community.&n= bsp; For example, a web forum operates on the rules of the forum op= erator.   However, an open group using the email infrastructur= e has to work within the infrastructure it uses.   In the= email infrastructure, the recipient has to deal with fraud, and any rec= ipient accommodation to "harmless" fraud facilitates the people who are = doing "harmful" fraud to that recipient.
 
<= div>There are some obvious use-cases for MTA changes to a message, and w= e would do well to document and address them.
 
The first that comes to mind is MTA comment fields.
- A list processor wants to add a comment indicating something about = the list that sent it.
- A spam filter wants to add a tag = indicating that the message is suspicious, but not sufficiently suspicio= us to be blocked.
 
IETF would do well = to specify a mechanism for MTAs to add information which MUAs present to= the user, while identifiying that that the information came from the MT= A rather than the original sender.
 
An= other use-case is related to body sections.   IETF only forwar= ds plain text, while most email solutions send messages in HTML+Text.&nb= sp;  I assume that IETF also drops attachments.   DK= IM cannot handle this because it hashes the entire body.   A s= ignature system that signed each section individually would allow s= ections to be dropped, with notification to the user, without breaking t= he signatures on the other MIME types.
 
DKIM was supposed to provide sender authentication when SPF was invali= dated by forwarding, so DMARC said that the two techniques should be eva= luated together.   I am realizing that if SPF is invalidated, = DKIM is probably invalidated as well, so we have no usable sender authen= tication technology.   This may explain why so many products t= hat I have examined lack support for DMARC or lack good exception m= echanisms for SPF, DKIM, and DMARC.
 
I= t seems that email needs something like "DNS Flag Day", where major play= ers announce a date after which certain behaviors that will no longer be= tolerated.   But as others have said, IETF is not that organi= zation, and the organization may not exist.
 
More discouraged than ever,
 
Do= ug Foster
 
 
 =
 
 
 
 
 

From: "Dave Crocker" <dhc@dcrocker.net>
S= ent: Friday, May 31, 2019 12:41 AM
To: fosterd@bayviewphy= sicians.com
Cc: "IETF DMARC WG" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- s= uggestion
 
On 5/30/2019 7:49 PM, Douglas E. Foster wrote:
> I rather hoped that IETF would be t= he poster-boy for list processing
> done correctly.
<= br>
"Correctly"?

A message to a list is 'delivered' to the list. As in, it goes to the<= br>
specified addresse... the li= st. A message from a list has been
re-posted by the list.

There are no constraints = on the changes that are permitted to a message,
before it is re-posted. There are no specifications = that limit or
direct the beh= aviors of a list processor.
=
Different groups want and p= robably need different behaviors by a list
processor. Periodic efforts to create such constraints ha= ve failed.

So while it would certainly make things easi= er to have list processors
b= ehave in a simple, consistent manner, there's ample evidence that ain't<= br>
gonna happen.

If you can link the 'correctly' you are suggesting, to some documente= d,
community consensus, plea= se cite it.


d/

--
Dav= e Crocker
Brandenburg Intern= etWorking
bbiw.net
=
 
<= div>_______________________________________________
dmarc = mailing list
dmarc@ietf.org
https://www.ietf= .org/mailman/listinfo/dmarc


--55f07ef4e38d4018ac744db198136f97-- From nobody Fri May 31 10:55:39 2019 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 2788B120058 for ; Fri, 31 May 2019 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 7rUreuDybAJB for ; Fri, 31 May 2019 10:55:36 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 466B912001A for ; Fri, 31 May 2019 10:55:36 -0700 (PDT) Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id x4VHtWaf010198 for ; Fri, 31 May 2019 17:55:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1559325333; i=dkim+sm-localhost@aegee.org; r=y; bh=7lb79T/kdh54MDKgefeKpi/hBqA4Fz7kQY9yFrdQ9Kc=; h=Date:From:To:Subject; b=g5YAXTvAegqvJyqPZDOElN+q6iaoSanQEsrroFv/6R22Fu/V/TNK6GOfpY4kxLEwu BU8Ys8+/RSTTVpRgCnD0rYeM/N77PZZ8XPdtCGMvFSDilTq0rlZE7CosbuuTGBdfgF poSyZhyyByLg/sPo4JTs9A13B1NH+xuSDUTSTbD1l57QyaKifD7yzVeNz1cZcIny+Y gdxhWvQvonzMuZ9wYqBfy+B2n18VWyrsV7sQiE5EAGX+DGcE6qIod/0ysXSBb0OM3j pxKiyFLkgK8osHS245nCUWw5iKzzA5fVMx/L159j1QR9SmfueXTYjYbqwdBC9lLGW6 Ktw2H7ZDUvojKAnPOhzfx47iH5Jao3tLN1cPd0hL5OaGx5xVadI8OV6J1t6Q410EVc fQfvr24i83YEM4iffnU4LmcCkwIDNAFyf2++uZNKHbgtjB6p+7Hm/E39bLBaXXIGQb YRapdeMDgEpIEp7NCKUIlfccNw0Gcd7vg6WYQWh5+4wX6xfKAlGztVioJUqdiZaufM 31uZRCyH2U0pXN39nXrUbZDOMq1UUmPAmOBiawhtsPEeSbg1F/2h6fa1Y1dueh9LLQ e3X+5dhxchXE5lKRxRYCRHMHiVLuHwFRhgMqShXNqmVIy2xe3vHg5Qpe1Lod8x9YjZ cCyYgyEK1MNs1UO1eNOamWA4= Authentication-Results: mail.aegee.org/x4VHtWaf010198; dkim=none Received: from 87-118-146-153.ip.btc-net.bg (87-118-146-153.ip.btc-net.bg [87.118.146.153]) by webmail.aegee.org (Horde Framework) with HTTPS; Fri, 31 May 2019 17:55:32 +0000 Date: Fri, 31 May 2019 17:55:32 +0000 Message-ID: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> From: Dilyan Palauzov To: IETF DMARC WG User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Endless Email Loops with Aggregate Reports 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, 31 May 2019 17:55:38 -0000 Hello, DMARC aggregate reports can and do cause endless loops, too: A site publishes an email address for receiving aggregate DMARC reports. The rua-address bounces the messages (aggregate report) received there and the bounces does not validate the DMARC policy. So on the next reporting period a new aggregate report is sent, stating that the reply on the previous report failed DMARC validation. Unlike endless email loops caused by message-specific failure reports, the endless email loops caused by aggregate reports are by design rate-limited: one email per reported domain and reporting period. A wait to reduce the possibility into getting in such loops is toT send the reports FROM:<>. That said I propose recommending in DMARC, that both the message-specific reports and the aggregate reports are sent FROM:<> or NOTIFY=NEVER. Shall I submit an erratum to RFC7489? Regards Дилян From nobody Fri May 31 13:47:53 2019 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 3BF9212010D; Fri, 31 May 2019 13:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 T8qXTILk0LBx; Fri, 31 May 2019 13:47:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C1B120058; Fri, 31 May 2019 13:47:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6A33EB81FDC; Fri, 31 May 2019 13:47:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmarc@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190531204745.6A33EB81FDC@rfc-editor.org> Date: Fri, 31 May 2019 13:47:45 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] =?utf-8?q?RFC_8601_on_Message_Header_Field_for_Indi?= =?utf-8?q?cating_Message_Authentication_Status?= 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, 31 May 2019 20:47:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8601 Title: Message Header Field for Indicating Message Authentication Status Author: M. Kucherawy Status: Standards Track Stream: IETF Date: May 2019 Mailbox: superuser@gmail.com Pages: 54 Characters: 122384 Obsoletes: RFC 7601 I-D Tag: draft-ietf-dmarc-rfc7601bis-06.txt URL: https://www.rfc-editor.org/info/rfc8601 DOI: 10.17487/RFC8601 This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. This document is a product of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC