From nobody Sun May 3 22:34:51 2020 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 AD48B3A0C53 for ; Sun, 3 May 2020 22:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zoyn7wJv6Dt for ; Sun, 3 May 2020 22:34:43 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450: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 736173A0B1B for ; Sun, 3 May 2020 22:34:43 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id u16so7463379wmc.5 for ; Sun, 03 May 2020 22:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=g1foYvuiie9kCe4TFwPh2Bqv4V1t1Tuvinu7Tf692i4=; b=HxoV2LIpLoh+zpRy84G7KR55YFI1uQM1nZ1iNIMyrSPsJ/4cDK8iQSuPLWZ+9ixTzd f+CEZ4RmpKmopRr5yUA/DpckPiDUCHBk8PXMB+bhFe14ATC+UYMFFR/QSOTe11Tcc++P MyGqCKeajApMG/yvDwZyWyk/eYdAs/jRhuna1wp81wOIctGr/ELwddhALlWWBrfHIamk NnVwn3s3V6WVFEGYEGHGOW+wX2IXfzeEa/1mC2Mr9bP5ux0vZ0rMOMsSKFI4Y1/pg79k v4J4b3sUT2GXDJ+mLk/PtbXiZhnJs1ird963iRIpCKlOQdwoJ1vI2cKV3n2bIy3yS7Ce cPRQ== 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=g1foYvuiie9kCe4TFwPh2Bqv4V1t1Tuvinu7Tf692i4=; b=g6p7JeVy9NGZdJVnSe3Lv93Z2HMHhSQRdo74SGJroj0EXgk/K2Fv+ygXwric/LJ0r7 w8PdEAISBrLL6p/8qM6EN+AMXng2otHmu6qoAFyWD6quZOO3UMJlG4By3Up550c4yZcm BchpCA1dzWXgxTB1zAEsfCe7mnvQJMXMkJlHNXNVfAbfPDNuufviZ03Dd/o7gEU8Smmi ADmi7qd96laPkm3aU002fYb0vOulmAphzv0O/EIriXhbxhgi2zx00pkmMiKmpHfoEqGp hSz3LEyu1yNQdhoNdMq8ZWAAg5Cw88EdO0KJTb/FTD+vncHFWB2IgQD+BhJWCHlpjg0+ drsA== X-Gm-Message-State: AGi0PuaqU4dZEPhLvadutC8Oy+XC4Mv/MBEKFHEgv5eHA/rEoA63EX68 Sg6e73THOe+HVdDG2SepHZwEvwntJPWyLrcCcsdhVizSs4A= X-Google-Smtp-Source: APiQypKpU8V79pn4+Xz0Q3b1DroY3g1FQx8nXRWWL7DaM4OvDBWsRRUEBKqxHZFZ+hH9pjltPWuQ/uQOu5GhKJsAZtI= X-Received: by 2002:a05:600c:258:: with SMTP id 24mr12348140wmj.73.1588570481194; Sun, 03 May 2020 22:34:41 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Sun, 3 May 2020 22:34:30 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003b896c05a4cbe33f" Archived-At: Subject: [dmarc-ietf] Kicking off DMARCbis -- tracker and process updates 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, 04 May 2020 05:34:50 -0000 --0000000000003b896c05a4cbe33f Content-Type: text/plain; charset="UTF-8" Hi all, For us to present a standards track document to the IESG, there are many items, some contentious and potentially time consuming, that we must discuss and resolve. While Tim has set up a GitHub repository for work on the I-D, we will be using the datatracker to manage that work. The intention of the Chairs is to have an orderly discussion of all the items, ensure all concerns are raised, tracked, and resolved, and deliver a document that successfully makes the transition from ISE to IESG approval. Look for a separate email from Alexey on our process for managing items in the data tracker itself. Please refrain from adding any new items until Alexey's email is in hand. The datatracker now reflects items raised on the list as well as other items brought to the Chairs directly: https://trac.ietf.org/trac/dmarc/report/1 Please do NOT edit, close, or comment on issues until a Chair explicitly opens discussion on the item on list, as discussed below. As of this evening, there are 56 open items in the tracker, they all appear to roughly fall into the following buckets (with some examples from each): 1) nits - ABNF issues, preventing feedback loops, better statuses 2) updates to tags (primarily calls for removal) - remove sp, pct, ri, apsf, adkim, and reporting chunking 3) reporting enhancements - more extensible reporting, ARC reports, JSON reports, https POST reporting, stripped down failure reports 4) clarifying prose - implications of failure reports, define what it means to have "implemented" DMARC 5) general improvements - PSD, removing the PSL and Org Domain definition from DMARC None of these items are themselves requirements, some may overstate their claims, other under, and others still are mutually exclusive or depend on the resolution state of other items. The only requirement is that every item in the tracker must be brought to the group for discussion. To efficiently discuss as a WG and arrive at a rough consensus on each item, the Chairs will use the following process for DMARCbis to tear through open tracker items: - We will have three tickets from the datatracker open for discussion on the list at any given time - Each ticket will have a Chair responsible for shepherding discussion - Once consensus is called on a ticket, that will be recorded in the tracker, and a new ticket will be opened for discussion - This process is separate from editing the I-D (or I-Ds), which will occur in parallel, but will not block this process We'll be bringing the first three items to the list later this week. As MSK said in March, it will likely be a long road to get this work ready for Standards Track and address all the open issues. We're looking forward to everyone's collaboration and progressing this work together. Seth, as Chair -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000003b896c05a4cbe33f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

For us to present a standa= rds track document to the IESG, there are many items, some contentious and = potentially time consuming, that we must discuss and resolve. While Tim has= =C2=A0set up a GitHub repository for work on the I-D, we will be using the = datatracker to manage that work.

The intention of = the Chairs is to have an orderly discussion of all the items, ensure all co= ncerns are raised, tracked, and resolved, and deliver a document that succe= ssfully=C2=A0makes the transition from ISE to IESG approval.

Look for=C2=A0a separate email from Alexey on o= ur process for managing items in the data tracker itself. Please refrain fr= om adding any new items until Alexey's email is in hand.
=

4) clarifying prose
=C2=A0 =C2=A0 - implications of failure reports, define what it mean= s to have "implemented" DMARC

5) general= improvements
=C2=A0 =C2=A0 - PSD, removing the PSL and Org Domai= n definition from DMARC

None= of these items are themselves requirements, some may overstate their claim= s, other under, and others still are mutually exclusive or depend on the=C2= =A0resolution state of other items. The only requirement is that every item= in the tracker must be brought to the group for discussion.

=
To efficiently discuss as a WG and arrive at a rough = consensus on each item, the Chairs will use the following process for DMARC= bis to tear through open tracker items:

- We will = have three tickets from the datatracker open for discussion on the list at = any given time

- Each ticket will have a Chair res= ponsible for shepherding discussion

- Once consens= us is called on a ticket, that will be recorded in the tracker, and a new t= icket will be opened for discussion

- This process= is separate from editing the I-D (or I-Ds), which will occur in parallel, = but will not block this process

We'll be bring= ing the first three items to the list later this week.

=
As MSK said in March, it will likely be a long road to get this work r= eady for Standards Track and address all the open issues. We're looking= forward to everyone's collaboration and progressing this work together= .

Seth, as Chair

--

--0000000000003b896c05a4cbe33f-- From nobody Tue May 5 05:13:58 2020 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 9B1793A165D for ; Tue, 5 May 2020 05:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=isode.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 LkGblD4lkNiJ for ; Tue, 5 May 2020 05:13:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9B3A164C for ; Tue, 5 May 2020 05:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588680830; d=isode.com; s=june2016; i=@isode.com; bh=oIywu4aD5e3qsILM1VPopgn91bXwfCyjn/0am/zr0vA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VISVQyinfYVyByAE36k4Hf/c6twP9jpDDvaswAUzP9Psxk1fKSGxP+ZIKc5dJclEgw7fwd asfRz4fSg4OLbqYKMuxCik6Rna+UyGb1eJOkaW2Uw3AphAleN2qkgiS3GHraJEzSjkX6yO abPLOSJ2sMX3OqDbhonWzLrSfaUJx+I=; Received: from [172.27.250.123] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 5 May 2020 13:13:50 +0100 References: To: dmarc@ietf.org From: Alexey Melnikov X-Forwarded-Message-Id: Message-ID: <4a7ed1a9-6f2c-59a3-aa16-51504372e6bf@isode.com> Date: Tue, 5 May 2020 13:13:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8F6AAD3A7B43F0C6422DA563" Content-Language: en-GB Archived-At: Subject: [dmarc-ietf] Fwd: Fwd: Reminder: Survey on planning for possible online IETF meetings 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, 05 May 2020 12:13:56 -0000 --------------8F6AAD3A7B43F0C6422DA563 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable -------- Forwarded Message -------- Subject: Fwd: Reminder: Survey on planning for possible online IETF=20 meetings Date: Tue, 5 May 2020 07:48:03 -0400 From: Alissa Cooper To: IETF WG Chairs Please circulate this to your working group lists. The survey data will=20 be very important as we plan future IETF meetings. Thanks, Alissa > Begin forwarded message: > > *From: *IETF Executive Director > > *Subject: **Reminder: Survey on planning for possible online IETF=20 > meetings* > *Date: *May 4, 2020 at 3:03:35 AM EDT > *To: *"IETF Announcement List" > > *Reply-To: *ietf108planning@ietf.org > > This is a reminder that we need the IETF community to help us plan for=20 > the possibility that one or more upcoming IETF meetings in 2020 and=20 > possibly 2021 may not be able to go ahead in person. =A0You can help us=20 > with this by filling out the following survey: > > https://www.surveymonkey.com/r/5328FFJ > > So far we have 114 responses and we would ideally like 500 or more. > > The survey contains the following pages and will take 15-20 minutes to=20 > complete: > > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else > > We run the survey in anonymous mode which means that we only see data=20 > that you explicitly provide. > > Thank you in advance for your help. > > --=20 > Alissa Cooper, IETF Chair > Jay Daley, IETF Executive Director > Colin Perkins, IRTF Chair > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --------------8F6AAD3A7B43F0C6422DA563 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
-------- Forwarded Message --------
Subjec= t: Fwd: Reminder: Survey on planning for possible online IETF meetings
Date: = Tue, 5 May 2020 07:48:03 -0400
From: = Alissa Cooper <alissa@cooperw.in>
To: IETF WG Chairs <wgchairs@ietf.org>

Please circulate this to your working group lists. The survey data will be very important as we plan future IETF meetings.

Thanks,
Alissa

Begin forwarded message:

From: IETF Executive Director <exec-director@ietf.org>
Subject: Reminder: Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" <ietf-announce@ietf.org= >
Reply-To: ietf108planning@ietf.org

This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. =A0You can help us with this by filling out the following survey:

https://www.surveymonkey.com/r/53= 28FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

--------------8F6AAD3A7B43F0C6422DA563-- From nobody Thu May 7 00:22:34 2020 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 BD6743A0A52; Thu, 7 May 2020 00:22:25 -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.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <158883614571.29832.10508160398155087158@ietfa.amsl.com> Date: Thu, 07 May 2020 00:22:25 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-09.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: Thu, 07 May 2020 07:22:33 -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 : Recommended Usage of the Authenticated Received Chain (ARC) Authors : Steven M Jones Kurt Andersen Filename : draft-ietf-dmarc-arc-usage-09.txt Pages : 19 Date : 2020-05-07 Abstract: The Authenticated Received Chain (ARC) provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. But the specification does not indicate how the entities handling these messages should interpret or utilize ARC results in making decisions about message disposition. This document will provide guidance in these areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-09 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-09 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 Sat May 9 07:45:07 2020 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 1E9EB3A0B0F for ; Sat, 9 May 2020 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=hmzVWeas; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pI2vV2US 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 q-U7jJyMku1b for ; Sat, 9 May 2020 07:45:00 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F054C3A0B08 for ; Sat, 9 May 2020 07:44:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 377F35C00A8 for ; Sat, 9 May 2020 10:44:59 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Sat, 09 May 2020 10:44:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=QYKK5P5Q8ji2Fv4T32GnstWbkGdgPlM JUsla5pTY4WU=; b=hmzVWeasW1lzphmB/bYMKM6ihkiwHbaC8r+DnlYw4ROB5j9 U2kxSvtj3Fech6zEUBKh+mAbjE1mmNJWiYwxkceS9DG/U0t6TV9SDXavQ1w8EyhU I6pcuwac7F9zDWelXvURJ/MsEJJGsJEX51kcAxkCQT6Bqn93o5G8wODTycFvd0Hw DPhlbTuzM06MI+6twuetcawzuSJtIeUr8q1QdqVyL4IddG8893iu2uUZeAMjH9nm GyJGT+ydeFIU0afYptzr27D5Qy8vuQmGj2O78xSH0JhqabpTpV5reQHc+7RkdY10 COYT0InZf4U5+pWjDXVda1FxSiTt6mczXFoWccw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=QYKK5P 5Q8ji2Fv4T32GnstWbkGdgPlMJUsla5pTY4WU=; b=pI2vV2USJ7KMoezY/u+JuP xhLjXwde5EznOw4ann+H9QDQvGHEv/mRgwDy6uKH6lpjFySBhKiK+tdzZEy4pbek VXSf5Ob5WKGo8pZBZHpsCwDRISQdliBQfupriTAvXi0cMSPjMwbSD6B2rB/Ya47r Cnn5/SdHWFQzqKYlA5zk8Nn61iVObblLxDTxgNBbyybJPoKatnMQJNUJuGrGIf1X vMJ/7+YPpV8OY9iAg445TqrgNVGUWAPk4wAUnXt2ZqVfZ/AmQO7VEep1myCMSUrA SKD7TtsUeb1211wPy3FblgjAKL0K4a5BmmLrlKyhPWU3TQjEJgrPUH7Rl04narAA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeehgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghffffh vffutgesrgdtreerreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfd cuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghr nhepgfellefgteduteegieeifffgueduteefveetvdekhefgjeevveelhfejieegffefne cuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EF537660069; Sat, 9 May 2020 10:44:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <76be3b2c-fe09-46f1-adc4-8804c86ca7c3@www.fastmail.com> In-Reply-To: References: Date: Sat, 09 May 2020 15:43:42 +0100 From: "Alexey Melnikov" To: "IETF DMARC WG" Content-Type: multipart/alternative; boundary=77b629220a054cf2956763ff7f932608 Archived-At: Subject: Re: [dmarc-ietf] Kicking off DMARCbis -- tracker and process updates 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, 09 May 2020 14:45:04 -0000 --77b629220a054cf2956763ff7f932608 Content-Type: text/plain Hi all, This is the followup email that Seth was talking about in the message below. Here is the process that chairs will use for managing tickets in trac (and just to clarify, when Seth wrote "datatracker" he really meant "trac" on tools.ietf.org) 1) Opening tickets: anyone can open a new ticket. But please check existing tickets (including the closed ones) if the issue was already discussed. Chairs would require higher bar for reopening closed tickets. If you want to reopen a ticket, please email WG chairs directly at dmarc-chairs@ietf.org. 2) Closing tickets: Document editors can close tickets about editorial issues. These will have the summary line starting with "Editorial: ". (If in doubt, please ask WG chairs whether you think it is editorial or not) Only Chairs can close larger issues. All issues must be closed with a reference to the mailing list discussion (typically an URL of a message in the DMARC mailing list archive). When we get closer to being done with DMARCbis, chairs might switch to stricter rules about closing tickets. If we do, we will send a separate email about that at that time. Best Regards, Alexey, on behalf of chairs. On Mon, May 4, 2020, at 6:34 AM, Seth Blank wrote: > Hi all, > > For us to present a standards track document to the IESG, there are many items, some contentious and potentially time consuming, that we must discuss and resolve. While Tim has set up a GitHub repository for work on the I-D, we will be using the datatracker to manage that work. > > The intention of the Chairs is to have an orderly discussion of all the items, ensure all concerns are raised, tracked, and resolved, and deliver a document that successfully makes the transition from ISE to IESG approval. > > > Look for a separate email from Alexey on our process for managing items in the data tracker itself. Please refrain from adding any new items until Alexey's email is in hand. > > The datatracker now reflects items raised on the list as well as other items brought to the Chairs directly: https://trac.ietf.org/trac/dmarc/report/1 Please do NOT edit, close, or comment on issues until a Chair explicitly opens discussion on the item on list, as discussed below. > > As of this evening, there are 56 open items in the tracker, they all appear to roughly fall into the following buckets (with some examples from each): > > 1) nits > - ABNF issues, preventing feedback loops, better statuses > > 2) updates to tags (primarily calls for removal) > - remove sp, pct, ri, apsf, adkim, and reporting chunking > > 3) reporting enhancements > - more extensible reporting, ARC reports, JSON reports, https POST reporting, stripped down failure reports > > 4) clarifying prose > - implications of failure reports, define what it means to have "implemented" DMARC > > 5) general improvements > - PSD, removing the PSL and Org Domain definition from DMARC > > > None of these items are themselves requirements, some may overstate their claims, other under, and others still are mutually exclusive or depend on the resolution state of other items. The only requirement is that every item in the tracker must be brought to the group for discussion. > > > To efficiently discuss as a WG and arrive at a rough consensus on each item, the Chairs will use the following process for DMARCbis to tear through open tracker items: > > - We will have three tickets from the datatracker open for discussion on the list at any given time > > - Each ticket will have a Chair responsible for shepherding discussion > > - Once consensus is called on a ticket, that will be recorded in the tracker, and a new ticket will be opened for discussion > > - This process is separate from editing the I-D (or I-Ds), which will occur in parallel, but will not block this process > > We'll be bringing the first three items to the list later this week. > > As MSK said in March, it will likely be a long road to get this work ready for Standards Track and address all the open issues. We're looking forward to everyone's collaboration and progressing this work together.. > > Seth, as Chair > > -- > > *Seth Blank* | VP, Standards and New Technologies > *e:* seth@valimail.com > *p:* 415.273.8818 > > > > This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --77b629220a054cf2956763ff7f932608 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

This is the followup email that Seth was talking = about in the message below. Here is the process that chairs will use for= managing tickets in trac (and just to clarify, when Seth wrote "datatra= cker" he really meant "trac" on tools.ietf.org)

=
1) Opening tickets: anyone can open a new ticket. But please check = existing tickets (including the closed ones) if the issue was already di= scussed. Chairs would require higher bar for reopening closed tickets. I= f you want to reopen a ticket, please email WG chairs directly at dmarc-chairs@ietf.org.
<= div>
2) Closing tickets:

Docu= ment editors can close tickets about editorial issues. These will have t= he summary line starting with "Editorial: ".
(If in doubt,= please ask WG chairs whether you think it is editorial or not)

Only Chairs can close larger issues.
=

All issues must be closed with a reference= to the mailing list discussion (typically an URL of a message in the DM= ARC mailing list archive).

When we get clos= er to being done with DMARCbis, chairs might switch to stricter rules ab= out closing tickets. If we do, we will send a separate email about that = at that time.

Best Regards,
A= lexey, on behalf of chairs.

On Mon, May 4, = 2020, at 6:34 AM, Seth Blank wrote:
Hi all,

For us to present a standards track document to the IESG, th= ere are many items, some contentious and potentially time consuming, tha= t we must discuss and resolve. While Tim has set up a GitHub reposi= tory for work on the I-D, we will be using the datatracker to manage tha= t work.

The intention of the Chairs is to h= ave an orderly discussion of all the items, ensure all concerns are rais= ed, tracked, and resolved, and deliver a document that successfully = ;makes the transition from ISE to IESG approval.


Look for a separate email from Alexey on= our process for managing items in the data tracker itself. Please refra= in from adding any new items until Alexey's email is in hand.
<= div>
The datatracker now reflects items raised on the list= as well as other items brought to the Chairs directly: https://trac.ietf.org/trac/dm= arc/report/1 Please do NOT edit, close, or comment on issues un= til a Chair explicitly opens discussion on the item on list, as discusse= d below.

As of this evening, there are= 56 open items in the tracker, they all appear to roughly fall into the = following buckets (with some examples from each):

1) nits
    - ABNF issues, preventing fee= dback loops, better statuses

2) updates to = tags (primarily calls for removal)
    - remove = sp, pct, ri, apsf, adkim, and reporting chunking

3) reporting enhancements
    - more exten= sible reporting, ARC reports, JSON reports, https POST reporting, stripp= ed down failure reports

4) clarifying prose=
    - implications of failure reports, define w= hat it means to have "implemented" DMARC

5)= general improvements
    - PSD, removing the PS= L and Org Domain definition from DMARC


None of these items are themselves requirements, s= ome may overstate their claims, other under, and others still are mutual= ly exclusive or depend on the resolution state of other items. The = only requirement is that every item in the tracker must be brought to th= e group for discussion.


To e= fficiently discuss as a WG and arrive at a rough consensus on each item,= the Chairs will use the following process for DMARCbis to tear through = open tracker items:

- We will have three ti= ckets from the datatracker open for discussion on the list at any given = time

- Each ticket will have a Chair respon= sible for shepherding discussion

- Once con= sensus is called on a ticket, that will be recorded in the tracker, and = a new ticket will be opened for discussion

= - This process is separate from editing the I-D (or I-Ds), which will oc= cur in parallel, but will not block this process

We'll be bringing the first three items to the list later this wee= k.

As MSK said in March, it will likely be = a long road to get this work ready for Standards Track and address all t= he open issues. We're looking forward to everyone's collaboration and pr= ogressing this work together..

Seth, as Cha= ir

--


Seth Blank | VP,= Standards and New Technologies
p: 415.273.8818



This email and all data transmitted with it contains confiden= tial and/or proprietary information intended solely for the use of indiv= idual(s) authorized to receive it. If you are not an intended and author= ized recipient you are hereby notified of any use, disclosure, copying o= r distribution of the information included in this transmission is prohi= bited and may be unlawful. Please immediately notify the sender by reply= ing to this email and then delete it from your system.

________________________= _______________________
dmarc mailing list
<= a href=3D"mailto:dmarc@ietf.org">dmarc@ietf.org


=
--77b629220a054cf2956763ff7f932608-- From nobody Mon May 11 06:55:10 2020 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 2EA823A0998; Mon, 11 May 2020 06:55:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158920530782.23655.6622928751672901506@ietfa.amsl.com> Date: Mon, 11 May 2020 06:55:07 -0700 Archived-At: Subject: [dmarc-ietf] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 13:55:08 -0000 The Domain-based Message Authentication, Reporting & Conformance (dmarc) Working Group will hold a virtual interim meeting on 2020-06-11 from 16:00 to 17:00 UTC. Agenda: Joint DMARC 2.0 Discussion (M3AAWG and IETF) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me6b9c2bdf971f0ead8713b4a9c50c975 From nobody Tue May 12 14:19:22 2020 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 47C453A0BF9 for ; Tue, 12 May 2020 14:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xEQi-JVF4CmE for ; Tue, 12 May 2020 14:19:19 -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 E919C3A0BF7 for ; Tue, 12 May 2020 14:19:19 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4300:2290:5113:a9dc:6efe:5be3]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 04CLJHRk009504 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 12 May 2020 14:19:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1589318359; bh=rKtIcw8l+Vo+fM92V3uLIAMvJo8/BNkliGiERzXquGc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mbDdGBGMrpgOlUzD0CUXHZVLkiz/cEGeNfjwvlV2VUHvW+xsPSEXQ4Bn46iHLE8av UYKjeYNwxhbsN4saFmKHxLHbWlvqw+9UVS9WiZ8rtoCmphpt/wwA6EFSvAMUTjJ0Pp sGdOJIcHpCxrydKabdKeyovJDxZgEcr4R/8f9NuU= To: dmarc@ietf.org References: <158920530782.23655.6622928751672901506@ietfa.amsl.com> From: Jim Fenton 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 AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 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++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <4bd34874-ea4d-1e72-40be-e3b1f44ef54e@bluepopcorn.net> Date: Tue, 12 May 2020 14:19:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <158920530782.23655.6622928751672901506@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:19:21 -0000 On 5/11/20 6:55 AM, IESG Secretary wrote: > The Domain-based Message Authentication, Reporting & Conformance (dmarc) Working Group will hold > a virtual interim meeting on 2020-06-11 from 16:00 to 17:00 UTC. > > Agenda: > Joint DMARC 2.0 Discussion (M3AAWG and IETF) Since this meeting is a joint discussion, I presume that it will be held under terms of the IETF Note Well rather than the more restrictive rules M3AAWG uses. Right? -Jim From nobody Tue May 12 14:24:43 2020 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 2E70A3A0A94 for ; Tue, 12 May 2020 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIQ1ODLs-syS for ; Tue, 12 May 2020 14:24:36 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 4B6AA3A0A84 for ; Tue, 12 May 2020 14:24:36 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id k133so19377533oih.12 for ; Tue, 12 May 2020 14:24:36 -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=SX9cUkFjruu5nNKBvXBiK4DTrvF3TJIGNzmcxLpXO7g=; b=velKiZUHYa0k32chsqb1kTcHVNTSh3XCd56gnp1NL6ozVOasrHIVhlltI72NoS8SaE N1hHT5f/O0/znrsGIsoAxrSGwkNSoHdY+eSWx1x8hu/WdOI2Japg0JZQ3FGiHQuvbX8r zbouphhP0Wf1lS1mSp/5MBT38DB7AnCIZTPWbRA3z7K3KsnuP1oKwEH+wgdQiB2KCleM rY1VHL4zRexqelYe8DZPxrp6pQqynszBiKfH68nIEzomd+TwhDGOl8GcyNVTdk3TyBhC ZgyLkZpyVDe3EEt4LU7sG9PpmyY5i08qAmdrRlAYCnff5G2+9tEQ/2Wh7/MbtZnpo0wH eu3Q== 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=SX9cUkFjruu5nNKBvXBiK4DTrvF3TJIGNzmcxLpXO7g=; b=qhZ9S4um/cDvEhBqnAQ/dlZp0twczyNIMTIjekOhWlQbfDjZ53iZKAacyySJ/qacfL yTUHa0ybmevwkmWQ+HHGQmDaedHSuEFt1WkrH2ZwwYhCx7hjXmm4k6ZYJUonoCMY//vQ vTzW0UcWnOieV4ok46oRscm/jkg5jga755IzCeWKUXOjcylN13XxebKpCQbF4w9Ltzj5 F8MFCIvfwxVqH3fSniG7AdJqpSBUukDvzF5/94khgux65RzboEqMKScTUEcEZoTkK06n eIO88BdsgOExFuBgB5aYMMKHs6lZ6w4g0Da9ai80//T2r4eXM9VNOdIaB7biRMbuEFq0 EwYA== X-Gm-Message-State: AGi0PuYwFMRZnDcPUheDHaM4okWh9NYmuyeJIF+VGeoF6m02TXLmvZ6S 4AKwaZxMjxqOZfU3FYNaA5e0LcdtPSAOk67KGFN4sbpF X-Google-Smtp-Source: APiQypJSP170eCmBj3QLP/UTH5OVGbWa6w2u/22O92mwhyXbp+46bIRwxyaR9kxnTwBvrpvjA5phIUEzgyYeqjLFhb0= X-Received: by 2002:aca:ac84:: with SMTP id v126mr25631852oie.132.1589318675432; Tue, 12 May 2020 14:24:35 -0700 (PDT) MIME-Version: 1.0 References: <158920530782.23655.6622928751672901506@ietfa.amsl.com> <4bd34874-ea4d-1e72-40be-e3b1f44ef54e@bluepopcorn.net> In-Reply-To: <4bd34874-ea4d-1e72-40be-e3b1f44ef54e@bluepopcorn.net> From: Tim Wicinski Date: Tue, 12 May 2020 17:24:24 -0400 Message-ID: To: Jim Fenton Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000015874d05a57a1720" Archived-At: Subject: Re: [dmarc-ietf] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:24:42 -0000 --00000000000015874d05a57a1720 Content-Type: text/plain; charset="UTF-8" Jim This part of the meeting will be under the IETF Note Well M3AAWG is holding a meeting in the previous hour which will be under the M3AAWG rules, with the idea of bringing forward useful discussion, etc. tim (Not being a M3AAWG member myself) On Tue, May 12, 2020 at 5:19 PM Jim Fenton wrote: > On 5/11/20 6:55 AM, IESG Secretary wrote: > > The Domain-based Message Authentication, Reporting & Conformance (dmarc) > Working Group will hold > > a virtual interim meeting on 2020-06-11 from 16:00 to 17:00 UTC. > > > > Agenda: > > Joint DMARC 2.0 Discussion (M3AAWG and IETF) > > Since this meeting is a joint discussion, I presume that it will be held > under terms of the IETF Note Well rather than the more restrictive rules > M3AAWG uses. Right? > > -Jim > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000015874d05a57a1720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jim
This part of the meeting will be under the IETF Note Well

M3AAWG is holding a = meeting in the previous hour which will=C2=A0
be under the M3AAWG rules, with the id= ea of bringing forward=C2=A0
useful discussion, etc.

tim
(Not being a M3AAWG member myself)



On Tue, May 12= , 2020 at 5:19 PM Jim Fenton <= fenton@bluepopcorn.net> wrote:
On 5/11/20 6:55 AM, IESG Secretary wrote:
> The Domain-based Message Authentication, Reporting & Conformance (= dmarc) Working Group will hold
> a virtual interim meeting on 2020-06-11 from 16:00 to 17:00 UTC.
>
> Agenda:
> Joint DMARC 2.0 Discussion (M3AAWG and IETF)

Since this meeting is a joint discussion, I presume that it will be held under terms of the IETF Note Well rather than the more restrictive rules M3AAWG uses. Right?

-Jim


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000015874d05a57a1720-- From nobody Fri May 15 11:26:40 2020 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 1D4C93A005B for ; Fri, 15 May 2020 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LJ8VYhmBnyh for ; Fri, 15 May 2020 11:26:37 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 E8FC23A003E for ; Fri, 15 May 2020 11:26:36 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id m12so3255488wmc.0 for ; Fri, 15 May 2020 11:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=ZOh4fXQhoRmAfBJOkAGwXse1O139g8fXuLeN5cyjaNY=; b=YvLkl9QOXUd37gmAE8OziXFIlcMlJ7r+B2+k2NCVN40nCuuMIB/fxKxzHkcRtANmkv c0QMaVb1roD3ZPgJHKIlsE/ofjZOl2bRk9R3ElnF7a7ggyVT9eYfrf4hb/xufrXLJqtl F2WiieYrSm90+1vqyNJUeMC1UR9UJwgAuWOKmPhZk/BLSMWeq0F9mPwgW2rLEaU4D/3B L//JpkNzENU9N+wu5nFg+2ntT1flfnfeRW7dtALiHEKCTtICjoQ+bCbthkHqpI/FQ0FB qoTTvAf7T2Xq7pCxb3BdaCzqYE/aoceG3wh1RBesJYMngGxs3iaWxaxZqU0FORbbJDfl vsow== 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=ZOh4fXQhoRmAfBJOkAGwXse1O139g8fXuLeN5cyjaNY=; b=joz1ZYEjn/OeTtBACS+bf3ifWpSMGxMR1Zkr0QxGedEKtmliNF6Mj7jjl56B47HhRi d3pegJjZjntqwuoXz9yuQ86vsuCnX4dKP1kv0iMdN37U5JDKaO7KHaZPzkx9k+ywF/YZ yS2d4x5B8woDTM9H8XzxehB3cgEGQemGoTfxECyg9M4D8sWRDlCLccV5i0e/OY0EXtDT KUfdIBeT3zA6bBNOmdEnW5kD/xePMXQ/oi3F7Vbi/9ifl65rADRmdHJPGgbClPFQ4pp6 9wARu3Se0vaz4qe+x8ObU0lN5OIpj4oI4E+9Le8BbAuS1b7gbWVqpwnVlD+bXTNdEcSk DUQA== X-Gm-Message-State: AOAM531bDmXzrhDh0T8X8jDt8BtyuQrfPzOdRx8/BCbgTE+tG/T+T4A4 Tic7eOGSQsZtYsblDyrZvt9AI4Rof0miSKzzCuLUN78fRyg= X-Google-Smtp-Source: ABdhPJx0/HWb7oERymzbtwREozBS+weHvH0ll23brRiQb8cr5D/3QG+1n4rdOHf2IVdiFnWS2AksKbXSWbz52GI5MTc= X-Received: by 2002:a1c:6706:: with SMTP id b6mr5055048wmc.54.1589567194862; Fri, 15 May 2020 11:26:34 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Fri, 15 May 2020 11:26:24 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ff37ae05a5b3f309" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 15 May 2020 18:26:39 -0000 --000000000000ff37ae05a5b3f309 Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/63 A published DMARC record that consists solely of "v=DMARC1; p=none" is syntactically valid, but is semantically equivalent to having no record at all. >From an ecosystem perspective, especially in Europe, data has been shared showing an increasing number of domains putting in bare p=none records, and then claiming that they are implementing DMARC and have some layer of protection against spoofing of their domain. Explicitly making this case invalid would remove confusion from the ecosystem, and allow any checker that is up to spec to properly flag a bare p=none record as being the same as not having a record at all. Should we make it invalid to have p=none without a reporting address? -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ff37ae05a5b3f309 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://trac.ietf.org/trac/dmarc/ticket/63

A published = DMARC record that consists solely of "v=3DDMARC1; p=3Dnone" is sy= ntactically valid, but is semantically equivalent to having no record at al= l.

From an ecosystem perspective, especially in Eu= rope, data has been shared showing an increasing number of domains putting = in bare p=3Dnone records, and then claiming that they are implementing DMAR= C and have some layer of protection against spoofing of their domain.
=

Explicitly making this case invalid would remove confus= ion from the ecosystem, and allow any checker that is up to spec to properl= y flag a bare p=3Dnone record as being the same as not having a record at a= ll.

Should we make it invalid to have p=3Dnone wit= hout a reporting address?

--

<= div style=3D"text-align:left">Seth Blank<= span style=3D"vertical-align:baseline;white-space:pre-wrap;font-size:small;= font-family:Arial"> | VP, Standards and New Technologies
p: 415.273.8818 <= span>



This email and all data transmitted with it cont= ains confidential and/or proprietary information intended solely for the us= e of individual(s) authorized to receive it. If you are not an intended and= authorized recipient you are hereby notified of any use, disclosure, copyi= ng or distribution of the information included in this transmission is proh= ibited and may be unlawful. Please immediately notify the sender by replyin= g to this email and then delete it from your system.

--000000000000ff37ae05a5b3f309-- From nobody Fri May 15 11:26:54 2020 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 305683A0064 for ; Fri, 15 May 2020 11:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5Ba4MLPCGbh for ; Fri, 15 May 2020 11:26:43 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 3F7293A03F6 for ; Fri, 15 May 2020 11:26:43 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id k13so2525881wrx.3 for ; Fri, 15 May 2020 11:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=jjyvPrppP/u4g5G3Rb1u4V9HpEdSOzR9y4pvYdiMwuM=; b=KsZgMfeBbp+SOcEd9v8rqBfLgDi4qga9PqyKonLjMA9fMFpFRJoSpDwpSzHpXzzYLd Hky/j8wYD37Jl3zi+ChptirIrXAZei4omwcZekDUzkVYZBraq8wRv+bTgJOBCZY20bYQ 2YyeDjrRQl9i2P9l/Nblof2oRSc/lF058rpeQ/omnIL20eRf3sRCqfH/wgKYmKBCBg60 OEfh1ybuqwauTNZqjd6ckCP+nQ85hxt3kotyL/YHEGk7Z3g2ehz5kddgAOwBe9REXbsb iMQXYDOTjSYWpdkI5mSKfs4IqykTuRV8PLIlobddckW9LmH01HauuCJK+DHSa0wWOezZ OV+A== 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=jjyvPrppP/u4g5G3Rb1u4V9HpEdSOzR9y4pvYdiMwuM=; b=SOspjicGag1Q5GKmFOAUgnDT0SMU8MuC6JLPaWIdvFYmjgaIEiOI7DVvdHmu6IfWBn /XBGh/RBW6cK930zzskEs9oV2Nz4diua+AzkAnTrt83eoYwNBUlmt/Yz5ciVV154E+kd 9vC2eAc+ZTJt5/37aNhZyZsPaKYPSCH6hBPEcSeQBSyR0z1Je2IfXFfc2QbBZoZJlUL6 xl6PeMk3MmWjHHuxXyRzF5dn2HESph0LTrnwoJn6uXq03b06DLrx2Z2zKI07kE0Vijv4 GEh9JAcfJIofnk4J4FtisPZajWXuUfjrn881lvMIN7YtGnm3r40OD+iUjDIoYy/gBShf wH7w== X-Gm-Message-State: AOAM532G5c7D5e1v6HpRNFc012obe4i/+DUqDrYMFUE657fpwNJt+3aw TZ+7UzbhCe3qxN1GKlGxTG8slP6RHKFrRbtslXAtFaUFNEU= X-Google-Smtp-Source: ABdhPJy6JVls3ek3WOtkYe47NXmkiPstCTb8mWpry1UlxpLs+Ohq11Ns3JHe8laxvgvPcgaFM5t9rUGi18jghiU/xU0= X-Received: by 2002:a5d:46cf:: with SMTP id g15mr6044088wrs.276.1589567201340; Fri, 15 May 2020 11:26:41 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Fri, 15 May 2020 11:26:30 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000062077d05a5b3f42d" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 15 May 2020 18:26:52 -0000 --00000000000062077d05a5b3f42d Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/49 The penultimate paragraph of https://tools.ietf.org/html/rfc7489#section-6.3 states: the "v" and "p" tags MUST be present and MUST appear in that order. While the v= tag pretty universally appears first, the p= tag does not in many records, and no implementation appears to care. The v= tag must appear first, or the policy discovery mechanism as defined in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break. But there doesn't appear to be any real reason to keep the normative requirement that the p= tag MUST be second in the record after the v= tag, nor does this requirement seem to have any impact on interoperability or general record parsing in theory or in practice. Should we remove this normative requirement? -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000062077d05a5b3f42d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

the "v" and "p" = tags MUST be present and MUST
=C2=A0 =C2=A0appear in that order.

While the v=3D tag pretty universally appears first, the = p=3D tag does not in many records, and no implementation appears to care.

The v=3D tag must appear first, or the policy disco= very mechanism as defined in=C2=A0https://tools.ietf.org/html/rfc7489#section-6.6.3= =C2=A0would break.

But there doesn't appear to= be any real reason to keep the normative requirement that the p=3D tag MUS= T be second in the record after the v=3D tag, nor does this requirement see= m to have any impact on interoperability or general record parsing in theor= y or in practice.

Should we remove thi= s normative requirement?

--

Seth Blank | VP, Standards and New Technologies
e: seth@valimail.com
p: 415.273.8818 <= /span>


<= p dir=3D"ltr" style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans= -serif;font-size:small;background-color:rgb(255,255,255);line-height:1.38;m= argin-top:0pt;margin-bottom:0pt">

= This email and all data transmitted with it contains c= onfidential and/or proprietary information intended solely for the use of i= ndividual(s) authorized to receive it. If you are not an intended and autho= rized recipient you are hereby notified of any use, disclosure, copying or = distribution of the information included in this transmission is prohibited= and may be unlawful. Please immediately notify the sender by replying to t= his email and then delete it from your system.

--00000000000062077d05a5b3f42d-- From nobody Fri May 15 11:27:03 2020 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 578DE3A041E for ; Fri, 15 May 2020 11:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZmVCjJscV88 for ; Fri, 15 May 2020 11:26:44 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 88EE03A0366 for ; Fri, 15 May 2020 11:26:44 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id w64so3644198wmg.4 for ; Fri, 15 May 2020 11:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=47xXc8qBVVy8ondlndw6PvvjLnFAjP8EHyd8mkRMBkg=; b=aeZ7qwMXkHj8NI7/O68FmciQrx9QmsuUWGy7D5VfmvZC6j6iMAHiAXCBeGOheb+zX4 8T4gFKbYkpR3VXgUpMztxwsUFo35YuR5rv9XZxU7/z+gkWXMPV922xtL2kDEQ/DJPxSz FdkqnOBKpi3dhRJ7KFoN9FKoRV/tkMeeXWLpwysxsFKJq2hDKvOErzJXuCsPWEWZm3RI OMNJxchcQEiuHYSY7Cf/HOGTujhYVn0Ztnoi125OMi4OT6bbLMLsnhm7k85H5eFtkHCg 6rAKGEwyX75bF8f53zmNwV+Lq4iOk4Ioo9ak0zGAARCB5R6DxqdzT5uW37pa3ypT8k/r v7dg== 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=47xXc8qBVVy8ondlndw6PvvjLnFAjP8EHyd8mkRMBkg=; b=mfsiFsQ7J+DEcaigl6I72I/tBUkqCHMWpouAMH0rCKOeBh3mnCAC0piQRakENnYoMl Z1aZvh/6qFFtY6BV96kfcWxuOWqL/7FB4IQl95VLmBWEE15yyjNBPnudN0oXHMykoCZs kXAz/1T3DgF/K8Ot+MnZxiQYciUiTIP65vD8VMbD1z77pcjVjh8+h0lbuvIVy1/FWItC Sc+Ua3krk45xp4dFdk/ZC9JcWZwSgIv01ppsYjrGaID8Ki6AJ8NfGI9/Jk2Cn4rCiCAJ /r3g+mQmY7otVpookscACuOjdapmMctNr6c8KP4x4SCRxNhnnTMoYv7qdZPNq2UJnzdD E4ig== X-Gm-Message-State: AOAM533vQQzQKeijR8pkOA2uVWyILAOJf20WCY31LjWiZnpq1hMlSOyh HH38w8TKiN4jMZsPSxFeIKY+aywfGLg/1WMDHHjIX7BXHcI= X-Google-Smtp-Source: ABdhPJwRYeUr6nZc6EtGkrFPtG8+IikrlydA/C7mdWtLOYkHEPNz9I83ZOVEEfrJdEZ7zDaJFIPOPag9EnzxXRk7Pa8= X-Received: by 2002:a1c:9e45:: with SMTP id h66mr5328505wme.106.1589567202710; Fri, 15 May 2020 11:26:42 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Fri, 15 May 2020 11:26:32 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000076f01c05a5b3f45e" Archived-At: Subject: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 15 May 2020 18:26:53 -0000 --00000000000076f01c05a5b3f45e Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/69 Aggregate reports are only sent in XML format. There's been some discussion (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting functionality beyond mailto:), of adding additional reporting formats, specifically JSON. Should we consider adding JSON formatting to DMARC? -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000076f01c05a5b3f45e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://trac.ietf.org/trac/dmarc/ticket/69

Aggregate reports are only sent in XML format. There's been some = discussion (that's also related to=C2=A0https://trac.ietf.org/trac/dmarc/ticket/42=C2= =A0about expanding reporting functionality beyond mailto:), of adding addit= ional reporting formats, specifically JSON.

Should= we consider adding JSON formatting to DMARC?

--

Seth Blan= k | VP, Standards and New Technologies
p: 415.273.8= 818



This email and all data transmitted = with it contains confidential and/or proprietary information intended solel= y for the use of individual(s) authorized to receive it. If you are not an = intended and authorized recipient you are hereby notified of any use, discl= osure, copying or distribution of the information included in this transmis= sion is prohibited and may be unlawful. Please immediately notify the sende= r by replying to this email and then delete it from your system.

--00000000000076f01c05a5b3f45e-- From nobody Fri May 15 13:02:53 2020 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 A05363A08B6 for ; Fri, 15 May 2020 13:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_FAIL=0.001, 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=nI8ekWE8; dkim=pass (2048-bit key) header.d=kitterman.com header.b=APN59O6w 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 2MF8Jq-CYkhz for ; Fri, 15 May 2020 13:02:48 -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 915EE3A0840 for ; Fri, 15 May 2020 13:02:48 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 869C6F80331 for ; Fri, 15 May 2020 16:02:46 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589572966; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=rOheDfu5uKyUOR3sdAoOJZxiderA+OntsYEZDdX07EA=; b=nI8ekWE87OFeZlZyMvl+cynJXd3YFq+xfA/pDO0zl89qEQyBCo2IGWw9BxAX3gRnUIeH1 GIwWwxpFA62sEVoDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589572966; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=rOheDfu5uKyUOR3sdAoOJZxiderA+OntsYEZDdX07EA=; b=APN59O6wAFqt26wiEk98KkY3HGF9TOYKLiDrisNgcKRU0kyZB41poF76BqOrmMQDVdXiT JiFevqgq8gvAoA3fY9FqTSjDU/VmsPW4oMm9b24+tD1N9tTCq41i3b30Uyf+MxRkDAQSNSh 2qDaTzup5L+UUixHuAOweqog4VmMY3ex8Q5jFJPzDo2v1OUdOFmPP4ZTabsYHX+ZwkueZbZ efJPukT3psUGWjyHIkbKBh2D7wj/XIbsp+yr55i4pzMk+/lNOsp0oJYRGuy05DkauH3cfji 3hpOnLcdAyHGOL/8zmcBhPTkGTkdSNFaLCEScHNMJRECDLyLAR8b4fv2AbWw== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 5983EF80120 for ; Fri, 15 May 2020 16:02:46 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 15 May 2020 16:02:46 -0400 Message-ID: <3457203.qin9KRflZP@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 15 May 2020 20:02:51 -0000 On Friday, May 15, 2020 2:26:24 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/63 > > A published DMARC record that consists solely of "v=DMARC1; p=none" is > syntactically valid, but is semantically equivalent to having no record at > all. > > >From an ecosystem perspective, especially in Europe, data has been shared > > showing an increasing number of domains putting in bare p=none records, and > then claiming that they are implementing DMARC and have some layer of > protection against spoofing of their domain. > > Explicitly making this case invalid would remove confusion from the > ecosystem, and allow any checker that is up to spec to properly flag a bare > p=none record as being the same as not having a record at all. > > Should we make it invalid to have p=none without a reporting address? I'll bite: No. This is unrelated to interoperability and unlikely to actually improve anything (this reminds me of the occasional suggestions to make v=spf1 +all special for SPF records). Let's imagine a world where a domain that wants to claim they do DMARC in accordance with the latest RFC 7489bis takes their "v=DMARC1; p=none" record and adds an RUA reporting address to it to comply. Then they never set up the email address and the RUA reports all bounce. It's compliant, right? So then people demand a fix to require the address to be accept mail. We spend two years doing that and then that same domain starts accepting mail to the RUA address, but they route it to /dev/null. Then people complain about the waste of bandwidth associated with sending reports that get thrown away... There's really no end to this. Let's not start down the path. Scott K From nobody Fri May 15 13:09:19 2020 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 5DB163A08E3 for ; Fri, 15 May 2020 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=dY06CZnr; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NxVxdiD4 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 6s2z1aGBoA-n for ; Fri, 15 May 2020 13:09:07 -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 B1DA73A0932 for ; Fri, 15 May 2020 13:09:07 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CD0D3F80331 for ; Fri, 15 May 2020 16:09:06 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589573346; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/MH1wuFHvuLzZsHOekJJUA7ghakPrfsQaqFfZau4dNg=; b=dY06CZnrnKCHZJrIsUfUsV/PFQOY7dYeid63CmN05vYpvzGpc7CmP+O6jEpJjZoglhUZG YpFNCkwKUa/t3tVCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589573346; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/MH1wuFHvuLzZsHOekJJUA7ghakPrfsQaqFfZau4dNg=; b=NxVxdiD4I1wZb9TtdUFIPwXX8RS5lWf6hMXrUT05aj/eG47WpOwOwPW23/4/kqkC/atO2 ukNQvGD6RqlM52pnf6SoZepohLXVJqgQSO+IsdIPFXJswNl5y+1/udKIJXUG0gVQe58Nwlk 7eLeNGadYm17V78LguSJt3BhZzx2gX2VSKRhO3F9bdBEx8tX6zRK18NcY3ZKJTdV7JmKOd0 LfGwQGdJrz7bsJvN3RX++6xs/0rI+zHzqhyA3r/ZGEwoLUmwalLsirT4apsfqzpDls+nm49 2a7YmZQIhI+/XziZYZg7HfKp2qf/69AT/SoMRLMEzCUAvks8mayVl2SDoIMw== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 9236FF80120 for ; Fri, 15 May 2020 16:09:06 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 15 May 2020 16:09:06 -0400 Message-ID: <5977449.Cccs3KlKfv@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 15 May 2020 20:09:17 -0000 On Friday, May 15, 2020 2:26:30 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/49 > > The penultimate paragraph of https://tools.ietf.org/html/rfc7489#section-6.3 > states: > > the "v" and "p" tags MUST be present and MUST > appear in that order. > > While the v= tag pretty universally appears first, the p= tag does not in > many records, and no implementation appears to care. > > The v= tag must appear first, or the policy discovery mechanism as defined > in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break. > > But there doesn't appear to be any real reason to keep the normative > requirement that the p= tag MUST be second in the record after the v= tag, > nor does this requirement seem to have any impact on interoperability or > general record parsing in theory or in practice. > > Should we remove this normative requirement? Section 6.6.3, step 6, sub-step 1 already says: > 1. if a "rua" tag is present and contains at least one > syntactically valid reporting URI, the Mail Receiver SHOULD > act as if a record containing a valid "v" tag and "p=none" > was retrieved, and continue processing; I don't see a problem with changing the MUST for p= to SHOULD and adding a MUST p= or rua=. That's consistent with what we already tell receivers they SHOULD do. Scott K From nobody Fri May 15 13:16:24 2020 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 D5DC73A08ED for ; Fri, 15 May 2020 13:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, 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=FnAhXipF; dkim=pass (2048-bit key) header.d=kitterman.com header.b=q5/5IaFT 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 3AIvCBZJ3oV2 for ; Fri, 15 May 2020 13:16:20 -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 BAA373A08E3 for ; Fri, 15 May 2020 13:16:20 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id D5CF2F80331 for ; Fri, 15 May 2020 16:16:19 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589573779; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sxAPulxHj/Kh93av3FODH+Vonrc3pNNgRrvFFsPKTm8=; b=FnAhXipFmEq2LLZxIQ1Nypa26Lt/KX1dvJ03UkfuL1kqJWQZzFVIBxgRukKBpaB4cvYkK lwd4ns9oXQF9CT3Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589573779; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sxAPulxHj/Kh93av3FODH+Vonrc3pNNgRrvFFsPKTm8=; b=q5/5IaFTQguxTZFR5vu6KqMOp9GuZ+H8LvtXOBDggO6OG0AWHAb9Dq3y9cdZtZ7aIDgQs LlZhvIYzn8BXl+x6onSTb2L3m6wJdbZ5ft3T5maFS1EFOxrT4jPF2JTISRs5+QqiS0kyVuz 5C/QxaqZqXucPCSi6vWY6c3rrYF5MHV6MHFueNT+60mbpEhc9m3Lth5+VjOeCS1t+5EMQDn B1tiG9OOfOSZve6Hmuo/PKQIlH0SUYalAPGa1hYIPUf+2sPuP7+OQw8KWBe75N1rtl0MaMf sRBvge1FztgvdTsLEhI5j+NJhTCH9Q/YzGWo021+FDmlWpy3NQcyP5ONSsYg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id A810FF80120 for ; Fri, 15 May 2020 16:16:19 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 15 May 2020 16:16:19 -0400 Message-ID: <3193525.cVJkX3U5sK@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 15 May 2020 20:16:24 -0000 On Friday, May 15, 2020 2:26:32 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/69 > > Aggregate reports are only sent in XML format. There's been some discussion > (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about > expanding reporting functionality beyond mailto:), of adding additional > reporting formats, specifically JSON. > > Should we consider adding JSON formatting to DMARC? When there is only one report format, there's no need to discover a common format between report senders and report receivers. As soon as there are two, then to be interoperable, then either both report formats are required or there has to be some kind of discovery mechanism, because we don't want report senders sending reports in a format the receiver can't parse. Each report format has to have a defined structure so that receivers can consistently parse them. Maintaining two report formats represents additional complexity and increased work to be done. If this were a green field effort and we were trying to decide on a report format, I would probably think JSON was a great choice, but it's not. Trying to support multiple formats is going to be a lot of work for little to no real gain. I'd suggest no. Scott K From nobody Fri May 15 15:08:32 2020 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 0F0593A09EC for ; Fri, 15 May 2020 15:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJSpvoYtjT3K for ; Fri, 15 May 2020 15:08:28 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 737683A09EB for ; Fri, 15 May 2020 15:08:28 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id o26so2163931vsr.10 for ; Fri, 15 May 2020 15:08:28 -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=YGCPJai21q610w62ZxqFyVo4AMrip5IVviwIVpAOyDc=; b=ISC3c8bcTwRWVh+gw4/7E4t+ZkL5nC1HXJAMUQn7PA2Rc7nh1QkC8Pwb8lJGOn+Joj 4T8HFB2avWPFn+p1w3VN7j6d14qtcdL0gVRA+YgI5IsXJwQeowMxVne/VReDjEkaRDVE edIzLMN5nrzUYdRQTPd5qlnH+L3xMM+Jg959xrvD0ic//y4hZiscI+k9oSjwNRWvxspT m1L0PuFOwRC5kczDvmsZJNvcsSd3AkcXTIwSL/LyCK66pgYgK8mpEQtmxoC3ca1OP8Ul 1Y9uqpu2DZKNZsKXWRjwE+uTpWTFwv8ClQrk+uXb7SXHz3a2pQBjMgECfnrabMIJTxi2 p7gQ== 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=YGCPJai21q610w62ZxqFyVo4AMrip5IVviwIVpAOyDc=; b=L9VVVBqJGjPhJq6rF6DRzlgFDR798qf6KIpsnVOhULEcUxVUb3qwoog6a6SFm3qq4U JpULr7zy2pZRpgWT6ktxYnIg0qX7NDdW8mGD9NjIHEGJEJrhEgbfQbwvXGqbZm5iUo01 wA/NywzSjylnsq9738SjkxlFstN/xw4vvZt09DhER99cxQZ8p6uM42giqZ0nPOPOi6ZC CFRWAYPvLDkBJpqjpbZYuHM6SR/I0a/8kKm1zXjGZbBco/lOBxFfZUwiBaCRPM1I42ZQ 7PyiIGcVe2dF5KB0liDX1CGAmsqjKUiOv7gT6YPHMv28uhCAbLdXkmwQLVt4NYntBytZ wLmQ== X-Gm-Message-State: AOAM530WTDOVWzy41vjKu4sI9w12gdr8snsqlBdMiAKAIWC/UTllwYKM DxJimOMNeCtz++ZuCwse3bbhp9Ytn08GpPrRPZ1ht9lE X-Google-Smtp-Source: ABdhPJyJYjZ5rDwK2R1DcyuBnLo/siQS48ZpdY/iXF2rl7PmvDSsv3eGgbVATAYX8tfZOnXv14Sg0iInlGnIDHnp1Qk= X-Received: by 2002:a67:f7c9:: with SMTP id a9mr4366792vsp.7.1589580507269; Fri, 15 May 2020 15:08:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Fri, 15 May 2020 15:08:15 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007a502505a5b70dfc" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 15 May 2020 22:08:30 -0000 --0000000000007a502505a5b70dfc Content-Type: text/plain; charset="UTF-8" On Fri, May 15, 2020 at 11:27 AM Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/49 > > The penultimate paragraph of > https://tools.ietf.org/html/rfc7489#section-6.3 states: > > the "v" and "p" tags MUST be present and MUST > appear in that order. > > While the v= tag pretty universally appears first, the p= tag does not in > many records, and no implementation appears to care. > > The v= tag must appear first, or the policy discovery mechanism as defined > in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break. > > But there doesn't appear to be any real reason to keep the normative > requirement that the p= tag MUST be second in the record after the v= tag, > nor does this requirement seem to have any impact on interoperability or > general record parsing in theory or in practice. > > Should we remove this normative requirement? > It's been a while since the original discussion, but I can't remember why the requirement is there in the first place. The only benefit I can think of is that having "v=" first lets you decide very quickly if you care to continue, but the savings is really pretty small. -MSK, devoid of hat --0000000000007a502505a5b70dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2020 at 11:27 AM Seth Bla= nk <seth=3D40valimail.c= om@dmarc.ietf.org> wrote:

The penu= ltimate paragraph of=C2=A0https://tools.ietf.org/html/rfc7489#section-6.= 3=C2=A0states:

the "v" and "p&q= uot; tags MUST be present and MUST
=C2=A0 =C2=A0appear in that order.

While the v=3D tag pretty universally appears first,= the p=3D tag does not in many records, and no implementation appears to ca= re.

The v=3D tag must appear first, or the policy = discovery mechanism as defined in=C2=A0https://tools.ietf.org/html/rfc= 7489#section-6.6.3=C2=A0would break.

But there= doesn't appear to be any real reason to keep the normative requirement= that the p=3D tag MUST be second in the record after the v=3D tag, nor doe= s this requirement seem to have any impact on interoperability or general r= ecord parsing in theory or in practice.

Should we remove this normative requirement?

It's been a while since the original discussion, = but I can't remember why the requirement is there in the first place.= =C2=A0 The only benefit I can think of is that having "v=3D" firs= t lets you decide very quickly if you care to continue, but the savings is = really pretty small.

-MSK, devoid of hat
=


--0000000000007a502505a5b70dfc-- From nobody Fri May 15 15:10:36 2020 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 99B9D3A0A83 for ; Fri, 15 May 2020 15:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xMVCLo4dO4cQ for ; Fri, 15 May 2020 15:10:27 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 40B8D3A0A52 for ; Fri, 15 May 2020 15:10:27 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id z1so2153398vsn.11 for ; Fri, 15 May 2020 15:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=df/scrsMdqkMOBlEc8nvAlfqAGs1SPc9L8oIyFqt0M0=; b=JaqVWRhddPP+3LxNLeUSGdFrcou11+WpEdZfEx9CxE3V89vZiNqkvOmlw/xwj2od45 DEUaEBW8MQ7k00D5H4ZefzlxXk5vNx4rws30nFA0tF7ZxkLktzVTPOY3D6nbubOSTH5E NPr15Jm5Xbw6hPgDZdSBY2GR81ZEbBvqq9rgM3tdDvKKsVkxqRG1Cbut681a4F0AGONs pHAJVGW5vaJ9wcWcapfSqJ7Wfmn/MppSTq/lA8zXletOLkdXQOV1Yj0Ip6YSaR3YcXqt bWRP/zA7O9GdrPoHdzPbiKSd3+24j9w11ED8Eom4XmsojLyugiNumLjq3BCPfMxxqgXK LjJg== 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=df/scrsMdqkMOBlEc8nvAlfqAGs1SPc9L8oIyFqt0M0=; b=h7fis+MOLgceCM2etJoo3SmU9m3bM86zD73qsxUL0vOYdyOyLfiZ6EawjZ6/eAGYRY 2iFGmEzLEk6RHH6TDRnaAop+QtfbDCN3ybfmZ4QkA2TvE6KdyDRSqNEcT8KLUJhyaS4S k1luFkUA1Wb6zHQ1tpzGpD0JNUb/oY4ivd9dbmwQJ+9mRLnQKzTkaF0nffsVmbdbz3fu ktd1FsftMeTyTBr1gWqwCFc/TujnlTea/icvVRirD8IcI3JbsfKYg+eRwJ+0UxPwwho1 fkVnuExvUMIxdjQJOvOViJtokn2HIQ+niW6xAAhVCHMQL1PgI9Q67ypPaXJS626xkMHK 3DaA== X-Gm-Message-State: AOAM533jUJRAoeCwss7b7h9QeogSarelgEqF1+ByBAqlwB923Ofs1X0O 4jgEyR8DUkCrAJy08gdTt/k3QQAVj4CUhqm1fgANZRM2 X-Google-Smtp-Source: ABdhPJwFIa543/b+C4fDAqUmmIGYnsM1ptDMmQfkIJnAXA+4Tu4cJ9KepriLQqc4wQnzMUyfKy5WMTocsTkvKhPzH+U= X-Received: by 2002:a67:2d17:: with SMTP id t23mr4379515vst.52.1589580626137; Fri, 15 May 2020 15:10:26 -0700 (PDT) MIME-Version: 1.0 References: <3193525.cVJkX3U5sK@sk-desktop> In-Reply-To: <3193525.cVJkX3U5sK@sk-desktop> From: "Murray S. Kucherawy" Date: Fri, 15 May 2020 15:09:57 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009018e405a5b714c5" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 15 May 2020 22:10:35 -0000 --0000000000009018e405a5b714c5 Content-Type: text/plain; charset="UTF-8" On Fri, May 15, 2020 at 1:16 PM Scott Kitterman wrote: > If this were a green field effort and we were trying to decide on a report > format, I would probably think JSON was a great choice, but it's not. > Trying > to support multiple formats is going to be a lot of work for little to no > real > gain. > > I'd suggest no. > +1, unless there are known cases where the XML payload size is a problem that switching to JSON would solve. -MSK, once again devoid of hat --0000000000009018e405a5b714c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 21, 2020 at 5:12 PM Scott Kitterman <sklist@kitterman.com> wrote:
Agreed.=C2=A0 I don't think = this is controversial.

Also, I don't see a problem with making the p=3D tag optional (with an = inferred
value of None if not present).=C2=A0 This is consistent with an existing SH= OULD in
RFC 7489 and appears to be broadly supported in existing implementations.
I'd propose we close this ticket with the following resolution:

The requirement that the v=3DDMARC1 tag be first will be retained.

The requirement that the p=3D tag be second and the requirement that the p= =3D tag
is mandatory will be dropped.=C2=A0 If the p=3D tag is not present, the imp= lied
policy value is None.

Scott K

On Thursday, May 21, 2020 4:54:55 PM EDT Tim Wicinski wrote:
> (With no hats)
>
> I agree with John the v=3DDMARC1; is magic and MUST be first.=C2=A0 Ev= erything
> else can show up wherever.
>
> tim
>
> On Fri, May 15, 2020 at 9:09 PM John Levine <johnl@taugh.com> wrote:
> > In article <CAL0qLwa-iuyB_iNQU+g6e3NH1+q0W413RaCZcHp=3D=3D
> > s9C= QA7s1g@mail.gmail.com>,
> >
> > Murray S. Kucherawy=C2=A0 <superuser@gmail.com> wrote:
> > >It's been a while since the original discussion, but I ca= n't remember why
> > >the requirement is there in the first place.=C2=A0 The only b= enefit I can
> > >think
> > >of is that having "v=3D" first lets you decide very= quickly if you care to
> > >continue, but the savings is really pretty small.
> >
> > The v=3DDMARC1; is a magic number that tells you whether it's= worth decoding
> > the
> > rest of the record.=C2=A0 People put a lot of junk at tops of the= ir zones, some
> > of which is in k=3Dv format and I would prefer not to try to deco= de records
> > full
> > of junk to see of a v=3D tag is in there somewhere.
> >
> > Other than that I agree there is no reason to specify the order o= f
> > tags.
> >
> > --
> > Regards,
> > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for
> > Dummies",
> > Please consider the environment before reading this e-mail. https://jl.ly=
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/dmarc=




_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Todd Herr | Sr. Technical P= rogram Manager
= p:


This email and= all data transmitted with it contains confidential and/or proprietary info= rmation intended solely for the use of individual(s) authorized to receive = it. If you are not an intended and authorized recipient you are hereby noti= fied of any use, disclosure, copying or distribution of the information inc= luded in this transmission is prohibited and may be unlawful. Please immedi= ately notify the sender by replying to this email and then delete it from y= our system.

--000000000000ee184505a6303326-- From nobody Thu May 21 15:50:23 2020 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 EFD7D3A0C7B for ; Thu, 21 May 2020 15:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=crash.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 w3mOM1VwbXHS for ; Thu, 21 May 2020 15:50:19 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 462673A0C64 for ; Thu, 21 May 2020 15:50:19 -0700 (PDT) Received: from [10.10.10.41] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 04LMo1Zj061449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 21 May 2020 22:50:18 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 04LMo1Zj061449 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1590101419; bh=SLRPbRgHc1EhvekN1iLmaF2atyycp7mSD33ZH3Lu2CA=; h=Subject:To:References:From:Date:In-Reply-To; b=Eeb1D2V5//MB/1G9BeMRVXXb6z/aSQCNEbrQV5QBKbGnHG8IzK9ONOqNxTx0phhB0 wj6mB7ZG70m3eYONBVsaJP0PpaxTPvlTETSPsVZ95XMd59hTe4qMC6P98u1q2NLlRO atuw3sB/lRPwdEh3RozcpL4hFDSMkiw03RKX+kVNw9l8U40WHtvqF8K3w9H43ttyN3 onasn35xLn4fDspIe9fxbWp66kPZM+1FMxPrVa/IdCA2M4KojzCJNd/Jz46wYs4OlK ABdvz76SyFoEk2bROWUKL2Snt5LmzzByupMZB/DlNxpeqr2+/1gt6jTBJ0Z1dGCtvW HAfte2gdSrslQ== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.41] To: dmarc@ietf.org References: <1784228.uJLO1Brz0r@localhost> From: Steven M Jones Organization: Crash Computing Message-ID: <304cc008-5270-8a07-1462-2ee42651e9df@crash.com> Date: Thu, 21 May 2020 15:50:01 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1784228.uJLO1Brz0r@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Thu, 21 May 2020 22:50:18 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 22:50:21 -0000 On 05/21/2020 14:11, Scott Kitterman wrote: > Also, I don't see a problem with making the p= tag optional (with an inferred > value of None if not present). This is consistent with an existing SHOULD in > RFC 7489 and appears to be broadly supported in existing implementations. Wow, did I miss/forget this proposal earlier in this thread? IMO this change should not be buried as a side-discussion, it should have it's own ticket (assuming it doesn't already) to raise visibility and record a proper discussion/decision. --S. From nobody Thu May 21 15:50:44 2020 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 B6D4C3A0C64 for ; Thu, 21 May 2020 15:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 1q2-qoqUXfDY for ; Thu, 21 May 2020 15:50:40 -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 3D48C3A0D21 for ; Thu, 21 May 2020 15:50:39 -0700 (PDT) Received: (qmail 72927 invoked from network); 21 May 2020 22:50:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11cdc.5ec705be.k2005; i=johnl-iecc.com@submit.iecc.com; bh=HE0UCb5+/I1QoSJAjsLiWp5+2LDQFX+go4dELnmx54U=; b=uP5iM/X/H4E/a6p4u80TVIB5oMScGvF7gFh4JuoVz92SbxTXp+P303HVUeGdBpPu888LgypCBm6Eka3CqU0or1BNd6wTqZzmlsPUGd1CCxuQYVBSKhr0QilDoCX5AAv5ZgFvHbhJMsCDXnKXopNovS+icavpqMtX7MGm0bzze8fhwtsJcE8pfJTBqJPoi29NCYwY1HD/RJ2PEy8H46MxGq4sjLV71Iyo0f9AY5iz3I3YgLF/3BCtcfIZUEh+eVYl 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.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 May 2020 22:50:37 -0000 Date: 21 May 2020 18:50:37 -0400 Message-ID: From: "John R. Levine" To: "Todd Herr" , dmarc@ietf.org In-Reply-To: References: <1784228.uJLO1Brz0r@localhost> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 22:50:43 -0000 > Making p= an optional tag, even with the default of p=none, I believe would > further erode receiver confidence in DMARC policy statements, simply > because publishing a record with no p= tag provides no evidence that the > domain owner has given any thought whatsoever to their policy statement. I don't see that making p= optional solves any problems, so I agree we should continue to require it. "People who don't read the spec and publish garbage" is not a problem we solve by changing the spec. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 21 16:17:33 2020 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 804AF3A0CA8 for ; Thu, 21 May 2020 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=deuaOUZn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ePkUo1FW 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 xwQPVJqZLROg for ; Thu, 21 May 2020 16:17:28 -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 7F45D3A0C9A for ; Thu, 21 May 2020 16:17:28 -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 C621DF80271; Thu, 21 May 2020 19:17:26 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1590103046; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=BENRlA8xlVOUjjaLh/VyqlVPrajVlwvQ5ST1XCXTA10=; b=deuaOUZn3SpinIqqAB1zLkTETB6wITq1LBs0/pM4PJa17WAowi5DTfoNtomPZdGPFfK/a Rvn80qhg2+k88GKAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1590103046; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=BENRlA8xlVOUjjaLh/VyqlVPrajVlwvQ5ST1XCXTA10=; b=ePkUo1FWvZim0IPOD3AZqmoWBi7/MgHbtlfpmOb4uqq6TMMaWKxHj853RqM54GwCTN3qv 709LANbMDhDmahAwt0CPt1qF8xg7AvNXt8YCX7J/pJ+D+Ioegdk3tfVclsthY3g9IvzUb7m cKqjTeL4zkqKUfAiCCWTKBMAy4egx2+Lj8Kvx6kYYBug9MX+IfBAav5MaKrd0tygYHn0WV5 Rk9jW0jUTeE7OcpJ0d8ESxMxiK/ZrCyRLRv6XyD99ulrSuQSvUhF5qPxn3qwZBdMlpGP5YD 3wgCwEW6Ci6xEnhgZaqoN5PYwiFK/V3OsrSrnipmVjiwaTub/NlHsPXyUnqQ== 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 7B5EDF8009D; Thu, 21 May 2020 19:17:26 -0400 (EDT) Date: Thu, 21 May 2020 23:17:24 +0000 In-Reply-To: References: <1784228.uJLO1Brz0r@localhost> 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: <84D5DBFB-B1C4-44D3-8A01-0330CB4BFC05@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 23:17:31 -0000 On May 21, 2020 10:50:37 PM UTC, "John R=2E Levine" wro= te: >> Making p=3D an optional tag, even with the default of p=3Dnone, I belie= ve >would >> further erode receiver confidence in DMARC policy statements, simply >> because publishing a record with no p=3D tag provides no evidence that >the >> domain owner has given any thought whatsoever to their policy >statement=2E > >I don't see that making p=3D optional solves any problems, so I agree we= =20 >should continue to require it=2E > >"People who don't read the spec and publish garbage" is not a problem >we=20 >solve by changing the spec=2E RFC 7489 already says if it's missing receivers SHOULD assume p=3Dnone, so= I don't see the point in "requiring" something in a record when receivers = are already supposed to deal with it being missing=2E Scott K From nobody Thu May 21 18:10:16 2020 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 C59393A0D70 for ; Thu, 21 May 2020 18:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsINLwZWaQOq for ; Thu, 21 May 2020 18:10:11 -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 496A13A0D6D for ; Thu, 21 May 2020 18:10:11 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id g12so7333529wrw.1 for ; Thu, 21 May 2020 18:10:11 -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=C7dxsocJ7bRc+uz3dRXdPJh9PXtTWkms/OLHbrQkdl8=; b=by6zd9Q9KxAHShU199/YrC5pGKqvqQ+zSP805o5F1yHbaVTA7SY93KadP7NXt91JA9 39VyVGe/T+ID7/LbfTxCJjp9ta8go6CofpwxO/N8ci88VpwOFCog6FfqDNs7QipRA7pE pmxbIKuQIKa9zfZlPW0brHybgn72pZo1u+QJxwtEbCL8RWt6D51CxnKpSorFmCtsB6pL hsMfR8GEhUpXjjTRft9XHrQWuXZUjC8n8KCwT3okV3//RbQOlZUZ15Vl6Daor+s9rOFG PcbndRAAUturkUZAJxU1jnRPhiiATv6Wu3BuU3NMvdi8pjHHNvZfuqi04k7f2e29LOIj gMsA== 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=C7dxsocJ7bRc+uz3dRXdPJh9PXtTWkms/OLHbrQkdl8=; b=J3+dBCeqO7bpfd8f7T5sby+3ymk30F5Aa/Kn2eqYQkaLdeml2cb0ONxNncQyj2Y7VN 5XYEyngF/u6tlgLWoAllVv6kXDB65SgbhEun3tZnSb2YO26grQJ5uNWwM47ccHMeGwCh 9KVQvdcvVGqILjK+Plg1vCm9x+sw/UeQ0tUJIgBhpIn04+DawG/dqwN9KBcsg/nDzync iHpvWfOlT6zCi8RWLq90vhKk7ECnL7vHaus4bTRrayaTqadz3n0CNijU94z0E5tSyT2p oXD+xA4etYz6zgJ7t8VypwdEysyFhQeGGnYDp4NfLftgmHTRF9sA5Eg5MeX3IHfVdOP9 tiCQ== X-Gm-Message-State: AOAM533AlKkW2TD/NkkXV3BV8hXDE2IBZdNrNSwM8RvEGVvRhd9gKJ10 O/O9tiSTp/SVf68qNtqc1dkqtaXH5r/370KeKI2RCXZt X-Google-Smtp-Source: ABdhPJx3j2fvgVfW8KXcdLyPwZaDqK5Aql0cOlaWF2Kq/huLSH5O23rWWhdijYRRQkL15BnT4sj/MOhlOagOVnL4vtQ= X-Received: by 2002:adf:e4c2:: with SMTP id v2mr1044211wrm.72.1590109809769; Thu, 21 May 2020 18:10:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Thu, 21 May 2020 21:09:56 -0400 Message-ID: To: Tim Wicinski Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005d800f05a6324a22" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 22 May 2020 01:10:15 -0000 --0000000000005d800f05a6324a22 Content-Type: text/plain; charset="UTF-8" On Thu, May 21, 2020 at 5:57 PM Tim Wicinski wrote: > (with no hats) > > p=none with no reporting is fine, and we should keep it. > > One thing the WG could do is a BCP document on operational recommendations > where there are certain suggestions like this. > > tim > > +1 > Michael Hammer --0000000000005d800f05a6324a22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 21, 2020 at 5:57 PM Tim W= icinski <tjw.ietf@gmail.com>= ; wrote:
(with no hats)

p=3Dnone with no reporting is fine, and we should keep it.=C2=A0

One thing the WG could do is a BCP document on operational recommendat= ions
where there are certain sugg= estions like this.=C2=A0=C2=A0
tim

+1

Michael Hammer
On Fri, May 15, 2020 at 1:16 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
If this were a green field effort and we were trying= to decide on a report
format, I would probably think JSON was a great choice, but it's not.= =C2=A0 Trying
to support multiple formats is going to be a lot of work for little to no r= eal
gain.

I'd suggest no.

+1, unless there ar= e known cases where the XML payload size is a problem that switching to JSO= N would solve.

-MSK, once again devoid of hat
<= /div>
--0000000000009018e405a5b714c5-- From nobody Fri May 15 15:36:28 2020 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 ECC263A0C21 for ; Fri, 15 May 2020 15:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 C8N7muP_fPau for ; Fri, 15 May 2020 15:36:25 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 D04333A0C20 for ; Fri, 15 May 2020 15:36:25 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id p127so3641474oia.13 for ; Fri, 15 May 2020 15:36:25 -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-transfer-encoding:content-language; bh=zhvz36sginNUXoKPozcPw93t/pPUeCGsNQIjoJ+nFqM=; b=MtplGSGUKrYay92MMm/TfVzEckhnip0lnzQmOcBM6+UnbzxTLzWaQPy1NQTmKOmI+P ZU4kTVyDKv+o+yXHVQVlN4X6TR54nrVIJXZmJuB7aLtKo4FWjQMU5R63ehVN3YD8Kc5x rsFpUpDCeYZ5DdLWa8Qz3YzaAEUP7foqxMiaE7w1fkIJQF31U/jajUjwOv4hXtr3oI2u l3RKYO0XLRE87Kr8X4sbaQBkxZgUeOGwX9NabM0w69rqTw9uNypAPgB1tPHx29dQ+DwS j7jY6enD6IBdSR+E+OA9R6Z+VmRDrphPPXBAaT3e+vESJdhG0/nlpTPt+0aqfk9I2OSE GRDg== 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-transfer-encoding :content-language; bh=zhvz36sginNUXoKPozcPw93t/pPUeCGsNQIjoJ+nFqM=; b=kr9YC4TEtmIJRfgCgF8r8cmxu+m87DXWp25SV7FbAls6U9vdvyReKkQOqqaZ6fVfsF vNFyzl1uiTx9+zJjoP9c3jJibpfR/m/ggeBi5WFPuUhL3rhUwgayBZayY7tuWJhPLKAC QVOSdWthEb3Nw2vIXM1JgtaF/a7u0gInKoVHl/jXV6mAMKK9trMzCI8o7yTG80zZz0IR PHpqOvuDDvXLEXSOnzGoPnuteYuI09xcwTNPLOZHvKgcqKZp1p3gLvg/eOt6/HjsE6W4 SoZY9Q+aZDlfxa9G+Cn+sIHkyc199+fB21f2l4u9oOsDIHBdlbIuPlClDcWyElpSmg8e DhTw== X-Gm-Message-State: AOAM530VuWRphnd1Hr7D6bEriEYiL2ggrSFy9jj3nqMNv7yzLjen2oEs S5VSrmT07/RtJYEG5X1AwmKJZamvc8E= X-Google-Smtp-Source: ABdhPJzTAo0CtiVjixMuPP9IPt48BeZpo2K+R6ANUy3sOtZ8yxbOgNUq7+rky3Gwtsdu09ceeh4gHw== X-Received: by 2002:aca:b309:: with SMTP id c9mr3688097oif.63.1589582184837; Fri, 15 May 2020 15:36:24 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:e005:a751:e94:d67d? ([2600:1700:a3a0:4c80:e005:a751:e94:d67d]) by smtp.gmail.com with ESMTPSA id s62sm945419ooa.39.2020.05.15.15.36.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 15:36:24 -0700 (PDT) To: "Murray S. Kucherawy" , Scott Kitterman Cc: IETF DMARC WG References: <3193525.cVJkX3U5sK@sk-desktop> From: Dave Crocker Message-ID: Date: Fri, 15 May 2020 15:36:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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] DMARC bis: ticket 69: add JSON reporting format? 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, 15 May 2020 22:36:27 -0000 On 5/15/2020 3:09 PM, Murray S. Kucherawy wrote: > +1, unless there are known cases where the XML payload size is a > problem that switching to JSON would solve. For any interesting specification, there are many ways to improve it.  The question is whether the improvement is worth the effort. So, when someone suggests a change, there should be an expectation of an accompanying explanation that makes the change compelling. A particular trap is changes that are fashionable rather than important.  That is, they suit the tastes of the day, but they don't really fix a problem or makes things markedly better. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 15 18:04:08 2020 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 E15963A07D6 for ; Fri, 15 May 2020 18:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=smSDTlfq; dkim=pass (1536-bit key) header.d=taugh.com header.b=z4EbmKU3 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 O1AiSv8ylYwS for ; Fri, 15 May 2020 18:04:04 -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 E475E3A07D0 for ; Fri, 15 May 2020 18:04:03 -0700 (PDT) Received: (qmail 37134 invoked from network); 16 May 2020 01:04:00 -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=910c.5ebf3c00.k2005; bh=+2O7GFKp/lMqg81roGvgSWASf2/2quAVnRi2mSjkaLs=; b=smSDTlfqzz+AfWdvNVuJ9GqbfZ4uAzMTrr8ywC8CZuk/rEfdYLWKUks7Y+Pu3ByM4FXm5IahyEaScILZVU0+VZ4XUUP84TDtNa5gYcq67bE0ci+00MjzEMyevn7OQD7IAV6S4x1+SMsG40jTZSfYMsIei1qS9Ii6y+iqY4rpJS/Q4+KUNNfryBzK/enzRufIBeDG4E8IL6htcU+fCJj2YF5V08p7v4p3O4TsTVoSFwvuvadfWn2YddqoicoXcbij 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=910c.5ebf3c00.k2005; bh=+2O7GFKp/lMqg81roGvgSWASf2/2quAVnRi2mSjkaLs=; b=z4EbmKU37gTtw8tOtu2MT3492zhhMjCyFrbah1yigADL0kryxXMle32k9KtIY8hG63Ccr+6cPum+WgEMzu/tyuv/bQPY9greB2HDQsFCHm+gFfnqkAg/u9TgECFjPa6hCJ0Mzjd/4C6M4WwfvPNAg2E4vijK7cZpewH6QTGA/VIEerZHZuPc4+yzbcS6Xp80icY90/U0wcfj2zburuk3LbumeYn5/zhGiy9PrlDRBX21SjH4WvXqhpFibqwWGGX6 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 May 2020 01:03:59 -0000 Received: by ary.qy (Postfix, from userid 501) id A422D195F526; Fri, 15 May 2020 21:03:59 -0400 (EDT) Date: 15 May 2020 21:03:59 -0400 Message-Id: <20200516010359.A422D195F526@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <3457203.qin9KRflZP@sk-desktop> 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] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 16 May 2020 01:04:06 -0000 In article <3457203.qin9KRflZP@sk-desktop> you write: >> Should we make it invalid to have p=none without a reporting address? > >I'll bite: > >No. > >This is unrelated to interoperability and unlikely to actually improve >anything (this reminds me of the occasional suggestions to make v=spf1 +all >special for SPF records). Agreed. If we want to create a profile so people can give themselves a DMARC gold star, we can do that, but let's not mess up the spec. Also, I can imagine situations where a plain p=none makese sense, for some tiny domain that sends out two robotic notifications a week or the like. It too little to be worth instrumenting. R's, John From nobody Fri May 15 18:09:29 2020 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 7CC063A07E1 for ; Fri, 15 May 2020 18:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=NTmg63PU; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=N5eyKOC7 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 P2_Ymmwp59ax for ; Fri, 15 May 2020 18:09:17 -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 F1A2D3A07E0 for ; Fri, 15 May 2020 18:09:16 -0700 (PDT) Received: (qmail 38067 invoked by uid 100); 16 May 2020 01:09:16 -0000 Date: 16 May 2020 01:09:15 -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:in-reply-to:cleverness; s=94a8.5ebf3d3c.k2005; i=news@user.iecc.com; bh=lF56xv3Km5FKLT+onq5V4hoKHPWqhTEq3AHeQbwbWUk=; b=NTmg63PUyt9p0HkHmJBVdiD1ZDDGmLDgaFlk/RjV3MJPQ84SvfstGA/u6nM3EZ+nHBDqgxfTsKP4vwKKxWwjZX6JpqTgZCw/v36avg5zuuL/V3k5hud02F/kxdu0/IffiQy30pUJqshMtaM9QI9sDB6RMlAnZ0pK+tz+VrB4Vimxsa5i4ElR5T63fSgsf0xaARCRbA8x3C9QdEWWbwpfsoIsLTzlqDynUrTOlEoGs2IwkwUdxFWkBhI0Ya+FCK0n DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=94a8.5ebf3d3c.k2005; olt=news@user.iecc.com; bh=lF56xv3Km5FKLT+onq5V4hoKHPWqhTEq3AHeQbwbWUk=; b=N5eyKOC7uyoKsUB2MVgIcbL8wjAa0iE6tyqpWFi1jUU9cecRnztVEO6nxmMjbp9pJZ9ysY6hn17Qwv/DpGHbW2PTil8fVJ+irNFiEBTX0FlIOfariT/q/epBNIeIhHKAjhLWchu8YF2kj/VqPibe4WZAfsUHsMRJdJSrnzTBRu51sQTTDPf1uajA08a3fb9SCp4dxK7Qu3K3xjbecdlaUUpRjbYHoQEK7cq0aY8JKYph1a6wuTlPVQ2izoHBxoNe Organization: Taughannock Networks References: In-Reply-To: Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 16 May 2020 01:09:22 -0000 In article , Murray S. Kucherawy wrote: >It's been a while since the original discussion, but I can't remember why >the requirement is there in the first place. The only benefit I can think >of is that having "v=" first lets you decide very quickly if you care to >continue, but the savings is really pretty small. The v=DMARC1; is a magic number that tells you whether it's worth decoding the rest of the record. People put a lot of junk at tops of their zones, some of which is in k=v format and I would prefer not to try to decode records full of junk to see of a v= tag is in there somewhere. Other than that I agree there is no reason to specify the order of tags. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 15 18:13:58 2020 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 D16D03A07E0 for ; Fri, 15 May 2020 18:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=T6NSqLKD; dkim=pass (1536-bit key) header.d=taugh.com header.b=SBvQlf+X 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 qhJveCPl0aYW for ; Fri, 15 May 2020 18:13: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 224153A0061 for ; Fri, 15 May 2020 18:13:54 -0700 (PDT) Received: (qmail 38871 invoked from network); 16 May 2020 01:13: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:mime-version:content-type:content-transfer-encoding; s=97d5.5ebf3e51.k2005; bh=yN6xmFdY+tbLdQIlGdvMxz6r12zgueX61PyOHaSsWwE=; b=T6NSqLKDuvxL7/XbnUYbeDTQWxjSpJMFDqg2MFKxrCf0a4tOHCpaZyjqkGQSV6b6WjHLhbv95zdVhPQ6MNFOdeeJFYFgtAD9x1vlOpfew2wt2D9xDGdZe+TgtlkyqomY+Bq4xFgFJtz06Ma6e15LUmkpjqjOIEQPjUZIbsktUWEj43BpTxO3FXtyuIggfn9oZ3EoRnW4G/hQVSJKHBs1N9ddlx8lJN3bjNd5EGcGXApdGM5orwfnwTU+QhI96oYB 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=97d5.5ebf3e51.k2005; bh=yN6xmFdY+tbLdQIlGdvMxz6r12zgueX61PyOHaSsWwE=; b=SBvQlf+XopCQ7/5o+zxFgs1K+81cZ1Vw5bDgK+yixVeD/+pvsPDZW37Qra0WIRH9KpOTf2fEDlAOFz6cl3IjuEj4h+v8YrUfIXnyhRFflLHRg5tj0oNFrK1MkprbNiG3OXO9vU4QIjLLwOzmexh3CaXO0aHN9ywCZfSl8KDw+q+v/t7k0kmdZ2Djsfg15c2vWBeHyO6hrbFK0I5mGfFYspn86sdLsMbmxBDeNY/c51QJ6Ik4JYjqmbj715/goMza Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 May 2020 01:13:52 -0000 Received: by ary.qy (Postfix, from userid 501) id DBF1A195F5FA; Fri, 15 May 2020 21:13:52 -0400 (EDT) Date: 15 May 2020 21:13:52 -0400 Message-Id: <20200516011352.DBF1A195F5FA@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.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] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 01:13:56 -0000 In article you write: >-=-=-=-=-=- >Should we consider adding JSON formatting to DMARC? What Scott said, no. Report processors will always have to be able to decode the existing XML so adding more options just adds more complexity with no more function. Apropos ticket #29 we might consider resuscitating the https: URI. It seems to work OK for the one reporter who uses it for mta-sts. From nobody Fri May 15 19:19:57 2020 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 310233A087F for ; Fri, 15 May 2020 19:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=qL3y//ee; dkim=pass (1536-bit key) header.d=taugh.com header.b=baK0a4MG 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 Uxieag4wQs-E for ; Fri, 15 May 2020 19:19: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 BCC763A087B for ; Fri, 15 May 2020 19:19:48 -0700 (PDT) Received: (qmail 52148 invoked from network); 16 May 2020 02:19:47 -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=cbb2.5ebf4dc3.k2005; bh=ziMkPEUQBtXES5OAYLk+jSOvcIKJya+lL+6V6TbIgGY=; b=qL3y//eetySxnC9+XCRWgumA3peUUX3ntBAlv+sRgNA2RAAYiSPZjeXG4r/yPKun2rVKFZLD2nYipgyeEgI6EYZXTOFulPSJLSe4g/rVtHjOvHqIBtETat7I+TQiXRm2nY0lH6B4g1SBiVyGWsuTc/qr0ZxdHSxisAswHPf5vnUN7VzSbiCeLhbrf8Kyo444BNxCpdZXnwCRzH+7SEliffSOAqA4Tht7VVXfzdD6f/nfZ5v1Ol/0qR7W+bbdHEZc 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=cbb2.5ebf4dc3.k2005; bh=ziMkPEUQBtXES5OAYLk+jSOvcIKJya+lL+6V6TbIgGY=; b=baK0a4MGR6PDgHO9xHIFTXOefVXzQ0SdQhGKuFFLMFz/SnI6SmKst0LMoETwr0Nf2OZmuuUq0/kQ7x+r/q2OnR3fQySEhOUziNNUQFQt+aJzdzY6KLRKtbENtVA3/MtbxyfELpGb0AbdaaXpGJpE9i+wrl1ww0ki6ex7ncXnsSHKtdfgRLV+8r3Q83Zm5Ov1ikpql5GZMRjZDTK077qoWCtNjreQU++6oJVD+AO7o2WmduUB1zVx7eJu7EVYPbrn Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 May 2020 02:19:46 -0000 Received: by ary.qy (Postfix, from userid 501) id 97571195FB9E; Fri, 15 May 2020 22:19:45 -0400 (EDT) Date: 15 May 2020 22:19:45 -0400 Message-Id: <20200516021946.97571195FB9E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.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] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 02:19:53 -0000 In article you write: >+1, unless there are known cases where the XML payload size is a problem >that switching to JSON would solve. It's gzipped, do I doubt it would make much difference. Gzip is really good at compressing the boilerplate strings that make XML bigger than JSON. Also, FWIW, in seven years the largest report message I ever got was under 300K, and if people really are concerned about big reports, I would much rather revive https reporting which avoids base64 encoding and doesn't have to buffer copies of the report for relay. From nobody Fri May 15 21:47:21 2020 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 ADEE53A0984 for ; Fri, 15 May 2020 21:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=isdg.net header.b=jIho6XQG; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=nslARS6/ 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 cudBkGr4MP9L for ; Fri, 15 May 2020 21:47:17 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (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 A48703A0980 for ; Fri, 15 May 2020 21:47:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=874; t=1589604422; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=05bn802U12yc5ox/sededuXjlGw=; b=jIho6XQGf7JAPU/Y+NDPwba06/0HRhmOt3PsE7VKiNGC8lVgDe7Yw/JkjID70y 992euDENq6pgj1QpwlSUBu2L7KUw7+a/sUX8gHbU9JZ/NnLF8jd+9tGsJZaWCFl2 dcODoYfVbiP5OEOA+ugLl6hwosCIQNuzEDWwbHnxaV/4s= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 00:47:02 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 331755326.1.4964; Sat, 16 May 2020 00:47:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=874; t=1589604048; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QKLFLbW 0TeFl38ApWSrHJiYDwccyQoDuGTiy6xs4uCs=; b=nslARS6/EI/5fBZYKLs1cMu jdJmcgWPDI8UBBnG2L4csDRYl5ab4Vkcl5rkmmBEnKF01acAUUG41rsN5bsbF67+ 7IuNRIDhs+3i13ubgSkczS25qIdGPz47w6d3IkERKP/BCg03myH4gnxdlt+XSXIC 5eI1VUB4mB0iD81s8ohc= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 00:40:48 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1338121593.3.11268; Sat, 16 May 2020 00:40:46 -0400 Message-ID: <5EBF7049.50502@isdg.net> Date: Sat, 16 May 2020 00:47:05 -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: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 16 May 2020 04:47:20 -0000 On 5/15/2020 2:26 PM, Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/63 > > A published DMARC record that consists solely of "v=DMARC1; p=none" is > syntactically valid, but is semantically equivalent to having no > record at all. > > From an ecosystem perspective, especially in Europe, data has been > shared showing an increasing number of domains putting in bare p=none > records, and then claiming that they are implementing DMARC and have > some layer of protection against spoofing of their domain. > > Explicitly making this case invalid would remove confusion from the > ecosystem, and allow any checker that is up to spec to properly flag a > bare p=none record as being the same as not having a record at all. > > Should we make it invalid to have p=none without a reporting address? No. Reporting can not be mandated. -- HLS From nobody Fri May 15 21:54:48 2020 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 C40F33A09A6 for ; Fri, 15 May 2020 21:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=isdg.net header.b=F4S+k180; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=OIgMDXsT 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 k-bb4K8VXTRB for ; Fri, 15 May 2020 21:54:44 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (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 689583A099C for ; Fri, 15 May 2020 21:54:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=174; t=1589604873; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=4bnEUpZ3eA/UQcxMsBxPoTI0PDQ=; b=F4S+k180wj/qy23dgSAiOu3Lwq/MVg4XLt/+xBxFneAl5rHQiEEi9EPnoHCvSD MLgYRyT+gDM1NaQ/AZGwVCBiQwZxBxQ0MEaIdvS40h3UrUU1d5S5Gr6C7Lz61eeI pe8bSK6meWs46cKhhhTvhlb7fcP3H9eEIBUJJHp4lV14Y= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 00:54:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 332205452.1.3392; Sat, 16 May 2020 00:54:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=174; t=1589604499; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0BIhCxj vNvwWNCgj4WWm07RB2lMRp7/LCXfkWj0s4D8=; b=OIgMDXsTZ5BSXw+0N4f07BM OqY+WM6I+/OgrWFOITGWF+6EtWUlVcaE1Rjvt8t/pqeL10/alJ2Hysv12BXpIIa3 pAKKJuKavZWccyst1aU/GY1usNUxBshZo8nGrVhNFBGnsIGlHFt93Oy8RWTbzpYa 7c+11vtHU9tkvVhuUkmo= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 00:48:19 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1338573343.3.11032; Sat, 16 May 2020 00:48:18 -0400 Message-ID: <5EBF720D.8040608@isdg.net> Date: Sat, 16 May 2020 00:54:37 -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: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 04:54:46 -0000 On 5/15/2020 2:26 PM, Seth Blank wrote: > Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. -- HLS From nobody Fri May 15 23:41:32 2020 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 74DC63A07E1 for ; Fri, 15 May 2020 23:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 XPEwzcj4oy6p for ; Fri, 15 May 2020 23:41:29 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0: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 764E23A07D6 for ; Fri, 15 May 2020 23:41:29 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id k110so3823905otc.2 for ; Fri, 15 May 2020 23:41:29 -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-transfer-encoding:content-language; bh=B5kROcioTA2EqqKbNcnpHHfQk4K7gtMSBx2YulAp09s=; b=fMbXhSLrc0jjxGtVMOPsbKzindTAdVZOmZ8LQNhuDzMfknTjUTv7PsXdNOR9Um3KHg UGnlSkb+Su2g7/44l1Cj/C52yQ71VKluyKcnMboB4Vr2Q/MB2LWQwq0HcT6nhAwjCfvw 6Ljs0cSITI+ehi/o7QoNN2KBjaouvOu7g4SslfzcR86tTXeiFZaPOL2rh2yP07mR6BCG 2mg2TPKSEOWXaGQQL927yMiCbiibwVmxHtNyUVxzhwKwe0AvF4RZ1f68UpsliYAvy1ub rIB6RgXGvg4HEqnN8ZvfGJBN0Os/I3piElos2neDedf/DEoAKg891ugwHdEge9s4iN5K HVhw== 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-transfer-encoding :content-language; bh=B5kROcioTA2EqqKbNcnpHHfQk4K7gtMSBx2YulAp09s=; b=ojr1edsYGjHgLNuTnLSSGNZO8x8CsFLtRRdPL5EvNBTVkgy2Iid8jkeg2E6zOf/his Qd+Ny0W5WR9GYpuQNdtnvNLMQuyUuPX9To8j4VZnyGYsKcKPe/PN6id8d8u07JAqR2Lj FikdYmZknW7btZtAYidcsdAJnwCnzH+3tL1vf+vZeWzro9EiHXhLl6jwSsMqZDBupq7k ejlKhGpFK+nxmoQCP6ATPa9XZeTht6JzhvPSIbkaJ3nWGFMd4QKnTnpsc/Oqm0J1W1Nr RW/hdPKcVfBOEOqdpt+9+p9gfiJVBCpq3IhYq7TH2ObAo3AFUjJQ9/FbxezOKHAh/288 Pe8Q== X-Gm-Message-State: AOAM532Q33GmFYQ3ux1/gp1j1KgxJYW/3kKWBmWOipt1r3wGiWveABTI HU/vtFTxVY8DRa0C0y+PdU8eAd5jqAw= X-Google-Smtp-Source: ABdhPJwgfDh4lYmKfWHOlPvDq1GxYhxHk0qukpPvyQvAM1V1P9hNQ6ep1pmqcRyfs+uFleOCCzEMJQ== X-Received: by 2002:a9d:4041:: with SMTP id o1mr4837906oti.265.1589611288502; Fri, 15 May 2020 23:41:28 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:dd9c:c44a:55bf:3c7f? ([2600:1700:a3a0:4c80:dd9c:c44a:55bf:3c7f]) by smtp.gmail.com with ESMTPSA id i5sm1236502ool.27.2020.05.15.23.41.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 23:41:27 -0700 (PDT) To: hsantos@isdg.net, dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> From: Dave Crocker Message-ID: Date: Fri, 15 May 2020 23:41:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EBF720D.8040608@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 06:41:30 -0000 On 5/15/2020 9:54 PM, Hector Santos wrote: > Protocols should be flexible. Adding it doesn't mean replace. Explain the need. Convince plenty of folk that it is necessary enough that they are inclined to write the code, deploy it, and use it.  Adding things is expensive. Flexibility that does not have a clear need is especially expensive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat May 16 02:37:13 2020 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 CBEF33A09D5 for ; Sat, 16 May 2020 02:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UyG_r8G55PZo for ; Sat, 16 May 2020 02:37:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 BE3D33A09D1 for ; Sat, 16 May 2020 02:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589621826; bh=cHedZdugpKiX0ODkxThmaVj+cwUhHU7IjE5kFYE785U=; l=2117; h=To:References:From:Date:In-Reply-To; b=A8hnYe97ZzEuhgzVHhlNtSoNSfhzVh3GidEUaN8cT5E9VTiK0A66OS9mqTz45P0H+ ihBCYFRiOpyQjjEEpz8JEkoWRosJt+1ZI6AqWLu+ujNv23NpzRlprazqOW3FQOdrBH 7ZTYm597EVW/omhBvn9nvGeUgApIvciql2LrNaBW1JsZcmGji1GN5V+23zEvK 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005EBFB441.00005053; Sat, 16 May 2020 11:37:05 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <50efb6dc-4b66-4846-f464-3787f399f340@tana.it> Date: Sat, 16 May 2020 11:37:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 16 May 2020 09:37:12 -0000 On Fri 15/May/2020 20:26:30 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/49 > > The penultimate paragraph > of https://tools.ietf.org/html/rfc7489#section-6.3 states: > > the "v" and "p" tags MUST be present and MUST >    appear in that order. Actually, the text says: A DMARC policy record MUST *comply with the formal specification* found in Section 6.4 in that the "v" and "p" tags MUST be present and MUST appear in that order. I agree to relax that rule, but that entails changing the spec in Section 6.4. A possible way is be like so: OLD dmarc-record = dmarc-version dmarc-sep [dmarc-request] [dmarc-sep dmarc-srequest] [dmarc-sep dmarc-auri] [dmarc-sep dmarc-furi] [dmarc-sep dmarc-adkim] [dmarc-sep dmarc-aspf] [dmarc-sep dmarc-ainterval] [dmarc-sep dmarc-fo] [dmarc-sep dmarc-rfmt] [dmarc-sep dmarc-percent] [dmarc-sep] ; components other than dmarc-version and ; dmarc-request may appear in any order NEW dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) dmarc-tag = dmarc-request / dmarc-srequest / dmarc-auri / dmarc-furi / dmarc-adkim / dmarc-aspf / dmarc-ainterval / dmarc-fo / dmarc-rfmt / dmarc-percent ; components other than dmarc-version may ; appear in any order The latter syntax allows repeating the same tag more than once. Should we add that in such cases it is undefined which value an implementation retains? > While the v= tag pretty universally appears first, the p= tag does not in many > records, and no implementation appears to care. > > The v= tag must appear first, or the policy discovery mechanism as defined > in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break. > > But there doesn't appear to be any real reason to keep the normative > requirement that the p= tag MUST be second in the record after the v= tag, nor > does this requirement seem to have any impact on interoperability or general > record parsing in theory or in practice. > > Should we remove this normative requirement? Yes. Best Ale -- From nobody Sat May 16 02:37:37 2020 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 2675E3A09D6 for ; Sat, 16 May 2020 02:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LTRI5-Ha4Ow2 for ; Sat, 16 May 2020 02:37:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2DE7A3A09D1 for ; Sat, 16 May 2020 02:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589621852; bh=7QcxfpZfiAfLOOqHNvIxYJzCQMmwrPQ6RHEO2d6GCSM=; l=1002; h=To:References:From:Date:In-Reply-To; b=CB6EkhBTDAjaqlpKavT863DJ32ARkZvhJrPAexDVMQBphdDsH2/1el3+/YkYbrLzk ih1ZPJlvyQsPXQbLntJ2AMJL9BBy2qWzPNETCcSAbrU58Iizb4mjj9CrgMndqQ8Q22 WPpqGmIwxZSMUibFRqtEV993npt7TJBkicvU+rq1uKp0y2sgdzlyJj3iyT/Ai 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C3.000000005EBFB45C.000050A4; Sat, 16 May 2020 11:37:32 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sat, 16 May 2020 11:37:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 16 May 2020 09:37:36 -0000 On Fri 15/May/2020 20:26:24 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/63 > > A published DMARC record that consists solely of "v=DMARC1; p=none" is > syntactically valid, but is semantically equivalent to having no record at all. > > From an ecosystem perspective, especially in Europe, data has been shared > showing an increasing number of domains putting in bare p=none records, and > then claiming that they are implementing DMARC and have some layer of > protection against spoofing of their domain. > > Explicitly making this case invalid would remove confusion from the ecosystem, > and allow any checker that is up to spec to properly flag a bare p=none record > as being the same as not having a record at all. > > Should we make it invalid to have p=none without a reporting address? No. A bare "v=DMARC1; p=none" still behaves better than NXDOMAIN, and may cut the number of necessary queries. We should instead recommend it. Best Ale -- From nobody Sat May 16 02:43:05 2020 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 210913A09DC for ; Sat, 16 May 2020 02:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KCRHxPAonwgT for ; Sat, 16 May 2020 02:43:02 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 85A2F3A09DA for ; Sat, 16 May 2020 02:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589621880; bh=vpXPKmpVQjgKNBxFSilJqpSGgG4xj26WnfvNK0BY3UM=; l=557; h=To:References:From:Date:In-Reply-To; b=DVXH4bjeZ+XFpLwhA8YN1+In9JUVZUD4XkWazjPuInGOlrDWnKD+WV+FSYCiDJsof SkK8FWKviME++GqS3QBBGvRXdMeLclBCOjbvurbYiHEMSGo0hAbnhrcb32LkjW/Wbq YHu/kTFweBycLwOe2TL3gyAGDECB56+zDcSxCb43HS2BoiC3yTEfKfZNDTZmZ 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005EBFB478.000050D4; Sat, 16 May 2020 11:38:00 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sat, 16 May 2020 11:38:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 09:43:04 -0000 On Fri 15/May/2020 20:26:32 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/69 > > Aggregate reports are only sent in XML format. There's been some discussion > (that's also related to https://trac.ietf.org/trac/dmarc/ticket/42 about > expanding reporting functionality beyond mailto:), of adding additional > reporting formats, specifically JSON. > > Should we consider adding JSON formatting to DMARC? Please let's not even air such hypothesies. There is still people who send zip rather than gzip... Best Ale -- From nobody Sat May 16 04:41:06 2020 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 0A34E3A0AAF for ; Sat, 16 May 2020 04:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 aBYNzeA1Zs-r for ; Sat, 16 May 2020 04:41:04 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 142603A0AAC for ; Sat, 16 May 2020 04:41:04 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 15E707FDEB for ; Sat, 16 May 2020 11:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=314; q=dns/txt; s=default; t=1589629263; h=from : subject : date : to; bh=e9P1uYHGQI0gJTMEWTC0K9e1PEO0bpKHkGjGzr0+Sh0=; b=TXA6WvBC70wEy5KsC2tHAjV6mz99IZRJOIot6yO/7WLEdHBv9uZk1+fvnBkU1R6qV/Ddk pVKfYn+p5FL4eNs9biGH2XEyyQVfs5EfGOr7CJtJTWHuQptIGmzUSavbAcz+mpbrjqbC2VJ 7dsmlxpla1XxkyACnE3MOzQ1mvlA7YI= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id E75397FA5E for ; Sat, 16 May 2020 11:41:02 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 16 May 2020 13:41:02 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.1 Message-ID: X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 11:41:05 -0000 On 2020-05-16 11:38, Alessandro Vesely wrote: > Please let's not even air such hypothesies. There is still people who > send zip > rather than gzip... and still people that does not use sid-milter, opendkim, openarc, opendmarc, all of them wait for software updates or precompiled problems to be solved From nobody Sat May 16 04:56:24 2020 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 F00663A095E for ; Sat, 16 May 2020 04:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 MFJMxHQ4HQei for ; Sat, 16 May 2020 04:56:21 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 A6B883A0959 for ; Sat, 16 May 2020 04:56:21 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id D29867FCE6 for ; Sat, 16 May 2020 11:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=247; q=dns/txt; s=default; t=1589630181; h=from : subject : date : to; bh=HAUzNmPXnGRkuIT+v5YtjkVPLQfQiZv1CL3q4hgB788=; b=CON891P9eBxoMKR03ZORAoaE6xuEVWHii0LWLfh9fNZMXPYHrONzkEFPoWd0riEwbwIzX BcQS8VpWRL3BBX9Qujkteyyz3pGShpe6/kEFEjXN/xA149XG3QO1FQtDgPAwSX90yAlNqGm YZ/aI7CGfqfhPpu3rqlW76WiAn12Zns= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id B27387FCE4 for ; Sat, 16 May 2020 11:56:21 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 16 May 2020 13:56:21 +0200 From: Benny Pedersen To: dmarc@ietf.org User-Agent: Roundcube Webmail/1.4.1 Message-ID: X-Sender: me@junc.eu Archived-At: Subject: [dmarc-ietf] dmarc.ietf.org failed 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: Sat, 16 May 2020 11:56:23 -0000 https://dmarcian.com/domain-checker/ test it there if not taking ownerships it will get dmarc pass oh well software testers needs cases to test on its one here then if its complete impossible to not break dkim i will leave this maillist From nobody Sat May 16 08:50:09 2020 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 66BE53A08CA for ; Sat, 16 May 2020 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRbPMIUGhWgR for ; Sat, 16 May 2020 08:50:06 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598D63A08C7 for ; Sat, 16 May 2020 08:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 00048AD01C04; Sat, 16 May 2020 10:50:01 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTDsugJXZhGg; Sat, 16 May 2020 10:49:58 -0500 (CDT) Received: from [172.16.1.9] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 02B0EAD01BE7; Sat, 16 May 2020 10:49:57 -0500 (CDT) From: "Pete Resnick" To: "Hector Santos" Cc: dmarc@ietf.org Date: Sat, 16 May 2020 10:49:46 -0500 X-Mailer: MailMate (1.13.1r5683) Message-ID: <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> In-Reply-To: <5EBF720D.8040608@isdg.net> References: <5EBF720D.8040608@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 15:50:07 -0000 On 15 May 2020, at 23:54, Hector Santos wrote: On 5/15/2020 2:26 PM, Seth Blank wrote: Should we consider adding JSON formatting to DMARC? Protocols should be flexible. Adding it doesn't mean replace. Flexible sometimes means less interoperable. You've already got to get the XML right. Adding another format that you've got to get right sounds like it increases the odds that an implementer is going to get one of them wrong, and you've got to make sure that the XML and JSON semantics match each other. As Dave said, unless there's a compelling reason to add JSON, the potential for decreased interoperability says to me this isn't a good idea. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Sat May 16 10:24:59 2020 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 431CF3A0974 for ; Sat, 16 May 2020 10:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=t1luoCup; dkim=pass (1536-bit key) header.d=taugh.com header.b=TGG7xaEH 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 TrKU2K_VAoGo for ; Sat, 16 May 2020 10:24: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 7300E3A0972 for ; Sat, 16 May 2020 10:24:55 -0700 (PDT) Received: (qmail 99310 invoked from network); 16 May 2020 17:24: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:mime-version:content-type:content-transfer-encoding; s=183ec.5ec021e5.k2005; bh=fKIt+NCLkte3dxP4kGSc4QTIqxoR67x7ms91urs8wfs=; b=t1luoCuphwrgtUHo0fuMF+HQvpgRb2iqjSPNpGaAJmwuZ/eJjnzi0jk8v3ZqLW+M333YpXYp4ESNemsjh3tLYKgyD4zB+DG6WHkM+dajOCT5N61HY1VI91omPweDWHCksY8izmkJAz73R+bwoWZSr+sk33FSHaWw1UgUecSqYqBb6ZfmC6O+LOgcFj4aMUaspt6FXOyxgJH2/FNRKAPn/01NEkkfCfH/iqldP2DRB3To6Mg2Av+l3Pv34DvtOYm7 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=183ec.5ec021e5.k2005; bh=fKIt+NCLkte3dxP4kGSc4QTIqxoR67x7ms91urs8wfs=; b=TGG7xaEHaslEdG/WcMWmLFD5/ohn0tZQciMV49RVPwg0D+UZus99Wj2gqdJvvJYnwkQNMZwoX8ShVX1n/6fXmugVbqrbQIOD1pjns1HqamDtX4sk7dbwcwIXtVe9sgUyk/HQ7Rsd9Ye40B0bcv9f+cTUysR5cm2A3yF+nRHr+TaGXZlX6S0fp6Yzo1KOvCiizAnqxlvOSj6VnIyvrYlEL2xNapLdktDiyy2YcCkaV0XcB/IUeIJ01o+OyDuhorv8 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 May 2020 17:24:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 53A841962CDD; Sat, 16 May 2020 13:24:52 -0400 (EDT) Date: 16 May 2020 13:24:52 -0400 Message-Id: <20200516172453.53A841962CDD@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: me@junc.eu 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] dmarc.ietf.org does not fail 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: Sat, 16 May 2020 17:24:57 -0000 In article you write: >https://dmarcian.com/domain-checker/ test it there You're misreading what it says. The DMARC setup is fine. >if its complete impossible to not break dkim i will leave this maillist After you leave, you might want to review the ARC work we've been doing over the past year. R's, John From nobody Sat May 16 10:48:32 2020 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 C5C1E3A0A02 for ; Sat, 16 May 2020 10:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=isdg.net header.b=BGsH24dB; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gXbMmSNs 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 0oFcqveePu2x for ; Sat, 16 May 2020 10:48:29 -0700 (PDT) Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (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 B4EE93A09FF for ; Sat, 16 May 2020 10:48:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2634; t=1589651304; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=R8d7L/1Vt5TQ5bXNBfnZo9kiyGI=; b=BGsH24dBnmHunkfCBh0BeG1UvvPkCYcaJN1A71JlC3DoKUGQRr/lDHO2d8bjpR vtsYRhlVi3pukoGNGMb9s1PrNwA1bKikywWTY86OqsJFmM/rJrr34hvH/eK3YKDP oMNE/OI2xMahNucHtVbPOyp0aPOAlR0luHiM55CJcVURY= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 13:48:24 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 378635998.1.5836; Sat, 16 May 2020 13:48:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2634; t=1589650926; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=X12LKCf 65F0CsmulqYSwYJOes1SslbqX4za485BXjDo=; b=gXbMmSNst/vGuF/w78Ni6JQ hygTv1wTigZIP2cN2TR5113LJ8O7iMJ6y89k//SyZ5VXuoRvueVh8UPDyG97RsBD EYZN3rGT5hp+BEn6bezSc67vloWzU1WYvRoE6WzlKwMC0zHBGr1xuJlWEEWMFylI auLNr+jzsSxcMpLUrU18= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 13:42:06 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1384999921.3.12972; Sat, 16 May 2020 13:42:05 -0400 Message-ID: <5EC02769.9070508@isdg.net> Date: Sat, 16 May 2020 13:48:25 -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: Pete Resnick CC: dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> In-Reply-To: <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 17:48:31 -0000 On 5/16/2020 11:49 AM, Pete Resnick wrote: > On 15 May 2020, at 23:54, Hector Santos wrote: > > On 5/15/2020 2:26 PM, Seth Blank wrote: > > Should we consider adding JSON formatting to DMARC? > > Protocols should be flexible. Adding it doesn't mean replace. > > Flexible sometimes means less interoperable. You've already got to get > the XML right. Adding another format that you've got to get right > sounds like it increases the odds that an implementer is going to get > one of them wrong, and you've got to make sure that the XML and JSON > semantics match each other. As Dave said, unless there's a compelling > reason to add JSON, the potential for decreased interoperability says > to me this isn't a good idea. On 5/16/2020 2:09 AM, Pete Resnick wrote:> On 15 May 2020, at 23:54, Hector Santos wrote: > >> On 5/15/2020 2:26 PM, Seth Blank wrote: >> >>> Should we consider adding JSON formatting to DMARC? >> >> Protocols should be flexible. Adding it doesn't mean replace. > > Flexible sometimes means less interoperable. You've already got to get > the XML right. Adding another format that you've got to get right > sounds like it increases the odds that an implementer is going to get > one of them wrong, and you've got to make sure that the XML and JSON > semantics match each other. As Dave said, unless there's a compelling > reason to add JSON, the potential for decreased interoperability says > to me this isn't a good idea. One can suggest XML is also complex to get right. The direction has been with JSON for a number of years, especially with the JavaScript developers using established tools and platforms based JSON. The APIs are readily available. Just consider, when the spec has XML-only, then for those who use a solid JSON I/O system, they are now going to be required to add XML. So for them, its additional development complexity. Everything they probably do JSON related. The exception would be DMARC using XML. This alone can delay or push aside DMARC Reporting implementation. There are other formats: - CSV - Flat Name spaces, i.e. A.B.C.D Even the Authentication-Result: header(s) can be sent, the one the verifier would create. Even an ad-hoc reporter that people can read immediately the email without any additional format readers would work very well. Anyway, when it comes to product development, and this all being put together as a "product" by many key folks here, then "High Quality" flexibility (options) generally works to cover a wider spectrum of implementators. We assume it will be done correctly. -- HLS From nobody Sat May 16 11:10:32 2020 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 476433A0A4E for ; Sat, 16 May 2020 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=isdg.net header.b=k2uZzG3Y; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AV6rPEdo 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 sEWqpNSGJBW6 for ; Sat, 16 May 2020 11:10:29 -0700 (PDT) Received: from mail.winserver.com (listserv.winserver.com [76.245.57.69]) (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 801AA3A0915 for ; Sat, 16 May 2020 11:10:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=775; t=1589652619; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=uBIcvDbhsc7yZR+fUV5ak9H722w=; b=k2uZzG3YQtEDh2ZKWqk26Kzub4xil/qS/7BNM9sS0/gzrUS7r3kiEsK2z8x67K kZMP9BaslSxRHEaJW4abOYMJPT19T413Q0iKZscuiww9uVZAXQnHFFVyxhjoUH3I 795VYcspaw4/sV27nvzMnSfjt/3luNbN/lHNnFK7kUyTg= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 14:10:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 379951149.1.3128; Sat, 16 May 2020 14:10:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=775; t=1589652244; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=y0Qxe1q r01P43iOaahIa64dvmM3r55My5CzKEwjdUOA=; b=AV6rPEdoCO0gHgk93L50rkV cY77pIpbO6XD+GZrbXKJsKY7EeXLkkAlZcx96DLtEtdVCO2m6A8pCXF2HO8e1M0e S8jIR7OBcgPLEBJrn1kGn+PaSNOef0WzjVvkIdJOHWHOWiDkhKf5i5idPJDgHPPA KrzSTDsMZttu06NZ5aNA= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sat, 16 May 2020 14:04:04 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1386317984.3.9432; Sat, 16 May 2020 14:04:03 -0400 Message-ID: <5EC02C8F.90701@isdg.net> Date: Sat, 16 May 2020 14:10:23 -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, Dave Crocker References: <5EBF720D.8040608@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 18:10:31 -0000 On 5/16/2020 2:41 AM, Dave Crocker wrote: > On 5/15/2020 9:54 PM, Hector Santos wrote: >> Protocols should be flexible. Adding it doesn't mean replace. > > Explain the need. > > Convince plenty of folk that it is necessary enough that they are > inclined to write the code, deploy it, and use it. Adding things is > expensive. > > Flexibility that does not have a clear need is especially expensive. A rather large point to consider, with many 'Modern' developers today, the "expense" would to fallback to XML when in fact, they are using JSON regularity and increasingly for new protocols and I/O exchanges. I personally prefer an easier ad-hoc reporting format for immediate reading by the laymen and not be dependent on XML or JSON readers. -- HLS From nobody Sat May 16 11:45:59 2020 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 87CD13A0765 for ; Sat, 16 May 2020 11:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgLIFlQGPWe6 for ; Sat, 16 May 2020 11:45:56 -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 5A1263A0764 for ; Sat, 16 May 2020 11:45:56 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id e1so7178880wrt.5 for ; Sat, 16 May 2020 11:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uz5WoUhqbd/OhT64O26A9uaiEC/pJ/NrIMrhznFxVDg=; b=ECEmRN92ge4uiRJSgEl00hBdoNugHjMDqTcaRaIAPGqfTA88/jdrSCHxOvhKKO5ImS 4h1mdi+UqEfZ+21kWE5C4i7wf8iz5JNkwUno2JRAkRAfQ4rFUciZQoTV0+39rKTYlhNJ uwU6z+lEmm0VWwCoSr+WZQQHPQ5nWhJlhXt509tRJKmTONqseGppSMMOPcMMAXn24Vhs FJ6BXAz+TjQq0ImmwFZfTnBSVdIyK6SIl7/mHjbNiJVgKsdI0vBlqjV/7L/jN7xfFLk/ W6T7xBfcI6zJdyHd1X7E+BagjWgOZLUqGu3Fsl0JOmcZm4Ua96Wa2TAQjkkN/hMbrl11 nd2A== 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=Uz5WoUhqbd/OhT64O26A9uaiEC/pJ/NrIMrhznFxVDg=; b=I1EJiVypmCDapFBHy4aShzZQFIlB/Qd9oq5oFI9nbELqVn3uw0YdzWJUz5OhhyAcPg cfHTfSfL9K3vWUz5ze6T1QIBzp3SWl3iinGDEjWw/Xwzhsh75edNm1DhxKOi66spFrtp zHrSmsLXZz8r3zAfemXGPbEuStBSUAi/oxDRgJQ/kOZvwZJAxS8eMBPpXTrqk+DR4dS6 5i8Qm/HSHW8eYVxrrtPussNye4I1VYVmr5vetNIwLtql0vUhakAInvsUg55m+soTV+Fv LDBs9n/wg7b044FtFBFkj2KI5I5Kv7Qqq4LfEjj3mVwJSBUnEDjy8gbW9ICCNhnVl7xk MNVg== X-Gm-Message-State: AOAM533vi6Mo0ZQTJdAz6SRO/c9HltZqZiv1ug2PtKQiR744eu7CQ2h4 Z4jV9OPEcVNikC8+iROnjSyF2zy3GABIq8QgEbFQ/QsJ X-Google-Smtp-Source: ABdhPJxdGaibVP/asGyd4eg3GTZs6GwV8W1K78FbEfmzUSFUse1/c2pQESGGAjZ3fdW57Cv+zLJgL++EBm5ENgqblSw= X-Received: by 2002:a5d:40d0:: with SMTP id b16mr10625842wrq.218.1589654754449; Sat, 16 May 2020 11:45:54 -0700 (PDT) MIME-Version: 1.0 References: <20200516021946.97571195FB9E@ary.qy> In-Reply-To: <20200516021946.97571195FB9E@ary.qy> From: Seth Blank Date: Sat, 16 May 2020 11:45:43 -0700 Message-ID: To: IETF DMARC WG Cc: John Levine Content-Type: multipart/alternative; boundary="000000000000f46ee705a5c856a0" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 18:45:59 -0000 --000000000000f46ee705a5c856a0 Content-Type: text/plain; charset="UTF-8" On Fri, May 15, 2020 at 7:20 PM John Levine wrote: > In article < > CAL0qLwaSKZDyEqnJs-BJ4TTfdGeVFC8gAuKMVNOst0wj3GEQ4w@mail.gmail.com> you > write: > >+1, unless there are known cases where the XML payload size is a problem > >that switching to JSON would solve. > > It's gzipped, do I doubt it would make much difference. Gzip is really > good at compressing the boilerplate strings that make XML bigger than > JSON. > > Also, FWIW, in seven years the largest report message I ever got was > under 300K, and if people really are concerned about big reports, I > would much rather revive https reporting which avoids base64 encoding > and doesn't have to buffer copies of the report for relay. > Hatless, as a data point: at Valimail we see reports that are hundreds of megabytes in size, and sometimes push close to a gigabyte. These reports continue to increase in size month over month as sending volume, geographic footprint, deployed third party services, and fraudulent mail attempting to impersonate the domain continually increase Seth -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f46ee705a5c856a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2020 at 7:20 PM John Levi= ne <johnl@taugh.com> wrote:
In article <CAL0qLwaSKZDyEqnJs-B= J4TTfdGeVFC8gAuKMVNOst0wj3GEQ4w@mail.gmail.com> you write:
>+1, unless there are known cases where the XML payload size is a proble= m
>that switching to JSON would solve.

It's gzipped, do I doubt it would make much difference. Gzip is really<= br> good at compressing the boilerplate strings that make XML bigger than
JSON.

Also, FWIW, in seven years the largest report message I ever got was
under 300K, and if people really are concerned about big reports, I
would much rather revive https reporting which avoids base64 encoding
and doesn't have to buffer copies of the report for relay.

Hatless, as a data point: at Valimail we see report= s that are hundreds of megabytes in size, and sometimes push close to a=C2= =A0gigabyte. These reports continue to increase in size month over month as= sending volume, geographic footprint, deployed third party services, and f= raudulent mail attempting to impersonate the domain continually increase

Seth

--

<= span style=3D"vertical-align:baseline;white-space:pre-wrap;font-size:small;= font-family:Arial">Seth Blank | VP, Stand= ards and New Technologies
<= b>p: 415.273.8818

=



Thi= s email and all data transmitted with it contains confidential and/or propr= ietary information intended solely for the use of individual(s) authorized = to receive it. If you are not an intended and authorized recipient you are = hereby notified of any use, disclosure, copying or distribution of the info= rmation included in this transmission is prohibited and may be unlawful. Pl= ease immediately notify the sender by replying to this email and then delet= e it from your system.

--000000000000f46ee705a5c856a0-- From nobody Sat May 16 12:37:28 2020 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 563333A0820 for ; Sat, 16 May 2020 12:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=UiPcinbD; dkim=pass (1536-bit key) header.d=taugh.com header.b=1bwIajNO 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 1Xr2RkXoeFpC for ; Sat, 16 May 2020 12:37:25 -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 D31CC3A07F9 for ; Sat, 16 May 2020 12:37:24 -0700 (PDT) Received: (qmail 30380 invoked from network); 16 May 2020 19:37:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=76aa.5ec040f3.k2005; i=johnl-iecc.com@submit.iecc.com; bh=sv9h2mi3JAm9hGo/9mGaGmSmoQWKvnmdC22ERID8Ai4=; b=UiPcinbDcNTs3EDFzmdk4iwkmCUltmHZcCMq2jLePbfyts8/uNPWC6+Mau7KzQuPCesLQlQYTvznu6HgzHV2brrMEZV5GoZjjw1Mna7BhvK5PsGGERMC81/oSq5It2LLu5bj9GrsC+CjgsXYTl9Y+Igz0Ey24ObfP0278UANKvwdZ+dI1t6bx7VRM3qM5cRZ8T+4alYvfxE9GgtPE01002J2zjHb7x4e/hsEifKNneBmyraiSXoxE1xvE/Sv+anx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=76aa.5ec040f3.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=sv9h2mi3JAm9hGo/9mGaGmSmoQWKvnmdC22ERID8Ai4=; b=1bwIajNOJ07DqQUj7iuaEFp8A3S39aHq5hRt/KhUZJlcXyWDDQYj+JQI595B+bZYAUAg2AMnrURQ5a5AqjDbs9VOHZyPDg5ZWNJbjb/pyw1a7sU1OcIWDQ44AA04fU/c/kCQu5iR3H6lKm/20CTlvoU6I/h6Xh6cKChKqMoAp35v9FCOXT2hHb7wvRn6xmTF/84elC+hfCZOOePhK5tlKn6k0IKusY/CuCCPy5L7acak/v8glcutDd5VsMDYA2jX 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.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 16 May 2020 19:37:23 -0000 Date: 16 May 2020 15:37:22 -0400 Message-ID: From: "John R Levine" To: "Seth Blank" , "IETF DMARC WG" In-Reply-To: References: <20200516021946.97571195FB9E@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 19:37:26 -0000 > Hatless, as a data point: at Valimail we see reports that are hundreds of > megabytes in size, and sometimes push close to a gigabyte. These reports > continue to increase in size month over month as sending volume, geographic > footprint, deployed third party services, and fraudulent mail attempting to > impersonate the domain continually increase I believe you, but switching to JSON would not make any difference. The reports are gzipped and the extra verbiage of XML is all squeezed out in the compression. I have a 4.1 meg XML report that zipped to 136K, about 3% of the original size, which I think is a typical ratio for reports of any size. E-mail is a lousy way to send around gigabyte files, so we should make https work. Semantically HTTP PUT is the right way to do it but HTTP POST like mta-sts does would be OK. It uploads a binary application/gzip version of the report so it's about as efficient as it can be. R's, John PS: Another think we might consider, although it would be significant work, is to add application/bzip2 as a compression type. That 4.1M XML file crunches down to 51K as bzip2. It has some issues, it's not well documented other than by the reference implementation, and it'd be yet another way for things not to interoperate so we'd have to add a signal in the DMARC record to say that reports can use it. From nobody Sat May 16 16:56:20 2020 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 1A15B3A0C1E for ; Sat, 16 May 2020 16:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=crash.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 N47RWkMuL8zt for ; Sat, 16 May 2020 16:56:17 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [72.52.75.15]) (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 049673A0C1D for ; Sat, 16 May 2020 16:56:16 -0700 (PDT) Received: from [10.10.10.41] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 04GB22DV080438 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 16 May 2020 11:02:21 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 04GB22DV080438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1589626943; bh=ZEH2vYzuENU0aTQtxXYcTIk5RyDWwSyC72jcOpknSzQ=; h=Subject:To:References:From:Date:In-Reply-To; b=Z4NDFzcYIi9Z1FqfmuFqApsHGPeVfnbKHqslmHaIVmZnVQWQ+Y+DnEU0JrD9RYduN oTsV9ScwBaGN3pTs5OOn2VekeOVFwlR/fTHDhhQSyExkiyfkQascAnEadS3QBlCguA z1j/47nRC/RHp2RjgGbtHjCKEPOjICGDDPQMksHW1uLsK9SPt1KuWyDvcfg72q/uLJ TkgzBmbZ2MMbmwVwmpDwsI/8pw72b6U8dRx2M3LbXTW2w0RvNsDyhLLffQALKkjn7o XDEeYpXKJlU7ukSer4pGIdBKCD1ydt6cxqjjLzyfHm/xhApVFMnyw6+aiYbH2f583K ank3aK48mmRuw== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.41] To: dmarc@ietf.org References: From: Steven M Jones Organization: Crash Computing Message-ID: <9659d522-22dd-e412-8bcd-e3866e4e5b77@crash.com> Date: Sat, 16 May 2020 04:02:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 16 May 2020 11:02:22 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 23:56:18 -0000 On 05/15/2020 11:26, Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/69 > > Aggregate reports are only sent in XML format. There's been some > discussion (that's also related to > https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting > functionality beyond mailto:), of adding additional reporting formats, > specifically JSON. > > Should we consider adding JSON formatting to DMARC? I don't see the benefit. Can anybody make that case? More overhead to maintain, more opportunity for errors. Does adding JSON somehow eliminate the anecdotes about report generators who have issues with their XML output? Any reason to think that wouldn't also happen with JSON? Does adding JSON reporting solve one of the other open tickets? --S. From nobody Sat May 16 16:56:57 2020 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 F41EA3A0C1E for ; Sat, 16 May 2020 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=crash.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 uEU4n7eh4khp for ; Sat, 16 May 2020 16:56:54 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [72.52.75.15]) (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 D3C803A0C1D for ; Sat, 16 May 2020 16:56:54 -0700 (PDT) Received: from [10.10.10.41] (135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged)) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 04GB6jNY040720 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 16 May 2020 11:07:04 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 04GB6jNY040720 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1589627225; bh=QPAHVPTSH8HWHPhMvXAGtu/EMeYLj74T9kLzCyvg0X0=; h=Subject:To:References:From:Date:In-Reply-To; b=DxRk3FuXY+xQs7rVEcOQPeVaY/DwzuQUN7g7eWOCQvv5PKzUtuZayajeokeR+1dt+ UXroZXTJxUbWBQAxVVk3Aka4M7EFhwmmoCWvjK3Aj9+HVlJ8kuT9AlOcKdlShhjFIP TgqQnqZ3K+3YqwJ1zFgmAG1wgrfHSLvclK+FkRXOKADtMLeKYhmAccTRIvWYGfoTuz a+0kJOvcYm9aGjuUzcK4ks9H7+P8xegkN/LB/BBCva8WLVumXCcid7hTUxgJ/YPE9v SX26JqOEqqrEvC4mSQbdIWULrKy+6jKFWBKJFBH4XHrbP/wQF/aAndfuiuxoPy5ZvR NErpR09i3ewTg== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.41] To: dmarc@ietf.org References: <3193525.cVJkX3U5sK@sk-desktop> From: Steven M Jones Organization: Crash Computing Message-ID: <8f5d3f7a-b8a0-1ff7-0930-02a8decdc777@crash.com> Date: Sat, 16 May 2020 04:06:45 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3193525.cVJkX3U5sK@sk-desktop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 16 May 2020 11:07:04 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 16 May 2020 23:56:56 -0000 On 05/15/2020 13:16, Scott Kitterman wrote: > > When there is only one report format, there's no need to discover a common > format between report senders and report receivers. As soon as there are two, > then to be interoperable, then either both report formats are required or > there has to be some kind of discovery mechanism, because we don't want report > senders sending reports in a format the receiver can't parse. And every time we add another flag or k/v pair we're adding another way for the domain owner/manager to screw up and invalidate their published policy. Something to bear in mind throughout these deliberations. --S. From nobody Sun May 17 09:54:40 2020 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 928C33A0991 for ; Sun, 17 May 2020 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4lrLvGpKQirj for ; Sun, 17 May 2020 09:54:38 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 0741F3A0990 for ; Sun, 17 May 2020 09:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589734474; bh=hFpzaamB20ljWT4o1cKxFclejSFjrTm5+C9X+OlL/zY=; l=1328; h=To:References:From:Date:In-Reply-To; b=AcRcfmGxzSSdRbrGR28tocgfrUM9aZdHlKSn206rcSzpLXRLpmlYJg3b6J2T1OESS HnHNUbsnhE9YdBt5VeEXJOK6pX/m4opoavPHb3BnvWsr94PNWqrVH+ZWltU5RQLgWw s7Lu6ni2KoALMQcyPPJMQkYw4lW3j0D+sOcbvBuveLRxS8QLzq6SBNAAAMRPU 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EC16C4A.00006A5C; Sun, 17 May 2020 18:54:34 +0200 To: dmarc@ietf.org References: <20200516021946.97571195FB9E@ary.qy> From: Alessandro Vesely Message-ID: <195b9733-a5ea-9e92-aebe-df8b5e6f7da2@tana.it> Date: Sun, 17 May 2020 18:54:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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] DMARC bis: ticket 69: add JSON reporting format? 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, 17 May 2020 16:54:40 -0000 On Sat 16/May/2020 20:45:43 +0200 Seth Blank wrote: > On Fri, May 15, 2020 at 7:20 PM John Levine wrote: >> In article you write: >>> +1, unless there are known cases where the XML payload size is a problem >>> that switching to JSON would solve. >> >> It's gzipped, do I doubt it would make much difference. Gzip is really >> good at compressing the boilerplate strings that make XML bigger than >> JSON. >> >> Also, FWIW, in seven years the largest report message I ever got was >> under 300K, and if people really are concerned about big reports, I >> would much rather revive https reporting which avoids base64 encoding >> and doesn't have to buffer copies of the report for relay. >> > > Hatless, as a data point: at Valimail we see reports that are hundreds of > megabytes in size, and sometimes push close to a gigabyte. These reports > continue to increase in size month over month as sending volume, geographic > footprint, deployed third party services, and fraudulent mail attempting to > impersonate the domain continually increase Another way to halve the size of the reports is to halve the reporting interval. I think this can be made clearer in DMARCbis, so I added ticket #71. Best Ale -- From nobody Mon May 18 01:28:00 2020 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 6126B3A0976 for ; Mon, 18 May 2020 01:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7sJiyHXT4RRx for ; Mon, 18 May 2020 01:27:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E5A6A3A0972 for ; Mon, 18 May 2020 01:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589790473; bh=383pfew2iaKGrCV6YjjDI1k5Gjdn9zU6NknfznIxMMg=; l=1570; h=To:References:From:Date:In-Reply-To; b=AwYSDDK1+2RwBju/FZnKAYFFY0WY09udt5YilgSUul7WUZl5ZBDUQv6vpoEtx2GH6 QwezRBdIXQAriQUVjL05LYVujcdyn2swSYxd5GasxV94U3nhItC2M81v8ZkNW29F6C jhY9cWzIpR3tjYBzwjl2hVWTo/K6FRNuApybaGQsJfOqAW11ELf/S0v0t/Nfr 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B7.000000005EC24709.000006F5; Mon, 18 May 2020 10:27:53 +0200 To: dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> From: Alessandro Vesely Message-ID: <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> Date: Mon, 18 May 2020 10:27:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EC02769.9070508@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 18 May 2020 08:27:58 -0000 On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote: > > One can suggest XML is also complex to get right. The direction has been with > JSON for a number of years, especially with the JavaScript developers using > established tools and platforms based JSON. The APIs are readily available. Yet, XML has style sheets, XSLT, that JSON seems to be still missing. A noticeable amount of web stuff uses XML and XHTML. Dropping those languages entirely is a harsh decision for an online entity. > Just consider, when the spec has XML-only, then for those who use a solid JSON > I/O system, they are now going to be required to add XML. So for them, its > additional development complexity.  Everything they probably do JSON related. > The exception would be DMARC using XML. This alone can delay or push aside > DMARC Reporting implementation. So you intend to ease report producers... How about consumers? I figure producing reports is quite easier than receiving them, once you have the relevant data structures. You don't need an API to write the data, you need it to parse. Since receivers have to verify report correctness and trustworthiness, /they/ deserve the right to decide what language they want reports to be written in. That is the kind of approach taken for failure reporting, where receivers can specify by rf= "a list of one or more report formats as requested by the Domain Owner". Disabled developers who are unable to produce XML reports can still resort to automatic translation by json2xml. Best Ale -- From nobody Mon May 18 05:25:27 2020 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 E72C43A0B4A for ; Mon, 18 May 2020 05:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 4y7V3xiXXFX2 for ; Mon, 18 May 2020 05:25:25 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 D98DE3A0ADF for ; Mon, 18 May 2020 05:25:24 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 7894C7FE81 for ; Mon, 18 May 2020 12:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=183; q=dns/txt; s=default; t=1589804724; h=from : subject : date : to; bh=V0LUpfG8MX06nNxzugC4kfXEvPausKDDoNSlOIKH6AU=; b=PkR4pxU4SqOXh2mbc2jhAaULfjTWuxZE/gaTgP82U8n4lole0HvQ6u2oEp8l6d8kQ1zh+ 3gBozCDy1xNaA0oM7iPNBVhJ28zJgPlkKV6C7HscR5FS3n6iEEGq1TJZiNIzwx+WnRq2HqG 8qMAsQoVdwTCO79pp++qRDLoDA7Hhek= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 535557FC9A for ; Mon, 18 May 2020 12:25:24 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 May 2020 14:25:24 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> User-Agent: Roundcube Webmail/1.4.1 Message-ID: X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 18 May 2020 12:25:26 -0000 On 2020-05-18 10:27, Alessandro Vesely wrote: > Best > Ale > -- > could you remove empty lines in your signature ? lets see dmarc fail, dkim invalid test in spamassassin From nobody Mon May 18 12:51:49 2020 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 898513A0AB9 for ; Mon, 18 May 2020 12:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 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 dOj2eV4OIG8X for ; Mon, 18 May 2020 12:51:33 -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 599BD3A0A40 for ; Mon, 18 May 2020 12:51:32 -0700 (PDT) Received: (qmail 54511 invoked from network); 18 May 2020 19:51:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d4ec.5ec2e743.k2005; i=johnl-iecc.com@submit.iecc.com; bh=lZ8IVURMCfMevU/QoRqIfT402kRdpMkMZacdQySG35U=; b=u8mpauYGGYofnXwhfbHffwsBMpk0GWKcloxFsT3Ow+u1489F0HxNPkmyrYIgshlsptlXiw5l9rl2TE+dUwIOSIesZh3cdKTtpoRQDsngUYcRvqe4vaZAx1NB+AVkynCD5O//WDkMOIBGR7maTwqUguDA5Do4RbzlaoQZ67pn61rm7BLbjpIv8J0d3fMVGr+sWJF85haxGMAAPvmuNG/6hJtG12gH1EV5+P9i6uf+jdz/MZpHGAiyYcnqbP8UniSs 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.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 May 2020 19:51:31 -0000 Date: 18 May 2020 15:51:30 -0400 Message-ID: From: "John R. Levine" To: dmarc@ietf.org In-Reply-To: References: User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 19:51:37 -0000 While the setup for dmarc.ietf.org was correct before, it was pretty funky. I suggested they make a few changes which they have now done: there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX record pointing at the mail server rather than A/AAAA records. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon May 18 12:59:49 2020 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 33F093A0DEE for ; Mon, 18 May 2020 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 2yZatj7qDR5D for ; Mon, 18 May 2020 12:59:41 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 0BF4D3A0CF5 for ; Mon, 18 May 2020 12:59:37 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 794A57FCF9 for ; Mon, 18 May 2020 19:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=590; q=dns/txt; s=default; t=1589831978; h=from : subject : date : to; bh=eH02W/FZ6f1+1mMwVmylorFxNY7MR0nW7vAnMQOCfWw=; b=Sl9KTIiaGH6c0F9Sla1XflamY6pOxhBeFto3tvLzX5cb91J3d5psQMB/lmm1NgjLroKE2 gvqbwkqOv+uUdnkwg8mzc5YY/k4OC6Ei8OWBC75b0aR4kNCTeMC87jmfLni//VT3S6790B+ Xn76xd7eSljj1HCwDmbD3FeHzYx141s= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 5E2887FC9A for ; Mon, 18 May 2020 19:59:38 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 May 2020 21:59:38 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.1 Message-ID: X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 19:59:48 -0000 On 2020-05-18 21:51, John R. Levine wrote: > While the setup for dmarc.ietf.org was correct before, it was pretty > funky. +1 > I suggested they make a few changes which they have now done: there is > now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX > record pointing at the mail server rather than A/AAAA records. spamassassin still says dkim invalid here not using sid-milter, opendkim, openarc, opendmarc or even python based dkim validators, pure perl Mail::DKIM 0.440 in gentoo sorry if its my own fault i self use fuglu 0.10.6 to dkim sign From nobody Mon May 18 13:02:50 2020 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 540373A0BA8 for ; Mon, 18 May 2020 13:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xRm86W4nr12D for ; Mon, 18 May 2020 13:02:46 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 9C8E63A0BC6 for ; Mon, 18 May 2020 13:02:46 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id b3so2240578oib.13 for ; Mon, 18 May 2020 13:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nakdmEqTGehGbL7aYeHmD39nk9qu6hWgxenCCksJvec=; b=s2UpG7gZYFaNYjh3ybssJBAsyKdU47MVdEYoiT0LLNaRETbkg0FaoT6a3HJXzmmX7c iy0tr+7CfGU/MBK2uOPqfAG+Cm32FNzcTTYhpOesVEdp5b5IgOBqGsiVWzEc3WpoDK+H 9fpOY21C6CiHjkVXyMZd6LrDirBBQwEc53MCL09DTLPDWllRQ8rZ8ThnYbNKfbt9qeip 9u1pAYEEgdOBw48o87RheBI8m5+EkakOgdIUfFY38zSt0X+8HAAN4XxpCwkiBXbQX/EK 53bwAO4gMxdajiSL7xo9siie1pSl0Vg9BSLN/ZS6L5XMrAp8qNgGoS3Llm8kkLS6a2ZU Y5XQ== 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=nakdmEqTGehGbL7aYeHmD39nk9qu6hWgxenCCksJvec=; b=rRFIj45FDMAALXOherNEQw2HfK9VCFuANEPCWwTWfZZMboNOauUDVPqXoFbi0KOgPD 0oYD0hUq68T1cD7jq+PEm3CB6y5ENcuBYCrJtq2Ww1NV6hOsPlDKYyAoMv78obxPqpsT IaK/QRZNiT6ux3zeTs0lh/sWcVZXjRfKkJqrKJ1Hw7DXkLZXChT6bdzqEBLvuLHb4ItL iIWyx93DIbcLOCMPCWhRxE7uf3phhf32m+mPwhgPCrNcnWQte93r6qDCIu5XORkOGD+M H7lv6rx+1GaBUF5Y5k3+m/B/8ceW18/itZZl8aUC2Cd4ekDYdBVcFULhKgRdXNpa861P Napw== X-Gm-Message-State: AOAM531eWGACSASoImg6aJXJeYJLHOOCC1fWJCVrEZsrznbiZWY01hmR knvRUAIYxuSNTB0IxVShRDbfIg1B4KLAzqjr9XBZtaA1 X-Google-Smtp-Source: ABdhPJwyT65MBhtpqdmF2EkUEfRuZ1c0YFrsDWPL3Ke8bEnS605GDVn4CtUgwnCczI6Khx4EUMcVQ800i9Rv1EGB/K4= X-Received: by 2002:a54:468e:: with SMTP id k14mr790875oic.132.1589832165990; Mon, 18 May 2020 13:02:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 18 May 2020 16:02:35 -0400 Message-ID: To: "John R. Levine" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000081a55b05a5f1a510" Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 20:02:48 -0000 --00000000000081a55b05a5f1a510 Content-Type: text/plain; charset="UTF-8" +1 John and thanks. tim On Mon, May 18, 2020 at 3:51 PM John R. Levine wrote: > While the setup for dmarc.ietf.org was correct before, it was pretty > funky. > > I suggested they make a few changes which they have now done: > there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there is > an > MX record pointing at the mail server rather than A/AAAA records. > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > 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 > --00000000000081a55b05a5f1a510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+= 1 John and thanks.=C2=A0

tim


On Mon, May 18, 2020 at 3:51 PM John R. Levine <johnl@iecc.com> wrote:
While the setup for dmarc.ietf.org= was correct before, it was pretty
funky.

I suggested they make a few changes which they have now done:
there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there = is an
MX record pointing at the mail server rather than A/AAAA records.

Regards,
John Levine, johnl@tau= gh.com, Primary Perpetrator of "The Internet for Dummies", 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
--00000000000081a55b05a5f1a510-- From nobody Mon May 18 13:08:03 2020 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 77CE73A0BE0 for ; Mon, 18 May 2020 13:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 JottlNwNAQA2 for ; Mon, 18 May 2020 13:07:58 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 2DCE33A0BDF for ; Mon, 18 May 2020 13:07:58 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id EB4B17FF39 for ; Mon, 18 May 2020 20:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=150; q=dns/txt; s=default; t=1589832478; h=from : subject : date : to; bh=mD3kj5VczgyC6b7ei0PvJO70kyVE+qGU42AXCUPWlG0=; b=qFmbbo9YICB8JbQ8ybXuB0qT6A6sK2gr1pIamKu00W9qKMbong+wNh1FdSNxaxY3wyWvC nnv8A6FYGUon8oS3a6pq/sbrBfNBP0KSW17amPS6rqgDiWLKJVTDCeEb/73/fzYfanxBwO7 3SL7+ExZv+0fYXEmMqxSFEGIujKBeZQ= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id D1EC07FF34 for ; Mon, 18 May 2020 20:07:58 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 May 2020 22:07:58 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.1 Message-ID: <46c8d2d63145c96faafdda802d5b2a3c@junc.eu> X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 20:08:02 -0000 On 2020-05-18 22:02, Tim Wicinski wrote: > +1 John and thanks. this mail is dkim valid au here, hope to see posts from John that is pass aswell From nobody Mon May 18 13:31:32 2020 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 AEF7C3A0BFA for ; Mon, 18 May 2020 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EqqUUPV6; dkim=pass (1536-bit key) header.d=taugh.com header.b=XBJrd0KO 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 WVzrKV30wpk9 for ; Mon, 18 May 2020 13:31:27 -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 89A763A082D for ; Mon, 18 May 2020 13:31:27 -0700 (PDT) Received: (qmail 64245 invoked from network); 18 May 2020 20:31: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:mime-version:content-type:content-transfer-encoding; s=faf3.5ec2f09e.k2005; bh=Ah2RN2LWIEsrpXe1/pYCxocat2fHqi4ChF2Im5dHaFw=; b=EqqUUPV6Qm5Hm9KES0R0CDAtVrQlxElEGZuvrWhwOnpgO2tKU+axTW9k2TcfFqy/NeVkS6ruCfMnqbN/5SZkD8J5iCKtuP3mBg6b5y+z91SKItDX3vD8AuCfyCN+NrNDSmZt3i7IAYqvzxvwe47CBU2nPJvCOLYYzMTnHvJdyC93u7FCFGTj6LASeNv9cx987YdgOfY9hWP7w7be+JVb3dKfWOvjJ5ZsHJEhSVcm7BUPQRXx+w8UqfEXf0FLyT9x 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=faf3.5ec2f09e.k2005; bh=Ah2RN2LWIEsrpXe1/pYCxocat2fHqi4ChF2Im5dHaFw=; b=XBJrd0KOQRcBv5TlTjBGZaNKV5p0qOokeoy+yOyW2SO3FnEJtJxp9C2Iv0VEils9jmgmNYiCtRxhDb8GSlagUBduursMKSzIJtQI1jPzrsWJ/XX85AR1QhPOGPBEaX8ZdpHQtRSLNRaami2yoj5IDjnzRc2AwdL3VSQPQZf6G644ttSkPfPBMnrbwTjVHPOP7RF2sFLWNIfEvpTRj8fuKd8Gh+ackwOvviZebYoPMb4w4eKYVNX3LZlctKyyoz0i Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 18 May 2020 20:31:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 0B3B2196F101; Mon, 18 May 2020 16:31:25 -0400 (EDT) Date: 18 May 2020 16:31:25 -0400 Message-Id: <20200518203126.0B3B2196F101@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> 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] DMARC bis: ticket 69: add JSON reporting format? No. 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, 18 May 2020 20:31:31 -0000 In article <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> you write: >Since receivers have to verify report correctness and trustworthiness, /they/ >deserve the right to decide what language they want reports to be written in. There is lots of freely available code to parse DMARC XML reports and put the results into a database or otherwise interpret them. You can find my scripts here: https://www.taugh.com/rddmarc/ The part of my routine that parses the XML into internal form is about three lines since it uses a generic XML parser. There are vast numbers of sites producing and consuming XML reports. They interoperate. It works. There is no problem to be solved here. Can we stop now and work on something else? R's, John From nobody Mon May 18 13:32:28 2020 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 40B013A0C2A for ; Mon, 18 May 2020 13:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=VVUwMaCE; dkim=pass (1536-bit key) header.d=taugh.com header.b=BfrrqnCy 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 6JRdUgJdT-Ba for ; Mon, 18 May 2020 13:32:23 -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 F21863A0BFA for ; Mon, 18 May 2020 13:32:22 -0700 (PDT) Received: (qmail 64655 invoked from network); 18 May 2020 20:32:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fc88.5ec2f0d6.k2005; bh=HKyIJKzuJp1lYQyWuzwT5gUnMZOE4vvNa3Nd2FscQzQ=; b=VVUwMaCEcVivIjj2giWfQ2cgCP2Ln9OOcqgubnyUraXyHDdzA02k2cyesMTVCY6o/BNjACnWE9bSFA82ANpMMNzN1BDc+44PhHxCuGwWsm/TTyIIe+MaHOKbEw6rDsZzXfTz+qUyitx6pTAv0zBvMbOuIK8TJztv5wKlm7d4hcxVn4tEaMZIFBJHrVuLAL6uaWexnsJcM9qslIw8xx+w+PNlv3lDYQ01kYryQbN0lFx2nJGPiHFx7ooM/4TmThqz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fc88.5ec2f0d6.k2005; bh=HKyIJKzuJp1lYQyWuzwT5gUnMZOE4vvNa3Nd2FscQzQ=; b=BfrrqnCyjuGZZbA9R3GY/IF2aXgkg7+6ZUZLtXpoxBdi1WcfC4GcGGk5MUju7+s/IBpSx+rEL+WgMSSM6hMaN1CMJBXpdz+ci0oyNjO7uspbOZ8ELpXHx8fezvoxQuz0gm8/Lv7wEAqZ4OQIDnOk3ERPl0+PDhj/DJHK30IYqq7Z+6NnrfZ3fFLardawdn5GHM8SxPzJ7Xr8YM1prlABSdDWWjAZkCKRLfhuRN/5EgoW1hM8M/mDCWQG2D0iKtvT Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 18 May 2020 20:32:21 -0000 Received: by ary.qy (Postfix, from userid 501) id 934EE196F111; Mon, 18 May 2020 16:32:21 -0400 (EDT) Date: 18 May 2020 16:32:21 -0400 Message-Id: <20200518203221.934EE196F111@ary.qy> From: "John Levine" Reply-To: abuse@no.sp.am To: dmarc@ietf.org Cc: me@junc.eu 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] dmarc.ietf.org failed 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: Mon, 18 May 2020 20:32:26 -0000 In article you write: >> I suggested they make a few changes which they have now done: there is >> now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX >> record pointing at the mail server rather than A/AAAA records. > >spamassassin still says dkim invalid here Yes, that is correct. I would suggest learning more about DMARC and why that is not a problem. From nobody Mon May 18 13:42:30 2020 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 D4D5F3A0D83 for ; Mon, 18 May 2020 13:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 TdGdJaZD4KvZ for ; Mon, 18 May 2020 13:42:27 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 6CEFB3A0F9D for ; Mon, 18 May 2020 13:42:17 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id D8B547FE81 for ; Mon, 18 May 2020 20:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=239; q=dns/txt; s=default; t=1589834537; h=from : subject : date : to; bh=oVgxjp0UWJzo56/78oynHlND+/1NHlPzuhk81L0k5p0=; b=zPGou27pduyVp79GNfnZ6mme68FaemELJNpkelmN+xGXgqnlsfWh50CCFIkbkXNJO+O3d NursItAPmVvN5P2UdKH62UO2THIPKbbvVw7TqUlHPda5INMwgn9f/czvXkRX4tzAiY7XfRK Aps05wnqPIMRgxrA401WgG1saHuu1ks= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id BC03F7FC9A for ; Mon, 18 May 2020 20:42:17 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 May 2020 22:42:17 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <20200518203221.934EE196F111@ary.qy> References: <20200518203221.934EE196F111@ary.qy> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <69685109c92a41e9922df08af1768f71@junc.eu> X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 20:42:29 -0000 On 2020-05-18 22:32, John Levine wrote: >> spamassassin still says dkim invalid here > > Yes, that is correct. I would suggest learning more about DMARC and > why > that is not a problem. i will when spamassassin supports dmarc From btv1==407f3a65f69==fosterd@bayviewphysicians.com Mon May 18 15:09:40 2020 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 E4DF13A0404 for ; Mon, 18 May 2020 15:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=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 EXdM7_9WngXa for ; Mon, 18 May 2020 15:09:36 -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 9B6AD3A03FF for ; Mon, 18 May 2020 15:09:35 -0700 (PDT) X-ASG-Debug-ID: 1589839772-11fa31073365c7c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id PNPadz1x5zyAMwQY (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 18 May 2020 18:09:32 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 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=pROMmrD3hZZavNZ0FXjNDEyjQqJh8iRU/3H2v7cLE4U=; b=j+oiSPJBxcYtzKtzkCMhzGkVSCBgse/N+fxBw5nmwroevl7NpO7qRFN5DbR2t42Ur XSWPvwQIDEwP4XSReUg3ooBEgui9Pef/zyur3nm+m/hzGRWMKa8AIZAhxFI7sJuLn fYO+liA5vDQNpHDT16Oi4QX0uxVJe7na8RSTfPC1Y= From: "Douglas E. Foster" To: Date: Mon, 18 May 2020 22:09:24 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] dmarc.ietf.org failed dmarc Reply-To: fosterd@bayviewphysicians.com Message-ID: <0127a137400d466095373373ec887b90@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=b0a9ef0ea15546f5a26dc3df33b83daf In-Reply-To: References: X-Exim-Id: 0127a137400d466095373373ec887b90 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1589839772 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: 6235 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.81942 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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: Mon, 18 May 2020 22:12:12 -0000 This is a multipart message in MIME format. --b0a9ef0ea15546f5a26dc3df33b83daf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I understand your question to be "Why do I see invalid DKIM signatures on m= essages from the IETF mailing list?" I can provide your answer The typical message on this mailing list has three signatures: Signature Analysis: The first signature is from the submitter's organization. In your message= , it was from junc.eu. The second signature is applied by IETF shortly after receipt of the messag= e. IETF adds an Athentication-Results header which indicates that the junc.eu = signature was valid when they checked it .Then, IETF changes the FROM address to be @dmarc.ietf.org and tags the Sub= ject with [dmarc-ietf]. This breaks both of the first two signatures. Then, IETF applies a second signature which is verifiable. Integrity Analysis: The IETF rule is "an unverified signature is the same as no signature." Th= erefore, the invalid signatures can and should be ignored. It appears that= your tool is getting confused by the invalid IETF signature and ignoring t= he valid one. The message passes SPF because the Sender Address has been changed to dmarc= -bounces@ietf.org. The second passes DKIM because the second IETF signature verifies. No official assertion is been made about the sender's domain, so there is n= o need to verify against that domain. But if you want to do so, you can e= valuate whether to place trust in the Authentication-Results header applied= by IETF. IETF converts all messages to plain text, and strips or blocks attachments,= so they have minimized the opportunity for malicious submission. Implications for Email Defenses: This example is a reminder that every message is a take-it-or-leave-it prop= osition. You can accept the message or reject it, based on the message ch= aracteristics, but you will probably be unable to cannot change the sender'= s behavior. In this situation, you may not like having two signatures fro= m IETF, but you cannot change IETF. As a result, any spam filter needs t= o be very flexible about exceptions. Too many spam filters do not have ad= equate exception mechanisms. Hope this helps, Doug Foster ---------------------------------------- From: me=3D40junc.eu@dmarc.ietf.org Sent: 5/16/20 7:58 AM To: dmarc@ietf.org Subject: [dmarc-ietf] dmarc.ietf.org failed dmarc https://dmarcian.com/domain-checker/ test it there if not taking ownerships it will get dmarc pass oh well software testers needs cases to test on its one here then if its complete impossible to not break dkim i will leave this maillist _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --b0a9ef0ea15546f5a26dc3df33b83daf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I understand your = question to be "Why do I see invalid DKIM signatures on messages from the I= ETF mailing list?"  I can provide your answer

The typical message on this mailing list has three signatures:
<= br>
Signature Analysis:
  • The first signature is from = the submitter's organization.   In your message, it was from junc.eu.<= br>
  • The second signature is applied by IETF shortly after recei= pt of the message.

  • IETF adds an Athentication-Results heade= r which indicates that the junc.eu signature was valid when they checked it=
    .
  • Then, IETF changes the FROM address to be @dmarc.ietf.org and= tags the Subject with [dmarc-ietf].   This breaks both of the first t= wo signatures.

  • Then, IETF applies a second signature which = is verifiable. 

Integrity Analysis:
=
  • The IETF rule is "an unverified signature is the same as no signatu= re."  Therefore, the invalid signatures can and should be ignored. &nb= sp;It appears that your tool is getting confused by the invalid IETF signat= ure and ignoring the valid one.

  • The message passes SPF beca= use the Sender Address has been changed to dmarc-bounces@ietf.org.

  • The= second passes DKIM because the second IETF signature verifies.

  • No official assertion is been made about the sender's domain, so there= is no need to verify against that domain.   But if you want to do so,= you can evaluate whether to place trust in the Authentication-Results head= er applied by IETF.

  • IETF converts all messages to plain te= xt, and strips or blocks attachments, so they have minimized the opportunit= y for malicious submission.
Implications for Email Defenses:<= /div>

This example is a reminder that every message is a= take-it-or-leave-it proposition.   You can accept the message or reje= ct it, based on the message characteristics, but you will probably be unabl= e to cannot change the sender's behavior.   In this situation, you may= not like having two signatures from IETF, but you cannot change IETF. &nbs= p;  As a result, any spam filter needs to be very flexible about excep= tions.   Too many spam filters do not have adequate exception mechanis= ms.

Hope this helps,

Doug= Foster

From: me=3D40junc.eu@dmarc.i= etf.org
Sent: 5/16/20 7:58 AM
To: d= marc@ietf.org
Subject: [dmarc-ietf] dmarc.ietf.org fail= ed dmarc
https://dmarcian.com/domain-checker/ test it there

if not taking ownerships it will get dmarc pass
=

oh well software testers needs cases to test on its one= here then

if its complete impossible to not break= dkim i will leave this maillist

_________________= ______________________________
dmarc mailing list
dmarc= @ietf.org

--b0a9ef0ea15546f5a26dc3df33b83daf-- From nobody Mon May 18 17:24:58 2020 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 3A5013A0D4C for ; Mon, 18 May 2020 17:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=fDXoRfa0; dkim=pass (1536-bit key) header.d=taugh.com header.b=gOwk/OEP 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 NiEuL7e615BO for ; Mon, 18 May 2020 17:24:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6088E3A0D3D for ; Mon, 18 May 2020 17:24:51 -0700 (PDT) Received: (qmail 39630 invoked from network); 19 May 2020 00:24:47 -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=9acb.5ec3274f.k2005; bh=KT9l+CgurkoaI4OhknV0ikqmLqkEwFThPzc6dukWICU=; b=fDXoRfa0fjj9waGuxWQkKVT3IGQnzoc8AMkUATOmMOG/DvbJYXOicD5OOkNBmrMnTq4M5QFfymle4PKgNmriE4XSL7eY420zjpY3vA7wzK5WE+InRs+4npt5dRfr7qtAcaqRk/E3ZdJsYMqiuJArtFA7Ohe42byShA/hU1G+br8I+V+n92Z1i6JcThaQg0PJsgrI3cmlsApEO0ojfdMoJ6FnkTy9/jU1Wnvzj25wH92m8IOWSsJUMdvDOGOPcxtE 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=9acb.5ec3274f.k2005; bh=KT9l+CgurkoaI4OhknV0ikqmLqkEwFThPzc6dukWICU=; b=gOwk/OEPqXnHt2swMomiRCKk35uQsX6qF82FZ1aSH0PCaPUzbaJgl/OpwxakEM+7Bdwdvu4s+BlunzDuG9QicsQAvOcG3MhuzW+keMVyg3OwHHGhbHfQ8ihekhMyIRzB2q7+uJPnB29HKwh9pmyLmZz8wdrzldMrg4+jAyOX55YBawsoteQUMryuuNuDWWcWmw5WNOoCBMLlnDOZ+rf9nOAlEj+NxQrxN6+RmgFBPCysFgbFx4AjqrQfy8PDo3iy Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 May 2020 00:24:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 264D119710B1; Mon, 18 May 2020 20:24:46 -0400 (EDT) Date: 18 May 2020 20:24:46 -0400 Message-Id: <20200519002447.264D119710B1@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <0127a137400d466095373373ec887b90@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] dmarc.ietf.org failed 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, 19 May 2020 00:24:55 -0000 In article <0127a137400d466095373373ec887b90@bayviewphysicians.com> you write: >This example is a reminder that every message is a take-it-or-leave-it proposition. You can accept >the message or reject it, based on the message characteristics, but you will probably be unable to >cannot change the sender's behavior. In this situation, you may not like having two signatures >from IETF, but you cannot change IETF. As a result, any spam filter needs to be very flexible >about exceptions. Too many spam filters do not have adequate exception mechanisms. You missed an important point -- for any From: address that has a quarantine or reject DMARC policy, the IETF lists rewrite the address into the dmarc.ietf.org domain using a kludge I suggested to them. You shouldn't be seeing any mail from IETF lists failing dmarc with a dmarc policy. You'll see plenty that fails with p=none (this one probably) but any spam filter that rejects on DMARC failure with p=none is pretty badly broken. From nobody Mon May 18 17:26:01 2020 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 8B9713A0D51 for ; Mon, 18 May 2020 17:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FWuoXZpUaKr for ; Mon, 18 May 2020 17:25:55 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450: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 704493A0D4C for ; Mon, 18 May 2020 17:25:55 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id z4so1239531wmi.2 for ; Mon, 18 May 2020 17:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kIiahlPqOPVAeY6OyeAslcPubX9TLUUfK4bCa4+L/9w=; b=UgEXS3fJm5ImQqw5TPwsR0pGQybGBv/Qf4Sqno5xkOMcZJksgVwKQyYClFJIt4eRgf LP54slTqLj/HoRVV4P13OX37J/YYuh7+Dmp1qBQ2j97dvArXXHkvGdLm19AMrQfmUpk3 0NOblsBDV0tz5tpCafOvz1V4mFTQlkGoflsTa9Go8gN3iaBuwcXIBLkqeW7uBd53bcoo vmMqM7JWgglsTKIfqpzztLi/vpi74mQAKIyLh+xLR0jwRN+wFIYXSpuJLSfQlwftX5u9 oIJtDen7oWSgq2+SF/CBDYrNMSK2mr0JOxKv19bakQFznKUj8XBzAkE8udpEtvz2DBRx fDYw== 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=kIiahlPqOPVAeY6OyeAslcPubX9TLUUfK4bCa4+L/9w=; b=lKzTo9bMoaFV9pqnWhbDcU7mRBHj+tgQfG2TbYOuDjqFZIgH42BIvm/GppoO4X+7pv LCgCm61VC9mI/lPwRoKyJYCsgh36HlX57hMd2rmSmFxirfslB/egai0nLWy9v5x6iWuQ ek2FDHVGbhkFwQEh1lljzPPO0r2X1gaTXpFzmt8ecEQSixeZsviEAy5dtge3rrIDvEja HgQcGyMrllXJ7wbnbBT9TZZ5MzvpTAfB9wUbjeX/eWYNQKfONzv0D0Z+KVNdgCj6mD2S z1/iypYAeAAsppZ1jSm/s2JSt1jQx9+HqhIQPx3O3aZKwA8qlgsraPToub5d5JyGisuG trGQ== X-Gm-Message-State: AOAM533lvaqgraZyWfUSh8BFCuhMlMmbB/nBXTWR3+1ZhOMs73GENheE tFsXR32TP5729JoFo14NxQbkIjwx9jlXyHFVG2VYzAUCBtE= X-Google-Smtp-Source: ABdhPJyBgSyFJfXObVwwa42E0c5slewG+6fVIzKmKSzUSDhANWpQx5HDkaxBhYiI0ZTeXIkchvoBEedbrd14V4w3EiI= X-Received: by 2002:a1c:720d:: with SMTP id n13mr2069836wmc.130.1589847953556; Mon, 18 May 2020 17:25:53 -0700 (PDT) MIME-Version: 1.0 References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> In-Reply-To: From: Seth Blank Date: Mon, 18 May 2020 17:25:42 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000084deb005a5f55270" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 19 May 2020 00:26:00 -0000 --00000000000084deb005a5f55270 Content-Type: text/plain; charset="UTF-8" On Mon, May 18, 2020 at 1:31 PM John Levine wrote: > There are vast numbers of sites producing and consuming XML reports. > They interoperate. It works. There is no problem to be solved here. > Can we stop now and work on something else? > The working group's consensus appears to be that aggregate reporting does not need to support JSON output. Does anyone disagree? Seth, as Chair On Mon, May 18, 2020 at 5:25 AM Benny Pedersen wrote: > On 2020-05-18 10:27, Alessandro Vesely wrote: > > > Best > > Ale > > -- > > > > could you remove empty lines in your signature ? > > lets see dmarc fail, dkim invalid test in spamassassin > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000084deb005a5f55270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 18, 2020 at 1:31 PM John Levi= ne <johnl@taugh.com> wrote:
There are vast numbers of sites producing and consuming XML repo= rts.
They interoperate. It works. There is no problem to be solved here.
Can we stop now and work on something else?

=
The working group's consensus appears to be that aggregate reporti= ng does not need to support JSON output. Does anyone disagree?
Seth, as Chair

On Mon, May 18, 2020 at 5:25 AM Benn= y Pedersen <me=3D40junc.eu@d= marc.ietf.org> wrote:
On 2020-05-18 10:27, Alessandro Vesely wrote:

> Best
> Ale
> --
>

could you remove empty lines in your signature ?

lets see dmarc fail, dkim invalid test in spamassassin

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818



This em= ail and all data transmitted with it contains confidential and/or proprieta= ry information intended solely for the use of individual(s) authorized to r= eceive it. If you are not an intended and authorized recipient you are here= by notified of any use, disclosure, copying or distribution of the informat= ion included in this transmission is prohibited and may be unlawful. Please= immediately notify the sender by replying to this email and then delete it= from your system.

--00000000000084deb005a5f55270-- From nobody Tue May 19 02:47:11 2020 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 D033F3A132A for ; Tue, 19 May 2020 02:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Qcx34jd9m80f for ; Tue, 19 May 2020 02:46:53 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 59FDD3A1320 for ; Tue, 19 May 2020 02:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589881609; bh=NVNHV9Ze4Lvzbd4McWWltWC8oP5HVh7UYKrLlBjzZLk=; l=24828; h=To:Cc:References:From:Date:In-Reply-To; b=AkRuSU0USpF+cjGQjV3mzH/l5jN4nAAZlsBuqS3sBwRHoX28qumG8e+PXyVjhkDMe 20qDMn2CIR69rHY3NSwonx4aUa82WQxTKAgqIKxrp3asOZSZ7f+xMcfK/T2LxuPk0T U81G8OcbowmQ8NDRLYhhbV9IDyUMu/g/NsL8xxhDrwCbwGzJsYOJUMr40lN8j 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B4.000000005EC3AB09.00004F57; Tue, 19 May 2020 11:46:49 +0200 To: abuse@no.sp.am, dmarc@ietf.org Cc: me@junc.eu References: <20200518203221.934EE196F111@ary.qy> From: Alessandro Vesely Message-ID: <302a1b59-b92f-33db-aca6-5d25fc45b466@tana.it> Date: Tue, 19 May 2020 11:46:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-20311-1589881609-0001-2" In-Reply-To: <20200518203221.934EE196F111@ary.qy> Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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, 19 May 2020 09:46:58 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-20311-1589881609-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Mon 18/May/2020 22:32:21 +0200 John Levine wrote: > In article you write: >>> I suggested they make a few changes which they have now done: there is >>> now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX >>> record pointing at the mail server rather than A/AAAA records. >> >>spamassassin still says dkim invalid here > > Yes, that is correct. Why would that be correct? It says DKIM_VALID here, not only in normal TB usage (attached) but also if I run SA locally (normally I spare SA for list messages), getting the following (notice dkim: signature verification result: PASS): ale@pcale:~/tmp$ spamassassin -D dkim < valid.eml May 19 11:35:03.226 [4856] dbg: dkim: using Mail::DKIM version 0.4 May 19 11:35:03.226 [4856] dbg: dkim: providing our own resolver: Mail::SpamAssassin::DnsResolver May 19 11:35:03.231 [4856] dbg: dkim: performing public key lookup and signature verification May 19 11:35:03.979 [4856] dbg: dkim: VALID DKIM, i=@ietf.org, d=ietf.org, s=ietf1, a=rsa-sha256, c=relaxed/simple, key_bits=1024, pass, does not match author domain May 19 11:35:03.979 [4856] dbg: dkim: VALID DKIM, i=@ietf.org, d=ietf.org, s=ietf1, a=rsa-sha256, c=relaxed/simple, key_bits=1024, pass, does not match author domain May 19 11:35:03.979 [4856] dbg: dkim: FAILED DKIM, i=@iecc.com, d=iecc.com, s=fc88.5ec2f0d6.k2005, a=rsa-sha256, c=simple/simple, unknown key size, fail, does not match author domain May 19 11:35:03.980 [4856] dbg: dkim: FAILED DKIM, i=@taugh.com, d=taugh.com, s=fc88.5ec2f0d6.k2005, a=rsa-sha256, c=simple/simple, unknown key size, fail, matches author domain May 19 11:35:03.980 [4856] dbg: dkim: signature verification result: PASS May 19 11:35:03.983 [4856] dbg: dkim: adsp: performing lookup on _adsp._domainkey.taugh.com May 19 11:35:04.219 [4856] dbg: dkim: adsp result: U/unknown (dns: unknown), author domain 'taugh.com' May 19 11:35:04.238 [4856] dbg: dkim: VALID signature by ietf.org, author johnl@taugh.com, no valid matches May 19 11:35:04.238 [4856] dbg: dkim: VALID signature by ietf.org, author johnl@taugh.com, no valid matches May 19 11:35:04.238 [4856] dbg: dkim: FAILED signature by iecc.com, author johnl@taugh.com, no valid matches May 19 11:35:04.238 [4856] dbg: dkim: FAILED signature by taugh.com, author johnl@taugh.com, no valid matches May 19 11:35:04.238 [4856] dbg: dkim: author johnl@taugh.com, not in any dkim whitelist May 19 11:35:06.693 [4857] info: util: setuid: ruid=1000 euid=1000 rgid=1000 27 29 104 109 115 125 1000 egid=1000 27 29 104 109 115 125 1000 X-Spam-Checker-Version: SpamAssassin 4.0.0-r1845952 (2018-11-06) on pcale.tana X-Spam-Level: X-Spam-Status: No, score=-4.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.0-r1845952 Best Ale -- --=_north-20311-1589881609-0001-2 Content-Type: image/png; name="Thunderbird.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Thunderbird.png" iVBORw0KGgoAAAANSUhEUgAAAikAAAHzCAMAAADSAH34AAADAFBMVEUAAAAAABIAEhISEhIS JDckJCRbEpIkNyQ3NyQ3NzdbJJI3N0lJNzc3SSQ3STc3SUlJSSRJSTckSaRJSUltN5JbSSRJ SVttN6RbSVtJSZJJSaRbSYBJWzdJW0kkW7ZJW1ttSaQ3W6RbW0ltWyRbW1uASaRbW21JW6Rb W4CAWyQSbchbW6QSbdskbbYkbcgkbds3baRbbUk3bbZbbVtJbZKAW6RbbW1JbaRtbUlbbYBJ bbZtbVtbbZJtbW1bbaSSW7aSbRJtbYCSbSRtbaQkgMgSgP+kbRKSbUkkgNs3gLY3gMg3gNtt gElbgIBJgLZtgFtbgJKSbbZtgG1bgKRtgIBbgLbbbQDbbRKAgG0Skv+kgBKAgIDtbQCSgFs3 kraAgJKSgG0kkv83ksi2gBKkgEk3ktuSgJJbkpJJksg3kv/IgBJtkm22gElbkqRJktu2gFtt koBJku2AklukgKSAkm2kgLbbgCSkgMiAkoBbku3bgDeAkpLtgBKSkm3tgCSSkoDtgDeSkpKA ksikkm3IkhLbkgCApFtJpP/bkhKApG2kkshbpO3tkgBtpMhbpP+SpG3bkkntkiS2ksiSpIBt pO3tkjeSpJKApMjtkkmSpKT/kiSApO2kpJKkpKSkpMjtpADIpG3tpBLIpIDIpJK2pMiStoBt tu3/pADtpDe2pNv/pBLtpEmAttv/pCTtpFuktoCAtu3tpG2ktpLIpNv/pEmktqSSttv/pFuk traStu22tpK2tqSkttu2tra2tsjItqTbtm3btpLIttvbtqTttoD/tlvttpKSyO3/tm22yJK2 yKT/toCkyNu2yLakyO22yNvIyLa2yO3tyFvIyMjtyG3IyNvbyKTtyJL/yG3tyKTbyNu225L/ yIDtyLbbyO3I25LI27a22+3I28i22//I2+3I2//b28jb29vt27bb2+3/25Lt28jI7ZL/26Tt 29vI7aT/27bt2+3b7aTb7dvb7e3b7f//7aTt7dvt7e3t7f/b/6T/7f/t/+3t/////+3///8I sJixAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH5AUTCQ0qqokIIQAAAB1pVFh0Q29t bWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAgAElEQVR42u19DYAkx3VWnyazd7Un Z3X0ncyP44utycHBxH+gMyEM0QnrsrZiCzlLsBkgOIqAKEbmLjZeZw1HJ9JJsi45ItYOi9Rc AMVHcH6O/JBTlAYi4khx8EWi4yCMEzgRqVBCAoZcrhd73an/rlddPdM9O7M7s/uedFvT1VWv XlV9/epVV9erIEBCqkf/HwmpBjGknENCGk4GKX/nb3/j3/z2U9ggSIOR8v6/8Le+5XWvfvWr /+y36xs5I/WjHqdSul/M8txwacLKy2lgDpCA/3TTjyBFTUF9pdUpqXRPR4Ab45N1TEh555vf 9i1vezWnN7zTyLh37171o2az7YUVzPLXMhYweu/onAblAAl4drekEaSw0l9jf695Ok2X5HDM FQ0sqXRPR4AbTWWdNFLe/+a3vfVNX/3qP/Dq173udW9+vyNjbWH3Op3B/pwarY/8nAZj6xTI Pl6k5F977sdyX7a9XqScE8+H85TURopd+6lDytvf8f3veMd3fdef/xNvfctbvvprLBl/7Fqe y6ZglGV59oui4a79uB6d/nuh9sWPF76Yv/SD5qGSmlnWtQGrCk6MXvrSl17SI6NkWDzEFjtV qmRhSm4ohdVb6U+deun/CRaWAHlRkoKzYGP3ME/1xU/Zo5S8NhIpCZUCYgx+sEgI5J4KpPzf c+fe8P0/+8O/kf3uy5/54be85a1/1KrrS/m73imbov/aPD/92jz7Bob5MKeneNTevS/kT75i r6V7Xsrf38nTU3LokuOXrmsDVhWcOI/T78o/fUZmeClffpelsXkCzW4vYKFLbiiFhZRefkf+ fslSCnBu77vya3ud0UeygUjpixKKdPJaS1FUss8r+c535s9q8UUFC7mnAin/+9y5N/2b36Xc /Mx+9m1vfetrrLp+Kd93h5R8359m/97I/v24QPorRNS5L7K4h8QjIDN8STxsB8yYYenPmqx0 0R5Oikf2KplBMzTCFuz2AhZ2wkZSGBW391qW7ZUspQDnfjz/4lfsA0jRbCBSRClWOnmtpSgq yYrOTeX2lis4FUj5X+fO/ZnfYJo4yyj9j3/trW9wkKKreUb9y/Kv3aejeMOeko0qm+KL+Zfv NYqkhJQ6rHTRHk6KR7ZPZtAMjbAWO8DCTthIioL5p/L+KxRShAA/9qX8T+47BZCi2UCkiBLs dGcMG1hJrihN5coVnA6kPPTQNzJ1QplW2fjld7zpTa95SBCT8aGHXsrf+TP8h/Xvi/lXPKkv H3oh/9gpnphVV0S8kD92Smb+csVB/a3NKs8f8nPiNwSPJ/dp2Xo/o5mL0GZns9AlN5DiIV0p zfyNe9/IAy1AxkaHOx6yuZjSrdaz7r32U3ZaLUVRyb38D4tM9plEQO4pIIaUM2eW/u1n5buP 3/iLb3rTnzojiMP6zD+iwqg6Y/37mayIOnPuSXZ1psggrlnEp3i0SKH+1malr0ucROSns+zZ fa+CshlhbXY2CzthkwqdsSqm62cEyG1h+T/Nxs6j733KkUxLoSUUqXkUPfAqkwjIPQUkkHLq j/2Rv5FwsPzym1/zhrfruvI6nHoFV49nzlj/vmFfEXXm1Kv27dV14T/ENQvfyKP37j1j1bUm K/3P5aQj973qlM7wig4zK4uyATubhS65gRSAVAQUwOVi2Nh59L03upIpKbSEIjWPesWpIhGQ eyqQcurUqTtu/IN3vP+x5DP/9A+/5mtOKeJSnto0jYeLl/gz+Np9p5C2hiRSTt1xB/+z9Of+ 0NfMkOz8GbwDu3DLkPLfzO9vf/vbseGRaiAFCWkQUv7rG5GQhhN+84dUlzIkpBqESEFCpCAh UpAQKUiIFKQdiRTSiAnZ1U046bYi04sUMkLtyQ7FFBlb1XcWUginWtIRk9SkrsyThlSE9DBt IBnth2ThWDJUkBtFcOOY2hPUa3M9Sby8SD1uZNqRUls6Ur6oztOLRRD1mwAl7KeUJseGCtLh YLrUIVujQ5plISMpqdlBitKoUbiwRIe1Ae0vLEQiw4BnMQ1l36cWX3aRxfqWh5ZWMquIfrUg cYf97cSWxEmHhLEJ0t7C/h4tJK1XLxKHpJOKa1NFFnU4UfGaKxmGFC29DokRbChSlKC8iGhQ E2w3UqJOSnv9YS0aHaG0Q4a12DHeMHHP5tuPM0potlZVAkeSVURULUiYZEloSxzG9IUlExxO KO2z2JVjlB6rXS/SS2nUEdc6IznGonS85joUKVp6HRIj2DCkaEF5ESzzkWj67BRZe95VNBw2 nvNU6VCkJPy5P5zafJNeFi3EWa/KECFUlqKKqBaEI5Ah0ZI4XBOPnwqkOiskrVcvXjwtGiI1 USpecx2KFC29DgkQrNK6sQTlRQxsgu3WKYNtO2J1KB2KlIwZEwItBV/WBodZVFjVaAupkcXq HJ8gNIwZF0tiNjIwPWOCzgLs+3r1shqiqGLxx3AdhhSTu+CiBBumUwxohzXBdiOlUP+DWrSe TsmYZSosT4tvhxkYnUudqhxL3+w+ldUKnkSuxMmCCZiuF61s65Th9SKwIVIXKZrrKDqlkG8g UrSgU69ToiMpTXtD7RQ2iB+RGRYGdcHh+LAZuCXfKFxj/6LqqbWY+3A7gY/wKzW6VnNmpgQz XHSwcIlFWuZGvXpZSDF2ih2vuQ5FipZeh8QINtROUYIKE4mJEE0rUrI1buoPG8+LuU8W7R/Q ZjGJdQGKb0r4U1mNrheWQrLAzZghcx8rVJz59KQIkpCEa5ak9eplIcWqYvFHcx1l7qMEGzr3 UYJO5dxnp9PIGnybVf80vFIBSCG131AS0uRlJmmWHGQhddMNZd6naac/Sht5MtYpk4zwvrei 3lOHlJ1NUTiiBh85487VKUhIiBQkRAoSIgVpqpCSIiHVINQpSDj6ICFSkBApSIgUJEQKEiJl e6i/q4qdlcrUQEo6Ct90EzJNdD0s3Wyx6VbLNcnKzAJS6MqRzgrdeUiJjoSKjqztXKT0Qot6 TeuQ9o/EtStOO2E/rVlLJU/ztkxVrx1JR2zctBNnKx3aoEsjuwmroUJ7SzONlBBQ0zrwRorr ZloJ1+hKx69V/EgJw0tNK9cxj/dojcvgvHYpbISUTvFBd2oX65oR4fEZR4rvd706pCu0Z3XJ sEydPhX92KF1kML/xs2houtg16tB47IKHU9Lpaa1inR/uw9Vqd67BilpJ+yxlu3XRkq6Eh6n 9Hi4UgspPTYWXmoMlU0iZYWNeBzOR5Zi2gQp8hEYgJRL/P5Sfy1tjpRej04KKcc1a9rrbQIp lA4DCrMk6EpaN9MKa0/+xXrYqY0UFyqUjowUSpsghfdrmtWrWS2dckmPitb+6LRelayHsVll LBxU7HQ9Hsok7IHfDFLIfh7Qw71qoIT25p1hmWgzpJgWtqAyWCSdkWOshBRvVt/os8RHn/TS ccvkGFyzWjqFjz5pmkQdq0vSelViY3Y0UmUsHByvsrJFEhXUQYrUPQ5Slrg89DDpDwBKx51i DMhE6Qp7ouhSndGnZxIxqBRlDBRpMFK8WQdZtJ1iV+zgmtWzU5hF25P8af1WvrRUsuwbVGYI DkySygTu3Ee1a68092HyJIfJUk2gDMuUNLFo2XOtoRLb84kBIg2zU3xZvbPkSM6S3S6tLFvr FDa9zuigWXJPzpRo3VamS2HoR0rNygzGgUlSmcB9n1IgxX2fskSIv1eoByhDMiWsJZlSYbRS Aylclaz4ntNKkazEfBT3WLSerIN2QLrDRGXZpqhkKVwa5lCqPlveI51L1Dv61K3MQByYJCxB euRIWusdras0U9Mv/l6JO2WgDM7Eqpte0rbipRp2u4FKDO2apYFA4TWJO+zp9s19ylnJIHs9 rdkcSqesJcwaDsNk2DQgrd3KatJzvGzR1q6MxMHgF6K8mE7oexPkIoWlDEM4TUqHzMn4hNcF yuBMa2HM+v54Qmly3DP1JVkVVICdUmfKKt4697yz5LT2xJIBe6Vuc+iievydQZXt2JxteQoz SmVor1dnh1sn9M0zSkjh7QqnSemwNynsfxcogzOx6nb069y1sqlCsgqoNH35JlRd0glHfJ9i tUnjN2/CAKHh4Alvg1beyjdvnu70IIXKp5DWr8PK0pFOTLMmSOnEa8Xjdry0PEKq30E0e/UW djhrurZZpDRoDj2g1NApTdhO2zta/2A2pA6dlbRRHRQ8LDpeq5ZsVO80bE69m5geH2PjDpZh Ta0NSjslHUenTytSyoPZJL466NhI6Uy8ltmWISVbU/Y9s8COJ9mORsqk6zCc8EumGUXKlhPZ VcXOSmXwO9rtLnZWKoPf5iMhUpAQKUiIFCRECtKsIyVB2kJKZ1Zy1ClIOPogIVKQEClIiBQk RAoSIgUJCZGChEhBQqQgIVKQdjZSfuVHLuwg+pFfMRV7DpExVqT8J6uZyWR6jwy5bpR5KGmo XLztIkJjnEj5VyP1CmmSYmuR8iOyXi+/+7Z3v4zYGCNSBnXpmPSMFylnbz1AyE33DC2iefla pdyGSqUBUpY5bTFSzp44NBwp91x/64MXzt91w63jQsqhE2cNUl5+7uID72ZIefcDF59DvVIT KfV0yq3XXy+67MQBcuj+IrR76pYD5OiF8+Q8+3n++vPESiTuGLrrJnL0HpWvgi27dZbcJ1Kf P3TXBX6w8IUL99/EVMx5VR7/c5Rcf4JAWXhRJyDfG+67S96/5yi56S6FlPfcVtB7EB8NkLKc ROxHEkV86+Tys9HpKE2j049RjZRbbjp79tAtrOlvOnvhlkNFaCHlxKGz54/eeuEo76gTt/JY nUjdEfTgUXLorvM6XxVbduvoLRcevIHcQi7cd0gVceieC+ePHi2QwjPfRKAstxy6//ytNt/7 L5wQf8T983cdIkcf5Ej5uIWUjyM+miCF+zFIYkrjRFxcSyL+J9ZIOcCeyfsPsKY/K3tJhxZS bmBJzh4QqS4cOGsnUndk4gP3WaNGFVt569CJCyeIvpZ0/kCBFJHZkeXA/SYo+Fr3L9x3gAg7 5XsNUL4X4dHETlnm2iPifqOiTFzQZXUhkaJ7xw3tgMhBgmn4u47CxOqO6CmuU0w+Uh2qKyJ7 XKijQ5JNHVlKt4jRKfdJi/Z7ESij6RT+5/S1LLt2Wl0Uf8DDX907Nyh78Z5DFw49CBLpO2U7 pYot+//6s1Kn3M/+yvgDbNQ6rxKdtXXKhWqdYiPFtlOy7GmFlKcRHc2RYnRKGSm36oG/Gikn mDlw/00cMidugonMHTj3GcCW2yknpJ0iNBDhALj+Lm7UMnvllgvCPrlV2ylaCF6UtFNcvuKP PfeRc+TbcJ48GlKMnVJGyoWj119/9EIFUtTgcuIG2a1/mdzjJNJ3yrPbCrZ8pkMeLJKe4Pzv uYEc4HbL/YdkyOc+tzhIuXCrnPs4fJ2pNK/VA3zWw/49gOhojpRrfO5zrYSUf7ZFr/Aduovc cj/TPjcNTHT/gVFWfiRSvu257LlvQ6SM8R3tX71pIkB5cFgn33/0ALn+pvuqE9zKhphbRyhZ rPtckQbK01cQHWNDSucHJrKWLEaJTdGJA9cf3dRaMtJ4kYKESEFCQqQgIVKQEClIiBQkRAoS IgUJkYKEhEhBmhhSlrF5kBohZXTE8I8Oit/NcpbjkpDF2izHybcGwXT8tyffpqSbEaTQJIqi OK2jU5YhGCrPQXRbdsQeVRchSTfdFwP4DiWYbhcjJX6SZjSNGyMloxHpjRspPjYwGDvfEfTR LkVKRG0cLIsNHHLvRia2ccTXMrWdw94yxpuCkv0CaoeJOFOwNOLEN5IbY/kMxiE5nEQhEQfF RYQs8BPgCFkLCT9Od78+x1LmVAyJHHFUYLEfL19GazcScRyxzqj5G+1JbOaQm5t8FOlmRafE L1yDSCm+idSfR/IwcXUKQ8oCz096dIXEZaTE5Bilx2SbLdFE/jnM2yylMT9knsewbiJHXqB9 K6fL0FUBY+bL+7BP+yTSGQv+dm0K5g43J/ko0s2MnfKx01FCLaQU31nrT66V3imNPryqN7Jh nJIby7r3MB/fU9lmbIDjf4reIaGMLswA8ejy+4ZhBVIa8jWZK/jylJyNyVjwd0cSmcbh5iQf RboZmvvQOLaQUuzdiNQm5dPXfBYtEacDy++rSRkpokmo0dbmT3pkQet/k8xGimFYgZSGfC07 1MuX/7hm8bP4W7UBzB1uIPko0s3SLJkrjtNi/1dJp1i2jKNT+lz5iifSa97daD1ddpuFJLlm dUzp2TcMK5AyZr5Ap2RVOgUwB9xuhMlHkW5W7JSUtdOTfMBlVYlLdgrTN8ZOiSi0UxYWKB/l e+zmscF2itNmDGSmzdZ4MtueMAwXwPTYawnU4Gvu+/iKm5adkinDq2SnAOaA2wA7pW6tZwQp aRxJO4U+djp6Vs19nlQa5NN867qe+2RiV7vVfHKazKz4/ccS39yHmf5xuc0SNmmIrVGgPEdR DOMFe9JjzS4a8S0SefgqazXUcx/I35IJMAfc3OQj1HpW39FqOr3ZFxbjpa19RZHy0QipFlLk bvVNv80fG062Dim9lKYdEiNKaiIlena3Nk7cIfs7lxAktUcfJCREChIiBQmRgoRIQUKkICFS kBApSEiIFCRECtI0I2VrPytOOyl2HCKlBnVIBztu6pCyPB6k0H5IFnrJWEROCCEJ9tzOREqy 0E8pjcNxfNuVdkhCcPzZPqQsLy9HMR2CFBc3aW9hP98/SKIFuYVFwSbpEPEdVxQu8J0K6YLU AbTDPz2L5b4X2pd5BJJkes0GsBZ7ZWK9V6bDFMpStsT+diLsve1BCt/GETdEyuGE0j7/RPUI pUeiAilhTF9Y4v2a0h673Y+y9EYSkSw5zG73UhoxQyNieXRvq/SaDWB9LOV7FGWejKEmukQz eik6jN+ibR9SxNdtarNgsX9Q7FSm4htrtXdQ3dImCP+WnX+GHlpIWROaIUzlbRZ21ugaySj/ fFRsbpA3U9XbKj2xogxrkVzlydL9++W4Y34gbYtOecw+80l9l5/yh/ynkkKn6CTCZliQW1dU T2qksKEjTPRWGHFb7I8AaDK9nxXp7SjN2thBxEIIAmVb7ZRlpjjAmU9yr89jqVIpzhEuctSQ CNE6pejqZEGqDaVbOjHTKWlnzdI7UIHw9LZOMawhUrJLYt5ziVzCvttGncIGGr1Z0No/yJRK /GnLTtHHQjFauETTHu9OvrWFgacTyWtmViQhN0VSdp1lx6WdstBJrF5f4XbKivyt0ms2PMqw dpASkYTGNCFoz26vnaKVh61Tso8lkW3RWjolCUm4RopJS8rnMERsdRGoWOPzFj73SZ0ZNbHm PkV6M/chFmsHKX0S7Sf75U5opO1CCrNe9WZBa/9gli7rjhY4suyUunRpIUqv0ai32Rd4GX9B Szox/4N9t51ISR/TmwXt/YOp0fRi76A+FqrR67KlOu9o6yClH3IL5VKIOmW7kDLgPUq8VdMM gv0x00h5Fo1HpDpIWY4oNhMSfsmEhEhBQqQgIVKQEClIiBQkRAoS0jiRsuk3q0k4jMWVB65g V+1CpLgZhjvIeuC2B7CrdgtS/Ps4RN79w14CP3fbbbc9h321O5BSsY+D1GFw5QGGFBx/Zgkp y8vL9oEt8mukiDhbLYqtHdz+iML9kbuPI9P7O5SLfOk3VH/aJPJpztlFDhNJD1zE/podnbIM rsRODOJstTD7Lzhc+EaO0j6OYn+HrVP0tg6Rb0W4Emex77mtoPdgf80WUopdHOKraeJutciK rR36o2u4j6PY32EjRX+CbfJxztmVdxugvBsHoNlCivV1pLt7Q27hAPsvqE4I9nGY/R0WUiAz AzsDFQTKrCHF3sWhdYqNFLD/wtIp9j4Ovb/Dq1NszowuK6Rcxt6aMaRYuzgiZk0ccZEC9l8o O8Xdx6H3d4iP9kkGtnWIfMZOYTatQgraszOsU8zcx0YK2H9xbSVciDz7ONT+jmg/MUgxcx+b M6OPK6R8HHtrdu2U+lRzHwcgtZ2QTZMfeJr/wd6aMaSMsouj7j6Ogvo07cjXdB9/D7dQLr8H dcpMIWXLKAqNKxUkRAoSIgUJkYKESEFCQqQgIVKQEClIiBQkRAoSImXrCM/a2I1IGWUzEJ61 sWuQsrmTN/CsjV2DlM2dvIFnbcw+UmgcnX4MdKFzUIbv5A3L/XmRbr92HaeymC+h8KyNnYAU GiXSV62FFHv3hv/kDQspVjqlbkqbOfCsjZ2AlOI7N7ONA+ze8J+8UT5SISzUUmkzB561sROQ YnxI8s8jk2JmY5BQcfKGuW8hRuuk0mYOPGtjByDl9DUXMs7ujYqTN9xNQY5OKXST+Ilnbewg nWIgA5FSdfKGPqDDpFN2ipVFJ8nwrI0dZadU6JSqkzf0AR06ndrYAbKoJBmetbGj5j6FneIn e8dG43e0eNbGTnqfAg8iLFOxYyNtPNXFszZ2AFJGIBJjEyNSkBApSEiIFCREChIiBQmRgoRI QUKkICFSkJAQKf/z17CzESk16Leeeea3sLenCimk/DM61jx/jTXoQccCHXM/b/nPn/vcz2Nv TxtSCOx0an+vMhQC1UhpcixQugB9xP3W55555pdw/JkQUpaXl6OPJbzFlzPxdQoPl+XDGi2r Hgllj9DDtFKnxPxDFfrNNTeL1dIpw48FOgYXsX/hlz73S88MVSpGSELIwnGqvvNFkAxFSpZd own/wI39eilKRbgsPlBJH1NIyXqyR6J+9egjkhwTm8U640TKwCQx8Hz7a8/89G//n098cphS MUJyP8q93hgOzts1SOHWQMx/pRwoAikp7/fHUo0U+akSDVNzqo/xVx1Z/vCLD/IJPBXI3lJm ZyKRcHjNN5dlL0jF1ehYIPgJ1c//9DO/+qvP/OS/HoZSWzHSBQe2SiRzflHCP+k0ASKF+z1f TuWnsxwpWfQSw01xzo9Q8+wJNqf6qE+p5cE/pv2P9RKqW137xHe3lIFM7PeRKEtuZL+XIp2z /rFA1FYHv/aTH/3Nv/fXf/ujP/lfhugUS0gPUqRIpqZhTF9YMgEiJTvNfp1OM4OUZ+MsfrZA SsJHlMPyPjUbfKyjNCRSKN8UqLziw1OBwJayIpM6mIMpFW0LNToWCCDlR//Jj/7ed3/37/3o h//x7wy2Uywh5ehj2ylaJF3TcE3IpQJEitIpqUFKFqWRfXZYJxFosU71IWADT7G/J1065t0A ZG0pM5n07yTMemvFrKr2sUD26POr3/f3P/eb//4HPvfMN33454Y2iBSSWbQ96tgpmreuKRuF wsQEiBTXTmExpxMbKckxDhb7VB9Hp/TMKE7hTc+WspJOyQ73lUppdiyQZdH+zj/8Kx99/vlv /dbnn/+X3/SdvzO0RWh5ng9F0jXldV+wg92MFGrmPqme+8ChidPh+HAGTvUhxcE/ZhrSiem1 tH8M2ina+lD7w+xMhKfh9klsPtpudCyQNUv+uQ9/+JPPP//1X//888//pV/454MawxayPBHT IumaMiuLaTwd4PsU931KGSmyL61TfZy5j3jzlvQWChPAPRVI7Q/zzH0Y99CeGtc9Fsh680a/ 88Pf94lPfOKTn2R//m7+L54d9NbXEtKDFCWSrimfuSUmwHe0YyDf2/zaG4F6jWegnLX1Nv8/ fN9HBf0D9v935vTfjWx/7vKXK9uyQlic3TOUxMi2Kdbp+9773ve+733vY//e+968TVOKSJkZ pNQ/u4eE6eZZ04LyFslGhQoiZRcRzYNWODJUECm7CylthAoipRZSWu0OQgWRMhwpTKkgVEZD SrKLKOZIabVJL4vjbSg+neW2C4J8F1HGkMKVCulnNMuRmtBuRApTKiFCBZEyFClBi4oLir2P SBmElHav1U8jZqYgUhApg5DSplmrnYmFT+x9REo1UhhI0j5TKqhQECmDkZKxUYcrlRQ1CiJl IFIS8R1MiwXY94iUAUihXJdkTKPEiJStQUoAWIyOtu6I9zx0udu1ggr64wIgNInpuCXublWH TQFS+KuGYCRBh+bqcmLh/7i3u3jZbV8Z2S31ML9+tNu9qLJ38yss4eq6jtSBpsUXrcDK5/Lk UXzeA4uVGVQJKh+8gojodrvb+4Rvr04JRpQwqPkgvrh4eX39YeeGifQg5em7r169/WlxtXox P3llY/3RD+lI6x7oQv5H3ev6BekCWewMqgSVD165ukP+ePHu7sn1XYqUIGq1EhNFwyCkIrbd irTa0bqnz+N0vqzTInDwv3x3fvVk996rpnk/JPXJxsPde1nrrt/bvdg1kSqRyqDu3X2FP9k8 fv31sj82ujpSBboE+eCrQN1TxRqeX3Zd0GIk/4i/9pWKYWn0LXB1Hav1Hp5KBCrfniC4TuYN VJS8kJdBEFiMZHadpGURuwqKfJpTqxBTJAjk31arSAlK8BOZIFJ6WVywbydZFPLYkGZhgWUR 8J04PXPV62T9TsHr6sXFD13Jb7+y8cRJ1oGL3dufyPPXP7HYfXg9v7i6cZE9zaurG6tdE6mQ ojKoe10OKBH/xKpke+V2HakClQHqFJ1EFqt5XrcnsJGiulxe7eG93gK94lwZTEAuOh9Aik65 J7DQcJ0FA4O3WkixUREAfAeWLFU0OaRkrm7jZQUUaD0RtKmdr53lWSHVycUn1qGavvdi3l1d X199OF9czzcWcx5c5WiQkVCv63tM5cj4xasSf4tXdGRxzxpTit/qHi9WxXzZHqtTZT+aphcd pLWEPwhk9gBy2WN3lobBHhNYekNlt7RRUEJKy4MUA1QLIgVOayCFTAwpYBRMiBxqgryMlADm AwbxydsFUq7cbky/q4vyUX+9GSmUhSkjVR+rDPY9/vvyh7Shkzs6xZTg0SmqWJVkjwULS4vA qz26R0pX7hMv/1ynFYeNlCKwRxiYHSIlKGcHUClivDplMG0NUtpJnlUhpaRTbJKjz+Jz3LIQ tL6Y3y1BsbghZylSb9wNkKIy6HvaTq0uzq4AABk6SURBVLldzGieYxold+wUU4KNlMK+4cWq JK42AEgJjI5vFUgBV8F1tm4odApEiqU3HJ1yne7hPaXRR5s5RqcEgYuwCqS06tDWIKWVZj07 ppVCO6UvQMIje72MdlyLdvHFDW6ZPvxifvVDq/kTD4uB5uLq+lVmdqw+KmwRFamRIjOoe3xK cjeb3zx3t7BV5AxYRapAZSjPfdg9VaxK4loYYPSRV9pY3dPyXu0p2ylw9HFskT3uaGfZMK7C qbJTq5AS1LZTxo8UPbEBSIlbrciOiVpBMdDouU/MI7Neqx2XXoctdp9mnXT59u4itxdWu9x4 3Vhd5KOImt+oSDUkqQzWvUdZcO9z5q1Md0NHykBlgEjR92SxKske2BHysYbzFKnq9wS+q+uK yD1Wr7asHnRGGNCP1w2argxESstCSoENkDLYap2ys6k1AeKzZPCsj0ZB0JogTTVSulNIwdQR ImX36BQ4fEynSkGkTBNSppoQKYgURAoiBZGCSEGkIFIQKYgURAoiZcJ9NBWcxo2U7/keRMpm OilvljVvVlC+CSERKWNAyuaVTT4oHnXKzkHKxLoQkbITkZL3M/YjzrJYXdCwR/OUmDQdypfK TVpxRyYvGOfWPR1vIiLJm5PilUsWfStVDrn3tcT6t09AkmRZ0nZLR6RMCim8raO03U4jdsFa O8oS9ic1abJOq616mqfld0xyi5W+V+gUFdFPSTtRDBSvXLGwsuUOd8Va//YKSEOGoLhUOiJl MnZKzoDSovwJpS15If8USOm3TQ51xyS3kQJzwcTtTCFF8tIsrGy5w11x0r8rBWxlpdIRKRPS Kfaf3LUyWBAmGe1A+wOEpawuT0sAxSv3ssoHcPIKGIqt+KU8iJQJIgUoiVJPtToZ7DevTqlC Cm2DUjsZ1CllpAzUKYBzr91qI1K2FCnA8HD6nBkFLlJ08oz4kSLidQSzU5jtKW8oXradUkbK QDvFFoPvx0u2Cynf8R27EilmauFBCptocNMR3FHJxbTJgxQRbyL6jIEavhQvxSLyI0Xf8s59 bDH4TKqPSNkF6z4kG+XWlLxPQaRsFcVsOIkb30Kk7D6k9Iv3cQ1u7WykBEMj6mf1kdhxNITL aB9Dl360KnZsBHW4bOKr7NETb6ZhayKllu+dWlJ4dyqOESntNJ8wUgZFBlOElKA2UsarU4Ix 6ZBJI6WOLylEylYhJSEB306q9p5mYatvBdLNjk4idZGKVEmgnlL+fFSSNrU9agTtftg3Tn5Y 4j5LAx35aAdAgKdMIvfVt0xauSWWlWe7KBkQqAYvnAnYO9sH7Bx2g9aAJK0hXALHGdBQcQfK otwkwRZUo4XqsfEihfUs36KukNLria3tOpBudlQS6HunI5M4OkX689FJojwqdr8HEauacfIT 5DF3owAd+WgHQICnTNLjm+oTc1O5A2LlDUdKKyh5uIFbfys6KahEw2aQAr1mVCMl8OgUBynC TZLjCkm2memxcSKl3ac6KhBqgFqBdLOjkkDfOy2ZxEGK9OejksRhTgqPYUEWZCoDuxckQktA Rz7qHuQpk6SEZe9ERmqqeOaWQ4nC+QTsOefhtFzfADcUQeCxcL08LdyB0iuTyEhnN6orp82l Ail2EuUmyW3BwOrU8SIl7Ug9LqOdQOp/lQT63gmq7JQiX9ay6xCI/7STn6DVK1vX2gEQ5CmT tKIgLgafwuFLq+QgC/pl8zzjgetYp+iNwGcbQGYwwZDhwyNSUHEPMKu0U2yd4p2fBFanjt2i TVrSRvHpFCsJ9L3Deo1WIUXna3c6JaQoJz8BJWnuOvLRDoBcncKp0wpbxcikdYpGSgt4OGk5 ri3Ko0HLp1MGIsXk9yDF+D1plbwCOiJ5PGOUhB9o0RZJVC86rpBM3yatcSOlQ5nFkOckBgaK Cfhwp5Iohzw60rFTxL3C2hHDZC9ISkhRTn6CnHJDDDry0Q6AoJ0ik8RBEhSPiXIH5NcpNUwL Bylln33GqGm5jiOrdAp0lzJI7fjtFEenuE57qnSK6wopsDp1vO9T4nbAn+5E+t5x5j7SzY5K ohzyqEg499HOetQMSrnniWG3C6QoJz98HOq4jny0AyBQa11ey5r5mLlPHaT4nuOWx3FoGSnB 2JHSGhkpQQVSYAuqvjU9NtF3tMq2yMYwYY/DbXqbPzGHFBP2dDFLb/N7cs7Vg1OvEYnE24KU IECkTB4pUYvQItikFFugUrYWKVMEFFxL3hHfpyBSQBGBb8odbH61p1HKgPiVylb1VzBCkmAc jMkM6ZSg+b3xIwUqlaDRIAHe2Jb8+U0EKUFtpNRVKfzVAZswhjwIESmD7eYyUpp1tHlPF0xc p4wLKcRSqqwFgpy2Le/kY/s+RS34hq2wtEarV3rBGS9quZLBVqzt9Xk+6127/X4jCCq/gFEv YOCSsloQNd6SG6ZUxSgBi9NnrNJlNXV29y2Q/N2Jo14JnnCpVhY7mJmnBWusuNdfE/Z2Doti 8UUdxooUueDLX7KW1mj1Si8440UtV9J2xnHF7vV6cO3FPerFqxLUS124pKwWRE32hindo2U8 pctq6uw93wp4nhGSlZFiL9WqYiEz9zW1pwVrrLjXXxP2dk4Q9Xv8Daeuw1iRIhd8+WJwaY1W r/SCM170cqV4xPkSJm273QKPZfAiRS0+wyVlvSBKR0vpHi3jKV1W08pOPeepkbAsNViqVcVC Zu5yuqcFa6y4N1sTLnVOkLXb4pKM9E5iMFLAejFco9UrvaDZtDqnok6B84Gb56gXL1JMsfaS sl4QHTGle7RM4P8WD2YvIyVpyyMmgrKlZK2cD2XmacEaK+7114T9nZOHPdFMqg4TQApfDG6V 1mjVSm/u6BSpyMXScCDzNdcpcvEZLinrBVE6Wkr3aBmfTlHimuwenUJiOW3wIEWx1joFMHOX 0z0tWGfFvfaasLdzNEddhwkgRY25cI3WrPTawqjlyrQtPoEO1Fitv4eGR70E1sqy304BS8oq PcxePyVcboanz1jMOibOa6ckbVUZD1IUa1UsZGaMELimbrdgnRX32mvC3s5RApg6TAApyo6H a7TFSq8ljFquDGOx5Bf01NwnLh/1YlRo1Kqc+4AlZV0KPCWzdkr9yZReT1XF2kgx0xVbCNjO fHkqDv1I0ayduQ9gltpvwWAL1llxr70m7O0cVWFThyl6nzLrbimz1rg5hsnstgYiZchaOdIU IkW9JZ+SlhnLIjkiBQmRMgJSgmZ3xrN/tTrRJNRSMCYBt16sGUHKqPXyfJ8QbFcD1ii9RhKi Zz1iPURdeQNEyq5GStbSLxj4XFZdeYMZRUrTVVK1eqyS6BfnckWzWL+1ImF2vQQK7Fr/sqq6 B3cw+z6ZUouscDm2LVekYCSsNJTFu6jrFdC7jMs0iZogC5WirrxB05avv7F4skhpuEqqVo91 ErAg6iz/qFVSkN3sNvbpFLisqtsTLCJ739HLRVZnOTbK+co7jISVhjy9i7peAb3LuHmv3+8Z laKvvEHTlq+/sXiySGm4SqpWj3USsCDqICWzdzfbPVuFFLisqu7ARWQfUtQiK1yOZU82f4Bh JKw05Old1PUKqPLBZdy8ncrXs/KrDXXlDZq2fP2NxZNFClCvRVzVKqm7LhqAJO6Scul9s9lt XGGnlD4+chaRfUjRu6nBcizfB525kbDSkKd3UdcroHcZV2zkz7RKUVfeoHHL199YvAVIqb9K qlaPW2AReRBSoE4xu42rkQIXUp1F5Ir1ab7ICpdjc9IjeSkSVhrw9C7q+gX0LePGvMdjrVLU lTcYpeWT1rQgpdYqqbFTOiU7Rf+w12+hFxat7fVuY7jA7FtWBUgx+QKt64vMapEVLsfm/aCf lyJBpaEs3kVdr4DeZVz+ARg3jOQinrryBo1b3iwiB1OAlDqrpBopztwHKOLIWlL2rqCa3cZw gdm3rAqQopdO9chk+wdUi6xwOTZPgzQvRYJKQ1m8i7peAb3LuFwpMANOfVuqrrxB45Y3i8jb i5StmN9nW6I7p4JIOsPCbzdScMUWkVKPcMV2dyIFCZGChEhBpCCNiBQkJEQKEiIFCZGChEhB QqQgIVKQECmIFCREChIiBQmRgoRIQUKkICFSkBApiBQkRAoSIgUJkYKESEFCpCAhUpCQEClI U4KUug4Xi1OhRiojGFjeAMeWJWdfQRPRESlbVK7vapNI2TSUESmIFETKRJCi3BEqR5DaGSJw 06iSqMAbCZ1EOqyBH0kvUiDrNhXeM6CjRHMSR94nmSlPyglHGCWEchmpzysEY5/jCGb4AYCI FOOOUDmC1M4QgZtGlUQF3kjXc6TN2sVGtc9HxboT5VHHdZRoTveJ29bBmFJOxxJSrh+ly0iv q8mSc6nhBwAiUpQ7QnOMoHKGaLtp1B4Z+7afRTfSdalYujcIKZB1HOYkcR0l6lMIE+UHTZVn 5CwJoVxGKp6wWMcJZp0DABEp2t1iDp0h2m4aVRIVeCNdL2826xpIgay5s8fcdZSoHTq2ejYo pJwOUuQ/5TLS62rS7wRz4AGAiJRcuiNUjiCNM0ToplF7LExaFZHeHoD3BiHFYd3udOzsUi+o UwgpSeshRbuM9LmadJxg5jUOAESkKHeEyhGkcYZou2lUSVTgjfQixdyD5wAqZ48en4/ahWMv SHL3tD1jp1DrEOOBSJEuI41bSPt8RMdOyWscAIhIUe4IlSNI4wzRdtOokujAF+l6jrRZQz+S xtmjx+ejduEYByC7M/dJOlZ5QflYXi2EdBlp3ELa5yM6c5986AGAiJTpfKcQhzkSIqUGkRj7 CpFSR0xUKVOMFCQkRAoSIgVp4khBQkKkICFSkBApSIgUJEQKEiIFCZGCbYCESEFCpCAhUpAQ KUiIFCREChISIgUJkYKESEFCpCAhUpAQKUiIFCQkRArSliEl2MTdSVcnGJ8YtbyljKO2E26x YCzlFY0hvKP1wzqlBpOs6UC3oMP7bpNICbYD9MHw6CBocXdSQZTnwk8DIbJBWp0sz1MSWA6I Jo4Uyv1XtegUI6W+h9sdiJQ8S9ppHjCAEOFdqpUpvx1hnraSgY5dxo2UvN8RekV5SIRuGuFT rTwraq+S4FFXv53sfeF1KwuFRxblitHxyCiTDNYb1h3p262VKZ4BQDF0hqIdVsq76p4OQG3d 0iUzmUR7nJRSqyaAvikdHyzSiyWsNPQ/qVtQeumEVXGaNRdu6lhylof/FBqGS9fKQ9BPmqdH JN1mhSvNBn7r7IZp97i/I+UhEbppdHSK9Kzo+mC0k8Ds/ZBmPen3qHDFCD0yqiS1dUqvL9tO 8YRIgQ6WtC/MXPtZ6lmBU1tPVVQSXVsptXGJCXxTQr9O0oslrDT0P6n9csok3qpYkrBuDaJ+ jzsd6vX7PYl7Zi/AgaDgyUUCLaHbTN+TDjlHQEoiPGQpD4nQTaODlMIfZKuieWF25dxRjG+5 dsUIPTK2abPRJyVZkLG6Kp6weaEjSO0LU/5ry3s6cGrrq0rhMrIQ3jSB3SBtx/+k8GIJK132 P9mSXjpbub8qcNQPsnZblJSmRKod7om31E4tIxJoCd1m6p5yyDnK3CewRhjoprFspwRlH4x2 krKXxyIfdABoOdhqZKe0oiBuZUZXg+b1OqyEKaGOd31aehpE1zYAVQHluf4nAzvS53/S+OX0 SObXKXnY4zZLS7gwZJGUDZpQp3h5ettMOeQcGSmFh8SkNRgprg9Gpzut7FqnZOrxshOq8prq lLzTYsO64ckrbukU4AhSyaKSlHQKENevU6RWlyUMQIqjU5QPRVBp6H9S++XMhOdfb1UcO0X+ jjneYhnZduwU4+sz16UHbptp4Y1DztGQojwkQg+QBSrTomGMD8ZWWmpe6OWRGyF9a8i2+12V p5K4XiWrkRIHCZ8zKp4ktv1BQjtFyaKSOHaKU1tYFcFMJdG1HYAUx06RSIGVhv4ntV9O6U3c rYoti577yN8dPlnuySsSw7mP8fWZ69IDt8208NIh58hIUR4StZvGlID00uejTGt8MEatkrdG 6OXRnfvY/a49MvaV/lfMgmHvU5jmbBUThgT4g4STECWLSuLMfWBtQVU0M5VElQCQAn1Tuv4n AxVpVRr6n9R+OcHcJ/E3a0vPdtgfroBpW14x2zSx36cYX58ekVSb6WrETabLQ19lhQ1gNyuk hudJuDafKXfpjRxy7sJ1n56cp/YmcFxCb7aOYGjkkHMXIiVqEVoEk2A9I9TMISeuJSONipSt XigOwCoA0kwgZTzLf8GIyREpiBREys5CyqgLxcWqpVgJBRnMkX8yZR8sq6oMKhIs3MLTBJGm U6c0XSi2Vi1Ly7GGi07J30WqZVW9dAryqbVW9zRBpGlEStOFYmvVsuUbRYp3UfpkQ7msqpdO QT611uqeJog0pXZK44XiqiVQw8VO6bwQB/m85zkhTTNS6i8UW6uWrfLok2fgxFBrWVUvnWbq CFV74RaRMt1IGW2h2Fq17LgZDBdjpxTLqpadIj52sxduDVIQLlOJlNEWiotVSzmHsTMYLgop YFnVmfvYC7eIlOlGysQLw/ZGpCBSECmIFKQtRwoSIgUJkYKEhEhBQqQgIVKQEClIiBQkRAoS IgUJCZGChEhBQqQgIVKQEClIiBQkRAoSEiIFCZGChEhBQqQgIVKQEClIiBQkJEQKEiIFCZGC NLVICZDGQ6hTkFCnWJejMVE6aRiPGkmQdjRS6mcORsyHhEhBpMweUtTxUsq9NDwe2JzoJTOB JHBMGXSCMExScUYx0tQjRR1Zp9xLw+OBzWnGMhNMAk+LG3CCMExScUYx0tQjRR2ta7mXto75 BQccOUm8SPGdIAyTVJxRjDT1SDE+p4Pcezyw3d+Bzw02QEruOa4XJqk4oxhp+nWKPFpXwQAe D+zoFJhkAFIG6ZTcf0Yx0szYKepAaHA8sDnN2EaKcWCteLTTElJcO8VOUnFGMdLMzH0kDODx wM7cByQxkxfhpHrQCcIwScUZxUgz8T5lAjRTJwgjbRtSZuwEYaRtQ8psnSCMtJ2jD9KOREq3 ZjZvusvdLjYoIqUGbhZfxPZEpCh68e7uyfUqpKBG2SVIWb+3e5F1dnfx4smLeX71ZPfeq7z7 n1jsPpHnF8Xfq4tXNlZX864cZjYe7t7LYNPtimsVaGYnJaRkdsUaaWcgZXV1Y5X3+OXu5cU8 v/3KxhMneVefvLp+Mn/i3qvrDD6PcggtavVxcXXj4sMVOoUzWzXZ2dWjiJQdg5TF9fwqR8oG +6/o+u5VcU/8zW+/evn1D3c1KFiGjcUKpHBmi3b2dUTKjkGKQkBX/JdfuV0OJl1giWwsvvii iTXjjQcpXeuf/QtpB+kUiZTF5/KNooOVToFIWdyotmiNTtHZryJSdo6d8qi0UxRSXty4WCDl 4klhp9z+oj36XFxdv7pqTY9twHBmqyaO2Slo0e68uY9EyuXF7tPWoCHnPqLzzbCzsbq4eJlf P1EehBize9dNHM59dtz7lCG0vvj0xogFrS9iY+8QpHQnTtjau0enjExPyNd4SIgUpF2ElLmJ FODl+kPzc6Mzm5sbmtkkmRsuUoUsc4iN4UiZq9NWn73ZDhri5uDLNdJWs64hWf3ed2VRxSJS xoWUmz9rBw2RUqsbqlnXkKw+Uub8xSJSBiDl8fmDTwnNzXW3Dj44f3PGHrSvnD/4Q36V8krx TM7DIIPDwBfunP+qzGWtKLtZlJDPPXJw/pF8/eb5j8yZEuYOfuTmj+T551mSz7tjinNPCm8k s8cpJXxRerm2WgiZnV19cM4tQQmYf0T83d1I+cD641/pPvgs8gN3MhX9VP75O+1HrVApH2CN mT91MwycR/YDd65/5M4KnXKnLCGfu/nz2c3ias6UMPf43OMH8/yVT+WP3FySDNwzwivJ7JSu 8HPl2mohZHYlhFO6FPAj7O8HdztS2EM1X2rQLM9Yax185GXQx5aV8tmvWp9f/7rHYeAg5WCW rx+sQMpBWUI+93l9NVdYG1+Y+8K8TFaWDNwzwkMzQ5buCD9Xrq0WQmZXQjilSwFf+TKOPnOm Ee0Glc308p0H5x+vsFLmH5//CTbcwAAiZX5e6/wyUuZ1RxRdYlkb/D8+fMx5JLPvzYF8MKUR 3q1YwVMLoWoko53SCwERKT6k6Ict/8x8xcTnzoNfd/BmN3B0yheqLVqjU3Jbp2hrQ/QVGz6+ YEs2X76nhdcTpnlY0GfmByNFCyGza50CS5e5UadYbTf/67kJlJ1y58v5U9bwASY+T809Nfe4 G8Bu+eAH1rM7Ldb2PWOnGKtlzrI2RF/N//oXPmgj5ZWfLd3TwusJ0yst1WKEt0uHSNFCyOza ToGly8LRTrHa7pH5IlBzn6deOf9VhaUI36Wsz+fz625QzD6E5r5TTZ0UaxspZu4jmbG5z7xl bYi++on5+cftOdNT83Ole5KDeQcjk8gMRvhHrEiIFCWEyq7nPqAELfQHce5T/9XFaO9S6hK3 fUdlvUmRJlSjHYaUOaT6hDql4evQCdAj4h0d0swhBQkJkYKESEFCpCAhUpAQKUiIFCREChIS IgUJkYKESEFCpCAhUpAQKUiIFCQkRAoSIgUJkYKESEFCpCAhUpAQKUhIiBQkRAoSIgUJkYKE SEFCpCAh/T5uOgzSug2hvAAAAABJRU5ErkJggg== --=_north-20311-1589881609-0001-2-- From nobody Tue May 19 04:44:53 2020 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 420AA3A089D for ; Tue, 19 May 2020 04:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 fE1NL1Dzf52K for ; Tue, 19 May 2020 04:44:49 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 BC1B53A0890 for ; Tue, 19 May 2020 04:44:49 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 867778002B for ; Tue, 19 May 2020 11:44:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=3612; q=dns/txt; s=default; t=1589888689; h=from : subject : date : to; bh=tX1G/nQMGJ01CQZHaWH8JQZ6iyl5r7Rj5kaoBoCsJWA=; b=gSkkLDkcOZptWSZcFpAT4iR584BU5WUCIaQ3kN/Z8LZ+XrSbTZtZ17Z/NePS1RbhKplZW Qy3AEXGMWVK+icgbPmm2gMY4FmeOSGcuBoFDxiX0JPlfemZUawSkA5zya5c4FFZgi1irria lzOOdXcmrBZKLkioP44S/k3zjugD6HY= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 69C1D7FC9A for ; Tue, 19 May 2020 11:44:49 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 May 2020 13:44:49 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <0127a137400d466095373373ec887b90@bayviewphysicians.com> References: <0127a137400d466095373373ec887b90@bayviewphysicians.com> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <4c2c727be112c186a3866685629b0859@junc.eu> X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org failed 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, 19 May 2020 11:44:52 -0000 On 2020-05-19 00:09, Douglas E. Foster wrote: > I understand your question to be "Why do I see invalid DKIM signatures > on messages from the IETF mailing list?" yes this is my consern, it should not be breaked on take ownerships, if maillist can break dkim and take ownerships and still not make it dmarc pass then its incompetent maillist admins its just sadly not the only maillist its daily problem on > I can provide your answer > > The typical message on this mailing list has three signatures: > > Signature Analysis: > > * The first signature is from the submitter's organization. In your > message, it was from junc.eu. yes > > * The second signature is applied by IETF shortly after receipt of > the message. opendkim resign ? > > * IETF adds an Athentication-Results header which indicates that the > junc.eu signature was valid when they checked it yes i did my homework then > . > * Then, IETF changes the FROM address to be @dmarc.ietf.org and tags > the Subject with [dmarc-ietf]. This breaks both of the first two > signatures. why is it done ?, to fix there own problem of breaking dkim ? > > * Then, IETF applies a second signature which is verifiable. it just not giving dmarc pass, why ? > > Integrity Analysis: > > * The IETF rule is "an unverified signature is the same as no > signature." Therefore, the invalid signatures can and should be > ignored. It appears that your tool is getting confused by the invalid > IETF signature and ignoring the valid one. i think that on the safe side to not make dkim pass with signatures not from original outhor domain, if that ships sail it would make it hard to verify without openarc sealing > > * The message passes SPF because the Sender Address has been changed > to dmarc-bounces@ietf.org. thats the standard aling changes, all well there > > * The second passes DKIM because the second IETF signature verifies. but why is it not dmarc pass > > * No official assertion is been made about the sender's domain, so > there is no need to verify against that domain. But if you want to > do so, you can evaluate whether to place trust in the > Authentication-Results header applied by IETF. waiting for AuthRes plugin in spamassassin then all problems will be bigger if results is evaluated outside of spamassassin from AR headers hope developpers wake up on the risk of breaking more then just dkim > > * IETF converts all messages to plain text, and strips or blocks > attachments, so they have minimized the opportunity for malicious > submission. i remember with amavisd-new it was good to disable 8bitmime before letting amavisd-new do its dkim sign, that helps make dkim signed signature not break on mime converters > > Implications for Email Defenses: > > This example is a reminder that every message is a take-it-or-leave-it > proposition. You can accept the message or reject it, based on the > message characteristics, but you will probably be unable to cannot > change the sender's behavior. In this situation, you may not like > having two signatures from IETF, but you cannot change IETF. As a > result, any spam filter needs to be very flexible about exceptions. > Too many spam filters do not have adequate exception mechanisms. i will let spamassassin do its work on dkim breakage on maillists, but that is same reason i do not use sid-milter, opendkim, openarc, opendmarc, its designed badly to maillists that claim its impossible to not break dkim > > Hope this helps, it does hopefully :=) From nobody Tue May 19 13:48:07 2020 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 EC1E43A114C for ; Tue, 19 May 2020 13:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=junc.eu 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 SrZCghyizmRa for ; Tue, 19 May 2020 13:48:03 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 BCA883A0BE4 for ; Tue, 19 May 2020 13:48:03 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id A04347FDEF for ; Tue, 19 May 2020 20:48:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=770; q=dns/txt; s=default; t=1589921283; h=from : subject : date : to; bh=3eIe1ruMQz+7PzDFoTdSxC4jUde4WkvDnB4hVTrBi0A=; b=E2Ua4IeU12gBYbm97cy+LQI6p3bxb1jV6UzRukoq1aERs7fa7A+mz0xQLY8VTR+Kq6eo6 JwuFiSOgyNN+x6+KLpVnOdLiAuqAwhLzyYF4DaJ/ZYjaup59pkBHXuVS0EMSIiBSnUrMkEg ZBq+tXvH04v85zshDQkscZzU5WwpDHo= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 7B9027FDCF for ; Tue, 19 May 2020 20:48:03 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 May 2020 22:48:03 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <20200516172453.53A841962CDD@ary.qy> References: <20200516172453.53A841962CDD@ary.qy> User-Agent: Roundcube Webmail/1.4.1 Message-ID: X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] dmarc.ietf.org does not fail 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, 19 May 2020 20:48:05 -0000 On 2020-05-16 19:24, John Levine wrote: > In article you write: >> https://dmarcian.com/domain-checker/ test it there > > You're misreading what it says. The DMARC setup is fine. page does not test arc results :) >> if its complete impossible to not break dkim i will leave this >> maillist > > After you leave, you might want to review the ARC work we've been > doing over the past year. it does not matter if opendmarc does not use openarc yet opendmarc from trunk does, but none of it is stable on gentoo, even opendkim is not stable, since gentoo devs insists on backports with delays to not happend soon thats why i leaved from opendkim, openarc, opendmarc, its simple to unstable for real life From nobody Tue May 19 17:23:52 2020 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 8ADCF3A0783 for ; Tue, 19 May 2020 17:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=WBdAe3yE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=djKr8rQE 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 Ap1R71iJTCB6 for ; Tue, 19 May 2020 17:23:49 -0700 (PDT) Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (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 350583A003E for ; Tue, 19 May 2020 17:23:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2233; t=1589934220; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=dWRLoGCJRZ2K0JZ1RFm3W8YZ0+I=; b=WBdAe3yE2fs9EgidlV0tPTNNp0wgtPonffCHXoZRl0PbRDjBGlkoGXojzj7mTC 4sK66P+BkpR0vDF98fFY+Fmqemp5yKeziak8Q1/8WLbPklVrE62o2YW+PNwwmvkk KDP0cHnzZ2oltiVM6rjB2lL6pFNGFgNg/wT+ir347S5Fw= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Tue, 19 May 2020 20:23:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 661549256.1.4512; Tue, 19 May 2020 20:23:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2233; t=1589933838; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CAJTRDy o49JfNHTOtr3hYs9+C3ehvDHvCGoQ84hD4yc=; b=djKr8rQExQeQs6yr94uMCKL eUHruKTwcfAexUkDBt0+st6hhKb7Lfy43LPVDtVB9L3/LPQF/mzmP0BZN77JQuVP xlmIA8+8o8+nkr6nEh4KYq0NXmxQPTwar7PFJOKLjjBb8UOoC1TBiOBEqyr9JVU3 MYdV7KkPPLvTSp250vPY= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Tue, 19 May 2020 20:17:18 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1667912187.3.18316; Tue, 19 May 2020 20:17:17 -0400 Message-ID: <5EC47889.3030905@isdg.net> Date: Tue, 19 May 2020 20:23:37 -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: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 00:23:52 -0000 On 5/18/2020 8:25 PM, Seth Blank wrote: > On Mon, May 18, 2020 at 1:31 PM John Levine > wrote: > > There are vast numbers of sites producing and consuming XML reports. > They interoperate. It works. There is no problem to be solved here. > Can we stop now and work on something else? > > > The working group's consensus appears to be that aggregate reporting > does not need to support JSON output. Does anyone disagree? > > Seth, as Chair-- Since the specs will already be outdated by the time it is completed, may I suggest that there is a new tag that provides a "Preferred Report Format" or "prf=" tag using registered acronymns for long time "standard" formats. For example: prf=cvs,json,xml,afrf,iodef 1st choice cvs, 2nd choice json 3rd choice xml new current fall back 4rd choice afrf old fall back, obsolete? See Note 1 3rd choice iodef old fall back, obsolete? See note 1 The verifier will do what can it offer. The publisher is providing a preference, that it may not get. The fall back could be the XML format. This does two things: 1) Flexibility offers a consumer preference, verifiers can eventually, as a "Product Update," provide additional report formats. 2) It doesn't lock in just the "XML" format. By the time a PS DMARC appears and it is finally completed, it would be outdated as the growth of DMARC is realized with a "better spec." So flexibility here would be a plus. Consider GitHub for its Web Hooks, JSON only. The conversion tools availability is surely there, but we can't assume the consumers have programming skills. Note #1, there are DMARC descriptions and record generation wizards, who don't even offer the "rf=" tag in their wizards and just document XML as the report format. Case in point, google: https://support.google.com/a/answer/2466563?hl=en&ref_topic=2759254 So does this suggest a complete removal of "rf=" tag, no more afrf and iodef, and xml only? If so, can we add the "Preferred Report Format" "prf=" tag? I am asking for the "prf=" tag and to register the common format acronyms, allowing for advanced DMARC processors to add support over time. thanks. -- HLS From nobody Tue May 19 17:46:35 2020 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 A92FD3A07DE for ; Tue, 19 May 2020 17:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=toRn6fr3; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qMbKfnQQ 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 sk27nSgUCDGg for ; Tue, 19 May 2020 17:46:30 -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 C1A803A07CE for ; Tue, 19 May 2020 17:46:30 -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 83E05F802AF; Tue, 19 May 2020 20:46:29 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589935589; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ZVynnJCwmykWQ3g7vPiqSpHJa8q+o/bOxN9891r1ZSI=; b=toRn6fr3uGZsLLN6F9Ktx+ssr+bGoxGQjzSZUIiUa3TH/aJkZUupuYzXz0nuYXmZFx+FZ OUBJREkXpWAF8FUAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589935589; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ZVynnJCwmykWQ3g7vPiqSpHJa8q+o/bOxN9891r1ZSI=; b=qMbKfnQQYbuYrQmLwr9/mFGb3K3zcb+xgVtGUl8ILR0S/HKOi5/Ez5JHlqu5Ms0gRKGA7 HOa7wCiAd2PyV/8PaP5WcQsq1m2TVZihKe+s0CZgCMbpO5x29tHBwINZCrEXQDONSSU8IGw XyqCoVt271LjEon+7TnP4fn6qMfk8KQtUR9wKXTsZN9oTglCnVYQzIj1U1DuuBKEvLEWeFs tfOoqAngiV0Gs6XA1n++WDBm3j+d1QPpcxdg/tXgBBNXRjS0bjnLXvdXRTPaDH8isZtu2rr E557pBZjskptZckiFB7dYUbSE0bPlpPTO9hV1YIkjSebCI3zgvDEl2+aTYEQ== 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 4458BF8009D; Tue, 19 May 2020 20:46:29 -0400 (EDT) Date: Wed, 20 May 2020 00:46:26 +0000 In-Reply-To: <5EC47889.3030905@isdg.net> References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.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: <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 00:46:33 -0000 On May 20, 2020 12:23:37 AM UTC, Hector Santos wrote: >On 5/18/2020 8:25 PM, Seth Blank wrote: >> On Mon, May 18, 2020 at 1:31 PM John Levine > > wrote: >> >> There are vast numbers of sites producing and consuming XML >reports=2E >> They interoperate=2E It works=2E There is no problem to be solved >here=2E >> Can we stop now and work on something else? >> >> >> The working group's consensus appears to be that aggregate reporting >> does not need to support JSON output=2E Does anyone disagree? >> >> Seth, as Chair-- > >Since the specs will already be outdated by the time it is completed,=20 >may I suggest that there is a new tag that provides a "Preferred=20 >Report Format" or "prf=3D" tag using registered acronymns for long time= =20 >"standard" formats=2E For example: > >prf=3Dcvs,json,xml,afrf,iodef > >1st choice cvs, >2nd choice json >3rd choice xml new current fall back >4rd choice afrf old fall back, obsolete? See Note 1 >3rd choice iodef old fall back, obsolete? See note 1 > >The verifier will do what can it offer=2E The publisher is providing a=20 >preference, that it may not get=2E The fall back could be the XML format= =2E > >This does two things: > >1) Flexibility offers a consumer preference, verifiers can eventually,=20 >as a "Product Update," provide additional report formats=2E > >2) It doesn't lock in just the "XML" format=2E > >By the time a PS DMARC appears and it is finally completed, it would=20 >be outdated as the growth of DMARC is realized with a "better spec=2E"=20 >So flexibility here would be a plus=2E Consider GitHub for its Web=20 >Hooks, JSON only=2E > >The conversion tools availability is surely there, but we can't assume=20 >the consumers have programming skills=2E > >Note #1, there are DMARC descriptions and record generation wizards,=20 >who don't even offer the "rf=3D" tag in their wizards and just document= =20 >XML as the report format=2E Case in point, google: > >https://support=2Egoogle=2Ecom/a/answer/2466563?hl=3Den&ref_topic=3D27592= 54 > >So does this suggest a complete removal of "rf=3D" tag, no more afrf and= =20 >iodef, and xml only? > >If so, can we add the "Preferred Report Format" "prf=3D" tag? I am=20 >asking for the "prf=3D" tag and to register the common format acronyms,= =20 >allowing for advanced DMARC processors to add support over time=2E Please don't=2E This is a large stack of protocol and implementation comp= lexity for little or no gain=2E Hector, you realize that for this to work reliably you would need to code = up support for everything so that you wouldn't have undeliverable reports? Have you implemented the XML format already and you're willing to code up = the alternatives too? Scott K From nobody Wed May 20 05:50:22 2020 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 463B63A096B for ; Wed, 20 May 2020 05:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=Ok0MDn+O; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=BgnncZRO 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 o8ldD_Gzp7cl for ; Wed, 20 May 2020 05:49:27 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (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 10CC43A096A for ; Wed, 20 May 2020 05:49:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2535; t=1589978956; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=JVZ5//BR0Of5VOIjQGaTWzsMtGM=; b=Ok0MDn+OIj4Em835fP+lB1gv7ZFJPWwEzTClGw8lSaCVRKOteJKHDS82q4xJoR HPygla2+MYPOSGjHIQGLevLmd28AyItchMAXU820hZhHlMl+Kz35eQWkAMTvmEU5 sZazgA2wXcdmytn55n0MpBq+kZIYYrnhZaZazwZ/4czlY= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 08:49:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 706285148.1.7016; Wed, 20 May 2020 08:49:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2535; t=1589978573; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Z0TcVZr iPHC1IjoUKEaRvqeSynEtbbNS7OpKM1j6iO8=; b=BgnncZROeUxK77N+u96Ry1f 64KixWsJadGW41Q8h6e1ukH1p3B0k1UOSGBM2yQSprjLmAYApBxrFB+wtEMRA5W4 C8etPwXpCJqDYr0HjNZyEzAIrhfWQeIjG/Hw4606zUgiZf8GF1lbwCKtsNziJQgQ qD1f5Ldcsbm7ka5sYXwU= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 08:42:52 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1712647109.3.17876; Wed, 20 May 2020 08:42:52 -0400 Message-ID: <5EC52749.20801@isdg.net> Date: Wed, 20 May 2020 08:49:13 -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: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> In-Reply-To: <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 12:50:19 -0000 On 5/19/2020 8:46 PM, Scott Kitterman wrote: > > Please don't. This is a large stack of protocol and implementation complexity for little or no gain. > Rhetorically, I feel the same about reporting. What is gained from it? But that is just my opinion since the proposed ideas for reporting came and it was mostly rejected with SSP. It's redundant overhead. If reporting is going to be optional feature to possibly implement, it might as well be useful for consumers and that is where the gain will be. > Hector, you realize that for this to work reliably you would need to code up support for everything so that you wouldn't have undeliverable reports? > The proposal is more to IANA register the formats (the common ones mostly used in practice) and not to mandate implementers use them all. XML would be the fall back. At a minimum, XML is what publisher (or report handler) will get despite the publisher stating a preferred reporting format, like: prf=csv, json, xml. That's asking the verifier, if you can handle a csv or json format, please send us these reports. I can see where certain 3rd party report handlers would only need XML and they generate readable reports for their DMARC customers. But we can't assume all publishers will be using a 3rd party report handler. So its about being ready for the future and DMARC not be obsolete fixed with XML only. In my opinion, JSON is the direction most systems are heading too. > Have you implemented the XML format already and you're willing to code up the alternatives too? I can support any format. Easily done with reporting/output templates for CSV, JSON or XML -- single sourced output generator. This benefits customers, consumers, publishers who will have tools already, today, that imports certain common formats already, and generally, it would begin with a CSV format. Just consider, all spreadsheets apps, Microsoft, Google, etc, all support CSV today, but not JSON or XML. Most or not all, SQL packages, support CSV and probably XML and maybe JSON. Let me double check with Google Docs ..... no. It supports csv, txt, tab, htm, html, xls, xlsx, xlsm, xlt, xltm, xltx, ods I don't know if the list will strip attachments, but this link shows an image of the Google Docs popup I got: https://secure.winserver.com/public/files/google-json-no-support.png So, from a product design standpoint, for immediate consumer "pay off," at the very least, csv should be the default option, not XML. -- HLS From nobody Wed May 20 07:01:48 2020 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 E2E893A0A60 for ; Wed, 20 May 2020 07:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=HG+sN94A; dkim=pass (2048-bit key) header.d=kitterman.com header.b=i6EeyKrb 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 4Q-fVyDSLVPo for ; Wed, 20 May 2020 07:01: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 A713B3A0A5E for ; Wed, 20 May 2020 07:01:43 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 34B90F8027B for ; Wed, 20 May 2020 10:01:42 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589983302; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=+niYjbk3ZSl62L3p90vMtMxEmc2OlQ/aaNj8bUGbBOo=; b=HG+sN94ALKGBzOXgXRiFX43Be4Yu3pNqYc3aZYpORRZLKPnRSqdZNv2946E+R/Fueg5ea pr1IjsYgdJUbDqfAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589983302; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=+niYjbk3ZSl62L3p90vMtMxEmc2OlQ/aaNj8bUGbBOo=; b=i6EeyKrbz0UepT1/crxw9izAqGNB62IVTSp/HIq4D4pQTjAwat6Rhkfsx3Cc9IT/qa+Ex oa53I5V0EMmkAfpBDV+iWTUBMBWHtKRRWQgAySXn1HyR+6oiDT7RfoAi1qWoRK20uqtBJRp kDynib1ZE1NCuKqZNsco7ybXxQ4x+FzpkV8fnnkMW2Qc+6DsRYCbrTh47GAIcN4GNABhWWk a7C7yWElbvjID1G3Evaff8c0eNPn/341hBUb1159T6eyczd/mQ0SvDlodOauRmnTyQpEo+K 48ebIsmAUPNwkNQRPT8dUFl89gZ0Q3s/IVG08HvbH1Wlw7vCjoOqrKTaGlOQ== Received: from localhost.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 087BAF8009D for ; Wed, 20 May 2020 10:01:42 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 20 May 2020 10:01:41 -0400 Message-ID: <5114096.80zr39ycxx@localhost> In-Reply-To: <5EC52749.20801@isdg.net> References: <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 14:01:46 -0000 On Wednesday, May 20, 2020 8:49:13 AM EDT Hector Santos wrote: > On 5/19/2020 8:46 PM, Scott Kitterman wrote: > > Please don't. This is a large stack of protocol and implementation > > complexity for little or no gain. > Rhetorically, I feel the same about reporting. What is gained from > it? But that is just my opinion since the proposed ideas for > reporting came and it was mostly rejected with SSP. It's redundant > overhead. If reporting is going to be optional feature to possibly > implement, it might as well be useful for consumers and that is where > the gain will be. > > > Hector, you realize that for this to work reliably you would need to code > > up support for everything so that you wouldn't have undeliverable > > reports? > The proposal is more to IANA register the formats (the common ones > mostly used in practice) and not to mandate implementers use them all. > XML would be the fall back. At a minimum, XML is what publisher (or > report handler) will get despite the publisher stating a preferred > reporting format, like: > > prf=csv, json, xml. > > That's asking the verifier, if you can handle a csv or json format, > please send us these reports. > > I can see where certain 3rd party report handlers would only need XML > and they generate readable reports for their DMARC customers. But we > can't assume all publishers will be using a 3rd party report handler. > > So its about being ready for the future and DMARC not be obsolete > fixed with XML only. In my opinion, JSON is the direction most systems > are heading too. > > > Have you implemented the XML format already and you're willing to code up > > the alternatives too? > I can support any format. Easily done with reporting/output templates > for CSV, JSON or XML -- single sourced output generator. > > This benefits customers, consumers, publishers who will have tools > already, today, that imports certain common formats already, and > generally, it would begin with a CSV format. Just consider, all > spreadsheets apps, Microsoft, Google, etc, all support CSV today, but > not JSON or XML. Most or not all, SQL packages, support CSV and > probably XML and maybe JSON. Let me double check with Google Docs > ...... no. It supports > > csv, txt, tab, htm, html, xls, xlsx, xlsm, xlt, xltm, xltx, ods > > I don't know if the list will strip attachments, but this link shows > an image of the Google Docs popup I got: > > https://secure.winserver.com/public/files/google-json-no-support.png > > So, from a product design standpoint, for immediate consumer "pay > off," at the very least, csv should be the default option, not XML. You're several years too late on deciding a default. If I understand your proposal correctly, everyone would still need to implement XML ("At a minimum, XML is what publisher (or report handler) will get"). If there's no avoiding implementing XML (which is what I thought the original point was), why would this need to be defined now? It seems like it could easily be added later if there was a significant demand signal. Scott K From nobody Wed May 20 08:30:15 2020 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 894BE3A09BC for ; Wed, 20 May 2020 08:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzoBjtUk1mvo for ; Wed, 20 May 2020 08:30:09 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 B814B3A0938 for ; Wed, 20 May 2020 08:30:09 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id y17so1308441ilg.0 for ; Wed, 20 May 2020 08:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KB0c2RnDKoD565cL68cJQ6YkMKge7a0nEbXJuRzlhyg=; b=PbewSLqEpDIIjIBnHWWgVXVLjoJqq4JTy0EpUQpNzM7Hy2OkXWSq+uuhJ2WWzvf126 HxO9WTtyNHXZ2PUJ7qKHIuk+L5dTMBYf9a+1IT1UnipzLLcfrECbyKBFYRP7waK9MMG2 SKWkmpMkl/7QkqOYAqh8DlJPVx2T4zX1ehV5s= 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=KB0c2RnDKoD565cL68cJQ6YkMKge7a0nEbXJuRzlhyg=; b=km3c6oX9pxFQJzTMFwhWM/1orRuj3djCq5EphsD4pdOf5fNL/nFwPaln985LRzrDOK uCykgX1B0lOB2Kxw/OQUGrKnrFGlHMV+kC3rgVO75ganmxf0LksJD5G3D4dEIkyzX9iO tgZ3ZfYqf5LQXaB69YbaRxN7B/S/tQUbPmw9nI/e6mxuSIn1/0eR0BVnpLRBr1NRC0HQ kP+b6RTFdVlp6ohERUz8Gro5tDuuqvS+2jnVm4/4K6XyCoM2XHQ/S8mPM10mE8Hy5mBB bT4v8nU7kOdAYL07RY8o5bMW0RukFfF16XG6LhwaR/ysXOSKEJI2pYXXiLaOALDrvsiA d2cw== X-Gm-Message-State: AOAM531CY5jf/EnEw/dmxcHywYyW1RSmdyz4qDi4xOZsIplCSW31dMRF D2y/ZNnOwykv64Jvr7D2uzvLiitxKhiY+zknVxsrlpjp X-Google-Smtp-Source: ABdhPJygZsoUrlhj071BInl6a19St0M8Y9MU7AZMGsfqMdIKYgGDLB6P9fKF6BAdG5YYcrczcmZ/sbO4N1lFMb6qBZ4= X-Received: by 2002:a92:2a09:: with SMTP id r9mr4458526ile.103.1589988608709; Wed, 20 May 2020 08:30:08 -0700 (PDT) MIME-Version: 1.0 References: <20200516011352.DBF1A195F5FA@ary.qy> In-Reply-To: <20200516011352.DBF1A195F5FA@ary.qy> From: "Kurt Andersen (b)" Date: Wed, 20 May 2020 08:29:56 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="00000000000038330505a616121f" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 15:30:13 -0000 --00000000000038330505a616121f Content-Type: text/plain; charset="UTF-8" On Fri, May 15, 2020 at 6:14 PM John Levine wrote: > In article ZmN0oxMGNS0cSpYWu58hqLAW7wvvbh1442yU4E5Dg@mail.gmail.com> you write: > >-=-=-=-=-=- > >Should we consider adding JSON formatting to DMARC? > > What Scott said, no. Report processors will always have to be able to > decode the existing XML so adding more options just adds more > complexity with no more function. > Agree 100% --Kurt --00000000000038330505a616121f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2020 at 6:14 PM John Levi= ne <johnl@taugh.com> wrote:
In article <CAOZAAfPY=3DZmN0oxMGNS0cSpYWu5= 8hqLAW7wvvbh1442yU4E5Dg@mail.gmail.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>Should we consider adding JSON formatting to DMARC?

What Scott said, no. Report processors will always have to be able to
decode the existing XML so adding more options just adds more
complexity with no more function.

Agree= 100%

--Kurt=C2=A0
--00000000000038330505a616121f-- From nobody Wed May 20 08:49:33 2020 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 3EC723A0A84 for ; Wed, 20 May 2020 08:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 J84AibAlIHYi for ; Wed, 20 May 2020 08:49:31 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 0D8173A0A6E for ; Wed, 20 May 2020 08:49:31 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id z26so816530oog.8 for ; Wed, 20 May 2020 08:49:31 -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-transfer-encoding:content-language; bh=KxNyBGUyAh1ZGf+YA3xoDecqqTAR4LDQ+oPcaFzsNJg=; b=YgkxfvcvcIUPGoVFw1hsk6TIS3w+nv7UlDieE2IBh5NltIlFJbfZWoIO0rZPmG15bi zj/Cf66QNCtkCIVO8m9mcl1ZqdhYe8Ad1J1s8CyNkMrw3QdGSsX/igCFwOlGMyW0zeXG OjeFpSWKg/UazAiY3Bts0rMqE9sTcXNiYPU2WY2uhEDh7vKm876rHoJS3XtQwe9fFqtS WgAan8w/rmeswUWX+DJUJiXCiyRoHLE/NuJDFlKV9NLHMD7kqcLx/vc9WU3D4qCF1z4t vx4tCS5woUyHwL9b17ajM/SdWD3ZY8kXzXk+1Jmrl8vlBSt0HqfRXGcQRvzLr93JLnKh 9Edg== 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-transfer-encoding :content-language; bh=KxNyBGUyAh1ZGf+YA3xoDecqqTAR4LDQ+oPcaFzsNJg=; b=cf1oElFjyEoTMtoraYkP0q3mb8HT01MeawoWRLivw0g6/s9PqGG+MyYpeIruVKrqCc Q0BNzMBcEn0HO7w2PUydwCSzPk4t2s0DlaTTDQ44M94YZhcrZUwAwN5hgccr8kh6GBwp SJL6gasglprX1Msnvm4d23mFQD/IIeagQ9PtI9dLaSJJoxrMzG8+us7EA+NwQukCN+/L EEYH5TdFLMqBRoKw5A09k4UxC+T8EsjM+PpLR4BxbOsACXxhvMiQKr09UOEkW86rcYS0 afKR6TKM5ndmiE+EGkYUEqlurZVwqDffroXNzOiFKGWY+Fvo5bfsyUkRLanCkF36JwiO fOpw== X-Gm-Message-State: AOAM530PNrJ3YyOXB4XwtgoSaioukBAzSa6+hzcmT0mZ8b4YG31t2odO 40F6ZAj52Q+AQmp9qyW6vkBZQm120Ms= X-Google-Smtp-Source: ABdhPJxFgw76rPFxeQGO5wZztn1F8ix10ceoN4g91HgYW/u9HasZSLbrvmY0GfDc2+elIeDIF5Iyvg== X-Received: by 2002:a4a:e836:: with SMTP id d22mr3845199ood.54.1589989769799; Wed, 20 May 2020 08:49:29 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:d526:c9d7:bfc:db1f? ([2600:1700:a3a0:4c80:d526:c9d7:bfc:db1f]) by smtp.gmail.com with ESMTPSA id v9sm866130oop.8.2020.05.20.08.49.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 08:49:29 -0700 (PDT) To: "dmarc@ietf.org" References: <20200516011352.DBF1A195F5FA@ary.qy> From: Dave Crocker Message-ID: Date: Wed, 20 May 2020 08:49:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 15:49:32 -0000 On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: > Agree 100% This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit.  Yes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 20 08:56:51 2020 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 202203A0B10 for ; Wed, 20 May 2020 08:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=T5T4PIx+; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=IN15yG70 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 rZ8VMsq7uizf for ; Wed, 20 May 2020 08:56:48 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 37FEC3A0B0F for ; Wed, 20 May 2020 08:56:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1928; t=1589990117; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=hZlBSmRr2kmhtjDbygH6Hl4jJYw=; b=T5T4PIx+2ND/Sg1aRmDOfHiKxQQKCw+hYK6I4eBvQdzWDEDvmPCKyJ4Bqbx/P1 y8z9/AMu3iemydslQsZlEm+Vhpx1ZN7IHHyf6HZ5Vn1KSR/TMFJDY4VZGtSoK7Y4 TkPSIZEDJUIkW7E6+TboOqu0PfTcTc+V+OOoqDjw3aSnc= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 11:55:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 717445225.1.4352; Wed, 20 May 2020 11:55:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1928; t=1589989738; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=S4wZTI8 H2MtmViaiTm/lEPx1lkWsb7lmHdV/imXrSHQ=; b=IN15yG70962ETK+hQ6WJiq0 sOBRN8PM7GSLElIPoNgvKM+ETsWE1zarsMdxRtU6ufxt2NSNz000bucN1IwRvJpl as7elWL2lYCDhIC9XO3h5V+mlo83MlYlb2GtMEwhXuLubO3n9XIRZlD8frC8wOfZ PBa8K5ycXDKNMfH3NLsU= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 11:48:58 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1723811968.3.18212; Wed, 20 May 2020 11:48:57 -0400 Message-ID: <5EC552E7.9060907@isdg.net> Date: Wed, 20 May 2020 11:55:19 -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: <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5114096.80zr39ycxx@localhost> In-Reply-To: <5114096.80zr39ycxx@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 15:56:50 -0000 On 5/20/2020 10:01 AM, Scott Kitterman wrote: >> So, from a product design standpoint, for immediate consumer "pay >> off," at the very least, csv should be the default option, not XML. > > You're several years too late on deciding a default. DMARC is informational, not a proposed standard. My confused understanding of the RFC7489 informational status DMARC draft, it has removed the IANA registered "rf=" report format tag, continues to describe the afrf and iodef format. But the XML schema is described as the report format? Sound there is a lot of clean up to do. We haven't even discussed 3rd party policy support. DMARC PS can not ignore it. The rewrite kludge is not a preferred and acceptable concept. > If I understand your proposal correctly, everyone would still need to > implement XML ("At a minimum, XML is what publisher (or report handler) will > get"). If there's no avoiding implementing XML (which is what I thought the > original point was), why would this need to be defined now? It seems like it > could easily be added later if there was a significant demand signal. But XML was added unofficially? As I pointed out, Google doesn't even mention the "rf=" tag and just described reports are in XML format. If that is the decision for the initial DMARC proposed standard, I am fine with the XML default, but it would be simple to add an optional "prf=" tag with additional report format IANA registered well known acronyms namely csv, json. XML will be registered for the PS so I am suggesting to also register csv and json with optional implementation semantics. This may give verifiers (new or PS updated), preparedness to recognize the "prf=" tag for future support. You are correct. The "prf=" can alway be added but the format tags won't be registered. Another RFC to cover the registration. Thanks Scoot, I hope all is safe for you and family. -- HLS From nobody Wed May 20 09:00:20 2020 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 9EDA13A0B5A for ; Wed, 20 May 2020 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=junc.eu 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 2tTN1MzF4SZ7 for ; Wed, 20 May 2020 09:00:18 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 9BD093A0B53 for ; Wed, 20 May 2020 09:00:18 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id AC92480170 for ; Wed, 20 May 2020 16:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=635; q=dns/txt; s=default; t=1589990419; h=from : subject : date : to; bh=xbRp+gj0RKURABEqK6GpdiGG5jShlB2vJZ0nWQ1ngAE=; b=hKShE6mOssZJabdJAWK2DE8fQb8GkqCLDbeqQaOm63VPlpLlpaFDlWV1yNtnpnp1qMWPw Kvg7lqLH+G2TstPD7NB7x+JrETw9PBp0Jo9Wol0NnV72jfsI4T7JjjAfgqAyyObc32VskEg LMQ65Cr2XRIHmI/K3qOwcSDM1RNTXYY= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 959717FE81 for ; Wed, 20 May 2020 16:00:19 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2020 18:00:19 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <20200516011352.DBF1A195F5FA@ary.qy> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <6b4fac8fde840c9737c84bc0375f97d4@junc.eu> X-Sender: me@junc.eu Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 16:00:20 -0000 On 2020-05-20 17:49, Dave Crocker wrote: > This looks like it has a strong constituency against the proposal, a > much smaller constituency in favor of it, and little or no offered > benefit.=C2=A0 Yes? if the mouse have 2 holes to select from, it will be 50% fails in 50%=20 reports, this is why postfix keep old dokumented bugs :) bla i am just funny here, it can be solved, but main part is that=20 software need to be updated then, and not all precompiled problems do=20 this same reason i dropped sid-milter, opendkim, openarc, opendmarc, to=20 unmatined and still have unclear bugs not solved, no thanks to it From nobody Wed May 20 09:15:41 2020 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 17C073A0BFB for ; Wed, 20 May 2020 09:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=icW6EGfW; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=xv0sTn90 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 Yc1zQL6Ti20w for ; Wed, 20 May 2020 09:15:38 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) (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 E948E3A0BFA for ; Wed, 20 May 2020 09:15:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1828; t=1589991333; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ke6XUOf8eG4lEU2pXEwdGHDWDpo=; b=icW6EGfWWAD0mIH51YlTKXMk4Z/dAR1CQtTSYDO9HhwfRqacBD+7/oE4T2id+R 3CwGves8LbI6taddDUDNyZG1kFvzaT10iQ036+vl/yfMpfT3hHvy39pdbhecoD3c B6I3xhVcVs4dgQrTj2lNGv31Abd0K0lAvNhY/77oAraic= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:15:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 718660629.1.7520; Wed, 20 May 2020 12:15:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1828; t=1589990949; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xO1deYE EUuwmEGeGTWUNrrjkBJxJUuCf99+kNnsGvO8=; b=xv0sTn90LkpqtQ95JNPK6Kf gwukElXBc9McuM0jtdso/pUIl8DvfcXuSGLE9Am4M3kXuiKLt8jhPe19u1QMvLis gB0WExbxQYzRSBYz2RHj7nWJfb+V28X51jQ2Licp9RTxKF0XuQxkkN993uVF0Fn5 GN3wwr8e3p+pzq9rmMNM= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:09:09 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1725023656.3.18372; Wed, 20 May 2020 12:09:08 -0400 Message-ID: <5EC557A2.3060409@isdg.net> Date: Wed, 20 May 2020 12:15:30 -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: <20200516011352.DBF1A195F5FA@ary.qy> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 16:15:40 -0000 On 5/20/2020 11:49 AM, Dave Crocker wrote: > On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote: >> Agree 100% > > > This looks like it has a strong constituency against the proposal, a > much smaller constituency in favor of it, and little or no offered > benefit. Yes? Just like DKIM Policy had a "strong constituency" against DKIM Policy, yet, the wrong decision was made to abandon DKIM Policy, only to find out today (the last few years), it was the wrong decision. Just look at the support we have today for DKIM policy. Whatever. In regards to the report format, I am proposing an easy non-complicated compromise. Consumer will instantly benefit by offering additional registered report formats such as: csv json xml as the fall back. The key is the register the tags, not mandate that verifiers need to support csv or json. I am proposing an new tag "prf=" to be recognized by standard DMARC verifiers but optional implementation of the registered tags csv and json. XML will be registered and required reporting format IFF reporting is offered by the verifier. Reporting is not a requirement. Keep in mind DMARC specs need a major cleanup in this regard and many others. It mentions XML, but the "rf=" no longer defined. It says the tag is registered, but no description describing its possible values. We need to stop this lock down methods and expand the desperately needed fix up for DMARC policy tags. We have discussed these issues but the "smaller" entities in this group are getting absolutely pushed out with no recognition. In the end, we get the usual, the "Follow the Chieftain" syndrome and other folks, who may agree, stay quiet or just agree with "chief" +1 -- no rocking of the proverbial boat. Rough Consensus is good, but is not always correct. -- HLS From nobody Wed May 20 09:20:01 2020 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 8B9BC3A0BC9 for ; Wed, 20 May 2020 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=AZlcoyuZ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=V8TG+ATa 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 sOYgFwdjJ8c2 for ; Wed, 20 May 2020 09:19:58 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (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 C3CE83A0B6E for ; Wed, 20 May 2020 09:19:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=108; t=1589991592; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=t7D2g+JLl9Y0gFjp57QslwqsXsE=; b=AZlcoyuZhNYp2MgHKdA/VXUoLN1XFv6iMAo/Wr8/HgWBMhMhhWgxjP+VE/G6BQ /GUbbbUHiuHlamyTKomCGI9DUbjJCVrD8zWYmhCqJh/OFBZKoMqeQChZEybSnz4n V+PuQ9if7hNtttYl2EilEVI1FzMQXe4RK3QoGm8ryb16E= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:19:52 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 718920339.1.5416; Wed, 20 May 2020 12:19:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=108; t=1589991210; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iUB8MrJ QEoy+pHEKD8s2GO0Lmtq0n/pyxFDiOJ6alSA=; b=V8TG+ATaUBCn2E6/kwOGEHQ me2FIG6SjUUByESu6CIRQaH7HXPzQEHV/XaA/3uhWLvFHe1xRFmhGG9am0lD93BF 7RGc/2k0Ms1U/9qgFSIpVJ6+1oreUaJmCS17XP38YdDWF1WimYoXH+DYAmkfIVNN cjwFl7mcpImvPQp9jQfI= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:13:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1725284875.3.18092; Wed, 20 May 2020 12:13:30 -0400 Message-ID: <5EC558A8.8030005@isdg.net> Date: Wed, 20 May 2020 12:19:52 -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, Scott Kitterman References: <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5114096.80zr39ycxx@localhost> <5EC552E7.9060907@isdg.net> In-Reply-To: <5EC552E7.9060907@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 16:20:00 -0000 > Thanks Scoot, I hope all is safe for you and family. argggggggggg sorry about that, Scott. -- HLS From nobody Wed May 20 09:26:42 2020 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 DA91B3A0988 for ; Wed, 20 May 2020 09:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7jNeFte5VYny for ; Wed, 20 May 2020 09:26:39 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 6841B3A0978 for ; Wed, 20 May 2020 09:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1589991997; bh=z5YpJBDYS3qxp90E0k6XuGe50rd31H42Qo3EXRV3SaQ=; l=2449; h=To:References:From:Date:In-Reply-To; b=Cdbdjzb54rCbQKdAIe4SfuU+HrauUhmdjj++aGF91+DZ1W57JFdJI9AMK8urLHBoE yEtL3JZGjMRAdTXMc+JajSoXXQa2JnqMizaHYRPPvTmjWX3anb7rV7uBaQrZDOXODP GNn/TyDEx7GMw3aVFiggtxRR5mb6bdltUA+CdPWK83Cda6OKHayi1ZjDWsBm5 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B7.000000005EC55A3D.00006939; Wed, 20 May 2020 18:26:37 +0200 To: dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> From: Alessandro Vesely Message-ID: Date: Wed, 20 May 2020 18:26:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EC52749.20801@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 16:26:41 -0000 On Wed 20/May/2020 14:49:13 +0200 Hector Santos wrote: > On 5/19/2020 8:46 PM, Scott Kitterman wrote: >> >> Please don't.  This is a large stack of protocol and implementation >> complexity for little or no gain. >> > > Rhetorically, I feel the same about reporting.  What is gained from it?  But > that is just my opinion since the proposed ideas for reporting came and it was > mostly rejected with SSP. It's redundant overhead.  If reporting is going to be > optional feature to possibly implement, it might as well be useful for > consumers and that is where the gain will be. Other people here consider reporting the (only) useful innovation of DMARC. I agree we should consider ways to increase the report generators base, but requiring support for multiple formats goes in exactly the opposite direction. Although automatic converters exist, having to provide multiple formats can be a showstopper. > The proposal is more to IANA register the formats (the common ones mostly used > in practice) and not to mandate implementers use them all.  XML would be the > fall back. At a minimum, XML is what publisher (or report handler) will get > despite the publisher stating a preferred reporting format, like: > > prf=csv, json, xml. > > That's asking the verifier, if you can handle a csv or json format, please send > us these reports. Hector, what are you talking about? > I can support any format. Easily done with reporting/output templates for CSV, > JSON or XML -- single sourced output generator. Can you show us how does a CSV report look like? Let me recall that DMARC reports consist of a header part and a series of record with a varying number of columns. XML, like JSON, support complex template schemata. CSV templates require fixed columns. I doubt you're talking seriously if you make such claims. DMARC reports are supposed to be machine-readable. To define multiple formats, we'd need to supply schemata for each. We'll likely have to update the schema version for PS DMARC. Given that automatic translation /of schemata/ is going to lack for some more years, how would we manage equivalence proofs of all those formats? > So, from a product design standpoint, for immediate consumer "pay off," at the > very least, csv should be the default option, not XML. Yes, and I am Catherine Deneuve... Can we get back to work, please? Best Ale -- From nobody Wed May 20 09:51:48 2020 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 4A67B3A0BB9 for ; Wed, 20 May 2020 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=FMmmdgYp; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gYUer0C3 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 37RMaTVqTapA for ; Wed, 20 May 2020 09:51:41 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) (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 5E0B33A0C0B for ; Wed, 20 May 2020 09:51:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2027; t=1589993492; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vgQqISEQYujmiYjvhTPS/+WriMI=; b=FMmmdgYp5meSeGMQAn/Z76EnG57+mdBG7gaphiQR4GkJ+2esl63KytrzdwVEM8 CERqQxwuGgKc4ltU5k2jymlxriHRq2P/SpOCrLr+t/yESrs9JAUeh0qcGy2nNIy0 ZAOVzDXyXjJYy7mh3ruFwRgC1+x9j0j5+fp7yn+Qub8r0= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:51:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 720820712.1.6976; Wed, 20 May 2020 12:51:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2027; t=1589993111; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vTFQBUc TDC+F2a7CubF7SWHxmNj0GhAx1nPPM9E3eV8=; b=gYUer0C3s0NUJo8ROARc/WZ Kx7T9Hy8EZDAH/qyrJ6+Fga+4Ca3ZAzaOrrosUEWHLCt8/jSfWDER2f4FK/wml4c eWcob99hv+ZCXmvFaBBpAZSgK7cPoLGf2kKUaqMtIcW1Dl2jyx881n3rrRs0J6n5 WYCQs5B/JNPXFRzp1V7c= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 12:45:11 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1727185578.3.10452; Wed, 20 May 2020 12:45:10 -0400 Message-ID: <5EC56014.70506@isdg.net> Date: Wed, 20 May 2020 12:51:32 -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: Alessandro Vesely , dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 16:51:46 -0000 On 5/20/2020 12:26 PM, Alessandro Vesely wrote: > > I agree we should consider ways to increase the report generators base, but > requiring support for multiple formats goes in exactly the opposite direction. > Although automatic converters exist, having to provide multiple formats can be > a showstopper. I don't agree this would be show-stopper. Not after all the work that has to be done to move from Draft Informational status RFC to DMARC proposed standard RFC. Its not complicated at all. The proposal is to offer a new optional "prf=" tag that provides a preferred reporting format where the verifier MAY implement (NOT MUST) and provide to consumers. I would say SHOULD but MAY is fine. > Hector, what are you talking about? hhmmm, I don't known any other way of describing this simple concept. > Can you show us how does a CSV report look like? Like a standard format for CSV: line #1, name of fields, separated by a comma line #2, transaction #1 values separated by comma . . . Line #N, transaction #N-1 values separated by comma A standard csv layout. Most if not all table like "tools" like a spreadsheet or SQL, support a CSV import, maybe a XML import and if you are lucky, the JSON format. But XML is older than JSON so you may see CSV and XML with older tools. But relatively soon, JSON will be the more common comm I/O technique. > XML, like JSON, support complex template schemata. CSV templates require fixed > columns. I doubt you're talking seriously if you make such claims. It is possible to have XML and JSON represented in a table-like flat name space with multiple columns. > > Yes, and I am Catherine Deneuve... > Who? > ... Can we get back to work, please? Sorry, but I consider a rude, disrespectful and ignorant statement, to be saying that. We are working. If you don't agree or lack the ability to support anything XML but others can, you should note it and but also not push your limitations on others. -- HLS From nobody Wed May 20 11:43:41 2020 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 561C33A0FAD for ; Wed, 20 May 2020 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vG10WviEIP_o for ; Wed, 20 May 2020 11:43:38 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 5EE823A0FA7 for ; Wed, 20 May 2020 11:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1590000216; bh=4JJOV1SQjwT+5ZaJNlTvurmabUdFmRtFVQMPyCBoCJw=; l=5774; h=To:References:From:Date:In-Reply-To; b=AF8IxuOfGka8hZORzkiEK+k7TxIwd8+s0N/mdoMcPVS8VGoCy87/EMJ5juLEZsF2O jqC9M1BnLOkamW9rBoVloUPtpwswLdbkvskJR3OGBMnH599zyygIw/1J/Cmd9fVTul h9GSbOr8H1ev7l2tD61lG0O3uTVXMKBLsMv3Yq2LkZzSeXVU9KMk2DxDpf/DO 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005EC57A58.00007A3B; Wed, 20 May 2020 20:43:36 +0200 To: hsantos@isdg.net, dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> From: Alessandro Vesely Message-ID: <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> Date: Wed, 20 May 2020 20:43:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EC56014.70506@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 18:43:40 -0000 On Wed 20/May/2020 18:51:32 +0200 Hector Santos wrote: > On 5/20/2020 12:26 PM, Alessandro Vesely wrote: >> >> Hector, what are you talking about? > > hhmmm, I don't known any other way of describing this simple concept. > >> Can you show us how does a CSV report look like? > > Like a standard format for CSV: > > line #1, name of fields, separated by a comma > line #2, transaction #1 values separated by comma > .. > .. > .. > Line #N, transaction #N-1 values separated by comma Transaction? I thought we were talking about aggregate reports. There are no transactions there. I mean, what is the CSV format of the following report, that I sent yesterday for this list: tana.it postmaster@noloop.tana.it eb74db90c32d432ea1652a0eb656fe5a 1589846400 1589932800 dmarc.ietf.org r r

none

 4.31.198.44 1 none pass pass dmarc.ietf.org ietf.org ietf1 pass ietf.org ietf1 fail akamai.com jan2016.eng fail ietf.org pass mfrom 4.31.198.44 1 none pass pass dmarc.ietf.org ietf.org ietf1 pass ietf.org ietf1 fail cisco.com iport fail ietf.org pass mfrom 4.31.198.44 2 none pass pass dmarc.ietf.org ietf.org ietf1 pass ietf.org ietf1 fail junc.eu default fail ietf.org pass mfrom 4.31.198.44 1 none pass pass dmarc.ietf.org ietf.org ietf1 pass ietf.org ietf1 fail valimail.com google2048 fail ietf.org pass mfrom > A standard csv layout. Most if not all table like "tools" like a spreadsheet or > SQL, support a CSV import, maybe a XML import and if you are lucky, the JSON > format. But XML is older than JSON so you may see CSV and XML with older tools. > But relatively soon, JSON will be the more common comm I/O technique. > >> XML, like JSON, support complex template schemata.  CSV templates require fixed >> columns.  I doubt you're talking seriously if you make such claims. > > It is possible to have XML and JSON represented in a table-like flat name space > with multiple columns. > >> >> Yes, and I am Catherine Deneuve... >> > > Who? > >> ...  Can we get back to work, please? > > Sorry, but I consider a rude, disrespectful and ignorant statement, to be > saying that. No personal attack intended. I'm being rude because I have the impression that you are not defending a concrete, well defined need, but instead find new arguments opportunistically to pursue a vague sense of format fashion. You shifted from an asserted necessity of producers to a possible desire of consumers. Now you introduce formats like CSV which make no sense in DMARC context. Is that work? > We are working. If you don't agree or lack the ability to support anything [but > XML] others can, you should note it and but also not push your limitations on > others. I don't think that the inability to support CSV is a limitation of mine. I hold that CSV cannot satisfy DMARC requirements. Please do contradict me by showing us how an aggregate report in CSV would look like, as well as some ideas for defining the corresponding template, similar to what Appendix C of RFC 7489 specifies for XML. Best Ale -- From nobody Wed May 20 13:00:49 2020 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 DE4CE3A08ED for ; Wed, 20 May 2020 13:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=isdg.net header.b=RyfV5Hu/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=hS7bziKr 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 6nouHyJoAJmY for ; Wed, 20 May 2020 13:00:44 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (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 8C4BF3A08E5 for ; Wed, 20 May 2020 13:00:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2494; t=1590004833; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=55cY5LMUhEB5yb32A6UE5xZrvfU=; b=RyfV5Hu/ZNzLRUWLHZqPUXEqft/KPf3NdFk5sJbfezvf1sClp+YG3+eatyRyfx UBnFRozodyagmyo1MmmwCxL/G+4Yb4/toEwMnc0nYWHiZ+0HNf9I65O8D/3aBq8z JDa4v2BpVw0v1BiRABvNl/3wLwA0CuZvXGgwsRzE9OgaU= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 16:00:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 732160877.1.7952; Wed, 20 May 2020 16:00:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2494; t=1590004453; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eTseoXi rnGvJURsW4tGmZwnRI1qGygxLdo4FuFDG3L0=; b=hS7bziKrOmn95mR/0KT4oAL bdpzhuS9GogOxutu2IuEmZ46qA+/QSx4vuh6RVoRuyMZUwC9YgwQZaye7KU3kOrq 9kbyh5Vr1kvKIsopPfrrtVtVfNZmZ+qcJuwIA+JREQgYbZuzIoWf8y0TZiE4dCG7 vJ2WM3eyz2CGaK6dSwCs= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 20 May 2020 15:54:13 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 1738527000.3.17876; Wed, 20 May 2020 15:54:12 -0400 Message-ID: <5EC58C62.8090703@isdg.net> Date: Wed, 20 May 2020 16:00:34 -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: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> In-Reply-To: <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 20:00:47 -0000 On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > Transaction? I thought we were talking about aggregate reports. So am I. > There are no transactions there. Really? Each SMTP session can be considered a transaction. You are provided results on the these DMARC processed transaction. > I mean, what is the CSV format of the following report, that I sent yesterday > for this list: Sorry, if I ignored it. Forgetting fact that you can your report easier to read for consumers, these would be an example of the CSV field headers. CSV headers: report_metadata.org_name, report_metadata.email, report_metadata.report_id, report_metadata.date_range.begin, report_metadata.date_range.end Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, Policy_Published.p record.row, record.row.source_ip.record.count. record.row.policy_evaluated, record.row.policy_evaluated.disposition, record.row,policy_evaluated.disposition, record.row.policy_evaluated.dkim, record.row.policy_evaluated.spf Note: You don't have to stick to redundant "name space" field names. >>> ... Can we get back to work, please? >> >> Sorry, but I consider a rude, disrespectful and ignorant statement, to be >> saying that. > > > No personal attack intended. I'm being rude because I have the impression that > you are not defending a concrete, well defined need, but instead find new > arguments opportunistically to pursue a vague sense of format fashion. That's a personal attack. If you don't understand the proposal, you should back off or ask for clarification. > You > shifted from an asserted necessity of producers to a possible desire of > consumers. I did no such thing. I won't repeat it, but it appears you didn't understand the proposal. >Now you introduce formats like CSV which make no sense in DMARC > context. I disagree. See above. > I hold that CSV cannot satisfy DMARC requirements. Hold it all you want. You know it would not be true. See above. ? Please do contradict me by > showing us how an aggregate report in CSV would look like, as well as some > ideas for defining the corresponding template, similar to what Appendix C of > RFC 7489 specifies for XML. Ok, I won't but if you don't understand the proposal, you should ask for clarification. CSV can work, so can JSON. Limiting it and locking it down to XML only would be a limitation. You can agree or not agree with that. -- HLS From nobody Wed May 20 13:05:52 2020 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 CC8043A0A4A for ; Wed, 20 May 2020 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, 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=0nSoQ5Wj; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CCY3r6sh 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 SaHWD117ZFnq for ; Wed, 20 May 2020 13:05:48 -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 DB3213A0A1B for ; Wed, 20 May 2020 13:05:48 -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 790C3F8027B; Wed, 20 May 2020 16:05:47 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1590005147; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=DqJqiscIc3ijchI6agsiI58ua9UMLJEiheG1NqGF8+A=; b=0nSoQ5WjA8Ut4l9m08lvtfFt0fJIIxrOh0ZJ8Wc0JvM6J/DNRBo2tZkYceGz5p2eNuyYb +64FEY/BdHYO3W6BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1590005147; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=DqJqiscIc3ijchI6agsiI58ua9UMLJEiheG1NqGF8+A=; b=CCY3r6shQeO0Edin35ljanH0s8at94l6WjghfgTCjJvXoqp5IcZnd+KZSvB+ELsBK5cQ2 ejJHZTNePD4z3xEfy2AHWbZXV+h58j7KjafY7BFZeh/OqRWc61vxG5EFztMm59lqw89/dT2 BNEduu+n/MtfRby7DPONDZqT4Cv8OMgau8X1i4uKApY6qc9IN3k3CKjv8VUhBARwoJ3I7aC vIW7zbKgXOl75gKOuYDtFLTKdXDtk75F8xrewkS4BDO+9E6ggCJuv8ZXrB0Pp+5aHbazoLX AJi+AK+LuOqXe3V/eEzMg09lO0c0aiJw5e1VMnpzcpVLkcOeppQzoBaU1A1w== 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 41C1AF8009D; Wed, 20 May 2020 16:05:47 -0400 (EDT) Date: Wed, 20 May 2020 20:05:44 +0000 In-Reply-To: <5EC58C62.8090703@isdg.net> References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> <5EC58C62.8090703@isdg.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: <7F78C2BA-648F-4051-822A-177DC2E7BD6B@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 20:05:51 -0000 On May 20, 2020 8:00:34 PM UTC, Hector Santos wrote: > >On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > >> Transaction? I thought we were talking about aggregate reports=2E > >So am I=2E > >> There are no transactions there=2E > >Really? > >Each SMTP session can be considered a transaction=2E You are provided >results on the these DMARC processed transaction=2E > >> I mean, what is the CSV format of the following report, that I sent >yesterday >> for this list: > >Sorry, if I ignored it=2E > >Forgetting fact that you can your report easier to read for consumers,=20 >these would be an example of the CSV field headers=2E > >CSV headers: > >report_metadata=2Eorg_name, report_metadata=2Eemail,=20 >report_metadata=2Ereport_id, report_metadata=2Edate_range=2Ebegin,=20 >report_metadata=2Edate_range=2Eend > >Policy_Published=2Edomain, Policy_Published=2Eadkim,=20 >Policy_Published=2Easpf, Policy_Published=2Ep > >record=2Erow, record=2Erow=2Esource_ip=2Erecord=2Ecount=2E=20 >record=2Erow=2Epolicy_evaluated, record=2Erow=2Epolicy_evaluated=2Edispos= ition,=20 >record=2Erow,policy_evaluated=2Edisposition,=20 >record=2Erow=2Epolicy_evaluated=2Edkim, record=2Erow=2Epolicy_evaluated= =2Espf > >Note: You don't have to stick to redundant "name space" field names=2E > >>>> =2E=2E=2E Can we get back to work, please? >>> >>> Sorry, but I consider a rude, disrespectful and ignorant statement, >to be >>> saying that=2E >> >> >> No personal attack intended=2E I'm being rude because I have the >impression that >> you are not defending a concrete, well defined need, but instead find >new >> arguments opportunistically to pursue a vague sense of format >fashion=2E > >That's a personal attack=2E If you don't understand the proposal, you=20 >should back off or ask for clarification=2E > >> You >> shifted from an asserted necessity of producers to a possible desire >of >> consumers=2E > >I did no such thing=2E I won't repeat it, but it appears you didn't=20 >understand the proposal=2E > >>Now you introduce formats like CSV which make no sense in DMARC >> context=2E > >I disagree=2E See above=2E > >> I hold that CSV cannot satisfy DMARC requirements=2E > >Hold it all you want=2E You know it would not be true=2E See above=2E > >? Please do contradict me by >> showing us how an aggregate report in CSV would look like, as well as >some >> ideas for defining the corresponding template, similar to what >Appendix C of >> RFC 7489 specifies for XML=2E > >Ok, I won't but if you don't understand the proposal, you should ask=20 >for clarification=2E > >CSV can work, so can JSON=2E Limiting it and locking it down to XML=20 >only would be a limitation=2E You can agree or not agree with that=2E Not requiring RFC 1149 support is also a limitation, but I'm fine with tha= t=2E Scott K From nobody Wed May 20 14:31:55 2020 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 4AA073A00D3 for ; Wed, 20 May 2020 14:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f3J8RjhyBQp for ; Wed, 20 May 2020 14:31:52 -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 D91A43A00D2 for ; Wed, 20 May 2020 14:31:51 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id g14so907228wme.1 for ; Wed, 20 May 2020 14:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=p7T+uHdTehs//ksvUi3IBAS3z7v70CFFZVSbuYjGIGw=; b=LLlFemxF/SWE32maM/FIj+rS8mqmBv9/Davy8vW/rTP9ULB81fSjADerMeFfhsKrgJ d1vTPMZYKU4a3Eens7UnbVTzg+UU7TNMlZCjuaHMbCKDDTbxt3y2XBLbQGr6oZ0d+M+3 49YdeWOjTghKiXLtwjUtM6fbLg6ntF7uqgYkZcnq9dOI2FKAoPT0eyQgN270IgY/Bcqz nMfLNbe64a6RwaDq+j6Wm1zLj4AATzWWqArjo6T9Q/VK1QnIZMHNYEbvdf5gKkVwUkwd GDowOkwFnCfKiVuzfEMOrW9Hl2otaX91xpKOuqRJhLaCNlPK+8EkLE4v+FRZOPwOJ7Q0 qKrA== 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=p7T+uHdTehs//ksvUi3IBAS3z7v70CFFZVSbuYjGIGw=; b=R49scLpaK8/h2hPuD3te27LVlzwt4M78uW/7HiOBOaBcaCR/o6abHForY5QAEdijUF z9L4wqycWLEi34Q66yS0cW/vh6b2aVd1QJLouuhRA+Ab//7k3PdRl3tSEScAyK/kIkZ+ M4ECzZTgksu3Dejl56Hc0y084Ra9EHyukmKYblwgCcwWwoAYQ0TxHLwIr/tzYp1/RH1P VPs/xDBkrDc5p72tb3SkREDTBHWt3CcZDQQFHt/a8UZtx8NIjeI0WQsHYLAIT0md5A1L xMyT5eoSeHkGAcABzOCbltj+bI6tNt5nhnjgQgNlhf+NUFCaJffCzidO1Qd4i4VxKH6o ilDA== X-Gm-Message-State: AOAM530Uxuxka/NlMhSo1pkViOQ0FzIGPkvMz/UBb8Y66/F+rNSFfgVF jiztyz/jIRKODpOodo8rTphU35BtlX3YClSjOZ+mQdTN3T4= X-Google-Smtp-Source: ABdhPJzZ24BLj6+UEPwFxCLociHydB19E6KpodtLS4bkPkb34hcl7Xk4n9D52rlv5N1y3PNkLceeJUs2USVIbHiNdHU= X-Received: by 2002:a1c:720d:: with SMTP id n13mr6088896wmc.130.1590010309963; Wed, 20 May 2020 14:31:49 -0700 (PDT) MIME-Version: 1.0 References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> <5EC58C62.8090703@isdg.net> <7F78C2BA-648F-4051-822A-177DC2E7BD6B@kitterman.com> In-Reply-To: <7F78C2BA-648F-4051-822A-177DC2E7BD6B@kitterman.com> From: Seth Blank Date: Wed, 20 May 2020 14:31:38 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b7073c05a61b1f07" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 20 May 2020 21:31:54 -0000 --000000000000b7073c05a61b1f07 Content-Type: text/plain; charset="UTF-8" There appears to be broad consensus in the group that there is no need for JSON output from aggregate reports, except for one argument that the additional flexibility of allowing JSON would be good for those who work in Javascript. But I haven't heard any group specifically identified that would want to use this. Can anyone raise their hand, or bring someone to the table, who has a working DMARC implementation that would be improved by a standards track documents which includes JSON support, or has not implemented DMARC solely due to lack of JSON support? Short this, I'll call rough consensus that DMARCbis need not support JSON. Seth, as Chair On Wed, May 20, 2020 at 1:06 PM Scott Kitterman wrote: > > > On May 20, 2020 8:00:34 PM UTC, Hector Santos 40isdg.net@dmarc.ietf.org> wrote: > > > >On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > > > >> Transaction? I thought we were talking about aggregate reports. > > > >So am I. > > > >> There are no transactions there. > > > >Really? > > > >Each SMTP session can be considered a transaction. You are provided > >results on the these DMARC processed transaction. > > > >> I mean, what is the CSV format of the following report, that I sent > >yesterday > >> for this list: > > > >Sorry, if I ignored it. > > > >Forgetting fact that you can your report easier to read for consumers, > >these would be an example of the CSV field headers. > > > >CSV headers: > > > >report_metadata.org_name, report_metadata.email, > >report_metadata.report_id, report_metadata.date_range.begin, > >report_metadata.date_range.end > > > >Policy_Published.domain, Policy_Published.adkim, > >Policy_Published.aspf, Policy_Published.p > > > >record.row, record.row.source_ip.record.count. > >record.row.policy_evaluated, record.row.policy_evaluated.disposition, > >record.row,policy_evaluated.disposition, > >record.row.policy_evaluated.dkim, record.row.policy_evaluated.spf > > > >Note: You don't have to stick to redundant "name space" field names. > > > >>>> ... Can we get back to work, please? > >>> > >>> Sorry, but I consider a rude, disrespectful and ignorant statement, > >to be > >>> saying that. > >> > >> > >> No personal attack intended. I'm being rude because I have the > >impression that > >> you are not defending a concrete, well defined need, but instead find > >new > >> arguments opportunistically to pursue a vague sense of format > >fashion. > > > >That's a personal attack. If you don't understand the proposal, you > >should back off or ask for clarification. > > > >> You > >> shifted from an asserted necessity of producers to a possible desire > >of > >> consumers. > > > >I did no such thing. I won't repeat it, but it appears you didn't > >understand the proposal. > > > >>Now you introduce formats like CSV which make no sense in DMARC > >> context. > > > >I disagree. See above. > > > >> I hold that CSV cannot satisfy DMARC requirements. > > > >Hold it all you want. You know it would not be true. See above. > > > >? Please do contradict me by > >> showing us how an aggregate report in CSV would look like, as well as > >some > >> ideas for defining the corresponding template, similar to what > >Appendix C of > >> RFC 7489 specifies for XML. > > > >Ok, I won't but if you don't understand the proposal, you should ask > >for clarification. > > > >CSV can work, so can JSON. Limiting it and locking it down to XML > >only would be a limitation. You can agree or not agree with that. > > Not requiring RFC 1149 support is also a limitation, but I'm fine with > that. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000b7073c05a61b1f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There appears to be broad consensus in the group that= there is no need for JSON output from aggregate reports, except for one ar= gument that the additional flexibility of allowing JSON would be good for t= hose who work in Javascript. But I haven't heard any group specifically= identified that would want to use this.

Can anyon= e raise their hand, or bring someone to the table, who has a working DMARC = implementation that would be improved by a standards track documents which = includes JSON support,=C2=A0or has not implemented DMARC solely due to lack= of JSON support?

Short this, I'll call rough = consensus that DMARCbis need not=C2=A0support JSON.

Seth, as Chair


On Wed, May 20, 2020 at 1:06 PM Scott Kitterman &= lt;sklist@kitterman.com> wro= te:


On May 20, 2020 8:00:34 PM UTC, Hector Santos <hsantos=3D40isdg.net@dmarc.ietf.org> wrote:
>
>On 5/20/2020 2:43 PM, Alessandro Vesely wrote:
>
>> Transaction?=C2=A0 I thought we were talking about aggregate repor= ts.
>
>So am I.
>
>> There are no transactions there.
>
>Really?
>
>Each SMTP session can be considered a transaction. You are provided
>results on the these DMARC processed transaction.
>
>> I mean, what is the CSV format of the following report, that I sen= t
>yesterday
>> for this list:
>
>Sorry, if I ignored it.
>
>Forgetting fact that you can your report easier to read for consumers, =
>these would be an example of the CSV field headers.
>
>CSV headers:
>
>report_metadata.org_name, report_metadata.email,
>report_metadata.report_id, report_metadata.date_range.begin,
>report_metadata.date_range.end
>
>Policy_Published.domain, Policy_Published.adkim,
>Policy_Published.aspf, Policy_Published.p
>
>record.row, record.row.source_ip.record.count.
>record.row.policy_evaluated, record.row.policy_evaluated.disposition, <= br> >record.row,policy_evaluated.disposition,
>record.row.policy_evaluated.dkim, record.row.policy_evaluated.spf
>
>Note: You don't have to stick to redundant "name space" f= ield names.
>
>>>> ...=C2=A0 Can we get back to work, please?
>>>
>>> Sorry, but I consider a rude, disrespectful and ignorant state= ment,
>to be
>>> saying that.
>>
>>
>> No personal attack intended.=C2=A0 I'm being rude because I ha= ve the
>impression that
>> you are not defending a concrete, well defined need, but instead f= ind
>new
>> arguments opportunistically to pursue a vague sense of format
>fashion.
>
>That's a personal attack. If you don't understand the proposal,= you
>should back off or ask for clarification.
>
>> You
>> shifted from an asserted necessity of producers to a possible desi= re
>of
>> consumers.
>
>I did no such thing. I won't repeat it, but it appears you didn'= ;t
>understand the proposal.
>
>>Now you introduce formats like CSV which make no sense in DMARC
>> context.
>
>I disagree. See above.
>
>> I hold that CSV cannot satisfy DMARC requirements.
>
>Hold it all you want. You know it would not be true. See above.
>
>? Please do contradict me by
>> showing us how an aggregate report in CSV would look like, as well= as
>some
>> ideas for defining the corresponding template, similar to what
>Appendix C of
>> RFC 7489 specifies for XML.
>
>Ok, I won't but if you don't understand the proposal, you shoul= d ask
>for clarification.
>
>CSV can work, so can JSON.=C2=A0 Limiting it and locking it down to XML=
>only would be a limitation.=C2=A0 =C2=A0You can agree or not agree with= that.

Not requiring RFC 1149 support is also a limitation, but I'm fine with = that.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818



This em= ail and all data transmitted with it contains confidential and/or proprieta= ry information intended solely for the use of individual(s) authorized to r= eceive it. If you are not an intended and authorized recipient you are here= by notified of any use, disclosure, copying or distribution of the informat= ion included in this transmission is prohibited and may be unlawful. Please= immediately notify the sender by replying to this email and then delete it= from your system.

--000000000000b7073c05a61b1f07-- From nobody Wed May 20 22:21:39 2020 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 C72E83A0B1D for ; Wed, 20 May 2020 22:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZHLbh_eIUYt for ; Wed, 20 May 2020 22:21:35 -0700 (PDT) Received: from mail.leemankuiper.nl (mail.leemankuiper.nl [87.239.13.39]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30AE3A0B1C for ; Wed, 20 May 2020 22:21:34 -0700 (PDT) Received: from LAPC01 (83-83-137-222.cable.dynamic.v4.ziggo.nl [83.83.137.222]) by mail.leemankuiper.nl (Postfix) with ESMTPSA id 6B913142BA7; Thu, 21 May 2020 07:21:30 +0200 (CEST) Authentication-Results: mail.leemankuiper.nl; auth=pass; dkim=pass (2048-bit rsa key sha256) header.d=leemankuiper.nl header.i=@leemankuiper.nl header.b=SEwKe4cK header.a=rsa-sha256 header.s=mta1; x-return-mx=pass header.domain=leemankuiper.nl policy.is_org=yes (MX Records found: mail.leemankuiper.nl); x-return-mx=pass smtp.domain=leemankuiper.nl policy.is_org=yes (MX Records found: mail.leemankuiper.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=leemankuiper.nl; s=mta1; t=1590038490; bh=syPMeNnrW2hsPr5ImkdejAObWJMT68M5qT9fwwmW3oA=; h=From:To:References:In-Reply-To:Subject:Date:From; b=SEwKe4cKajTT28UidDge1nBnslSHpfBARic1O9EAefX9AFv2QmcjzZBmYmr6AY6B5 Ru+lrfuZJJ2oo6litAZgPqC6OOyZ2P3aVsX66dyJdvi5d8pl9d1KqrBNGXLD8VMmbU eq+cxyy86pBhWcAERdqdqr8teZHXZMK7cADvmZYDuSvq5sjALytCV0UDYBW5jcAxoI ouCu4ZdAHijm1Qkzmv00GLzMQ2i6ekCZ3tewwNLrzHIKf9JimOLHBBOHjk4IIKmp8l BXjTBhjRGOMAZoWhmmrUeg7tUy2B0SJSZLA/KWBdg0qs5ubPTQwfETVJUhfRj5FWSR 6sVblAcr/NYGw== From: "Freddie Leeman" To: , References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> <5EC58C62.8090703@isdg.net> In-Reply-To: <5EC58C62.8090703@isdg.net> Date: Thu, 21 May 2020 07:21:29 +0200 Message-ID: <0b0901d62f2f$afd134a0$0f739de0$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHqhqrkGq4QDGdtlw1nCJjfBCszWQJwYSDVAgoyGbcCyWxIBQK4/HM4AqjaHvgByEGZ+AEVOd/xAYiot1oCAfq3xQImbdqdAdLo5esCn4uxmQId4Lbbp6smqnA= Content-Language: nl Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 21 May 2020 05:21:38 -0000 Let me get this straight? You want to repeat all the header values on = each row for each record? How is that better than XML? CSV is just not a format that we can use here, it just isn't. I bet that = there are people that would like the reports in D64 or MP3 format, but = for obvious reasons that is just as unrealistic. Personally I would = prefer JSON over XML, but I do not see a benefit to having multiple = formats, and since we already have XML, I suggest we keep it that way. I don't think 'consumers' would want to read DMARC reports anyway. = Reading DMARC reports is one thing, understanding them is something = else. If a consumer is willing to read DMARC reports, and understands = them, they would have no problem reading XML or converting them to = something that fits their needs. --- Freddie -----Oorspronkelijk bericht----- Van: Hector Santos [mailto:hsantos@isdg.net]=20 Verzonden: woensdag 20 mei 2020 22:01 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting = format? On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > Transaction? I thought we were talking about aggregate reports. So am I. > There are no transactions there. Really? Each SMTP session can be considered a transaction. You are provided = results on the these DMARC processed transaction. > I mean, what is the CSV format of the following report, that I sent=20 > yesterday for this list: Sorry, if I ignored it. Forgetting fact that you can your report easier to read for consumers, = these would be an example of the CSV field headers. CSV headers: report_metadata.org_name, report_metadata.email, = report_metadata.report_id, report_metadata.date_range.begin, = report_metadata.date_range.end Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, = Policy_Published.p record.row, record.row.source_ip.record.count.=20 record.row.policy_evaluated, record.row.policy_evaluated.disposition, record.row,policy_evaluated.disposition, record.row.policy_evaluated.dkim, record.row.policy_evaluated.spf Note: You don't have to stick to redundant "name space" field names. >>> ... Can we get back to work, please? >> >> Sorry, but I consider a rude, disrespectful and ignorant statement,=20 >> to be saying that. > > > No personal attack intended. I'm being rude because I have the=20 > impression that you are not defending a concrete, well defined need,=20 > but instead find new arguments opportunistically to pursue a vague = sense of format fashion. That's a personal attack. If you don't understand the proposal, you = should back off or ask for clarification. > You > shifted from an asserted necessity of producers to a possible desire=20 > of consumers. I did no such thing. I won't repeat it, but it appears you didn't = understand the proposal. >Now you introduce formats like CSV which make no sense in DMARC =20 >context. I disagree. See above. > I hold that CSV cannot satisfy DMARC requirements. Hold it all you want. You know it would not be true. See above. ? Please do contradict me by > showing us how an aggregate report in CSV would look like, as well as=20 > some ideas for defining the corresponding template, similar to what=20 > Appendix C of RFC 7489 specifies for XML. Ok, I won't but if you don't understand the proposal, you should ask for = clarification. CSV can work, so can JSON. Limiting it and locking it down to XML=20 only would be a limitation. You can agree or not agree with that. -- HLS From nobody Thu May 21 03:38:43 2020 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 F03903A0B88 for ; Thu, 21 May 2020 03:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=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 lemifSFA0blv for ; Thu, 21 May 2020 03:38:39 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 5E1BB3A0B9F for ; Thu, 21 May 2020 03:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1590057515; bh=Xs+Z8EWGuRtdbdf0UIDSDNfDaRgpELaOwYKt0pjG+Go=; l=10329; h=To:References:From:Date:In-Reply-To; b=AAx7Rn1ESgWtoQXr83IoGZT1gLF/eMdv+CUdq3xtizKbMNJGmUVWFBFi4+cw+RK6V L9Mj2y6WDB5EbOSm9q6rXvsYXn0x1oX+xiTDhKULAnfuLLHxuUHXwbxrIjI6pcWo1Q sbn3jVTRZYJT2D3nTnxcamjMxpB6TskLq/XNNsiVDB35M7giuG5w+dwz11o8q 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BA.000000005EC65A2A.00002115; Thu, 21 May 2020 12:38:34 +0200 To: dmarc@ietf.org References: <5EBF720D.8040608@isdg.net> <44D5CBFA-85B6-4FEE-BBB3-B915D229984B@episteme.net> <5EC02769.9070508@isdg.net> <492288f0-3fc3-f85e-26c0-eda418de6b5c@tana.it> <5EC47889.3030905@isdg.net> <8675CCF3-436F-4D0C-B286-AEAD0AF91BB7@kitterman.com> <5EC52749.20801@isdg.net> <5EC56014.70506@isdg.net> <3e9d3c49-c1c9-796f-64f3-fcc8f316a51c@tana.it> <5EC58C62.8090703@isdg.net> From: Alessandro Vesely Message-ID: Date: Thu, 21 May 2020 12:38:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5EC58C62.8090703@isdg.net> Content-Type: multipart/mixed; boundary="------------96A003BEBFB854D8B0E1193A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format? 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, 21 May 2020 10:38:42 -0000 This is a multi-part message in MIME format. --------------96A003BEBFB854D8B0E1193A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On Wed 20/May/2020 22:00:34 +0200 Hector Santos wrote: > On 5/20/2020 2:43 PM, Alessandro Vesely wrote: > >> I mean, what is the CSV format of the following report, that I sent yesterday >> for this list: > > Sorry, if I ignored it. > > Forgetting fact that you can your report easier to read for consumers, these > would be an example of the CSV field headers. > > CSV headers: > > report_metadata.org_name, report_metadata.email, report_metadata.report_id, > report_metadata.date_range.begin, report_metadata.date_range.end > > Policy_Published.domain, Policy_Published.adkim, Policy_Published.aspf, > Policy_Published.p > > record.row, record.row.source_ip.record.count. record.row.policy_evaluated, > record.row.policy_evaluated.disposition, > record.row,policy_evaluated.disposition, record.row.policy_evaluated.dkim, > record.row.policy_evaluated.spf > > Note: You don't have to stick to redundant "name space" field names. You didn't include auth_results. That's tricky because you can have zero or more dkim and spf results. That would bring on a variable number of columns, with no hint about which is which. As Freddie noted, repeating the headers for every record may sound a little bit wasteful, but gzip may come to rescue here too. As for readability, aggregate reports are designed to be machine-readable to the extreme detriment of any kind of human readability. The best samples of such attitude are the date_range elements. HTML provides for a much better human readability. (Indeed, it is one of the formats you mentioned, as it is supported by Google Docs). I attach the HTML equivalent of the data I sent yesterday. Posters whose From: was rewritten can easily spot their row —readability meaning exactly that. Let me note that such htmlization is the result of a DMARC XSLT applied by a mail filter after rua messages authentication but before delivery. That way, a readable format of the reports is ready in the mail folder whenever I'd care to look at it, *as if it had been written in HTML in the first place*. By similar techniques one can obtain JSON, SQL, TXT, …. In the face of such flexibility, I'm puzzled by your asking for more. >>>> ...  Can we get back to work, please? >>> >>> Sorry, but I consider a rude, disrespectful and ignorant statement, to be >>> saying that. >> >> >> No personal attack intended.  I'm being rude because I have the impression that >> you are not defending a concrete, well defined need, but instead find new >> arguments opportunistically to pursue a vague sense of format fashion. > > That's a personal attack. If you don't understand the proposal, you should back > off or ask for clarification. I /am/ asking for clarifications. Please excuse my tone if it hurts you. I'll try and keep calm, but please restrain from technically flaky arguments such as CSV. I think you're perfectly aware of the capabilities I'm exemplifying here. They rest on the fact that a report consumer knows in advance the format of the data inside the received gzip. Hence, that flexibility would be destroyed by the introduction of multiple formats, as they would come randomly at the mercy of the report generators, any prf= notwithstanding. Not a great loss, given your feeling about reporting? >> You shifted from an asserted necessity of producers to a possible desire >> of consumers.> > I did no such thing. I won't repeat it, but it appears you didn't understand > the proposal. For sure, I don't understand the proposal. Let's start over: On Sat 16/May/2020 19:48:25 +0200 Hector Santos wrote: > Just consider, when the spec has XML-only, then for those who use a solid > JSON I/O system, they are now going to be required to add XML. So for them, > its additional development complexity. Everything they probably do JSON > related. The exception would be DMARC using XML. This alone can delay or > push aside DMARC Reporting implementation. Does DMARC Reporting implementation mean generation or consumption? On Wed 20/May/2020 02:23:37 +0200 Hector Santos wrote: > I suggest that there is a new tag that provides a "Preferred Report Format" > or "prf=" tag using registered acronymns for long time "standard" formats. > For example:> > prf=cvs,json,xml,afrf,iodef > > [...] > > The verifier will do what can it offer. The publisher is providing a > preference, that it may not get. That's 100% uncertainty of the result, isn't it? How is flexibility improved? I cannot store a received report as-is in Google Docs anyway, can I? Best Ale -- --------------96A003BEBFB854D8B0E1193A Content-Type: text/html; charset=UTF-8; name="readable-report.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="readable-report.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0 bWwiIHhtbG5zOmRhdGU9Imh0dHA6Ly9leHNsdC5vcmcvZGF0ZXMtYW5kLXRpbWVzIj48aGVh ZD48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1VVEYtOCIgLz48dGl0bGU+DQoJCQkJRmVlZGJhY2sgZnJvbQ0KCQkJCXRhbmEu aXQ8L3RpdGxlPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgaWQ9ImludGVybmFsLXN0eWxlIj4N CgkJCQkJYm9keSB7DQoJCQkJCQlmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsNCgkJCQkJCWNvbG9yOiAjMDAzMzAwOw0KCQkJCQkJYmFja2dyb3VuZC1jb2xv cjogI2ZmY2M2NjsNCgkJCQkJfQ0KCQkJCQl0YWJsZSwgcCB7DQoJCQkJCQltYXJnaW46IDFl bTsNCgkJCQkJCXBhZGRpbmc6IDRwdDsNCgkJCQkJCWJhY2tncm91bmQtY29sb3I6ICNmZmVl YWE7DQoJCQkJCQlib3JkZXI6IDNwdCBzb2xpZCAjNzc2NjMzOyANCgkJCQkJfQ0KCQkJCQl0 ZCwgdGggew0KCQkJCQkJbWFyZ2luOiAycHQ7DQoJCQkJCQlwYWRkaW5nOiAycHQ7DQoJCQkJ CQlib3JkZXI6IDFwdCBzb2xpZCAjNzc2NjMzOyANCgkJCQkJfQ0KCQkJCQkucGFzcyB7DQoJ CQkJCQliYWNrZ3JvdW5kLWNvbG9yOiAjMTFiYjAwOw0KCQkJCQl9DQoJCQkJCS5mYWlsIHsN CgkJCQkJCWJhY2tncm91bmQtY29sb3I6ICNjYzAwMDA7DQoJCQkJCX0NCgkJCQkJLmRraW1w b2xpY3kgew0KCQkJCQkJYmFja2dyb3VuZC1jb2xvcjogI2ZmZmY2NjsNCgkJCQkJfQ0KCQkJ CQkuZXJyb3Igew0KCQkJCQkJYmFja2dyb3VuZC1jb2xvcjogI2JiYWFhYTsNCgkJCQkJCWZv bnQtd2VpZ2h0OiBib2xkOw0KCQkJCQl9DQoJCQkJCS5zb2Z0ZmFpbCB7DQoJCQkJCQliYWNr Z3JvdW5kLWNvbG9yOiAjZmY4ODY2Ow0KCQkJCQl9DQoJCQkJCS5yZWplY3Qgew0KCQkJCQkJ YmFja2dyb3VuZC1jb2xvcjogI2NjMDAwMDsNCgkJCQkJfQ0KCQkJCQkucXVhcmFudGluZSB7 DQoJCQkJCQliYWNrZ3JvdW5kLWNvbG9yOiAjZmY4ODY2Ow0KCQkJCQl9DQoJCQkJCS5ub3Jt YWwgew0KCQkJCQl9DQoJCQkJCS5maWVsZCB7DQoJCQkJCQlmb250LXdlaWdodDogYm9sZDsN CgkJCQkJfQ0KCQkJCTwvc3R5bGU+PC9oZWFkPjxib2R5PjxoMT4NCgkJCQlGZWVkYmFjayBm cm9tDQoJCQkJdGFuYS5pdDwvaDE+PHA+PHNwYW4gY2xhc3M9ImZpZWxkIj5JZDogPC9zcGFu PmViNzRkYjkwYzMyZDQzMmVhMTY1MmEwZWI2NTZmZTVhOyA8c3BhbiBjbGFzcz0iZmllbGQi PmJlZ2luOiA8L3NwYW4+MjAyMC0wNS0xOVQwMDowMDowMFo7IDxzcGFuIGNsYXNzPSJmaWVs ZCI+ZW5kOiA8L3NwYW4+MjAyMC0wNS0yMFQwMDowMDowMFo8YnIgLz48c3BhbiBjbGFzcz0i ZmllbGQiPkRvbWFpbjogPC9zcGFuPmRtYXJjLmlldGYub3JnOyA8c3BhbiBjbGFzcz0iZmll bGQiPkRLSU06IDwvc3Bhbj5yZWxheGVkOyA8c3BhbiBjbGFzcz0iZmllbGQiPlNQRjogPC9z cGFuPnJlbGF4ZWQ7IDxzcGFuIGNsYXNzPSJmaWVsZCI+cG9saWN5IHB1Ymxpc2hlZDogPC9z cGFuPm5vbmUgIDwvcD48dGFibGU+PHRyPjx0aD4NCgkJCQkJCQlSZWxheWluZyBJUA0KCQkJ CQkJPC90aD48dGg+DQoJCQkJCQkJbWVzc2FnZSBjb3VudA0KCQkJCQkJPC90aD48dGg+DQoJ CQkJCQkJcmVhc29uIGFuZCBkaXNwb3NpdGlvbg0KCQkJCQkJPC90aD48dGg+DQoJCQkJCQkJ RnJvbSBoZWFkZXINCgkJCQkJCQk8YnIgLz4NCgkJCQkJCQkob3B0LiBlbnZlbG9wZSkNCgkJ CQkJCTwvdGg+PHRoPg0KCQkJCQkJCVNQRg0KCQkJCQkJPC90aD48dGg+DQoJCQkJCQkJCURL SU0NCgkJCQkJCQk8L3RoPjx0aD4NCgkJCQkJCQkJCTJuZCBES0lNDQoJCQkJCQkJCTwvdGg+ PHRoPg0KCQkJCQkJCQkJCTNyZCBES0lNDQoJCQkJCQkJCQk8L3RoPjwvdHI+DQoJCQkJCTx0 cj48dGQ+PGEgaHJlZj0iIyI+NC4zMS4xOTguNDQ8L2E+PC90ZD48dGQgYWxpZ249InJpZ2h0 Ij4xPC90ZD48dGQgY2xhc3M9Im5vcm1hbCI+PC90ZD48dGQ+ZG1hcmMuaWV0Zi5vcmc8L3Rk Pjx0ZCBjbGFzcz0icGFzcyI+aWV0Zi5vcmc8YnIgLz5tZnJvbTxiciAvPjwvdGQ+PHRkIGNs YXNzPSJwYXNzIj5pZXRmLm9yZzxiciAvPmlldGYxPGJyIC8+PC90ZD48dGQgY2xhc3M9ImZh aWwiPmlldGYub3JnPGJyIC8+aWV0ZjE8YnIgLz48L3RkPjx0ZCBjbGFzcz0iZmFpbCI+YWth bWFpLmNvbTxiciAvPmphbjIwMTYuZW5nPGJyIC8+PC90ZD48L3RyPg0KCQk8dHI+PHRkPjxh IGhyZWY9IiMiPjQuMzEuMTk4LjQ0PC9hPjwvdGQ+PHRkIGFsaWduPSJyaWdodCI+MTwvdGQ+ PHRkIGNsYXNzPSJub3JtYWwiPjwvdGQ+PHRkPmRtYXJjLmlldGYub3JnPC90ZD48dGQgY2xh c3M9InBhc3MiPmlldGYub3JnPGJyIC8+bWZyb208YnIgLz48L3RkPjx0ZCBjbGFzcz0icGFz cyI+aWV0Zi5vcmc8YnIgLz5pZXRmMTxiciAvPjwvdGQ+PHRkIGNsYXNzPSJmYWlsIj5pZXRm Lm9yZzxiciAvPmlldGYxPGJyIC8+PC90ZD48dGQgY2xhc3M9ImZhaWwiPmNpc2NvLmNvbTxi ciAvPmlwb3J0PGJyIC8+PC90ZD48L3RyPg0KCQk8dHI+PHRkPjxhIGhyZWY9IiMiPjQuMzEu MTk4LjQ0PC9hPjwvdGQ+PHRkIGFsaWduPSJyaWdodCI+MjwvdGQ+PHRkIGNsYXNzPSJub3Jt YWwiPjwvdGQ+PHRkPmRtYXJjLmlldGYub3JnPC90ZD48dGQgY2xhc3M9InBhc3MiPmlldGYu b3JnPGJyIC8+bWZyb208YnIgLz48L3RkPjx0ZCBjbGFzcz0icGFzcyI+aWV0Zi5vcmc8YnIg Lz5pZXRmMTxiciAvPjwvdGQ+PHRkIGNsYXNzPSJmYWlsIj5pZXRmLm9yZzxiciAvPmlldGYx PGJyIC8+PC90ZD48dGQgY2xhc3M9ImZhaWwiPmp1bmMuZXU8YnIgLz5kZWZhdWx0PGJyIC8+ PC90ZD48L3RyPg0KCQk8dHI+PHRkPjxhIGhyZWY9IiMiPjQuMzEuMTk4LjQ0PC9hPjwvdGQ+ PHRkIGFsaWduPSJyaWdodCI+MTwvdGQ+PHRkIGNsYXNzPSJub3JtYWwiPjwvdGQ+PHRkPmRt YXJjLmlldGYub3JnPC90ZD48dGQgY2xhc3M9InBhc3MiPmlldGYub3JnPGJyIC8+bWZyb208 YnIgLz48L3RkPjx0ZCBjbGFzcz0icGFzcyI+aWV0Zi5vcmc8YnIgLz5pZXRmMTxiciAvPjwv dGQ+PHRkIGNsYXNzPSJmYWlsIj5pZXRmLm9yZzxiciAvPmlldGYxPGJyIC8+PC90ZD48dGQg Y2xhc3M9ImZhaWwiPnZhbGltYWlsLmNvbTxiciAvPmdvb2dsZTIwNDg8YnIgLz48L3RkPjwv dHI+DQoJCTwvdGFibGU+PHA+PGI+PHU+TGVnZW5kPC91PjxiciAvPg0KCQkJCQlkaXNwb3Np dGlvbjogPC9iPjxzcGFuIGNsYXNzPSJxdWFyYW50aW5lIj5xdWFyYW50aW5lPC9zcGFuPiwN CgkJCQkJPHNwYW4gY2xhc3M9InJlamVjdCI+cmVqZWN0PC9zcGFuPi48YnIgLz48Yj5zcGY6 IDwvYj48c3BhbiBjbGFzcz0icGFzcyI+cGFzczwvc3Bhbj4sDQoJCQkJCTxzcGFuIGNsYXNz PSJmYWlsIj5mYWlsPC9zcGFuPiwNCgkJCQkJPHNwYW4gY2xhc3M9InNvZnRmYWlsIj5zb2Z0 ZmFpbDwvc3Bhbj4sDQoJCQkJCTxzcGFuIGNsYXNzPSJlcnJvciI+dGVtcGVycm9yIG9yIHBl cm1lcnJvcjwvc3Bhbj4uPGJyIC8+PGI+ZGtpbTogPC9iPjxzcGFuIGNsYXNzPSJwYXNzIj5w YXNzPC9zcGFuPiwNCgkJCQkJPHNwYW4gY2xhc3M9ImZhaWwiPmZhaWw8L3NwYW4+LA0KCQkJ CQk8c3BhbiBjbGFzcz0iZGtpbXBvbGljeSI+cG9saWN5PC9zcGFuPi4NCgkJCQk8L3A+PC9i b2R5PjwvaHRtbD4NCg== --------------96A003BEBFB854D8B0E1193A-- From nobody Thu May 21 13:55:12 2020 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 2D5743A0ABC for ; Thu, 21 May 2020 13:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvkhiQH-rJVV for ; Thu, 21 May 2020 13:55:07 -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 4B78C3A0A8D for ; Thu, 21 May 2020 13:55:07 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 63so6621503oto.8 for ; Thu, 21 May 2020 13:55:07 -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=aTOZ0Yr/6DdNaKAbbHHtTUaAUHb6H9lgUvV2clQJe4Y=; b=fDHCViVJaHumWI1HH+5aS/ELvgbsW64dyDSDs6c1RMLUwcxgOHzHoxwnOxYKpWQFK2 rCC4boVl4DD1RbrQ7sCmlSyySdAxzbBg4Ue3aktYFcod2K4G79nZr62BdpUg8a70op7j R0jHoKU1Hy5/Yf2E3ieeD2wdByGYIr0JeKwol2vKMjVOyqCxePihvb/rUQrLQ8yO0aXl vrbn9/iubVex1PZNqtDkcJQ05roeBUIpYOQToRjmH72WWYfCbViU9dPak6VkddHvfEB+ bpnJEcI7/f7QyMqe3Hg0lsLlA3yegMKyjvFOOFUIeFKYddAgiHXsrHMy057MWKmZKLxr dMww== 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=aTOZ0Yr/6DdNaKAbbHHtTUaAUHb6H9lgUvV2clQJe4Y=; b=galzXJabao5xQfDUdEaFYfXHKmQvI88zE7HUsTaSwp3hj4lmYTD/n651BYZpWARup8 ckgM0s8zIW3rouZTiHgfGgXlaluZWrDTbkdbWXNwb6rlRv3f8IdHwHyndVaBWhNiAolZ uJR5GyIqkoHLLIUpjzb67wUAWjmkCAzrHY+/JPSFalmZUSJ8SPcP9mnj5BD+R7mPHZzC HwG93wu6AVa2HnPXCj+dSFOukMZoqACt0vYlRrkE/TbDV9qKKtKmGusRAoCVbtR8XTpB OpDkknVKE3TdZqod8MsXWkWRJ1q8IO9A65TMBsldoBeZVE2eR1ynH51fDIaTlvxfTdvF 22Dw== X-Gm-Message-State: AOAM530dbbguWhZfwyoIZIymsrDz0WC3vLOxlU7u/hx25e5IMlOR1T8y pz9F3XlnaybAznq3+XoYl8dC+RQypVs1PlibMXI= X-Google-Smtp-Source: ABdhPJzqfinV52pvP26XsbsVdrdjvOmr/wlWbNd+FcEmYTnHZ6oOZiqB2ebycKrwQVAAJgrw9nZQGy4IY4JN4NPiVac= X-Received: by 2002:a05:6830:3109:: with SMTP id b9mr5461898ots.41.1590094506610; Thu, 21 May 2020 13:55:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 21 May 2020 16:54:55 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000039d37a05a62eba62" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 20:55:09 -0000 --00000000000039d37a05a62eba62 Content-Type: text/plain; charset="UTF-8" (With no hats) I agree with John the v=DMARC1; is magic and MUST be first. Everything else can show up wherever. tim On Fri, May 15, 2020 at 9:09 PM John Levine wrote: > In article s9CQA7s1g@mail.gmail.com>, > Murray S. Kucherawy wrote: > >It's been a while since the original discussion, but I can't remember why > >the requirement is there in the first place. The only benefit I can think > >of is that having "v=" first lets you decide very quickly if you care to > >continue, but the savings is really pretty small. > > The v=DMARC1; is a magic number that tells you whether it's worth decoding > the > rest of the record. People put a lot of junk at tops of their zones, some > of which is in k=v format and I would prefer not to try to decode records > full > of junk to see of a v= tag is in there somewhere. > > Other than that I agree there is no reason to specify the order of > tags. > > -- > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > 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 > --00000000000039d37a05a62eba62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(= With no hats)

I agree with John the=C2=A0v=3DDMARC1; is magic and MUST be first.=C2=A0 E= verything else can show up wherever.

tim


On Fri, May 15, 2020 at 9:09 PM John Levine &= lt;johnl@taugh.com> wrote:
In article <CAL0qLw= a-iuyB_iNQU+g6e3NH1+q0W413RaCZcHp=3D=3Ds9CQA7s1g@mail.gmail.com>,
Murray S. Kucherawy=C2=A0 <superuser@gmail.com> wrote:
>It's been a while since the original discussion, but I can't re= member why
>the requirement is there in the first place.=C2=A0 The only benefit I c= an think
>of is that having "v=3D" first lets you decide very quickly i= f you care to
>continue, but the savings is really pretty small.

The v=3DDMARC1; is a magic number that tells you whether it's worth dec= oding the
rest of the record.=C2=A0 People put a lot of junk at tops of their zones, = some
of which is in k=3Dv format and I would prefer not to try to decode records= full
of junk to see of a v=3D tag is in there somewhere.

Other than that I agree there is no reason to specify the order of
tags.

--
Regards,
John Levine, johnl@tau= gh.com, Primary Perpetrator of "The Internet for Dummies", 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
--00000000000039d37a05a62eba62-- From nobody Thu May 21 14:12:00 2020 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 4EF9A3A0A98 for ; Thu, 21 May 2020 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=eEfcDWKH; dkim=pass (2048-bit key) header.d=kitterman.com header.b=JJYT5J0g 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 NfXybElUdgJi for ; Thu, 21 May 2020 14:11:56 -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 A935B3A0A86 for ; Thu, 21 May 2020 14:11:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 58423F80271 for ; Thu, 21 May 2020 17:11:55 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1590095515; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fzMHOtUCS+HxTS8hvXJ1npLj/FMuDclnF+bBBiBx9SU=; b=eEfcDWKH5ZEBu5fprJFgKzaB19uuW2mijuoR+6NBmzhO9+fqEP6tRFQ0xWdOCeRZNied8 nf8SfHipZExq7q5DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1590095515; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fzMHOtUCS+HxTS8hvXJ1npLj/FMuDclnF+bBBiBx9SU=; b=JJYT5J0gmYTXpYhAoRtCnzVERKOHk6XcgUJwxR6y7m6y7oyFQLJT9BJhMsRrzSYLDq0lX 7mAsuEVgWxryz2ZjcLU9h60sNN5selHX0ZSmPCxfxJ+jsQ78bEzXtOyRZA/2jQcw0X09P01 10DMigqXRImOzkbihXcAqDwnPjJ64kOzynS9uyXWtqzhyWjmpQZEq5w57Av1jfHdK4XIQu2 9catJogJJrqOfMTQqi+/cfCuEP3NvjLmBorM0otA0Xdo/9KE/v0lt8AkL/wIhNjL6AWBS7v 4GnzZy3SOjQW+94QA06U1O9DfMtSfNf/w2YyPQ5NmQOwRBnLcy8StseofzkQ== Received: from localhost.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 1B89DF8009D for ; Thu, 21 May 2020 17:11:55 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 21 May 2020 17:11:54 -0400 Message-ID: <1784228.uJLO1Brz0r@localhost> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 21:11:59 -0000 Agreed. I don't think this is controversial. Also, I don't see a problem with making the p= tag optional (with an inferred value of None if not present). This is consistent with an existing SHOULD in RFC 7489 and appears to be broadly supported in existing implementations. I'd propose we close this ticket with the following resolution: The requirement that the v=DMARC1 tag be first will be retained. The requirement that the p= tag be second and the requirement that the p= tag is mandatory will be dropped. If the p= tag is not present, the implied policy value is None. Scott K On Thursday, May 21, 2020 4:54:55 PM EDT Tim Wicinski wrote: > (With no hats) > > I agree with John the v=DMARC1; is magic and MUST be first. Everything > else can show up wherever. > > tim > > On Fri, May 15, 2020 at 9:09 PM John Levine wrote: > > In article > s9CQA7s1g@mail.gmail.com>, > > > > Murray S. Kucherawy wrote: > > >It's been a while since the original discussion, but I can't remember why > > >the requirement is there in the first place. The only benefit I can > > >think > > >of is that having "v=" first lets you decide very quickly if you care to > > >continue, but the savings is really pretty small. > > > > The v=DMARC1; is a magic number that tells you whether it's worth decoding > > the > > rest of the record. People put a lot of junk at tops of their zones, some > > of which is in k=v format and I would prefer not to try to decode records > > full > > of junk to see of a v= tag is in there somewhere. > > > > Other than that I agree there is no reason to specify the order of > > tags. > > > > -- > > Regards, > > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > > Dummies", > > 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 From nobody Thu May 21 14:57:37 2020 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 568693A0C0E for ; Thu, 21 May 2020 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJF5YONEqNHA for ; Thu, 21 May 2020 14:57:34 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 A9FF83A0C00 for ; Thu, 21 May 2020 14:57:34 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id 23so6351727oiq.8 for ; Thu, 21 May 2020 14:57:34 -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=Oqz4abuvJBQE67kt/05DJXNk7fyGgWUO2ziRrXKmPU8=; b=VnrFeMujN97tVWYyAjx8U72dD/i+hU6dO70MXqBhCCfsQ9Lvgp/p5hL5wSpwP+XurT wK1r4m6lVPKhiPK2erw18JqtPKObSuZQhSfwwgGBlx1NsEeLr5cjkbKo8TgdfQB5A2A+ JY8/KEkyS9LN/ur3xfTP/1duX2cYguOtxaK5zSmPfTEG/kttY53D0YeArhxCGyZaNea4 6yVoa32xC7t4P8gcnpzYuSZef1ep33GdCqPIGT8LAyupKo3uhrr31vrNPxIkXG/iX/Ks C5r54sM+v3AXzVrgm8ZcG1aaxNUCrz/Pykq1F2/81tgSADNz7I3zgCk85tT3f8INIKHC GpmQ== 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=Oqz4abuvJBQE67kt/05DJXNk7fyGgWUO2ziRrXKmPU8=; b=GeGns6Xy56sydQLJXtvwpu/uYNyemWqIAXUl0VnVhJ2Yq0Jip6emuBx/m3qwEkjgus 7Z48u0HB0nGmDIaTnWdi3kdgj1Mv+8Pi5vlJM18tK+QRjgzAYfIY6mAvH6bmI3uS4zmN 9pJYCKX+a09zD+a9YxTwUsAagl4SE/7TBRIgRO4FwCG1PnUNfZvRr0e72EcigpRlrmtZ a1LVOMEK798XAUt2di7gP4rg+eAizUPxXeEgehLqbGygGBnOKpEWYtgWF/YWNL3/5Hgt cRnqL9vn8sWF1wAp06nX2IQ4LKrIXG/7gyAJZ9/qvkeVSI/8wCCXhj7R/meE/gBj6Qby jUjw== X-Gm-Message-State: AOAM532M424FLyPeQlHZsP6gkQqEklxDV7xCjr2HLcJwJj0OPReRK5KC ZwIZe+y+KU+EIZ/5Z1DiA36WQIUTGbi602rTykVIQWLF X-Google-Smtp-Source: ABdhPJzVxbUy3l0lWqh0y7liZxtY4u5yMzLYi7u17tR1pfpFqdPZkiFWZ5zbK4UCULqHtLuUplHmtED1QTtmM58fjG4= X-Received: by 2002:aca:518c:: with SMTP id f134mr547833oib.6.1590098253810; Thu, 21 May 2020 14:57:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 21 May 2020 17:57:22 -0400 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000938fbc05a62f99af" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 63: make p=none with no reporting URI invalid? 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, 21 May 2020 21:57:37 -0000 --000000000000938fbc05a62f99af Content-Type: text/plain; charset="UTF-8" (with no hats) p=none with no reporting is fine, and we should keep it. One thing the WG could do is a BCP document on operational recommendations where there are certain suggestions like this. tim On Sat, May 16, 2020 at 5:37 AM Alessandro Vesely wrote: > On Fri 15/May/2020 20:26:24 +0200 Seth Blank wrote: > > https://trac.ietf.org/trac/dmarc/ticket/63 > > > > A published DMARC record that consists solely of "v=DMARC1; p=none" is > > syntactically valid, but is semantically equivalent to having no record > at all. > > > > From an ecosystem perspective, especially in Europe, data has been shared > > showing an increasing number of domains putting in bare p=none records, > and > > then claiming that they are implementing DMARC and have some layer of > > protection against spoofing of their domain. > > > > Explicitly making this case invalid would remove confusion from the > ecosystem, > > and allow any checker that is up to spec to properly flag a bare p=none > record > > as being the same as not having a record at all. > > > > Should we make it invalid to have p=none without a reporting address? > > > No. A bare "v=DMARC1; p=none" still behaves better than NXDOMAIN, and may > cut > the number of necessary queries. We should instead recommend it. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000938fbc05a62f99af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(with no hats)

p=3Dnone with no reporting is fine, and we should keep it.=C2=A0
=

One thing the WG c= ould do is a BCP document on operational recommendations
where there are certain sug= gestions like this.=C2=A0=C2=A0

tim

On Sat, May 16, 2020 at 5:37 AM Alessandro Ve= sely <vesely@tana.it> wrote:
On Fri 15/May/2020= 20:26:24 +0200 Seth Blank wrote:
> https://trac.ietf.org/trac/dmarc/ticket/63
>
> A published DMARC record that consists solely of "v=3DDMARC1; p= =3Dnone" is
> syntactically valid, but is semantically equivalent to having no recor= d at all.
>
> From an ecosystem perspective, especially in Europe, data has been sha= red
> showing an increasing number of domains putting in bare p=3Dnone recor= ds, and
> then claiming that they are implementing DMARC and have some layer of<= br> > protection against spoofing of their domain.
>
> Explicitly making this case invalid would remove confusion from the ec= osystem,
> and allow any checker that is up to spec to properly flag a bare p=3Dn= one record
> as being the same as not having a record at all.
>
> Should we make it invalid to have p=3Dnone without a reporting address= ?


No.=C2=A0 A bare "v=3DDMARC1; p=3Dnone" still behaves better than= NXDOMAIN, and may cut
the number of necessary queries.=C2=A0 We should instead recommend it.


Best
Ale
--









































_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000938fbc05a62f99af-- From nobody Thu May 21 15:40:50 2020 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 8E3433A07A6 for ; Thu, 21 May 2020 15:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwIIJoTKrH-r for ; Thu, 21 May 2020 15:40:45 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D6D363A076F for ; Thu, 21 May 2020 15:40:44 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g185so8962511qke.7 for ; Thu, 21 May 2020 15:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OuqUD7biyNKnc9z5S6zLHXXfdOOCMIBNM7tIbjstkDg=; b=EQ6V3/14wPq8FVT8X5mchkpdiOce2CCwM3/w75NweIdtHLfZirEhMXCba/eqUDBg9I zoIgYRq4rUPr3CixEE0ZFg17S8MQiakOmGCe1uesoC3cSfJH+n0Ji87z+QVMc5eBTBDS N/KqCKabewt9sdZaJtm+2N2+vtPIWnE68Kfk+EtW57n+i+IHDLlBFGNRbwaQTKS562DA Ttn5VhqUKF2EyavRMaZMOzxwRbZqaC6MYN7C0AiS2+gu3QwHjANR5znWOIVWM0Iv6nAj zNT4sR44r05AVfjP5HCEMgbZCkI2EwDkYe6h/qspZWPIwcXXxDhGvXHHY+3yhkluDF76 XmEQ== 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=OuqUD7biyNKnc9z5S6zLHXXfdOOCMIBNM7tIbjstkDg=; b=LTX+0MKyKNz4XcxRDynDKVEVGOZCSxIVVJt/qmzhnSFpiv9It2N53dw/IABGeMST+F A2tg7DsPfjzDbM0YFAGH4YRBQNYaV4M6o8etEFoz4jAGadtQkVDiHP3oqJP865ukJeoi nacJHCv2BLWUeJDfaaFSJBU/bQQ9iYAmgJyhEbeWnXtZhHF7GbPZAtgc0rdHVtUq+1hq cC6Z0fGuSvV7JEe7xlm7lM/DFOVo2U+/lY4qiq4nSIYClGbjLeHbGz/TWqvMFcXJGKOy LViUnpfHLlL3vmMQdH7QSqZCxnhiUWlqZXRneoqHSg3Kx6vCBaXm8wNyX/LQMhdxUjMy ZChw== X-Gm-Message-State: AOAM533I5T2zkCFCKGcWEyJKgIjEXKoEXSQfIEq2uqkChqpKZvi2Puth 7ASuRRW404nublFGBfz1j9L7B4A3Ko3pFiX/dDmkW+yd X-Google-Smtp-Source: ABdhPJy4owsFv31Wi8HKd4nBIzxCRdqW5GaSPquIVTl+wpqmY5erurEvtFQKR6v1/aREOU2gm3XAWuT7r0JpwBrAegc= X-Received: by 2002:a37:384:: with SMTP id 126mr4480577qkd.325.1590100843425; Thu, 21 May 2020 15:40:43 -0700 (PDT) MIME-Version: 1.0 References: <1784228.uJLO1Brz0r@localhost> In-Reply-To: <1784228.uJLO1Brz0r@localhost> From: Todd Herr Date: Thu, 21 May 2020 18:40:32 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee184505a6303326" Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 21 May 2020 22:40:49 -0000 --000000000000ee184505a6303326 Content-Type: text/plain; charset="UTF-8" I disagree with the idea of making p= optional. My perception is that DMARC has been advertised to the ecosystem as a way for domain/brand owners to request specific treatment for mail that claims to be sent on behalf of a domain but that fails authentication checks. It's couched as a request for treatment because we already see frequent cases where the request is not honored, for example where a p=reject policy receives a disposition of quarantine; I've always believed this sort of thing to be due to the mailbox providers not exactly trusting the domain owners to fully understand the ramifications of their policy statement, and rather than do what's asked, the receiver takes the safer route to avoid the chance of a massive rejection of a legitimate mailing that had broken authentication for whatever reason. Making p= an optional tag, even with the default of p=none, I believe would further erode receiver confidence in DMARC policy statements, simply because publishing a record with no p= tag provides no evidence that the domain owner has given any thought whatsoever to their policy statement. On Thu, May 21, 2020 at 5:12 PM Scott Kitterman wrote: > Agreed. I don't think this is controversial. > > Also, I don't see a problem with making the p= tag optional (with an > inferred > value of None if not present). This is consistent with an existing SHOULD > in > RFC 7489 and appears to be broadly supported in existing implementations. > > I'd propose we close this ticket with the following resolution: > > The requirement that the v=DMARC1 tag be first will be retained. > > The requirement that the p= tag be second and the requirement that the p= > tag > is mandatory will be dropped. If the p= tag is not present, the implied > policy value is None. > > Scott K > > On Thursday, May 21, 2020 4:54:55 PM EDT Tim Wicinski wrote: > > (With no hats) > > > > I agree with John the v=DMARC1; is magic and MUST be first. Everything > > else can show up wherever. > > > > tim > > > > On Fri, May 15, 2020 at 9:09 PM John Levine wrote: > > > In article > > s9CQA7s1g@mail.gmail.com>, > > > > > > Murray S. Kucherawy wrote: > > > >It's been a while since the original discussion, but I can't remember > why > > > >the requirement is there in the first place. The only benefit I can > > > >think > > > >of is that having "v=" first lets you decide very quickly if you care > to > > > >continue, but the savings is really pretty small. > > > > > > The v=DMARC1; is a magic number that tells you whether it's worth > decoding > > > the > > > rest of the record. People put a lot of junk at tops of their zones, > some > > > of which is in k=v format and I would prefer not to try to decode > records > > > full > > > of junk to see of a v= tag is in there somewhere. > > > > > > Other than that I agree there is no reason to specify the order of > > > tags. > > > > > > -- > > > Regards, > > > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > > > Dummies", > > > 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 > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ee184505a6303326 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I disagree with the idea of making p=3D optional.

=
My perception is that DMARC has been advertised to the ecosystem= as a way for domain/brand owners to request specific=C2=A0treatment for ma= il that claims to be sent on behalf of a domain but that fails authenticati= on checks. It's couched as a request for treatment because we already s= ee frequent cases where the request is not honored, for example where a p= =3Dreject policy receives a disposition of quarantine; I've always beli= eved this sort of thing to be due to the mailbox providers not exactly trus= ting the domain owners to fully understand the ramifications of their polic= y statement, and rather than do what's asked, the receiver takes the sa= fer route to avoid the chance of a massive rejection of a legitimate mailin= g that had broken authentication for whatever reason.

<= div>Making p=3D an optional tag, even with the default of p=3Dnone, I belie= ve would further erode receiver confidence in DMARC policy statements, simp= ly because publishing a record with no p=3D tag provides no evidence that t= he domain owner has given any thought whatsoever to their policy statement.=
--0000000000005d800f05a6324a22-- From nobody Fri May 22 01:02:48 2020 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 E508D3A0A30 for ; Fri, 22 May 2020 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PN3xGdzHcRF9 for ; Fri, 22 May 2020 01:02:43 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 A5ABD3A0A13 for ; Fri, 22 May 2020 01:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1590134561; bh=aXRnlG7t+m7wHPZmrh+bKPVwQYhnvWrhguvfU6WVTHo=; l=835; h=To:References:From:Date:In-Reply-To; b=BJVnIbddfL/yKXRMty0JIIsxjwfz1dOGKBCwru5iStJv0na5MOIgqh4on/tn1LQZb mhSjmO7bA3vmImFk4mB5aK2T7SUNvjGZ8Pgtwy1CQnQ7q3HStuD5c+cDwwQoVvmtmP WaBRNAVNZuSMZfbq31WoSGkRX4VeiupwjzfIqYNOHkHBO2xd+yivsWXRbHGjG 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B0.000000005EC78721.00006B5C; Fri, 22 May 2020 10:02:41 +0200 To: dmarc@ietf.org References: <1784228.uJLO1Brz0r@localhost> From: Alessandro Vesely Message-ID: <7c29c378-56cf-d601-6a18-215fe2b502d2@tana.it> Date: Fri, 22 May 2020 10:02:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1784228.uJLO1Brz0r@localhost> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement 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, 22 May 2020 08:02:47 -0000 On Thu 21/May/2020 23:11:54 +0200 Scott Kitterman wrote: > Agreed. I don't think this is controversial. > > Also, I don't see a problem with making the p= tag optional (with an inferred > value of None if not present). This is consistent with an existing SHOULD in > RFC 7489 and appears to be broadly supported in existing implementations. > > I'd propose we close this ticket with the following resolution: > > The requirement that the v=DMARC1 tag be first will be retained. > > The requirement that the p= tag be second and the requirement that the p= tag > is mandatory will be dropped. If the p= tag is not present, the implied > policy value is None. Please, let's not forget to update the grammar, e.g. as proposed in https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8 Best Ale -- From nobody Fri May 29 09:11:20 2020 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 1F7C83A0D64; Fri, 29 May 2020 09:11:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: superuser@gmail.com, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159076867759.5710.7672845659191144980@ietfa.amsl.com> Date: Fri, 29 May 2020 09:11:18 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:11:18 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the dmarc working group. --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: Conflicts to Avoid: Chair Conflict: dnsop dprive extra jmap cbor cfrg kitten Technology Overlap: saag People who must be present: Alexey Melnikov Murray Kucherawy Tim Wicinski Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri May 29 09:13:18 2020 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 E0A003A0D73; Fri, 29 May 2020 09:13:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: superuser@gmail.com, dmarc-chairs@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159076879683.565.3448204572634894731@ietfa.amsl.com> Date: Fri, 29 May 2020 09:13:16 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Update to a Meeting Session Request for IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:13:17 -0000 An update to a meeting session request has just been submitted by Alexey Melnikov, a Chair of the dmarc working group. --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: None Conflicts to Avoid: Chair Conflict: dnsop dprive extra jmap cbor cfrg kitten Technology Overlap: saag uta People who must be present: Alexey Melnikov Murray Kucherawy Tim Wicinski Seth Blank Resources Requested: Special Requests: ---------------------------------------------------------