From nobody Thu Oct 1 00:00: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 1566A3A0B49 for ; Thu, 1 Oct 2020 00:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 5fSBxBz8pgca for ; Thu, 1 Oct 2020 00:00:04 -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 BFA993A0B48 for ; Thu, 1 Oct 2020 00:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1601535602; bh=4oxSXQuFKjXmTSSF5vrllKAiwYjJkPff6pFfwFvuHco=; l=816; h=To:References:From:Date:In-Reply-To; b=AtYLIVtqFPTF5aSz4+RUkY2UpFY/39AAS57KWWAj8L/NVAZ2qQlt+iJio49Wgm80M vMVyWBqqRNoVNqusLUKdupxPOTdZesG5KxUsa3nvGRAK5pl+Yt1CV73AkYXQiL0wqK i5T+IkCOtMn7lKs/WVKmfELOFO2LeiWk5hV+Kd6Kg63Cmo0BxEX1Scb/1yy+X 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.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F757E72.00002238; Thu, 01 Oct 2020 09:00:02 +0200 To: dmarc@ietf.org References: <11b4d6127cd748afa47c75387ed85c04@bayviewphysicians.com> From: Alessandro Vesely Message-ID: <1d365acc-0513-fe01-829f-9bc6356318f7@tana.it> Date: Thu, 1 Oct 2020 09:00:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <11b4d6127cd748afa47c75387ed85c04@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Weakend Signatures vs Experimental draft 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, 01 Oct 2020 07:00:06 -0000 On Wed 30/Sep/2020 12:27:26 +0200 Douglas E. Foster wrote: > Weakened signatures seem capable of getting to the desired goal more quickly > than the draft under consideration. > > Building on prior discussions of conditional signatures, I define a "weakened > signature" as: > one where SUBJECT is omitted from the header list, and l=0 is included to > exclude the body content.   The protected user-visible content becomes limited > to From, To, and Date headers. +1, I'd support adopting draft-levine-dkim-conditional or equivalent. I'd also support adopting some kind of DKIM Transformation. Note that the latter can be conceived as "not-so-strengthened signatures", in the sense that exotic fields (such as Sender:) are not signed. Similar benefits, less disadvantages. Best Ale -- From nobody Thu Oct 1 05:47:56 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 80C473A1010 for ; Thu, 1 Oct 2020 05:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 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, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 aoi7iNXK-VaE for ; Thu, 1 Oct 2020 05:47:53 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 1AAAA3A1004 for ; Thu, 1 Oct 2020 05:47:53 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id d6so4375911pfn.9 for ; Thu, 01 Oct 2020 05:47:53 -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=wqpeRf0ABvGcJTKQJQLG4qbLpq6SS2pRVRAFLAdxDTo=; b=I2Q0kjdkAwgL/YAn4t8k7lxzU1C5dB/kiaNMdVuJoLOpE82vXzTtlzVB5GrbetwakS 0byJCAyKGYJnKJsMcKO9aspwZQpnBsaoKxuwm8TF5+YnL4SwkW4zUtHh1WP7bht4lHx4 XdB0CgxvsUlVnYv2ErenjV3rBgvd2H5q4zchzV3TIGjxx6HjeoTPp2Bd6X0g5pO/QcrB J+dseHE6PhgI7jNCt2xQaAznivWLcgxL/oyD+MEaKqkr70jGun3njKlg7RuS5tCgNCXd G4oTCi3blTmzM3b1ZKs5h0wqP/lG3GmZf8uNM5LWp+klweqWtMcy48DS62iP8/hf0f1L rzhw== 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=wqpeRf0ABvGcJTKQJQLG4qbLpq6SS2pRVRAFLAdxDTo=; b=OdQWRLcb6R8gv9w2XIou9foAXv6zWq6m49ZHqmp9v3AP5gWfxufGv53eKUZ3yVH6gE vpje3oElMjh4ofdVHL8d5QsZYqTfj8W3hJG02TwJNNJHKTOJTnHui5saudewnHKT24u+ LLNHsvo2ZYI3s9X6L1p074GpyDkyHRGBemtkO9lC0/krRvOU8LQB8mXrZWhhucI1tXGv qYPRjwrg/GAO/eJrYo6eLgCSFWrFQ4UBzjLQ02hKYEo9dtDyEd5P+IYlfPC3n6PBtpjW MA/GYbFJjTrH9ZqfJTT3Wym4/+BhQZZy/P8nMgz5xDjiUwbkdHvKmXonDUZA5ehhObnW QuIg== X-Gm-Message-State: AOAM531J07PDzHJvsWZBTUInf6YJh7UxBl2VhF5czfaBQlQJvYVMf9hi WFLnvWthVLv59+hz5sl+NCzTAG7Jnfv0mQ== X-Google-Smtp-Source: ABdhPJyDfsg4FmkIud0X78xRSCqnNhDvvyldyiMvlrK2gBXnhw8WQhlo/uFE/yO7A+eF8p0fJvrIKA== X-Received: by 2002:aa7:9787:0:b029:13e:d13d:a05c with SMTP id o7-20020aa797870000b029013ed13da05cmr6806208pfp.34.1601556472289; Thu, 01 Oct 2020 05:47:52 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id q18sm6394901pfg.158.2020.10.01.05.47.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 05:47:51 -0700 (PDT) To: Seth Blank Cc: IETF DMARC WG References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> <5F73393D.4010805@isdg.net> <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net> <5F73B80F.2000402@isdg.net> <5F753B16.8050409@isdg.net> <5F754780.5080503@isdg.net> From: Dave Crocker Message-ID: Date: Thu, 1 Oct 2020 05:47:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field 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, 01 Oct 2020 12:47:55 -0000 On 9/30/2020 9:37 PM, Seth Blank wrote: > Hector, the chairs hear your frustration, thank you for not escalating > further, and would be happy to speak with you off list on the matter. Seth, Please reread the post you responded to.  It is, in fact, an escalation.  The tone you've set with your response  fully undermines the necesary firm, direct, disciplinary action. And yes, I intended this note to go to the list, since my private note to you apparently was not sufficient. There is a long-standing pattern of behavior here. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Thu Oct 1 06:32: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 8E8FE3A1053; Thu, 1 Oct 2020 06:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL3nns4sEi9r; Thu, 1 Oct 2020 06:32:30 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CBD3A103D; Thu, 1 Oct 2020 06:32:28 -0700 (PDT) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 091DZb6l009836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Oct 2020 06:35:37 -0700 From: Dave Crocker To: Seth Blank Cc: IETF DMARC WG References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> <5F73393D.4010805@isdg.net> <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net> <5F73B80F.2000402@isdg.net> <5F753B16.8050409@isdg.net> <5F754780.5080503@isdg.net> Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <17070425-6853-8c9d-6e6c-debebec7219a@dcrocker.net> Date: Thu, 1 Oct 2020 06:32:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field 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, 01 Oct 2020 13:32:34 -0000 On 9/30/2020 9:37 PM, Seth Blank wrote: > Hector, the chairs hear your frustration, thank you for not escalating > further, and would be happy to speak with you off list on the matter. Seth, Please reread the post you responded to.  It is, in fact, an escalation.  The tone you've set with your response  fully undermines the necesary firm, direct, disciplinary action. And yes, I intended this note to go to the list, since my private note to you apparently was not sufficient. There is a long-standing pattern of behavior here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 1 06:56:38 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 8CBE43A107E for ; Thu, 1 Oct 2020 06:56:36 -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 Z0U2JXRYBB6c for ; Thu, 1 Oct 2020 06:56:34 -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 79B7A3A107C for ; Thu, 1 Oct 2020 06:56:34 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id d4so2999056wmd.5 for ; Thu, 01 Oct 2020 06:56:34 -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=ULSXc47NM7Cam7vigrzRGoZ+vmBu7+eeLYbJsXvlVFI=; b=H+kWRS+rDIG6UGaBOqIrB7nAavEB506R/fcnzf5QoZAWNv6GOLbelLz/bZG9il/Xbh M0+wQR4b0b7GVSkpR0DXY7YFH2RCQnfCujpn+DsXDiGMZsZIRLgqp6gYb75r2h9hyhOU mD67+ECE884Mavo5ZeJkXDDLC7jS1klp+deUcA6xcTDz+uHVvk9FFc3G/Qr7NEgVnvFY Ll6iaKA5Cneat/Pe7DJq5QA0CpnTy1Fju0uFHm3oNTsJOEjsAbmYSm5u2OLarb3mFxU3 DnTUd33C7ENHqyH0jv2dTyW34EUfZBqUy0Q+Hf3C0C/37P0ICmPpOy79ZtdtqKANsu1h t6jQ== 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=ULSXc47NM7Cam7vigrzRGoZ+vmBu7+eeLYbJsXvlVFI=; b=rdU4mshRE+aGRRRtmjiQOChgfVZQqz6URXpO2v8caZjvrQg6TTPqzX1Fx1utV6cWSR nzPsex5kJHgezQ90OGwQhlKyS+3uHu89FTLlrBHpWgSxxkGUXq9mzgwoRMztWjZb+lEI NXgTrRSZd6vre5c5lVy471n03bLiPuJz1Fh15moKhk3tnXVXRAyviGHwkw9z2qVLH2rY mNirioZXvk9g6PGVMHCEO12Q1FkzYMhD7x+bfiE96tLfW2ldKESw00BsegiXebgQWLca q8aMMOOJ36ypRWoY2wLNlfLqfxPQYLXZ01OJk3yoqXtwlgdZZ5NqsKS2kbfByPkFohSm t6Sw== X-Gm-Message-State: AOAM533f/X7yuWDSpsEv14ODO7jp3UBDIutzbT+FMqBzfZ1o2/aTFdE1 mLUZvrHoFAM7HeU7EbM9OAxbauY6IrBn0Aq/BubaC+AKRjg= X-Google-Smtp-Source: ABdhPJxnSaatEsMiiYZ6+zzQsRDgs7896MQDVa+/cS0jCiM2KzXGbGUeMIEUMnvUDPOeX2TynjWE6saGVEakO0MHq0Y= X-Received: by 2002:a1c:7d4d:: with SMTP id y74mr113104wmc.73.1601560592598; Thu, 01 Oct 2020 06:56:32 -0700 (PDT) MIME-Version: 1.0 References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> <5F73393D.4010805@isdg.net> <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net> <5F73B80F.2000402@isdg.net> <5F753B16.8050409@isdg.net> <5F754780.5080503@isdg.net> <17070425-6853-8c9d-6e6c-debebec7219a@dcrocker.net> In-Reply-To: <17070425-6853-8c9d-6e6c-debebec7219a@dcrocker.net> From: Seth Blank Date: Thu, 1 Oct 2020 06:56:21 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003564bd05b09c626c" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field 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, 01 Oct 2020 13:56:37 -0000 --0000000000003564bd05b09c626c Content-Type: text/plain; charset="UTF-8" Dave, disengage from this thread. Continuing to publicly attack a participant who's been asked to disengage and so far has done so is not acceptable. This is a formal warning. The chairs and ADs will be in touch. Feel free to reach out to us directly in the meantime if you so wish. Seth, as Chair On Thu, Oct 1, 2020 at 6:32 AM Dave Crocker wrote: > On 9/30/2020 9:37 PM, Seth Blank wrote: > > Hector, the chairs hear your frustration, thank you for not escalating > > further, and would be happy to speak with you off list on the matter. > > > Seth, > > Please reread the post you responded to. It is, in fact, an > escalation. The tone you've set with your response fully undermines > the necesary firm, direct, disciplinary action. > > And yes, I intended this note to go to the list, since my private note > to you apparently was not sufficient. > > There is a long-standing pattern of behavior here. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- *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. --0000000000003564bd05b09c626c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave, disengage from this thread. Continuing to publicly a= ttack a participant who's been asked to disengage and so far has done s= o is not acceptable. This is a formal warning.

The chair= s and ADs will be in touch. Feel free to reach out to us directly in the me= antime if you so wish.

Seth, as Chair
<= br>
On Thu,= Oct 1, 2020 at 6:32 AM Dave Crocker <dhc@dcrocker.net> wrote:
On 9/30/2020 9:37 PM, Seth Blank wrote:
> Hector, the chairs hear your frustration, thank you for not escalating=
> further, and would be happy to speak with you off list on the matter.<= br>

Seth,

Please reread the post you responded to.=C2=A0 It is, in fact, an
escalation.=C2=A0 The tone you've set with your response=C2=A0 fully un= dermines
the necesary firm, direct, disciplinary action.

And yes, I intended this note to go to the list, since my private note
to you apparently was not sufficient.

There is a long-standing pattern of behavior here.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



--

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


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion 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 include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--0000000000003564bd05b09c626c-- From nobody Thu Oct 1 06:58: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 AB22F3A1087 for ; Thu, 1 Oct 2020 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=bbiw.net header.b=MbuzHiAK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KvH+ROrW 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 cX_xkrlymq45 for ; Thu, 1 Oct 2020 06:58:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D7D3A1092 for ; Thu, 1 Oct 2020 06:58:35 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 46EA65C01C6; Thu, 1 Oct 2020 09:58:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 01 Oct 2020 09:58:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=1 7fKC8HmVZOPQgPq4zSDNwZso+JPqTrQfyi+cCPlatk=; b=MbuzHiAK45ujJzS3a pQlHQWfep7uaJtsTEe9EX9DBNq9IdEtSVhgPLOVNbyetY1EtbEmxXjkpjDmzSNsQ OcVnvYOXYcSRMx/RzdcRS+ZWta6YCOCPOGqxhEbloCtLBxSb9PAAy3QeZSwFx21M XBA1Y73WGaOgf3/GEahIO3zBTeCBwD6qu0nNeNQvWcPSolwCv2YI+Zp2rdg4GnQy cRG9WMqQW9ouXoWTiQ2cymGOLzBx9z9ydX1xLtLbO46H7CkTjS9UhGj7ir+0f9by qaNQiM8DQUpx1H+4MPCnxWA7Mr+ZsfjmnRE3zuthrstHB2OWLdK9tyndKBTmJT5r 7lYsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=17fKC8HmVZOPQgPq4zSDNwZso+JPqTrQfyi+cCPla tk=; b=KvH+ROrW4xeuyHsBQNAFqgOxfPcUnFdNWdlPqoCEqI/ly/5KeC2rH0ZF9 +e1q0rHw7lvycj0ExteO2yfT1L95OWy3+YpZPklVrhF02/XcSZubhFPEWnTIUIkJ dlOW6MWJuwszveuXRSSV3DhtIbbuc1SlhFtn0oUXqZnaLzCcNFpSbBnDn7pFaF8i oP/LBtrajiYB70BvjpLrNqSSZzW/k6Yj3jpNzVSWwjbon5cDgD+D2CTAW1s0Xwk3 h+U+R/eJO04hZxJR/J05jpqh2cEs/z0a63KXTEPpxhQJPPKn4z6gNZvJ9eYDZOC3 JnU1R86BHGrEjdqOe9nNxQ42bLWgQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepffgrvhgv ucevrhhotghkvghruceouggtrhhotghkvghrsegssghifidrnhgvtheqnecuggftrfgrth htvghrnhepiefhvdeugfejkefftdfhleevleetveefgeetfeegteejjedujeeugeehfeeh gfeinecuffhomhgrihhnpegssghifidrnhgvthenucfkphepvdegrddufedtrdeivddrud ekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu tghrohgtkhgvrhessggsihifrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D2A33064674; Thu, 1 Oct 2020 09:58:34 -0400 (EDT) To: Seth Blank Cc: IETF DMARC WG References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> <5F73393D.4010805@isdg.net> <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net> <5F73B80F.2000402@isdg.net> <5F753B16.8050409@isdg.net> <5F754780.5080503@isdg.net> <17070425-6853-8c9d-6e6c-debebec7219a@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 1 Oct 2020 06:58:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field 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, 01 Oct 2020 13:58:40 -0000 On 10/1/2020 6:56 AM, Seth Blank wrote: > and so far has done so is not acceptable. He didn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 4 03:00: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 178F93A126B for ; Sun, 4 Oct 2020 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE_DDhV9VwMY for ; Sun, 4 Oct 2020 03:00:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6783A1395 for ; Sun, 4 Oct 2020 03:00:08 -0700 (PDT) Received: (qmail 80179 invoked by uid 100); 4 Oct 2020 10:00:06 -0000 Date: 4 Oct 2020 09:59:43 -0000 Message-ID: <20201004095943.80171.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 4 06:00:06 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 10:00:11 -0000 Count | Bytes | Who ------------+----------------+------- 13 (20.3%) | 73062 (14.6%) | Dave Crocker 11 (17.2%) | 141915 (28.3%) | Seth Blank 7 (10.9%) | 37199 ( 7.4%) | Alessandro Vesely 6 ( 9.4%) | 35289 ( 7.0%) | Scott Kitterman 5 ( 7.8%) | 36424 ( 7.3%) | Dave Crocker 5 ( 7.8%) | 32891 ( 6.6%) | Kurt Andersen (b) 4 ( 6.2%) | 42759 ( 8.5%) | Brandon Long 4 ( 6.2%) | 30047 ( 6.0%) | Hector Santos 2 ( 3.1%) | 24061 ( 4.8%) | Douglas E. Foster 2 ( 3.1%) | 15790 ( 3.2%) | Dotzero 2 ( 3.1%) | 15742 ( 3.1%) | Dave Crocker 2 ( 3.1%) | 8459 ( 1.7%) | John Levine 1 ( 1.6%) | 7434 ( 1.5%) | Murray S. Kucherawy From nobody Mon Oct 5 00:22: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 8E9673A0E04 for ; Mon, 5 Oct 2020 00:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 TjyHp8quiztS for ; Mon, 5 Oct 2020 00:22:35 -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 786823A07F0 for ; Mon, 5 Oct 2020 00:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1601882553; bh=ftNazv4pSwcji2bCza26Ex5VtjIB/HuVAR/j0sWM42A=; l=481; h=To:References:From:Date:In-Reply-To; b=AkfR6/4UC7/NVTSroAUI5+U6gJ7cNNGblhOVL83ihvUnDOmScLazDra341XRYn/Gv UngeOHfrcRM1lcY4IPFWPF3n7x8n0WTXEPwvQ9qxU03gV4eG0u9pZl8gJetd6XWMHj 294Tvz63xnTE9YVm2frv7YlahkhvhmOTqAT3w6EE1r4RdkwQUBnE47+emogyW 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.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.000000005F7AC9B8.0000306E; Mon, 05 Oct 2020 09:22:32 +0200 To: dmarc@ietf.org References: <20201004095943.80171.qmail@submit.iecc.com> From: Alessandro Vesely Message-ID: Date: Mon, 5 Oct 2020 09:22:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201004095943.80171.qmail@submit.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 4 06:00:06 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 07:22:39 -0000 On Sun 04/Oct/2020 11:59:43 +0200 John Levine wrote: > Count | Bytes | Who > ------------+----------------+------- > 13 (20.3%) | 73062 (14.6%) | Dave Crocker > 5 ( 7.8%) | 36424 ( 7.3%) | Dave Crocker > 2 ( 3.1%) | 15742 ( 3.1%) | Dave Crocker ------------+----------------+------- 20 (31.2%) | 125228 (25.0%) | Dave Crocker Are (signed) display names amenable to any programmatic usage? Best Ale -- From nobody Mon Oct 5 17:21: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 3CF4F3A142A for ; Mon, 5 Oct 2020 17:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.213, 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=wisc.edu 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 HxZ8e17Wre3B for ; Mon, 5 Oct 2020 17:21:36 -0700 (PDT) Received: from wmauth1.doit.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (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 AEB943A1427 for ; Mon, 5 Oct 2020 17:21:36 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2055.outbound.protection.outlook.com [104.47.38.55]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QHR00KIQ6KG7N40@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 05 Oct 2020 18:57:53 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-1, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.10.5.235418, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.9.22.5770001, SenderIP=[104.47.38.55] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zl7hp+R+FJkSisBZ4Pw0NmTyG9X2XxXz+55mxQOMi7X4C55aTRlZH+Z/dbdHVsTvXfGD5VH7se3A0eFomGK9hjdKFbGtlK3qlDpbTf4ZQO7ft6IRCbIsTJub6N4gOXMJ0m9AMEAZP6sjikIoVOoUN1a2Y73hFTNq0MaXCW2RepYavq9+uWv3gM6SWAlYEPkbkWoMz6QTeG8DR2JSIPgcEpOaeBcAXlT4HgLHPsgvjSwB+gZsxFT/eFn8A0Uz3KWqE4ywtHqDoLGVLG5e0NM9uNwU7yNvKg2GqzFhnM4q4lEhcPgS4h+2ZO1RKpYfJmJCEHSD5CFPeL7SHEP4YoxPOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oh4mQjthNiAQD0uBVI0uf3vFf0GyYCKdvZzdeOXO7J0=; b=euYeQdsN8QqN6aQl+X5nLHd+drb8qSV1QkyNB0SkqiDDqzkTFPDFYt2U4lswfOHuI0sKxM1KVMpXY3XEy8YbxdvBSc64CWE8uK5sJk9EtS0mSkmYB4cDIoEpg8Lk5aCKT2Ltka7TAJIDqmZ3G541nVz5dA2OPBpAs6RJEdfgZ8L8hAm+nGRgUZpeIIPLSNOaNl95vEff2fyStmCl5FL5JomB+fRd7O2aEdLo+ZHbuySZwRPYnH11KnX93PVy9qDcEZoCOxm7tGEYR9AEc0jg8m23KbV1u7oKg4vx9weFyF//oLzKB8oVOlq/JlCufJG+F5uT6t3aH8plHVWFS8GN8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oh4mQjthNiAQD0uBVI0uf3vFf0GyYCKdvZzdeOXO7J0=; b=hEhyR0uHJj8aYPIUSeEi1lIk3qwBN4eD+n9GZYKs2jzXkprQeUcWdnyiNekyiHKNgBKO/o9OKnjucdU/7pYDKpazEoTanNGtt0lMKslrUlPdBQ62x/cfLInRVN1zup1ZQbN3LwInf2RUl58VSkGVGRDBcBEconTK0J0cpa5qtE8= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB5066.namprd06.prod.outlook.com (2603:10b6:5:59::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.42; Mon, 5 Oct 2020 23:57:50 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::3140:5114:c860:9a7b]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::3140:5114:c860:9a7b%5]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 23:57:50 +0000 To: dmarc@ietf.org References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> From: Jesse Thompson Message-id: Date: Mon, 5 Oct 2020 18:57:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR04CA0020.namprd04.prod.outlook.com (2603:10b6:610:52::30) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR04CA0020.namprd04.prod.outlook.com (2603:10b6:610:52::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38 via Frontend Transport; Mon, 5 Oct 2020 23:57:50 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f3bec13b-8009-4277-e87d-08d8698a778c X-MS-TrafficTypeDiagnostic: DM6PR06MB5066: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: duzyV01Rsw2BLJdjVAzy+32R8y+tCA1MdiTMVVZ5JBax56Dje8S7g+bIfiHo5RV6Fw1XGUOr5IRxhfJLtV//DIbbb9K2p1Nyc+vMl3sXa0yFuE0Ahc73Y/yX7jgM7vuvsOGAnweWdga4yX16iD6U0NfWJc9TKIBdur1zzC1bB9uZf+oju/0JunsPfOaBIsg0KKphoR9qkFqPhcWzReiGst4R1l2TSPUZUsD0tA9eu7gBEeRNg6XNqh8i/tGr9dTOys1hIZ2UgHL0LXJY7x7PQ+0Gi6MYRA/BncPFnhzNID1kf1a0bslm8axBWeOx8CtPM057nbuMZzNUj7notj2OTQWCrPNyH0kJvjF5/J+yE7oq6ZRyzyqnjNTeIHK8nAMz X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(39860400002)(396003)(66476007)(66556008)(8676002)(6486002)(86362001)(5660300002)(31686004)(316002)(16576012)(956004)(66946007)(786003)(26005)(2616005)(83380400001)(75432002)(8936002)(478600001)(44832011)(36756003)(53546011)(186003)(16526019)(31696002)(2906002)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 2ZLS/wYpETTBUNnEEGpe39WfTxJM5vtzk8Khs3M8B3XPbEoQZJQtRRvy0U22rg3GqfC96g72965zW/e3v+Aw7Co/ZdwH6pdMMdPBTsmmgE6lhFT33eztNdPS4f3eI4loMFpGqRUka77lX/H2GFdVQeAszX3CovMscaw44x1C4IS2mgCA7VB1lFduJszmjisUgHRA3rYF+xvBmGG7xiNpWjx9cXr2KNDuNeEBI5xlsqXW4Q5Znrofm4kC4YisIB+92I7+fQxjkUEFPAP06Azfa8Kz+LdGFl+wsyUTVsw/jJNttGWnsRB6+Kz5BToX5D78k4QxPp8qA0IDmvvE9af4wng/3NIIOD+B9iEsTcsKTZnUrLzViqcwFfgOd9mPyal9p0jmdWDCf8ifS1zsY77ylqj0scmas64P9XZ5zxv3XoR+7Y/EdyxzhkWn7abCSCKK9JjphA2OJRQOtR3opjZnAKkFBxmXTXtNYm90P8g0upxNrTihYXOTh60IPcItMGo8EE5AAM2+xNtUWwyHLLapUrUV5bJJeIHsyhneYe4VH7pB9ZCVyWWaYtvIFhgPdgt8lxSvZIKcHdUkiQgzfs2HYPwtJaaVuYw0XRA8mdEpFMzme9jy0Py9+Xs35XttC8G3BXDv+0YtOw939IV1h2FB5w== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: f3bec13b-8009-4277-e87d-08d8698a778c X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2020 23:57:50.6890 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y7mwyxC8PEglraDCKMBfGkbH9OH20Org9QdWluTNMpIZkUcHvPTII38ol3GUsLI/AsIhdBkeK8Nhyt6TbB12yg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5066 Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 00:21:38 -0000 On 9/28/20 10:35 AM, Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman > wrote: > > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed.  Maybe it would help if someone who takes the latter view would > explain what they think RFC 7489, Section 6.6.2, Step 6 is for: > > >    6.  Apply policy.  Emails that fail the DMARC mechanism check are > >        disposed of in accordance with the discovered DMARC policy of the > >        Domain Owner.  See Section 6.3 for details. > > I don't think that says "then toss the results into your classifier". > > > You completely ignored section 6.7 (Policy Enforcement Considerations) which states: > >> Final disposition of a message is always a matter of local policy. > > Local policy could be considered "the output of some classifier" or other mechanics left to the invention of the receiver. > > This is a part of the documented DMARC spec, not a change. Reading this thread, it comes to my mind that the "fundamental disconnect" that John raises is partly caused by an externalized factor: the shift to cloud mailbox hosting. The roles, responsibilities, and assumptions have changed. The receiver, who is now a customer of an ISP, does not have the ability to "invent mechanics" because the tools aren't provided by the ISP. The ISP, of course, has a good reason to K.I.S.S. for support. It means that the ISP takes over responsibility for local policy mechanics to a greater extent. Falling short of providing their customers a platform to invent mechanics the ISP will just implement the none|reject|quarantine mechanics and say they "support DMARC". Even if the ISP has proprietary local policy mechanics that they apply to all of their customers' inbound mail, they aren't likely to document it in great detail or offer many exemptions. It's a black box. e.g. I find it hard to imagine that an ISP would have the willingness to exempt a boutique MLM for all of their customers, so ARC, in and of itself, doesn't really help MLMs move away from From munging. Does it make sense to suggest that in order for ARC to succeed, then ISPs need to offer a way for their customers to define their trusted intermediaries? What if the ISP chooses not to offer that? Do they "support ARC" in a meaningful way? For the "filtering signal" viewpoint to succeed, I would ask: is there a need to define some local policy mechanics into the spec so that the ISP can be held to account by customers to "fully support DMARC". If the ISP offers no adequate mechanics to do signal filtering, then that ISP's hosted receivers cannot realistically support DMARC based on the assumption baked into DMARC that receivers can and will implement override mechanics. The roles have changed, which has diluted the "filtering signal's" value mostly to the ISPs, and the benefit to receivers is metered by the extent to which the ISPs are willing to build a platform for their customers to invent mechanics. If the shift to cloud is incompatible with "filtering signal" mechanics for local policy overrides, is DMARC's only value left to receivers "what users see" and the simplistic none|quarantine|fail mechanics, as defined? Jesse From nobody Mon Oct 5 19:14: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 CEB473A0EEC for ; Mon, 5 Oct 2020 19:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 KFAi9NqykCiC for ; Mon, 5 Oct 2020 19:13:58 -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 32C4B3A0EF2 for ; Mon, 5 Oct 2020 19:13:57 -0700 (PDT) X-ASG-Debug-ID: 1601950432-11fa31207327b30001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id bSd59xRhuuV70lOO (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 05 Oct 2020 22:13:52 -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=Be4sBQCnrf53JVxiCc5R5KBDZ9Ny2LCKv8mvZzfJq8g=; b=BADP3IYi3pdCIQxsrFwV6FTJz1RUA9ds7QBN3PqQvYHkKHzjEm5WbIagCIlSGiPCV krNt1LNtLmbAdm5ijbGFf5b1qOMFXqNguw8ujl+0oQZMcYQWcOHMoxh/7lpEgW7It wAogYrFSF8nBP3l4BTCagoUS7CrgsM9/bbHIDffKM= From: "Douglas E. Foster" To: Date: Mon, 5 Oct 2020 22:13:45 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field Reply-To: fosterd@bayviewphysicians.com Message-ID: <8bf5fc0363e1493890fb7496a8a35ceb@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=307e52deb1d14fcf850587d110d99d48 In-Reply-To: References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> X-Exim-Id: 8bf5fc0363e1493890fb7496a8a35ceb X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1601950432 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: 13942 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.85100 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 02:14:01 -0000 This is a multipart message in MIME format. --307e52deb1d14fcf850587d110d99d48 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From Rewrite ------------------ The need for From rewrite was predictable, based on the experience with SPF= . It should have been included in the original specification. SPF says that "The last domain to handle this message must authenticate its= elf." If the message is sent directly, this is achieved by the domain own= er's server identity, SMTP MailFrom identity, and SPF policy. If the mess= age is relayed for any reason, the SMTP MailFrom must be rewritten while al= so protecting the Return-Path. SRS is the most common implementation for = doing this, but there are other possibilities. DMARC says that "The last domain to alter this message must authenticate it= self." If the message is sent without modification, the domain owner's DK= IM signature authenticates the message whether it is sent directly or relay= ed. If it is altered in transit by a mediator, the mediator must rewrite = the From address while protecting the recipient's perception of authorship = and also protecting the Reply-To. The most common method seems to be use= r=3Ddomain@listdomain, but there are other possibilities, including my sugg= estion of useralias.listname@listdomain. These requirements are inevitable consequences of the criterion being impos= ed. So an important question is whether the end-user's dislike of From r= ewrite is sufficient reason to ignore the security benefits that DMARC prov= ides. Exception Mechanisms ------------------------------- Both SPF and DMARC are subject to configuration errors by the domain owner,= as well as abuse by "essential" sources of incoming mail. Therefore imple= mentations SHOULD provide an exception mechanism which does not create side= -effect risks. I have major grievance with commercial products that do no= t provide safe and sufficient exception mechanisms. I would like the speci= fication to document exception handling as a requirement. ISP Limitations -------------------- I am told that Office365 allows clients to place their own email filter in = front of the one provided by Microsoft. I don't know whether that solves t= he black box problem that Jesse raises. Consensus --------------- I thought the group had informally agreed that none of the alternative auth= entication mechanisms had a reasonable expectation of widespread implementa= tion. If so, the discussion comes down to those who believe DMARC is a di= saster that needs to be undone, and those who believe that DMARC is a good = thing that needs to be formalized. I see no available path to consensus b= etween those two positions. Doug Foster ---------------------------------------- From: jesse.thompson=3D40wisc.edu@dmarc.ietf.org Sent: 10/5/20 8:22 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sende= r Header Field On 9/28/20 10:35 AM, Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman > wrote: > > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed. Maybe it would help if someone who takes the latter view would > explain what they think RFC 7489, Section 6.6.2, Step 6 is for: > > > 6. Apply policy. Emails that fail the DMARC mechanism check are > > disposed of in accordance with the discovered DMARC policy of th= e > > Domain Owner. See Section 6.3 for details. > > I don't think that says "then toss the results into your classifier". > > > You completely ignored section 6.7 (Policy Enforcement Considerations) wh= ich states: > >> Final disposition of a message is always a matter of local policy. > > Local policy could be considered "the output of some classifier" or other= mechanics left to the invention of the receiver. > > This is a part of the documented DMARC spec, not a change. Reading this thread, it comes to my mind that the "fundamental disconnect" = that John raises is partly caused by an externalized factor: the shift to c= loud mailbox hosting. The roles, responsibilities, and assumptions have cha= nged. The receiver, who is now a customer of an ISP, does not have the ability to= "invent mechanics" because the tools aren't provided by the ISP. The ISP, = of course, has a good reason to K.I.S.S. for support. It means that the ISP takes over responsibility for local policy mechanics = to a greater extent. Falling short of providing their customers a platform = to invent mechanics the ISP will just implement the none|reject|quarantine = mechanics and say they "support DMARC". Even if the ISP has proprietary local policy mechanics that they apply to a= ll of their customers' inbound mail, they aren't likely to document it in g= reat detail or offer many exemptions. It's a black box. e.g. I find it hard to imagine that an ISP would have the willingness to ex= empt a boutique MLM for all of their customers, so ARC, in and of itself, d= oesn't really help MLMs move away from From munging. Does it make sense to = suggest that in order for ARC to succeed, then ISPs need to offer a way for= their customers to define their trusted intermediaries=3F What if the ISP = chooses not to offer that=3F Do they "support ARC" in a meaningful way=3F For the "filtering signal" viewpoint to succeed, I would ask: is there a ne= ed to define some local policy mechanics into the spec so that the ISP can = be held to account by customers to "fully support DMARC". If the ISP offers= no adequate mechanics to do signal filtering, then that ISP's hosted recei= vers cannot realistically support DMARC based on the assumption baked into = DMARC that receivers can and will implement override mechanics. The roles have changed, which has diluted the "filtering signal's" value mo= stly to the ISPs, and the benefit to receivers is metered by the extent to = which the ISPs are willing to build a platform for their customers to inven= t mechanics. If the shift to cloud is incompatible with "filtering signal" mechanics for= local policy overrides, is DMARC's only value left to receivers "what user= s see" and the simplistic none|quarantine|fail mechanics, as defined=3F Jesse =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --307e52deb1d14fcf850587d110d99d48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From Rewrite
=
------------------
The need for From rewrite was predictable= , based on the experience with SPF.  It should have been included in t= he original specification.

SPF says that "The last= domain to handle this message must authenticate itself."   If the mes= sage is sent directly, this is achieved by the domain owner's server identi= ty, SMTP MailFrom identity, and SPF policy.   If the message is relaye= d for any reason, the SMTP MailFrom must be rewritten while also protecting= the Return-Path.   SRS is the most common implementation for doing th= is, but there are other possibilities.

DMARC says = that "The last domain to alter this message must authenticate itself." &nbs= p; If the message is sent without modification, the domain owner's DKIM sig= nature authenticates the message whether it is sent directly or relayed. &n= bsp; If it is altered in transit by a mediator, the mediator must rewrite t= he From address while protecting the recipient's perception of authorship a= nd also protecting the Reply-To.    The most common method seems = to be user=3Ddomain@listdomain, but there are other possibilities, includin= g my suggestion of useralias.listname@listdomain.

= These requirements are inevitable consequences of the criterion being impos= ed.    So an important question is whether the end-user's dislike= of From rewrite is sufficient reason to ignore the security benefits that = DMARC provides.


Exception Mechanism= s
-------------------------------
Both SPF and DMARC ar= e subject to configuration errors by the domain owner, as well as abuse by = "essential" sources of incoming mail.  Therefore implementations SHOUL= D provide an exception mechanism which does not create side-effect risks. &= nbsp; I have major grievance with commercial products that do not provide s= afe and sufficient exception mechanisms.  I would like the specificati= on to document exception handling as a requirement.


ISP Limitations
--------------------
I= am told that Office365 allows clients to place their own email filter in f= ront of the one provided by Microsoft.  I don't know whether that solv= es the black box problem that Jesse raises. 


Consensus
---= ------------
I thought the grou= p had informally agreed that none of the alternative authentication mechani= sms had a reasonable expectation of widespread implementation.   If so= , the discussion comes down to those who believe DMARC is a disaster that n= eeds to be undone, and those who believe that DMARC is a good thing that ne= eds to be formalized.   I see no available path to consensus between t= hose two positions.

<= div style=3D"box-sizing: border-box;">Doug Foster

From: jesse.thompson=3D40wisc.edu@dmarc.ietf.org
Sent= : 10/5/20 8:22 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RF= C5322.Sender Header Field

On 9/28/20 10:35 = AM, Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 A= M Scott Kitterman <sklist@kitterman.com <mailto:sklist@kitterman.com&= gt;> wrote:
>
> On Sunday, September 27, 2020 = 1:16:11 PM EDT John Levine wrote:
>
> Agreed.&nbs= p; Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:=
>
> >    6.  Apply policy.  Ema= ils that fail the DMARC mechanism check are
> >   = ;     disposed of in accordance with the discovered DMARC policy = of the
> >        Domain Owner.  S= ee Section 6.3 for details.
>
> I don't think tha= t says "then toss the results into your classifier".
>
>
> You completely ignored section 6.7 (Policy Enforceme= nt Considerations) which states:
>
>> Final di= sposition of a message is always a matter of local policy.
>
> Local policy could be considered "the output of some classifi= er" or other mechanics left to the invention of the receiver.
>= ;
> This is a part of the documented DMARC spec, not a change.=

Reading this thread, it comes to my mind that the= "fundamental disconnect" that John raises is partly caused by an externali= zed factor: the shift to cloud mailbox hosting. The roles, responsibilities= , and assumptions have changed.

The receiver, who = is now a customer of an ISP, does not have the ability to "invent mechanics= " because the tools aren't provided by the ISP. The ISP, of course, has a g= ood reason to K.I.S.S. for support.

It means that = the ISP takes over responsibility for local policy mechanics to a greater e= xtent. Falling short of providing their customers a platform to invent mech= anics the ISP will just implement the none|reject|quarantine mechanics and = say they "support DMARC".

Even if the ISP has prop= rietary local policy mechanics that they apply to all of their customers' i= nbound mail, they aren't likely to document it in great detail or offer man= y exemptions. It's a black box.

e.g. I find it har= d to imagine that an ISP would have the willingness to exempt a boutique ML= M for all of their customers, so ARC, in and of itself, doesn't really help= MLMs move away from From munging. Does it make sense to suggest that in or= der for ARC to succeed, then ISPs need to offer a way for their customers t= o define their trusted intermediaries=3F What if the ISP chooses not to off= er that=3F Do they "support ARC" in a meaningful way=3F

For the "filtering signal" viewpoint to succeed, I would ask: is ther= e a need to define some local policy mechanics into the spec so that the IS= P can be held to account by customers to "fully support DMARC". If the ISP = offers no adequate mechanics to do signal filtering, then that ISP's hosted= receivers cannot realistically support DMARC based on the assumption baked= into DMARC that receivers can and will implement override mechanics.
=

The roles have changed, which has diluted the "filterin= g signal's" value mostly to the ISPs, and the benefit to receivers is meter= ed by the extent to which the ISPs are willing to build a platform for thei= r customers to invent mechanics.

If the shift to c= loud is incompatible with "filtering signal" mechanics for local policy ove= rrides, is DMARC's only value left to receivers "what users see" and the si= mplistic none|quarantine|fail mechanics, as defined=3F

=
Jesse

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
dmarc mailing list
dmarc@ie= tf.org
--307e52deb1d14fcf850587d110d99d48-- From nobody Tue Oct 6 00:24: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 DD2D23A1207 for ; Tue, 6 Oct 2020 00:24:31 -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_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 B9uOVcuBisnV for ; Tue, 6 Oct 2020 00:24:30 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 2277F3A12F6 for ; Tue, 6 Oct 2020 00:23:38 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id DB1426A275; Tue, 6 Oct 2020 09:23:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1601969016; bh=QSgmypbgk3CEgychbnfEjSypnzgzhA6/E61cbSSmv28=; h=Date:From:To:In-Reply-To:References:Subject:From; b=8yvya3adbpCGCbUSW9UogzpeDh05I8z8J/EpcSMGX+o6sYIJGrM48BBwCdp0/kmZI KshRACuf1sy3YmzWvoaDVKJMtOrDDV2dvhHtII7HLdfi/kpZ7twoZ9az422pLBPqqh YN8BixncZc3QC9hmFtcgXA57wNfj4vLLKsy71XiZmArjA7MDB7OGqhalaFYhnfez8R YfRJZxGsLKzwnjaBtPP8Xr9cd1xtLFQ8puudz/laT+nH2E/MU5vTv8Xl4E4WXaKIAa 7YdtJmNJjjWuZyMXRdWsRY/vcFnydCKBNHN+AyJb3FlBGdyQsSSlNWUyvK9KcaCoY4 55EO6O6r9wyMQ== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id CB40A3C0385; Tue, 6 Oct 2020 09:23:36 +0200 (CEST) Date: Tue, 6 Oct 2020 09:23:36 +0200 (CEST) From: Vittorio Bertola To: Jesse Thompson , dmarc@ietf.org Message-ID: <1265372281.9984.1601969016735@appsuite-gw1.open-xchange.com> In-Reply-To: References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 07:24:32 -0000 > Il 06/10/2020 01:57 Jesse Thompson ha scritto: > > e.g. I find it hard to imagine that an ISP would have the willingness to exempt a boutique MLM for all of their customers, so ARC, in and of itself, doesn't really help MLMs move away from From munging. Does it make sense to suggest that in order for ARC to succeed, then ISPs need to offer a way for their customers to define their trusted intermediaries? What if the ISP chooses not to offer that? Do they "support ARC" in a meaningful way? >From a policy standpoint, it is troubling to imagine that each email system would define their own list of trusted ARC intermediaries. This is a recipe for centralization and oligopoly, as most people would just create a shortlist of a few well known big intermediaries, and any smaller entity trying to compete with them (including non-profit operations, community servers, self-hosted mailing lists etc) would be at a serious disadvantage. There is also the problem of keeping these lists up to date once installed. It would be much better if there were a few professional/community efforts to build reliable and complete lists of good and bad ARC intermediaries, like for spam. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Oct 6 08:20: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 5D8373A0B0B for ; Tue, 6 Oct 2020 08:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FFsRmJRp; dkim=pass (2048-bit key) header.d=taugh.com header.b=L0hxv2ww 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 k6Ng0FdNUpNj for ; Tue, 6 Oct 2020 08:20:45 -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 BB8133A0B01 for ; Tue, 6 Oct 2020 08:20:44 -0700 (PDT) Received: (qmail 99625 invoked from network); 6 Oct 2020 15:20:42 -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=18527.5f7c8b4a.k2010; bh=HTahy6FCAu6CKXV/l2HZhkPquU0WELIQVn5eUfsc7mw=; b=FFsRmJRp46/D6iHX1N5D82DneM/mmmKAgyFUCAKnZp1rC8A6o89ORFJ1eYSjwqUaK31Ic8IpfMmOU5xTa6A2Rbc7CAIo5CHSuG6KabITsJ6ev60urM1JY7xJFExvgkw7hFlw/DiGWnC9OxShUxBJ/3BUrKnE4WjHNH7/sMkk5zC6+Ghy38A/K7YbGUH++UposDF0Xwrk+NCNFhvAYpQ2U/14Jtap6q8bFCFIEqTd4HmDG6Vokr9xaO6gqPNgC+ScqOYwKkdn01eP2p3jQasTv0SAsRWgCY6GmD2BpALT+luewPU3GEGJ3vrfnOz65/Uqd5ZFl2OHYJNdcJ3aylOKUw== 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=18527.5f7c8b4a.k2010; bh=HTahy6FCAu6CKXV/l2HZhkPquU0WELIQVn5eUfsc7mw=; b=L0hxv2wwrl4a6FidjTvck5LuG+In2bcIFSUXm8vCF9gNABlsVd0HwAlB9/izUOBzoorwaFKn05/1mhhH9YP/XTNB+77R/ihVhZoSExEh8jD4IAJ8vrG/uBATh8IqVgI040BNeV7DmMimPUQcWMcv13QhV6k8TaAXH2ZML6uumI9GXAZJ6+w+opG/jO33e3OXS3m89tZaBBS8sov4QfOTK7N+ev1kGG1afjV1JCODjm9oCqGHRqm7+xhw3ZYyjgK7uBCGQfj65aCkt6YoHyuwdHBSK/3RK8iEVs0iuybuQTdNkTGaH6USB+sC6sE0sJaL4RVS0ycn/Y+y3NJQgNUaow== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Oct 2020 15:20:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 9A2BC23014C8; Tue, 6 Oct 2020 11:20:41 -0400 (EDT) Date: 6 Oct 2020 11:20:41 -0400 Message-Id: <20201006152041.9A2BC23014C8@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vittorio.bertola@open-xchange.com In-Reply-To: <1265372281.9984.1601969016735@appsuite-gw1.open-xchange.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] ARC usage, was Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 15:20:46 -0000 In article <1265372281.9984.1601969016735@appsuite-gw1.open-xchange.com> you write: > It would be much better if there were a few professional/community efforts to build reliable and complete lists of good > and bad ARC intermediaries, like for spam. Having tried and failed to build a whitelist for Spamhaus, I can tell you that it's hopeless. The bar for ARC to be usable is pretty low. It's not "doesn't send spam" or even "knows who its users are." It's only "doesn't lie about where mail came from." I expect that in practice the usual DNSBLs will be good enough. R's, John From nobody Tue Oct 6 12:05: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 D01EC3A0A1C for ; Tue, 6 Oct 2020 12:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.213, 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=wisc.edu 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 edBhCbmAQMNQ for ; Tue, 6 Oct 2020 12:05:11 -0700 (PDT) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 A45B23A0A47 for ; Tue, 6 Oct 2020 12:05:07 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QHS03SAHNESEF40@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 06 Oct 2020 13:59:17 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.10.6.185418, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.9.24.5770001, SenderIP=[104.47.55.103] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SGqMgRVK+J0eT6EEG+LVGvqKvF7+qwQo6xTuuhsTXPHp8yLxWOYqAgbMk/x3B/5wn+1HzGDrJ01FwOmg3EjAmoVQVktjJ+dHyYtu3+u+Ndd5Qsu0i5gSDK9IFVdXUZR+uA3Uh9UNC/viasG1jcqnQwA2YKMRbGhPBcporOumONrRUxZxEH5arCQ+oaYPNxFl4UPScyE1UfukHpvx6u8UciINQaNSazepoyaYNSkAxnqNG+zkA/fMy7QYqwqRFWT00QRzvJJXkX/Sd4iHwxP5/Xvb7TGVImsABtBPmpuCR9x4zld7KUS4K/1qwy/Z8eEx1Xs5mC/l3CWKj7FL1lB5rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wks5+/QbCxK+gRI0Wk+cgVr85bBKfTCeortlcmnwLUk=; b=JyVTCKdBQceR685re4NMBAIr76yISlWHbGK0seF+BmDsDj66apYeF8NVUDGinFg+OkB23+25ZxTUcwozVhmX/CDJBRhiFIGy/DZ/+vO4zAx/liGMKKYKoo+x8GKIY2AYmScxMhNRGzRPDFUezxfZJOoB6pM5v9RuQP0iPd1cf0A5Rzeev9UK+gmZSjojY5NrhjR1z7XJB/y/lSc0eseqKRSPbuX+5+im0Epnq7recTnI73WR/h4I0juSo0vV8sTjghhNXl/5x52NO2YzTfXZuzPT3H94ix8U8tdRkgFmJctZlltMNEidFW8aqfLMhLkKK4EeLqQPly9B7Pp5hCdewQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wks5+/QbCxK+gRI0Wk+cgVr85bBKfTCeortlcmnwLUk=; b=X3ZYi6QNkhl7CKpqhcbMvSTsZm1O3UZQL5iMYbukdNo15MyJ+FDhdcY08v2OxjkEFG7ykX8bkVZ1nf0MhqgNgh+cvqPOqCGVcXFkFjY7kQ+46LcEsMX97kUzaiAq0iquSMGQadevS9SQ7Oq4dakb+KrUvWbDDoXghk+/EeC9MhQ= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4539.namprd06.prod.outlook.com (2603:10b6:5:19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Tue, 6 Oct 2020 18:59:16 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::3140:5114:c860:9a7b]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::3140:5114:c860:9a7b%5]) with mapi id 15.20.3433.045; Tue, 6 Oct 2020 18:59:16 +0000 To: dmarc@ietf.org References: <20201006152041.9A2BC23014C8@ary.qy> From: Jesse Thompson Message-id: Date: Tue, 6 Oct 2020 13:59:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 In-reply-to: <20201006152041.9A2BC23014C8@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [144.92.38.238] X-ClientProxiedBy: CH2PR08CA0023.namprd08.prod.outlook.com (2603:10b6:610:5a::33) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.130.185.247] (144.92.38.238) by CH2PR08CA0023.namprd08.prod.outlook.com (2603:10b6:610:5a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38 via Frontend Transport; Tue, 6 Oct 2020 18:59:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 19666f5e-8942-498a-acc4-08d86a29ebe0 X-MS-TrafficTypeDiagnostic: DM6PR06MB4539: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oudQC8eGBTGgOY17WGFbbC/pSb8FU5HKHFccLN8sU1pJT1CNZgWuq9s0jEMH26F7s1eF4QO4ZPd+erOXtblqzK4BOlKfy78T8tcqba1KWFc/Nsod6rLtXmdeGtp+mARtbRTYGKoOU/kGpvQDmIkdyU2vBgnpOnSKdBvt7VK60egr2pIEbcfqgLogU74O5izBx68SOt5u7xFHzxRQ0SkelAOBbKt/hh45v0YPpC8T5LRv/N0mpW+lbSdRR22SOzmeycf5+4C82xJ4FNwsAFib/LrCqFwdsUd2im6+dOoNKWfg6P0nHzH/dy8wH/C+yJDY4owpsaQbxylNL6vuLK2g+Wr5cgZbGWHB0pBrZt8P7kcxL6x6jEkVTtzwiTdLA/5L X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(396003)(346002)(366004)(39860400002)(956004)(2616005)(31686004)(66556008)(6486002)(66476007)(66946007)(36756003)(2906002)(44832011)(75432002)(86362001)(6916009)(5660300002)(8936002)(8676002)(16576012)(16526019)(186003)(786003)(316002)(26005)(53546011)(31696002)(83380400001)(45080400002)(478600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Q4Bm+6/GvMOkgxIcN3ejuJcmmlnFzRbGLil0CXciQwcNPuQWJO0m4HfCwpfm5KDiCXKXIFxOXrWZAnGkIIt8B1njaBLta1LWjGyvrj4IBQvr2d6Ex42GIMwN/ykR/ZFlcodeGEPaDYf6OxMqKhU5Rzgec9/QSGYg36KxiqJ28vsiljQiZaonDvIJGHR1hNbJhF5NKeogzt7sFzRYQHUTG4NNOBduwtqbksNQg/T9cRsSzqwAKPey9HK4JVzTq2PMhZIhqwNivMYpl8tpf4Pic14LUb7/xPYFuAf/ViOauNF8sS9849kKzmkLjlHngnlpD0cDaz43CY2IfDl4GQItowT2pbIqTSGbgRvVxZLZ87Ho5gxIHuZhzAYfgRAP5n04GppBx7d0PUUTbx7Ikq7mqs8pIDKNBQ5UR7RABP7/hx9CO1o4i4iN+bAYTfObr3cMdnZS49RXSXP86gOJRAa70Clz/i6bBMX5iZqhse58hjaMLhRbg9Avd5834ECOa/OJo0LEH8oY42Mg68FprB3Ki4YBbUwwMt0pRfA/7yz8NDYA4sJJSxCjxYMv5ik/+TLfZp5xJi3DS6SJBkTW2EmnSi0gMlbGx5w60XyqiiyVqm5EpaSTRSPdavhcCxSorignSBNuvJxDxPG3KkZcm7DOCQ== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 19666f5e-8942-498a-acc4-08d86a29ebe0 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2020 18:59:15.8657 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zq9j2MLyj1JOrqOTef0ROKD1L1pWbq/M9RQRDJwG8nZI3I1Ui0k7HO1m4KaAd6CA1iIwH+HlNZbw8m9Q9mZggQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4539 Archived-At: Subject: Re: [dmarc-ietf] ARC usage, was Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 19:05:13 -0000 On 10/6/20 10:20 AM, John Levine wrote: > In article <1265372281.9984.1601969016735@appsuite-gw1.open-xchange.com> you write: >> It would be much better if there were a few professional/community efforts to build reliable and complete lists of good >> and bad ARC intermediaries, like for spam. > > Having tried and failed to build a whitelist for Spamhaus, I can tell > you that it's hopeless. > > The bar for ARC to be usable is pretty low. It's not "doesn't send > spam" or even "knows who its users are." It's only "doesn't lie about > where mail came from." I expect that in practice the usual DNSBLs > will be good enough. Is the assumption with ARC, when it reaches some point of "production" status, that intermediaries will be able to look themselves up in the usual DNSBLs to see if they are trusted so they know that they don't need to rewrite the From? Sorry, that's going down the rabbit hole... I only brought up ARC as one example of local policy overrides that an ISP-hosted receiver might want to have mechanics to control. Even with ARC being adequately managed by the usual DNSBLs, I could imagine that I would want to have some control over the edge cases. Surely there are other examples... * This is probably the most common one, based on personal experience: Allowing a 3rd party to send inbound mail to your organization "From" your own domain, but not allowing that 3rd party to use your domain to send outside of your organization (hence, not authorized by DMARC). Ideally I would want a solution that keys off of multiple signals (SPF result, DKIM result, DKIM domain/selector, etc) rather than something crude, like "trust all mail from these IPs". Again, my larger point is that if we want "filtering signal" to be the primary value-add for DMARC, then I'm suggesting that we may need to ensure that receivers actually have the ability to invent filtering signal mechanics in order to be "using DMARC". If the receiver's ISP is preventing that, then perhaps there needs to be a way for ISPs' customers' to measure their ISP's DMARC capabilities/maturity in this regard. > I am told that Office365 allows clients to place their own email filter in front of the one provided by Microsoft. I don't know whether that solves the black box problem that Jesse raises. Yes, this is what we do, but it's not common. Microsoft occasionally tries to convince us to point MX at them, and I sympathize with their motivation to put all of their customers in a consistent configuration. On the other hand, there are some local policy mechanics that we currently rely on which they don't provide. Jesse From nobody Tue Oct 6 13:41: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 182E33A106D for ; Tue, 6 Oct 2020 13:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=sm5IW63b; dkim=pass (2048-bit key) header.d=taugh.com header.b=izhNHBKy 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 cVFFEz4atB_e for ; Tue, 6 Oct 2020 13:41:06 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08D43A1039 for ; Tue, 6 Oct 2020 13:41:05 -0700 (PDT) Received: (qmail 58419 invoked from network); 6 Oct 2020 20:41:04 -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=e431.5f7cd660.k2010; bh=EOj7pWrosY4CXNLNjZM8IKtiPgaTP1c9C7tCDSfHRrc=; b=sm5IW63b6Be0IFrMfxZbn/c1jSlZ9AGnrwo2hL/NCOOh8WcVqxh4Qh69zOLXARhv7OJ3Nu8rzTtbHr/HkbbwPx/bVnHvpMSqUwCkySLJD7/DJ7BSDax1XlqOnJZrq9OOP7ZXHccXyjuwUSpo2kFeYqkW1x9BHOSpDqSksoIz6fxdeM4FxYEVo91ErTUtF/wjfJJpK6auwruZlsqqIADK8aH+7lS4lUX7pAtaInTxple5ejTQ3RqCW2o98MRQj5jXt8fdbMckYiyKHp60XMMAf84dgsfAMnipFBEWBrgIz628V0o1N0rtjF3BJLoNFqcKvTBDI9WxxYTnTxdKqKtRSQ== 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=e431.5f7cd660.k2010; bh=EOj7pWrosY4CXNLNjZM8IKtiPgaTP1c9C7tCDSfHRrc=; b=izhNHBKyp9UNzzZbVAbDUrWBq7xQugmejLkW28gWyDZFS3090h4B0fwXUlj5IDm40cVe/lCMI606aXztfCDwMk+wuTt25XGunx5lPiugTNUi5vKX7zdLFRT+6QhodtLEyKnHdxaiqyp2up2KxRjR7Be99dONzxQWs2st8qyiOIlZdZYI+xC5T2Lj/3DlzVDX90U49ELf4MH3PaMYRMofGs1y0YGDtADjcNtiO00Ww0hB0CYcLJRhPo3ZOeLnDpmSVDdA9bpqPhAkv6BJqbNe43IvfBXP8l382srzlPOd3M2QlBbv34FcYT9O2664PI6h1mH4nZcCX4aZBYYDxjSjZQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Oct 2020 20:41:04 -0000 Received: by ary.qy (Postfix, from userid 501) id 636F62306628; Tue, 6 Oct 2020 16:41:03 -0400 (EDT) Date: 6 Oct 2020 16:41:03 -0400 Message-Id: <20201006204103.636F62306628@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu 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] ARC usage, was Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 20:41:09 -0000 In article you write: >> The bar for ARC to be usable is pretty low. It's not "doesn't send >> spam" or even "knows who its users are." It's only "doesn't lie about >> where mail came from." I expect that in practice the usual DNSBLs >> will be good enough. > >Is the assumption with ARC, when it reaches some point of "production" status, that intermediaries will be able to look themselves >up in the usual DNSBLs to see if they are trusted so they know that they don't need to rewrite the From? No, not at all. ARC puts a chain of signatures on a message, but the final recipient can only verify the most recent one and has to trust the previous ones for ARC to be useful. So is the chain real, or just a bunch of garbage invented by spamware, like the long chains of Received headers they used to add? You only have to trust the most recent signer, since each link in the chain says whether the prior links were valid and a legit signer will note that the previous seal didn't verify if that's the case. R's, John From nobody Tue Oct 6 19:46: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 62AA53A15C1 for ; Tue, 6 Oct 2020 19:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tOiKr1q2mWDJ for ; Tue, 6 Oct 2020 19:46:50 -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 18B653A15C0 for ; Tue, 6 Oct 2020 19:46:49 -0700 (PDT) X-ASG-Debug-ID: 1602038808-11fa312073457b0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id xszJyp8farJrO6qV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 06 Oct 2020 22:46:48 -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=XRF2cc1A1NVm2IqKsVI7VoQb0NywHWd6Knp3XHXoCVo=; b=VjX0J32+eBdDkoTAmeMFAi8xb4vsq6M3CR4Br/B2LW+t7kUQmYSl0yNpRHECXJ7JF SrfZJFgWAAFqldBHuTrpGvMTHlln1aiHOX3dmmNX0YZZfx4zbzeWM5B5dLaJyIWq8 m1oVUBIYlB02/bcI/ykfxMi+t1G16ML+cTFw/uFIw= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Tue, 6 Oct 2020 22:46:39 -0400 X-ASG-Orig-Subj: RESENT fields? Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=80b1f0965ad7459ebb53df5f49283199 X-Exim-Id: e979ca77650640c0a304b655855b2367 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1602038808 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2411 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.85119 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] RESENT fields? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 02:46:51 -0000 This is a multipart message in MIME format. --80b1f0965ad7459ebb53df5f49283199 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are the RESENT fields from RFC 5322 an interesting idea that everybody has = ignored=3F For purposes of this discussion, they interest me because the= y provide a way of documenting changes to the SMTP sender, the From Header,= and the recipient list. RFC 5322 Section 3.6.6 says they SHOULD by added = whenever a message is re-introduced to the transport system. Mailing list= activity seems to fit the language and intent of this section. But I do = not see any RESENT fields on the most recent posts to this list. In fact,= I am not sure that I have ever seen a message anywhere with these fields. Application: For forwarded messages, I don't want to trust the forwarder's spam filter, = so I want to reconstruct the message identity as it appeared when the messa= ge entered the forwarder's ADMD. The Resent fields would allow that logic= to be developed, but I would also need forwarders to use those fields. T= he usage would also need to apply to auto-forwarders, even though they are = explicitly exempted from the RESENT header recommendation in the current RF= C. Doug Foster --80b1f0965ad7459ebb53df5f49283199 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are the RESENT fie= lds from RFC 5322 an interesting idea that everybody has ignored=3F   =  For purposes of this discussion, they interest me because they provid= e a way of documenting changes to the SMTP sender, the From Header, and the= recipient list.  RFC 5322 Section 3.6.6 says they SHOULD by added whe= never a message is re-introduced to the transport system.   Mailing li= st activity seems to fit the language and intent of this section.   Bu= t I do not see any RESENT fields on the most recent posts to this list. &nb= sp; In fact, I am not sure that I have ever seen a message anywhere with th= ese fields.

Application:
For forwarded m= essages, I don't want to trust the forwarder's spam filter, so I want to re= construct the message identity as it appeared when the message entered the = forwarder's ADMD.   The Resent fields would allow that logic to be dev= eloped, but I would also need forwarders to use those fields.   The us= age would also need to apply to auto-forwarders, even though they are expli= citly exempted from the RESENT header recommendation in the current RFC.

Doug Foster
 

--80b1f0965ad7459ebb53df5f49283199-- From nobody Wed Oct 7 04:35:38 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 416EA3A0A2B for ; Wed, 7 Oct 2020 04:35:37 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=wemonitoremail.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 bOyWJ4MtXvft for ; Wed, 7 Oct 2020 04:35:35 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2115.outbound.protection.outlook.com [40.107.22.115]) (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 26D083A0A21 for ; Wed, 7 Oct 2020 04:35:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JueZDKOFq9oWsMa6u7QNP5ADQ/EzHaJHBi7EvfMJZlYmINKheKBzaDPWJWROCeR8KKbJDMJCtrp/kAvFPUv1uYlfc18E+Q8hkr8mgR5CL/TB+fKlqish5na4H6aGvCBEjQpDaD2XRRXqf5iSog8QVdrFsjJBEvzHfs15ddHj1J4cpwRpLHSNBYnIpjo3mUqsKUio8zTiZQzm9Ut9XLSAFas+a/nlQnFyR6A5MFkZBXZHUdvftsvL4mdQSgbT8p01BT+m1VNwt3nZ3xrBaZ0bo7ls4bXmbvBSPlrcqodZpwHgCIu6LH0HG7BGbezdC275wMGyZpuUtzIC71n7oxwx3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aKTaJaLBeWJQRqEn1Yt7MRshIPi95HT46t1MzL3Fs+c=; b=SsodoYhAsGT0j5y8mdqOqOA1eryC0snqfrq4djraNBsQG+SWCFTuPhm6fTGXD/ch1UyPCFqf3+4vtXl9DFSufVFI0jmAP8HbnuGbzW5vyjQ5wj8FEfsWhTVl2XJORC583YTw1rY2UvHKpjzFKVtrxakwTfByyvmg6FTDhAeNIDQl8jeX7q+Ne+wzV7/saF/+OkWxJvTOdHwhPnE6FmqbspQxKhJlYfMiPpTdtasoYVXXDxmBHWFt17J1bMrkn72nHO3WKokT/4P0X+I7wwJUM0hf44B6I80oYQGrHbJqKT1eAlhcvMI29UwhrHzx4XfnGqBEn5l2ZE/osKrsCyN6Wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wemonitoremail.com; dmarc=pass action=none header.from=wemonitoremail.com; dkim=pass header.d=wemonitoremail.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aKTaJaLBeWJQRqEn1Yt7MRshIPi95HT46t1MzL3Fs+c=; b=LKCMCUBss9iDT7QXllXoaSBZTkEzrnxdiXUKAH0JYLd3cqVLEY9scCAkTzOOUhyIGf6AxBBF3uBMDAws21YAbqr133VWvQOSsvX9ryDxNjlw5/I6H6sHtvAK/bIp4ytx18SSmV8Qw/fBdGpE2VA9YCKhAukCtexJcuewYVVwTplt14WTfojfRJ3Xv8QDLxXSKWZkZfKQyeKO5CrXUrtSxySuHlvQpsTW7sB+CwPKuWzntRgdke59bsi3FYXUK5l7rAEXls1Ak3lLeVwqwmRDzjCQI1hzo4OWySbr7iBIbtR19A7SUVKpQxqPhFT3jH0kpfh2pmfRJeyjL8aNz2jL2Q== Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com (2603:10a6:800:19a::9) by VE1PR01MB6112.eurprd01.prod.exchangelabs.com (2603:10a6:803:127::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Wed, 7 Oct 2020 11:35:31 +0000 Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::8bc:5ccf:ec3f:385d]) by VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::8bc:5ccf:ec3f:385d%7]) with mapi id 15.20.3455.023; Wed, 7 Oct 2020 11:35:30 +0000 From: Ken O'Driscoll To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] RESENT fields? Thread-Index: AQHWnFQkeJJm/Sd6vE2wcTRKHIcUbamL44IQ Date: Wed, 7 Oct 2020 11:35:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=wemonitoremail.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 461a4ae1-fe76-4a68-10e3-08d86ab518b5 x-ms-traffictypediagnostic: VE1PR01MB6112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qmGAYaEd4xFRMh0zp/NjkVRQqUwjfmY6DY9Q66Wi6xxncYbPWkJIgEs5fnbQCagt30VFNnYSsI7fS3w79nzePA7OYHa7AxqjxpSbw50itnxK3rv+4sxg4P+DQR4D53wngv5buWE6upvtNUTGTcCAhvUMg3y+q46elLajErZOOUtrHpdOToBYxrhy/GMaQcapLV/Qx4812RbPYsRMny0suDbdnk42TUHBvE+t8GV2FheUNGwJuGd7KqirbOBjnsUQ9+s076CmqssavD2t6IY+VlnKJtuvqrTFyv/zuTbex14ZAHIRwLeT20uW/2vGSAfFgqklrpQ1cKCHjeMeti1/og== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB7053.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(39830400003)(34096005)(376002)(346002)(76116006)(66946007)(55016002)(66556008)(64756008)(66446008)(66476007)(5660300002)(33656002)(8936002)(52536014)(6506007)(53546011)(7696005)(186003)(26005)(9686003)(83380400001)(478600001)(316002)(71200400001)(2906002)(8676002)(6916009)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: pyYVtxUQz/dE+P/acIWa/8IWcEMZfirUw8ycnxPTT6gpf89b+hh0lJunkuF9TwYwpxMNlZpC/ZMKcftOEVKvBt1q1OOSHIgDbiwjxNSD5XDR0muBHM9O91ZIa4IYEwg32kuKb9FX+SDnVJ+K8zc5R6l9GJEmu1Y/a5LiQoJGth3qLHEvhpoP8POOX2+Nl/JB1Rgwrr4ibJRfQ/n0j/SRwYQMU9hvkoqu/QWX665WW3N6LEOH6i3p4lCBQdCSVHo2YVbl/A0YYEYya7JpX7kj0kEkxxu/fYE3UAI064Q2wYFdyZlMWEFZ8MsExyq4unFKuoeTj6qIiv1DyyUo3xj1/l/eDpFP0+gWgEG3wuI7Vl7OcjawYbbranXrxG6v4w7iKAgoLzW5pscdXovgRv4lkSOHnvvBJXmRWUJix5Dj5zAJYg0qsBIpFQWXvRmBWsjl6pOBFwMY2yyr+ReaH8Oa/FD2qaUX1QMF7wdIFYr2tRJFwZ/NHuq6oS99voNmP5up7eCV/teGh7Fa0K0JWmHB5nZltXtFfGyv0mLtFyyfwL5ERzVSmpPqXmuoo/jPiIH7A4h3iW2XE4x5wi9ZjFHSaYQnkfsKLPh4cIcEPOnvaWFF19MSpJ8+61p2S0ak0/ZxaKhNIic37rzaDeSUISLrdA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR01MB70535B6952A4216D394C6C46C70A0VI1PR01MB7053eurp_" MIME-Version: 1.0 X-OriginatorOrg: wemonitoremail.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB7053.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 461a4ae1-fe76-4a68-10e3-08d86ab518b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2020 11:35:30.6859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a2b1d6fe-fc8b-4b7c-b9f1-d7b1ab3d23b3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8cpAYOfKXTddwKX0WYdXmRLrD6Jny1tVlE0eyG49FYXSHdbOP6g07fKvvbn9IGnjzv0o7T2OfEcb84MUAuK95Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR01MB6112 Archived-At: Subject: Re: [dmarc-ietf] RESENT fields? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 11:35:37 -0000 --_000_VI1PR01MB70535B6952A4216D394C6C46C70A0VI1PR01MB7053eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The "resent" fields are currently used for their stated purpose, which as y= ou correctly note, is to signal that a message has been re-introduced into = the mail transport. These fields are typically used when a message which ha= s already been delivered to a mailbox is resent unmodified (and possibly af= ter a delay) to another email address. A mailing list does not resend messages, it modifies and re-posts them to a= subscriber list. The 5322.From and/or 5322.Sender fields are therefore mor= e appropriate for mailing lists because they indicate the originator of the= now re-posted/modified original message. Ken. From: dmarc On Behalf Of Douglas E. Foster Sent: Wednesday 7 October 2020 03:47 To: dmarc@ietf.org Subject: [dmarc-ietf] RESENT fields? Are the RESENT fields from RFC 5322 an interesting idea that everybody has = ignored? For purposes of this discussion, they interest me because they = provide a way of documenting changes to the SMTP sender, the From Header, a= nd the recipient list. RFC 5322 Section 3.6.6 says they SHOULD by added wh= enever a message is re-introduced to the transport system. Mailing list a= ctivity seems to fit the language and intent of this section. But I do no= t see any RESENT fields on the most recent posts to this list. In fact, I= am not sure that I have ever seen a message anywhere with these fields. Application: For forwarded messages, I don't want to trust the forwarder's spam filter, = so I want to reconstruct the message identity as it appeared when the messa= ge entered the forwarder's ADMD. The Resent fields would allow that logic= to be developed, but I would also need forwarders to use those fields. T= he usage would also need to apply to auto-forwarders, even though they are = explicitly exempted from the RESENT header recommendation in the current RF= C. Doug Foster --_000_VI1PR01MB70535B6952A4216D394C6C46C70A0VI1PR01MB7053eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The “resent” fields a= re currently used for their stated purpose, which as you correctly note, is= to signal that a message has been re-introduced into the mail transport. These fields are typically used when a message which h= as already been delivered to a mailbox is resent unmodified (and possibly a= fter a delay) to another email address.

 

A mailing list does not resend me= ssages, it modifies and re-posts them to a subscriber list. The 5322.From a= nd/or 5322.Sender fields are therefore more appropriate for mailing lists because they indicate the originator of the = now re-posted/modified original message.

 

Ken.

 

From: dmarc <dmarc-bounces@ie= tf.org> On Behalf Of Douglas E. Fost= er
Sent: Wednesday 7 October 20= 20 03:47
To: dmarc@ietf.org
Subject: [dmarc-ietf] RESENT= fields?

 

Are the RESENT fields from RFC 5322 an interesting idea that ever= ybody has ignored?    For purposes of this discussion, they interest me because they provide a way of documenting changes to the = SMTP sender, the From Header, and the recipient list.  RFC 5322 Sectio= n 3.6.6 says they SHOULD by added whenever a message is re-introduced to th= e transport system.   Mailing list activity seems to fit the language and intent of this section.   But I do not = see any RESENT fields on the most recent posts to this list.   In fact= , I am not sure that I have ever seen a message anywhere with these fields.=

 

Application:

For forwarded messages, I don't want to trust the forwarder's spa= m filter, so I want to reconstruct the message identity as it appeared when the message entered the forwarder's ADMD.   The R= esent fields would allow that logic to be developed, but I would also need = forwarders to use those fields.   The usage would also need to apply t= o auto-forwarders, even though they are explicitly exempted from the RESENT header recommendation in the current RFC.

 

Doug Foster

 

 

--_000_VI1PR01MB70535B6952A4216D394C6C46C70A0VI1PR01MB7053eurp_-- From nobody Fri Oct 9 15:52: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 8D97F3A15BD; Fri, 9 Oct 2020 15:52:32 -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 BQ5X9D8LWU2l; Fri, 9 Oct 2020 15:52:29 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0: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 B7A5B3A15BC; Fri, 9 Oct 2020 15:52:26 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id o8so10462621otl.4; Fri, 09 Oct 2020 15:52:26 -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=Z4DHzA0YH4Tsbw9dP4ZaiquSoX2/sovvVm1Zal6Qt5Y=; b=YJH8xCQtUqF0xeBIu0aL0etSKUw2KtkIcqAKf6fnhlA6BNZBJG6TIYpB57wPhLsFR5 uFgAbfvT1NOux/REbaYcIkwTzsTUmfHN1rIlI0s7pVMMH5UHI+9yRR2yxj24XbnMadgQ 71J+y7no+brfRw3OH1G03/diRrGs5a3q/nXgO3WXK6QxpCdFdY/USfRetyQv7Fb+MJgr 76Y1vHE3b/3lVcx7sHUzWdzz5hTNURtzRUTdK3xjzF+bEshpld4RdfRYcz1U/zPI82sG cKM6RtccpRTmYACCn0sJyt3ZlwdSb7Hj36Rzrpfb/3yR2wvgoGvvfV34Qwx++xFlskdv Q2+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4DHzA0YH4Tsbw9dP4ZaiquSoX2/sovvVm1Zal6Qt5Y=; b=X0mPC9khb36mrds24Gl92UL5UT8WDbtriKlVQATjDb/KSiNBC/fX+SXXDJMw09MTS2 Fpaig9a0iavadZHv91Fk933xX/BY/OQPamMPxW/yYNnX0WY0qgOhkgrwOycnkxdEgXOC P3vJoLdj6kl5Cmyp0f0tyocu0RkcLAYJ4nSyuFnhuPvcM+cD2S0rtg3eDgW/ON+CijMW t/nCigCLW1IjcAvmUqQeAg9vCMZCPP+ako7PiQeGDigizfqaYd0ssEPktY24aW3YptEZ RkoCz5c68pDc5znGfGbSe5uqo7rYRyrKG5qgL8rxF+K1j2VIFnzJBr26dZqqQbvodNaH UoGA== X-Gm-Message-State: AOAM533bjSsJVt2XWLsmujibpwlTuW3G9/XKRckeLtUZRl0cp6xMEBBK KRQ2EKy50n5F+fGfJgtpTU7Mmj7IuuOXP2RBaZLHGAvNeS2LWw== X-Google-Smtp-Source: ABdhPJwODWFnNUWMT5LaHkeB6fFogDfLSVKaFHjCbgHjFZo345OdoURpOhbnWlnVPotsUfK9tXNrjiGJ/KJYM/sWOEk= X-Received: by 2002:a9d:da7:: with SMTP id 36mr10764228ots.288.1602283945968; Fri, 09 Oct 2020 15:52:25 -0700 (PDT) MIME-Version: 1.0 References: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> <871rogwc0h.fsf@hobgoblin.ariadne.com> In-Reply-To: <871rogwc0h.fsf@hobgoblin.ariadne.com> From: Tim Wicinski Date: Fri, 9 Oct 2020 18:52:14 -0400 Message-ID: To: "Dale R. Worley" Cc: Scott Kitterman , last-call@ietf.org, IETF DMARC WG , General Area Review Team , draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/mixed; boundary="0000000000006e2fae05b144cdb1" Archived-At: Subject: Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 22:52:33 -0000 --0000000000006e2fae05b144cdb1 Content-Type: multipart/alternative; boundary="0000000000006e2fab05b144cdaf" --0000000000006e2fab05b144cdaf Content-Type: text/plain; charset="UTF-8" Dale Apologies for the delay on the PSD updates. I sat down with Scott and went through your review and made lots of edits related to your comments. I actually attached the reply to your email as it's been sitting in my editor buffer for a few months too long. One normative change that I want your assistance on is the descriptions of the Experiments. I updated them and pulled them apart, to make them more understandable to folks looking at this for the first time. I'm not still 100% on them. I want to go back through your opening Nits/editorial comments to make sure I'm not missing anything. Here's the link to the diff. https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 thanks tim On Tue, Apr 21, 2020 at 9:22 PM Dale R. Worley wrote: > Scott Kitterman writes: > > [important discussion clipped for brevity] > > If you want to add it and are confident we aren't diving into a deep, > > deep hole, I don't strongly object. Just let me know what to add. > > Well, my review amounted to about 5 pages of ordinary text, and my > follow-up e-mail about a page and a half. If I was unclear regarding > what I thought should be done to make the document clearer to the > unsophisticated reader, please get back to me so that I can improve my > review style. > > Dale > --0000000000006e2fab05b144cdaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale
<= br>
Apolo= gies for the delay on the PSD updates.=C2=A0 I sat down with Scott and went= through your review and made lots of edits
related to your comments.=C2=A0 I actual= ly attached the reply to your email as it's been sitting in my editor b= uffer for a few months too long.=C2=A0

One normative change that I want your assistance= on is the descriptions of the Experiments.=C2=A0 I updated them and pulled= them apart, to make them more understandable to folks looking at this for = the first time.=C2=A0 I'm not still 100% on them.=C2=A0

I want to go back through yo= ur opening Nits/editorial comments to make sure I'm not missing anythin= g.

He= re's the link to the diff.

https://www.ietf.org/rfcd= iff?url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-ietf-dmarc-psd-09

thanks
tim

<= br>
On Tue,= Apr 21, 2020 at 9:22 PM Dale R. Worley <worley@ariadne.com> wrote:
Scott Kitterman <scott@kitterman.com> writes:
> [important discussion clipped for brevity]
> If you want to add it and are confident we aren't diving into a de= ep,
> deep hole, I don't strongly object.=C2=A0 Just let me know what to= add.

Well, my review amounted to about 5 pages of ordinary text, and my
follow-up e-mail about a page and a half.=C2=A0 If I was unclear regarding<= br> what I thought should be done to make the document clearer to the
unsophisticated reader, please get back to me so that I can improve my
review style.

Dale
--0000000000006e2fab05b144cdaf-- --0000000000006e2fae05b144cdb1 Content-Type: text/plain; charset="US-ASCII"; name="psd-comments.txt" Content-Disposition: attachment; filename="psd-comments.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kg2uanho0 PiAqIFN1bW1hcnk6Cj4gCj4gICAgICAgIFRoaXMgZHJhZnQgaXMgb24gdGhlIHJpZ2h0IHRyYWNr IGJ1dCBoYXMgb3BlbiBpc3N1ZXMsIGRlc2NyaWJlZAo+ICAgICAgICBpbiB0aGUgcmV2aWV3Lgo+ IAo+ICogTWFqb3IgaXNzdWVzOgo+IAo+IFRoZSBwcml2YWN5IGNvbmNlcm5zIGRlc2NyaWJlZCBp biBzZWN0aW9uIDQgYXJlIHdyaXR0ZW4gYXMgaWYgdGhlcmUgaXMKPiBubyBjZXJ0YWludHkgdGhh dCB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50IHByb3Blcmx5Cj4gbWl0 aWdhdGUgdGhlbS4gIFNvIHRoZSBkb2N1bWVudCBhcHBlYXJzIHRvIGJlIGluY29tcGxldGUuICBP VE9ILCBzaW5jZQo+IHRoaXMgaXMgYW4gRXhwZXJpbWVudGFsIFJGQywgc3VjaCBtaXRpZ2F0aW9u IGlzbid0IG5lY2Vzc2FyeSBpZiB0aGVyZQo+IGlzIGNvbW1pdG1lbnQgdG8gZG8gc28gbGF0ZXIu ICBJbiB0aGF0IGNhc2UsIHRoZSBzZWN0aW9uIHNob3VsZAo+IGV4cGxpY2l0bHkgc3RhdGUgdGhh dCB0aGVzZSBhcmUgb3BlbiBpc3N1ZXMgYW5kIHRoYXQgdGhlcmUgaXMgYW4KPiBpbnRlbnRpb24g b2YgcmV2aXNpbmcgdGhlIGRvY3VtZW50IHRvIG1pdGlnYXRlIHRoZW0uCj4gCj4gVGhlIHRleHQg c3VnZ2VzdHMgdGhhdCBhIG1haWwgcmVjZWl2ZXIoPykgdGhhdCBkb2VzIERNQVJDIHByb2Nlc3Np bmcKPiBoYXMga25vd2xlZGdlIG9mIGFsbCBQU0RzLiAgVGhpcyBzZWVtcyBhIHByaW9yaSB1bmxp a2VseSBhbmQgZXZlbgo+IGltcG9zc2libGUgdG8gaW1wbGVtZW50LiAgU28gdGhpcyBvdWdodCB0 byBiZSBlaXRoZXIgZXhwbGFpbmVkIGF0IHRoZQo+IGFwcHJvcHJpYXRlIHBsYWNlIG9yIHJlc29s dmVkIHRlY2huaWNhbGx5Lgo+IAo+ICogTWlub3IgaXNzdWVzOgo+IAo+IFRoZSBkb2N1bWVudCBo YXMgdGhlIChjb21tb24pIGVkaXRvcmlhbCBwcm9ibGVtIHRoYXQgaXQgaXMgd3JpdHRlbiBieQo+ IHBlb3BsZSB3aG8gYXJlIGRlZXBseSBmYW1pbGlhciB3aXRoIHRoZSBzdWJqZWN0LCBhbmQgaXQn cyBkaWZmaWN1bHQgdG8KPiByZWFkIGlmIG9uZSBkb2Vzbid0IHNoYXJlIHRoYXQgZmFtaWxpYXJp dHkuICBUaGlzIGlzIHBhcnRpY3VsYXJseQo+IHNpZ25pZmljYW50IGJlY2F1c2UgRE1BUkMgaXMg YW4gZS1tYWlsIGZhY2lsaXR5IHRoYXQgKGlkZWFsbHkpIHdpbGwKPiBhZmZlY3QgYWxsIGUtbWFp bCB0aGF0IGlzIHNlbnQsIHNvIHRoZSB0YXJnZXQgYXVkaWVuY2UgcmVhbGx5IHNob3VsZAo+IGJl IGFueW9uZSB3aG8gaGFzIGEgYmFzaWMgdW5kZXJzdGFuZGluZyBvZiBlLW1haWwuICBUaHJlZSBw YXJ0aWN1bGFyCj4gZWxlbWVudHMgb2YgdGhpcyBhcmU6Cj4gCj4gLSBJdCB3b3VsZCBiZSB2ZXJ5 IGhlbHBmdWwgaWYgdGhlIEludHJvZHVjdGlvbiBjb3VsZCBzdGF0ZSwgaW4gYSBmZXcKPiAgIHNl bnRlbmNlcywgdGhlIHB1cnBvc2UgYW5kIG9wZXJhdGlvbiBvZiBETUFSQywgdGh1cyBpbmZvcm1p bmcgdGhlCj4gICByZWFkZXIgb2YgdGhlIGZyYW1ld29yayB3aG9zZSBkZWZpY2llbmNpZXMgdGhp cyBkb2N1bWVudCBhdHRlbXB0cyB0bwo+ICAgYWRkcmVzcy4gIEluIHBhcnRpY3VsYXIsIG9uZSBz aG91bGRuJ3QgaGF2ZSB0byByZWFkIHRoZSBETUFSQyBSRkNzCj4gICB0byBiZSBhYmxlIHRvIHJl YWQgdGhpcyBkb2N1bWVudCBhbmQgdW5kZXJzdGFuZCBpdHMgZ2VuZXJhbCBpbXBvcnQuCj4gCj4g LSBUaGUgImV4cGVyaW1lbnQiIGFwcGVuZGl4ZXMgYXJlIHVuY2xlYXIgYWJvdXQgd2hhdCB0aGUg ZXhwZXJpbWVudHMKPiAgIGFjdHVhbGx5IGFyZTogIHdoYXQgcXVlc3Rpb25zIHRoZXkgYXJlIHRv IGFuc3dlciwgd2hhdCBhY3Rpb25zIHdpbGwKPiAgIGJlIHRha2VuLCBob3cgdGhlIHJlc3VsdHMg d2lsbCBiZSBldmFsdWF0ZWQuICBTdGFydGluZyBlYWNoIGFwcGVuZGl4Cj4gICB3aXRoIGFuIG92 ZXJ2aWV3IHBhcmFncmFwaCB3b3VsZCBiZSBoZWxwZnVsLgo+IAo+IC0gRm9yd2FyZCByZWZlcmVu Y2VzIHNob3VsZCBiZSBtaW5pbWl6ZWQgc28gdGhhdCBhIHJlYWRlciBjYW4KPiAgIHVuZGVyc3Rh bmQgdGhlIGRvY3VtZW50IGluIG9uZSBwYXNzLgo+IAo+IEFzIGEgZGVyaXZhdGl2ZSBvZiB0aGUg Zmlyc3Qgb2YgdGhlc2UgZWxlbWVudHMsIHRoZSB0ZXJtaW5vbG9neSB1c2VkCj4gZm9yIHRoZSBw cm9wZXJ0aWVzIG9mIGRvbWFpbiBuYW1lcyBpcyBub3QgY2xlYXJseSBkZWZpbmVkLiAgSW4KPiBw YXJ0aWN1bGFyLCB3aGVyZSBkb2VzIGEgcmVnaXN0cmF0aW9uICJvY2N1ciI/ICBUaGUgb25seSB0 ZXJtIGZvcgo+IHdoaWNoIEkgdGhpbmsgdGhlIGdlbmVyYWwgYXVkaWVuY2UgcG9zc2Vzc2VzIGFu IHVuYW1iaWd1b3VzIGRlZmluaXRpb24KPiBpcyAidGhlIHJlZ2lzdGVyZWQgZG9tYWluIG5hbWUi LCBlLmcuIGlldGYub3JnLiAgTm93IEkgKnRoaW5rKiBpdHMgUFNECj4gaXMgIi5vcmciLCBidXQg aXQgbWlnaHQgYmUgImlldGYub3JnIiwgYW5kIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoZQo+IHJl Z2lzdHJhdGlvbiBvZiBpZXRmLm9yZyAib2NjdXJzIiBhdCBpZXRmLm9yZyBvciAub3JnLiAgRnVy dGhlciBwb2ludHMKPiBJIGRpZG4ndCB1bmRlcnN0YW5kIGFyZSBwb2ludGVkIG91dCBpbiB0aGUg cmV2aWV3IG9mIHRoZQo+IEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24uCj4gCj4gKiBOaXRzL2Vk aXRvcmlhbCBjb21tZW50czogCj4gCj4gQWJzdHJhY3QKPiAKPiBJJ20gaGF2aW5nIHF1aXRlIGEg Yml0IG9mIGRpZmZpY3VsdHkgZmlndXJpbmcgb3V0IGV4YWN0bHkgd2hhdCB0aGUKPiBBYnN0cmFj dCBtZWFucy4gIEknbSBzdXJlIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgY2xlYXJseSB1bmRlcnN0 YW5kcwo+IHdoYXQgaXMgbWVhbnQsIGJ1dCB0aGUgd3JpdGluZyBpcyBqdXN0IGxvb3NlIGVub3Vn aCB0aGF0IEkgY2FuJ3QgZml4Cj4gdGhlIG1lYW5pbmcuICBUbyByYWlzZSB0aGUgaW1tZWRpYXRl IHF1ZXN0aW9uczoKPiAKPiAgICBETUFSQyAoRG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGlj YXRpb24sIFJlcG9ydGluZywgYW5kCj4gICAgQ29uZm9ybWFuY2UpIGlzIGEgc2NhbGFibGUgbWVj aGFuaXNtIGJ5IHdoaWNoIGEgbWFpbC1vcmlnaW5hdGluZwo+ICAgIG9yZ2FuaXphdGlvbiBjYW4g ZXhwcmVzcyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcgo+ICAgIG1l c3NhZ2UgdmFsaWRhdGlvbiwgZGlzcG9zaXRpb24sIGFuZCByZXBvcnRpbmcsIHRoYXQgYSBtYWls LXJlY2VpdmluZwo+ICAgIG9yZ2FuaXphdGlvbiBjYW4gdXNlIHRvIGltcHJvdmUgbWFpbCBoYW5k bGluZy4KPiAKPiBUaGlzIHNlbnRlbmNlIGlzIHF1aXRlIGdvb2QsIGFzIGl0IGludHJvZHVjZXMg d2hhdCBETUFSQyBpcyBhbGwgYWJvdXQuCj4gCj4gICAgVGhlIGRlc2lnbiBvZiBETUFSQwo+ICAg IHByZXN1bWVzIHRoYXQgZG9tYWluIG5hbWVzIHJlcHJlc2VudCBlaXRoZXIgbm9kZXMgaW4gdGhl IHRyZWUgYmVsb3cKPiAgICB3aGljaCByZWdpc3RyYXRpb25zIG9jY3VyLCBvciBub2RlcyB3aGVy ZSByZWdpc3RyYXRpb25zIGhhdmUKPiAgICBvY2N1cnJlZDsgaXQgZG9lcyBub3QgcGVybWl0IGEg ZG9tYWluIG5hbWUgdG8gaGF2ZSBib3RoIG9mIHRoZXNlCj4gICAgcHJvcGVydGllcyBzaW11bHRh bmVvdXNseS4KPiAKPiBZb3Ugd2FudCB0byBtYWtlIGNsZWFyIGhlcmUgdGhhdCAicmVnaXN0cmF0 aW9uIiBtZWFucyAiZG9tYWluIG5hbWUKPiBvd25lcnNoaXAgcmVnaXN0cmF0aW9uIiAod2hpY2gg aXMgd2hhdCBzZWN0aW9uIDIuMiBzYXlzKS4gIE90aGVyd2lzZQo+IGl0IGxlYXZlcyBvcGVuIHRo YXQgdGhlcmUgaXMgc29tZSBzb3J0IG9mIERNQVJDIHJlZ2lzdHJhdGlvbiB0aGF0IHlvdQo+IG1p Z2h0IGludGVuZCwgdW50aWwgdGhlIHJlYWRlciBnZXRzIHRvIHNlY3Rpb24gMi4yLgo+IAo+IFRo ZXJlJ3MgYW4gYW1iaWd1aXR5IHJlZ2FyZGluZyAid2hlcmUiIGEgcmVnaXN0cmF0aW9uIGhhcHBl bnMuICBFLmcuLAo+IGRvZXMgdGhlIHJlZ2lzdHJhdGlvbiBvZiAiaWV0Zi5vcmciICJvY2N1ciBh dCIgImlldGYub3JnIiBvciAib2NjdXIKPiBhdCIgIm9yZyI/ICBJdCdzIHBvc3NpYmxlIHRoYXQg dGhpcyBjb3VsZCBiZSBzaW1wbGlmaWVkL2Rpc2FtYmlndWF0ZWQKPiBieSBub3QgdXNpbmcgdGhp cyB0ZXJtLCBidXQgaW5zdGVhZCBwaHJhc2luZyB0aGlzIGluIHRlcm1zIG9mIGRvbWFpbgo+IG5h bWVzIHRoYXQgImFyZSByZWdpc3RlcmVkIiwgYW5kIHRoZSBhbGxvd2VkIHJlbGF0aW9uc2hpcHMg YmV0d2Vlbgo+IHRoZW0uCj4gCj4gQW5kIGl0IGFwcGVhcnMgY2VydGFpbiB0aGF0IHRoZXJlIGFy ZSBETlMgbm9kZXMgd2hlcmUgcmVnaXN0cmF0aW9ucwo+IGFyZSBvbmx5IGRvbmUgKmFib3ZlKiB0 aGF0IG5vZGUsIGUuZy4gImRhdGF0cmFja2VyLmlldGYub3JnIiwgd2hpY2gKPiB0aGlzIHNlbnRl bmNlIChpZiB0YWtlbiBsaXRlcmFsbHkpIHNheXMgaXMgbm90IHBlcm1pdHRlZCBieSBETUFSQy4g IElzCj4gdGhlIHByb3BlcnR5IHlvdSB3YW50IHRvIGRlY2xhcmUgIm9uZSBub2RlIHdoZXJlIHJl Z2lzdHJhdGlvbnMgYXJlCj4gZG9uZSBjYW5ub3QgZXhpc3QgYmVsb3cgYW5vdGhlciBub2RlIHdo ZXJlIHJlZ2lzdHJhdGlvbnMgYXJlIGRvbmUiPwo+IAo+IE9yIHBlcmhhcHMgZG9tYWluIG5hbWVz IGxpa2UgImRhdGF0cmFja2VyLmlldGYub3JnIiBhcmUgb2Ygbm8gaW50ZXJlc3QKPiB0byBETUFS QyBiZWNhdXNlIERNQVJDIGlzIG5ldmVyIGFwcGxpZWQgdG8gbWVzc2FnZXMgZm9yIHdoaWNoIHRo YXQgaXMKPiB0aGUgcmVsZXZhbnQgYWRkcmVzcz8KPiAKPiAgICBTaW5jZSBpdHMgZGVwbG95bWVu dCBpbiAyMDE1LCB1c2Ugb2YKPiAgICBETUFSQyBoYXMgc2hvd24gYSBjbGVhciBuZWVkIGZvciB0 aGUgYWJpbGl0eSB0byBleHByZXNzIHBvbGljeSBmb3IKPiAgICB0aGVzZSBkb21haW5zIGFzIHdl bGwuCj4gCj4gVGhpcyBzZW50ZW5jZSBkb2Vzbid0IG1ha2UgaXQgY2xlYXIgd2hhdCAidGhlc2Ug ZG9tYWlucyIgcmVmZXJzIHRvLgo+IAo+ICAgIERvbWFpbnMgYXQgd2hpY2ggcmVnaXN0cmF0aW9u cyBjYW4gb2NjdXIgYXJlIHJlZmVycmVkIHRvIGFzIFB1YmxpYwo+ICAgIFN1ZmZpeCBEb21haW5z IChQU0RzKS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byBETUFSQwo+ ICAgIHRvIGVuYWJsZSBETUFSQyBmdW5jdGlvbmFsaXR5IGZvciBQU0RzLgo+IAo+IEl0IHdvdWxk IHByb2JhYmx5IGJlIGNsZWFyZXIgdG8gdXNlICJkb21haW4gbmFtZSBvd25lcnNoaXAKPiByZWdp c3RyYXRpb25zIiBhZ2FpbiBoZXJlLgo+IAo+IFRoaXMgc2VudGVuY2Ugc3VnZ2VzdHMgdGhhdCB0 aGUgcmVnaXN0cmF0aW9uIG9mICJpZXRmLm9yZyIgIm9jY3VycyBhdCIKPiAib3JnIiBhbmQgc28g Im9yZyIgaXMgYSBQU0QuCj4gCj4gICAgVGhpcyBkb2N1bWVudCBhbHNvIHNlZWtzIHRvIGFkZHJl c3MgaW1wbGVtZW50YXRpb25zIHRoYXQgY29uc2lkZXIgYQo+ICAgIGRvbWFpbiBvbiBhIHB1Ymxp YyBTdWZmaXggbGlzdCB0byBiZSBpbmVsaWdpYmxlIGZvciBETUFSQwo+ICAgIGVuZm9yY2VtZW50 Lgo+IAo+IFRoaXMgc3VnZ2VzdHMgdGhhdCBpbXBsZW1lbnRhdGlvbnMgYmVsaWV2ZSB0aGF0IHRo ZXkga25vdyBvZiBhbGwgUFNEcywKPiBzbyB0aGV5IGNhbiAiY29uc2lkZXIgdGhlbSBpbmVsaWdp YmxlIGZvciBETUFSQyBlbmZvcmNlbWVudCIuICBCdXQKPiBpdCdzIGhhcmQgdG8gaW1hZ2luZSB0 aGF0IHRoYXQgdGhleSBjYW4ga25vdyB0aGF0IHRoZXkga25vdyBvZiBhbGwKPiBQU0RzLgo+IAo+ IEFuIGFkZGl0aW9uYWwgcG9pbnQsIGFuZCBJJ20gbm90IHN1cmUgaG93IHZhbHVhYmxlIHRoaXMg aXMsIHdvdWxkIGJlCj4gdG8gY2xhcmlmeSAiSSdtIGhvbGRpbmcgYW4gZS1tYWlsIG1lc3NhZ2Ug aW4gbXkgaGFuZHMuICBXaGF0IGRvIEkgZG8KPiBuZXh0PyIsIHRoYXQgaXMsIFdoYXQgYWRkcmVz cyBpbiB0aGUgbWVzc2FnZSBpcyB0aGUgZG9tYWluIHdob3NlIERNQVJDCj4gaW5mb3JtYXRpb24g aXMgYXBwbGllZCB0byB0aGUgbWVzc2FnZT8gIEFuZCB3aGF0IGluZGVlZCBkb2VzIERNQVJDCj4g cHJvY2Vzc2luZyBkbyB0byBhIG1lc3NhZ2U/ICBGb3IgbW9zdCBvZiB0aGUgc2VudGVuY2VzIG9m IHRoZQo+IEFic3RyYWN0LCB0aGlzIGlzIG5vdCBpbXBvcnRhbnQsIGJ1dCBpdCBsZWF2ZXMgdGhl IGVmZmVjdCBvZiB0aGUgbGFzdAo+IHNlbnRlbmNlIHVuY2xlYXIsIGFzICJETUFSQyBpcyBub3Qg ZW5mb3JjZWQgb24gbWVzc2FnZXMgd2hvc2UgKnNlbmRlcioKPiBpcyBpbiBhIFBTRCIgaXMgcXVp dGUgYSBiaXQgZGlmZmVyZW50IGZyb20gIkRNQVJDIGlzIG5vdCBlbmZvcmNlZCBvbgo+IG1lc3Nh Z2VzIHdob3NlICpyZWNpcGllbnQqIGlzIGluIGEgUFNEIi4gIChTZWN0aW9uIDMuMyBzdWdnZXN0 cyB0aGF0Cj4gdGhlIGFkZHJlc3MgaW4gdGhlIEZyb20gaGVhZGVyIG9mIHRoZSBtZXNzYWdlIGlz IHRoZSBvbmUgdGhhdCBpcyB1c2VkCj4gZm9yIERNQVJDIHByb2Nlc3NpbmcuKQo+IAo+IEl0J3Mg dW5jbGVhciB3aGF0IGV4YWN0bHkgaXMgdGhlIGNvbnRlbnRzIG9mIGEgInB1YmxpYyBzdWZmaXgg bGlzdCIuCj4gTmFpdmVseSwgaXQgYXBwZWFycyB0aGF0IGl0IGlzIHRoZSBsaXN0IG9mIGRvbWFp biBuYW1lcyB1bmRlciB3aGljaAo+IG5hbWVzIGNhbiBiZSByZWdpc3RlcmVkLCBidXQgdGhlIHRl eHQgdXNlcyB0aGUgdGVybSBpbiB0aGUgcGx1cmFsLCBzbwo+IHRoZXJlIG11c3QgYmUgc29tZSBh ZGRpdGlvbmFsIHN0cnVjdHVyZS4KPiAKPiBBbHNvLCBpdCBzZWVtcyB0aGVyZSBhcmUgc29tZSBz aWduaWZpY2FudCBwcml2YWN5IG1hdHRlcnMgYWRkcmVzc2VkIGJ5Cj4gdGhpcyBkb2N1bWVudCwg YW5kIGl0J3MgcHJvYmFibHkgd29ydGggYWRkaW5nIGEgc2VudGVuY2UgdG8gbm90aWZ5IHRoZQo+ IHJlYWRlciBvZiB0aGF0Lgo+IAo+IDEuICBJbnRyb2R1Y3Rpb24KPiAKCi0tLS0KCj4gQSBudW1i ZXIgb2YgdGhlIHF1ZXN0aW9ucyBhYm91dCB0aGUgQWJzdHJhY3QgYXBwbHkgdG8gdGhlIEludHJv ZHVjdGlvbgo+IGFzIHdlbGwuICBCdXQgZ2VuZXJhbGx5LCBzaW5jZSBlLW1haWwgaXMgYSBzdWJq ZWN0IHRoYXQgZXZlcnkgcmVhZGVyCj4gaGFzIGEgYmFzaWMga25vd2xlZGdlIG9mLCBpdCB3b3Vs ZCBiZSB1c2VmdWwgdG8gd3JpdGUgdGhlIGludHJvZHVjdGlvbgo+IHNvIHRoYXQgb25lIGRpZCBu b3QgaGF2ZSB0byBoYXZlIGEga25vd2xlZGdlIG9mIHRoZSBETUFSQyBhcmNoaXRlY3R1cmUKPiB0 byB1bmRlcnN0YW5kIHRoZSBpbnRyb2R1Y3Rpb24uCj4gCj4gICAgImdvdi5leGFtcGxlIiBwdWJs aXNoZXMgdGhlIGZvbGxvd2luZyBETUFSQyByZWNvcmQ6Cj4gCj4gICAgInY9RE1BUkMxOyBwPXJl amVjdDsgcnVhPW1haWx0bzpkbWFyY0BkbWFyYy5zZXJ2aWNlLmdvdi5leGFtcGxlIgo+IAo+ICAg IGF0Cj4gCj4gICAgX2RtYXJjLmdvdi5leGFtcGxlLgo+IAo+IEV2ZW4gYmV0dGVyIHdvdWxkIGJl IHRoaXMgYWlkIHRvIHBlb3BsZSB3aG8gZG9uJ3QgYWxyZWFkeSBrbm93IERNQVJDCj4gaW1wbGVt ZW50YXRpb246Cj4gCj4gICAgImdvdi5leGFtcGxlIiBwdWJsaXNoZXMgdGhlIGZvbGxvd2luZyBE TUFSQyBETlMgcmVjb3JkOgo+IAo+ICAgIF9kbWFyYy5nb3YuZXhhbXBsZS4gIFRYVCBcCj4gICAg ICJ2PURNQVJDMTsgcD1yZWplY3Q7IHJ1YT1tYWlsdG86ZG1hcmNAZG1hcmMuc2VydmljZS5nb3Yu ZXhhbXBsZSIKPiAKClVwZGF0ZWQgdG8gYmUgYSBtb3JlIGNvbXBsZXRlIEROUyByZWNvcmQuCgo+ IC0tCj4gCj4gICAgdGhlIG5vbi1leGlzdGVudCBvcmdhbml6YXRpb25hbCBkb21haW4gb2YgQHRh eC5nb3YuZXhhbXBsZQo+IAo+IEkgc3VzcGVjdCB5b3UgbWVhbiAidDR4Lmdvdi5leGFtcGxlIiBo ZXJlLgoKQ29ycmVjdC4gVXBkYXRlZC4gCgo+IAo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg YSBzaW1wbGUgZXh0ZW5zaW9uIHRvIERNQVJDIFtSRkM3NDg5XSB0bwo+ICAgIGFsbG93IFsuLi5d Cj4gCj4gVGhpcyBzZW50ZW5jZSBsaXN0cyA0IGltcG9ydGFudCBpdGVtcywgZWFjaCBvZiB3aGlj aCBpcyBmYWlybHkgbG9uZywKPiB3aGljaCB0b2dldGhlciBhcmUgdGhlIHN1bW1hcnkgb2YgdGhl IHdob2xlIGRvY3VtZW50LCBzbyBpdCBtaWdodCBiZQo+IHVzZWZ1bCB0byBicmVhayB0aGlzIGlu dG8gYSBidWxsZXQtbGlzdC4KPiAKCk9waW5pb25zIG9uIFJlZm9ybWF0dGVkID8gCgogICBUaGlz IGRvY3VtZW50IHByb3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lvbiB0byBETUFSQyBbUkZDNzQ4OV0g dG8gYWxsb3cKICAgb3BlcmF0b3JzIG9mIFB1YmxpYyBTdWZmaXggRG9tYWlucyAoUFNEcykgdG86 CgogICBvICBFeHByZXNzIHBvbGljeSBhdCB0aGUgbGV2ZWwgb2YgdGhlIFBTRCB0aGF0IGNvdmVy cyBhbGwKICAgICAgb3JnYW5pemF0aW9uYWwgZG9tYWlucyB0aGF0IGRvIG5vdCBleHBsaWNpdGx5 IHB1Ymxpc2ggRE1BUkMKICAgICAgcmVjb3JkcwoKICAgbyAgRXh0ZW5kcyB0aGUgRE1BUkMgcG9s aWN5IHF1ZXJ5IGZ1bmN0aW9uYWxpdHkgdG8gZGV0ZWN0IGFuZCBwcm9jZXNzCiAgICAgIHN1Y2gg YSBwb2xpY3kKCiAgIG8gIERlc2NyaWJlcyByZWNlaXZlciBmZWVkYmFjayBmb3Igc3VjaCBwb2xp Y2llcwoKICAgbyAgUHJvdmlkZXMgY29udHJvbHMgdG8gbWl0aWdhdGUgcG90ZW50aWFsIHByaXZh Y3kgY29uc2lkZXJhdGlvbnMKICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZXh0ZW5zaW9uCgoK PiAyLiAgVGVybWlub2xvZ3kgYW5kIERlZmluaXRpb25zCj4gCj4gICAgSW4gbWFueSBjYXNlcyB0 aGUgcHVibGljIHBvcnRpb24gb2YgdGhlIEROUyB0cmVlIGlzIFsuLi5dCj4gCj4gV2hhdCBkb2Vz ICJ0aGUgcHVibGljIHBvcnRpb24iIG1lYW4/ICBJJ20gZ3Vlc3NpbmcgaXQgbWVhbnMgInRoZSBu YW1lcwo+IG5vdCBhdmFpbGFibGUgZm9yIHByaXZhdGUgcmVnaXN0cmF0aW9uIiwgYnV0IHlvdSBz aG91bGQgYmUgdW5hbWJpZ3VvdXMKPiBoZXJlLgoKSSBiZWxpZXZlIFNjb3R0IGNsZWFuZWQgdGhl IHdvcmRpbmcgdXAgaGVyZS4KCj4gICAgVGhleSBhcmUgbm90IGF2YWlsYWJsZSBmb3IgcHJpdmF0 ZQo+ICAgIHJlZ2lzdHJhdGlvbi4gIEluIG1hbnkgY2FzZXMgdGhlIHB1YmxpYyBwb3J0aW9uIG9m IHRoZSBETlMgdHJlZSBpcwo+ICAgIG1vcmUgdGhhbiBvbmUgbGV2ZWwgZGVlcC4KPiAKPiBJdCBz ZWVtcyBsaWtlIHRoZXNlIHR3byBzZW50ZW5jZXMgYXJlIHJlZHVuZGFudCBhbmQgdGhlIGZsb3cg b2YgdGhlCj4gcGFyYWdyYXBoIHdvdWxkIGJlIGJldHRlciBpZiB0aGV5IHdlcmUgcmVtb3ZlZC4g Li4uIEFjdHVhbGx5IG9uY2UgdGhleQo+IGFyZSByZW1vdmVkLCBpdCByZXZlYWxzIHRoYXQgdGhl IG5leHQgdHdvIHNlbnRlbmNlcyBsYXJnZWx5IGR1cGxpY2F0ZQo+IHRoZSBmaXJzdCB0d28gc2Vu dGVuY2VzIG9mIHRoZSBwYXJhZ3JhcGguCgpBZ3JlZWQuIFdlJ3ZlIHJlbW92ZWQgdGhlc2Ugc2Vu dGVuY2VzLiAKCi0tLS0tLS0tCgo+ICAgIDIuMy4gIExvbmdlc3QgUFNECj4gCj4gICAgVGhlIGxv bmdlc3QgUFNEIGlzIHRoZSBPcmdhbml6YXRpb25hbCBEb21haW4gd2l0aCBvbmUgbGFiZWwgcmVt b3ZlZC4KPiAKPiAgICAyLjQuICBPcmdhbml6YXRpb25hbCBEb21haW4KPiAKPiAgICBUaGUgdGVy bSBPcmdhbml6YXRpb25hbCBEb21haW5zIGlzIGRlZmluZWQgaW4gRE1BUkMgW1JGQzc0ODldCj4g ICAgU2VjdGlvbiAzLjIuCj4gCj4gMi40IHNob3VsZCBiZSBtb3ZlZCBhaGVhZCBvZiAyLjMgdG8g YXZvaWQgYSBmb3J3YXJkLXJlZmVyZW5jZS4gIEJ1dCBpdAo+IHdvdWxkIGJlIHJlYWxseSBoZWxw ZnVsIGlmIHRoZSBkZWZpbml0aW9uIG9mIE9yZ2FuaXphdGlvbmFsIERvbWFpbiB3YXMKPiBlaXRo ZXIgc3VtbWFyaXplZCBoZXJlIG9yIGNvbXBsZXRlbHkgY29waWVkIGZyb20gUkZDNzQ4OS4gIElu Cj4gcGFydGljdWxhciwgaWYgT3JnYW5pemF0aW9uYWwgRG9tYWluIGlzIG5vdCB0aGUgc2FtZSBh cyByZWdpc3RlcmVkCj4gZG9tYWluIG5hbWUsIHRoYXQgc2hvdWxkIGJlIGZsYWdnZWQuCj4gCgpT d2l0Y2hlZCBzZWN0aW9ucyAyLjQgYW5kIDIuMy4KCkFzIGZvciAiT3JnYW5pemF0aW9uYWwgRG9t YWluIiwgdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSA3NDg5IGRlZmluaXRpb24gaXMgCiJUaGUg ZG9tYWluIHRoYXQgd2FzIHJlZ2lzdGVyZWQgd2l0aCBhIGRvbWFpbiBuYW1lIHJlZ2lzdHJhci4i IHdpdGggYWRkaXRpb25hbApzZW50ZW5jZXMgb24gZGV0ZXJtaW5pbmcgdGhpcy4gCgo+ICAgIDIu NS4gIFB1YmxpYyBTdWZmaXggT3BlcmF0b3IgKFBTTykKPiAKPiAgICBBIFB1YmxpYyBTdWZmaXgg T3BlcmF0b3IgbWFuYWdlcyBvcGVyYXRpb25zIHdpdGhpbiBpdHMgUFNELgo+IAo+IEJldHRlciB0 byBleHBsaWNpdGx5IGRlZmluZSB0aGUgcG9zc2Vzc2lvbiByZWxhdGlvbnNoaXAgZXhwbGljaXRs eToKPiAKPiAgICBBIFB1YmxpYyBTdWZmaXggT3BlcmF0b3IgaXMgYW4gb3JnYW5pemF0aW9uIHdo aWNoIG1hbmFnZXMKPiAgICBvcGVyYXRpb25zIHdpdGhpbiBhIFBTRCwgcGFydGljdWxhcmx5IHRo ZSBETlMgcmVjb3JkcyBwdWJsaXNoZWQgZm9yCj4gICAgbmFtZXMgYXQgYW5kIHVuZGVyIHRoYXQg ZG9tYWluIG5hbWUuCgpUaGlzIHdvcmtzIAoKPiAgICAyLjYuICBQU08gQ29udHJvbGxlZCBEb21h aW4gTmFtZXMKPiAKPiAgICBQU08gQ29udHJvbGxlZCBEb21haW4gTmFtZXMgYXJlIG5hbWVzIGlu IHRoZSBETlMgdGhhdCBhcmUgbWFuYWdlZCBieQo+ICAgIGEgUFNPIGFuZCBhcmUgbm90IGF2YWls YWJsZSBmb3IgdXNlIGFzIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMuCj4gICAgRGVwZW5kaW5nIG9u IFBTRCBwb2xpY3ksIHRoZXNlIHdpbGwgaGF2ZSBvbmUgKGUuZy4sICIuY29tIikgb3IgbW9yZQo+ ICAgIChlLmcuLCAiLmNvLnVrIikgbmFtZSBjb21wb25lbnRzLgo+IAo+IFRoZSBzZWNvbmQgc2Vu dGVuY2UgaXMgb2RkOyBpcyBpdCB1c2VmdWw/ICBJcyBpdCBqdXN0IHRvIHNheSAiUFNPCj4gQ29u dHJvbGxlZCBEb21haW4gTmFtZXMgbWF5IGhhdmUgb25lIG9yIG1vcmUgY29tcG9uZW50cy4iPwo+ IAoKWWVzLCBhIFBTTyBDb250cm9sbGVkIERvbWFpbiBOYW1lIG1heSBoYXZlIG9uZSBtb3JlIG5h bWUgY29tcG9uZW50cy4gIApIb3cgYWJvdXQ6CgoiUFNPIENvbnRyb2xsZWQgRG9tYWluIE5hbWVz IG1heSBoYXZlIG9uZSAoZS5nLiwgIi5jb20iKQpvciBtb3JlIChlLmcuLCAiLmNvLnVrIikgbmFt ZSBjb21wb25lbnRzLCBkZXBlbmRpbmcgb24gUFNEIHBvbGljeS4iCgoKPiAgICAzLjEuICBHZW5l cmFsIFVwZGF0ZXMKPiAKPiAgICBSZWZlcmVuY2VzIHRvICJEb21haW4gT3duZXJzIiBhbHNvIGFw cGx5IHRvIFBTT3MuCj4gCj4gVGhpcyBjaGFuZ2UgcmVhbGx5IG91Z2h0IHRvIGJlIGxvY2FsaXpl ZCB0byBhIHNwZWNpZmljIHRleHR1YWwgY2hhbmdlCj4gc29tZXdoZXJlIGluIFJGQyA3NDg5LCBp biB0aGUgc2F5IHdheSB0aGF0IHRoZSBvdGhlciBjaGFuZ2VzIGFyZQo+IHNwZWNpZmljIGFtZW5k bWVudHMgdG8gdGhlIERNQVJDIGFsZ29yaXRobS4KCiJEb21haW4gT3duZXIiIGlzIGRlZmluZWQg aW4gU2VjdGlvbiAzIG9mIDc0ODksIGJ1dCBQdWJsaWMgU3VmZml4IApPcGVyYXRvcnMgYW5kIFB1 YmxpYyBTdWZmaXggRG9tYWlucyBhcmVuJ3QgZGVmaW5lZCB0aGVyZS4gIApDb3VsZCB3ZSBzYXkg IkRvbWFpbiBPd25lcnMgYWxzbyBjYW4gcmVmZXIgdG8gUHVibGljIFN1ZmZpeCBPcGVyYXRvcnMK YXMgZGVmaW5lZCBpbiBbZG1hcmMtcHNkXSI/Cgo+IAo+ICAgIDMuMi4gIFNlY3Rpb24gNi4zIEdl bmVyYWwgUmVjb3JkIEZvcm1hdAo+IAo+IFRoZXNlIHNlY3Rpb24gdGl0bGVzIGFyZSBkaWZmaWN1 bHQgdG8gcmVhZC4gIEF0IGZpcnN0IEkgdGhvdWdodCB0aGVyZQo+IHdhcyBzb21lIHR5cG9ncmFw aGljYWwgcHJvYmxlbS4gIEJ1dCB5b3UgY291bGQgY2xhcmlmeSB0aGlzIGFzICIzLjIuCj4gVXBk YXRlcyB0byBTZWN0aW9uIDYuMy4gIEdlbmVyYWwgUmVjb3JkIEZvcm1hdCIuICBTaW1pbGFybHkg Zm9yIHRoZQo+IG90aGVyIHN1YnNlY3Rpb25zIG9mIHNlY3Rpb24gMy4KPiAKRG9uZS4gCgo+IDMu My4gIFNlY3Rpb24gNi41LiAgRG9tYWluIE93bmVyIEFjdGlvbnMKPiAKPiAgICBUaGUgbWVjaGFu aXNtIGZvciBkb2luZyBzbyBpcyBvbmUgb2YgdGhlCj4gICAgZXhwZXJpbWVudGFsIGVsZW1lbnRz IG9mIHRoaXMgZG9jdW1lbnQuCj4gCj4gSSB0aGluayB0aGF0IHdoYXQgdGhpcyBtZWFucyBpcyB0 aGF0IHRoZSB3aG9sZSBkb2N1bWVudCBpcyBhbgo+IGV4cGVyaW1lbnRhbCAibWVjaGFuaXNtIGZv ciBkb2luZyBzbyIuICBJZiBzbywgSSB0aGluayBpdCBjb3VsZCBiZQo+IGJldHRlciBwaHJhc2Vk Cj4gCj4gICAgVGhpcyBkb2N1bWVudCBpcyBhbiBleHBlcmltZW50YWwgbWVjaGFuaXNtIGZvciBk b2luZyBzby4KClRoaXMgaXMgYmV0dGVyIHdvcmRpbmcgZm9yIHRoaXMsIHVwZGF0ZWQuIAoKPiAt LQo+IAo+ICAgIDMuNC4gIFNlY3Rpb24gNi42LjEuICBFeHRyYWN0IEF1dGhvciBEb21haW4KPiAK PiAgICBbLi4uXSB3aGVuIHRoZSBkb21haW4gbmFtZSBleHRyYWN0ZWQgYnkgdGhlIHJlY2VpdmVy IChmcm9tIHRoZQo+ICAgIFJGQzUzMjIuRnJvbSkgaXMgb24gdGhlIHB1YmxpYyBzdWZmaXggbGlz dCB1c2VkIGJ5IHRoZSByZWNlaXZlci4KPiAKPiBUaGlzIHRvdWNoZXMgdGhlIHF1ZXN0aW9uIGFi b3ZlIGFib3V0IHdoYXQgYSBwdWJsaWMgc3VmZml4IGxpc3QgaXMsCj4gYW5kIGhvdyB0aGVyZSBj YW4gYmUgbW9yZSB0aGFuIG9uZSBvZiB0aGVtLiAgQnV0IHdpdGhvdXQgdGhhdAo+IGtub3dsZWRn ZSwgaXQncyBoYXJkIHRvIHNlZSB3aGljaCBQU0wgaXMgInVzZWQiIGJ5IHRoZSByZWNlaXZlciBv ZiB0aGUKPiBtZXNzYWdlLgo+IAo+IEFsc28sIGl0J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyAqdGhp cyogZG9jdW1lbnQgY3JlYXRlcyBhIGNhcGFiaWxpdHkKPiB3aGljaCBhcHBsaWVzIHRvIGRvbWFp bnMgdGhhdCBhcmUgb24gdGhlIFBTTC4gIEUuZy4sIGlmIGFuICJucCIgaXMKPiBkZWZpbmVkIGZv ciAiLm9yZyIsIGl0IGFwcGxpZXMgdG8gKHRoYXQgaXMsIGFmZmVjdHMgcHJvY2Vzc2luZyBvZgo+ IGUtbWFpbCBmcm9tKSBhbnkgIlgub3JnIiB0aGF0IGRvZXNuJ3QgaGF2ZSBpdHMgb3duIERNQVJD IHJlY29yZHMuICBCdXQKPiBJIGRvbid0IHNlZSBob3cgYW4gIm5wIiB0YWcgZm9yICIub3JnIiBh ZmZlY3RzIHByb2Nlc3Npbmcgb2YgbWVzc2FnZXMKPiBmcm9tICJleGFtcGxlQG9yZyIuCgoKPiAK PiAgICAzLjUuICBTZWN0aW9uIDYuNi4zLiAgUG9saWN5IERpc2NvdmVyeQo+IAo+ICAgICAgIChk aXNjdXNzZWQgaW4gdGhlIGV4cGVyaW1lbnQgZGVzY3JpcHRpb24KPiAgICAgICAoQXBwZW5kaXgg QSkpCj4gCj4gR2l2ZW4gdGhhdCB0aGlzIHRleHQgaXMgbm9taW5hbGx5IGFuIHVwZGF0ZSB0byB0 aGUgdGV4dCBvZiBSRkMgNzQ4OSwKPiB5b3Ugd2FudCB0byBkaXNhbWJpZ3VhdGUgdGhlIGJpbmRp bmcgb2YgIkFwcGVuZGl4IEEiOgo+IAo+ICAgICAgIChkaXNjdXNzZWQgaW4gdGhlIGV4cGVyaW1l bnQgZGVzY3JpcHRpb24KPiAgICAgICAoW3RoaXMgZG9jdW1lbnRdIEFwcGVuZGl4IEEpKQo+IAoK U2luY2UgdGhlc2Ugc2VjdGlvbnMgYXJlIHdyaXR0ZW4gdG8gdXBkYXRlIDc0ODksIEkgYWdyZWUg b24gcmVmZXJlbmNpbmcgCiIoW3RoaXMgZG9jdW1lbnRdIEFwcGVuZGl4IEEpIiBpbiB0aGlzIGNh c2UuICBCdXQgcmVhZGluZyBvdmVyIHRoZSB0ZXh0LCAKdGhlcmUgYXJlIHR3byByZWZlcmVuY2Vz IHRvIHNlY3Rpb24gMi4zIGluIHRoaXMgZG9jdW1lbnQgd2UnbGwgbmVlZCB0byAKdXBkYXRlIGFz IHdlbGwuIEFkZGl0aW9uYWxseSwgdXBkYXRpbmcgIkFwcGVuZGl4IEEiIGluIHNlY3Rpb24gMy4z IAoKCj4gICAgMy42LiAgU2VjdGlvbiA3LiAgRE1BUkMgRmVlZGJhY2sKPiAKPiAgICBTZWUgU2Vj dGlvbiA0IG9mIHRoaXMgZG9jdW1lbnQgZm9yIGRpc2N1c3Npb24gb2YgUHJpdmFjeQo+ICAgIENv bnNpZGVyYXRpb25zLgo+IAo+IFNpbWlsYXJseSB0byBzZWN0aW9uIDMuNSwgYnV0IGFsc28gY2xh cmlmeWluZyB0aGUgc2NvcGUgb2YgInByaXZhY3kKPiBjb25zaWRlcmF0aW9ucyI6Cj4gCj4gICAg U2VlIFNlY3Rpb24gNCBvZiBbdGhpcyBkb2N1bWVudF0gZm9yIGRpc2N1c3Npb24gb2YgUHJpdmFj eQo+ICAgIENvbnNpZGVyYXRpb25zIGZvciBQU0QgRE1BUkMuCgpBZ3JlZWQsIGFuZCB1cGRhdGVk Cgo+ICAgIDQuICBQcml2YWN5IENvbnNpZGVyYXRpb25zCj4gCj4gICAgVGhlIFByaXZhY3kgQ29u c2lkZXJhdGlvbnMgb2YgW1JGQzc0ODldIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQuCj4gCj4gVGhp cyBjb3VsZCBiZSBjbGFyaWZpZWQgYXMKPiAKPiAgICBBZGRpdGlvbmFsbHksIHRoZSBQcml2YWN5 IENvbnNpZGVyYXRpb25zIG9mIFtSRkM3NDg5XSBhcHBseSB0byB0aGUKPiAgICBtZWNoYW5pc21z IGRlc2NyaWJlZCBieSB0aGlzIGRvY3VtZW50LgoKQWdyZWVkLCBhbmQgdXBkYXRlZCAKCj4gLS0K PiAKPiAgICBQcm92aWRpbmcgZmVlZGJhY2sgcmVwb3J0aW5nIHRvIFBTT3MgY2FuLCBpbiBzb21l IGNhc2VzLCBjcmVhdGUKPiAgICBsZWFrYWdlIG9mIGluZm9ybWF0aW9uIG91dHNpZGUgb2YgYW4g b3JnYW5pemF0aW9uIHRvIHRoZSBQU08uCj4gCj4gIm91dHNpZGUiIHByb2JhYmx5IGlzbid0IHRo ZSB3b3JkIHlvdSB3YW50IHRvIHVzZSBoZXJlLCBhcyBpdCBpcwo+IGVhc2llciB0byByZWFkICJv dXRzaWRlIiBhcyBnaXZpbmcgdGhlIG9yaWdpbmFsIGxvY2F0aW9uIG9mCj4gImluZm9ybWF0aW9u IiB0aGFuIHRvIHJlYWQgIm91dHNpZGUiIGFzIGdpdmluZyB0aGUgZGlyZWN0aW9uIG9mCj4gImxl YWthZ2UiLiAgUGVyaGFwcwo+IAo+ICAgIFByb3ZpZGluZyBmZWVkYmFjayByZXBvcnRpbmcgdG8g UFNPcyBjYW4sIGluIHNvbWUgY2FzZXMsIGNyZWF0ZQo+ICAgIGxlYWthZ2Ugb2YgaW5mb3JtYXRp b24gb3V0IG9mIGFuIG9yZ2FuaXphdGlvbiB0byB0aGUgUFNPIG9mIGl0cwo+ICAgIGRvbWFpbiBu YW1lLgoKV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhpczoKCiJQcm92aWRpbmcgZmVlZGJhY2sgcmVw b3J0aW5nIHRvIFBTT3MgY2FuLCBpbiBzb21lIGNhc2VzLCBjcmVhdGUgaW5mb3JtYXRpb24gCnRv IGxlYWsgb3V0IG9mIGFuIG9yZ2FuaXphdGlvbiB0byB0aGUgUFNPLiAiCgotLS0tCgo+IC0tCj4g Cj4gICAgVG8gbWluaW1pemUgdGhpcyBwb3RlbnRpYWwgY29uY2VybiwKPiAgICBQU0QgRE1BUkMg ZmVlZGJhY2sgaXMgYmVzdCBsaW1pdGVkIHRvIEFnZ3JlZ2F0ZSBSZXBvcnRzLiAgWy4uLl0KPiAK PiAgICBbLi4uXSBhbnkgRmVlZGJhY2sgUmVwb3J0aW5nIHJlbGF0ZWQgdG8gbXVsdGktCj4gICAg b3JnYW5pemF0aW9uYWwgUFNEcyBvdWdodCB0byBiZSBsaW1pdGVkIHRvIG5vbi1leGlzdGVudCBk b21haW5zCj4gICAgZXhjZXB0IGluIGNhc2VzIHdoZXJlIHRoZSByZXBvcnRlciBrbm93cyB0aGF0 IFBTTyByZXF1aXJlcyB1c2Ugb2YKPiAgICBETUFSQy4KPiAKPiBJIGNhbid0IHNlZSB3aGVyZSBp biB0aGUgZG9jdW1lbnQgdGhhdCB0aGVzZSBwcmluY2lwbGVzIGFyZSB0dXJuZWQKPiBpbnRvIE1V U1Qgc3RhdGVtZW50cyB0aGF0IGVuc3VyZSB0aGUgcHJpdmFjeSBpc3N1ZXMgYXJlIHNvbHZlZC4K PiAKCkhvdyBhYm91dCB0aGVzZSB0d28gc3RhdGVtZW50czoKCk9sZDoKICAgICJUbyBtaW5pbWl6 ZSB0aGlzIHBvdGVudGlhbCBjb25jZXJuLCBQU0QgRE1BUkMgZmVlZGJhY2sgaXMgYmVzdCBsaW1p dGVkIHRvIAogICAgQWdncmVnYXRlIFJlcG9ydHMuICIKCk5ldzoKICAgICJUbyBtaW5pbWl6ZSB0 aGlzIHBvdGVudGlhbCBjb25jZXJuLCBQU0QgRE1BUkMgZmVlZGJhY2sgU0hPVUxEIGJlIGxpbWl0 ZWQgCiAgICB0byBBZ2dyZWdhdGUgUmVwb3J0cy4iCgphbmQKCk9sZDoKCiAgIERNQVJDIGZvciBP cmdhbml6YXRpb25hbCBEb21haW5zIGluIG11bHRpLW9yZ2FuaXphdGlvbiBQU0RzIHRoYXQgZG8K ICAgbm90IHBhcnRpY3BhdGUgaW4gRE1BUkMsIGFueSBGZWVkYmFjayBSZXBvcnRpbmcgcmVsYXRl ZCB0byBtdWx0aS0KICAgb3JnYW5pemF0aW9uYWwgUFNEcyBvdWdodCB0byBiZSBsaW1pdGVkIHRv IG5vbi1leGlzdGVudCBkb21haW5zCgpOZXc6CgogICBETUFSQyBmb3IgT3JnYW5pemF0aW9uYWwg RG9tYWlucyBpbiBtdWx0aS1vcmdhbml6YXRpb24gUFNEcyB0aGF0IGRvCiAgIG5vdCBwYXJ0aWNw YXRlIGluIERNQVJDLCBhbnkgRmVlZGJhY2sgUmVwb3J0aW5nIHJlbGF0ZWQgdG8gbXVsdGktCiAg IG9yZ2FuaXphdGlvbmFsIFBTRHMgTVVTVCBiZSBsaW1pdGVkIHRvIG5vbi1leGlzdGVudCBkb21h aW5zCgoKPiAgICBUaGUgZXhwZXJpbWVudCBpcyB0byBldmFsdWF0ZSBkaWZmZXJlbnQgcG9zc2li bGUgYXBwcm9hY2hlcy4KPiAKPiBDYWxsaW5nIHRoaXMgYW4gImV4cGVyaW1lbnQiIHN1Z2dlc3Rz IHRoYXQgdGhlc2UgaXMgYW4gaW50ZW5kZWQgc2VyaWVzCj4gb2YgYWN0aW9ucyB3aG9zZSByZXN1 bHQgd2lsbCBhbnN3ZXIgdGhlIGxpc3RlZCBxdWVzdGlvbnMuICBCdXQgdGhlcmUKPiBkb2Vzbid0 IHNlZW0gdG8gYmUgYW55IHN1Y2ggYWN0aW9ucyBsaXN0ZWQuICBUaGUgZGVzY3JpcHRpb24gbWFr ZXMgaXQKPiBzb3VuZCBsaWtlIHdoYXQgaXMgaW50ZW5kZWQgaXMgY29udGludWluZyBkaXNjdXNz aW9ucyBpbiB0aGUgd29ya2luZwo+IGdyb3VwLCBidXQgdGhhdCB3b3VsZG4ndCBiZSBhbiAiZXhw ZXJpbWVudCIuCj4gCj4gQS4yLiAgTm9uLUV4aXN0ZW50IFN1YmRvbWFpbiBQb2xpY3kKPiAKPiBT aW1pbGFyIHF1ZXN0aW9ucyBhcmlzZSBmb3IgdGhpcyBzZWN0aW9uLiAgVGhlIHNlY29uZCBwYXJh Z3JhcGgKPiBzdWdnZXN0cyB0aGF0IHRoZSBleHBlcmltZW50IGlzIHRvIHNlZSB3aGV0aGVyIHRo ZSAibnAiIHRhZyBpcwo+IHN1Y2Nlc3NmdWwuCj4gCj4gICAgVGhlcmUgYXJlIGFsc28KPiAgICBz dWdnZXN0aW9ucyB0aGF0IGl0IHdvdWxkIGJlIG1vcmUgZ2VuZXJhbGx5IHVzZWZ1bCBmb3IgRE1B UkMuCj4gCj4gV2hhdCBkb2VzICJpdCIgcmVmZXIgdG8/ICAoRG9lcyBpdCBtZWFuICJ0aGlzIGFi aWxpdHkiPykKPiAKPiBBcHBlbmRpeCBCLiAgRE1BUkMgUFNEIFJlZ2lzdHJ5IEV4YW1wbGVzCj4g Cj4gSW4gdGhpcyBhcHBlbmRpeCwgaXQgYXBwZWFycyB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUg ZXhwZXJpbWVudCBhcmUKPiBjbGVhciBpbiB0aGUgYXV0aG9ycycgbWluZHMsIGJ1dCB0aGVyZSBp cyBubyBzdW1tYXJ5IGF0IHRoZSB0b3AgdGhhdAo+IHN0YXRlcyB3aGF0IHRoZSBleHBlcmltZW50 YWwgZmFjaWxpdGllcyBhcmUgYW5kIHRoZSAiYmlnIHBpY3R1cmUiIGludG8KPiB3aGljaCB0aGV5 IGZpdC4KPiAKPiBBcHBlbmRpeCBDLiAgSW1wbGVtZW50YXRpb25zCj4gCj4gICAgQy4xLiAgQXV0 aGhlYWRlcnMgTW9kdWxlCj4gCj4gV2hhdCBlLW1haWwgTVRBIGlzIEF1dGhoZWFkZXJzIGFuIGV4 dGVuc2lvbiBmb3I/Cj4gCj4gW0VORF0K --0000000000006e2fae05b144cdb1-- From nobody Sun Oct 11 02:52: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 78EC23A0475 for ; Sun, 11 Oct 2020 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 K7aUKm8cY7cn for ; Sun, 11 Oct 2020 02:52:25 -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 ED2D93A045E for ; Sun, 11 Oct 2020 02:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602409942; bh=DmK6dOm4U7L0JoAiZFsEG+1ibgsuYOkGdoSOx7eaaYU=; l=945; h=To:References:From:Date:In-Reply-To; b=DYP89q16bDy6FsEeALZ1m4JSfPy/kyqt27wGcK9A0R4XPjwzCW0c/EN6N2/XTFL3H Wurwcd7rGxL4R1TwUE32cZ0lWyXiFY7XGkyVLrMVxTvWTMGEm8bvm5PYPB1T/zmOG/ uJJJYhYQIXu9FTMK7MUwQbfZ/XIJxmzKtTzEILU3z7MRtWhYRtPxC14kDmOca 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.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005F82D5D6.00005BBC; Sun, 11 Oct 2020 11:52:22 +0200 To: dmarc@ietf.org References: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> <871rogwc0h.fsf@hobgoblin.ariadne.com> From: Alessandro Vesely Message-ID: Date: Sun, 11 Oct 2020 11:52:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 09:52:27 -0000 On Sat 10/Oct/2020 00:52:14 +0200 Tim Wicinski wrote: > > Here's the link to the diff. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 For a nit: o Provides controls to mitigate potential privacy considerations associated with this extension I don't think one would mitigate considerations. Either address considerations, or mitigate leakage. In Section 4.1: OLD: Feedback Reports carry more detailed information and present a greater risk. NEW: Failure Reports carry more detailed information and present a greater risk. The title of Appendix A is misleading. The experiment is not limited to privacy concerns. Shouldn't it be entitled just "The Experiment"? Later in Appendix A: o Section 3.2 modifies policy discovery to add an additional DNS lookup. Isn't that Section 3.5 «Changes in Section 6.6.3 "Policy Discovery"»? Best Ale -- From nobody Sun Oct 11 03:00:10 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 324D13A0808 for ; Sun, 11 Oct 2020 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQVvGHrBL8fX for ; Sun, 11 Oct 2020 03:00:07 -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 D00783A07F9 for ; Sun, 11 Oct 2020 03:00:06 -0700 (PDT) Received: (qmail 26661 invoked by uid 100); 11 Oct 2020 10:00:05 -0000 Date: 11 Oct 2020 09:59:42 -0000 Message-ID: <20201011095942.26641.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 11 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 10:00:08 -0000 Count | Bytes | Who ------------+----------------+------- 3 (25.0%) | 13231 (10.2%) | John Levine 2 (16.7%) | 26570 (20.5%) | Douglas E. Foster 2 (16.7%) | 23416 (18.1%) | Jesse Thompson 2 (16.7%) | 8551 ( 6.6%) | Alessandro Vesely 1 ( 8.3%) | 33575 (25.9%) | Tim Wicinski 1 ( 8.3%) | 17107 (13.2%) | Ken O'Driscoll 1 ( 8.3%) | 7247 ( 5.6%) | Vittorio Bertola From nobody Tue Oct 13 04:06: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 CB5A83A0F36 for ; Tue, 13 Oct 2020 04:06:53 -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, 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=VMMcQZ29; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nPcpKZdg 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 VM1IniJxTAuv for ; Tue, 13 Oct 2020 04:06:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B443A0F33 for ; Tue, 13 Oct 2020 04:06:52 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ADA4A5C00C2 for ; Tue, 13 Oct 2020 07:06:51 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 13 Oct 2020 07:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=Z3zUG/4j8omJgqMtU5WtVO1ag7BCZrJQ84jqOGCYAzw=; b=VMMcQZ29 ZkxEppWc6q2H2bQdqfrrbPDxmv4PwIF85LGPHGYm17RHZTKtqwPINLmfNtuF787L sN9o2vGKt2l+GYavnsWUw8TWGqLxp+6ceBUOUCMOi0v57aiXJEfvOzX9A34JlGjW z4CVoqtm3Po90WBYYuRKf8fjxDdMTQBMGQpgDKdN5Jruo1zBlV+01rmkHdCRq3oN zN9r+k/nCWNfljcnoyY921UHXtlDwvxqNMsdKMebZ62QiHAG0/ubh8AN0pWOcSrT SCThGC78MAViOqaJdPDywarHzOYby71eE66X6QAY83vNq9Kes//pYO9XjNUmIP03 zn6qDIdN3pk3RA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Z3zUG/4j8omJgqMtU5WtVO1ag7BCZ rJQ84jqOGCYAzw=; b=nPcpKZdgwRLdaF0+apBtsxqOD62MvOTPokFHPgetL7hH6 r+xy/JurqapmHMOUzY0WlCBprhP+esBfJCn/P9VHEBBo6E0PKY8GWWs37C+yIgap KyRgkBvZPUMzkSQXdcniI+MpElJF0N6ET9BnvTonQj5IHLWgg2OVNDUT7bygfwri eoRDdn298x59ebjZCr5yavu8zXtJIQ4xK66z1pALgzzTsSYzfrQVC08KJwvbdfEk sIpddhyf3jQtEqeKPrqpthHgatmG0Yh2uudnAuc+DlxatSleID6BHG0SwjBpL/sc 0Pex1rBKmGBSeoAuBAxqrXbSi9i2MfrzkYE8Ys5lQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheelgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepheefvdelhfdthf ekveeilefgtdelffegueejuddttefhieegjeekiedtkedtjefgnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrg hsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5E563660069; Tue, 13 Oct 2020 07:06:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-407-g461656c-fm-20201004.001-g461656c6 Mime-Version: 1.0 Message-Id: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> Date: Tue, 13 Oct 2020 12:06:32 +0100 From: "Alexey Melnikov" To: dmarc@ietf.org Content-Type: text/plain Archived-At: Subject: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:06:54 -0000 Dear DMARC WG participants, I would like your feedback on resolving the following ABNF issue: In Section 6.4 "dmarc-record" is defined as: 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 Note that dmarc-request is listed as optional field here. In Section 6.3: p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). >From the above it is clear that dmarc-request is required in some cases and optional in others. In Section 6.6.3: Item 6: 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; So, we should clarify under what conditions "dmarc-record" is optional. I can see a couple of ways of resolving this (there might be other better ways): 1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 different uses and different optionality of "dmarc-record" for them. 2) Make this more explicit and define dmarc-record = dmarc-policy-record / dmarc-reporting-record where dmarc-policy-record would require "dmarc-record" and dmarc-reporting-record shows it as optional. Opinions? Best Regards, Alexey, as a co-chair P.S. If you can provide your feedback by October 27th (2 weeks), that would be much appreciated. From nobody Tue Oct 13 09:12: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 3F6373A011D for ; Tue, 13 Oct 2020 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=ju/Oyg5y; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=rglg2DnY 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 nyhQXwUe13JP for ; Tue, 13 Oct 2020 09:12:45 -0700 (PDT) Received: from mail.winserver.com (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 C5DC13A086B for ; Tue, 13 Oct 2020 09:12:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3909; t=1602605559; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Bud51vAWyYN+mKJkiZygNKFgiLE=; b=ju/Oyg5yXCV3fmomwZHNsESqxGwKTOBsNI9K6kgNjM+RcARyRKG2mxfmIVdTHh bvJMLKxUqqI3xU0+rNxZqSNcXMUoVjxyP8+yJYnA5KLVDlc79htTXFyHtQcI1hL+ 2Zcjp62O1DrzRNc7rUkaoJO0CTjHzzGXk026awfHyxXAQ= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 13 Oct 2020 12:12:39 -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 mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 340666467.1.1004; Tue, 13 Oct 2020 12:12:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3909; t=1602605314; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=v/GNxEc SrZcQEwkWE3dTIcA8N4CbTNxMUzNHiHa7PfQ=; b=rglg2DnYvUzefeRWKUCanj9 RZJDP0YWhEvKfKohz5ax5sG2MSKO/84fCy9/BNXj+q3J/z1iTQW0eJGDNaAoUSdw 0QTobsrw9OMZRkz0nv0iOm36evUrV2iOVUxc3G6xXFYPkHkngKzg7y2cc40QjTSS KtJS6IVb7ZU4YuFpgx4c= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 13 Oct 2020 12:08:34 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 207586250.1.4980; Tue, 13 Oct 2020 12:08:33 -0400 Message-ID: <5F85D1F3.8020800@isdg.net> Date: Tue, 13 Oct 2020 12:12:35 -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: Alexey Melnikov , dmarc@ietf.org References: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> In-Reply-To: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 16:12:47 -0000 Hi Alexey, Not direct to "slightly wrong" question but related to the ABNF nonetheless. Maybe a need new Ticket? We need a consideration for extended tags in ABNF. The 3.1.3 text supports extensions. 3.1.3. Alignment and Extension Technologies If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. Using Extended Tags is a reality and in practice for many years, "running code", i.e. ATPS (rfc6541), it is part of the Wildcat! Mail/DKIM package and rest assured more are coming. How would extended tags be described be the ABNF? It currently says: ; components other than dmarc-version and ; dmarc-request may appear in any order Can we clarify or define "components" and state it may include extended tags such as adding to the ABNF [dmarc-sep dmarc-extended-tag] For an implementor note, a few days ago, I came across an GUI Zone Manager which had a specific form input for adding and editing DMARC TXT records. The form editor had DMARC documented fields with their options. You had to go into GUI's raw edit mode option to add extended tags and this was supported. Since the editor did not recognize the tag, it disabled the form Editor and only allowed the raw field editor. Nice job. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 10/13/2020 7:06 AM, Alexey Melnikov wrote: > Dear DMARC WG participants, > > I would like your feedback on resolving the following ABNF issue: > > In Section 6.4 "dmarc-record" is defined as: > > 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 > > Note that dmarc-request is listed as optional field here. > > In Section 6.3: > > p: Requested Mail Receiver policy (plain-text; REQUIRED for policy > records). Indicates the policy to be enacted by the Receiver at > the request of the Domain Owner. Policy applies to the domain > queried and to subdomains, unless subdomain policy is explicitly > described using the "sp" tag. This tag is mandatory for policy > records only, but not for third-party reporting records (see > Section 7.1). > >>From the above it is clear that dmarc-request is required in some cases and optional in others. > > In Section 6.6.3: > > Item 6: > > 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; > > So, we should clarify under what conditions "dmarc-record" is optional. > > I can see a couple of ways of resolving this (there might be other better ways): > > 1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 different uses and different optionality of "dmarc-record" for them. > > 2) Make this more explicit and define > > dmarc-record = dmarc-policy-record / dmarc-reporting-record > > where dmarc-policy-record would require "dmarc-record" and dmarc-reporting-record shows it as optional. > > Opinions? > > Best Regards, > Alexey, as a co-chair > > P.S. If you can provide your feedback by October 27th (2 weeks), that would be much appreciated. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Oct 13 11:37: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 CE48E3A0EA7 for ; Tue, 13 Oct 2020 11:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkUirdNP5CXY for ; Tue, 13 Oct 2020 11:37:05 -0700 (PDT) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 C92913A0E9F for ; Tue, 13 Oct 2020 11:37:04 -0700 (PDT) Received: by mail-oo1-xc2a.google.com with SMTP id f2so132542ooj.2 for ; Tue, 13 Oct 2020 11:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K91IqEqwQw0BxpB8C+jSggXKu6Lfu6sbgqRiiF18xIk=; b=lRMd5aLBPzEiJ6HGV6ZRHM4xVBt+NETfHPCaJkzgqcesHgyD0tveUd9e8Gy/zUBCuq sfPqrM6uUrwhoHvwe7hQezwxnhpJ3UAnVIAyqV41wqMNJGK+GPtns4T49yDSWLxYajUo IU4QB7PLtBbMDo1b9V5owwHDOX9SqNDGQqtyrNbVP0xO7tSYJgobUI74JA1xGSCpQ676 sB8mcDzwNP5bnVJ+2H3pbmAa1pHy2GjuV2gOoi/Ww+thxvJcFeofgfMQb87vdscCCWlp H5no/jJCIirb0uOSzZ7eqdFtAfwuKQWgMaRKNSoNe9umgjbjcePfn14SA2990/1dcFR3 NGFw== 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=K91IqEqwQw0BxpB8C+jSggXKu6Lfu6sbgqRiiF18xIk=; b=UPhPBfLUQzklp5dQtmwCXD7uRUbukRkqH5T5vcXtg3U+vjcW77l/LIUdJLNlw4EgfF 8netdqmYJ3wbfx0rs5LPVy/ZxmjcCoVz3XqUopaIxXMQNMSB7XteLSSHFGytuLP4Zo1V TOO5QkRKDSMBTCblZG2ZQ7PN0oVjUytRUEpaS0Z7DpsPSQx4UgR/E9He7xWJYcOxJktA c58EJYgU6YNLGge0KKCFMVXVNTS1CeLVXotBYnSBkfoTWaJUBQfGYIEMBCY3+mAZa64c OLS0zWaEuguN2MGDWEjgSf4FSaQSlLC4FoOCvcIviFFW9EslgvQD+Hyk4WnycAWQLDv4 G66g== X-Gm-Message-State: AOAM533YOqgHZ5z0OQ3YtOR+ueGO4o9pD6eua+jESXBlDwzuD23JFqDy 8AK+rchdTz6H4xGLy2IUHLeUPQJ01iywcaTYkQlcrA== X-Google-Smtp-Source: ABdhPJwgRGLN0F3s/3rrpna0L6NQymiTMw4kXlseL5sIRY3wKwSvI6JXs119eyvcepWKCP7ean9pY67wlsUuoyQ9A9E= X-Received: by 2002:a4a:c54:: with SMTP id n20mr544895ooe.66.1602614223777; Tue, 13 Oct 2020 11:37:03 -0700 (PDT) MIME-Version: 1.0 References: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> <5F85D1F3.8020800@isdg.net> In-Reply-To: <5F85D1F3.8020800@isdg.net> From: Seth Blank Date: Tue, 13 Oct 2020 11:36:47 -0700 Message-ID: To: hsantos@isdg.net Cc: Alexey Melnikov , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000854a6c05b191b32d" Archived-At: Subject: Re: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 18:37:07 -0000 --000000000000854a6c05b191b32d Content-Type: text/plain; charset="UTF-8" On Tue, Oct 13, 2020 at 9:12 AM Hector Santos wrote: > Hi Alexey, > > Not direct to "slightly wrong" question but related to the ABNF > nonetheless. Maybe a need new Ticket? > Yes, please create a new ticket. > > We need a consideration for extended tags in ABNF. The 3.1.3 text > supports extensions. > > 3.1.3. Alignment and Extension Technologies > > If in the future DMARC is extended to include the use of other > authentication mechanisms, the extensions will need to allow for > domain identifier extraction so that alignment with the RFC5322.From > domain can be verified. > > Using Extended Tags is a reality and in practice for many years, > "running code", i.e. ATPS (rfc6541), it is part of the Wildcat! > Mail/DKIM package and rest assured more are coming. > > How would extended tags be described be the ABNF? It currently says: > > ; components other than dmarc-version and > ; dmarc-request may appear in any order > > Can we clarify or define "components" and state it may include > extended tags such as adding to the ABNF > > [dmarc-sep dmarc-extended-tag] > > For an implementor note, a few days ago, I came across an GUI Zone > Manager which had a specific form input for adding and editing DMARC > TXT records. The form editor had DMARC documented fields with their > options. You had to go into GUI's raw edit mode option to add > extended tags and this was supported. Since the editor did not > recognize the tag, it disabled the form Editor and only allowed the > raw field editor. Nice job. > > -- > Hector Santos, > https://secure.santronics.com > https://twitter.com/hectorsantos > > > On 10/13/2020 7:06 AM, Alexey Melnikov wrote: > > Dear DMARC WG participants, > > > > I would like your feedback on resolving the following ABNF issue: > > > > In Section 6.4 "dmarc-record" is defined as: > > > > 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 > > > > Note that dmarc-request is listed as optional field here. > > > > In Section 6.3: > > > > p: Requested Mail Receiver policy (plain-text; REQUIRED for policy > > records). Indicates the policy to be enacted by the Receiver at > > the request of the Domain Owner. Policy applies to the domain > > queried and to subdomains, unless subdomain policy is explicitly > > described using the "sp" tag. This tag is mandatory for policy > > records only, but not for third-party reporting records (see > > Section 7.1). > > > >>From the above it is clear that dmarc-request is required in some cases > and optional in others. > > > > In Section 6.6.3: > > > > Item 6: > > > > 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; > > > > So, we should clarify under what conditions "dmarc-record" is optional. > > > > I can see a couple of ways of resolving this (there might be other > better ways): > > > > 1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 different > uses and different optionality of "dmarc-record" for them. > > > > 2) Make this more explicit and define > > > > dmarc-record = dmarc-policy-record / dmarc-reporting-record > > > > where dmarc-policy-record would require "dmarc-record" and > dmarc-reporting-record shows it as optional. > > > > Opinions? > > > > Best Regards, > > Alexey, as a co-chair > > > > P.S. If you can provide your feedback by October 27th (2 weeks), that > would be much appreciated. > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > -- > Hector Santos, > https://secure.santronics.com > https://twitter.com/hectorsantos > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000854a6c05b191b32d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 13, 2020 at 9:12 AM Hector Sa= ntos <hsantos=3D40isdg.net@= dmarc.ietf.org> wrote:
Hi Alexey,

Not direct to "slightly wrong" question but related to the ABNF <= br> nonetheless.=C2=A0 Maybe a need new Ticket?

=

Yes, please create a new ticket.


=C2=A0

We need=C2=A0 a consideration for extended tags in ABNF.=C2=A0 The 3.1.3 te= xt
supports extensions.

3.1.3.=C2=A0 Alignment and Extension Technologies

=C2=A0 =C2=A0 If in the future DMARC is extended to include the use of othe= r
=C2=A0 =C2=A0 authentication mechanisms, the extensions will need to allow = for
=C2=A0 =C2=A0 domain identifier extraction so that alignment with the RFC53= 22.From
=C2=A0 =C2=A0 domain can be verified.

Using Extended Tags is a reality and in practice for many years,
"running code", i.e. ATPS (rfc6541), it is part of the Wildcat! <= br> Mail/DKIM package and rest assured more are coming.

How would extended tags be described be the ABNF?=C2=A0 It currently says:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; components other than dmarc-vers= ion and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; dmarc-request may appear in any = order

Can we clarify or define "components" and state it may include extended tags such as adding to the ABNF

[dmarc-sep dmarc-extended-tag]

For an implementor note, a few days ago, I came across an GUI Zone
Manager which had a specific form input for adding and editing DMARC
TXT records. The form editor had DMARC documented fields with their
options.=C2=A0 You had to go into GUI's raw edit mode option to add extended tags and this was supported.=C2=A0 Since the editor did not
recognize the tag, it disabled the form Editor and only allowed the
raw field editor.=C2=A0 Nice job.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


On 10/13/2020 7:06 AM, Alexey Melnikov wrote:
> Dear DMARC WG participants,
>
> I would like your feedback on resolving the following ABNF issue:
>
> In Section 6.4 "dmarc-record" is defined as:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dmarc-record=C2=A0 =C2=A0 =3D dmarc-version = dmarc-sep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-request]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-srequest]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-auri]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-furi]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-adkim]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-aspf]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-ainterval]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-fo]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-rfmt]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep dmarc-percent]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[dmarc-sep]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0; components other than dmarc-version and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0; dmarc-request may appear in any order
>
> Note that dmarc-request is listed as optional field here.
>
> In Section 6.3:
>
>=C2=A0 =C2=A0 =C2=A0p: Requested Mail Receiver policy (plain-text; REQU= IRED for policy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 records).=C2=A0 Indicates the policy to be = enacted by the Receiver at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the request of the Domain Owner.=C2=A0 Poli= cy applies to the domain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 queried and to subdomains, unless subdomain= policy is explicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 described using the "sp" tag.=C2= =A0 This tag is mandatory for policy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 records only, but not for third-party repor= ting records (see
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 7.1).
>
>>From the above it is clear that dmarc-request is required in some c= ases and optional in others.
>
> In Section 6.6.3:
>
>=C2=A0 =C2=A0Item 6:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 if a "rua" tag is = present and contains at least one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syntactically valid rep= orting URI, the Mail Receiver SHOULD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0act as if a record cont= aining a valid "v" tag and "p=3Dnone"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was retrieved, and cont= inue processing;
>
> So, we should clarify under what conditions "dmarc-record" i= s optional.
>
> I can see a couple of ways of resolving this (there might be other bet= ter ways):
>
> 1) Add a clarifying ABNF comment in Section 6.4 pointing out 2 differe= nt uses and different optionality of "dmarc-record" for them.
>
> 2) Make this more explicit and define
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dmarc-record=C2=A0 =C2=A0 =3D dmarc-policy-r= ecord / dmarc-reporting-record
>
> where dmarc-policy-record would require "dmarc-record" and d= marc-reporting-record shows it as optional.
>
> Opinions?
>
> Best Regards,
> Alexey, as a co-chair
>
> P.S. If you can provide your feedback by October 27th (2 weeks), that = would be much appreciated.
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000854a6c05b191b32d-- From nobody Wed Oct 14 01:57: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 AA14B3A1419 for ; Wed, 14 Oct 2020 01:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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 jHfLvIRhdVWX for ; Wed, 14 Oct 2020 01:56: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 85F2A3A1418 for ; Wed, 14 Oct 2020 01:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1602665813; bh=UQHonNea4UEecEMWx8k6gS2cY1PcIGDrBYJf+G775tU=; l=1783; h=To:References:From:Date:In-Reply-To; b=BLamxl6AUm4TzDZ1mJzokv6vcTCDRGiqRrh2EgpK3L11t+va++THjLeIbT0LaoViz IIMEtTAGfk9eFQ63M9QduLH8EQUECEv+7pxjmyJ1GWXR5CPveYwPlv9Y85+lN6HIW3 UcW7hsG4OWGad0Yv+Y4jW9UBLGlRvLep5EwFPtxCIzD64A7ZY246VADDftoCZ 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.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F86BD55.00004ABC; Wed, 14 Oct 2020 10:56:53 +0200 To: dmarc@ietf.org References: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> From: Alessandro Vesely Message-ID: Date: Wed, 14 Oct 2020 10:56:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <3d8d69f1-1cbe-4737-a8a1-c349d0759004@www.fastmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ticket #7: ABNF for dmarc-record is slightly wrong X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 08:57:00 -0000 On Tue 13/Oct/2020 13:06:32 +0200 Alexey Melnikov wrote: > > In Section 6.4 "dmarc-record" is defined as: > > 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 > > Note that dmarc-request is listed as optional field here. There was some discussion on this question in the framework of ticket #49, about May. IMHO, it is better to let the policy be optional, thereby keeping a unique definition of dmarc-record.[*] For one thing, an empty DMARC record, like those which confirm external destinations, provides for better caching than no DMARC record at all. Of course, the existence of an empty DMARC record doesn't have to imply that DMARC is "implemented" at the site, that's a different question. > In Section 6.3: > > p: Requested Mail Receiver policy (plain-text; REQUIRED for policy > records). Indicates the policy to be enacted by the Receiver at > the request of the Domain Owner. Policy applies to the domain > queried and to subdomains, unless subdomain policy is explicitly > described using the "sp" tag. This tag is mandatory for policy > records only, but not for third-party reporting records (see > Section 7.1). > > From the above it is clear that dmarc-request is required in some cases and optional in others. Unneeded complication. Best Ale -- [*] alternative syntax proposed at: https://mailarchive.ietf.org/arch/msg/dmarc/tRjV69kdM6XzkiIb3ceZ2T8OWK8/ From nobody Wed Oct 14 11:17: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 CFB633A0BE3 for ; Wed, 14 Oct 2020 11:17:41 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=YrDh2y3S; dkim=pass (2048-bit key) header.d=comcast.com header.b=6IENcn7x; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=ihm6ZcS0 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 8z7--wIAxAmV for ; Wed, 14 Oct 2020 11:17:40 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBE63A0BAE for ; Wed, 14 Oct 2020 11:17:40 -0700 (PDT) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09EIFHxR032261 for ; Wed, 14 Oct 2020 14:17:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=20190412; bh=RXKpipqnsi0PF3SUoVRT+BQF3jWF4ujjyWmPpUPVFKU=; b=YrDh2y3S40jK0bUx7vmxE97s5bZB8aHVwkhbH1avZ+Y0MO0bHQjArPmzXDIbzKBzQAlD 7SFD/t93oO+9UEMecIKExOuabHHN9Ci5DG55cnTADHo3KDWg9G/OkCKi/HE3b8jsZosi 8MC0/gm2QvEYXt8ssp2fYAU526JxTdk5OV/1WNUCSsBZqVmKgCD6uKvbjqFGPMAqPlgh BsiEFeeX2nXlK0AvFfW+dL0U60Dw7LNCkEVrnbZSyhDhlzS10LfOWl82Hn8GhRoK8E3m pg/33lRaBsrcO1bsBxD7Up4H0d7r3hbuwZTbbwd++ZpvxUo2XkUMBTjyPwiyjfRZ1ZQc hg== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 34368y1b48-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 14 Oct 2020 14:17:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1602699459; x=2466613059; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=REJ/OXhDoye/VDcG1MJiTwvXnkJ0dAPDTsbkrp3aYo0=; b=6IENcn7xwy7UPTAJjG2HMlal7JoNLR7KRPu2mglw3QCi5CkYK61ozcv5clUTvUWw jB/ApJ6jK5mGZaB0d3X5BEFwMDfrnr7/hy++O5ETw6k18UMzxSCDH3mIr3Pym/Ii ++gJ1O3Q9vJHnMsNT8/Ff+YG0BAEp59rr3LlmZ/1Ov89KtKfp67wAG2OZIejDjQ5 lsOxIwQa0f4vJln7gNJQe+bJnZZPOyReKQMHVUELZ3Cm8PBRu21QLzQKMcXL+fU/ Fu3huiBZUjExSEXyehdpO4zSQgiX2SqQm0bqpY2/osBa7QZP0F+nnIRY8eFxvut7 CZ5gQNIOP/rmlTntf7bl7w==; X-AuditID: 60729ed4-aabff7000000b5b5-2b-5f8740c32d34 Received: from COPDCEX11.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id ED.A9.46517.3C0478F5; Wed, 14 Oct 2020 12:17:39 -0600 (MDT) Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEX11.cable.comcast.com (147.191.124.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 14 Oct 2020 12:17:38 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 14 Oct 2020 12:17:38 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.56) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 14 Oct 2020 14:17:23 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4335.namprd11.prod.outlook.com (2603:10b6:208:18d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.28; Wed, 14 Oct 2020 18:17:22 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3477.020; Wed, 14 Oct 2020 18:17:22 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: Thoughts on "Senders DMARC" Reports Thread-Index: AdaiVc1hNC32VOspTmuLojW6xIuQgA== Date: Wed, 14 Oct 2020 18:17:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:90ec:6b04:ce3e:7102] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42744d45-0790-422d-a572-08d8706d6547 x-ms-traffictypediagnostic: MN2PR11MB4335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qGDj9k/OjQN8XW1dWT653DK7R2EO8XFg/kExcYKdTeHAifpodEJssUaUrKvR/kS7AVCMhlnJhV5oIH1pUYsOPqi7EOq46OrxSpyO9BvtFfcTkQVaS/zqqWc7MghmljL/TMpTITnzkhYUUtWBoscmXExxbN9W4iqIP6hntvNdjc42S1hYkCuYBBR7RtMVk6DcXZp7sD+/9nwBQTgxmupUh39sZJqkUALWXqYQUiZZ91dlh96q8HaHClxcoMXmkEMTl0o7cWyZOUGY7MR3+Q3z9d/bIo6pTGBwKmRNOapU3vpWV6co9njPCNBk1QRlmPE6 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(136003)(396003)(39860400002)(9686003)(33656002)(66946007)(55016002)(2906002)(316002)(83380400001)(186003)(6916009)(5660300002)(86362001)(71200400001)(8936002)(76116006)(7696005)(66476007)(66446008)(52536014)(66556008)(64756008)(6506007)(478600001)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sIjo1+MC6RdLQJPj6tkSNhG8+yNfPkpHShnMNjTQaAbUD0/cNOfkCNqMtc+Ajej2AIKv9JnpthJp6+0+zo4JVpjDZPHxEmODLNHDA+aDfWJP+kooa9HC9UkLzjUUIKdaYHBI0E5CWm3QwZxYO1rDlvBi70Wse4QxpkQAy+F6ami+0ESpaGLYrhOyhUVwFLPhkE86mdl0qyKzYBoUCwXToFjZLdSpDLOyWjHQTWwABwvWeYgxUIOglo2QynxSHr4DfUBBO1nWgPPUlDLq0RFvj7TQkKe5P9pEvfgJuudu4lsgYoGoqUYYCbflm1OpuN3+PGBmHix9Po/KjjGSPaJnmqrTkeOXEp2NDFOAvqS5xUOFHblEOS4urS2frpOA9MU300nk0r/qyR515OYlrhW+Wr8FqnUBXsNU0ipawC1s/VRpFjGD05a/0VMJY11haf8qvOFdi492JyrY7ighpXjzJ+pG0giWCds335yLYdBJY2XVbP+WkHXMUNfdnwIHV/Q3BZL0wsTpIM9bgV+qR1+F5Sa1PwsFVtOrIk00BfREr+ijIOcFFLrz5n1JNNhd9ic/Rs0W8fVnHvMFbHBAqRf5X7w92wiKfAsF5V57h9q+S53gZPHeeiG8qgU62MYNxMNx5WALjXvjrvpq0e12D5vxxIrmqdQ+h2McF/YeQtnfdXKtD6KuGfFiYBqx06BT6/nf5OuN2oJtZcS9diDKenx10g== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jhZO3gdxHJE2wML6FW3BDllwBebrQEJsZIgXueWJLGv8IWt/tGCHhJbcWqm6dp8Omclp5LqgzjwQGFCD3Z4HdaZl1z/jUThcxPsHMHEK8J0pouwucDrEIpckHID1naLtskiMNTf/g0cWrS6lvprEfEuMuxnuXwkkPbDLN5Kg4Nzw460C+OFfm47oJ+dBwwR+4jZtU3NYwO7963LC6SOe3P5x6g+4HU1bkWD1r0T8xteVV9PmaafWYsHVMvmXFt8epgw9yHo+hZj0tb/uKFkZLYY2uwQXe+v8qFzkOrQ7i4iHrmNCwK/WcCA5MCeSjHn62pVK1k/eC9pT52HffSOm6A== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6TR9nnVZNLDgJXioBxIkimu809B5WKU9mbdlNfUhu0=; b=Ot6qoptDAuBCFQC2v+nO40hVWomnreGq7j1/ZfffG/K1yYASirSb3Qd2oHLIQdpFzNtBuXKKRLBj7k2LYiWLhin3r2LX+WUmv5Vw91Zp+Vh118zImQG3HyKePgnQADPt01c36zNNVfnVNPLF0mO63DF3/V1NiaLNMZTGNyr+Pw+YGnX0xKPEBVjB9UWFGDlDYp6BdTGkmNRMFShNR1Tiya5RWnkqZB4QsR9vWEO5a8fqoCL4Gt0O4ctxt1OerzuTnvqc1gwIwMZOTRliqq30fucybE2WYV1lX9BDHnylI9oriJHA6/tnHCKqEgGGDhIIIn9ui93i8rNszD4VrNeBdw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6TR9nnVZNLDgJXioBxIkimu809B5WKU9mbdlNfUhu0=; b=ihm6ZcS0EXKU6l/fmcb9FfB73/yVyH0YBaHz96haoRZF3ndpS5YeoaWdi8k4FOYRVCQR8lPi7TIYh3lcJVoiQT0hahDtkNgvxZBB710T9Nxl3vpWqXA+Cg+X2cO+7M4661z76Kzec+Gg8PobzXX/GOVLOMXObK4QCOTUelwZnC8= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 42744d45-0790-422d-a572-08d8706d6547 x-ms-exchange-crosstenant-originalarrivaltime: 14 Oct 2020 18:17:22.4156 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: kRC7wLjKa69Eg76yRrh+DtgviG0G4Mkkd1wPIuGmTu5T1N9ofkg9TmcOyS+va86CruKKnJZswn1VAKkS0i2knQq/Ieg7i1Vc6/mevBafzn4= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4335 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWM X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d27O6/i4jY1D/ZAL1lgznZFc7MUQ3wUSYGEIsa8zJuKemd3 ahkEq7SZVpiKkZZaTAMfrOxhoH/ULNAeZvYyS5pPSnvgTHsg0rY7of8+3+85XzjncEhcPkD4 kTl8ISfwbB4t9ZBkCFdqFH0xRo1yoFypMlk6UQxKNJn+YAdQWuyubI7N5AR/jtfqMnP4rCh6 T/J+hUoVrlYwtD/P5nNRdKoiOSlBEccf1glajvYvZvOK7K6OLxC4fHp7dEZstmnGRhTMeByz dpcTBvSOrEDuJFBhMP29FlUgD1JO9WEwfHZwVSCwlpld4ioG5nmzVBT9CGzPRwhHXk61YGBs yhPZimCsC3OwlFLC7PBDiYO9qUDorytFDvaigqHhrg0TfQaq3z8jRA6BqbEGpy+x9xuqW3AH y6h0+DzRIXUwotbBrycdzh6c8oXRqSZM3IECU+8LXGQf+DK5QjgGRVQFgtmKB0gsRIBp7ror sBGGmypdfhI8au1zhYOg9/GCm8i58PvnnETkrVA630iIvAnazo+7/A1gHel2XgWoSQzm2lox UTzFwdZej4timQDD7Ul7hbSLzbBiKRHHa8Xh5MhNaRVi6v9bSeRgaO6xSUXeBq3X5vB65znW wsDlKUkzkrShNeodIQwTFsKEq0JCmdAu5Hyjxtf30atLiRZEkYj2lPFRRo2cYIv1JfkWBCRO e8tm15/RyGWZbMlxTtBphKI8Tm9B4fazX8T9fLQ6+1PyhRomXK2OCFOpmVAmQkn7yvZaMzRy Kost5HI5roATVnMY6e5nQMS5CUbSP7I7Le7gEdt8xBhZaF32vOF1a9g42af+Wmso/9SYNlh3 eqfhwom/qfzbN7JRq5su3jOx0+iTHh8dtJgyNERRMQuNKQS/1OOxaMbkqUfNtVUfvV/eWwr0 Tgj+8CPSM1mZGNmubWD2jW35NnCHONV1qMY9MqCSKZseD6Al+myWCcIFPfsPu1r1WFwDAAA= X-SMG-Enforce: onprem X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-14_11:2020-10-14, 2020-10-14 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 18:17:42 -0000 During a session at M3AAWG50, one of the other participants proposed an ide= a where a sender could optionally send reports to a domain holder when they= send messages on behalf of that domain. Let's consider the idea that example.com has properly created SPF/DKIM/DMAR= C reports for themselves, and are enforcing at p=3Dreject. And example.com= has permitted ESP-A to deliver messages on their behalf, and they're prope= rly setup in the SPF, and properly sign with DKIM. ESP-B has no such autho= rization, but some entity has asked that ESP-B send messages on behalf of e= xample.com, but is targeting a mailbox provider who does not support DMARC,= nor send reports. Both entities participate in this "Senders DMARC", and = now example.com knows that ESP-A is acting properly, while ESP-B may need s= ome contact to understand more about what is going on. I'd suggest that th= e policy be separate from the receiving policy ("p=3D" and "ps=3D" (policy-= senders) for example, though, that may also lend itself to "psp=3D"), but r= esiding in the same DNS TXT record. This would not be meant just for ESPs, but also for MBPs/ISPs as well. Does this sound like a reasonable idea? Report overload? Not a helpful da= ta set for a domain holder? Thank you for your time. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From nobody Wed Oct 14 16:03: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 D6CB93A1114 for ; Wed, 14 Oct 2020 16:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.213, 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=wisc.edu 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 ovsaxJSXGaXI for ; Wed, 14 Oct 2020 16:03:08 -0700 (PDT) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 23C983A1115 for ; Wed, 14 Oct 2020 16:03:07 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QI700LB2RU70990@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 14 Oct 2020 17:58:55 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.10.14.225417, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.9.24.5770001, SenderIP=[104.47.59.170] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SUdrNVkOfIBUON3cmmT5o2aeFK893kAO4SPHw2w6B7RejR1oQ2Qw3kC4DEhUpBLHvDKm8CDUa22l+B7xVX8ISWgDawQ2csFjotN10GUuY4v93bjI5cfrw6ArGYFXijg2reK5a3Brf3jz0w/s0FVbkYR9vk9WkGN32EIhUlr7DHsGB8WZqGURT/71eDEmg6LcdKrxmN9HRnxvNOg/jD5Cv/E/FaveSRniQ4w/0L0V9B6HfpDANYozfX1c0tffysX3iSuf/xGxvrrZTWsx3XsOjwaLvyZm8l8esDWzX3Got1VcqNi3mQ7BGlLwhqFJhLpBfnjO/t42J3MwuMaVS6EdnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GQAjfSEcRjdcyZ9q9CaDUk7O908JZhDYYYa98xISlPs=; b=dz8r+Hl3tiqS+s1eM29eABexhcSjBQhDUkaFvLj4z+pCbwyDKXenYXQCXlD6bX2EPWcHNwC0V4CmP2oQhrd9D0i/S7XXHzcypoqIOzNMB3uinGoMFU0rIIbVbaHQQJSnefzlWPIIuSwg6cVMVzJwA3CrGqtvVYCPCL/2Q/GokxUNloOt+jSAnOuANDlwaItkAHrETTu8l9vaRMiLdIS1+wMhnMrENDXUGRuN0vnS9HW9F/Il9wHHP1sAKxQDBWWGt3DaXeiQ16cOGn+mOkoXNz9MsGl0+gt402+ZUC7K/30QN+CaveAlkF7MNCKJspLhz9jzZsvoDE+JmWXiuMRdqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GQAjfSEcRjdcyZ9q9CaDUk7O908JZhDYYYa98xISlPs=; b=sgvEDvRlFBEcPFKL0CplnwO0U1iYhlGYI61iDW6jBu6rEXdSv818KxTjkOhOHi/h08rHS9NzLDe14qoU8Bjah9hAMuC4TtTh1VBnYw5EdzPUhEz8epAYmpmKqb5s8XBANHIR29u9gagli9jX6bdcNpGi+VnE5lYqYWFqUEvx3l0= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4266.namprd06.prod.outlook.com (2603:10b6:5:27::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Wed, 14 Oct 2020 22:58:54 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::90e3:64b2:3032:4b00]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::90e3:64b2:3032:4b00%7]) with mapi id 15.20.3477.021; Wed, 14 Oct 2020 22:58:54 +0000 To: dmarc@ietf.org References: From: Jesse Thompson Message-id: <2d2018ba-6bd9-320e-b135-190c46e771da@wisc.edu> Date: Wed, 14 Oct 2020 17:58:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR14CA0038.namprd14.prod.outlook.com (2603:10b6:610:56::18) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR14CA0038.namprd14.prod.outlook.com (2603:10b6:610:56::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Wed, 14 Oct 2020 22:58:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2e48e48f-8120-4cbe-af81-08d87094b979 X-MS-TrafficTypeDiagnostic: DM6PR06MB4266: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SMVpa3QLB0O7/+50Q3Ils/4W0GA3o1A95fA2qe2vYUlB2ZIkB0FHTGVZ6CIStQTEgrJLZ2USu13WANy/qA9ZD2hqBktoEs9ocLU6/cGwiI0m7dzQPBAbz+UEIYUHoTtyQa9JzuZVxEHTzeTk6tWK/ebYPNJgVI1UFsyUlIdgzmXpUfO0dbFQUSxOhUHDRaEqUzRzcLjiajghlBSlSElAbveYBgYQKxxDl8BYMAWsY4oEbUNmfbuEGbTD8nUdpCBSpQtAjFgY7+BKA1AtQ//Qg1aUYVbPTrmLkm5J2Y0mBDbDEL2++pNcH8qxtilwAcEOmie1R6RXukJVlO5KHgIoJw+o8XRa6ubvyXom8nJgR048KnKIQdDPwaSKoQeBbl+x X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(39860400002)(376002)(396003)(86362001)(83380400001)(2616005)(956004)(478600001)(75432002)(16526019)(186003)(8936002)(31686004)(26005)(6486002)(36756003)(8676002)(16576012)(5660300002)(2906002)(31696002)(66556008)(66946007)(66476007)(44832011)(316002)(786003)(6916009)(53546011)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: IlbM1UYZdgYsxmPlzEBusNHSTWVmp9l5SCCf80+T+sGq7N8iC5G3y0SuGRPxMIE88XK//Zn2specvMgGWl1wU+AHAS9XQFnFphdK1FYmvqxPIM7z91BaKEMmNFgGRXg2TZ/bp0S+Aj/+3Br9MeqzRonjg2ifpRBBLsi35+19ip2Ln4lyuC8aTtfKhTKfg8sPJZ2kYGHVrUcB+FqNYEbt3+1Nf7vODWG8iPFIfqD0ZMtViPQFiTZx/AgQHJhmCO+5sAXCQfUtEDhyCNZEyFeyrGV+leuK72wySYKIUXZ1sUP1lFnGOObnfxFCf55nZyw+y8P4A7BzkSDU1AzuGTvYUF98RHmlypLiQCBG1uBnGmtsHVIQTEIhFOhQ8cycMBTDYE7OJvvC3rN2hXcyr6jZyPfGKYRMqjQHaA6rb1veSW9fV7YY4XZZR99BRduRt184nlOlIobL4/LPUavp7EZBsJ9aPbJUQNJ1fGBelXYDpmbwUW9Y7lJwf0CQZ2vnQCzQ5T9TkvmHFOSNkc8f4SfHCzdJRrBlq6RA4TDVLelse+pOi3kBT39PFmVHjYRrftC92seWh95O5krUjG2+egzye1cWg2Hq7ZHKAiHsJlNn7NcrqD0msP2T30btiI3cy9Dnb2EX16oPNuaRFEn7QXR25g== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 2e48e48f-8120-4cbe-af81-08d87094b979 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2020 22:58:54.4684 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dM7maWkWx2fzSQhCmw9zaHPQO0rQqLfpx7ukkrkI4gtbvk8Ff7HTwaquuiw2+MauVeEizii3jNBPq8kKBzyoiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4266 Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 23:03:10 -0000 On 10/14/20 1:17 PM, Brotman, Alex wrote: > During a session at M3AAWG50, one of the other participants proposed an idea where a sender could optionally send reports to a domain holder when they send messages on behalf of that domain. > > Let's consider the idea that example.com has properly created SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject. And example.com has permitted ESP-A to deliver messages on their behalf, and they're properly setup in the SPF, and properly sign with DKIM. ESP-B has no such authorization, but some entity has asked that ESP-B send messages on behalf of example.com, but is targeting a mailbox provider who does not support DMARC, nor send reports. Both entities participate in this "Senders DMARC", and now example.com knows that ESP-A is acting properly, while ESP-B may need some contact to understand more about what is going on. I'd suggest that the policy be separate from the receiving policy ("p=" and "ps=" (policy-senders) for example, though, that may also lend itself to "psp="), but residing in the same DNS TXT record. > > This would not be meant just for ESPs, but also for MBPs/ISPs as well. > > Does this sound like a reasonable idea? Report overload? Not a helpful data set for a domain holder? I would assume that any additional information sent to domain owners would be useful for identifying ESPs using a domain without permission or mis-configuration/drift. It also sends a positive signal that the ESP is acting more responsibly than the ESPs that don't send the reports, which could be seen as good for business. Permission: Currently, with the reports we get, we already have a very good picture of which ESPs are using our domains, and we don't know why. So, in order to make this idea more than a lateral change, I'd want to see information about who the ESP's "customer" is (or some customer ID we can reference), since with a large institution it's currently hard to figure out who these people are without drinking from the forensics firehose and inferring. Domains that have a quarantine|reject DMARC policy would expect ESPs to not send mail as that domain unless authorized, but they've probably succumbed to the fact that it happens anyway. So, in these respects, the idea would be an improvement especially for domains that are at p=none during the inventory phase of their DMARC deployment to help them identify who within their organization is using which ESPs. Mis-configuration/drift: I assume that the ESP would have to maintain a record of prior properly configured SPF/DKIM setups. From there, the ESP could send reports indicating that something needs to be updated in the domain's DNS records. Is that what you're suggesting? That seems like a positive, since I assume that ESPs' customers have a hard time relaying technical information to their DNS admins. Other scenarios, which I don't think this idea has much benefit: 1) The recipients are all local and there is a prearranged local override, and the domain owner doesn't want to authorize the ESP to use the domain in other contexts via DMARC 2) Domains that have very broken DMARC/SPF/DKIM probably aren't paying attention to the reports anyway 3) Domains that don't have a DMARC record 4) Domains like gmail.com who can't/won't authorize every ESP at the domain-wide level. This also applies to the org domain at large institutions, which is typically the domain that houses users, which also happens to be the domain that users want to use as a customer of an ESP. * Could we publish something that says: ESPs: please don't try to use this domain :-) Hope this helps! It sounded like a great session. Jesse From nobody Thu Oct 15 16:33: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 115733A0CBC for ; Thu, 15 Oct 2020 16:33: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 (1024-bit key) header.d=twofive25.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 Wqyevo4djJIo for ; Thu, 15 Oct 2020 16:33:46 -0700 (PDT) Received: from mx02.twofive25.com (mx02.twofive25.com [160.16.234.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 D7DDB3A0CB9 for ; Thu, 15 Oct 2020 16:33:45 -0700 (PDT) Received: from Nihonbashi.local ([150.249.214.210]) by TwoFive with ESMTP id TCkhk2J301YJCTCkhkdgpB; Fri, 16 Oct 2020 08:33:43 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=twofive25.com; s=tf0001; t=1602804823; bh=nHKMX3bMOM7V1zCBQgOPp8sudn3Cit89RWvkyByvpsk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kCT92imJb8WB+cKJq/8toIv9hKxjpXEmYaXpkePQgUij65KGT2qxM6xKmitCtHRy2 F+6TiFCEOh7HQtQFC+erP0Oy1pniePlq1tP/S2bm76gILTeTtwBAgOBrP47pkpLaYW zsik8B8/lmYp1tubjNAtzvqb/VnpLZxfzNxzY6RM= Authentication-Results: mx02.twofive25.com; spf=pass (mx02.twofive25.com: domain of kase@twofive25.com designates 150.249.214.210 as permited sender) smtp.mailfrom=kase@twofive25.com Received: from [192.168.11.23] (m106073026161.v4.enabler.ne.jp [106.73.26.161]) by Nihonbashi.local (Postfix) with ESMTPSA id 94E2D107591B7A; Fri, 16 Oct 2020 08:33:42 +0900 (JST) From: Masaki Kase Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B68392FC-977D-4257-8C96-AAD8EC7556C3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 16 Oct 2020 08:33:33 +0900 In-Reply-To: Cc: "dmarc@ietf.org" To: "Brotman, Alex" References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 23:33:48 -0000 --Apple-Mail=_B68392FC-977D-4257-8C96-AAD8EC7556C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Alex, > This would not be meant just for ESPs, but also for MBPs/ISPs as well. >=20 > Does this sound like a reasonable idea? Report overload? Not a = helpful data set for a domain holder? With the perspective of MBPs, I imagined these 3 things: (a) Identify the E/U=E2=80=99s IP address The MBPs can receive aggregate reports and can easily identify E/U=E2=80=99= s IP addresses. I wonder that information would be useful for EAC = issues. (b) Gather the MSAs information Some MSAs will overwrite RFC5322.=46rom before sending and others = won=E2=80=99t. In the latter cases, DMARC results might be reported as = =E2=80=9Cdmarc=3Dfail=E2=80=9D but MBPs can make sure these MSA=E2=80=99 = behavoir or specification via aggregate reports. Hopefully, MBPs may = allow to use 3rd party DKIM signatures to save the messages. (c) Leverage =E2=80=9Ccomment" field on XML If MSAs overwrote RFC5322.=46rom the aggregate reports could imply it, = for example using =E2=80=9Ccomment=E2=80=9D or generating new field. Best regards, -- =E5=8A=A0=E7=80=AC=E3=80=80=E6=AD=A3=E6=A8=B9 =E6=A0=AA=E5=BC=8F=E4=BC=9A=E7=A4=BETwoFive 103-0027 =E6=9D=B1=E4=BA=AC=E9=83=BD=E4=B8=AD=E5=A4=AE=E5=8C=BA=E6=97=A5= =E6=9C=AC=E6=A9=8B3-1-4 =E7=94=BB=E5=BB=8A=E3=83=93=E3=83=AB3F Mail: kase@twofive25.com Tel: 03-5704-9948 Tel: 080-9805-0025 URL: https://www.twofive25.com Masaki Kase TwoFive, Inc. kase@twofive25.com > 2020/10/15 3:17=E3=80=81Brotman, Alex = =E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB: >=20 > During a session at M3AAWG50, one of the other participants proposed = an idea where a sender could optionally send reports to a domain holder = when they send messages on behalf of that domain. >=20 > Let's consider the idea that example.com has properly created = SPF/DKIM/DMARC reports for themselves, and are enforcing at p=3Dreject. = And example.com has permitted ESP-A to deliver messages on their behalf, = and they're properly setup in the SPF, and properly sign with DKIM. = ESP-B has no such authorization, but some entity has asked that ESP-B = send messages on behalf of example.com, but is targeting a mailbox = provider who does not support DMARC, nor send reports. Both entities = participate in this "Senders DMARC", and now example.com knows that = ESP-A is acting properly, while ESP-B may need some contact to = understand more about what is going on. I'd suggest that the policy be = separate from the receiving policy ("p=3D" and "ps=3D" (policy-senders) = for example, though, that may also lend itself to "psp=3D"), but = residing in the same DNS TXT record. >=20 > This would not be meant just for ESPs, but also for MBPs/ISPs as well. >=20 > Does this sound like a reasonable idea? Report overload? Not a = helpful data set for a domain holder? >=20 > Thank you for your time. >=20 > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_B68392FC-977D-4257-8C96-AAD8EC7556C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Alex,

This would not be meant = just for ESPs, but also for MBPs/ISPs as well.

Does this sound like a reasonable idea?  Report = overload?  Not a helpful data set for a domain holder?

With the perspective of MBPs, I imagined these 3 = things:

(a) = Identify the E/U=E2=80=99s IP address
The MBPs can = receive aggregate reports and can easily identify E/U=E2=80=99s IP = addresses. I wonder that information would be useful for EAC = issues.

(b) = Gather the MSAs information
Some MSAs will = overwrite RFC5322.=46rom before sending and others won=E2=80=99t. In the = latter cases, DMARC results might be reported as =E2=80=9Cdmarc=3Dfail=E2=80= =9D but MBPs can make sure these MSA=E2=80=99 behavoir or specification = via aggregate reports. Hopefully, MBPs may allow to use 3rd party DKIM = signatures to save the messages.

(c) Leverage =E2=80=9Ccomment" field on = XML
If MSAs overwrote RFC5322.=46rom the aggregate = reports could imply it, for example using =E2=80=9Ccomment=E2=80=9D or = generating new field.

Best regards,



--
=E5=8A=A0=E7=80=AC=E3=80=80=E6=AD=A3=E6=A8=B9<= br class=3D"">  =E6=A0=AA=E5=BC=8F=E4=BC=9A=E7=A4=BETwoFive
  103-0027 =E6=9D=B1=E4=BA=AC=E9=83=BD=E4=B8=AD=E5=A4=AE=E5= =8C=BA=E6=97=A5=E6=9C=AC=E6=A9=8B3-1-4 =E7=94=BB=E5=BB=8A=E3=83=93=E3=83=AB= 3F
  Mail: kase@twofive25.com
  Tel: = 03-5704-9948
  Tel: 080-9805-0025
  = URL: https://www.twofive25.com

Masaki Kase
TwoFive, Inc.
kase@twofive25.com



2020/10/15 3:17=E3=80=81Brotman, Alex <Alex_Brotman=3D40comcast.com@dmarc.ietf.org>=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB:

During= a session at M3AAWG50, one of the other participants proposed an idea = where a sender could optionally send reports to a domain holder when = they send messages on behalf of that domain.

Let's consider the idea that example.com has properly created SPF/DKIM/DMARC reports = for themselves, and are enforcing at p=3Dreject.  And example.com has permitted = ESP-A to deliver messages on their behalf, and they're properly setup in = the SPF, and properly sign with DKIM.  ESP-B has no such = authorization, but some entity has asked that ESP-B send messages on = behalf of example.com, but = is targeting a mailbox provider who does not support DMARC, nor send = reports.  Both entities participate in this "Senders DMARC", and = now example.com knows that = ESP-A is acting properly, while ESP-B may need some contact to = understand more about what is going on.  I'd suggest that the = policy be separate from the receiving policy ("p=3D" and "ps=3D" = (policy-senders) for example, though, that may also lend itself to = "psp=3D"), but residing in the same DNS TXT record.

This would not be meant just for ESPs, but also for MBPs/ISPs = as well.

Does this sound like a reasonable = idea?  Report overload?  Not a helpful data set for a domain = holder?

Thank you for your time.

--
Alex Brotman
Sr. = Engineer, Anti-Abuse & Messaging Policy
Comcast

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

= --Apple-Mail=_B68392FC-977D-4257-8C96-AAD8EC7556C3-- From nobody Sun Oct 18 03:00: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 2AF6A3A09A8 for ; Sun, 18 Oct 2020 03:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvbzwcLoRfJe for ; Sun, 18 Oct 2020 03:00:07 -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 AA5E93A09A5 for ; Sun, 18 Oct 2020 03:00:07 -0700 (PDT) Received: (qmail 81355 invoked by uid 100); 18 Oct 2020 10:00:06 -0000 Date: 18 Oct 2020 09:59:42 -0000 Message-ID: <20201018095942.81340.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 18 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 10:00:09 -0000 Count | Bytes | Who ------------+----------------+------- 2 (22.2%) | 10184 (11.9%) | Alessandro Vesely 1 (11.1%) | 17576 (20.5%) | Seth Blank 1 (11.1%) | 13653 (15.9%) | Brotman, Alex 1 (11.1%) | 12737 (14.9%) | Masaki Kase 1 (11.1%) | 12406 (14.5%) | Jesse Thompson 1 (11.1%) | 8810 (10.3%) | Hector Santos 1 (11.1%) | 7592 ( 8.9%) | Alexey Melnikov 1 (11.1%) | 2813 ( 3.3%) | John Levine From nobody Mon Oct 19 05:17: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 496143A0BDC; Mon, 19 Oct 2020 05:17: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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=MotG+n8l; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=TPWMmZqt 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 77zGNW4kHkCm; Mon, 19 Oct 2020 05:17:26 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7718A3A0BC0; Mon, 19 Oct 2020 05:17:26 -0700 (PDT) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JCEGNj021184; Mon, 19 Oct 2020 08:17:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=NwwMtWzWfvb95FENFG9NAQRSVtPr8KmG84azklBqngU=; b=MotG+n8lgCcYNrDiRCnoomubu4cegfIO43exium9dmLy6R/aR2C5yn6DeG4j8wu9kfQJ TdgAxikEC/5ehh5BJgVbu3r7w3m8ZnOmPGWZipd91OtDpl06LTgNtXKlQWUNz1FKhAlA 2ZUw7lc5FEOSfTp+9W6XpRIgjPU5Fo/F5jj5hmmSPkpGD59eu1XU8R7DRCDGECmjr/MX pbdM5jT+MG5xXp6bVFzTWUQBnaZ7to/8LyUOfXwtwb4//K2BeS/4O5lTFsA7FvZYiQID 92LVuEO9zi4Ai+2Rzi8mnzq0rhlm2lGRuzGoye/VPPFYvNxwptdgP+Btz6iaxUE4xBbr EA== Received: from pacdcex41.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 3487wre8us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 08:17:25 -0400 Received: from PACDCEX44.cable.comcast.com (24.40.2.143) by PACDCEX41.cable.comcast.com (24.40.2.140) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 08:17:24 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX44.cable.comcast.com (24.40.2.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 19 Oct 2020 08:17:24 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.107) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 08:17:23 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4552.namprd11.prod.outlook.com (2603:10b6:208:263::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Mon, 19 Oct 2020 12:17:21 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 12:17:21 +0000 From: "Brotman, Alex" To: Jesse Thompson , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Thoughts on "Senders DMARC" Reports Thread-Index: AdaiVc1hNC32VOspTmuLojW6xIuQgAAJ8e2AAOS13BA= Date: Mon, 19 Oct 2020 12:17:21 +0000 Message-ID: References: <2d2018ba-6bd9-320e-b135-190c46e771da@wisc.edu> In-Reply-To: <2d2018ba-6bd9-320e-b135-190c46e771da@wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:d9e5:68ca:5ca1:1cc5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff42fdb8-fb09-404a-82b9-08d87428ee4c x-ms-traffictypediagnostic: MN2PR11MB4552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: veFYLgQ/5jc2bL9YY0hHDHE5nW24uZdalLn847pA0bsZX+xypsQPOCaPYureI9AEhvgDpeTOKrfE0u42VB0PawTCsNxWKIcndnBccltR8GZgm8BDBPXTn16JIj292AYsXXCJc7a7CAX/SNDEJFbX3Adst5lxgu7u1WDWb7ZMR5sAGVk/WoR+hGMVZ6XGJtgir9XAteXjdogIN1DOvwKsccm7p+RbP2wzMgpY6M2jVdPBTiT7SBwv7IOP3zq+FSNEE8C0/rIqgSlLSmuv7XTSmPckG3nx09PR/7XBIV4P3FolRIhfS8zSn9yUQLyHmmvSVX4Z2Py1WzTbfs6Z5v89AhJJp71i/put7cEq+qOzAxhfcZCiP66/YnwPrkInf5S7GMMYNR6+U1Vbg/YvfaiTaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(66446008)(83380400001)(64756008)(8676002)(66556008)(8936002)(76116006)(55016002)(52536014)(66946007)(66476007)(86362001)(5660300002)(9686003)(478600001)(33656002)(316002)(966005)(2906002)(71200400001)(186003)(6506007)(53546011)(7696005)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: aKMZCTZk2cr/uXlIL4duIS680TFk2Bvoc8xj71M7AI/jOpCF4vcTbBjKEC4zWleJPg7XhIEKU7ItZQtBoEinIp9OTaeJF1kxbmOw+ZoTS3cudten7QM3wy21BHWcuAoE7D91eC5IBkkYm/fibjvN4EcBDRfqaTpw9LoZH9cm2HYFFLz/nixVSBOx7oNojNkYQF4BXWltG5Lb62RvFu0+Kb2dUJVZaoGdDsvzw2KmrsEITUOpG3yEo3PwWbywRtJQobveeT14aWcatplbghuWkNoMXnltoq8o9PIQWjnRqfTvHKDrTrUg5Qlagxck3VyVW+XFarb476TDu70BqpbiLbVXa9ADS7wLndHXf4KdCOvkqiG5t3MuLLZ1WR+/Afx7gtQdiWxZowXdiaZGwp9TExh7BMZ2AJqzMfPEWpvwjIls+uEWMMxH55QmS2NAFoO9AYOlPzquYmqFNXuj32oit8N7i1FirlFtkVAZpDPL2pKGqRCs477H2WPrel5DRXfLiWHWwOgZXVFsBoQml8lpx/9QR2VhBBIgPlwY1wHFGF9HhbRjhnwpPWned6tm9gMJY5veJIWWsfrNYk1+CPcquWHbxw+WPy7Od0hRmkxd3ToQ9El9U9vrZlmnqJ02iEA4R87s+M3KV0MoJ2wKfnfgjs8foZKbxqzVqrgwCwZZ1CTyGr6XsNArk3zoA10t4kbyRk2qvXOXATWpgVLj/FAgCg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CvJvOSGIojc2Bti4SKGsx6bBMzOp6CcZalIz0R0Cg7ySaUQucwLf5NjfJGMDMxj4cDSu6wsUwMEysGZG00EnDmfL9t+/VgeFqkmVZ7b8hnQU3+08NboA1aAx+MIIUDm2AmOlSKb4SvIVrmeiMKV8ERlnhk+sp4Bgxn8WVmNGGw5BzqDWbjYpasONLFXc93mGbF07TQke7M5pu1bpAnQ4mqSUKQSzaI8g4LnbJ9bilo2+SRdNFN6ucVbjf8BdCfDdySrdoXAAWi5firR96wXt8LyW49TUQygTtOaNwvnzO+R+0L2AZi/zjfGQfTAbGHchrmeoKNkCWxn6xA6VjaElMw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUIKgOG4m2Z5ZcSx61Pg8koEoNrpDyvFbEdvFVEfOEI=; b=mA6kKeLgfihg5ZuOt2qwWG9qq6/igSlZfNRFeV4J1vRfhUDq3SF8YhpwdB2dXR7FGzls3nERsclsQkXcbsYoHDWD/xLtX6rDafE1HO8enDezGY6lxopGMz/8wFcCwmyZZRx98xwas4w7h/pB09Cz4C/0eqjWQsZpUbCeCjJ0cWrz6PXRg0zhjLMiH9j9z6Yx+wEQwYosZ0ryHXRCNJYJwlHB1RDUVwnBInRSt0vw5bHWgeoEl0mwtnJ5YWLG+9XMXBjhu/nBjKUfpcB0c7K1DplITnCnKfAZorGwX+DzpkmXRtpl7OmYWvXxuqLjZ89BzHnvsVUnZjWZOHPDd+GPCg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUIKgOG4m2Z5ZcSx61Pg8koEoNrpDyvFbEdvFVEfOEI=; b=TPWMmZqt+7HCaMfvbyCTEK8EO8mxdQK6kMEvbYjXeU8KOFKM3CdhbNGMcs7J8N7wNbLc+moSYMhADNblsJKAkdyTh43ZGC7i7rXUZazwAMDgSLNOBplY5jFbhZKhnsKz5qFZV++HxhPp7J2BLxAkjjxyiuqsxFR/w1OlZ1S+TSE= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: ff42fdb8-fb09-404a-82b9-08d87428ee4c x-ms-exchange-crosstenant-originalarrivaltime: 19 Oct 2020 12:17:21.5892 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: qzSF0Keb8uv/fUskZaGLe7sEUludiA7mPOnS0SfhwKqLNhGLAgZw3H2LMcvEk+Jw0H/oB9JwD+m/YU0l3DrJVmKMq9pZXywn2wYC+nh17AY= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4552 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWS X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_05:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 12:17:28 -0000 -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc On Behalf Of Jesse Thompson > Sent: Wednesday, October 14, 2020 6:59 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports > > On 10/14/20 1:17 PM, Brotman, Alex wrote: > > During a session at M3AAWG50, one of the other participants proposed an > idea where a sender could optionally send reports to a domain holder when > they send messages on behalf of that domain. > > > > Let's consider the idea that example.com has properly created > SPF/DKIM/DMARC reports for themselves, and are enforcing at p=3Dreject. > And example.com has permitted ESP-A to deliver messages on their behalf, > and they're properly setup in the SPF, and properly sign with DKIM. ESP-= B > has no such authorization, but some entity has asked that ESP-B send > messages on behalf of example.com, but is targeting a mailbox provider wh= o > does not support DMARC, nor send reports. Both entities participate in t= his > "Senders DMARC", and now example.com knows that ESP-A is acting > properly, while ESP-B may need some contact to understand more about > what is going on. I'd suggest that the policy be separate from the recei= ving > policy ("p=3D" and "ps=3D" (policy-senders) for example, though, that may= also > lend itself to "psp=3D"), but residing in the same DNS TXT record. > > > > This would not be meant just for ESPs, but also for MBPs/ISPs as well. > > > > Does this sound like a reasonable idea? Report overload? Not a helpfu= l > data set for a domain holder? > > I would assume that any additional information sent to domain owners > would be useful for identifying ESPs using a domain without permission or > mis-configuration/drift. It also sends a positive signal that the ESP is= acting > more responsibly than the ESPs that don't send the reports, which could b= e > seen as good for business. > > Permission: Currently, with the reports we get, we already have a very g= ood > picture of which ESPs are using our domains, and we don't know why. So, = in > order to make this idea more than a lateral change, I'd want to see > information about who the ESP's "customer" is (or some customer ID we can > reference), since with a large institution it's currently hard to figure = out who > these people are without drinking from the forensics firehose and inferri= ng. > Domains that have a quarantine|reject DMARC policy would expect ESPs to > not send mail as that domain unless authorized, but they've probably > succumbed to the fact that it happens anyway. So, in these respects, the > idea would be an improvement especially for domains that are at p=3Dnone > during the inventory phase of their DMARC deployment to help them > identify who within their organization is using which ESPs. [Brotman, Alexander] Sure, I think Masaki Kase is suggesting roughly the same thing (along with = IP address). Tell the domain who is the entity responsible for attempting = this delivery? This might need to be a hash of some sort. > > Mis-configuration/drift: I assume that the ESP would have to maintain a > record of prior properly configured SPF/DKIM setups. From there, the ESP > could send reports indicating that something needs to be updated in the > domain's DNS records. Is that what you're suggesting? That seems like a > positive, since I assume that ESPs' customers have a hard time relaying > technical information to their DNS admins. > [Brotman, Alexander] I think this sort of data would benefit both the domain holder, but as you = suggested, also the ESP. They could aggregate their own data to show drift= /misconfiguration. And yes, as you also suggest, sometimes the DNS guys ch= ange things that the MarComm team doesn't know about, believing they're doi= ng the proper thing. > Other scenarios, which I don't think this idea has much benefit: > > 1) The recipients are all local and there is a prearranged local override= , and > the domain owner doesn't want to authorize the ESP to use the domain in > other contexts via DMARC > > 2) Domains that have very broken DMARC/SPF/DKIM probably aren't paying > attention to the reports anyway [Brotman, Alexander] Perhaps not, but as you alluded above, the ESP could potentially use the da= ta to understand more about their platform. > > 3) Domains that don't have a DMARC record [Brotman, Alexander] It might be possible, depending how this were created, to have a "Senders D= MARC" Policy, without a proper DMARC policy. Perhaps marginally useful to = the domain. > > 4) Domains like gmail.com who can't/won't authorize every ESP at the > domain-wide level. This also applies to the org domain at large institut= ions, > which is typically the domain that houses users, which also happens to be= the > domain that users want to use as a customer of an ESP. > > * Could we publish something that says: ESPs: please don't try to use th= is > domain :-) > > Hope this helps! It sounded like a great session. > > Jesse > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc > __;!!CQl3mcHX2A!QcpORx5hkGoLGAIubf00VCePDChJAiXUA1dPAK64CV9ffw > di6bRkdDFOss0mMsK_Dzh9b-CSbg$ From nobody Mon Oct 19 05:19: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 5CE173A0BDC; Mon, 19 Oct 2020 05:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=0PIIN7Z/; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=cJMeEK38 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 Q6vFE44PEWXj; Mon, 19 Oct 2020 05:19:35 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F0A3A0BC0; Mon, 19 Oct 2020 05:19:31 -0700 (PDT) Received: from pps.filterd (m0156896.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JCDcp9017656; Mon, 19 Oct 2020 08:19:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=QaG36hhsfFJlW8LQQwV54LKPvzNqB0IkTvr5p6H9Ldg=; b=0PIIN7Z/GMhZH9IQk0V52FLeuuQbMAmQK84GaaTVGqc7BNnHP1XCQARqQMGtEZpE7lF2 jIMv/lgYYARVxmv83VUoLAKEKokmSVgtMhkMNgr3Cwwq4xlIY/k6Ax1ZoMRUW4Oehnqy 4VM/WfIQaSRMca8d00NLnikWIkcrx/qF+eRScXKP46wutMeQbhopqpOt60DnTOZgsJuj vLzaDZ9G0R9AlWFUqenGKBtZ//Jhsl2n4LH/1WHRFxACn21K5sXl+yTLkO6vFENZMyr/ JOUusjtvVA9oYv7vVQQvMJibIvyC3yGRpAMjvnX37rybeZxUMq0UzXkjPI+IwSMv5A8c lA== Received: from copdcexc38.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0b-00143702.pphosted.com with ESMTP id 347um70k69-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 08:19:30 -0400 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC38.cable.comcast.com (147.191.125.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 19 Oct 2020 06:19:28 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 19 Oct 2020 06:19:28 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.105) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 08:19:26 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4552.namprd11.prod.outlook.com (2603:10b6:208:263::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Mon, 19 Oct 2020 12:19:24 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 12:19:23 +0000 From: "Brotman, Alex" To: Masaki Kase , "Brotman, Alex" CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Thoughts on "Senders DMARC" Reports Thread-Index: AdaiVc1hNC32VOspTmuLojW6xIuQgAA9csaAALGRy6A= Date: Mon, 19 Oct 2020 12:19:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: twofive25.com; dkim=none (message not signed) header.d=none;twofive25.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:d9e5:68ca:5ca1:1cc5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a4f8392-df86-46a7-7ec9-08d874293715 x-ms-traffictypediagnostic: MN2PR11MB4552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W/Cdr1u6417MEczM2ap0L8UV4eNMrGMJ/TKGhd1YSU31LTFL3QID5CexHBkLJc+jfE53rKtrQ3kfKo7kImR7rCH/AK5dFqxMTHnr2OcEvirSmIFKtctZfdJJAvXG/8RG08dg76V+lXQukHwg0Ajp3pVvTufM7sWqe3SBZKfYtGQpL/AmLLY8AIh5fWBO3v8vTs/1hLsKFQrHH7T5oILigNpYjlg+Edq4yS+jMXcZws8VqS8ePMPWLjPnAXWxhAZFr/YCQ/pavD++hNb+M4LOTE0onoecX3e76Hg5qEOyCDiJc2pKZQZEmfuOY4AXF0tFg+SmLtlV2DzNKlAHCo2oH3LKLjpSU5+DyFcu0moOvEbxohMQJ4lKy9SBcqeauUlKHzk65TvSr2OiwBBMzjnK6g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(66446008)(166002)(83380400001)(64756008)(8676002)(66556008)(8936002)(76116006)(55016002)(52536014)(66946007)(66476007)(86362001)(4326008)(5660300002)(9686003)(478600001)(33656002)(316002)(966005)(2906002)(71200400001)(186003)(6506007)(53546011)(7696005)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: VEbnkPa5boQErX/yEUcpNg9mc0zhBl5Z8wSjOwaAclYOGb2BBE0d7a2p6kIyqrHLrubhnhYbShkujEpJn/KJCHClbfXN2dMc85JzNZjDhGyhhmFuiDTCSQQ2de1WZpqAoELiH1DXWuJcljKbvL8FquwoJjjkKVzr1QdUuKXyByZn61TkX4AHwSbb8ihP0AfPPaXF2mVGSPeQqBPuvor44NgmmRtm75SZHyxRefIoOApch9tRHJdxS9NiCQZuh2SlFVLySyJeX85WoIxCGt1ML7RtnVit8knOgejlfk85hk2wcF3NVE8JJkue9kTlM1foWZavNfQadvFh7ty5VwtEkB4QO6eL4pl1mx6dcuBXVByQ0/hQUlP/q2fQLSw1Z4FGBzTQthlZ0waSKqTaA0zLTkNvAB/Ra4hiGP1ZZESlif74WzSjNR5OvJPxHUYNFVBmQyvOAIJGMigKk1B6o5mexqKN9nOjpZ2DZdSo5a/EzeF4FSegV5V5kvpvqpF5azSeTdhzrMD/4QJ+zRiG1YSemg0RW3qaZNlzqUG0MCZyuJ6l+DEjTRUH5LfRTyD3MoWyfBNJkUpXzlJUR+S0gT9BchiOTE2fP9tTLEWWh78i7VvTnMj74RQYmL3XF5QZrMjC53zaci85GpvjOB+ADwG2vW06ntwbdx7sguOCeaD4YB712jz14jSRw6hQ8253eq7Dw078vUAPN70qcy9yX4+3qQ== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SbYXV3UlDF1WQt4IpXK7dkLMAMkHyCd2hIpCfexWGBvGr8FRNFBq9x0rteW3nkE5N9jorXkGWH1Cy3CZ0nB6vWfCAGZxbceXwCQQF654cR0kc5s+K0X1Bb+MxtR20tBaGn5YkMX6OEXRyd/1c+2CVREdxrLEpBID8vk4cT0Zxgh6toCyoov4JCHDKuOyLBUAib+6gKi/fXjSXAWJLOAKfXGSyInx4fjkiLSeNzjVnVlmzTqyGcj11OZF7G4QYY+6lbjb0BUaaOfSslPlwmKfjAwjvDSP5GfIcHH79PAO/8TQkza3I2dWJ08T5Lb7vajcIhTAvAvkNgXAm8AojSfvMA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PHYMwUaKzCbFou048erGLvrXb78fCzCwEelnXsGtD7s=; b=DlActiI5UZdxRVvLULxt1Uy4sTg3jyVZlr/vfM7LfrZnj9B7stEPYPcVfc3kJmPzxoY/K69bjHpnQTorn8uxkoyIGuzBOCa35r+UwpMpE2zo0JZkZ4ZLTOK4aLJSxsgN/XB9+bgARzCIDzr5xnQnJ8TGpgG1IUx8mhzrUiL3MvDTtgUDSlB6NaYYsMldC6W93Kx8S99IeiPufynNe2NA9+H2PDt6tImGuBTrPETFSv0b2uVSXi4vT9TlG05CJ6b08UiKbPnA3g4KWn96UsdD92pxdWCYOANSHit2sN94x51OXk0t9YKGAMX8AIx7G5saacgGu7vw93XktIPTfMYaOQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PHYMwUaKzCbFou048erGLvrXb78fCzCwEelnXsGtD7s=; b=cJMeEK385LwKqXCCbTBg+vLjuQBtWcv5azu4FbXk66CL6bQ8+V4mDBhFClSkol+MZszMmltgV42Db0xTRQ9VJPgRwhE3C3ztoRTlacO4GD8D5wu+tF6fvu9dHD0eMmtAlTURPUqe88ZnLdzIAumSrFLguFkL+mY1Qtt5VhkS9M0= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 8a4f8392-df86-46a7-7ec9-08d874293715 x-ms-exchange-crosstenant-originalarrivaltime: 19 Oct 2020 12:19:23.7543 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: gQfKDoi/nE+knWPXs1NCcjNr3U6+g63GF8zsWJnXvwklO+5iVdB9atptou2i+y9HcZTwfvjUSHMnSJimpz54s6TIWLwdyHo1vaTV1KlTUz8= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4552 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43518D96C44A630AF011B8F9F71E0MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWC X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_05:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 12:19:37 -0000 --_000_MN2PR11MB43518D96C44A630AF011B8F9F71E0MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGNvdWxkIGJlIHJlYXNvbmFibGUuICBJdCBjb3VsZCBtYWtlIHJlcG9ydHMg bm9pc3kgdGhvdWdoPw0KDQotLQ0KQWxleCBCcm90bWFuDQpTci4gRW5naW5lZXIsIEFudGktQWJ1 c2UgJiBNZXNzYWdpbmcgUG9saWN5DQpDb21jYXN0DQoNCkZyb206IGRtYXJjIDxkbWFyYy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFzYWtpIEthc2UNClNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDE1LCAyMDIwIDc6MzQgUE0NClRvOiBCcm90bWFuLCBBbGV4IDxBbGV4X0Jyb3RtYW49 NDBjb21jYXN0LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtkbWFyYy1pZXRmXSBUaG91Z2h0cyBvbiAiU2VuZGVycyBETUFSQyIgUmVwb3J0cw0K DQpIZWxsbyBBbGV4LA0KDQpUaGlzIHdvdWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBi dXQgYWxzbyBmb3IgTUJQcy9JU1BzIGFzIHdlbGwuDQoNCkRvZXMgdGhpcyBzb3VuZCBsaWtlIGEg cmVhc29uYWJsZSBpZGVhPyAgUmVwb3J0IG92ZXJsb2FkPyAgTm90IGEgaGVscGZ1bCBkYXRhIHNl dCBmb3IgYSBkb21haW4gaG9sZGVyPw0KDQpXaXRoIHRoZSBwZXJzcGVjdGl2ZSBvZiBNQlBzLCBJ IGltYWdpbmVkIHRoZXNlIDMgdGhpbmdzOg0KDQooYSkgSWRlbnRpZnkgdGhlIEUvVeKAmXMgSVAg YWRkcmVzcw0KVGhlIE1CUHMgY2FuIHJlY2VpdmUgYWdncmVnYXRlIHJlcG9ydHMgYW5kIGNhbiBl YXNpbHkgaWRlbnRpZnkgRS9V4oCZcyBJUCBhZGRyZXNzZXMuIEkgd29uZGVyIHRoYXQgaW5mb3Jt YXRpb24gd291bGQgYmUgdXNlZnVsIGZvciBFQUMgaXNzdWVzLg0KDQooYikgR2F0aGVyIHRoZSBN U0FzIGluZm9ybWF0aW9uDQpTb21lIE1TQXMgd2lsbCBvdmVyd3JpdGUgUkZDNTMyMi5Gcm9tIGJl Zm9yZSBzZW5kaW5nIGFuZCBvdGhlcnMgd29u4oCZdC4gSW4gdGhlIGxhdHRlciBjYXNlcywgRE1B UkMgcmVzdWx0cyBtaWdodCBiZSByZXBvcnRlZCBhcyDigJxkbWFyYz1mYWls4oCdIGJ1dCBNQlBz IGNhbiBtYWtlIHN1cmUgdGhlc2UgTVNB4oCZIGJlaGF2b2lyIG9yIHNwZWNpZmljYXRpb24gdmlh IGFnZ3JlZ2F0ZSByZXBvcnRzLiBIb3BlZnVsbHksIE1CUHMgbWF5IGFsbG93IHRvIHVzZSAzcmQg cGFydHkgREtJTSBzaWduYXR1cmVzIHRvIHNhdmUgdGhlIG1lc3NhZ2VzLg0KDQooYykgTGV2ZXJh Z2Ug4oCcY29tbWVudCIgZmllbGQgb24gWE1MDQpJZiBNU0FzIG92ZXJ3cm90ZSBSRkM1MzIyLkZy b20gdGhlIGFnZ3JlZ2F0ZSByZXBvcnRzIGNvdWxkIGltcGx5IGl0LCBmb3IgZXhhbXBsZSB1c2lu ZyDigJxjb21tZW504oCdIG9yIGdlbmVyYXRpbmcgbmV3IGZpZWxkLg0KDQpCZXN0IHJlZ2FyZHMs DQoNCg0KDQotLQ0K5Yqg54Cs44CA5q2j5qi5DQogIOagquW8j+S8muekvlR3b0ZpdmUNCiAgMTAz LTAwMjcg5p2x5Lqs6YO95Lit5aSu5Yy65pel5pys5qmLMy0xLTQg55S75buK44OT44OrM0YNCiAg TWFpbDoga2FzZUB0d29maXZlMjUuY29tPG1haWx0bzprYXNlQHR3b2ZpdmUyNS5jb20+DQogIFRl bDogMDMtNTcwNC05OTQ4DQogIFRlbDogMDgwLTk4MDUtMDAyNQ0KICBVUkw6IGh0dHBzOi8vd3d3 LnR3b2ZpdmUyNS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cudHdv Zml2ZTI1LmNvbV9fOyEhQ1FsM21jSFgyQSFRV0phdVN0amdwRFYtenVlM1pScjRRTHR1ejZXLU80 d210QU9SNDdoNDFmMFRuVHBxNzNGeVFxVjB3V1VVSjU2VDFoMDlNQzI2USQ+DQoNCk1hc2FraSBL YXNlDQpUd29GaXZlLCBJbmMuDQprYXNlQHR3b2ZpdmUyNS5jb208bWFpbHRvOmthc2VAdHdvZml2 ZTI1LmNvbT4NCg0KDQoNCjIwMjAvMTAvMTUgMzoxN+OAgUJyb3RtYW4sIEFsZXggPEFsZXhfQnJv dG1hbj00MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpBbGV4X0Jyb3RtYW49NDBj b21jYXN0LmNvbUBkbWFyYy5pZXRmLm9yZz4+44Gu44Oh44O844OrOg0KDQpEdXJpbmcgYSBzZXNz aW9uIGF0IE0zQUFXRzUwLCBvbmUgb2YgdGhlIG90aGVyIHBhcnRpY2lwYW50cyBwcm9wb3NlZCBh biBpZGVhIHdoZXJlIGEgc2VuZGVyIGNvdWxkIG9wdGlvbmFsbHkgc2VuZCByZXBvcnRzIHRvIGEg ZG9tYWluIGhvbGRlciB3aGVuIHRoZXkgc2VuZCBtZXNzYWdlcyBvbiBiZWhhbGYgb2YgdGhhdCBk b21haW4uDQoNCkxldCdzIGNvbnNpZGVyIHRoZSBpZGVhIHRoYXQgZXhhbXBsZS5jb208aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUuY29tX187ISFDUWwzbWNIWDJBIVFX SmF1U3RqZ3BEVi16dWUzWlJyNFFMdHV6NlctTzR3bXRBT1I0N2g0MWYwVG5UcHE3M0Z5UXFWMHdX VVVKNTZUMWpHSGFmek9nJD4gaGFzIHByb3Blcmx5IGNyZWF0ZWQgU1BGL0RLSU0vRE1BUkMgcmVw b3J0cyBmb3IgdGhlbXNlbHZlcywgYW5kIGFyZSBlbmZvcmNpbmcgYXQgcD1yZWplY3QuICBBbmQg ZXhhbXBsZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUuY29t X187ISFDUWwzbWNIWDJBIVFXSmF1U3RqZ3BEVi16dWUzWlJyNFFMdHV6NlctTzR3bXRBT1I0N2g0 MWYwVG5UcHE3M0Z5UXFWMHdXVVVKNTZUMWpHSGFmek9nJD4gaGFzIHBlcm1pdHRlZCBFU1AtQSB0 byBkZWxpdmVyIG1lc3NhZ2VzIG9uIHRoZWlyIGJlaGFsZiwgYW5kIHRoZXkncmUgcHJvcGVybHkg c2V0dXAgaW4gdGhlIFNQRiwgYW5kIHByb3Blcmx5IHNpZ24gd2l0aCBES0lNLiAgRVNQLUIgaGFz IG5vIHN1Y2ggYXV0aG9yaXphdGlvbiwgYnV0IHNvbWUgZW50aXR5IGhhcyBhc2tlZCB0aGF0IEVT UC1CIHNlbmQgbWVzc2FnZXMgb24gYmVoYWxmIG9mIGV4YW1wbGUuY29tPGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLmNvbV9fOyEhQ1FsM21jSFgyQSFRV0phdVN0amdw RFYtenVlM1pScjRRTHR1ejZXLU80d210QU9SNDdoNDFmMFRuVHBxNzNGeVFxVjB3V1VVSjU2VDFq R0hhZnpPZyQ+LCBidXQgaXMgdGFyZ2V0aW5nIGEgbWFpbGJveCBwcm92aWRlciB3aG8gZG9lcyBu b3Qgc3VwcG9ydCBETUFSQywgbm9yIHNlbmQgcmVwb3J0cy4gIEJvdGggZW50aXRpZXMgcGFydGlj aXBhdGUgaW4gdGhpcyAiU2VuZGVycyBETUFSQyIsIGFuZCBub3cgZXhhbXBsZS5jb208aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUuY29tX187ISFDUWwzbWNIWDJBIVFX SmF1U3RqZ3BEVi16dWUzWlJyNFFMdHV6NlctTzR3bXRBT1I0N2g0MWYwVG5UcHE3M0Z5UXFWMHdX VVVKNTZUMWpHSGFmek9nJD4ga25vd3MgdGhhdCBFU1AtQSBpcyBhY3RpbmcgcHJvcGVybHksIHdo aWxlIEVTUC1CIG1heSBuZWVkIHNvbWUgY29udGFjdCB0byB1bmRlcnN0YW5kIG1vcmUgYWJvdXQg d2hhdCBpcyBnb2luZyBvbi4gIEknZCBzdWdnZXN0IHRoYXQgdGhlIHBvbGljeSBiZSBzZXBhcmF0 ZSBmcm9tIHRoZSByZWNlaXZpbmcgcG9saWN5ICgicD0iIGFuZCAicHM9IiAocG9saWN5LXNlbmRl cnMpIGZvciBleGFtcGxlLCB0aG91Z2gsIHRoYXQgbWF5IGFsc28gbGVuZCBpdHNlbGYgdG8gInBz cD0iKSwgYnV0IHJlc2lkaW5nIGluIHRoZSBzYW1lIEROUyBUWFQgcmVjb3JkLg0KDQpUaGlzIHdv dWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBidXQgYWxzbyBmb3IgTUJQcy9JU1BzIGFz IHdlbGwuDQoNCkRvZXMgdGhpcyBzb3VuZCBsaWtlIGEgcmVhc29uYWJsZSBpZGVhPyAgUmVwb3J0 IG92ZXJsb2FkPyAgTm90IGEgaGVscGZ1bCBkYXRhIHNldCBmb3IgYSBkb21haW4gaG9sZGVyPw0K DQpUaGFuayB5b3UgZm9yIHlvdXIgdGltZS4NCg0KLS0NCkFsZXggQnJvdG1hbg0KU3IuIEVuZ2lu ZWVyLCBBbnRpLUFidXNlICYgTWVzc2FnaW5nIFBvbGljeQ0KQ29tY2FzdA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFpbGluZyBsaXN0 DQpkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmNfXzshIUNRbDNtY0hYMkEh UVdKYXVTdGpncERWLXp1ZTNaUnI0UUx0dXo2Vy1PNHdtdEFPUjQ3aDQxZjBUblRwcTczRnlRcVYw d1dVVUo1NlQxZ0FZdXU5YWckPg0KDQo= --_000_MN2PR11MB43518D96C44A630AF011B8F9F71E0MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IGNvdWxkIGJlIHJlYXNvbmFibGUu Jm5ic3A7IEl0IGNvdWxkIG1ha2UgcmVwb3J0cyBub2lzeSB0aG91Z2g/Jm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbGV4IEJyb3RtYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNyLiBFbmdpbmVlciwgQW50aS1BYnVzZSAmYW1wOyBNZXNzYWdpbmcgUG9saWN5PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21jYXN0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG1hcmMgJmx0O2RtYXJjLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpNYXNha2kgS2FzZTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCA3OjM0IFBNPGJyPg0KPGI+VG86PC9iPiBCcm90 bWFuLCBBbGV4ICZsdDtBbGV4X0Jyb3RtYW49NDBjb21jYXN0LmNvbUBkbWFyYy5pZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbZG1hcmMtaWV0Zl0gVGhvdWdodHMgb24gJnF1b3Q7U2VuZGVycyBETUFSQyZxdW90OyBSZXBv cnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8g QWxleCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIHdvdWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBidXQgYWxzbyBmb3Ig TUJQcy9JU1BzIGFzIHdlbGwuPGJyPg0KPGJyPg0KRG9lcyB0aGlzIHNvdW5kIGxpa2UgYSByZWFz b25hYmxlIGlkZWE/ICZuYnNwO1JlcG9ydCBvdmVybG9hZD8gJm5ic3A7Tm90IGEgaGVscGZ1bCBk YXRhIHNldCBmb3IgYSBkb21haW4gaG9sZGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoZSBwZXJzcGVj dGl2ZSBvZiBNQlBzLCBJIGltYWdpbmVkIHRoZXNlIDMgdGhpbmdzOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYSkgSWRlbnRpZnkgdGhlIEUv VeKAmXMgSVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIE1CUHMgY2FuIHJlY2VpdmUgYWdncmVnYXRlIHJlcG9ydHMgYW5kIGNh biBlYXNpbHkgaWRlbnRpZnkgRS9V4oCZcyBJUCBhZGRyZXNzZXMuIEkgd29uZGVyIHRoYXQgaW5m b3JtYXRpb24gd291bGQgYmUgdXNlZnVsIGZvciBFQUMgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYikgR2F0aGVyIHRoZSBNU0Fz IGluZm9ybWF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Tb21lIE1TQXMgd2lsbCBvdmVyd3JpdGUgUkZDNTMyMi5Gcm9tIGJlZm9yZSBzZW5k aW5nIGFuZCBvdGhlcnMgd29u4oCZdC4gSW4gdGhlIGxhdHRlciBjYXNlcywgRE1BUkMgcmVzdWx0 cyBtaWdodCBiZSByZXBvcnRlZCBhcyDigJxkbWFyYz1mYWls4oCdIGJ1dCBNQlBzIGNhbiBtYWtl IHN1cmUgdGhlc2UgTVNB4oCZIGJlaGF2b2lyIG9yIHNwZWNpZmljYXRpb24gdmlhIGFnZ3JlZ2F0 ZSByZXBvcnRzLiBIb3BlZnVsbHksIE1CUHMNCiBtYXkgYWxsb3cgdG8gdXNlIDNyZCBwYXJ0eSBE S0lNIHNpZ25hdHVyZXMgdG8gc2F2ZSB0aGUgbWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihjKSBMZXZlcmFnZSDigJxjb21tZW50 JnF1b3Q7IGZpZWxkIG9uIFhNTDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgTVNBcyBvdmVyd3JvdGUgUkZDNTMyMi5Gcm9tIHRoZSBhZ2dyZWdh dGUgcmVwb3J0cyBjb3VsZCBpbXBseSBpdCwgZm9yIGV4YW1wbGUgdXNpbmcg4oCcY29tbWVudOKA nSBvciBnZW5lcmF0aW5nIG5ldyBmaWVsZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7liqDngKzjgIDm raPmqLk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQombmJzcDsgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6Ymxh Y2siPuagquW8j+S8muekvjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlR3b0ZpdmU8 YnI+DQombmJzcDsgMTAzLTAwMjcgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuadseS6rOmDveS4reWkruWMuuaXpeacrOap izwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMtMS00DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+55S75buK 44OT44OrPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+M0Y8YnI+DQombmJzcDsgTWFp bDogPGEgaHJlZj0ibWFpbHRvOmthc2VAdHdvZml2ZTI1LmNvbSI+a2FzZUB0d29maXZlMjUuY29t PC9hPjxicj4NCiZuYnNwOyBUZWw6IDAzLTU3MDQtOTk0ODxicj4NCiZuYnNwOyBUZWw6IDA4MC05 ODA1LTAwMjU8YnI+DQombmJzcDsgVVJMOiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L3d3dy50d29maXZlMjUuY29tX187ISFDUWwzbWNIWDJBIVFXSmF1U3RqZ3BE Vi16dWUzWlJyNFFMdHV6NlctTzR3bXRBT1I0N2g0MWYwVG5UcHE3M0Z5UXFWMHdXVVVKNTZUMWgw OU1DMjZRJCI+DQpodHRwczovL3d3dy50d29maXZlMjUuY29tPC9hPjxicj4NCjxicj4NCk1hc2Fr aSBLYXNlPGJyPg0KVHdvRml2ZSwgSW5jLjxicj4NCjxhIGhyZWY9Im1haWx0bzprYXNlQHR3b2Zp dmUyNS5jb20iPmthc2VAdHdvZml2ZTI1LmNvbTwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MjAyMC8xMC8xNSAzOjE3PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+44CBPC9zcGFuPkJyb3RtYW4sIEFsZXggJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4X0Jy b3RtYW49NDBjb21jYXN0LmNvbUBkbWFyYy5pZXRmLm9yZyI+QWxleF9Ccm90bWFuPTQwY29tY2Fz dC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDsiPuOBruODoeODvOODqzwvc3Bhbj46PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EdXJpbmcgYSBzZXNzaW9uIGF0IE0zQUFXRzUw LCBvbmUgb2YgdGhlIG90aGVyIHBhcnRpY2lwYW50cyBwcm9wb3NlZCBhbiBpZGVhIHdoZXJlIGEg c2VuZGVyIGNvdWxkIG9wdGlvbmFsbHkgc2VuZCByZXBvcnRzIHRvIGEgZG9tYWluIGhvbGRlciB3 aGVuIHRoZXkgc2VuZCBtZXNzYWdlcyBvbiBiZWhhbGYgb2YgdGhhdCBkb21haW4uPGJyPg0KPGJy Pg0KTGV0J3MgY29uc2lkZXIgdGhlIGlkZWEgdGhhdCA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cDovZXhhbXBsZS5jb21fXzshIUNRbDNtY0hYMkEhUVdKYXVTdGpncERW LXp1ZTNaUnI0UUx0dXo2Vy1PNHdtdEFPUjQ3aDQxZjBUblRwcTczRnlRcVYwd1dVVUo1NlQxakdI YWZ6T2ckIj4NCmV4YW1wbGUuY29tPC9hPiBoYXMgcHJvcGVybHkgY3JlYXRlZCBTUEYvREtJTS9E TUFSQyByZXBvcnRzIGZvciB0aGVtc2VsdmVzLCBhbmQgYXJlIGVuZm9yY2luZyBhdCBwPXJlamVj dC4gJm5ic3A7QW5kDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDov ZXhhbXBsZS5jb21fXzshIUNRbDNtY0hYMkEhUVdKYXVTdGpncERWLXp1ZTNaUnI0UUx0dXo2Vy1P NHdtdEFPUjQ3aDQxZjBUblRwcTczRnlRcVYwd1dVVUo1NlQxakdIYWZ6T2ckIj4NCmV4YW1wbGUu Y29tPC9hPiBoYXMgcGVybWl0dGVkIEVTUC1BIHRvIGRlbGl2ZXIgbWVzc2FnZXMgb24gdGhlaXIg YmVoYWxmLCBhbmQgdGhleSdyZSBwcm9wZXJseSBzZXR1cCBpbiB0aGUgU1BGLCBhbmQgcHJvcGVy bHkgc2lnbiB3aXRoIERLSU0uICZuYnNwO0VTUC1CIGhhcyBubyBzdWNoIGF1dGhvcml6YXRpb24s IGJ1dCBzb21lIGVudGl0eSBoYXMgYXNrZWQgdGhhdCBFU1AtQiBzZW5kIG1lc3NhZ2VzIG9uIGJl aGFsZiBvZg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1w bGUuY29tX187ISFDUWwzbWNIWDJBIVFXSmF1U3RqZ3BEVi16dWUzWlJyNFFMdHV6NlctTzR3bXRB T1I0N2g0MWYwVG5UcHE3M0Z5UXFWMHdXVVVKNTZUMWpHSGFmek9nJCI+DQpleGFtcGxlLmNvbTwv YT4sIGJ1dCBpcyB0YXJnZXRpbmcgYSBtYWlsYm94IHByb3ZpZGVyIHdobyBkb2VzIG5vdCBzdXBw b3J0IERNQVJDLCBub3Igc2VuZCByZXBvcnRzLiAmbmJzcDtCb3RoIGVudGl0aWVzIHBhcnRpY2lw YXRlIGluIHRoaXMgJnF1b3Q7U2VuZGVycyBETUFSQyZxdW90OywgYW5kIG5vdw0KPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUuY29tX187ISFDUWwzbWNI WDJBIVFXSmF1U3RqZ3BEVi16dWUzWlJyNFFMdHV6NlctTzR3bXRBT1I0N2g0MWYwVG5UcHE3M0Z5 UXFWMHdXVVVKNTZUMWpHSGFmek9nJCI+DQpleGFtcGxlLmNvbTwvYT4ga25vd3MgdGhhdCBFU1At QSBpcyBhY3RpbmcgcHJvcGVybHksIHdoaWxlIEVTUC1CIG1heSBuZWVkIHNvbWUgY29udGFjdCB0 byB1bmRlcnN0YW5kIG1vcmUgYWJvdXQgd2hhdCBpcyBnb2luZyBvbi4gJm5ic3A7SSdkIHN1Z2dl c3QgdGhhdCB0aGUgcG9saWN5IGJlIHNlcGFyYXRlIGZyb20gdGhlIHJlY2VpdmluZyBwb2xpY3kg KCZxdW90O3A9JnF1b3Q7IGFuZCAmcXVvdDtwcz0mcXVvdDsgKHBvbGljeS1zZW5kZXJzKSBmb3Ig ZXhhbXBsZSwgdGhvdWdoLCB0aGF0IG1heQ0KIGFsc28gbGVuZCBpdHNlbGYgdG8gJnF1b3Q7cHNw PSZxdW90OyksIGJ1dCByZXNpZGluZyBpbiB0aGUgc2FtZSBETlMgVFhUIHJlY29yZC48YnI+DQo8 YnI+DQpUaGlzIHdvdWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBidXQgYWxzbyBmb3Ig TUJQcy9JU1BzIGFzIHdlbGwuPGJyPg0KPGJyPg0KRG9lcyB0aGlzIHNvdW5kIGxpa2UgYSByZWFz b25hYmxlIGlkZWE/ICZuYnNwO1JlcG9ydCBvdmVybG9hZD8gJm5ic3A7Tm90IGEgaGVscGZ1bCBk YXRhIHNldCBmb3IgYSBkb21haW4gaG9sZGVyPzxicj4NCjxicj4NClRoYW5rIHlvdSBmb3IgeW91 ciB0aW1lLjxicj4NCjxicj4NCi0tPGJyPg0KQWxleCBCcm90bWFuPGJyPg0KU3IuIEVuZ2luZWVy LCBBbnRpLUFidXNlICZhbXA7IE1lc3NhZ2luZyBQb2xpY3k8YnI+DQpDb21jYXN0PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpk bWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciPmRt YXJjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmNfXzshIUNRbDNtY0hY MkEhUVdKYXVTdGpncERWLXp1ZTNaUnI0UUx0dXo2Vy1PNHdtdEFPUjQ3aDQxZjBUblRwcTczRnlR cVYwd1dVVUo1NlQxZ0FZdXU5YWckIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RtYXJjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB43518D96C44A630AF011B8F9F71E0MN2PR11MB4351namp_-- From nobody Mon Oct 19 06: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 A4C5B3A0A3A for ; Mon, 19 Oct 2020 06:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, 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=wisc.edu 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 ESg8PQ2vUx0w for ; Mon, 19 Oct 2020 06:50:41 -0700 (PDT) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 524AE3A0A06 for ; Mon, 19 Oct 2020 06:50:41 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QIG00C0DBSFNP90@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 19 Oct 2020 08:50:40 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.10.19.134517, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.9.22.5770001, SenderIP=[104.47.55.173] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IsNQw/69uqjKLpN+Dbm6LbGTpBu41rncnFq2L6ivRGsStou5jKeFdTSU3HUOl/Djs0CxRJE5G+8c9UR82sgS9IGL05Oc/HyhOtXwse/5H7NevsKEmwYujy25RwPyryXi8GhJdtl8Id75ftx2Xqk8LBz6ae8NdqfTMZ3DZdB9uHpMr6lGuw+U8UHl3GxFEBWLczE9MTt6jkQXcyTLibvnZHU8pnAF0UB6HtOgdLY7ymuFkCJMGIe34zEXvD5hIgNK4g8h3bZMGmDpN51jCiF+3oW1r6HswQEcIjbxdT0O+MLAlGw1O9V914e5MvwlH5Wx+OAlg8Hu/VTNTpphGhZIEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4W7nedRg0O+15cOu3GM/B2rXjgHoAy5nG6yFukgvz1c=; b=Nwy10zOEBg11Sbw2CPNi5z54wqnhPd0+/FcW2fwQsfNpgOXifGWSFCshe4gJrJ+VadSUt3BkRsuUpORLMUgotV9mMVxGXgS5Ny1J3zOr+lwbmJIAHxtnwP1qJMl+pcP0UqVbz2Yq6HxuhC6xuulbSN48GxkFQLjGRwkYVhzEnE5jBy8ZStpPjocFXURosz2DYWdFCK0vaXupInEZpVnAVjkrEw/Yre/z22jd1IsbhZooxSGAl+prLZREUmNBMfIrValLRaNFZZzTNsJV46JamCHWAjQ0y3+Vs96pBV0Re9fE594iMasoRQdjrAPMLsI7b9C7LNjxGThCS8NDfm/6og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4W7nedRg0O+15cOu3GM/B2rXjgHoAy5nG6yFukgvz1c=; b=PtsIW23uHt2eKIgpNrTtIrc0o6H9Vu9hUk4LoaUQMYrehrh7QEGwnkhDbAOTghL1rvQnoB9PX2ldEegAlEkY098m8mTCXLfpQ6cTF1FiMI8Q4cPcM0U4OoSLLVh7yNJDbUsfy1y3oZBlz9gxVa+WR0KVa3aswp2LQrVL3zgk0cY= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7222.namprd06.prod.outlook.com (2603:10b6:510:20::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Mon, 19 Oct 2020 13:50:38 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98%7]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 13:50:38 +0000 To: "Brotman, Alex" , "dmarc@ietf.org" References: <2d2018ba-6bd9-320e-b135-190c46e771da@wisc.edu> From: Jesse Thompson Message-id: <99547633-cdbc-df18-2d19-6b8715b95614@wisc.edu> Date: Mon, 19 Oct 2020 08:50:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR15CA0019.namprd15.prod.outlook.com (2603:10b6:610:51::29) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR15CA0019.namprd15.prod.outlook.com (2603:10b6:610:51::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Mon, 19 Oct 2020 13:50:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2b67b45f-eca0-4ee6-f2a0-08d87435f5f8 X-MS-TrafficTypeDiagnostic: PH0PR06MB7222: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BYarrQJFTOsq79BDMtdDcHXqNDcgakR562I7vMhwAWTt7zM9gby8G1mRLUgJ2Vdq7/lh5uJyM5Q8pHZr1+/0n3uPyuyfaQK2YQlqYQPLkAKjoEA/MOl3DqOuiw+bc5x4NtpOlrxQaEyUtN14e+edm9+8fHCAZTRYk66sOiPbbT8BchsV+XXyPZRuLTZ3z6lthjXf3H0DevabOGrR7hvRKKiqor+hYxzq+xgdtS7L/0FxTFPwmevND4tnM6F8QzZrgLzP6SsLIbH/R0boRAIh/zB7tldkDOfhJomPXY1fdsRplxK4E3Xu4T8hf6eMz2uuvAUwgAS1ZHGTfmj/EvUpZXF0ZRvZ5Oy+8E+YVrWjFn/cn9Bm5YY3yuGMJMqaLdVj X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(39860400002)(346002)(136003)(86362001)(31696002)(6486002)(66556008)(44832011)(5660300002)(16576012)(110136005)(66476007)(66946007)(2616005)(36756003)(316002)(786003)(956004)(31686004)(186003)(75432002)(478600001)(16526019)(2906002)(26005)(8676002)(53546011)(8936002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 3uNOzXypsoKc68FKDte4DCkp42xiNHt2AvudzXi4oRcrMxRp9rNb+af3/8P4MPWj91TvMufz14y9Le1cIJOup4KRBgYJNUB545+b7R3Jg+McbnoncSHIudnBEPjKoUXE5piFErV96BJfDit4xs5VCVoAXgU/7qqvjyHO2VpowK73jumTlF8mAx2+TbwwRt1nZ3Kr9p8jUr819UGRegQeoFkLB3/ZfGQS6DD+kA0om54RD9gExIAxg+1j3FNu6rKxOoQ7H9KLtWG7uSoorUE0oGztlchS0me1jZMlsq8PTpaqbSL1CSDGXAfQFKgdbnTeLpdvRQ3I4n9ZjhuzVh2FEhnvGXPOkJS7IfEQh5f0mbIjDj2s8OwaoqN5UIW+bcPCbMSt5AlN2mJR1kFiW9VT8orRtJ+8o37o9MBgxRDuzRoh1aFU9TYu24qDVlokv2nxfWAoiXtXbmzElJcEVg5Mzi9yJtA8frsg5OfbiWf+0dGKUtJTsEVYkfJmngALQ2+ydTQjxKLVHa+TavSxo8pR0IZiLmk/PqP6cnW0R937KnsbGYqkjWVo1552xjxR3K7XhcgjkIEQH4lE6E55A/HUatgQrcXSeCBI7xcYkNojsU7hHcDuN9MPPN28HbIj2vu8jX7jZViLL/5N4BYSHpxQ5Q== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 2b67b45f-eca0-4ee6-f2a0-08d87435f5f8 X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2020 13:50:38.4634 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IkE0/zF3ozuEOxH/1mdgmnqZq18wf+mVq/Z4DNZUyBZM1mXSkhKCFyRlP/JddQSk0QftkoTKI6BFyJIa4VYa4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7222 Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 13:50:43 -0000 On 10/19/20 7:17 AM, Brotman, Alex wrote: > Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP address). Tell the domain who is the entity responsible for attempting this delivery? This might need to be a hash of some sort. > I think this sort of data would benefit both the domain holder, but as you suggested, also the ESP. They could aggregate their own data to show drift/misconfiguration. And yes, as you also suggest, sometimes the DNS guys change things that the MarComm team doesn't know about, believing they're doing the proper thing. ESPs who hash/obscure the customer ID may want to consider a special support portal for mailop->ESP questions. It would be frustrating to be sent to front-line agents and given the stiff arm. >> 3) Domains that don't have a DMARC record > [Brotman, Alexander] > > It might be possible, depending how this were created, to have a "Senders DMARC" Policy, without a proper DMARC policy. Perhaps marginally useful to the domain. Sent to where, postmaster? Jesse From nobody Mon Oct 19 07:59:34 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 E49E73A00D2; Mon, 19 Oct 2020 07:59:32 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=vYzY4/tY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Pg4uXv25 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 WsKfl8JujY7Y; Mon, 19 Oct 2020 07:59:31 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDC93A005E; Mon, 19 Oct 2020 07:59:31 -0700 (PDT) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JEs7do018750; Mon, 19 Oct 2020 10:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=CSbi+ZLQ4jLfVyYNHAQ/p08aE8S6dvRmMBCJLgJzOxE=; b=vYzY4/tY3bNW7S+R+A0EaWxfOJtTi5szXz/UeJJ78ZdBNSqrTzG5t1Y38lAmS/C2+4P3 TvuNqJgAaqtz/h6MFLNI0hxvluJUDOJYlMTaT+anhMWCNS4xgD17dqjdhWf3g3/jqtHh oe+EtQV4MS5ttl7W/vxxRM0UBou0rAzKbJubTITJbaajea6FprQPCwDjiI5wwYlV6PNf ypC/pDX22kEj/Jag779DJYwwDnGs+V9ymV2BmCJHBn3DvPlvVphxrTevgH5QnItS1E/e mRLO0Kwx018tD4liVHpLou9xgoTdRfg1q6tOud4GDssUYVswl4hKxUrJnmTh8Pp3ZfHG hg== Received: from pacdcex49.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 3487wrfa6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 10:59:31 -0400 Received: from PACDCEX45.cable.comcast.com (24.40.2.144) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 10:59:29 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX45.cable.comcast.com (24.40.2.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 19 Oct 2020 10:59:29 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.173) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 10:59:27 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4599.namprd11.prod.outlook.com (2603:10b6:208:26d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.24; Mon, 19 Oct 2020 14:59:26 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 14:59:26 +0000 From: "Brotman, Alex" To: Jesse Thompson , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Thoughts on "Senders DMARC" Reports Thread-Index: AdaiVc1hNC32VOspTmuLojW6xIuQgAAJ8e2AAOS13BAAA5lGgAACPEpA Date: Mon, 19 Oct 2020 14:59:25 +0000 Message-ID: References: <2d2018ba-6bd9-320e-b135-190c46e771da@wisc.edu> <99547633-cdbc-df18-2d19-6b8715b95614@wisc.edu> In-Reply-To: <99547633-cdbc-df18-2d19-6b8715b95614@wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:d9e5:68ca:5ca1:1cc5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b127f00-5046-4329-8317-08d8743f925a x-ms-traffictypediagnostic: MN2PR11MB4599: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Eg7ixGABFhpmGAhOjIR351W5bclm07fGipm7jAEVCvkTrQ/tnJ+8I9ReT4MQbf+T8jUfNzKrt7BFYBoUYzxFMsHdb1LGVfs7fIdBDj03CDPj/F2nw7lmAkKE/NMpf6rORIwRrUB8p9uBLCcJ2kg9OszWxMOMvHn7NmpL3BnE/bOxk/fTpE+bUAm9gzFC/jpUecC5Ybr+gq0/vUHnII3i5Bzg56snJUhCvVs9uV+3PoJ/tHtsQ2X8+iFSyYqTbyuhI8uI0bTGLdWshp1/cBwXIug4/ZZn0eoSf8iw8fHfMS4Wphn7FV50IQmYcbyegljn64kv1kp3PWWdyZU4y7UDgQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(2906002)(64756008)(66446008)(66476007)(66556008)(110136005)(86362001)(316002)(5660300002)(66946007)(76116006)(55016002)(53546011)(83380400001)(71200400001)(52536014)(8676002)(9686003)(7696005)(186003)(6506007)(33656002)(8936002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 5JRrMuj1a4qNlUqVCkfNGv54GkmEsF/Vq+tmGigAxiQNytmQvn/8eQgLYhrW9wIyFw4GJ3ytj+EyTZhUpnru41uOEbzT8JM39kd8RLfbtud434ViBIRFkwFma2GffSXFfhEiBGew3NYciUnTni6c7AA7uHQpkojB4TdsstxmSsroPwhqE4d9qANrNE1LlMtyuWfR0jVVef8g5ce2UUl+43Ti7KLR/KMIn1sIKd0pOLrws27CH8+Rom9Hn2ZOrcwSzC1P0g4+2R8pbfEwRPQQxTHq1v9o45G6dNo5xS/8SLR8v0X0+3BkO4MyecIISLwJNi6JqvPL77LGC2nbJmV2zPsruTYAALR+8thQ2G3imncPkX15Ob6jOMgSRgU9kvhqKzyLi3ebBG/DF4xD1Nkz1/CRdObXtvFomOSlCdBUCtrrx76LtRApLGuJZXEZAOuvbnkZIa2Zja1TGF/YbCzSIKNnmWsRXekKs/QyktH4dIRLttS0ke5ACBxWTTV/TS7uCz/NicMtjS8H4dcvgmPgr5nQMCBWBHkWqwQwEQabfmS6YkW62fmQ035QGwcPV/SBL918wbvLP+5KN+40yllIvcUeXcAjKAG5G6FBoiCIOMc7eclj4U9SVsEBO2E4IMRS89JJODqrMf6BjoHisXj3uMr7B+bwBVTz/EMBfYM+P3Ee8/NJghmOB/c4as+INqN4sqcwdw8h8dEY8BDs4PYTow== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ak+9opCebuWQI1LVs+zT5mbDfA6uuOkGWFboAgeyX1EWzi/hfyaM1v3PVkuCfH9YoBJeGspwt7DxDyYKDlbpPEqUvuY6sDme9Ug8Z3uru/nMZezs3KgEmb27mdX1wSDYNcF/APJ7hbI039+e9ttAHinREpp8sD0g8GT8tZnawROa0w57aRziSnQ0sFDzs5PG3bEw39tQZmS5QXcJ3b6jcJZs88REWomoZXeWdLWkX6eHrTr/G3rZoCIKsX2XHglHRpkfgeFb7behLqtxaL1NjUfZ418EcDp04jJBLw8P/K93Zrltn8FsJEGM0g8nhAoNr8zAGILNqzhXcAYxu5gwSg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vMl9wo8CZqXxdPWcP6hMYm7t2SkKrUj7yN00NCI2N4E=; b=PJ5F5KeA2gF+JuuihrJ6IKWtEi+SSRHwExu0g+EMcaWBiS4Tec6a/W7OoalEwSxFzeEl3UcukSQKBmEbaGZtJ50nVmnIGQVULJw3k2jBkXREXJmkc4RV35Hxw7xN4G8P4bVfEn/4Pt17kMpQkDu5E8pvWEpQLHJfBdbdyDG1CQS0ETJfbPWiAdb6hMy1wRbL9o845/iBZFCW9lx9Qu0ZYlmLatdoaCwrZ/ciz6/cfdRwTCBH+BX3LavzTogV6E3SRhZUJ3J1t8fMgZMuFOX6Kg8WpbpmDVQfP6ixjHSBOoiMapV23jW8RTPUJ6hmEZpgqC30oUXfvP216XedIU92rg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vMl9wo8CZqXxdPWcP6hMYm7t2SkKrUj7yN00NCI2N4E=; b=Pg4uXv25LmI3s0f6K97khiUGMJaGi2FVbkYtEKc1FTraUwXZwrsYGbvq1pNG87L9eug9roEwa1h97XJPxeCzXUSe1FA3tL2UwsPmXdbCeRy6Y22zti0gy5Vo7+SE4LlGlwK47cB9p093JenRy2qmXdYuiz+g0cKs7sdVxbX12m8= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 8b127f00-5046-4329-8317-08d8743f925a x-ms-exchange-crosstenant-originalarrivaltime: 19 Oct 2020 14:59:25.8453 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: OOSl4i0MUhWCyeq0iKct4VzG9xvkryEfmh3nRseh+jmscZmX6W83FxrbrP+BoHsuhmQdOA0bFd8ljSg50RjymU5ulFPpyrOvFnnLoqMII8Y= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4599 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWQ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:59:33 -0000 DQoNCi0tDQpBbGV4IEJyb3RtYW4NClNyLiBFbmdpbmVlciwgQW50aS1BYnVzZSAmIE1lc3NhZ2lu ZyBQb2xpY3kNCkNvbWNhc3QNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKZXNzZSBUaG9tcHNvbiA8amVzc2UudGhvbXBzb249NDB3aXNjLmVkdUBkbWFyYy5pZXRmLm9y Zz4NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDk6NTEgQU0NCj4gVG86IEJyb3Rt YW4sIEFsZXggPEFsZXhfQnJvdG1hbkBjb21jYXN0LmNvbT47IGRtYXJjQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gVGhvdWdodHMgb24gIlNlbmRlcnMgRE1BUkMiIFJlcG9y dHMNCj4NCj4gT24gMTAvMTkvMjAgNzoxNyBBTSwgQnJvdG1hbiwgQWxleCB3cm90ZToNCj4gPiBT dXJlLCBJIHRoaW5rIE1hc2FraSBLYXNlIGlzIHN1Z2dlc3Rpbmcgcm91Z2hseSB0aGUgc2FtZSB0 aGluZyAoYWxvbmcgd2l0aA0KPiBJUCBhZGRyZXNzKS4gIFRlbGwgdGhlIGRvbWFpbiB3aG8gaXMg dGhlIGVudGl0eSByZXNwb25zaWJsZSBmb3IgYXR0ZW1wdGluZyB0aGlzDQo+IGRlbGl2ZXJ5PyAg VGhpcyBtaWdodCBuZWVkIHRvIGJlIGEgaGFzaCBvZiBzb21lIHNvcnQuDQo+DQo+ID4gSSB0aGlu ayB0aGlzIHNvcnQgb2YgZGF0YSB3b3VsZCBiZW5lZml0IGJvdGggdGhlIGRvbWFpbiBob2xkZXIs IGJ1dCBhcyB5b3UNCj4gc3VnZ2VzdGVkLCBhbHNvIHRoZSBFU1AuICBUaGV5IGNvdWxkIGFnZ3Jl Z2F0ZSB0aGVpciBvd24gZGF0YSB0byBzaG93DQo+IGRyaWZ0L21pc2NvbmZpZ3VyYXRpb24uICBB bmQgeWVzLCBhcyB5b3UgYWxzbyBzdWdnZXN0LCBzb21ldGltZXMgdGhlIEROUw0KPiBndXlzIGNo YW5nZSB0aGluZ3MgdGhhdCB0aGUgTWFyQ29tbSB0ZWFtIGRvZXNuJ3Qga25vdyBhYm91dCwgYmVs aWV2aW5nDQo+IHRoZXkncmUgZG9pbmcgdGhlIHByb3BlciB0aGluZy4NCj4NCj4gRVNQcyB3aG8g aGFzaC9vYnNjdXJlIHRoZSBjdXN0b21lciBJRCBtYXkgd2FudCB0byBjb25zaWRlciBhIHNwZWNp YWwNCj4gc3VwcG9ydCBwb3J0YWwgZm9yIG1haWxvcC0+RVNQIHF1ZXN0aW9ucy4gIEl0IHdvdWxk IGJlIGZydXN0cmF0aW5nIHRvIGJlIHNlbnQNCj4gdG8gZnJvbnQtbGluZSBhZ2VudHMgYW5kIGdp dmVuIHRoZSBzdGlmZiBhcm0uDQo+DQpbQnJvdG1hbiwgQWxleGFuZGVyXQ0KDQpUaGVyZSBhcmUg bGlrZWx5IGEgZmV3IHdheXMgdG8gYWRkcmVzcyBzdXBwb3J0aW5nIGEgaGFzaGVkIHNlbmRlciwg YnV0IHllcywgc29tZXRoaW5nIHRvIGNvbnNpZGVyLg0KDQo+DQo+ID4+IDMpIERvbWFpbnMgdGhh dCBkb24ndCBoYXZlIGEgRE1BUkMgcmVjb3JkDQo+ID4gW0Jyb3RtYW4sIEFsZXhhbmRlcl0NCj4g Pg0KPiA+IEl0IG1pZ2h0IGJlIHBvc3NpYmxlLCBkZXBlbmRpbmcgaG93IHRoaXMgd2VyZSBjcmVh dGVkLCB0byBoYXZlIGEgIlNlbmRlcnMNCj4gRE1BUkMiIFBvbGljeSwgd2l0aG91dCBhIHByb3Bl ciBETUFSQyBwb2xpY3kuICBQZXJoYXBzIG1hcmdpbmFsbHkgdXNlZnVsDQo+IHRvIHRoZSBkb21h aW4uDQo+DQo+IFNlbnQgdG8gd2hlcmUsIHBvc3RtYXN0ZXI/DQpbQnJvdG1hbiwgQWxleGFuZGVy XQ0KDQpJZiB5b3UgZGlkbuKAmXQnIHdhbnQgYSByZWd1bGFyIERNQVJDIHBvbGljeSwgeW91IHN0 aWxsIG1pZ2h0IGJlIGFibGUgdG8gZG8gc29tZXRoaW5nIGFraW4gdG86DQoNCl9kbWFyYy5leGFt cGxlLmNvbSBUWFQgInY9RE1BUkMxIDsgcHM9bm9uZSA7IHNydWE9bWFpbHRvOnNlbmRlci1yZXBv cnRzQGV4YW1wbGUuY29tIg0KDQpTbyB0aGUgc2VuZGVycyBtYXliZSBzaG91bGQgbm90IHRha2Ug YWN0aW9uIGlmIHRoZSBka2ltL3NwZiB3ZXJlIG5vdCBnb2luZyB0byBwYXNzLCBhbmQgc2VuZGVy IHJlcG9ydHMgb2Ygc3VjaCBkYXRhIHdvdWxkIGJlIHNlbmQgdG8gdGhlIGFkZHJlc3Mgc3BlY2lm aWVkLiAgVGhleSB3b3VsZCBub3QgYmUgY3JlYXRpbmcgRE1BUkMgcG9saWN5IGZvciByZWNlaXZl cnMgYXQgdGhhdCBwb2ludC4NCg0KDQoNCg0KPg0KPiBKZXNzZQ0K From nobody Mon Oct 19 14:48: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 81EBA3A0C39 for ; Mon, 19 Oct 2020 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 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_H2=-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=emersion.fr 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 jIGmFTXKZ3HJ for ; Mon, 19 Oct 2020 14:48:47 -0700 (PDT) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (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 BD38A3A0C25 for ; Mon, 19 Oct 2020 14:48:44 -0700 (PDT) Date: Mon, 19 Oct 2020 21:48:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1603144121; bh=MBagcCsVmB7Kbb13o89cKaG7YwNC9HB0VFCpXnhOMXg=; h=Date:To:From:Reply-To:Subject:From; b=XzU3Og0+G5btPzXKy1AMcdyvO2ULvlC1GA65oIsukJS403ITMQ8kMv6H/2hq3q6X5 w8yBuhIxc+URtE/eAcQF8vfJfIw00iqGNHENOkcclge2a0NHpz4brVmj4nAGWep5Vk J1wT12XG5zKf2znWSrHC/Huz65Pgm/AkoOaxG7QFlucxsN8RuQ6N94oh8I7PnyUURb 4yuHux5siKEtaTP39laTnPCwbBh2qUky32vc4Q74emDWTI63vQO8IrAA/1JfHTq0k0 g8t548dWMbruuttd3Jv4kSAs8Z2E2b0f/Z4olpRFxbzJYwLXUHLz1ALQ1qfWD3NG1A 9OHTIACz+mrmA== To: "dmarc@ietf.org" From: Simon Ser Reply-To: Simon Ser Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 21:48:50 -0000 Hi all, I've submitted a draft for a new Authentication-Results method a while back [1]. I'd like to get some feedback. My use-case is: on a mailing list system [2], I'd like to display PGP signature status, if a PGP signature is present. I'd like the verification to happen once in a mail filter. Having a standardized Authentication-Results method that mail filters can generate and mail user agents can display would be helpful. A very similar thing is already implemented for DKIM. Does this sounds like something worth doing? Thanks, Simon [1]: https://datatracker.ietf.org/doc/draft-ser-authentication-results-open= pgp/ [2]: https://lists.sr.ht From nobody Mon Oct 19 18:24: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 F003A3A08C4 for ; Mon, 19 Oct 2020 18:24:26 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=B5q5aJxj; dkim=pass (2048-bit key) header.d=taugh.com header.b=FCGTdhc6 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 sU9p5q7wiiVM for ; Mon, 19 Oct 2020 18:24: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 CA2713A08C3 for ; Mon, 19 Oct 2020 18:24:24 -0700 (PDT) Received: (qmail 22637 invoked from network); 20 Oct 2020 01:24: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=586b.5f8e3c46.k2010; bh=4vl5Wjziog+bQUTlrlfLH1Xaxm79hsMoh+zXCd2MhDg=; b=B5q5aJxjvaNTk8t/yUvyg/L0dv/uQfvfau/1/RJSLJfL+qhXYAfjkxYwor7fwzd/57RXmxpTL7vU9DRcguPnwsZ4W0sItdJHVrl/JBbkRJmSVW72BC2nN2dOH9VMvmnO8MsOKyj/NO8cXkLMFGWaECOGl5qvfgByUrbhFMr9i6ZYcGUzQhHfV/sizBUVjeFglyidehQb+CgsX/e/Iz56hvyXBlu08LtwHFeiWFVN/uA2/yxKrpKRmi87q/EENbPhWtMUns2/RjsXgXjpvoFQ6l7H+1obTYboKm/+L8Wn8rcqq1KQkVyP2GvqVLwwwWGhMdjn6WdoknHsnK5m4j53aA== 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=586b.5f8e3c46.k2010; bh=4vl5Wjziog+bQUTlrlfLH1Xaxm79hsMoh+zXCd2MhDg=; b=FCGTdhc6a8GjS1IYYkoLREqHtwTtJJb+gg6p+nQrPYNOlWZ/U86UnrJp0KizpJu7Nd/6WeUZj2H8mo5PXdx8jk3hEKulfh5lq9cgX92Hfx+AYYRoBS0Q6C31acZqUUd06bdACaAt1J7g0Hj/lFOViLyQcOVTm7tbCYMTfqo5p0dYM1Dv8HKdF0IzgvlN71f6h6KKgft2Lae4UXIlIFEt1MJet5/CxFbdVQvOn01UkqzaZG0hRkmqPNtv9mB91yxNrt+uJKdhJwg3efKFndAVdg0xB3QUv3NK4v50HwB33j0rt6WAem/3LMDfnjyAuWYU8UjL4gfsSQqLNhRZomB7xA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 20 Oct 2020 01:24:21 -0000 Received: by ary.qy (Postfix, from userid 501) id 4A46623B1365; Mon, 19 Oct 2020 21:24:20 -0400 (EDT) Date: 19 Oct 2020 21:24:20 -0400 Message-Id: <20201020012421.4A46623B1365@ary.qy> From: "John Levine" Reply-To: ietf-822@ietf.org To: dmarc@ietf.org, ietf-822@ietf.org Cc: contact@emersion.fr 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] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 01:24:27 -0000 [ Replies sent to ietf-822 since this is unrelated to DMARC ] In article you write: >I've submitted a draft for a new Authentication-Results method a while >back [1]. I'd like to get some feedback. > >My use-case is: on a mailing list system [2], I'd like to display PGP >signature status, if a PGP signature is present. ... >[1]: https://datatracker.ietf.org/doc/draft-ser-authentication-results-openpgp/ >[2]: https://lists.sr.ht >Does this sounds like something worth doing? Maybe, but probably not. DKIM is intended as a signature for messages in transit, applied as a message leaves its sending system and verified as it arrives at the recipient system. The sorts of changs made by list managers often break DKIM signatures, causing all sorts of excitement when DMARC is involved. PGP signatures (and S/MIME signatures) are normally applied and verified by the end-user mail programs. They're in the message body and the changes that list managers typically make, tagging the signature or adding body headers or footers, are unlikely to break a PGP signature. Or to put it another way, if your A-R header said the PGP signature on the message contents was good, but the end user found it was bad, that would suggest something was screwed up, not normal mailing list processing. R's, John PS: It's not unreasonble for a list manager to use a PGP signature to verify that it should forward a message, but there's not much use to adding a header saying it did so. From nobody Thu Oct 22 00:52:04 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 0D9A23A0ECB for ; Thu, 22 Oct 2020 00:52:03 -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 VrsfF27glkZM for ; Thu, 22 Oct 2020 00:52:01 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA7B3A0EC6 for ; Thu, 22 Oct 2020 00:52:01 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id v23so340226vsp.6 for ; Thu, 22 Oct 2020 00:52:01 -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=SrZROicvktXMhJmlKQ8siVSphDRdmg4mM3awWXfkaAA=; b=kORzCEx6SrFwT3EcQECuUh2Mp20RP6lQVDZaQK56jdoL8ZwV5eM5WkG9p49uK1TgQn b5Ju/xn32PIl5jiQ6dEUTPuTBWFERMw74grJlcMIe7e/mPHOd4qMI2yRwfigu827nmEy b0qAWDK7ToT/c09HMk6KHLLVXY/2Ft5MwCnXabfzm45RFyW85I/ybH1226pjChKQwJ0a KpsLGKyg8yqiVpv7b3xplAHW6GUWYF++kECaSGZiXm5VQEtpDvkW+rq2NVi7h7vQl8J7 prNoGXEOlSxdbZeH09sv+xKM16mHXSg0ISqFOytGuuUPFtDY7fsj9amIuTAZB3SCjgPG mYsw== 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=SrZROicvktXMhJmlKQ8siVSphDRdmg4mM3awWXfkaAA=; b=fV56MIY85XNllJsffkL3cybY87c4SOIwlv9eqt74zYYG3o24Nna6PQzuyfZA+IZ2on tqZo/AbALsEgftuK2smMz+WisptgmEWv1YRMT2bCaY1XQHU+5s6ttM/frThpasXQjj2Y vAH4Y5OqOF0z3p13s076dnQF1Pq5PuugV/UBzlctzJwUSnj9EgWNLw6BdYIf9wfmTffq hZEe2cxtzR81gd5aW5bkUTVQ4p6lMYSy2BaKlI47mgXnuUcZWlNGF5MZAD5qIO5vQW1y MxZS+Rbuc7XSWQDxB04V8shMW6pq7BstMcwdGl+SxxGHiE7lzQWWtG2ubszOPuqmnMuY pikQ== X-Gm-Message-State: AOAM5311rfS8RmhYgT/QtAhlTCWC+xuUK8SWmKXV8BA/LO2k69LfAx0B 2K57L86td0GYg5nxOZ0kuj0LIPeYjjWlqcA0Q390mhAAKgE= X-Google-Smtp-Source: ABdhPJxzOSZKAaNBOy9iJObytVBS5q+E8M5QjtRj5S8pyJMXUNGnA2EiyZ1VYwgP8slpYxqqh/z1PuIWpLdU2t4/uEo= X-Received: by 2002:a67:e9d8:: with SMTP id q24mr512139vso.54.1603353120384; Thu, 22 Oct 2020 00:52:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 22 Oct 2020 00:51:49 -0700 Message-ID: To: Simon Ser Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000030aca305b23dbd3b" Archived-At: Subject: Re: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 07:52:03 -0000 --00000000000030aca305b23dbd3b Content-Type: text/plain; charset="UTF-8" On Mon, Oct 19, 2020 at 2:49 PM Simon Ser wrote: > I've submitted a draft for a new Authentication-Results method a while > back [1]. I'd like to get some feedback. > > My use-case is: on a mailing list system [2], I'd like to display PGP > signature status, if a PGP signature is present. I'd like the > verification to happen once in a mail filter. Having a standardized > Authentication-Results method that mail filters can generate and mail > user agents can display would be helpful. A very similar thing is > already implemented for DKIM. > > Does this sounds like something worth doing? > Your references to RFC 7601 should change to RFC 8601. Are there any existing implementations of MTAs that generate this, and MUAs that consume it? -MSK --00000000000030aca305b23dbd3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 19, 2020 at 2:49 PM Simon Ser= <contact@emersion.fr> wro= te:
I've submitted a draft for a new Authentication-Results = method a while
back [1]. I'd like to get some feedback.

My use-case is: on a mailing list system [2], I'd like to display PGP signature status, if a PGP signature is present. I'd like the
verification to happen once in a mail filter. Having a standardized
Authentication-Results method that mail filters can generate and mail
user agents can display would be helpful. A very similar thing is
already implemented for DKIM.

Does this sounds like something worth doing?

Your references to RFC 7601 should change to RFC 8601.

=
Are there any existing implementations of MTAs that generate thi= s, and MUAs that consume it?

-MSK
<= /div> --00000000000030aca305b23dbd3b-- From nobody Thu Oct 22 04:36: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 119583A0A3D for ; Thu, 22 Oct 2020 04:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8XyTGo__lbh for ; Thu, 22 Oct 2020 04:36:55 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 4DF7E3A0A2D for ; Thu, 22 Oct 2020 04:36:55 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id s14so1040247qkg.11 for ; Thu, 22 Oct 2020 04:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ybLZKrlO1RaAGaSh6FtBtRTCwTgnTBsBK2r5akgxG70=; b=G9iWMJyVe9m96h57iNK5OV5b5iblbqQjAcfS5WbwGnhli06m8UWYu20Y/suoivpDJ0 owHzxFV0PxYsaAcsq94f0Nxtg+d5Mof0OP4K25OTQSItMzRsp31RdYgFAw+4xdvfmTow Vuc5aVuZtzJctHt/72fStp4UB37z8DByB6FuT7QmGNHNJA0WFYeZJb2BXjKNMTnzVH9h uyoMZNGAIhCU0ZPtT72AOVQFCG7H6YJ47/tT3hhKmQk9NEcJ8vhIkLxdJVE669afzL6F /qjF+dD4oOGgprHYdk3SsfagPT9c/7LD28izcYlI4IpExeB/NX7DpkrcYZ7NrTbFfqlh YrpA== 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=ybLZKrlO1RaAGaSh6FtBtRTCwTgnTBsBK2r5akgxG70=; b=UlDvrGDUnHRzYLAOHybg010Va/vRR6IpP39dXHzgK05C+//GH9wr7bi6hbuD2if/DD Weqc3oFPZi/436ixLU1Q7KS+tAOG9bQ1KgSA/YKBWZI4P98FdF5hUhU3i8bkVcEnDAPz ae7l7Z/EsGFW5M3Vin3BpWWWulH/cB6+bLRyQgcAkT1N8j6zTQhjSSrYSOMtl2lmasYL jTm2RgKsuMETLbBxyco1dGUeGKmraYZw8qnst2/FUpr8tKDYIryIqpDB+YkihpnrTiu/ g+YOOYLikZ3R4FVcGjjUaiHiOvRRzpzjYc4dsLL21/t7fFBHZfOtzcu9U/lEh79JefDW Kmiw== X-Gm-Message-State: AOAM5323PK60ho0rTtof89iEpRrtw+BUuMttEuo/gIFKNzyl047JADH9 XFTJc2VWhJVMlda1sM8VHumzreMjaFsYri1Xoybh+sYO X-Google-Smtp-Source: ABdhPJw6lrGkLDSMeg/Zl0j32taTbUYSDqQozf4oORhCa92XP8LxNnSTleAHcx8zcgsfOLooy0YHZRl6C09OKNAsz08= X-Received: by 2002:a37:7086:: with SMTP id l128mr1891394qkc.64.1603366614317; Thu, 22 Oct 2020 04:36:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Thu, 22 Oct 2020 07:36:43 -0400 Message-ID: To: "Brotman, Alex" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dbdeb05b240e1af" Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 11:36:57 -0000 --0000000000007dbdeb05b240e1af Content-Type: text/plain; charset="UTF-8" On Wed, Oct 14, 2020 at 2:17 PM Brotman, Alex wrote: > During a session at M3AAWG50, one of the other participants proposed an > idea where a sender could optionally send reports to a domain holder when > they send messages on behalf of that domain. > > Let's consider the idea that example.com has properly created > SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject. And > example.com has permitted ESP-A to deliver messages on their behalf, and > they're properly setup in the SPF, and properly sign with DKIM. ESP-B has > no such authorization, but some entity has asked that ESP-B send messages > on behalf of example.com, but is targeting a mailbox provider who does > not support DMARC, nor send reports. Both entities participate in this > "Senders DMARC", and now example.com knows that ESP-A is acting properly, > while ESP-B may need some contact to understand more about what is going > on. I'd suggest that the policy be separate from the receiving policy > ("p=" and "ps=" (policy-senders) for example, though, that may also lend > itself to "psp="), but residing in the same DNS TXT record. > > This would not be meant just for ESPs, but also for MBPs/ISPs as well. > > Does this sound like a reasonable idea? Report overload? Not a helpful > data set for a domain holder? > > Thank you for your time. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > In the example you give, wouldn't ESP B be just a wee bit suspicious and see HUGE red flags that a non-validating receiver is targeted for mail purporting to be from a domain publishing p=reject? If they were unsure and concerned enough to want to send reports then why wouldn't they be concerned enough to reach out to the domain owner/administrator without such a report scheme? or to reject the customer? (Oh, leaving money on the table, the horror!) Either the mailstream involved is malicious, or it is not. If it's malicious, I would expect (and have experienced) reports coming in from end users (recipients) to customer service, abuse@, postmaster@, etc. very quickly. This would typically be much faster than once a day automated reports from the ESP, etc. If it's not malicious, the juice may not be worth the squeeze. I believe - no, know - that domains paying attention to existing reports, logs, inbound mail to role accounts, etc. have no pressing need for something like this. Domains not paying attention to these things are unlikely to pay attention to these proposed reports anyways. Michael Hammer --0000000000007dbdeb05b240e1af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 14, 2020 at 2:17 PM Brotm= an, Alex <Alex_Brotman=3D40comcast.com@dmarc.ietf.org> wrote:
During a session at M3AAWG50, one of the other= participants proposed an idea where a sender could optionally send reports= to a domain holder when they send messages on behalf of that domain.

Let's consider the idea that example.com has properly created SPF/DKIM/DMA= RC reports for themselves, and are enforcing at p=3Dreject.=C2=A0 And example.com<= /a> has permitted ESP-A to deliver messages on their behalf, and they'r= e properly setup in the SPF, and properly sign with DKIM.=C2=A0 ESP-B has n= o such authorization, but some entity has asked that ESP-B send messages on= behalf of example.com, but is targeting a mailbox provider who does not suppo= rt DMARC, nor send reports.=C2=A0 Both entities participate in this "S= enders DMARC", and now example.com knows that ESP-A is acting properly, w= hile ESP-B may need some contact to understand more about what is going on.= =C2=A0 I'd suggest that the policy be separate from the receiving polic= y ("p=3D" and "ps=3D" (policy-senders) for example, tho= ugh, that may also lend itself to "psp=3D"), but residing in the = same DNS TXT record.

This would not be meant just for ESPs, but also for MBPs/ISPs as well.

Does this sound like a reasonable idea?=C2=A0 Report overload?=C2=A0 Not a = helpful data set for a domain holder?

Thank you for your time.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

In the example you give, wouldn= 't ESP B be just a wee bit suspicious and see HUGE red flags that a non= -validating receiver is targeted for mail purporting to be from a domain pu= blishing p=3Dreject? If they were unsure and concerned enough to want to se= nd reports then why wouldn't they be concerned enough to reach out to t= he domain owner/administrator without such a report scheme? or to reject th= e customer? (Oh, leaving money on the table, the horror!)
Either the mailstream involved is malicious, or it is not. If i= t's malicious, I would expect (and have experienced) reports coming in = from end users (recipients) to customer service, abuse@, postmaster@, etc. = very quickly. This would typically be much faster than once a day automated= reports from the ESP, etc. If it's not malicious, the juice may not be= worth the squeeze.

I believe - no, know - that domains p= aying attention to existing reports, logs, inbound mail to role accounts, e= tc. have no pressing need for something like this. Domains not paying atten= tion to these things are unlikely to pay attention to these proposed report= s anyways.

Michael Hammer
--0000000000007dbdeb05b240e1af-- From nobody Thu Oct 22 05:12:47 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 062473A0AC5; Thu, 22 Oct 2020 05:12: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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=emersion.fr 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 y6Rj--pCsucG; Thu, 22 Oct 2020 05:12:42 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 A33E03A0AC3; Thu, 22 Oct 2020 05:12:42 -0700 (PDT) Date: Thu, 22 Oct 2020 12:12:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1603368759; bh=ruZZpKXq+5hnVN3tAHbzMo1ePlk1uVSSGprUJG81g18=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=hMmY9KIjJaGwh13zz7pInjxzgOF+mmRg5QWsFeN+wSLIIsuaNchYzVhTXguGhNDlw S0/QtbEtBh60RFcbo4BCn0TCIPVeoW25XdY9XG1q4tss0HmQkt6NZkJDctwHe7GL3Q KUn5Jurkb0s9idNxsSIzb9s9r5OAC+bRFLg+GWJc1kUvf1o4ob7XXv7YKnCccBzd+K qaqKa9+k5sFu2cacT48qJ8JVTFavOC09pgVmlULqitWAaZbImyv5Abw4gnE9GGxihp t9qIHigjOtshf86oarzs21tWvMmS+Gh5Cwvqomen3abNdKE8krCnJuhSubkKYIlaTw g3hpxr7nt2DHw== To: "ietf-822@ietf.org" From: Simon Ser Cc: "dmarc@ietf.org" Reply-To: Simon Ser Message-ID: <1D0mNvhgL7vfSzrdCLrTIFkAk7ulKhb6vw3yQiKdVjP2dxJqF4OZiEzUSsPLhXjiLE3n5NyO9mCP-uVdfyR6FyVQvEsUeoAmGcM4Qj46uR4=@emersion.fr> In-Reply-To: <20201020012421.4A46623B1365@ary.qy> References: <20201020012421.4A46623B1365@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 12:12:45 -0000 Thanks for your reply. On Tuesday, October 20, 2020 3:24 AM, John Levine wrote: > [ Replies sent to ietf-822 since this is unrelated to DMARC ] (Sorry, I wasn't sure where to send this e-mail to.) > In article ZxWD3Yo-oiRI8Rq8k9H-7vG3Rgogp5lhNRwW3JcDUpFjHlfxgubW8rC5g4jQKW= nhFazItAexGXsB4xMb69mZg2jRtuXEC7l1GxfmqdBbCOU=3D@emersion.fr you write: > > > I've submitted a draft for a new Authentication-Results method a while > > back 1. I'd like to get some feedback. > > My use-case is: on a mailing list system 2, I'd like to display PGP > > signature status, if a PGP signature is present. ... > > > > > > Does this sounds like something worth doing? > > Maybe, but probably not. > > DKIM is intended as a signature for messages in transit, applied as a > message leaves its sending system and verified as it arrives at the > recipient system. The sorts of changs made by list managers often > break DKIM signatures, causing all sorts of excitement when DMARC > is involved. > > PGP signatures (and S/MIME signatures) are normally applied and > verified by the end-user mail programs. They're in the message body > and the changes that list managers typically make, tagging the > signature or adding body headers or footers, are unlikely to break a > PGP signature. I can think of ways a ML can change a PGP-signed message to make it invalid. Adding a footer to all inline text parts for instance. > Or to put it another way, if your A-R header said the PGP signature on > the message contents was good, but the end user found it was bad, that > would suggest something was screwed up, not normal mailing list > processing. I don't think I understand your point here. I don't expect the A-R header of the mailing list server which relayed the message to be preserved. In fact, many mail filters adding A-R will just remove all existing A-R header fields. In an email client, I may want to display the DKIM A-R result in the UI. A bad DKIM signature might indicate an untrustworthy message. Similarly, I may want to display the PGP signature verification result. > PS: It's not unreasonble for a list manager to use a PGP signature to > verify that it should forward a message, but there's not much use to > adding a header saying it did so. (My goal isn't to necessarily block messages with a bad PGP signature, but rather display the PGP verification result in the mailing list archives UI.) Well, what's the use-case for A-R then? Couldn't the receiving server check DKIM/DMARC without adding an A-R field and drop/quarantine messages which fail this test? My understanding was that A-R allows to have standardized email filters that check DKIM/DMARC, put the result in a header field, and then system administrators can consume this field and decide what to do. I think this could apply to PGP as well. I don't want to perform PGP key lookup and verification in the Web server displaying the ML archives. I'd rather do this upon receiving the message, in a completely isolated daemon (just like DKIM, e.g. with OpenDKIM). Thanks, Simon From nobody Thu Oct 22 05:15:18 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 E760C3A0AD3 for ; Thu, 22 Oct 2020 05:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=emersion.fr 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 K6ifdrDJm1b1 for ; Thu, 22 Oct 2020 05:15:13 -0700 (PDT) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (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 4FD173A0ADC for ; Thu, 22 Oct 2020 05:15:13 -0700 (PDT) Date: Thu, 22 Oct 2020 12:15:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1603368911; bh=YQDnT5pCjJbwyY5XFNAYCJlfOHXJrBdgkyC5UBUvpIU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=dgdoQPcEy09m/e8YsvZeHuLGiNfvJNBI1y6u+vNnrCkc3aUeJCN3JiBXOhTKDJCno bfuJHrvYBG250zpFPbHf6Y+x4xm3vaf8Zu7Qxt9IOxjVJwFe3ZsA/2NPrhrafJHIU8 vm/kM+gXe2Xrng6U36OLa+O6lqeYRhiVHiAODzwBeabVCQjjpJkzEjKb+ReRBrzehc av+IWuS/RwjmX6bDA1fu9W1imIh4TKolcQmSd+Z/I+I9gsD/b2WruNvInOOfHCTnzP 0otZtugvmtXtvdZx7kyjqy1/tiuMwkmczuLfAe98s7v7gA5E9pfSHi44OtrUprZzBe w4s0Ed3nRZsWQ== To: "Murray S. Kucherawy" From: Simon Ser Cc: "dmarc@ietf.org" Reply-To: Simon Ser Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 12:15:16 -0000 On Thursday, October 22, 2020 9:51 AM, Murray S. Kucherawy wrote: > On Mon, Oct 19, 2020 at 2:49 PM Simon Ser wrote: > > > I've submitted a draft for a new Authentication-Results method a while > > back [1]. I'd like to get some feedback. > > > > My use-case is: on a mailing list system [2], I'd like to display PGP > > signature status, if a PGP signature is present. I'd like the > > verification to happen once in a mail filter. Having a standardized > > Authentication-Results method that mail filters can generate and mail > > user agents can display would be helpful. A very similar thing is > > already implemented for DKIM. > > > > Does this sounds like something worth doing? > > Your references to RFC 7601 should change to RFC 8601. Good catch! > Are there any existing implementations of MTAs that generate this, and MU= As that consume it? No, I wanted to try to standardize this before writing software that depends on it. If you think software should come first, I could start using an x- token or something. From nobody Thu Oct 22 07:25: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 377E63A0EB5 for ; Thu, 22 Oct 2020 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix8DpDzoP9yY for ; Thu, 22 Oct 2020 07:25:00 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 E845E3A0DD1 for ; Thu, 22 Oct 2020 07:24:59 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id m195so411823vkh.11 for ; Thu, 22 Oct 2020 07:24:59 -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=gdWHS18zCKz3ph74Bf+07hdQ+bfO2ttOnjE1LA2+68w=; b=vI5CfWRSGsN1qqcsS7h53hS5EvQAGfOtUqINrj6YLArNh9aC6vsvJNbV7dYqQFNHet CBEdDehggs35lCQ5Y/fcG0YrdAKmcw6P8PCnwK3UGKJ0TpUpf0nPmCNM4o29COHmAmvm /C6PqZ9FIfSUO71yDBMmWeZdZpb3H1yQjeNmAnJocgm71tm0LpSKiwBtqCHHKHH6o3Uz RwFovdMw8MjSU4a3JQ3I17O8fO2tapNv8h3dxbAgxsHzupDUQ4SuJBxViPqO+LDli+QE cWIkZCfE94c8mms9PNtRrkcfpl7Z16urZ36td03nBgpgUUpA6xCAkBztr7/8QZBKIaEQ zc8A== 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=gdWHS18zCKz3ph74Bf+07hdQ+bfO2ttOnjE1LA2+68w=; b=izHNwN8qteMHTfdtASM0FZoQsgVsZp15L0dAl+flU1vlg9c1eA18+v6vmbBVbamMn8 ZfX18S8eFwhgRZNORoxAj3OMeSy6gwcKZOZcr2uv4wX8xKS5kMJKXPnQ+hY79y/Z7apG mrdSd9yA0NXjI9ubC3B3pRKj55XiO/VRHojNBa1zzz+BqtFB8x8xIrudj1DW4/m2ujpY dnDmpAQbO5Fsd4LoTSFMbHDOAwe7r0R/qsd24+fqLXB2w7/UuM4qiDH2LABRzOBT/wKA KoYpiRWq3KVMbpXZopxwyvBjCXBWMKtcTP+r86u2PNqJb0Yjb66lnxKR7eGS5fxXkEx0 /WQQ== X-Gm-Message-State: AOAM532hn/ppGLezakFYqYqafpG/q/cyoBSzfyYyqRNJ+6TXZez3sQ9w WnnfIQUN9w0+mxSGYyBeESsJXUtmdr/TbWcPzAiCoFKOewo= X-Google-Smtp-Source: ABdhPJyAsA6f3FMJse1D6aMlIlPixfz+gY2QywMjypCb5azY8XqzbGPxCQRQ3C0/TMyvVywiqxxuQXgcUmvQ7Tm4ttQ= X-Received: by 2002:a1f:36cb:: with SMTP id d194mr1759548vka.5.1603376698773; Thu, 22 Oct 2020 07:24:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 22 Oct 2020 07:24:47 -0700 Message-ID: To: Simon Ser Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000092571205b2433aef" Archived-At: Subject: Re: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 14:25:01 -0000 --00000000000092571205b2433aef Content-Type: text/plain; charset="UTF-8" On Thu, Oct 22, 2020 at 5:15 AM Simon Ser wrote: > > Are there any existing implementations of MTAs that generate this, and > MUAs that consume it? > > No, I wanted to try to standardize this before writing software that > depends on it. If you think software should come first, I could start > using an x- token or something. > It's not mandatory, but it helps to make the case that this should go forward. -MSK --00000000000092571205b2433aef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 22, 2020 at 5:15 AM Simon Ser= <contact@emersion.fr> wro= te:
> Are there any existing implementations of MTAs that gen= erate this, and MUAs that consume it?

No, I wanted to try to standardize this before writing software that
depends on it. If you think software should come first, I could start
using an x- token or something.

It'= s not mandatory, but it helps to make the case that this should go forward.=

-MSK
--00000000000092571205b2433aef-- From nobody Thu Oct 22 08:22: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 D10813A1047 for ; Thu, 22 Oct 2020 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=Bw0xk8Ow; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=RCYS9PZ9 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 UVEQgMhr-UHm for ; Thu, 22 Oct 2020 08:22:36 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D823A10BC for ; Thu, 22 Oct 2020 08:22:36 -0700 (PDT) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09MF5MJl007955; Thu, 22 Oct 2020 11:22:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=/3/1o7juoXtE4QhYfVPZKVPLsWvUpZvJgB9VSEe5X2g=; b=Bw0xk8OwapbU9dHlytTXFwDQXUMqDtnad+SroWWuEPdWJcy3Xjg2DaTdEhoxhujN0kEp fgPk1Hh28ZqGCaRBREQ17ciWkoCnekYkYm64hFWIGjhwmLfjzUTBoIXbNVWBG/a3YZcP /V+0caMwdS7H3j06mAwuOtJTO/I+T0lSH0LN35YciKkoLlHQlFvlewAfWJaFYGvBkdcb /s4wXFBrFtvPwtK3biaOP9D/DfKgjlrRWf1e7hSNBcI2FJCTSYECarYDtnxnGr7oBTHN tPtdn8hXYdPY4rmt/tOeao2dNUTMgEoh5GPvUN3wFHJLukJHswzKE+DqVYV/Zv5QJsRg 5Q== Received: from pacdcex56.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 347wakq9rs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 11:22:35 -0400 Received: from PACDCEX09.cable.comcast.com (24.40.1.132) by PACDCEX56.cable.comcast.com (24.40.2.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Oct 2020 11:22:33 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX09.cable.comcast.com (24.40.1.132) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 22 Oct 2020 11:22:33 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 22 Oct 2020 11:22:24 -0400 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4552.namprd11.prod.outlook.com (2603:10b6:208:263::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Thu, 22 Oct 2020 15:22:23 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3477.028; Thu, 22 Oct 2020 15:22:23 +0000 From: "Brotman, Alex" To: Dotzero CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Thoughts on "Senders DMARC" Reports Thread-Index: AdaiVc1hNC32VOspTmuLojW6xIuQgAGEdAGAAAfEk1A= Date: Thu, 22 Oct 2020 15:22:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:1450:61f2:6dd:407f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e4c29657-980e-4e14-33ec-08d8769e46c8 x-ms-traffictypediagnostic: MN2PR11MB4552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 23HXHaxemw+1GntC3zYyWv0a5BzQSQa8MESety9LyEFJa9ZwKSUR5SwDbUa1tdxNbPSrrKARja/KTWYkRd8aJhNlyCXWaj2TqWvj4EfngHL9Q4FM5TQ+Q+Jc2AJ4BhkR7mKtcdBBZ5mw+9e8AHle6law5EXjTmxk7Kh0+jBO7Vao+oYjjObf79To8ofZDSQZEjTn7J66Yg3EFntczTdDdSagYf37hBSpj8IOE88ADQlFV6O3w0bqkXYjzpZ6euTY0xC8QoZkSDvhv/HWBe2XRbzH14nThry7g+VnmGOpWH+RW6UobbvkwW9BEE3p8qjXmJ80Fn9em6wxpIaikKQkPjvrCwlRP43437Ye/ydK4UjPRG//aRSnBBJUPV7AOWB53nLDqcbndEH+D//EzNp57XBj2pqDU1SjISzwIZG9wCQr8umWNx2eV6AAnL8UKjUs9aqoh/bEN5kyNrT6ZQIiSA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(39860400002)(136003)(396003)(71200400001)(66946007)(83380400001)(64756008)(55016002)(86362001)(8676002)(66476007)(76116006)(66556008)(8936002)(52536014)(9686003)(4326008)(5660300002)(316002)(478600001)(33656002)(66446008)(2906002)(186003)(166002)(53546011)(6506007)(7696005)(6916009)(13220200004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TGaEBPNAhQjjALDJfl1yUXLhZq0aqrKvh2ZvR0H30QyxZ3Xy16nQEiZNTt9y23aIJgMpwxVkEvHvPalnFPmKOMtH4tA9QwJWmmw2qu/aBeYSd+cdkNbncjouu6fdTeRWPePQchVSoeacBs6MfZf6tvjOGXyrBldkCI10TR/UYMoz8Z8YTHvrWAL8Piqxopia2c11+2M8B+GAlowwzYrwXUT3kaNBY9kIb3K2Nx9gfyU4W3cvvwC9VQ2mJBsNCSKigDBNOz3vuOHQE+3fz0PLImUEZbulBOoSgK/BENDOcQGKdGISdN3ibUSoRFfKi9i2PtmzRkQNm+pWbOhWk0JMVvw/xQqL7LuymiEZ3/tqBVcJwX5KzWWJpzhVFNIJpzsIGq67Kjgx+tyw6GUo4WfhiE0NZoiWTHwHuAmdy8JhGsFMoiGaUERsuFOgzxl5VLJXdfPojuSnfcivqaBcmyRlS0AmDbbvTA9iy30dyHuJ9N/dK4PiDWRgelEg4gc2T2+DRFKS5QjoaEn773hWZz8Hg0YI7U9cyPeZvwt3k+eKNfnDyrI9tb5EVQ8DW5iaYpazasCz68/nQybobQt3VYf2W92F6KBS+ohNS9VUZ3qSk/ng+k9d25R2dO8ofgI4B9lc2Hwjsel34+l9A7HNBA+jiTc9f3QegwjiUqu3KZPQALPDxQEmPFnMD+cZsQT6XaB1bL5sOwCOHRs6dEa0oWh3DQ== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dE4GLFcqCKj7wMHDhP1OnUyeGVB2YwbPssfwhqeYE5il4sG2xd/HZbhBlN2GbjtQnbMXBB/IR8vAkRZfhGVzj2qQ3a7c/oZYuekaG95nBLiSXBx05DCJctFBaJRsW0xX7iEmJNzmf7xOUGElMWgadWspMGcxT8NKa7I4bBF/gqEmV4PRHSc3aNZ6rIiIqALO1tcSXziEScS9CZz8gbotGVQkioutg/o6+A47L9Hl00I68/CEKIu9oTMvCyASQKBIisFAv9XhifUtqm0XL9O9vtBTYuSsgth4DlilTd4hZmc6fLVP1i/DXAYM0simBL3ZOWaLZsLWHXZ6NI9RDB3Gtw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zU9B+IpGwoICF+avZNAFJOvVx5/ZHEt+eTRChHR9qGc=; b=Mg2OHJVAFlGEgw0WogcRSeCZ5QqJXSm9pZ4oXOcNW+ANircJ2ZENS2/qYJ1UKtP0Zl2gOZrR62pMEwb4pbNPcJCxx6YFCXipnxbYDdF5/MnZ5A69ZFSQOqfF7x81a1Aag7V92XffriAEufTvSvxXXH9tjXDzCbN3S21/L98KHHF9zXsEE3zCNK/4kMoHXoad5d+pHwQISwO5D+w65X85nCnaPMaOgME8jkZ2XHTJxOpQB+tN3GpfzPw/6fzfVwFG4cJd9y8XyOuTd0x2OFo32Dc8sP/kE+xouMZ91GbJdKtXryIy8dPt4HqYHtNDY+hQBR9oSniYuPANzYXBjo/NLg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zU9B+IpGwoICF+avZNAFJOvVx5/ZHEt+eTRChHR9qGc=; b=RCYS9PZ9UFCFClgYaRI0QpKwxlNyjJH9oYa+Qu5SiM629WTQ8bGC6OTAYhwmMv2L1ELBYW7S8WHjfez/qPgs1ngWADscJmmJ9sX5prG5VEfjAN0QbWUKWNpBtj/yrzhic53oAUp+Nc6baAXA2xl1Bu1tibv9luUhfYGGuls4VQs= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: e4c29657-980e-4e14-33ec-08d8769e46c8 x-ms-exchange-crosstenant-originalarrivaltime: 22 Oct 2020 15:22:23.5592 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 4KwHm4bLy1pNsyy/mKZEIp3V5Z1ufEMpurKTmSyu8lNo0mKZFwdwhX5yzftKmV7Wtgfo05BPEIlXq5e2Zhtx5iPCRmVfs7ovdXwWrq933LA= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4552 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB435126B9D45E690D6EBFB0E6F71D0MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-22_10:2020-10-20, 2020-10-22 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:22:40 -0000 --_000_MN2PR11MB435126B9D45E690D6EBFB0E6F71D0MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCi0tDQpBbGV4IEJyb3RtYW4NClNyLiBFbmdpbmVlciwgQW50aS1BYnVzZSAmIE1lc3NhZ2lu ZyBQb2xpY3kNCkNvbWNhc3QNCg0KRnJvbTogRG90emVybyA8ZG90emVyb0BnbWFpbC5jb20+DQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAyMCA3OjM3IEFNDQpUbzogQnJvdG1hbiwgQWxl eCA8QWxleF9Ccm90bWFuQGNvbWNhc3QuY29tPg0KQ2M6IGRtYXJjQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2RtYXJjLWlldGZdIFRob3VnaHRzIG9uICJTZW5kZXJzIERNQVJDIiBSZXBvcnRzDQoN Cg0KDQpPbiBXZWQsIE9jdCAxNCwgMjAyMCBhdCAyOjE3IFBNIEJyb3RtYW4sIEFsZXggPEFsZXhf QnJvdG1hbj00MGNvbWNhc3QuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNvbWNhc3QuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpEdXJpbmcgYSBzZXNzaW9uIGF0IE0zQUFXRzUwLCBv bmUgb2YgdGhlIG90aGVyIHBhcnRpY2lwYW50cyBwcm9wb3NlZCBhbiBpZGVhIHdoZXJlIGEgc2Vu ZGVyIGNvdWxkIG9wdGlvbmFsbHkgc2VuZCByZXBvcnRzIHRvIGEgZG9tYWluIGhvbGRlciB3aGVu IHRoZXkgc2VuZCBtZXNzYWdlcyBvbiBiZWhhbGYgb2YgdGhhdCBkb21haW4uDQoNCkxldCdzIGNv bnNpZGVyIHRoZSBpZGVhIHRoYXQgZXhhbXBsZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHA6L2V4YW1wbGUuY29tX187ISFDUWwzbWNIWDJBIVdScFBuSU5aeTFvQ2EtRHNkdVpZ MUstOHBWVFdqeHFSb1lIdXptRU10WnJUNjAxNy1Ma0EwZ3JsQnBFQ2RwWGdxXzJEJD4gaGFzIHBy b3Blcmx5IGNyZWF0ZWQgU1BGL0RLSU0vRE1BUkMgcmVwb3J0cyBmb3IgdGhlbXNlbHZlcywgYW5k IGFyZSBlbmZvcmNpbmcgYXQgcD1yZWplY3QuICBBbmQgZXhhbXBsZS5jb208aHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUuY29tX187ISFDUWwzbWNIWDJBIVdScFBuSU5a eTFvQ2EtRHNkdVpZMUstOHBWVFdqeHFSb1lIdXptRU10WnJUNjAxNy1Ma0EwZ3JsQnBFQ2RwWGdx XzJEJD4gaGFzIHBlcm1pdHRlZCBFU1AtQSB0byBkZWxpdmVyIG1lc3NhZ2VzIG9uIHRoZWlyIGJl aGFsZiwgYW5kIHRoZXkncmUgcHJvcGVybHkgc2V0dXAgaW4gdGhlIFNQRiwgYW5kIHByb3Blcmx5 IHNpZ24gd2l0aCBES0lNLiAgRVNQLUIgaGFzIG5vIHN1Y2ggYXV0aG9yaXphdGlvbiwgYnV0IHNv bWUgZW50aXR5IGhhcyBhc2tlZCB0aGF0IEVTUC1CIHNlbmQgbWVzc2FnZXMgb24gYmVoYWxmIG9m IGV4YW1wbGUuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLmNv bV9fOyEhQ1FsM21jSFgyQSFXUnBQbklOWnkxb0NhLURzZHVaWTFLLThwVlRXanhxUm9ZSHV6bUVN dFpyVDYwMTctTGtBMGdybEJwRUNkcFhncV8yRCQ+LCBidXQgaXMgdGFyZ2V0aW5nIGEgbWFpbGJv eCBwcm92aWRlciB3aG8gZG9lcyBub3Qgc3VwcG9ydCBETUFSQywgbm9yIHNlbmQgcmVwb3J0cy4g IEJvdGggZW50aXRpZXMgcGFydGljaXBhdGUgaW4gdGhpcyAiU2VuZGVycyBETUFSQyIsIGFuZCBu b3cgZXhhbXBsZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L2V4YW1wbGUu Y29tX187ISFDUWwzbWNIWDJBIVdScFBuSU5aeTFvQ2EtRHNkdVpZMUstOHBWVFdqeHFSb1lIdXpt RU10WnJUNjAxNy1Ma0EwZ3JsQnBFQ2RwWGdxXzJEJD4ga25vd3MgdGhhdCBFU1AtQSBpcyBhY3Rp bmcgcHJvcGVybHksIHdoaWxlIEVTUC1CIG1heSBuZWVkIHNvbWUgY29udGFjdCB0byB1bmRlcnN0 YW5kIG1vcmUgYWJvdXQgd2hhdCBpcyBnb2luZyBvbi4gIEknZCBzdWdnZXN0IHRoYXQgdGhlIHBv bGljeSBiZSBzZXBhcmF0ZSBmcm9tIHRoZSByZWNlaXZpbmcgcG9saWN5ICgicD0iIGFuZCAicHM9 IiAocG9saWN5LXNlbmRlcnMpIGZvciBleGFtcGxlLCB0aG91Z2gsIHRoYXQgbWF5IGFsc28gbGVu ZCBpdHNlbGYgdG8gInBzcD0iKSwgYnV0IHJlc2lkaW5nIGluIHRoZSBzYW1lIEROUyBUWFQgcmVj b3JkLg0KDQpUaGlzIHdvdWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBidXQgYWxzbyBm b3IgTUJQcy9JU1BzIGFzIHdlbGwuDQoNCkRvZXMgdGhpcyBzb3VuZCBsaWtlIGEgcmVhc29uYWJs ZSBpZGVhPyAgUmVwb3J0IG92ZXJsb2FkPyAgTm90IGEgaGVscGZ1bCBkYXRhIHNldCBmb3IgYSBk b21haW4gaG9sZGVyPw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgdGltZS4NCg0KLS0NCkFsZXggQnJv dG1hbg0KU3IuIEVuZ2luZWVyLCBBbnRpLUFidXNlICYgTWVzc2FnaW5nIFBvbGljeQ0KQ29tY2Fz dA0KDQpJbiB0aGUgZXhhbXBsZSB5b3UgZ2l2ZSwgd291bGRuJ3QgRVNQIEIgYmUganVzdCBhIHdl ZSBiaXQgc3VzcGljaW91cyBhbmQgc2VlIEhVR0UgcmVkIGZsYWdzIHRoYXQgYSBub24tdmFsaWRh dGluZyByZWNlaXZlciBpcyB0YXJnZXRlZCBmb3IgbWFpbCBwdXJwb3J0aW5nIHRvIGJlIGZyb20g YSBkb21haW4gcHVibGlzaGluZyBwPXJlamVjdD8gSWYgdGhleSB3ZXJlIHVuc3VyZSBhbmQgY29u Y2VybmVkIGVub3VnaCB0byB3YW50IHRvIHNlbmQgcmVwb3J0cyB0aGVuIHdoeSB3b3VsZG4ndCB0 aGV5IGJlIGNvbmNlcm5lZCBlbm91Z2ggdG8gcmVhY2ggb3V0IHRvIHRoZSBkb21haW4gb3duZXIv YWRtaW5pc3RyYXRvciB3aXRob3V0IHN1Y2ggYSByZXBvcnQgc2NoZW1lPyBvciB0byByZWplY3Qg dGhlIGN1c3RvbWVyPyAoT2gsIGxlYXZpbmcgbW9uZXkgb24gdGhlIHRhYmxlLCB0aGUgaG9ycm9y ISkNCltCcm90bWFuLCBBbGV4YW5kZXJdDQoNClRoYXTigJlzIHB1dHRpbmcgdGhlIG9udXMgb24g dGhlIEVTUCBmb3IgdGhlIGFuYWx5c2lzLCBpbnN0ZWFkIG9mIHRoZSBwYXJ0eSB0aGF0IGhhcyBh IHZlc3RlZCBpbnRlcmVzdCwgdGhlIGRvbWFpbiBvd25lci4gIFRoZSByZXBvcnRzIHdvdWxkIGJl IGF1dG9tYXRlZCB0byB0aGUgZG9tYWluIGhvbGRlci4NCg0KRWl0aGVyIHRoZSBtYWlsc3RyZWFt IGludm9sdmVkIGlzIG1hbGljaW91cywgb3IgaXQgaXMgbm90LiBJZiBpdCdzIG1hbGljaW91cywg SSB3b3VsZCBleHBlY3QgKGFuZCBoYXZlIGV4cGVyaWVuY2VkKSByZXBvcnRzIGNvbWluZyBpbiBm cm9tIGVuZCB1c2VycyAocmVjaXBpZW50cykgdG8gY3VzdG9tZXIgc2VydmljZSwgYWJ1c2VALCBw b3N0bWFzdGVyQCwgZXRjLiB2ZXJ5IHF1aWNrbHkuIFRoaXMgd291bGQgdHlwaWNhbGx5IGJlIG11 Y2ggZmFzdGVyIHRoYW4gb25jZSBhIGRheSBhdXRvbWF0ZWQgcmVwb3J0cyBmcm9tIHRoZSBFU1As IGV0Yy4gSWYgaXQncyBub3QgbWFsaWNpb3VzLCB0aGUganVpY2UgbWF5IG5vdCBiZSB3b3J0aCB0 aGUgc3F1ZWV6ZS4NCkkgYmVsaWV2ZSAtIG5vLCBrbm93IC0gdGhhdCBkb21haW5zIHBheWluZyBh dHRlbnRpb24gdG8gZXhpc3RpbmcgcmVwb3J0cywgbG9ncywgaW5ib3VuZCBtYWlsIHRvIHJvbGUg YWNjb3VudHMsIGV0Yy4gaGF2ZSBubyBwcmVzc2luZyBuZWVkIGZvciBzb21ldGhpbmcgbGlrZSB0 aGlzLiBEb21haW5zIG5vdCBwYXlpbmcgYXR0ZW50aW9uIHRvIHRoZXNlIHRoaW5ncyBhcmUgdW5s aWtlbHkgdG8gcGF5IGF0dGVudGlvbiB0byB0aGVzZSBwcm9wb3NlZCByZXBvcnRzIGFueXdheXMu DQpbQnJvdG1hbiwgQWxleGFuZGVyXQ0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgYWdyZWUuICBJ dOKAmXMgcXVpdGUgcG9zc2libGUgdGhhdCB0aGUgcmVwb3J0cyBjb3VsZCBnbyB0byBhbiBhZ2dy ZWdhdG9yIHRoYXQgY291bGQgc2VuZCBhIHJlcG9ydCB3aXRoIGJpZyByZWQgZmxhZ3MuICBXaGlj aCBQb3N0bWFzdGVyIGdldHMgdGhlIHJlcG9ydHM/IFRoZSBkb21haW4gaG9sZGVyIG9yIHRoZSBF U1AsIG9yIGJvdGg/ICBZb3XigJlyZSByZWx5aW5nIG9uIHRoZSByZWNpcGllbnQgb2YgdGhlIChw b3RlbnRpYWxseSkgb2JqZWN0aW9uYWJsZSBtYXRlcmlhbCB0byBrbm93IHRoYXQgcG9zdG1hc3Rl ckAgZXZlbiBleGlzdHMuICBTcGFtIHJlcG9ydHMgYXJlIGdyZWF0IGFzIHdlbGwsIGJ1dCB0aGlz IG1heSBub3QgYmUgYSBjYXNlIG9mIGZyYXVkdWxlbnQgbWVzc2FnZXMsIGp1c3QgYSByb2d1ZSBt YXJrZXRpbmcgZGVwYXJ0bWVudC4NCg0KTWljaGFlbCBIYW1tZXINCg== --_000_MN2PR11MB435126B9D45E690D6EBFB0E6F71D0MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxleCBCcm90bWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Tci4gRW5naW5lZXIsIEFudGktQWJ1c2UgJmFtcDsgTWVzc2FnaW5nIFBvbGlj eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tY2FzdDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBEb3R6ZXJvICZsdDtkb3R6ZXJvQGdtYWlsLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIwIDc6Mzcg QU08YnI+DQo8Yj5Ubzo8L2I+IEJyb3RtYW4sIEFsZXggJmx0O0FsZXhfQnJvdG1hbkBjb21jYXN0 LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbZG1hcmMtaWV0Zl0gVGhvdWdodHMgb24gJnF1b3Q7U2VuZGVycyBETUFSQyZxdW90 OyBSZXBvcnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBPY3QgMTQsIDIwMjAgYXQgMjoxNyBQTSBCcm90bWFuLCBBbGV4ICZsdDtBbGV4 X0Jyb3RtYW49PGEgaHJlZj0ibWFpbHRvOjQwY29tY2FzdC5jb21AZG1hcmMuaWV0Zi5vcmciPjQw Y29tY2FzdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1cmluZyBhIHNlc3Np b24gYXQgTTNBQVdHNTAsIG9uZSBvZiB0aGUgb3RoZXIgcGFydGljaXBhbnRzIHByb3Bvc2VkIGFu IGlkZWEgd2hlcmUgYSBzZW5kZXIgY291bGQgb3B0aW9uYWxseSBzZW5kIHJlcG9ydHMgdG8gYSBk b21haW4gaG9sZGVyIHdoZW4gdGhleSBzZW5kIG1lc3NhZ2VzIG9uIGJlaGFsZiBvZiB0aGF0IGRv bWFpbi48YnI+DQo8YnI+DQpMZXQncyBjb25zaWRlciB0aGUgaWRlYSB0aGF0IDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLmNvbV9fOyEhQ1FsM21jSFgy QSFXUnBQbklOWnkxb0NhLURzZHVaWTFLLThwVlRXanhxUm9ZSHV6bUVNdFpyVDYwMTctTGtBMGdy bEJwRUNkcFhncV8yRCQiIHRhcmdldD0iX2JsYW5rIj4NCmV4YW1wbGUuY29tPC9hPiBoYXMgcHJv cGVybHkgY3JlYXRlZCBTUEYvREtJTS9ETUFSQyByZXBvcnRzIGZvciB0aGVtc2VsdmVzLCBhbmQg YXJlIGVuZm9yY2luZyBhdCBwPXJlamVjdC4mbmJzcDsgQW5kDQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cDovZXhhbXBsZS5jb21fXzshIUNRbDNtY0hYMkEhV1JwUG5J Tlp5MW9DYS1Ec2R1WlkxSy04cFZUV2p4cVJvWUh1em1FTXRaclQ2MDE3LUxrQTBncmxCcEVDZHBY Z3FfMkQkIiB0YXJnZXQ9Il9ibGFuayI+DQpleGFtcGxlLmNvbTwvYT4gaGFzIHBlcm1pdHRlZCBF U1AtQSB0byBkZWxpdmVyIG1lc3NhZ2VzIG9uIHRoZWlyIGJlaGFsZiwgYW5kIHRoZXkncmUgcHJv cGVybHkgc2V0dXAgaW4gdGhlIFNQRiwgYW5kIHByb3Blcmx5IHNpZ24gd2l0aCBES0lNLiZuYnNw OyBFU1AtQiBoYXMgbm8gc3VjaCBhdXRob3JpemF0aW9uLCBidXQgc29tZSBlbnRpdHkgaGFzIGFz a2VkIHRoYXQgRVNQLUIgc2VuZCBtZXNzYWdlcyBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLmNvbV9fOyEhQ1FsM21jSFgyQSFX UnBQbklOWnkxb0NhLURzZHVaWTFLLThwVlRXanhxUm9ZSHV6bUVNdFpyVDYwMTctTGtBMGdybEJw RUNkcFhncV8yRCQiIHRhcmdldD0iX2JsYW5rIj4NCmV4YW1wbGUuY29tPC9hPiwgYnV0IGlzIHRh cmdldGluZyBhIG1haWxib3ggcHJvdmlkZXIgd2hvIGRvZXMgbm90IHN1cHBvcnQgRE1BUkMsIG5v ciBzZW5kIHJlcG9ydHMuJm5ic3A7IEJvdGggZW50aXRpZXMgcGFydGljaXBhdGUgaW4gdGhpcyAm cXVvdDtTZW5kZXJzIERNQVJDJnF1b3Q7LCBhbmQgbm93DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cDovZXhhbXBsZS5jb21fXzshIUNRbDNtY0hYMkEhV1JwUG5JTlp5 MW9DYS1Ec2R1WlkxSy04cFZUV2p4cVJvWUh1em1FTXRaclQ2MDE3LUxrQTBncmxCcEVDZHBYZ3Ff MkQkIiB0YXJnZXQ9Il9ibGFuayI+DQpleGFtcGxlLmNvbTwvYT4ga25vd3MgdGhhdCBFU1AtQSBp cyBhY3RpbmcgcHJvcGVybHksIHdoaWxlIEVTUC1CIG1heSBuZWVkIHNvbWUgY29udGFjdCB0byB1 bmRlcnN0YW5kIG1vcmUgYWJvdXQgd2hhdCBpcyBnb2luZyBvbi4mbmJzcDsgSSdkIHN1Z2dlc3Qg dGhhdCB0aGUgcG9saWN5IGJlIHNlcGFyYXRlIGZyb20gdGhlIHJlY2VpdmluZyBwb2xpY3kgKCZx dW90O3A9JnF1b3Q7IGFuZCAmcXVvdDtwcz0mcXVvdDsgKHBvbGljeS1zZW5kZXJzKSBmb3IgZXhh bXBsZSwgdGhvdWdoLCB0aGF0IG1heQ0KIGFsc28gbGVuZCBpdHNlbGYgdG8gJnF1b3Q7cHNwPSZx dW90OyksIGJ1dCByZXNpZGluZyBpbiB0aGUgc2FtZSBETlMgVFhUIHJlY29yZC48YnI+DQo8YnI+ DQpUaGlzIHdvdWxkIG5vdCBiZSBtZWFudCBqdXN0IGZvciBFU1BzLCBidXQgYWxzbyBmb3IgTUJQ cy9JU1BzIGFzIHdlbGwuPGJyPg0KPGJyPg0KRG9lcyB0aGlzIHNvdW5kIGxpa2UgYSByZWFzb25h YmxlIGlkZWE/Jm5ic3A7IFJlcG9ydCBvdmVybG9hZD8mbmJzcDsgTm90IGEgaGVscGZ1bCBkYXRh IHNldCBmb3IgYSBkb21haW4gaG9sZGVyPzxicj4NCjxicj4NClRoYW5rIHlvdSBmb3IgeW91ciB0 aW1lLjxicj4NCjxicj4NCi0tPGJyPg0KQWxleCBCcm90bWFuPGJyPg0KU3IuIEVuZ2luZWVyLCBB bnRpLUFidXNlICZhbXA7IE1lc3NhZ2luZyBQb2xpY3k8YnI+DQpDb21jYXN0PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUg ZXhhbXBsZSB5b3UgZ2l2ZSwgd291bGRuJ3QgRVNQIEIgYmUganVzdCBhIHdlZSBiaXQgc3VzcGlj aW91cyBhbmQgc2VlIEhVR0UgcmVkIGZsYWdzIHRoYXQgYSBub24tdmFsaWRhdGluZyByZWNlaXZl ciBpcyB0YXJnZXRlZCBmb3IgbWFpbCBwdXJwb3J0aW5nIHRvIGJlIGZyb20gYSBkb21haW4gcHVi bGlzaGluZyBwPXJlamVjdD8gSWYgdGhleSB3ZXJlIHVuc3VyZSBhbmQgY29uY2VybmVkIGVub3Vn aA0KIHRvIHdhbnQgdG8gc2VuZCByZXBvcnRzIHRoZW4gd2h5IHdvdWxkbid0IHRoZXkgYmUgY29u Y2VybmVkIGVub3VnaCB0byByZWFjaCBvdXQgdG8gdGhlIGRvbWFpbiBvd25lci9hZG1pbmlzdHJh dG9yIHdpdGhvdXQgc3VjaCBhIHJlcG9ydCBzY2hlbWU/IG9yIHRvIHJlamVjdCB0aGUgY3VzdG9t ZXI/IChPaCwgbGVhdmluZyBtb25leSBvbiB0aGUgdGFibGUsIHRoZSBob3Jyb3IhKTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+W0Jyb3RtYW4sIEFsZXhhbmRlcl0g PG86cD48L286cD48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT5UaGF04oCZcyBwdXR0aW5nIHRoZSBvbnVzIG9uIHRoZSBFU1AgZm9yIHRoZSBh bmFseXNpcywgaW5zdGVhZCBvZiB0aGUgcGFydHkgdGhhdCBoYXMgYSB2ZXN0ZWQgaW50ZXJlc3Qs IHRoZSBkb21haW4gb3duZXIuJm5ic3A7IFRoZSByZXBvcnRzIHdvdWxkIGJlIGF1dG9tYXRlZCB0 byB0aGUgZG9tYWluIGhvbGRlci48bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkVpdGhlciB0aGUgbWFpbHN0 cmVhbSBpbnZvbHZlZCBpcyBtYWxpY2lvdXMsIG9yIGl0IGlzIG5vdC4gSWYgaXQncyBtYWxpY2lv dXMsIEkgd291bGQgZXhwZWN0IChhbmQgaGF2ZSBleHBlcmllbmNlZCkgcmVwb3J0cyBjb21pbmcg aW4gZnJvbSBlbmQgdXNlcnMgKHJlY2lwaWVudHMpIHRvIGN1c3RvbWVyIHNlcnZpY2UsIGFidXNl QCwgcG9zdG1hc3RlckAsIGV0Yy4NCiB2ZXJ5IHF1aWNrbHkuIFRoaXMgd291bGQgdHlwaWNhbGx5 IGJlIG11Y2ggZmFzdGVyIHRoYW4gb25jZSBhIGRheSBhdXRvbWF0ZWQgcmVwb3J0cyBmcm9tIHRo ZSBFU1AsIGV0Yy4gSWYgaXQncyBub3QgbWFsaWNpb3VzLCB0aGUganVpY2UgbWF5IG5vdCBiZSB3 b3J0aCB0aGUgc3F1ZWV6ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSAtIG5vLCBrbm93IC0gdGhhdCBkb21haW5zIHBheWluZyBh dHRlbnRpb24gdG8gZXhpc3RpbmcgcmVwb3J0cywgbG9ncywgaW5ib3VuZCBtYWlsIHRvIHJvbGUg YWNjb3VudHMsIGV0Yy4gaGF2ZSBubyBwcmVzc2luZyBuZWVkIGZvciBzb21ldGhpbmcgbGlrZSB0 aGlzLiBEb21haW5zIG5vdCBwYXlpbmcgYXR0ZW50aW9uIHRvIHRoZXNlIHRoaW5ncyBhcmUgdW5s aWtlbHkgdG8gcGF5IGF0dGVudGlvbg0KIHRvIHRoZXNlIHByb3Bvc2VkIHJlcG9ydHMgYW55d2F5 cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltCcm90bWFuLCBB bGV4YW5kZXJdIDxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+SSBkb27igJl0IG5lY2Vzc2FyaWx5IGFncmVlLiZuYnNwOyBJdOKAmXMgcXVpdGUgcG9z c2libGUgdGhhdCB0aGUgcmVwb3J0cyBjb3VsZCBnbyB0byBhbiBhZ2dyZWdhdG9yIHRoYXQgY291 bGQgc2VuZCBhIHJlcG9ydCB3aXRoIGJpZyByZWQgZmxhZ3MuJm5ic3A7IFdoaWNoIFBvc3RtYXN0 ZXIgZ2V0cyB0aGUgcmVwb3J0cz8gVGhlIGRvbWFpbiBob2xkZXIgb3IgdGhlIEVTUCwgb3IgYm90 aD8mbmJzcDsgWW914oCZcmUgcmVseWluZyBvbg0KIHRoZSByZWNpcGllbnQgb2YgdGhlIChwb3Rl bnRpYWxseSkgb2JqZWN0aW9uYWJsZSBtYXRlcmlhbCB0byBrbm93IHRoYXQgcG9zdG1hc3RlckAg ZXZlbiBleGlzdHMuJm5ic3A7IFNwYW0gcmVwb3J0cyBhcmUgZ3JlYXQgYXMgd2VsbCwgYnV0IHRo aXMgbWF5IG5vdCBiZSBhIGNhc2Ugb2YgZnJhdWR1bGVudCBtZXNzYWdlcywganVzdCBhIHJvZ3Vl IG1hcmtldGluZyBkZXBhcnRtZW50LjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWwgSGFtbWVyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_MN2PR11MB435126B9D45E690D6EBFB0E6F71D0MN2PR11MB4351namp_-- From nobody Fri Oct 23 14:20:27 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 5D2933A13F0; Fri, 23 Oct 2020 14:16:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmarc@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348778036.5087.10385742180673159700@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:20 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 109 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:16:24 -0000 Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (2:00 requested) Wednesday, 18 November 2020, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/dmarc.ics Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Tim Wicinski Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 76 Conflicts to Avoid: Chair Conflict: dnsop dprive cfrg kitten emailcore Technology Overlap: saag uta extra jmap cbor People who must be present: Alexey Melnikov Murray Kucherawy Tim Wicinski Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 25 03:00: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 494613A0916 for ; Sun, 25 Oct 2020 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suzpj5M4OGHc for ; Sun, 25 Oct 2020 03:00:07 -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 E15FA3A156B for ; Sun, 25 Oct 2020 03:00:06 -0700 (PDT) Received: (qmail 41634 invoked by uid 100); 25 Oct 2020 10:00:06 -0000 Date: 25 Oct 2020 09:59:42 -0000 Message-ID: <20201025095942.41624.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Oct 25 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 10:00:08 -0000 Count | Bytes | Who ------------+----------------+------- 4 (28.6%) | 83728 (58.4%) | Brotman, Alex 3 (21.4%) | 14615 (10.2%) | Simon Ser 2 (14.3%) | 12832 ( 9.0%) | Murray S. Kucherawy 2 (14.3%) | 8763 ( 6.1%) | John Levine 1 ( 7.1%) | 10823 ( 7.6%) | Dotzero 1 ( 7.1%) | 9912 ( 6.9%) | Jesse Thompson 1 ( 7.1%) | 2607 ( 1.8%) | "IETF Secretariat" From nobody Mon Oct 26 14:59: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 552423A0FF7; Mon, 26 Oct 2020 14:59:04 -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 t5V5iRLcI5h4; Mon, 26 Oct 2020 14:59:02 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0: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 D80DD3A0FF6; Mon, 26 Oct 2020 14:59:02 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id f37so9396085otf.12; Mon, 26 Oct 2020 14:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6vhXHaDLrGQ87CSOnntZYbmfiOs0jmAIlrXNIl9KQUk=; b=ZKgWppvkxZMOi2GdMJ4ZLW88jGhlN5ZCaETnxpi7X2EbjaGKOKgFiKbhnN6hfBoykf 0STeWFqJnCDppp6+WdUWBEooh5YI9MNlH+cA3zHzt2jeTb0oW3QzaLMj5Hcj6uGnq2An IGow+GohBtDV46aLI5Ep/WRBk6dqAeRzT5SGPVovPXBPs0/jp9uhKwiPFYGyy+o3/gYs gD1p+zS52pTMbEmzRwjqpo/O8wtbendxAcphm+j6MlbZ6Yih+tPLi5pI8xZ+7q7f0WxM YnXba8gCodCaJz7aTMsZ7wHuI+qivTGr9bVpaTjaElc8zE3QSsbTcwTa3nTTNKCZpoGN sB6w== 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:cc; bh=6vhXHaDLrGQ87CSOnntZYbmfiOs0jmAIlrXNIl9KQUk=; b=FG2W+eq3CeknxqjIr4MgcBUmpb/h3XCj+zNjMHh1U/u6VGRRqddVMFhWr7X5inOdZH dZb1kKlbvrGIQUb+J2JF8+23u89DqGR5oxCUXgq0eGxT/AzDNdbTbITeY7ETkyudLEIG drA2meUJUtf7gL6edhkywg7fyuE5V0qOr7mqAkI47dDQnlpNWIINnUzeGsz8rLsaRdZz z+FzdqCDyC3TxxVDOlggdatfnx7U1LlqKK+bFfsIYHBmrREeWbmT38O3KrJ8jPLXeac8 /zqjwISDiPLmMNkHms/B8RaztFtA4sRkqJqLH5Uo/m8y1WTB2Q5yjZ9V/LqHye4Ev4w4 7Lcg== X-Gm-Message-State: AOAM531sWo85E5qtLVeT1XOTGhJ7ZZMBhpUJSH60EwfWR6IIEMbycd0R opVww4W00brf39uktxxUEizXlaop7RbagxB1jUxNXNw0cM6VWQ== X-Google-Smtp-Source: ABdhPJzSvNZXohsKLGL5ek4hNDOzecTAbfUs2GL1e+1baf5FKneP2W5BeCMAcvQnYKNHxiLg09gGBAEDXfjvICGrD2M= X-Received: by 2002:a9d:5910:: with SMTP id t16mr17236510oth.155.1603749541988; Mon, 26 Oct 2020 14:59:01 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Mon, 26 Oct 2020 17:58:50 -0400 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c24bed05b29a09d9" Archived-At: Subject: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis 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, 26 Oct 2020 21:59:04 -0000 --000000000000c24bed05b29a09d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All While the chairs are aware that working on DMARC-bis is the charter of the working group, we want to ensure the process is followed. This starts a Call for Adoption for: DMARC-bis We'll be starting with the text from the RFC 7489. This is available here: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ Changes made so far have been to include the current Errata. Please review this draft, and we are looking for *objections to adoption*, and send comments to the list stating your objections. The working group can pick over the document after adoption. Also, the Chairs have announced that the document will be split into multiple pieces. The details around this split will be sent out shortly in a separate email. Since this bis project is the group=E2=80=99s currently chartered phase of = work, the chairs believe one week is sufficient time for objections. This call for adoption ends: November 2nd, 2020, at 5pm PST. Thanks, tim (for Alexey/Seth) --000000000000c24bed05b29a09d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All

While the chairs are aware that working on DMARC-bis is t= he charter of the working group, we want to ensure the process is followed.= =C2=A0

This starts a Call for Adoption for: DMARC-bis

We= 9;ll be starting with the text from the RFC 7489.
This is available her= e: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/
Changes made so far have been to include the current Errata.=C2=A0
Please review this draft, and we are looking for *objections to adopti= on*, and send comments to the list stating your objections.=C2=A0 The worki= ng group can pick over the document after adoption.

Also, the Chair= s have announced that the document will be split into multiple pieces. The = details around this split will be sent out shortly in a separate email.
=
Since this bis project is the group=E2=80=99s currently chartered phase= of work, the chairs believe one week is sufficient time for objections. Th= is call for adoption ends: November 2nd, 2020, at 5pm PST.

Thanks,

tim
<= div class=3D"gmail_default" style=3D"font-family:monospace">(for Alexey/Set= h)
--000000000000c24bed05b29a09d9-- From nobody Mon Oct 26 17:33:46 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 4F38C3A111E for ; Mon, 26 Oct 2020 17:33:44 -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 a5_NgQlDSX4G for ; Mon, 26 Oct 2020 17:33:42 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 9E6813A11CA for ; Mon, 26 Oct 2020 17:33:24 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h21so13197591iob.10 for ; Mon, 26 Oct 2020 17:33:24 -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=GZjtcP3xBSRVUa5utIsOuF9wnm/uw7Fzg1eKamE4Sok=; b=EpkmHxBGDp7aGuSFjNeXRsxZ0MP6tKdWWHIBD1oQHCKqw5zPquss67spndGFyz8ZNW wa8fk4P9fCK+MjRjbVZw/YBx4MnCfjRZcEYfBE4dUSMRmVpxNGS6PKBty3L7/xuUWt73 74AiTo2IJ88p1UOjzE7AeOfeFiu75BCoo/6Uk= 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=GZjtcP3xBSRVUa5utIsOuF9wnm/uw7Fzg1eKamE4Sok=; b=YKiNINcJEUPmhSGDfOpHoZmU0aqSVaAHgwQDSt+WVrVchzUe9pLYMyXdN1yQHJ0j1h 9rQYiEisjGQAHiGksut/A5Vuvwhg4fWkklwNoZA09HzpPPF7LwifgE5Ku85NWRdJG71z 1Bk3THzksDmPcBNB7Mcyh3nqkwyplS0M36gbMP6zK53cPcF+205XN7/tJmJ6KSR9vFIV RE2dDPm1RIEV1O9+Njs0i+51hisDW4KgFcV4RFoS78A3uS5Bd/LCwlGYSjjCKEmrxfFC T1tk+ofTMEVqMQa8YlBXKkvPI8fhPr3RkoagzfXzSbOuSk1hk2hK/D1/4z3tkbIRGnxF hb5g== X-Gm-Message-State: AOAM5325H1MKB142HvCui7cSOgKPTi9QjZnRGa1uHATlDsQ/5sO3OPcv nTY++R+JEO3up4JuyqeYiAdKCOApD7UgwcmpVO42lA== X-Google-Smtp-Source: ABdhPJwKqjFBH7boBRVExt/m7fEQDZxkDvTrBsjklHn/rcpiF7i+fmzilIOLTTwwGZMg7mUkaYEwy/R6IqVyqJQJMMk= X-Received: by 2002:a5d:9513:: with SMTP id d19mr12588898iom.29.1603758803773; Mon, 26 Oct 2020 17:33:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 26 Oct 2020 17:33:04 -0700 Message-ID: To: Tim Wicinski Cc: IETF DMARC WG , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce03da05b29c3101" Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis 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, 27 Oct 2020 00:33:44 -0000 --000000000000ce03da05b29c3101 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 26, 2020 at 2:59 PM Tim Wicinski wrote: > > This starts a Call for Adoption for: DMARC-bis > > We'll be starting with the text from the RFC 7489. > This is available here: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ > > Changes made so far have been to include the current Errata. > > Please review this draft, and we are looking for *objections to adoption*, > and send comments to the list stating your objections. The working group > can pick over the document after adoption. > No objection to adopting this draft. --Kurt --000000000000ce03da05b29c3101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 26, 2020 at 2:59 PM Tim Wicin= ski <tjw.ietf@gmail.com> wr= ote:

T= his starts a Call for Adoption for: DMARC-bis

We'll be starting = with the text from the RFC 7489.
This is available here: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/<= br>
Changes made so far have been to include the current Errata.=C2=A0
Please review this draft, and we are looking for *objections to adopt= ion*, and send comments to the list stating your objections.=C2=A0 The work= ing group can pick over the document after adoption.

No objection to adopting this draft.
<= br>
--Kurt=C2=A0
--000000000000ce03da05b29c3101-- From nobody Tue Oct 27 00:52: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 1AA7D3A1620 for ; Tue, 27 Oct 2020 00:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 s2Yj9B9P_yQJ for ; Tue, 27 Oct 2020 00:52:27 -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 171683A1623 for ; Tue, 27 Oct 2020 00:52:26 -0700 (PDT) Received: from shiny.crash.com (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 09R7qEhT001095 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 27 Oct 2020 07:52:22 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 09R7qEhT001095 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1603785144; bh=bLAadzfIww2AesPQ2P6c5bZ1QTgISE0AaLwP09mbez0=; h=Subject:To:References:From:Date:In-Reply-To; b=OZVrQi8JlS516t955wcril5vqDyH/PEZZ0UmCS3RteseZ4zAZ2WlkO1cZ4T8hSeAy NKLuN4lqwMfABIaFhlTHYFZamFhnoU5ivR/ESheb/szdl14KldId3/6rxXkiRiK9OD 9HbwHe1ovI1J9RauZ9SL/gktbb0WeNrJ6+cZlTVtfEoSzR53R4oyzF4NHBuFXhzuWT 7eyApqY1uF0Z7jgdR+DZYty1yzg7kYQq1vbo7C4tIqOWOPfQg1lTuRKQ4GkU39AQZ4 6LmL+OGKFDncXRbpVzHl2Z1gRQHy+u3dZ0ThSAGHjejFXQAdclqNnPjMSRcZyM+TpA SstgLihQ8FTQg== 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 shiny.crash.com To: dmarc@ietf.org References: From: Steven M Jones Message-ID: <95757413-0a40-e5de-6f8a-0971b2f07573@crash.com> Date: Tue, 27 Oct 2020 00:52:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EB9C3A9E5B153F5DE2D12149" 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]); Tue, 27 Oct 2020 07:52:23 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis 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, 27 Oct 2020 07:52:28 -0000 This is a multi-part message in MIME format. --------------EB9C3A9E5B153F5DE2D12149 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/26/20 14:58, Tim Wicinski wrote: > > This starts a Call for Adoption for: DMARC-bis I support adoption of the DMARCbis draft as a working group document. (I realize you asked for objections, but you need some record of support to proceed, don't you?) --S. --------------EB9C3A9E5B153F5DE2D12149 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/26/20 14:58, Tim Wicinski wrote:

This starts a Call for Adoption for: DMARC-bis


I support adoption of the DMARCbis draft as a working group document.

(I realize you asked for objections, but you need some record of support to proceed, don't you?)

--S.


--------------EB9C3A9E5B153F5DE2D12149-- From nobody Tue Oct 27 01:17: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 19FC93A1633 for ; Tue, 27 Oct 2020 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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 BgJhvc_jl_hm for ; Tue, 27 Oct 2020 01:17:30 -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 E5AB73A1632 for ; Tue, 27 Oct 2020 01:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1603786645; bh=+Eh+Nxf4X+L67zzjC2ZBOv9+DfLc+XEbZPLHWY/HhCY=; l=815; h=To:References:From:Date:In-Reply-To; b=A3hdOVl77np9XFtLGn9XA8c2JVus6xvNWbkFYt+lZDvCsy/jUF/U/rDOS1sHx4GMp lk5LTCBEllb1O85imdsNc8DIc1vs6nXXUoA6a5yy7a9DP00JmysUK5/ZW0wMf3s5A3 ZSWND2DtS8AHtONY7cCLoEAHWBKhUnOFNbKxxDcWyQUirA2+FdeTkBSBCgaBb 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.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F97D795.00005593; Tue, 27 Oct 2020 09:17:25 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <3b1ee23c-cb27-1f0c-1abc-6bd6967d8b22@tana.it> Date: Tue, 27 Oct 2020 09:17:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis 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, 27 Oct 2020 08:17:31 -0000 On Mon 26/Oct/2020 22:58:50 +0100 Tim Wicinski wrote: > Please review this draft, and we are looking for *objections to adoption*, and > send comments to the list stating your objections.  The working group can pick > over the document after adoption. > > Also, the Chairs have announced that the document will be split into multiple > pieces. The details around this split will be sent out shortly in a separate email. I don't think there is going to be much use of the document after the split. Perhaps, it's more efficient to split the document first, so as to let the WG review documents which are more or less in their final shape. Adopting and discussing a document that is not going to be published as RFC seems rather tortuous. I'm not objecting, I'm just confused. Best Ale -- From nobody Tue Oct 27 09:29:45 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 85BAD3A1100 for ; Tue, 27 Oct 2020 09:29:43 -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 B-nh2-TUt-Q7 for ; Tue, 27 Oct 2020 09:29:41 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 709C23A10FF for ; Tue, 27 Oct 2020 09:29:41 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id k21so1444572wmi.1 for ; Tue, 27 Oct 2020 09:29:41 -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=cigtqYLcWpwguJsMg4cwA73nY6IMl0lt7E77VnrnZsg=; b=T8NSfWom8hZeyK6/1A7EnjFeJYtuOqGxPvC2MxGeYGs0cVKuc8JjG2q8iUQUT955yL GX0A1E2oQiO3O1hyZ7N9vZN3JaDyZYWYUGRHwKcVjYOZBMBPSK1nk1V99E3gJbjQwyxy 0Jpa1EhczJBZJIKiITVQ47Z/+WDZxYOvvo/O6xxogPkYdqMbEQXve0K1ZzqNAwMP3Z+E yRlSp49XWOuuU3nkKTe3UTvYwG8e+qY68Jt/v03ei6UTyuDnwwqmE+Lx1rpcBwi5iPZ2 RpJZ81BlGAwN9ThwnceVCcl+0tg4QhJkZIMywUZXyglQra1oK8WDwj4Y/T7dbDjKdgE9 sVWw== 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=cigtqYLcWpwguJsMg4cwA73nY6IMl0lt7E77VnrnZsg=; b=FuU61lzi4FTQz56PmGpjMHYXbyuWmsAUanSsOn0vMju0+ZIxXdqxjMgLnpdZqXu7JX MK2plLY3sRTLzHpTHgzMtZaiC8aBQTbsw7FjSkUHIN59SOlzS6864Y76xK8I+ibHN0A4 aZX0kXyCRDB5i8VtEwQUgfiBvx+iM9oz+JuJcB3dEg9LuPuoRl0KS2RvaH26mXFHoFkX x8jNzVhWY5Qk18lKsJjG6q+P70S4UcZTCGoIRs57s8RKrz+jqWoQJLBzC6exYRpbMfB0 5l3tWLMziJ8xwawq/b0f06EhrIsTF1XTefaRIZHpaoE99fxz6Vq9sFD+EAwAE4XKBwUw PRSQ== X-Gm-Message-State: AOAM531TKoWFHnW93MNJNw8Vz70BZ63gSlGq2mh2tGvQwGZBI22qLj5z JL0BqLPclSEFaaDzS0AXtWsmAAC9s5Bd2807l6Lalpo/K6UP2Q== X-Google-Smtp-Source: ABdhPJwUkRwWOEoTBElM5NJroM9AYAM62glX7wlvYFW3tiExcpoC0ElCQKrkcoJ6bFymXz9J0rwC5K4ntzLVwsg2Ud0= X-Received: by 2002:a1c:e4c1:: with SMTP id b184mr3555484wmh.73.1603816179259; Tue, 27 Oct 2020 09:29:39 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Tue, 27 Oct 2020 09:29:28 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a676c305b2a98d56" Archived-At: Subject: [dmarc-ietf] Announcing DMARCbis Editors 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, 27 Oct 2020 16:29:44 -0000 --000000000000a676c305b2a98d56 Content-Type: text/plain; charset="UTF-8" One of the primary activities of the WG to review and improve the base DMARC specification. As the chairs sat down and reviewed the issues raised by everyone in the issue tracker (https://trac.ietf.org/trac/dmarc/report/1), we felt it would be better to split RFC7489 into three documents. All this work will benefit from multiple document editors working on specific pieces and interacting with the WG. After an open call for volunteers, we selected individuals from the community with the idea of balancing bringing new document authors with those with experience with the IETF process. Assuming draft-kucherawy-dmarc-dmarcbis is adopted (see the adoption thread started by Tim), we will then split the draft into three documents scoped as follows, with the corresponding editors below. The drafts will live in GitHub, but all issues are to be managed via the IETF Trac tool. All issues will continue to be discussed and resolved on the mailing list. 1. Base Spec * Define terms and operational implications that are now better understood * Clean up confusing or remove unused tags * Address nits and errata * Clarify Organizational Domain lookups or remove definition from base spec * Incorporate ARC or something that deals with indirect mailflows Editors: - Emil Gustafsson, Google - Todd Herr, Valimail - John Levine 2. Aggregate reporting * Address reporting nits and clarifications * Provide for more flexible reporting * Handle ARC data in a structured manner Editors - Alex Brotman, Comcast 3. Failure reporting * Create a simplified failure report * Address privacy considerations Editors - Steve Jones, LinkedIn - Alessandro Vesely Thanks everyone, and join us in thanking our editors for volunteering, Seth, Tim, and Alexey, as Chairs -- *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. --000000000000a676c305b2a98d56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the primary activities of the WG to review and impr= ove the base DMARC specification. As the chairs =C2=A0sat down and reviewed= the issues raised by everyone in the issue tracker
(https://trac.ietf.org/trac/dmarc/report= /1), we felt it would be better to split RFC7489 into three
documen= ts. All this work will benefit from multiple document editors working on sp= ecific pieces and interacting with the WG. After an open call for volunteer= s, we selected individuals from the community with the idea of balancing br= inging new document authors with those with experience with the IETF proces= s.

Assuming draft-kucherawy-dmarc-dmarcbis is adopted (see the adop= tion thread started by Tim), we will then split the draft into three docume= nts scoped as follows, with the corresponding editors below.

The dra= fts will live in GitHub, but all issues are to be managed via the IETF Trac= tool. All issues will continue to be discussed and resolved on the mailing= list.

1. Base Spec

* Define terms and operational implicati= ons that are now better understood
* Clean up confusing or remove unused= tags
* Address nits and errata
* Clarify Organizational Domain looku= ps or remove definition from base spec
* Incorporate ARC or something th= at deals with indirect mailflows

Editors:
- Emil Gustafsson, Goog= le
- Todd Herr, Valimail
- John Levine

2. Aggregate reporting<= br>
* Address reporting nits and clarifications
* Provide for more fl= exible reporting
* Handle ARC data in a structured manner

Editors=
- Alex Brotman, Comcast

3. Failure reporting

* Create a s= implified failure report
* Address privacy considerations

Editors=
- Steve Jones, LinkedIn
- Alessandro Vesely

Thanks everyone, = and join us in thanking our editors for volunteering,

Seth, Tim, and= Alexey, as Chairs

--

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


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

--000000000000a676c305b2a98d56--