From nobody Wed Jul 1 04:34:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8933A0E79 for ; Wed, 1 Jul 2020 04:34:57 -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 1_fH5LdmOKqr for ; Wed, 1 Jul 2020 04:34:55 -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 2B9083A0E76 for ; Wed, 1 Jul 2020 04:34:55 -0700 (PDT) X-ASG-Debug-ID: 1593603293-11fa313a102b3ae0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Az4CFPPm3oiT0DLW (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 01 Jul 2020 07:34:53 -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=Cxr3SV/Fj+jZz7lYZ9RXZyzzbWfOnxLUAUQzZvWzTbQ=; b=OOzBlVDpT4d0AOs6AhfgvLecW80zZReMvq9yZavJMmpbJnZI8iGC6ZS5XRys+yRnG hZcWNY6g/zuHZt0801CSry2dBpI8uSVSvlRoIJtNd6ajBcDmGY7WQub4E2dIbOkd9 WSRLLNPTzZ934MWsC9VoI1SIdE0LZ0r52hC15+C1E= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Wed, 01 Jul 2020 11:34:45 GMT X-ASG-Orig-Subj: DMARC as an instance of a class Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=2f382217a6be48359de89b2758662732 X-Exim-Id: b4ac41a910db493ebfdd4e777449bc2c X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1593603293 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: 7645 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.82922 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Jul 2020 11:34:57 -0000 This is a multipart message in MIME format. --2f382217a6be48359de89b2758662732 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable DMARC either introduced or popularized the concept of filtering on the Mess= age From. Low-end gateways that lack DMARC support will typically do noth= ing with the Message From -- the header value does not appear in the messag= e logs and it cannot be used for filtering because it is not examined. Now that the concept has been established, spam defenses based on From filt= ering are a class, of which DMARC is only an instance. Recipient systems= might choose to: Enforce DMARC on a domain even if the domain has a DMARC policy with p=3Dno= ne or pct=3D0.Enforce DMARC-equivalent requirements on a domain that has no= DMARC policy at all.Block based on the TLD of the From addressBlock based = on Domain reputation lookups using the From address. This creates a difficult problem for the MLM which wants to use author as t= he From address. The recipient gateway does not know the universe of all = mailing list subscribers, and the list changes over time as members subscri= be and unsubscribe. The MLM does not know the universe of all domains blo= cked by the recipient gateway, and the list of blocked domains will change = over time as policies are modified. These limitations of knowledge will limit our options for solutions. I se= e four possible recipient configurations with specific implications for wha= t the MLM can do. 1. Recipient system does not block based on From address MLM options are unrestricted 2. Recipient system whitelists mailing list messages based on source server= identity MLM server must be reliably identifiable, typically using forward-confirmed= DNS name. From address is unrestricted. 3. Recipient system whitelists mailing list messages based on list identity MLM list id must be reliably identifiable, probably using a SPF lookup on t= he List-ID or a DKIM signature with identifier specified to the list rather= than the domain. From address is unrestricted. 4. Recipient system blocks on From address but is unwilling to whitelist (o= r not yet configured to do so) MLM needs to use its own Domain for the From address and for a verifiable D= KIM signature. Alternatively, IETF would need to provide a way to trick t= he recipient into accepting the message in violation of its configured poli= cy, which it should not do. More complicated solutions, like dual signatures, are alternatives for the = middle of the above list, but are not needed for the first configuration an= d are excluded from the last configuration because of the "not configured" = assumption. Filtering on From Address is itself an instance of a larger class: defenses= based on verified identifiers. An identifier is useful to the spammer if the identifier might case the inc= oming gateway to allow a message that would otherwise be blocked.An identif= ier is useful to the spammer if it will be displayed to the user by the MUA= , because then it can be used to perfect the spammer's social engineering a= ttacks. Because of these risks, SPF validation restricts unauthorized use of the RF= C 5321 Mail From, and DMARC validation limits the use of the RFC 5322 Messa= ge From. Going forward, we need to look for ways to validate any identifi= er that is used for either message filtering or message display. If we do = not, we should expect that some non-IETF source will do so instead. For the current issue, changing the roles of the Sender and From fields wil= l not be a long term solution unless the change includes validation of both= fields. The change by itself will attract spammers to whatever field rema= ins unvalidated. DF --2f382217a6be48359de89b2758662732 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
DMARC either intro= duced or popularized the concept of filtering on the Message From.   L= ow-end gateways that lack DMARC support will typically do nothing with the = Message From -- the header value does not appear in the message logs and it= cannot be used for filtering because it is not examined.

Now that the concept has been established, spam defenses based on F= rom filtering are a class, of which DMARC is only an instance.    = ;Recipient systems might choose to:
  • Enforce DMARC on a domain = even if the domain has a DMARC policy with p=3Dnone or pct=3D0.
  • Enf= orce DMARC-equivalent requirements on a domain that has no DMARC policy at = all.
  • Block based on the TLD of the From address
  • Block based= on Domain reputation lookups using the From address.
This cr= eates a difficult problem for the MLM which wants to use author as the From= address.   The recipient gateway does not know the universe of all ma= iling list subscribers, and the list changes over time as members subscribe= and unsubscribe.   The MLM does not know the universe of all domains = blocked by the recipient gateway, and the list of blocked domains will chan= ge over time as policies are modified.   

These limitations of knowledge will limit our options for solutions. &nbs= p; I see four possible recipient configurations with specific implications = for what the MLM can do.

1. Recipient system does = not block based on From address
  • MLM options are unrestricted
2. Recipient system whitelists mailing list messages based on = source server identity
  • MLM server must be reliably identifiabl= e, typically using forward-confirmed DNS name.  From address is unrest= ricted.
3. Recipient system whitelists mailing list messages = based on list identity
  • MLM list id must be reliably identifiab= le, probably using a SPF lookup on the List-ID or a DKIM signature with ide= ntifier specified to the list rather than the domain.  From address is= unrestricted.
4. Recipient system blocks on From address but= is unwilling to whitelist (or not yet configured to do so)
  • ML= M needs to use its own Domain for the From address and for a verifiable DKI= M signature.   Alternatively, IETF would need to provide a way to tric= k the recipient into accepting the message in violation of its configured p= olicy, which it should not do.
More complicated solutions, like dual signatures, are alternatives f= or the middle of the above list, but are not needed for the first configura= tion and are excluded from the last configuration because of the "not confi= gured" assumption.

Filtering on From Address is it= self an instance of a larger class: defenses based on verified identifiers.=
  • An identifier is useful to the spammer if the identifier migh= t case the incoming gateway to allow a message that would otherwise be bloc= ked.
  • An identifier is useful to the spammer if it will be displayed= to the user by the MUA, because then it can be used to perfect the spammer= 's social engineering attacks.
Because of these risks, SPF va= lidation restricts unauthorized use of the RFC 5321 Mail From, and DMARC va= lidation limits the use of the RFC 5322 Message From.   Going forward,= we need to look for ways to validate any identifier that is used for eithe= r message filtering or message display.  If we do not, we should expec= t that some non-IETF source will do so instead.

Fo= r the current issue, changing the roles of the Sender and From fields will = not be a long term solution unless the change includes validation of both f= ields.  The change by itself will attract spammers to whatever field r= emains unvalidated.

DF 

<= /div> --2f382217a6be48359de89b2758662732-- From nobody Wed Jul 1 16:51: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 4D9B73A11FE for ; Wed, 1 Jul 2020 16:51:31 -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 (1536-bit key) header.d=iecc.com header.b=XroAQ9JD; dkim=pass (1536-bit key) header.d=taugh.com header.b=IBJuB5Mp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWmCxfh6RJkh for ; Wed, 1 Jul 2020 16:51:29 -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 8F2753A1205 for ; Wed, 1 Jul 2020 16:51:29 -0700 (PDT) Received: (qmail 72204 invoked from network); 1 Jul 2020 23:51:27 -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=11a08.5efd217f.k2007; bh=rcLQCGFRAxbuypVeV7P3FrMQtgu+s5NoSuktqv49U7E=; b=XroAQ9JDety/KeM+I4y6KWC/Zu34RiNUCGS1tn3IGnbGPbHMYTBbNIrgVHKOktDguna0gxf3kF3Qw5Lm5Gjay3qo5Px5heGcWrTOol0XxX0CIewOI8WJU/VebaLOLVCrDZME9nZYvEYdznC1FX79jpjVYu5qxcjSOucJqJ3Iw3PcvnP9JDG/pbh9+u+W5drHYSMPIHVbDm/OPzRJhF60oMuKTyFmVPbj0kcab+mKFETp3sMnfZV72YXHny78YUAO 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=11a08.5efd217f.k2007; bh=rcLQCGFRAxbuypVeV7P3FrMQtgu+s5NoSuktqv49U7E=; b=IBJuB5MpNxA11mOTeHi837M+h2d6fZVIVAXaGMnPzYHwgfTHYDs7HqQZDPGzNAebH76LONX5+pX01by8R0TU3dGfInKhIyfucEcykb4kNMqtwaIvYV1eLaGAJHWqUHI4z9F2GFMKeShuiBv/xk0eKChd5c/WzLG15yEMBhAua3TNIHDIw8YVS10VN7lr/KlP1sE7wn3sz9raEQAifcPM07kGS5fm4IrolU/XTrN7WDCZFU/1G/VDwhQQ/WVCaTLs Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Jul 2020 23:51:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 2EBB21C3C828; Wed, 1 Jul 2020 19:51:27 -0400 (EDT) Date: 1 Jul 2020 19:51:27 -0400 Message-Id: <20200701235127.2EBB21C3C828@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Jul 2020 23:51:31 -0000 In article you write: >-=-=-=-=-=- > >DMARC either introduced or popularized the concept of filtering on the Message From. Low-end gateways >that lack DMARC support will typically do nothing with the Message From -- the header value does not >appear in the message logs and it cannot be used for filtering because it is not examined. Oh, please. Spam filters like spamassassin have looked at the headers along with everything else in the message forever. Given that the basis of your argument isn't true, I don't see any need to go point by point through the rest of it. R's, John From nobody Fri Jul 3 06:58:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920403A03F6 for ; Fri, 3 Jul 2020 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=hzvG7dOB; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=EjbjCTBj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDIHtAt61_dY for ; Fri, 3 Jul 2020 06:58:23 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522B23A0365 for ; Fri, 3 Jul 2020 06:58:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2365; t=1593784699; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=A8RDqnA7k7D7kji5J3/fI18Bwhw=; b=hzvG7dOByHJwe70TDpoU5kMPruLt+byMD356QrC1ls/TyaNYQxh0P++EUk//Um x92CV+uC704fqMvNvACT97+2BCRLo/gyV9cS/mJIcYLArJjJsoIj3BHb+unaB2ic LokxLAxRqYaMrTbLf/ACAzXgVwJ7lGJegzhs+WBiCE6w8= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 09:58:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 217017310.78.4652; Fri, 03 Jul 2020 09:58:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2365; t=1593784630; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=o2EtIyq 2Txe4lFSje6/hE6zIMiGkVpexfLBevOcsdqk=; b=EjbjCTBjRSKl59RVa0phMsp 2iiWEnukZxPwacrZTGVHOgueHLei2Gbxe8LYyTNscOclOJT8RKBPwrNxyH8YEphL PQb1Sl1FwT9m+qM6HF4L3RJFSRmx3H9bm4zhZxrzWV7ko9SHTMD39gPXzcg4bfbd IokU8PO+KnIRb5N3fWd4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 09:57:10 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1223358157.1.54396; Fri, 03 Jul 2020 09:57:09 -0400 Message-ID: <5EFF397F.7080807@isdg.net> Date: Fri, 03 Jul 2020 09:58:23 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200701235127.2EBB21C3C828@ary.qy> In-Reply-To: <20200701235127.2EBB21C3C828@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Jul 2020 13:58:26 -0000 On 7/1/2020 7:51 PM, John Levine wrote: > In article you write: >> -=-=-=-=-=- >> >> DMARC either introduced or popularized the concept of filtering on the Message From. Low-end gateways >> that lack DMARC support will typically do nothing with the Message From -- the header value does not >> appear in the message logs and it cannot be used for filtering because it is not examined. > > ##, #######. Spam filters like spamassassin have looked at the headers > along with everything else in the message forever. SA is a tool that reads the entire RS232 payload. I believe the OP was describing situations where the parameters for a DKIM assessor like DMARC may not always be provided in a log file or something that can process by their own tools. It would be akin to lacking certain data bits in the AUTH-RES header for an assessor only looking for the header. Accumulating these for some current or future evaluator to can explore is useful. In fact, the OP actually gave me an idea to do more in the area, for example, log the SMTP/DKIM Identities, in a CSV file: {timestamp},{smtp.ip},{smtp.ehlo},{smtp.mail},{smtp.to},{mail.from},{dkim.signer},{mail.sender},{list.id}, {reply.code} That would be something that can imported into a SQL table or a spreadsheet. But for something the sysop or 3rd party developer may be already reading, adding the identities not already logged to a process session log file, i.e. wcSMTP-{date}.log could be useful to them. In this case, the OP is highlighting his system is not logging the 5322.From in the log file. Not a protocol item, maybe an implementation suggestion side note item. All this would be something SA is not compatible with. > Given that the basis of your argument isn't true, I don't see any need > to go point by point through the rest of it. This is about synergism, like the above. A comment you may not agree with can be something that sparks something else. Most folks, if not all, cherry pick comments to follow up on so I would appreciate it if WG participation is not stifled with such rude comments. I would hope and expect the WG chairs and AD would be addressing this. Have a safe holiday weekend. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jul 3 07:02:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392AE3A0602 for ; Fri, 3 Jul 2020 07:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jEiwGWOr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=t7OEo75w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u6nNWl0ezpJ for ; Fri, 3 Jul 2020 07:02:33 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6063A05A0 for ; Fri, 3 Jul 2020 07:02:32 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=480; t=1593784945; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=645J0fKSH+Gf3Mku+ubyRAeWQlc=; b=jEiwGWOr7A+Jshtt5FiXdGslEorcg2THaiTb5Ar9YJ1ev5lVBl/dfNa7BdfocI zbs4H2LYV8n2mlW194Bt+Xe04V5SwgkbDBapE4TBrP8DMEdflw9Ot+kFpBDKkmmF eCf4AxW3oeH7gETAd44oe+EHYqdVk6u8liqPcYgx+IHXY= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 10:02:25 -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 217262419.78.6124; Fri, 03 Jul 2020 10:02:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=480; t=1593784875; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=8kfA30F sD+9D7yUFhJWNy0kqlCHIa59WVBwDk327F3I=; b=t7OEo75wVlZk8Qp7kZi2REu /gGKqTGmdlvocIi6AbJcbYC4yuRnGVfib4ApTETQ7qhttdD2lzWMcCpNSpj1Qyqc HeF49f21jnRYH+7RdbHvjq5kPd6zYvHm6iowVF0UPRhc01Yd4aNivDkxGA2YMFs9 h715VOCT68Jhaw33RyZs= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 10:01:15 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1223603516.1.57464; Fri, 03 Jul 2020 10:01:14 -0400 Message-ID: <5EFF3A74.9020802@isdg.net> Date: Fri, 03 Jul 2020 10:02:28 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200701235127.2EBB21C3C828@ary.qy> <5EFF397F.7080807@isdg.net> In-Reply-To: <5EFF397F.7080807@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Jul 2020 14:02:35 -0000 On 7/3/2020 9:58 AM, Hector Santos wrote: > On 7/1/2020 7:51 PM, John Levine wrote: >> >> ##, #######. Spam filters like spamassassin have looked at the headers >> along with everything else in the message forever. > > SA is a tool that reads the entire RS232 payload. HA! RS232 on my mind, helping an enterprise customer with his 32 modem server setup. Of course, I meant RFC5322. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jul 3 07:39: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 709A03A0818 for ; Fri, 3 Jul 2020 07:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 x09651J4yIaV for ; Fri, 3 Jul 2020 07:39:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 8A6253A081F for ; Fri, 3 Jul 2020 07:39:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RMSL7FPQ8W0084ZX@mauve.mrochek.com> for dmarc@ietf.org; Fri, 3 Jul 2020 07:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1593786888; bh=s/CFGXeR0vc9zwtGxukH1ye9dMm5keZ/dbzAxCgwny4=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=X7BKw0mT57tLk8ndstRTiKf4p2rWSFXwlcyQImn1LcMJMZ+mCF18SvrpP0mn1ah1T cIkNxhLJrbUfvs5Xly3mDhDH//0MAcqQysta2ZtvcsHLgShI8ktjVVNvcu93ZOrZOs l9nS6yfqLrw+QtKciQUcxD0EDwu0ncyvvT6y16SI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RMRLGT65HC000059@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 3 Jul 2020 07:34:45 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: dmarc@ietf.org Message-id: <01RMSL7DQVQQ000059@mauve.mrochek.com> Date: Fri, 03 Jul 2020 07:34:01 -0700 (PDT) In-reply-to: "Your message dated Fri, 03 Jul 2020 10:02:28 -0400" <5EFF3A74.9020802@isdg.net> References: <20200701235127.2EBB21C3C828@ary.qy> <5EFF397F.7080807@isdg.net> <5EFF3A74.9020802@isdg.net> To: Hector Santos Archived-At: Subject: Re: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Jul 2020 14:39:55 -0000 > On 7/3/2020 9:58 AM, Hector Santos wrote: > > On 7/1/2020 7:51 PM, John Levine wrote: > >> > >> ##, #######. Spam filters like spamassassin have looked at the headers > >> along with everything else in the message forever. > > > > SA is a tool that reads the entire RS232 payload. > HA! RS232 on my mind, helping an enterprise customer with his 32 modem > server setup. Of course, I meant RFC5322. Good to know I'm not the only one who confuses those. Ned From nobody Fri Jul 3 08:33:17 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 6DC813A0942 for ; Fri, 3 Jul 2020 08:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=QtRm4HJj; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Z49qr+Fu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI1YvOPJjWLy for ; Fri, 3 Jul 2020 08:33:14 -0700 (PDT) Received: from mail.winserver.com (pop3.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 5B3093A093A for ; Fri, 3 Jul 2020 08:33:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=587; t=1593790385; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=fxHO2pVkC0ZmZ9+fn3FsjAxqjdg=; b=QtRm4HJjZSxNEzZxHzSArQejntadWj/el4c3L33gueU/jHUN98rDHy5dC7+GZ0 GTP01s9ugeEgcVpyNpbPPaUqk9rC6Rs/Y+Ju61uinL6aTIXV/udvE8JBlElCRIpB a+0+2VEb0Z95DdbjIll91YV3gyS802o/XOZtzjkC7REQk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 11:33:05 -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 222702564.78.7724; Fri, 03 Jul 2020 11:33:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=587; t=1593790312; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=K4CN+rJ H1qvgf1Y65mLuemKmiUNs9PCZ32C14thWDy0=; b=Z49qr+FuTQNDA1C5jTxNEkd UZPsQ3+bFxzHNYVu5j9o1NC/mdYpBl1nou6mGkyYRQj9qqttd5am0BgODRHVX7et RbPPIqEtfrGqLrJ9uBGDiUpScBGkLxgFYqxYKta3pOAPvl2aPYQ2aDYbObW5OXTX O0DTq8hmbOvDgWYZP1bE= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 03 Jul 2020 11:31:52 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1229041235.1.54396; Fri, 03 Jul 2020 11:31:52 -0400 Message-ID: <5EFF4FB2.3030100@isdg.net> Date: Fri, 03 Jul 2020 11:33:06 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200701235127.2EBB21C3C828@ary.qy> <5EFF397F.7080807@isdg.net> <5EFF3A74.9020802@isdg.net> <01RMSL7DQVQQ000059@mauve.mrochek.com> In-Reply-To: <01RMSL7DQVQQ000059@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC as an instance of a class X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Jul 2020 15:33:16 -0000 On 7/3/2020 10:34 AM, ned+dmarc@mrochek.com wrote: >> On 7/3/2020 9:58 AM, Hector Santos wrote: >>> >>> SA is a tool that reads the entire RS232 payload. > >> HA! RS232 on my mind, helping an enterprise customer with his 32 modem >> server setup. Of course, I meant RFC5322. > > Good to know I'm not the only one who confuses those. A good example of the mental "Query Theory" [1] lookup misdirection :-) Be safe. [1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1959766 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Jul 5 14:56: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 0C29B3A0B57 for ; Sun, 5 Jul 2020 14:56:41 -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 ubPc51HNm_82 for ; Sun, 5 Jul 2020 14:56:38 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 C1A4A3A0B55 for ; Sun, 5 Jul 2020 14:56:38 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id s20so12232543vsq.5 for ; Sun, 05 Jul 2020 14:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+vAfLIkWrlKbIqmNcQs0NY3SJFUrvEo+j6n8BfHpEmY=; b=EfK1w2ZeTE9HTzr4HCyCFxZ7yTM3kvmnUkggnZM+HKKOBnSZ35A2/NwlsersKr739o dla9Q0lmrkKvl/RKY5xLJqLL5r5FepM8pPjqC44r4IuoiM02qcE+ol7Rz6XH7AbnEuWb 8c+wUE1Z8me6gum/+aYdugygywhJ6dx7QcBI37OsqWrYVZn9ouw52bNxCz1qOpdhGBCE ZJ1mEWQjF71BMLo11jTk5WzYyuZ8s+WHP5UpPkNyKam0FIOJgf5LuyafNghOpyCDq/Bv p4o41QAsYKIbuOYA77Wpvf/LOwP9hd7d/58JpXpTAoH5CuE//hveWXk9J3hYsjsHV8zc wHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+vAfLIkWrlKbIqmNcQs0NY3SJFUrvEo+j6n8BfHpEmY=; b=DNLji9/2oXL/E2vkMQft27TpVCgvJvDmG3iwgrrwqnyjC2w80D4afm+PIcYJVcHYb1 NslWoIzAu4bQmhSFMnz7ym/I4bhCdJAISwBFADe7c16sS8XeOx5aA5hZ9rZErp4EKWHk b5W+3Twp2DAIiiwx72aTuTeB8ureq+WHMNbDv1LovH00gOKvKvIgzgqlrRLM4COAJmB2 zJJqrjIvXmEclq5TUaHEPSp2q418VY2rdQrPR5Lt3/QSb+/dds7lhMrEI/UEYP8I+Cvx a4TDx0Tv2JPivuURRiyFD+oqBHMmZ4D0jlsVh8Ef136qO1SY8+A9qf1/0zZ79mtBNfd7 jqaA== X-Gm-Message-State: AOAM530SbbpfWvz5i1wH5BUF4MuvWOazSivj65dwgNXtOO/Thw77M5a0 pgfWPjicBA9SXdSFvDfxBRxcNSooRsIVS9qMVaGTPw== X-Google-Smtp-Source: ABdhPJwe6FlB83WtNfXuAwV79hCyfh7aw6LZtE0ox8W8CP0oigA+d8Xnn1TSIM2zYYC6VO9xvssw1jjcXhc365jj8Y8= X-Received: by 2002:a67:1305:: with SMTP id 5mr4107788vst.52.1593986197192; Sun, 05 Jul 2020 14:56:37 -0700 (PDT) MIME-Version: 1.0 References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> In-Reply-To: <159398558133.21061.9212076992920148901@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 14:56:26 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000f823805a9b8d5c3" Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 21:56:41 -0000 --0000000000000f823805a9b8d5c3 Content-Type: text/plain; charset="UTF-8" I decided to breathe life into this idea since it's relevant and got some discussion recently. Comments welcome. I'm talking to the Mailman people about the idea now; this is based on some things they mentioned. I haven't managed to get the attention of Sympa or L-Soft yet. -MSK ---------- Forwarded message --------- From: Date: Sun, Jul 5, 2020 at 2:46 PM Subject: New Version Notification for draft-kucherawy-dkim-transform-01.txt To: Murray S. Kucherawy A new version of I-D, draft-kucherawy-dkim-transform-01.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-transform Revision: 01 Title: Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures Document date: 2020-07-05 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Htmlized: https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform Diff: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-transform-01 Abstract: DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations prior to being re-signed by a mediator, so that a verifier might rewind such a modification and thereby confirm that the original signature still verifies against the original content. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000000f823805a9b8d5c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I decided to breathe life into this idea since it'= ;s relevant and got some discussion recently.=C2=A0 Comments welcome.
=

I'm talking to the Mailman people about the idea no= w; this is based on some things they mentioned.=C2=A0 I haven't managed= to get the attention of Sympa or L-Soft yet.

-MSK=

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Sun, Jul 5, 2020 at 2:46 PM
Subject: New Version = Notification for draft-kucherawy-dkim-transform-01.txt
To: Murray S. Kuc= herawy <superuser@gmail.com&g= t;



A new version of I-D, draft-kucherawy-dkim-transform-01.txt
has been successfully submitted by Murray Kucherawy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kucherawy-dkim-transfor= m
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Recognized Transformations of Mess= ages Bearing DomainKeys Identified Mail (DKIM) Signatures
Document date:=C2=A0 2020-07-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kucherawy-dk= im-transform-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-kucherawy-dkim-transform-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dkim-tra= nsform-01

Abstract:
=C2=A0 =C2=A0DomainKeys Identified Mail (DKIM) introduced a mechanism where= by a
=C2=A0 =C2=A0mail operator can affix a signature to a message that validate= s at
=C2=A0 =C2=A0the level of the signer's domain name.=C2=A0 It specified = two possible
=C2=A0 =C2=A0ways of converting the message body to a canonical form, one =C2=A0 =C2=A0intolerant of changes and the other tolerant of simple changes= to
=C2=A0 =C2=A0whitespace within the message body.

=C2=A0 =C2=A0The provided canonicalization schemes do not tolerate changes = in a
=C2=A0 =C2=A0message such as conversion between transfer encodings or addit= ion of
=C2=A0 =C2=A0new message content.=C2=A0 It is useful to have these capabili= ties to
=C2=A0 =C2=A0allow for transport through gateways, and also for transport t= hrough
=C2=A0 =C2=A0handlers (such as mailing list services) that might add conten= t that
=C2=A0 =C2=A0would invalidate a signature generated using the existing
=C2=A0 =C2=A0canonicalization schemes.

=C2=A0 =C2=A0This document presents a mechanism for declaring that a messag= e
=C2=A0 =C2=A0underwent one of a handful of well-defined transformations pri= or to
=C2=A0 =C2=A0being re-signed by a mediator, so that a verifier might rewind= such a
=C2=A0 =C2=A0modification and thereby confirm that the original signature s= till
=C2=A0 =C2=A0verifies against the original content.




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

The IETF Secretariat


--0000000000000f823805a9b8d5c3-- From nobody Sun Jul 5 15:31: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 73CAB3A0B95 for ; Sun, 5 Jul 2020 15:31:31 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=pw2WfGWn; dkim=pass (2048-bit key) header.d=wizmail.org header.b=StLRGnCD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNOjZB89kF5J for ; Sun, 5 Jul 2020 15:31:28 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 CA86E3A0B93 for ; Sun, 5 Jul 2020 15:31:27 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :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:Autocrypt; bh=ibbebGcZhrIJjncHf01mFzOAnGHoAopQLYV4fsHytfo=; b=pw2WfGWnCuJqbMSX6lKorXIF+t sEIw99P3nBzgpKKjl1kK79j4UcQmBerS7MlbZLBjdGVr7wkzaWR7KzO3ImAw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject: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:Autocrypt; bh=ibbebGcZhrIJjncHf01mFzOAnGHoAopQLYV4fsHytfo=; b=StLRGnCDeQjqR4SyFb+3JXqsWI VNysh+NIIk8WpJDkOQqoLqkq/AqXRKycDYKs78u4DuRlxf55FKJ4ydb+FavX9J55B8Gu873HtB67W 0yS1Y4GDrwI485ba6XxTobDTDbeFVO9Nn5HP+oTfRmM5rgkkqmS8KeejZmSApgyXdTGYKtVtZxUw3 PTb/i35fNx5bUbYQ+jtFpwMcSyavEULq62P0yJfCRUC9ukf+nZj+4ll/J+udFRqF7QGhynZ2xpwCn stX2UVS1j0PEBghk7T0diO3u5pwuqY/yp0Ho6nb9VPQ8nmoLYxrn/OuQ5fQCUruXeDsXgkz1mlk2u zMXYYC4w==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.102) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1jsDAT-0064LQ-K9 for dmarc@ietf.org (return-path ); Sun, 05 Jul 2020 22:31:25 +0000 To: dmarc@ietf.org References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: <8d77b193-492c-ec5a-8cae-414daf037005@wizmail.org> Date: Sun, 5 Jul 2020 23:31:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 22:31:31 -0000 On 05/07/2020 22:56, Murray S. Kucherawy wrote: > https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Substansive: section 6, on footers: - Is not a common boundary marker a signature-marker, namely two dashes, space, end-of-line? The exim-users list, for example, uses that. Nit: section 3: s/such transmission was/such transformation was/ -- Cheers, Jeremy From nobody Sun Jul 5 15:39: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 006073A0B9C for ; Sun, 5 Jul 2020 15:39:47 -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 mN-pgb2B-uqP for ; Sun, 5 Jul 2020 15:39:45 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 895F63A0B9D for ; Sun, 5 Jul 2020 15:39:45 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id i15so11522478uah.13 for ; Sun, 05 Jul 2020 15:39:45 -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=9yEDJQYp+ROOiCkrtyVbOv0RAqNayMY5XNYtLHKhvkg=; b=gaz+x3yi9R3j95YCxlyBeKeC9hfmiSQOvwb6defcslFLazSkBHtUVSyWnHTmbhT/eb lApmqgukTmY3cdpzIKnhwnCpUbR9Xb4+1fvtH5U3piQUoz+QqbCRageYKKMp6GEQ3yH1 6H1YFViu/3eiV5mOOT2f+MXv3KNO98NEqTNUFWdvAw03WbmUiKWu1Zj+cY/yaub/ywmI lLHlfyBHQ4prRNkyUsg5yJgbEOzsjXBDmpxvWoLzbiSucxUKdDDf34os77jrrF8d0YuU jWgeAJwJ3KA8zAxYHjPQwS5sN1Z8LYPVm3oaw1zC/21L6mGEckNjpyc1fyRIq4plOBfq AZ2Q== 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=9yEDJQYp+ROOiCkrtyVbOv0RAqNayMY5XNYtLHKhvkg=; b=KzFECF2rTnVw8SRtXzwjQNQv7Ta9dox620EdeZfvjJnsYZYaYw+4pkb9MosBiTneCA Vm4PBiS6GHpZs+i/ZcaJMMPiKqeweJMkzfnvfcFppU7P61SbC+2aF9Ztww8pIQnZcseX 5Mf6hE/W+SDctj6KK3ty8ho1ekvZFLBXEyJ85iKUlU15DPn+I5FoSmGO6qDpoPgL/dKc CcA51xEJQ5a9MlTeSWRYjBv5RhY/hVPkN5f4m5MllWGofIhyU3C0ux3J6Bac+5DfL31x ObvM70ayEZcc1wJXaNl3ytpXiSVdka6SJqui91La8ZGVsN19lI7LXrbVgnlHa1g+BKfl YmBQ== X-Gm-Message-State: AOAM533ZcPSgF1KhNIxJ5r7gKLK+Q1haB90xSmQQzy66TyscqQQxF6kN UiAP3Lt+yovf3L+vdDwTsOu3Z0ySDEG8884XczNuDQ== X-Google-Smtp-Source: ABdhPJzHvyniMTJ3iKXBR5evUyQf7sTRga3IJS1rUr917O+brQyOjxLbzhJRVIOlSlut30J/zsea2hqZT1ZOEJPjSFM= X-Received: by 2002:ab0:2c3:: with SMTP id 61mr31878461uah.87.1593988784511; Sun, 05 Jul 2020 15:39:44 -0700 (PDT) MIME-Version: 1.0 References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <8d77b193-492c-ec5a-8cae-414daf037005@wizmail.org> In-Reply-To: <8d77b193-492c-ec5a-8cae-414daf037005@wizmail.org> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 15:39:33 -0700 Message-ID: To: Jeremy Harris Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000046e0fc05a9b96f7f" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 22:39:47 -0000 --00000000000046e0fc05a9b96f7f Content-Type: text/plain; charset="UTF-8" On Sun, Jul 5, 2020 at 3:31 PM Jeremy Harris wrote: > On 05/07/2020 22:56, Murray S. Kucherawy wrote: > > https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 > > Substansive: > > section 6, on footers: > - Is not a common boundary marker a signature-marker, namely > two dashes, space, end-of-line? The exim-users list, for > example, uses that. > Yes, that's common, but I also looked at a list run by Mailman and found that it uses a line of underscores. I thought having one transformation that handles either case might be a good idea, but I'm happy to split them or whatnot if they can both be precisely described and that's what people want to do. Any opinion on the whole thing generally? Nit: > > section 3: s/such transmission was/such transformation was/ > Got it! -MSK --00000000000046e0fc05a9b96f7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 5, 2020 at 3:31 PM Jeremy Har= ris <jgh@wizmail.or= g> wrote:
On 05/07/2020 22:56, Murray S. Kucherawy wrote:=
> https://tools.ietf.org/html/draft-= kucherawy-dkim-transform-01

Substansive:

section 6, on footers:
- Is not a common boundary marker a signature-marker, namely
=C2=A0 two dashes, space, end-of-line?=C2=A0 The exim-users list, for
=C2=A0 example, uses that.

Yes, that= 9;s common, but I also looked at a list run by Mailman and found that it us= es a line of underscores.=C2=A0 I thought having one transformation that ha= ndles either case might be a good idea, but I'm happy to split them or = whatnot if they can both be precisely described and that's what people = want to do.

Any opinion on the whole thing ge= nerally?

Nit:

section 3:=C2=A0 =C2=A0s/such transmission was/such transformation was/
=

Got it!

-MSK
--00000000000046e0fc05a9b96f7f-- From nobody Sun Jul 5 15:48: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 2CEE93A0BAB for ; Sun, 5 Jul 2020 15:48: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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=pOZOngAm; dkim=pass (2048-bit key) header.d=wizmail.org header.b=QLTugarA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTI3XDoZipmq for ; Sun, 5 Jul 2020 15:48:41 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 6CB153A0BA8 for ; Sun, 5 Jul 2020 15:48:41 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:Cc:To: Subject: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:Autocrypt; bh=qAcCTrEbMY08uWamraLo8/GpbXQknI9BPa0hRP7tyY4=; b=pOZOngAmUBtdBQ4NztgNqAbxYw aYs2km3potVwUbD6J7dGKAUjMW/3kkxowi6NJxar6RJvmq5nxEE8fAi0nhBw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:Cc:To:Subject: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:Autocrypt; bh=qAcCTrEbMY08uWamraLo8/GpbXQknI9BPa0hRP7tyY4=; b=QLTugarAyAc84GEmF+iDtdCQuC gcDEn+3Arm+/meTLiVA5FC3hzhQT0A7JJwBn344tsv/2KM+43tWrnfmDMM5qtKkzUE60zdcOskbwv SN9RCt/ERJwELYBOtke2KsGGKzCixD/3yNdrmzpDOA15jt99a6AkNWeg9r7W/fricVTioWA5EWHoC ZjmwO7acfXkAIMDahEMjynGwIXo0dcVolr48Lcw2nNs3APnKABXRS46azUkP95/gUHPL7CgxVF2eC fsE5qUXEiufoXp1m8zluJRn6qxECIFyXxUAEwkQcFZBlXYbZgmjxD3gTtrp2eo8xDyCIbJxTCC0LD o+0MYV5A==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.102) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1jsDRA-0064hF-2m (return-path ); Sun, 05 Jul 2020 22:48:40 +0000 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <8d77b193-492c-ec5a-8cae-414daf037005@wizmail.org> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: <5f92f86a-8c0a-c24e-3acc-1d23db7f4084@wizmail.org> Date: Sun, 5 Jul 2020 23:48:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 22:48:43 -0000 On 05/07/2020 23:39, Murray S. Kucherawy wrote: > Any opinion on the whole thing generally? Certainly worthy of discussion. I wonder if it needs tying to ARC rather than, or in addition to DKIM? -- Cheers, Jeremy From nobody Sun Jul 5 15:53: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 7ABA63A0BAC for ; Sun, 5 Jul 2020 15:53:27 -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 j6CFtnHnefip for ; Sun, 5 Jul 2020 15:53:26 -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 154073A0BAA for ; Sun, 5 Jul 2020 15:53:26 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id s20so12265321vsq.5 for ; Sun, 05 Jul 2020 15:53: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=dnGwtJtqt5/aGmVWTvgP9aTCbo8Wnj+tA+RLdCVq9HY=; b=HJDmxCz/hKRc4Lpr/Kk0RSLSFP43eL3waaWzmnIpVThOPFU79FJvj/2c8jp2rpV+Zv Zo4hhly4Vb1MBgVLSBsWmPu2qNcxcCAFq6/L5t1Y9YRljukSEKacyaX864Dakq5W0R8b Fw12qY6mU2+/GARDvkutd6u0n1rwtREmurG2bHPAJ9h3Sbcw/eCgZELuvlDCEjLbxiRA oqtW1RTcvBTgK01zS5Mksa5+uCwpNWIxEvZrRgDZGJkMCsQsVTHHzFF9jFvH0gDzCDk4 smwCsV6PLgglyYRhquZn1tHhvRNb5dJcd9ZJkklFFrtlZ3Z2ZUzTd71WZcmsCl9hBQpW 9IuA== 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=dnGwtJtqt5/aGmVWTvgP9aTCbo8Wnj+tA+RLdCVq9HY=; b=BU4qsAemO9+CM0Ru+pCEwQG7HWHMyS25fawnlmt1LB2eWRBiKBcdp/RpNkBg+QDmMZ 277432l2D7KKTz62AvRgBQZ0sicXKNw1jraNGXcffDoqsdTpgI0dXZ63L9j9y99guGCD joHnFiluEGLcRbK5fVHmabT6wPqOQTDbaYGkImWyFCRfXuSlpSEfAK/Ku7qjFjMlSb8s +VCSc9B1YN7gQj6xAslfGkR/3Q3bmOS5mYlebVohGCQqDV8NTfKqJ60VshYBeJu75rxe Ev4Kf95cL9ywgEB65e+H7cqjGNp2rPJUSnzg0vMxwAC7+x5ena0+5azrsu/lpcNyCTsL ThsA== X-Gm-Message-State: AOAM5314zFbhisIppcAzwTRfV4wAFPElIfzaDDuisTB6hR59gWZf68q/ L5RhWuVHoKYSyn9h9+JW/GwAu60Qb81aWqhwFS9yYA== X-Google-Smtp-Source: ABdhPJyxKCfRWVf9OBBoFefq/ynDtmpIxiE/IvBBYggTnYTga2WJC3wC1MuzMtQgQBk1XXpQ7tFN7DmBphoVA6UcZKc= X-Received: by 2002:a67:ed15:: with SMTP id l21mr33697667vsp.175.1593989605073; Sun, 05 Jul 2020 15:53:25 -0700 (PDT) MIME-Version: 1.0 References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <8d77b193-492c-ec5a-8cae-414daf037005@wizmail.org> <5f92f86a-8c0a-c24e-3acc-1d23db7f4084@wizmail.org> In-Reply-To: <5f92f86a-8c0a-c24e-3acc-1d23db7f4084@wizmail.org> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 15:53:14 -0700 Message-ID: To: Jeremy Harris Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002fa64005a9b9a04e" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 22:53:28 -0000 --0000000000002fa64005a9b9a04e Content-Type: text/plain; charset="UTF-8" On Sun, Jul 5, 2020 at 3:48 PM Jeremy Harris wrote: > On 05/07/2020 23:39, Murray S. Kucherawy wrote: > > Any opinion on the whole thing generally? > > Certainly worthy of discussion. I wonder if it needs tying > to ARC rather than, or in addition to DKIM? > I think it solves the same problem ARC does. You want to know what authentication was possible at the time the MLM received the message; ARC transmits that information downstream using cryptographic signatures, while this lets the verifier see for itself. I originally floated this idea years before ARC was proposed, but there was no apparent community interest in pursuing it so I let it expire. -MSK --0000000000002fa64005a9b9a04e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 5, 2020 at 3:48 PM Jeremy Har= ris <jgh@wizmail.org> wrote:
On 05/07/2020 23:39, Murray S. Kucherawy wrote:
> Any opinion on the whole thing generally?

Certainly worthy of discussion.=C2=A0 I wonder if it needs tying
to ARC rather than, or in addition to DKIM?

= I think it solves the same problem ARC does.=C2=A0 You want to know what au= thentication was possible at the time the MLM received the message; ARC tra= nsmits that information downstream using cryptographic signatures, while th= is lets the verifier see for itself.

I originally floated this idea years before = ARC was proposed, but there was no apparent community interest in pursuing = it so I let it expire.

-MSK
--0000000000002fa64005a9b9a04e-- From nobody Sun Jul 5 19:42: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 004553A0DD8 for ; Sun, 5 Jul 2020 19:42: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 (1536-bit key) header.d=iecc.com header.b=Zg/5VpJn; dkim=pass (1536-bit key) header.d=taugh.com header.b=hNiDBeky Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kf8tsbFcXcE for ; Sun, 5 Jul 2020 19:42:44 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7143A0DD7 for ; Sun, 5 Jul 2020 19:42:43 -0700 (PDT) Received: (qmail 74712 invoked from network); 6 Jul 2020 02:42:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=123d3.5f028fa0.k2007; bh=b0LXwrCJvYQln4Acp8xwnDwuVZtOQfFer6KfsUWJiHQ=; b=Zg/5VpJnsb6nRSZa6FBXJDeOvpoGTSOLG/ChR/Vw+zF2NgTpHqU2trIlqbrzYo/XWYmlWsk7V2R5zLmQ/qQnyjVF3oANRlSCHhqDyw7e40k45NMpzqWyE1BSQsg2FXImShreP3jVF+U4ypqO+LMJO55IuhNnYzYtLHt/6QQZkZ7h5qq7su1lmniBkT7ba/Cg9w9K4E24UD+mMwxfWJFMDfarmLVrcfEMMzvDi7heR596t5mLILROY10t36QuiL5C 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=123d3.5f028fa0.k2007; bh=b0LXwrCJvYQln4Acp8xwnDwuVZtOQfFer6KfsUWJiHQ=; b=hNiDBekyIsGEvh4YFwR9QB+2kFVi/WOrLAQt4g2bngtqSGA2oOpBhlGjoem5o1pu5wQDLnnxMjhUn8OVNqE75EawcpPPHfmLOogfVsgcFnjP/JWibpHxihOx4utuKwGTB+YkrLVx95L9g+DRyCsKDrETrWjItTSgbkYMUmFMYHXzNZzInudqbw4y2juiqZR1Yngr5TI5IdFGovdUkBq25ViH6rXbfEiqjlRcmEv0LMB6X6zN0TWyEZ/lCdnOnkVs Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Jul 2020 02:42:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 8A4A41C598F8; Sun, 5 Jul 2020 22:42:51 -0400 (EDT) Date: 5 Jul 2020 22:42:51 -0400 Message-Id: <20200706024251.8A4A41C598F8@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 02:42:46 -0000 In article you write: >-=-=-=-=-=- > >I decided to breathe life into this idea since it's relevant and got some >discussion recently. Comments welcome. > >I'm talking to the Mailman people about the idea now; this is based on some >things they mentioned. I haven't managed to get the attention of Sympa or >L-Soft yet. I wrote the Sympa ARC code which is entwined with the DKIM code so that would probably be me. Honestly, this looks like a lot more work than ARC to get a result likely to be worse in practice than ARC. It would not be hard for a bad guy to use the footer or add-part transformation to lay a big spammy blob on top of some innocuous original message. Rather than play cat and mouse and try to figure one when a change is too big, recipients would use this the same way they use ARC, and only check it on mail from senders who are generally well behaved. I believe that the main thing that recipients will do with either of these is to ask was the original message actually from the putative sender, and ARC is a lot easier to implement. R's, John From nobody Sun Jul 5 20:35: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 9B7603A0E6A for ; Sun, 5 Jul 2020 20:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=JbYUiB2e; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=un6rfYyf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHvieo5FQrSV for ; Sun, 5 Jul 2020 20:35:41 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFDE3A0E69 for ; Sun, 5 Jul 2020 20:35:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4288; t=1594006538; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=tbqkzxfdzsjSfI/sSHn4K8z7rck=; b=JbYUiB2e//KDbx+iu7lF2LNYkZjN0MzxGby8VGJDiqRZFef+pntYzoU8qaHAYT 1Ukbro5ad2DLP/v7bF7Xv3D3kT6gWP3lckWxLOoKmqOF+jtg7Fd8tpOfQMXP/kk5 nAiPrhYAWVsuif9lAmm3BCp4KXAq4zANHsR3F+EkfP04s= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 05 Jul 2020 23:35:38 -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 438852339.78.4360; Sun, 05 Jul 2020 23:35:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4288; t=1594006462; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0TDMLek yU9GIjjguj9gbbQkays1GugIcG0etYJ5IQio=; b=un6rfYyf1kQufvaQlcLzFY+ N3J4VD9I/NBZ/TgXZs4Esov53D2AgJjyr0t20OtgLFKhmMx05Lxh63AlCwdnMBIv xhdvqPY40wirSAgvFGkGrTKBh3G8rnEV1BLyHL+e/YXwFvgCd17f8nJLCZP6b1kh +TchpH7JOJvmR0BfMyeg= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 05 Jul 2020 23:34:22 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 149636546.3.4216; Sun, 05 Jul 2020 23:34:20 -0400 Message-ID: <5F029C03.1000805@isdg.net> Date: Sun, 05 Jul 2020 23:35:31 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , IETF DMARC WG References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 03:35:44 -0000 1) Curious, are these Mail List Server (MLS) developers active participants of the WG list? Lurkers? Was there a consideration to include a MLS developer participant that is active in the WG? I'm sure you are aware SSI (Santronics Software, Inc) has a MLS albeit commercial, not free, not open source. 2) Was Mailman asked (the other two MLS were not) if a simple DNS lookup can be considered? IMO, as a MLS developer, it would be less coding than making a more complex change with this proposal or ARC. Given the proposal would be asking MLS developers to finally make changes to their code, it opens an opportunity to explore other available well-defined, empirically proven to work "running code" options. 3) And this hurts to ask, but I believe it is a natural "IETF Discuss" question to ask, is there an AD vs Editor conflict here? It is more of a general question and not specifically address to you as WG AD and the proposal editor. I'm sure you can be fair, but nonetheless, I have an active implementer "fairness" concern with each of these itemize questions. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 7/5/2020 5:56 PM, Murray S. Kucherawy wrote: > I decided to breathe life into this idea since it's relevant and got > some discussion recently. Comments welcome. > > I'm talking to the Mailman people about the idea now; this is based on > some things they mentioned. I haven't managed to get the attention of > Sympa or L-Soft yet. > > -MSK > > ---------- Forwarded message --------- > From: > > Date: Sun, Jul 5, 2020 at 2:46 PM > Subject: New Version Notification for > draft-kucherawy-dkim-transform-01.txt > To: Murray S. Kucherawy > > > > > A new version of I-D, draft-kucherawy-dkim-transform-01.txt > has been successfully submitted by Murray Kucherawy and posted to the > IETF repository. > > Name: draft-kucherawy-dkim-transform > Revision: 01 > Title: Recognized Transformations of Messages Bearing > DomainKeys Identified Mail (DKIM) Signatures > Document date: 2020-07-05 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.txt > Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ > Htmlized: https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform > Diff: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-transform-01 > > Abstract: > DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a > mail operator can affix a signature to a message that validates at > the level of the signer's domain name. It specified two possible > ways of converting the message body to a canonical form, one > intolerant of changes and the other tolerant of simple changes to > whitespace within the message body. > > The provided canonicalization schemes do not tolerate changes in a > message such as conversion between transfer encodings or addition of > new message content. It is useful to have these capabilities to > allow for transport through gateways, and also for transport through > handlers (such as mailing list services) that might add content that > would invalidate a signature generated using the existing > canonicalization schemes. > > This document presents a mechanism for declaring that a message > underwent one of a handful of well-defined transformations prior to > being re-signed by a mediator, so that a verifier might rewind such a > modification and thereby confirm that the original signature still > verifies against the original content. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > _______________________________________________ > 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 Sun Jul 5 21:44: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 1CD073A0F0C for ; Sun, 5 Jul 2020 21:44:07 -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 NZ5_gJnik8UI for ; Sun, 5 Jul 2020 21:44:05 -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 8B6043A0F0B for ; Sun, 5 Jul 2020 21:44:05 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id s20so12521409vsq.5 for ; Sun, 05 Jul 2020 21:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sEcp36MiSI5LGj6FaMJyk+ZoP57TSJHv2rBJuIOxDRw=; b=kGMjHoSGjK0lkuiKLPlzBX/qmFJ2sYd4n1ZgvNX1Wk4jf6Y2P3Ro9M/j+uk/Rhmu7H Qd8u9D+CIsuoROZ2P7NQauxIHb0AbY4SZHlg6yR3IKxPriTXcair1CwsVWMUBuzRVPAZ h7wXT3qszf8KITyXeJFsGTs2Eyuo0dG7VYNG7LzBHSmlLFGGDcMqTdctYZXyROl6191L R8gN4N7PYztqYyGcytAygPPRtROMraxV9q6aFc132YYuOZxDMtmG4yIQ+8xaIFvTQg8+ 6hL817fr6roaPcIly2fQ/f6z10ZRGB6v9puYY0zEWnMBI0YMKeeRjiv5DGfw2/R7t1hn IvMQ== 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=sEcp36MiSI5LGj6FaMJyk+ZoP57TSJHv2rBJuIOxDRw=; b=Hak+lb9j/Y4nVimC2X8hLdlAMcLK3HuSjHA6BetNUiCIw351J2mR0I7OIRs2Ke3x/V D0dJQDCvoEqnW6uYrpO1r7LfXlUCwQP1f6mrMQjoIbNCm+jcjmZ49aGRQpXlMixPb1jS QxzKmiPAtZfGV2BTyJsovikeve7rX6ODWk8jcpS0ywCuqStnTNuWAJvqj1aKjelGx0VX GJJvGmrrOW6pD6N/igG2rBRF9kFsml5maVmsSQz+dSh8E6fo9+xwA/y06/BjdyYKRWuw cEpHoGU4gYQYKWnIWejuyP3Eio+nYaPN9k6L7CdpCJmxE7IDbGz0Nj5QCjiNTrRPRqPv fALQ== X-Gm-Message-State: AOAM532pqpKRkui3rBiEhNOwui6liGYpc93u2t6EWC0qy0lIPULray4c wGQA3V0IHXK/q4g6ANyzFwC98qpMU/ry19wRI1rA7/J3 X-Google-Smtp-Source: ABdhPJwi+PRW4XlHuKs+wGSReid1z6pkc/mzPZIGrIhP6jGvaN2gV3mcessDujXavfmpXdZuC77Q8LxHMsCp81E7qpQ= X-Received: by 2002:a67:ed15:: with SMTP id l21mr34244251vsp.175.1594010644541; Sun, 05 Jul 2020 21:44:04 -0700 (PDT) MIME-Version: 1.0 References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <5F029C03.1000805@isdg.net> In-Reply-To: <5F029C03.1000805@isdg.net> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 21:43:53 -0700 Message-ID: To: Hector Santos Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003c735405a9be865c" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 04:44:07 -0000 --0000000000003c735405a9be865c Content-Type: text/plain; charset="UTF-8" On Sun, Jul 5, 2020 at 8:35 PM Hector Santos wrote: > 1) Curious, are these Mail List Server (MLS) developers active > participants of the WG list? Lurkers? Was there a consideration to > include a MLS developer participant that is active in the WG? I'm sure > you are aware SSI (Santronics Software, Inc) has a MLS albeit > commercial, not free, not open source. > The ones I've approached are not here, so that's why I reached out to them. You, on the other hand, are already participating, and are free to give your perspective. 2) Was Mailman asked (the other two MLS were not) if a simple DNS > lookup can be considered? IMO, as a MLS developer, it would be less > coding than making a more complex change with this proposal or ARC. > Given the proposal would be asking MLS developers to finally make > changes to their code, it opens an opportunity to explore other > available well-defined, empirically proven to work "running code" > options. > No, I have not put that question to them. If they join the list, you could ask them here; if they don't, you can reach out to them to make that inquiry. 3) And this hurts to ask, but I believe it is a natural "IETF Discuss" > question to ask, is there an AD vs Editor conflict here? It is more of > a general question and not specifically address to you as WG AD and > the proposal editor. I'm sure you can be fair, but nonetheless, I have > an active implementer "fairness" concern with each of these itemize > questions. > Fair question. Area directors are not barred from participating in working groups. If the WG were to choose to adopt this draft, for example, the chairs would have the choice of picking a different editor, as they do with any other document. It would be the chairs that make consensus calls as needed as the document evolves. They run the Working Group Last Call. Once it gets sent up for IETF-wide Last Call, some other Area Director would step in to run it through that part of the process (probably Barry, the other ART AD, but not necessarily). And when it gets to IESG balloting, I would recuse myself. If at any point it looks like a conflict of interest is possible, we tag other Area Director(s) to review it for undue influence. -MSK --0000000000003c735405a9be865c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 5, 2020 at 8:35 PM Hector Santos <hsantos@isdg.net> wrote:
1) Curio= us, are these Mail List Server (MLS) developers active
participants of the WG list?=C2=A0 Lurkers?=C2=A0 Was there a consideration= to
include a MLS developer participant that is active in the WG? I'm sure =
you are aware SSI (Santronics Software, Inc) has a MLS albeit
commercial, not free, not open source.

= The ones I've approached are not here, so that's why I reached out = to them.=C2=A0 You, on the other hand, are already participating, and are f= ree to give your perspective.

2) Was Mailman asked (the other two MLS were not) if a simple DNS
lookup can be considered? IMO, as a MLS developer, it would be less
coding than making a more complex change with this proposal or ARC.
Given the proposal would be asking MLS developers to finally make
changes to their code, it opens an opportunity to explore other
available well-defined, empirically proven to work "running code"=
options.

No, I have not put that questi= on to them.=C2=A0 If they join the list, you could ask them here; if they d= on't, you can reach out to them to make that inquiry.
3) And this hurts to ask, but I believe it is a natural "IETF Discuss&= quot;
question to ask, is there an AD vs Editor conflict here? It is more of
a general question and not specifically address to you as WG AD and
the proposal editor. I'm sure you can be fair, but nonetheless, I have =
an active implementer "fairness" concern with each of these itemi= ze
questions.

Fair question.
Area directors are not barred from participating in working gro= ups.=C2=A0 If the WG were to choose to adopt this draft, for example, the c= hairs would have the choice of picking a different editor, as they do with = any other document.=C2=A0 It would be the chairs that make consensus calls = as needed as the document evolves.=C2=A0 They run the Working Group Last Ca= ll.=C2=A0 Once it gets sent up for IETF-wide Last Call, some other Area Dir= ector would step in to run it through that part of the process (probably Ba= rry, the other ART AD, but not necessarily).=C2=A0 And when it gets to IESG= balloting, I would recuse myself.=C2=A0 If at any point it looks like a co= nflict of interest is possible, we tag other Area Director(s) to review it = for undue influence.

-MSK
--0000000000003c735405a9be865c-- From nobody Sun Jul 5 21:50:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF813A0F18 for ; Sun, 5 Jul 2020 21:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOJFsq_5CcWx for ; Sun, 5 Jul 2020 21:50:53 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADAE3A0F17 for ; Sun, 5 Jul 2020 21:50:53 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:6969:d55:4d3d:a50b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 0664opoS007912 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 5 Jul 2020 21:50:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594011053; bh=YFiQI73++l+949EmNttv/sm4ZsHHx6Oc2iBj40e3FEI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PPhoBIc9DIoH5zwz8LD09ZV3oAILgDYFBzRCmUUPuOLVwX6nh8Hw2ynOBZbdyACZd xThEeddwBFcA1glki5IRlWVj2mnwPhKpX3FVt96wbV3Thpb3eyzr4KEjGxAA3AqjPl vBvxKfYZsQw46PsYzB4WA8IHPJ1jJiLX7DXWHswU= To: dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> Date: Sun, 5 Jul 2020 21:50:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200706024251.8A4A41C598F8@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 04:50:55 -0000 On 7/5/20 7:42 PM, John Levine wrote: > > It would not be hard for a bad guy to use the footer or add-part > transformation to lay a big spammy blob on top of some innocuous > original message. Rather than play cat and mouse and try to figure one > when a change is too big, recipients would use this the same way they > use ARC, and only check it on mail from senders who are generally well > behaved. That was basically the argument against the l= parameter in DKIM signatures. We did end up keeping l= because it only has effect if the signer uses it and the verifier accepts its use, although it was widely expected that it would not be used much. I suspect that's what happened. -Jim From nobody Sun Jul 5 22:01:14 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 AC90A3A0F19 for ; Sun, 5 Jul 2020 22:01:12 -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 B40F3qceCpPn for ; Sun, 5 Jul 2020 22:01:11 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306303A0F17 for ; Sun, 5 Jul 2020 22:01:11 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id h1so8182618vkn.12 for ; Sun, 05 Jul 2020 22:01:10 -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=gaiHx++oy1+1l+JnS97rOINq0pkLFApoyrRSuQaDOUk=; b=SnA8FnZhjrPRzmjdZuGy5xRnQFOVSxc1OcCwESsAI3mlPSf1PuKS1BuJPrhGvqC3RC jDhr0i9En5Ve58yy+CjS85rbZxB5Ll6D8htTxsbHBpC6te1btV3bbaGHZimZJe0RZy7l YURujVhEgJOmz5qSdCZChG/E2V9Tk0o7aJ9O0mgpiYU0bRGAhqziPmJ7VfdudZADwNiZ ktU5fKYOtl7I/06IcJ+SKZ1Lp8kgPraw4lYuGUy9NSxrtiFNuBXynQ2x6mXZKNdgkWlU VN8b+R7aYu45S4uGednd7zbzyN2J7bQcgRLLd1JH88LZF0DTnY8Fb810rSR8BQyJeSXP nCiw== 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=gaiHx++oy1+1l+JnS97rOINq0pkLFApoyrRSuQaDOUk=; b=NrdTRopsvvW5xodFnqRJLXxey565+9UXhrZP0IjnesNCQSR7thWI6t1ewRv2WuSM0S 1HvUbDrEyhRqX/Pcnk8eLcId6m7mqgRJ4JpS6wuX4L6D1oGsBCdLnCQDSEPZl00qjIXS 0+MXeF4PXVVE590BSByyEGnmdLtfs8W0y1mlY1SYoOraNiGtByZng2r16HEJBVaqJdQy WtI824/bO+ja8iytf5Xzn+a3weLHalQWTpZt3wCjVNFO6bqWBA5p1PTaJluu4vvok6tT AWuDk/xdrwUDTaU10/vd+vS9TywZ3gOJ2jmzx6yz5FgE27gyjymqe+1DiCgpe06hxtwu 5L2Q== X-Gm-Message-State: AOAM5323IIvpE5t/ERpb7iLed6jPB+rVmjoUBTXgQ//JrVRUWGnWiJ2j jDQvVPOd5kIdv8/y+Mi5f8x4Xdrabxx142dZuMkecg3n X-Google-Smtp-Source: ABdhPJxvNej7DvRtFDzDB20+hfuXkBY5OHhCIvQIWlxUzeSzesfvvcFkv2uAlok7nxmnbL8ouYypFuVZJQTLMv+wJ54= X-Received: by 2002:a1f:9151:: with SMTP id t78mr32737354vkd.89.1594011669976; Sun, 05 Jul 2020 22:01:09 -0700 (PDT) MIME-Version: 1.0 References: <20200706024251.8A4A41C598F8@ary.qy> In-Reply-To: <20200706024251.8A4A41C598F8@ary.qy> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 22:00:59 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005b5c0805a9bec337" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 05:01:13 -0000 --0000000000005b5c0805a9bec337 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 5, 2020 at 7:42 PM John Levine wrote: > I wrote the Sympa ARC code which is entwined with the DKIM code so > that would probably be me. Honestly, this looks like a lot more work > than ARC to get a result likely to be worse in practice than ARC. > Interesting; I had the opposite experience, and I had a lot of our DKIM code to recycle when I built our ARC implementation. This idea doesn't seem nearly as complicated to implement. Moreover, ARC is a much more heavyweight addition to the stack than a new DKIM tag would be. > It would not be hard for a bad guy to use the footer or add-part > transformation to lay a big spammy blob on top of some innocuous > original message. Rather than play cat and mouse and try to figure one > when a change is too big, recipients would use this the same way they > use ARC, and only check it on mail from senders who are generally well > behaved. > That isn't a new attack though, given spammers sign their email already. This way you have (in theory) two good signatures: one from the author for the "safe" form of the message, and one for the spam that got bolted on, and you could in theory strip the spam before you deliver because you know exactly what it is. I believe that the main thing that recipients will do with either of > these is to ask was the original message actually from the putative > sender, and ARC is a lot easier to implement. > As I said upthread, I agree that it fulfills the same need that ARC does. There was a previous thread about ways to avoid MLMs needing to munge headers in a DMARC world, and that reminded me of this, so I thought it might be worth dusting it off. -MSK --0000000000005b5c0805a9bec337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 5, 2020 at 7:42 PM John Levin= e <johnl@taugh.com> wrote:
=
I wrote the Sympa ARC code which is entwined with the DKIM code so<= br> that would probably be me. Honestly, this looks like a lot more work
than ARC to get a result likely to be worse in practice than ARC.

Interesting; I had the opposite experience,= and I had a lot of our DKIM code to recycle when I built our ARC implement= ation.=C2=A0 This idea doesn't seem nearly as complicated to implement.= =C2=A0 Moreover, ARC is a much more heavyweight addition to the stack than = a new DKIM tag would be.
=C2=A0
It would not be hard for a bad guy to use the footer or add-part
transformation to lay a big spammy blob on top of some innocuous
original message. Rather than play cat and mouse and try to figure one
when a change is too big, recipients would use this the same way they
use ARC, and only check it on mail from senders who are generally well
behaved.

That isn't a new attack though,= given spammers sign their email already.=C2=A0 This way you have (in theor= y) two good signatures: one from the author for the "safe" form o= f the message, and one for the spam that got bolted on, and you could in th= eory strip the spam before you deliver because you know exactly what it is.=

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> I believe that the main thing that recipients will do with either of
these is to ask was the original message actually from the putative
sender, and ARC is a lot easier to implement.

As I said upthread, I agree that it fulfills the same need that= ARC does.=C2=A0 There was a previous thread about ways to avoid MLMs needi= ng to munge headers in a DMARC world, and that reminded me of this, so I th= ought it might be worth dusting it off.

-MSK
--0000000000005b5c0805a9bec337-- From nobody Sun Jul 5 22:04: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 33D3A3A0F20 for ; Sun, 5 Jul 2020 22:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ZhKLzXxBruVG for ; Sun, 5 Jul 2020 22:04:44 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 356893A0F1F for ; Sun, 5 Jul 2020 22:04:44 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id v1so19914811vsb.10 for ; Sun, 05 Jul 2020 22:04:44 -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=tJeAntNe7QN6lCBajVzlnxTU0oOtIlYx9dMmHunYkUQ=; b=VJq8KcxlV7pi2g/I1Oe+JLg/MJ/abtEkD5XKGYPOsH/utnZUmrq+BKgIoiDsLC5bqp oEPcopKhPpAtDFx1usljnuXsnz4Ma+FyJRidRSw0boejGKWzuxbBobea43ec2ez6SLeV oUJPI2iIrBUUOTIXQy0k6kGMIYrDAKjRRbTg8cwpFeK9Um/gcWzmenEevSOgphPWhuNJ UOI1Q1zG//lAG1Zvt5uPG6ZCUeRZskAV4JkfjPPNkbq2A6+A/1Te/wtLa5wSeofLTefE rQ5Vr7O20dzpgx6NwBwnDSjt648e6tIR3JkXqp13ZI9fNAPpy3510xU18LPqmY7mrm25 zAKA== 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=tJeAntNe7QN6lCBajVzlnxTU0oOtIlYx9dMmHunYkUQ=; b=gpdDkpbot+LrxbBXzs+EgsPICulQ1j7SvgHRykrNNdFFd+J7VK+yJCtEHmLKWjyHYS Lreiolt9jAot2im/rfsdpEmM8VAEstjxD4zCkXgZN+iIBFGrpbML8mWHrRJtQ84htEey 5p/R055z8WkI/jIYbrgGb9njqnYm8YGevgAOCGGfe9bChDrrrz0+9E4XG4F4cVJbbT0f tBIvEykJ48mj944Ga2PMrRmqDaAh9n97QrR+q2ZgvFxY3Yxat+lFceYMyWsxmfxn1cY3 waulXho9K5AJeb/bcSdNY/Uzby/fiqtrgdrsba+Y9aj2ekXhZ9xc6nFnphEnmzBbNgDw tqmg== X-Gm-Message-State: AOAM533DIQnpB7ldafGoPm+gQsSVM8h6aO8Qhu5k2frxHOeGjCRynPFx 0bz7OXu6qJeIq0K2gmzbmw4PGSXd51P9wVmPR4xzPA== X-Google-Smtp-Source: ABdhPJwFt7keFRl+aEPqKM6RSfkDFA5ZshsQcR5kmRRgr8uY+AWjjT4Ktr3y7z3a/cC06sDjpdAVbUwgIv4ZIkGMLkE= X-Received: by 2002:a67:1305:: with SMTP id 5mr4809147vst.52.1594011883158; Sun, 05 Jul 2020 22:04:43 -0700 (PDT) MIME-Version: 1.0 References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> In-Reply-To: <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Sun, 5 Jul 2020 22:04:32 -0700 Message-ID: To: Jim Fenton Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001040cd05a9bed0a3" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 05:04:45 -0000 --0000000000001040cd05a9bed0a3 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 5, 2020 at 9:51 PM Jim Fenton wrote: > That was basically the argument against the l= parameter in DKIM > signatures. We did end up keeping l= because it only has effect if the > signer uses it and the verifier accepts its use, although it was widely > expected that it would not be used much. I suspect that's what happened. > That sounds right to me. OpenDKIM, for example, makes it optional to consider signatures using "l=" invalid, or that have more than N bytes added using "l=", etc. -MSK --0000000000001040cd05a9bed0a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 5, 2020 at 9:51 PM Jim Fenton= <fenton@bluepopcorn.net&g= t; wrote:
That was basically the argument against the l=3D param= eter in DKIM
signatures. We did end up keeping l=3D because it only has effect if the signer uses it and the verifier accepts its use, although it was widely
expected that it would not be used much. I suspect that's what happened= .

That sounds right to me.=C2=A0 OpenDK= IM, for example, makes it optional to consider signatures using "l=3D&= quot; invalid, or that have more than N bytes added using "l=3D",= etc.

-MSK
--0000000000001040cd05a9bed0a3-- From nobody Sun Jul 5 22:22: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 25E0E3A0F50 for ; Sun, 5 Jul 2020 22:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=SlXHJXx5; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=NAbgFXXL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqjkK3XcrpFL for ; Sun, 5 Jul 2020 22:22:12 -0700 (PDT) Received: from mail.winserver.com (listserv.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB513A0F4C for ; Sun, 5 Jul 2020 22:22:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3056; t=1594012927; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=v/S1w6LqpaaLB6CTo4DncMIX4jk=; b=SlXHJXx5V+3+MME6l5GgoEChHUJ7Y4WSBdXzvg071tfUUhtu3dXuP2ANo4/PQW YTpREzG7nIE4gRCdo5/RrCAMtG05OUUf1dLBbjU3poasggdRoCPyV1wsuX4IU+4l sEdvBnT85sakowmZz1q91KM5qAoBeeuFI+ukdBrB6B+e8= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 06 Jul 2020 01:22:07 -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 445242623.78.5428; Mon, 06 Jul 2020 01:22:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3056; t=1594012855; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yffJ3BB pTjTbJ0205HSjM9KC8BgNtfTSXdndlLxAnu0=; b=NAbgFXXL7eZC078uRpE068j OSfrk/X2MxcBtNzTTQEfQkRjg3c0el9YlzfhJ8rPxdOXh15Ti4ELRi2wu5p4keOX eudR199yS2K1btoAjSwqBWwTjpZOhQMdwD5M0zfDp6CLgDjT4Fya2F/05cFCmuEi tedmDgFx82JjZyxLq2tQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 06 Jul 2020 01:20:55 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 156030765.3.2768; Mon, 06 Jul 2020 01:20:55 -0400 Message-ID: <5F02B4FE.8030901@isdg.net> Date: Mon, 06 Jul 2020 01:22:06 -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: "Murray S. Kucherawy" CC: IETF DMARC WG References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <5F029C03.1000805@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 05:22:14 -0000 Yes, I was aware an AD can participate in a WG, but was not sure if the AD can do so in a WG where there might be proposed working items authored by the AD. A recusal consideration for a conflict, if any, would be the proper recourse. Thanks for your fair responses. I appreciate it. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 7/6/2020 12:43 AM, Murray S. Kucherawy wrote: > On Sun, Jul 5, 2020 at 8:35 PM Hector Santos > wrote: > > 1) Curious, are these Mail List Server (MLS) developers active > participants of the WG list? Lurkers? Was there a consideration to > include a MLS developer participant that is active in the WG? I'm > sure > you are aware SSI (Santronics Software, Inc) has a MLS albeit > commercial, not free, not open source. > > > The ones I've approached are not here, so that's why I reached out to > them. You, on the other hand, are already participating, and are free > to give your perspective. > > 2) Was Mailman asked (the other two MLS were not) if a simple DNS > lookup can be considered? IMO, as a MLS developer, it would be less > coding than making a more complex change with this proposal or ARC. > Given the proposal would be asking MLS developers to finally make > changes to their code, it opens an opportunity to explore other > available well-defined, empirically proven to work "running code" > options. > > > No, I have not put that question to them. If they join the list, you > could ask them here; if they don't, you can reach out to them to make > that inquiry. > > 3) And this hurts to ask, but I believe it is a natural "IETF > Discuss" > question to ask, is there an AD vs Editor conflict here? It is > more of > a general question and not specifically address to you as WG AD and > the proposal editor. I'm sure you can be fair, but nonetheless, I > have > an active implementer "fairness" concern with each of these itemize > questions. > > > Fair question. > > Area directors are not barred from participating in working groups. > If the WG were to choose to adopt this draft, for example, the chairs > would have the choice of picking a different editor, as they do with > any other document. It would be the chairs that make consensus calls > as needed as the document evolves. They run the Working Group Last > Call. Once it gets sent up for IETF-wide Last Call, some other Area > Director would step in to run it through that part of the process > (probably Barry, the other ART AD, but not necessarily). And when it > gets to IESG balloting, I would recuse myself. If at any point it > looks like a conflict of interest is possible, we tag other Area > Director(s) to review it for undue influence. > > -MSK > > > _______________________________________________ > 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 Mon Jul 6 01:49: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 656843A1215 for ; Mon, 6 Jul 2020 01:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG9yfnwFvbQ5 for ; Mon, 6 Jul 2020 01:49:10 -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 017AE3A1214 for ; Mon, 6 Jul 2020 01:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594025346; bh=aXEr337rhowaxMm0HOi4PJ1Qz4fB+VEPoDcpvLphQxo=; l=1806; h=To:References:From:Date:In-Reply-To; b=DLXaBICzFVUkH5XVsXR5Muxdr5IG9xMgI8UCidkb1wr7lPQ6Uo6yLNbSJYdM+MxyW NAGQ91tNRSRgW6Mb9z32U9armunau/duUo3waqf9UrIp1rfgzAAHsuN3wvPcOXpsiQ 1WOZ/Wwn2SBjWHs/z2DCIIR0e10bh7qWnuoKXKNlwVPNxUgvuEwdiofFMBsnp Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F02E582.00003493; Mon, 06 Jul 2020 10:49:06 +0200 To: dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> From: Alessandro Vesely Message-ID: <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> Date: Mon, 6 Jul 2020 10:49:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 08:49:12 -0000 On Mon 06/Jul/2020 06:50:45 +0200 Jim Fenton wrote: > On 7/5/20 7:42 PM, John Levine wrote: > >> It would not be hard for a bad guy to use the footer or add-part >> transformation to lay a big spammy blob on top of some innocuous >> original message. Rather than play cat and mouse and try to figure one >> when a change is too big, recipients would use this the same way they >> use ARC, and only check it on mail from senders who are generally well >> behaved. > > That was basically the argument against the l= parameter in DKIM > signatures. We did end up keeping l= because it only has effect if the > signer uses it and the verifier accepts its use, although it was widely > expected that it would not be used much. I suspect that's what happened. The rationale for deprecating l= was that HTML and CSS allow appended content to be displayed before or even above (overlapping) the original content. I don't recall an actual proof of concept, though. Perhaps, we could have thought better: 1. In most cases, text/html is relegated in its own MIME entity. Multipart messages don't support simple append, except for the "epilogue" area. 2. In any case, the etag is covered by the signature. Added text would trigger quirks mode, and suppress CSS. Rather than deprecate l=, perhaps we could just have noticed that it only makes sense in text/plain messages, where it allows the addition of a footer. For example, this message —now that IETF seems to have given up base64 encoding— should feature an unbroken author signature. For multipart messages, transformations may need to replace boundaries. In that case, the "restricted patch" to undo the transformation may require more data than it is convenient to store in a DKIM tag. Best Ale -- From nobody Mon Jul 6 02:03: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 E05E93A1230 for ; Mon, 6 Jul 2020 02:03: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, 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 39WtZiFrkk94 for ; Mon, 6 Jul 2020 02:03:36 -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 D0BAA3A122F for ; Mon, 6 Jul 2020 02:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594026213; bh=C8fXY3RgVKa2XFY1+kx4XJZm7xJnNg5M7FUNM8ydQ1A=; l=504; h=To:References:From:Date:In-Reply-To; b=AgNIIFa/HjD8beUF/JRk47DPGJKrF1NI+1Tw4/Ewgd8h1mtfqO7J4C3sePe3CxLSP jyts6lXprUrkMoh4tMKtOR8Ras9S9O+xgk+UVVVzYmu+gtMM76Yx6e5v9Sz/CKer/w BRqKzZ4nuVDMHXMQfL3oRW4Xp29Je14g+Aa2JMcC3or7ucUfyf87UlYfDx1A8 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F02E8E5.000036B1; Mon, 06 Jul 2020 11:03:33 +0200 To: dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> From: Alessandro Vesely Message-ID: <1b17ff95-b0a7-c210-7ffe-8e083d020af7@tana.it> Date: Mon, 6 Jul 2020 11:03:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Base64 encoding (some?) IETF messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Jul 2020 09:03:37 -0000 On Mon 06/Jul/2020 10:49:06 +0200 Alessandro Vesely wrote: > > Rather than deprecate l=, perhaps we could just have noticed that it only makes > sense in text/plain messages, where it allows the addition of a footer.  For > example, this message [...]now that IETF seems to have given up base64 encoding[...] > should feature an unbroken author signature. It doesn't. It was base64 encoded. Perhaps because of non-ASCII characters (which I elided in the quotation above)? Best Ale -- From nobody Mon Jul 6 02:24: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 AEA173A1261 for ; Mon, 6 Jul 2020 02:24:33 -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 OEZFVZMed1pT for ; Mon, 6 Jul 2020 02:24:32 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 79F993A1260 for ; Mon, 6 Jul 2020 02:24:32 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id m25so20179808vsp.8 for ; Mon, 06 Jul 2020 02:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qgHqTt695vj5WaTv8MOscXjemtO1KrsTuFMvGIRphuk=; b=HIreOV0SP9OSCz8NF1vOvQRid3W/zm6YrVJTWj8RVpTmcWiZ0DmPEF0AMWvxMI7Og3 qNNKDmSCiYI2hbGpnHbzxtmzeANJtylA8y5ywWlKt5JW5fuhSvFsLL7DvUqaaHjAJd66 l36bctbweZTzmx3s2oUTkAcfyaqfI08iQfYVwVKMbsGtiDg5HfoJx6fOhpixzUH3rob+ ifXV16l5fvLyO35Tjvz8TU1Q+PM0FL0gxRCASN2pmFzHDH+3TkY0h4/opa1Lb583ZNvS QW/7IZ5nz/RHGWuYKrtdRIarJemd7ZT5Z+RHQbqpIfmlSIkp65AhTLQ6PNA7eewISeoP thrA== 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=qgHqTt695vj5WaTv8MOscXjemtO1KrsTuFMvGIRphuk=; b=JLIz8ElrjotdHBzoc3SoaiCIZCWUjG7binzK/gzZe6zOmhJvlwLEyDxAFJShezhoS7 MM5182l3ei42eNhahw8SIiJnYY72As2F/VMcFY/fEv07jmIwij6sv0GxIeTYsqFmiPkQ zPHa9AafAicNEARsTLZUE69uAsa62jRza5T08QdgXge679wgOmkyZf3muZNGpJqCxTj/ A8seryQ0ypVS4vDSWOf2VbRcpCDTL6tF74qWFnUHkBHintLv33uD64MSiTpGotemwDOF anlJKkn1KW4anE0nzCPOb1HjktxYr2hBD0vDjQUxxEDB50AcKrUMDRh4HGH2zshIOvab 4y0A== X-Gm-Message-State: AOAM532OIxifg7/9DTtoOW+VumMIrmjVItWc3iWJsxffzAr+WpSmBxGl yF8K/agv4B3XGLnXq7dTiXLHF+G8zM9YtENpsTObHg== X-Google-Smtp-Source: ABdhPJy2CbvoaTG9CByJ/45gnA3qbFvkGql2mOOefhsQcWN7QOUkNKqKqqcHsiO2/Fa9OcUFUKQeVNCKztEsKTwXSGk= X-Received: by 2002:a67:ed15:: with SMTP id l21mr34747522vsp.175.1594027471395; Mon, 06 Jul 2020 02:24:31 -0700 (PDT) MIME-Version: 1.0 References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> In-Reply-To: <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 02:24:19 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000031de9705a9c271f8" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 09:24:34 -0000 --00000000000031de9705a9c271f8 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: > For multipart messages, transformations may need to replace boundaries. > In > that case, the "restricted patch" to undo the transformation may require > more > data than it is convenient to store in a DKIM tag. > Replace why? It might need to add its own, but it's easy to undo that. In order to be useful, this only needs to do what MLMs commonly do already. We don't need to cover the universe of possible futures right away. -MSK --00000000000031de9705a9c271f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 1:49 AM Alessandro= Vesely <vesely@tana.it> wrote:=
For multipart messages, transformations may need to replace bou= ndaries.=C2=A0 In
that case, the "restricted patch" to undo the transformation may = require more
data than it is convenient to store in a DKIM tag.
Replace why?=C2=A0 It might need to add its own, but it's e= asy to undo that.

In order to be useful, this only= needs to do what MLMs commonly do already.=C2=A0 We don't need to cove= r the universe of possible futures right away.

-MSK
--00000000000031de9705a9c271f8-- From nobody Mon Jul 6 05:49: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 9DCF03A1450 for ; Mon, 6 Jul 2020 05:49:02 -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 5OrMq6dGEurf for ; Mon, 6 Jul 2020 05:49:00 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C7B3A144D for ; Mon, 6 Jul 2020 05:49:00 -0700 (PDT) X-ASG-Debug-ID: 1594039735-11fa313a103037c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id l0QS7cgudZyg1eJW (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 06 Jul 2020 08:48:55 -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:subject:to:from; bh=/+kOsRN5qRkIpiUpKXNmed/jdZeNDVCIfMoxx9/ZPxY=; b=QaOFZWdaZnEL9P3Mi52G38YBjVCQex74NbjjMARswR94UcO1dcjeQdEgxGs6bllTf jvSTz33QnZiV9vCfMEMid6BWvDh9AeZBEA3Gfr+ixLWQU6CAz/4vZF40EzKdpSSOf 28UwjHrgYEGZj/6m4XSEejkyS93j0EhINJos0K5nU= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 6 Jul 2020 08:48:48 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: "'IETF DMARC WG'" References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> In-Reply-To: Date: Mon, 6 Jul 2020 08:48:48 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt Message-ID: <000901d65393$cb26bda0$617438e0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D65372.44162F10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWj34MJGz8Uh/irssZDnwOv1Pb9AIu90maqOiLuZA= Content-Language: en-us X-Exim-Id: 000901d65393$cb26bda0$617438e0$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594039735 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: 12705 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.83012 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 12:49:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D65372.44162F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like the idea of making signatures recoverable wherever possible. =20 For mailing lists, I wonder if this approach is sufficient to solve the = whole problem. If the MLM transformation is for security rather than = informational purposes, I expect that the transformations will be (even = should be) non-reversible.=20 =20 For some spam filters, it might be important. Lots of spam filters add = DKIM-invalidating content upon entry to the protected domain. Many of = those changes should be reversible. URL rewrite is the most difficult = to reverse using this approach. =20 =20 However, when the incoming and outgoing email gateways are from the same = vendor, as I suspect is often the case, the reversal should already be = feasible using proprietary methods. Is any known spam filter vendor = doing this type of reversal? =20 DF =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy Sent: Sunday, July 05, 2020 5:56 PM To: IETF DMARC WG Subject: [dmarc-ietf] Fwd: New Version Notification for = draft-kucherawy-dkim-transform-01.txt =20 I decided to breathe life into this idea since it's relevant and got = some discussion recently. Comments welcome. =20 I'm talking to the Mailman people about the idea now; this is based on = some things they mentioned. I haven't managed to get the attention of = Sympa or L-Soft yet. =20 -MSK =20 ---------- Forwarded message --------- From: Date: Sun, Jul 5, 2020 at 2:46 PM Subject: New Version Notification for = draft-kucherawy-dkim-transform-01.txt To: Murray S. Kucherawy A new version of I-D, draft-kucherawy-dkim-transform-01.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-transform Revision: 01 Title: Recognized Transformations of Messages Bearing = DomainKeys Identified Mail (DKIM) Signatures Document date: 2020-07-05 Group: Individual Submission Pages: 14 URL: = https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.tx= t Status: = https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Htmlized: = https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Htmlized: = https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dkim-transform-01 Abstract: DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations prior to being re-signed by a mediator, so that a verifier might rewind such a modification and thereby confirm that the original signature still verifies against the original content. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------=_NextPart_000_000A_01D65372.44162F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I like the idea of making signatures recoverable wherever = possible.

 

For mailing lists, I wonder if this approach is sufficient to solve = the whole problem.=C2=A0=C2=A0 If the MLM =C2=A0transformation is for = security rather than informational purposes, I expect that the = =C2=A0transformations will be (even should be) non-reversible. =

 

For some spam filters, it might be important.=C2=A0=C2=A0 Lots of = spam filters add DKIM-invalidating content upon entry to the protected = domain.=C2=A0=C2=A0 Many of those changes should be reversible.=C2=A0 = URL rewrite is the most difficult to reverse using this = approach.=C2=A0=C2=A0

 

However, when the incoming and outgoing email gateways are from the = same vendor, as I suspect is often the case, the reversal should already = be feasible using proprietary methods.=C2=A0=C2=A0 Is any known spam = filter vendor doing this type of reversal?

 

DF

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Sunday, July 05, 2020 5:56 PM
To: = IETF DMARC WG
Subject: [dmarc-ietf] Fwd: New Version = Notification for = draft-kucherawy-dkim-transform-01.txt

 

I = decided to breathe life into this idea since it's relevant and got some = discussion recently.  Comments welcome.

 

I'm talking to the Mailman people about the idea now; = this is based on some things they mentioned.  I haven't managed to = get the attention of Sympa or L-Soft yet.

 

-MSK

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>=
Date: Sun, Jul 5, 2020 at 2:46 PM
Subject: New Version = Notification for draft-kucherawy-dkim-transform-01.txt
To: Murray S. = Kucherawy <superuser@gmail.com>




A new version of I-D, = draft-kucherawy-dkim-transform-01.txt
has been successfully submitted = by Murray Kucherawy and posted to the
IETF = repository.

Name:          =  draft-kucherawy-dkim-transform
Revision:      =  01
Title:          Recognized = Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) = Signatures
Document date:  2020-07-05
Group:    =       Individual Submission
Pages:      =     14
URL:            https://www.ietf.org/internet-drafts/draft-kucherawy-dk= im-transform-01.txt
Status:         https://datatracker.ietf.org/doc/draft-kucherawy-dkim-t= ransform/
Htmlized:       https://tools.ietf.org/html/draft-kucherawy-dkim-transf= orm-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-kucherawy-d= kim-transform
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dki= m-transform-01

Abstract:
   DomainKeys = Identified Mail (DKIM) introduced a mechanism whereby a
  =  mail operator can affix a signature to a message that validates = at
   the level of the signer's domain name.  It = specified two possible
   ways of converting the message = body to a canonical form, one
   intolerant of changes and = the other tolerant of simple changes to
   whitespace = within the message body.

   The provided = canonicalization schemes do not tolerate changes in a
  =  message such as conversion between transfer encodings or addition = of
   new message content.  It is useful to have these = capabilities to
   allow for transport through gateways, = and also for transport through
   handlers (such as mailing = list services) that might add content that
   would = invalidate a signature generated using the existing
  =  canonicalization schemes.

   This document = presents a mechanism for declaring that a message
  =  underwent one of a handful of well-defined transformations prior = to
   being re-signed by a mediator, so that a verifier = might rewind such a
   modification and thereby confirm = that the original signature still
   verifies against the = original content.




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

The IETF = Secretariat

------=_NextPart_000_000A_01D65372.44162F10-- From nobody Mon Jul 6 06:09:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1377C3A1478 for ; Mon, 6 Jul 2020 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6c5vu1g2IGp for ; Mon, 6 Jul 2020 06:09:15 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4639F3A1477 for ; Mon, 6 Jul 2020 06:09:15 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id AA8B1801B2 for ; Mon, 6 Jul 2020 13:09:13 +0000 (UTC) X-Fuglu-Spamstatus: NO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=1735; q=dns/txt; s=default; t=1594040953; h=from : subject : date : to; bh=0TH577myGMlnxMNCFeaOxOFEuPYaObmY4PpalaJD0Hw=; b=CrqnpFEM6/wq8WVLI9ZSjElor3hPpFangaW6nWOcv22DScB0ma/mMJ8UJ0TxdZ/bJszNI nCvQSLNgnaKBsVsJErXJOok7pC3hBEgZks2KU6TFFlPvQ7/UIQT7J8F2i7XlG6cfWW1qHp9 HRCjXKZ03iIHdR8ahFE8rpV9QKXaoD8= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 57FF87F9C3 for ; Mon, 6 Jul 2020 13:09:13 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 06 Jul 2020 15:09:13 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <000901d65393$cb26bda0$617438e0$@bayviewphysicians.com> References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <000901d65393$cb26bda0$617438e0$@bayviewphysicians.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 13:09:18 -0000 Doug Foster skrev den 2020-07-06 14:48: > I like the idea of making signatures recoverable wherever possible. > > For mailing lists, I wonder if this approach is sufficient to solve > the whole problem. If the MLM transformation is for security rather > than informational purposes, I expect that the transformations will > be (even should be) non-reversible. > > For some spam filters, it might be important. Lots of spam filters > add DKIM-invalidating content upon entry to the protected domain. > Many of those changes should be reversible. URL rewrite is the most > difficult to reverse using this approach. > > However, when the incoming and outgoing email gateways are from the > same vendor, as I suspect is often the case, the reversal should > already be feasible using proprietary methods. Is any known spam > filter vendor doing this type of reversal? i know mailman can do the right things, ARC sealing, and then nothing more, then its op to DMARC to test results from ARC, job done but this does not work if DKIM is breaked before ARC sealing is done, and DMARC testing is not yet maked into stable releases yet, and in gentoo none of it exists i have dropped OpenDKIM, OpenARC, OpenDMARC, and now just live with fuglu > modification and thereby confirm that the original signature still > verifies against the original content. in the end it might work better if maillists in generic does not try to fix anything thay self creates as a problem to solve, dovecot and postfix maillists is known to not break DKIM, and currrently only dovecot is doing ARC sealing, not the worst case, but nice to know that maillist can stop breaking DKIM hope it will be standard in 2021 finaly From nobody Mon Jul 6 07:31: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 D7FAA3A07F2 for ; Mon, 6 Jul 2020 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=c9OvTXeL; dkim=pass (1536-bit key) header.d=taugh.com header.b=VW7jlL20 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6pA0eTGZ-x for ; Mon, 6 Jul 2020 07:31:03 -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 256283A07F0 for ; Mon, 6 Jul 2020 07:31:02 -0700 (PDT) Received: (qmail 88286 invoked from network); 6 Jul 2020 14:31:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=158d8.5f0335a5.k2007; i=johnl-iecc.com@submit.iecc.com; bh=U6SWcjSFKc5zM1up17QKVojQDDUIrmKAlZ+M5/SyClU=; b=c9OvTXeL9E2TOvTird9w0Xr9u1R6n3JkCHl3jHLpHZtpy4h2OVp9XqnrbN6kpmFHWmrznj+KzJo7llQd/MKWAlFXEeyvLKNjBV49qAfM6kW1+eaiAq8oxGrBiXUbF/FfUWk1g3HnArqbeUyEH3YCqrju6qo0TGr7EqdLSfVUqq1qkz/xTeaYTFla5Cjq635HEjFHzwuRLggyjij+iJVz/rUiJvH20RcEj6g5uYg2O+/Ggv20U6C/0JXUhXvZfPDe DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=158d8.5f0335a5.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=U6SWcjSFKc5zM1up17QKVojQDDUIrmKAlZ+M5/SyClU=; b=VW7jlL20/sl9W3kc46D+bxzUOvEqvjtkkKYaio0kCU3S/RJwBJANyDyYeA0+nGVmU5JTnbDRRO2L0rUl9CL9Vx8MMlH99/45gLLGR01/EOsK9FLWu0uq4NlwVcgPGL2Cy3VNA7ING7Q0sQWtELBsj6TirxwVmT2DdF22R7gbseYnG1+UzWdpbZ8j2JpVYesxaYBHVye9uUOBuFoAONQ91I2iXExqoCIIqesJNjIpjiCDWW+v6HvqibBr5D+VVFwV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Jul 2020 14:31:00 -0000 Date: 6 Jul 2020 10:31:13 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20200706024251.8A4A41C598F8@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 14:31:05 -0000 >> I wrote the Sympa ARC code which is entwined with the DKIM code so >> that would probably be me. Honestly, this looks like a lot more work >> than ARC to get a result likely to be worse in practice than ARC. > > Interesting; I had the opposite experience, and I had a lot of our DKIM > code to recycle when I built our ARC implementation. This idea doesn't > seem nearly as complicated to implement. Moreover, ARC is a much more > heavyweight addition to the stack than a new DKIM tag would be. I was thinking of the work involved in putting it into the mailing list software. ARC was straightforward, one bit where the messages come in to recard the A-R header, another bit cloned from the DKIM code to apply the seal. For this I'd need to go through vast amounts of code looking for every place that changes the message and figuring out what change might map onto what DKIM key, and we still have a lot of changes that don't map onto anything, so now some changes are safer than others. >> It would not be hard for a bad guy to use the footer or add-part >> transformation to lay a big spammy blob ... > That isn't a new attack though, given spammers sign their email already. > This way you have (in theory) two good signatures: one from the author for > the "safe" form of the message, and one for the spam that got bolted on, > and you could in theory strip the spam before you deliver because you know > exactly what it is. But then what? Surely we're not going to revisit the WKBI of showing different parts of the message in different colors depending on whether they're signed. If it's got bolted on spam, you treat the message as spam so I don't see that this has gained you anything. R's, John From nobody Mon Jul 6 08:43:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DA93A1654 for ; Mon, 6 Jul 2020 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kkvj24rmqwc4 for ; Mon, 6 Jul 2020 08:43:37 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4053A1657 for ; Mon, 6 Jul 2020 08:43:37 -0700 (PDT) X-ASG-Debug-ID: 1594050215-11fa313a10307690001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id wZFluRsW6kfLjmi7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 06 Jul 2020 11:43:35 -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:subject:to:from; bh=oJkHfd5DsOMK8dTvAmLDv2UoRK9Mg44f+Teo0vL3GCY=; b=fN5bD2//WS/ezyO4e7Xx8LcitczRUjZyZY3bKyb5JVpsSJMYhORlBQehCaShyj/sf Xa7uvPgiu3axAQnxaUVW/A2qRoYe0gbVq5bIuZ3rO6X54BpPCxrK7IeKOMVSjAold wzwaG9m1ElVQKnzPXgQYw8g+bjCVLu0rfqJ88Y0tU= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 6 Jul 2020 11:43:27 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: "'Murray S. Kucherawy'" , "'IETF DMARC WG'" References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> In-Reply-To: Date: Mon, 6 Jul 2020 11:43:27 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt Message-ID: <005301d653ac$31469d40$93d3d7c0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01D6538A.AA360EB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWj34MJGz8Uh/irssZDnwOv1Pb9AIu90maqOi5LtA= Content-Language: en-us X-Exim-Id: 005301d653ac$31469d40$93d3d7c0$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594050215 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: 16118 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.83014 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 15:43:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01D6538A.AA360EB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If MLM changes are not reversible, we still have the problem of = convincing the recipient gateway to trust the modified message. =20 At first glance, this is an internal issue between the user who created = the subscription and his email security administrator, and that = communication is not obviously an IETF problem. But in a large = consumer-focused environment like Gmail, or even within a Fortune 500 = enterprise, some level of automation may be necessary. Additionally, = the email filter MTA and the mail store are often separate products from = separate companies, so we have an multi-vendor interoperability issue. = Collectively this seems to make an IETF specification appropriate. =20 At present, email gateways have very limited ability to distinguish = between solicited and unsolicited mail. Some implementations check for = a match on the user=E2=80=99s contact list. Other products check for = outbound messages to the sender. Giving the email gateway better = information about subscribed mail flows should improve filtering = accuracy. =20 =20 This is the scenario in my head, a variant of something posted = previously: =C2=B7 User A subscribes to mailing list M. =C2=B7 Mailing list M sends a message to User A with a request = to ensure that the inbound gateway will accepts its message. The = message contains attachments needed to define and justify the request. = I envision an XML attachment for use with automation, and a text file = for non-automated environments. An XLST file could be used to convert = the XML to TXT, to validate that the XML attachment and the text = attachment are really stating the same thing. =20 =C2=B7 The configuration files provide this type of information: o The header fields which will uniquely identify message from this = subscription, and the tests which can be performed to validate those = headers. o The administrative contacts for the list. o Whether the list makes DKIM-invalidating changes, and why. o For Murray=E2=80=99s approach: Whether the changes will be fully = or partially reversible and whether it supports the tf extension. o For John=E2=80=99s approach: Whether or not the list implements = ARC. =C2=B7 The email administration then reviews the request and = replies to user and MLM in one of three ways: o Fully Approved - any required gateway trust changes have been = implemented. For automated systems, the XML file is used to apply these = changes. o Strongly rejected - subscription is contrary to policy and should = be cancelled; user should assume that any incoming messages will be = blocked. o Neutral =E2=80=93 Subscription is not rejected but no trust changes = will be made. Any particular message may or may not be blocked. =20 Would this be more likely to succeed than the alternatives? =20 DF ------=_NextPart_000_0054_01D6538A.AA360EB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If MLM changes are not reversible, we still have the problem of = convincing the recipient gateway to trust the modified = message.

 

At first glance, this is an internal issue between the user who = created the subscription and his email security administrator, and that = communication is not obviously an IETF problem.=C2=A0=C2=A0=C2=A0 But in = a large consumer-focused environment like Gmail, or even within a = Fortune 500 enterprise, some level of automation may be = necessary.=C2=A0=C2=A0 Additionally, the email filter MTA and the mail = store are often separate products from separate companies, so we have an = multi-vendor interoperability issue.=C2=A0 Collectively this seems to = make an IETF specification appropriate.

 

At present, email gateways have very limited ability to distinguish = between solicited and unsolicited mail.=C2=A0=C2=A0 Some implementations = check for a match on the user=E2=80=99s contact list.=C2=A0=C2=A0 Other = products check for outbound messages to the sender.=C2=A0=C2=A0=C2=A0 = Giving the email gateway better information about subscribed mail flows = should improve filtering accuracy.=C2=A0=C2=A0

 

This is the scenario in my head, a variant of something posted = previously:

=C2=B7         = User A subscribes to mailing list M.

=C2=B7         = Mailing list M sends a message to User A with a request to ensure = that the inbound gateway will accepts its message.=C2=A0=C2=A0 The = message contains attachments needed to define and justify the = request.=C2=A0=C2=A0=C2=A0 I envision an XML attachment for use with = automation, and a text file for non-automated environments.=C2=A0=C2=A0 = An XLST file could be used to convert the XML to TXT, to validate that = the XML attachment and the text attachment are really stating the same = thing.=C2=A0=C2=A0

=C2=B7         = The configuration files provide this type of = information:

o   The header fields which will uniquely identify message from this = subscription, and the tests which can be performed to validate those = headers.

o   The administrative contacts for the list.

o   Whether the list makes DKIM-invalidating changes, and = why.

o   For Murray=E2=80=99s approach:=C2=A0=C2=A0 Whether the changes will = be fully or partially reversible and whether it supports the tf = extension.

o   For John=E2=80=99s approach:=C2=A0 Whether or not the list implements = ARC.

=C2=B7         = The email administration then reviews the request and replies to user = and MLM in one of three ways:

o   Fully Approved - any required gateway trust changes have been = implemented.=C2=A0 For automated systems, the XML file is used to apply = these changes.

o   Strongly rejected=C2=A0 - subscription is contrary to policy and = should be cancelled; user should assume that any incoming messages will = be blocked.

o   Neutral =E2=80=93 Subscription is not rejected but no trust changes = will be made.=C2=A0=C2=A0 Any particular message may or may not be = blocked.

 

Would this be more likely to succeed than the = alternatives?

 

DF

------=_NextPart_000_0054_01D6538A.AA360EB0-- From nobody Mon Jul 6 09:44:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFD93A170E for ; Mon, 6 Jul 2020 09:44:17 -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 nNStuXBAknVQ for ; Mon, 6 Jul 2020 09:44:16 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428B23A170B for ; Mon, 6 Jul 2020 09:44:16 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id t187so471818vke.5 for ; Mon, 06 Jul 2020 09:44:16 -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=o33syGHhH4N4qtmBTBb4GjBL7uDZVWHvCI2z4+pK+xI=; b=OucCiO+14ZLBGHuF7M8U0uQuzpxmfdCKvVGwfJ5MyodjwNaMlhGTuWDFpTXUSdDzgw w4qJ9BArdPzIrzYjeIhdYaT4L6zChti2DnFXOvwWYszrhPj66gX0biToTj8XLN9/UCdl gyg/x2PJZIeZAtdMILb2tfhvsI46LmRWvCUsTiqYMX6NkA9sZEJ++51ArfKipP3TtPyG VOg8q/MD0g0Gv3IFbTcFngqQ0rURx21s4Di/wZRdljItPoKhSdJ5kqbgV85pIbUoqsfF gRTE2deNx2vUSXUNBuwYfTbKaM2ToVdY+9pyGdFM4TVmYND6pKzn4rvkzazA0EZIsrVY N7Bg== 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=o33syGHhH4N4qtmBTBb4GjBL7uDZVWHvCI2z4+pK+xI=; b=sOu7XOYDRfs0AwJTvwDz0eqyZm2ZZT70JHffCobNJX76Om9OaAo4NAtz1CmVOvQFAw JgXIV/ZRW12HBvQFg2dws8Z1D+BOcgQDzj5ras3Hu4+oNFzdsD0SBTq2iiXedvvYC8g4 SOuQEqKzvmXCQ+Rvvjkv+RhII+EVs9CHsJWsKh2fnpeSZcPXjmgRW/b39txzIlWlqDEJ bKsNm9VJt4iMbBqhA1o4zGtuyPT/Jc2ZlZ6E21cM5+8Ry7RGsGmvLYno8fSrC2tn9rO0 BcBvfVa+39FODfcQv4X3vh33ICgiXnpqSjX/17WypCPN9FongBNsI2opQ8LKHR2AWN0J 9QUQ== X-Gm-Message-State: AOAM532GnKD6q9vLvYZJwlW10B0LMRMqhb6KZMfY6Crent+axl2lv1VI zIdmWX0DpZw2GdFVZ8gW9Gg4QM2LJSWGMaDdAl9lMg== X-Google-Smtp-Source: ABdhPJxAcEp7hftXvHEXWrvjCz5ppHGMCKALCzrNlbXBV06gpymM7L/e5T8jf/E3Me+XQ7fHYOnA4ArsiYvoObfs2hQ= X-Received: by 2002:a1f:9151:: with SMTP id t78mr34702540vkd.89.1594053854004; Mon, 06 Jul 2020 09:44:14 -0700 (PDT) MIME-Version: 1.0 References: <20200706024251.8A4A41C598F8@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 09:44:01 -0700 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b88e9105a9c895a8" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:44:18 -0000 --000000000000b88e9105a9c895a8 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 7:31 AM John R Levine wrote: > > That isn't a new attack though, given spammers sign their email already. > > This way you have (in theory) two good signatures: one from the author > for > > the "safe" form of the message, and one for the spam that got bolted on, > > and you could in theory strip the spam before you deliver because you > know > > exactly what it is. > > But then what? Surely we're not going to revisit the WKBI of showing > different parts of the message in different colors depending on whether > they're signed. If it's got bolted on spam, you treat the message as spam > so I don't see that this has gained you anything. > No, I'm not saying render them differently. I'm saying that if the second signature passes, then the second one signed the bolted-on spam but also told you how to strip it away to get the original. So, do that; if the author signature now passes, you have the original "clean" message to show instead of the hijacked message. If not, you have a spammy message to deal with, as before. If the second signature doesn't pass in the first place, then it's ignored, and you still have spam to deal with. Of course, the original message might be spam too, but that's not new either. This isn't meant to solve spam. It's meant to deal with the legitimate MLM+DKIM+DMARC case. -MSK --000000000000b88e9105a9c895a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 7:31 AM John R Lev= ine <johnl@taugh.com> wrote:
> That isn't a new attack though, given spammers sign their email al= ready.
> This way you have (in theory) two good signatures: one from the author= for
> the "safe" form of the message, and one for the spam that go= t bolted on,
> and you could in theory strip the spam before you deliver because you = know
> exactly what it is.

But then what?=C2=A0 Surely we're not going to revisit the WKBI of show= ing
different parts of the message in different colors depending on whether they're signed.=C2=A0 If it's got bolted on spam, you treat the mes= sage as spam
so I don't see that this has gained you anything.
=
No, I'm not saying render them differently.=C2=A0 I'= m saying that if the second signature passes, then the second one signed th= e bolted-on spam but also told you how to strip it away to get the original= .=C2=A0 So, do that; if the author signature now passes, you have the origi= nal "clean" message to show instead of the hijacked message.=C2= =A0 If not, you have a spammy message to deal with, as before.

If the second signature doesn't pass in the first plac= e, then it's ignored, and you still have spam to deal with.

Of course, the original message might be spam too, but th= at's not new either.

This isn't meant to s= olve spam.=C2=A0 It's meant to deal with the legitimate MLM+DKIM+DMARC = case.

-MSK
--000000000000b88e9105a9c895a8-- From nobody Mon Jul 6 09:49: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 58C843A171B for ; Mon, 6 Jul 2020 09:49:27 -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 8D2arqU1zbWb for ; Mon, 6 Jul 2020 09:49:26 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 0627F3A1729 for ; Mon, 6 Jul 2020 09:49:25 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id u133so7416585vsc.0 for ; Mon, 06 Jul 2020 09:49:24 -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=Y4NGO6gE1ICbXUuriK8uoMjKjiBrwq+yO8ylw3VkdP0=; b=FPR9QHbC8Cak1sjzmSLMqAhG135oNlcACqU1HUoGWl2qlKXD4yE0V8Gy7Wt3R9rG4w ilXTDhKww1IPno8NJ7l0c1nhBtxy9aF8q4ZnyCs2GKxK4qoF+z6iBvC/2CCaZXJFdGEm AGYwz9fgOz+MNUBoTjlC/1CdQvEvPqi4i6PrKqMaf02YfV+VrwBcZdcoF+z1sziW6rrY 8jYgSisvUB2VRxXpFhofMRA5hNe8KI2rsIPwtlR1411QCybYmXgNQT4oqxzMXWfYlQfQ YnF0zEAy0vYDLC5ogJDXo2Lyax4Xd10CPB81fxHHu3VQ9lgXiMU6pixGtQFLkVbczb0H Bkkg== 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=Y4NGO6gE1ICbXUuriK8uoMjKjiBrwq+yO8ylw3VkdP0=; b=Rsscc+9YNCXMAZ5Kg1rrTNveuvJmTJosCnwUF6YmiVOvsUwuFVHUUTD/8vQWdBMkXC W4QHVqX+o3Bh3vt1JwfgHjlzHuqq/DUDf/QgvqkHq14d3YC9m8reRMRYoenGUd3h8eEq tpmO2RIQm5H2yv69CtzRcxk44Vcj1+mcoI6NJbNr4eccA0IysjfQ95Z537lrW4CKkMzS Jf8GqrXRL+d27EWHZL9zooTpb/mSGrStCB1Fzvr9hcooBDgBVK8ldWjaC4kqRkXAcCuD mkoSakb8vpQLQZSVUrspGqJHgBOggIUxDceiZIo8lz3TlGaKz9ByrqAYVvR0qORcKaxq uMhA== X-Gm-Message-State: AOAM530iw+UktUb7Fh7QlHKXfRzHDFap1wYRUoCm5q2M9q55qaK5GflA pIP4ObUB/qMa9EO+QyZfG1iTlrmk8fqiiVblxLXUAA== X-Google-Smtp-Source: ABdhPJx5l3tMSsTGF7esszgkNcoWkJPAAC1iLtB+3j3Qs64uij7/LxdoAZhS+ozsQfV8WF2vbmdlpACjozQzlyYMrro= X-Received: by 2002:a67:fd15:: with SMTP id f21mr547290vsr.7.1594054163876; Mon, 06 Jul 2020 09:49:23 -0700 (PDT) MIME-Version: 1.0 References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <005301d653ac$31469d40$93d3d7c0$@bayviewphysicians.com> In-Reply-To: <005301d653ac$31469d40$93d3d7c0$@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 09:49:11 -0700 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000030ce2805a9c8a867" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:49:27 -0000 --00000000000030ce2805a9c8a867 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 6, 2020 at 8:43 AM Doug Foster wrote: > =C2=B7 Mailing list M sends a message to User A with a request to > ensure that the inbound gateway will accepts its message. The message > contains attachments needed to define and justify the request. I > envision an XML attachment for use with automation, and a text file for > non-automated environments. An XLST file could be used to convert the X= ML > to TXT, to validate that the XML attachment and the text attachment are > really stating the same thing. > The first thing that comes to mind for things like this is whether and how spammers will try to use this to clear a path to the inbox. How do you know this XML blob is coming from a bona fide list? Anecdotally, spammers were the first to adopt DKIM. This wouldn't be any different. =C2=B7 The email administration then reviews the request and replie= s to > user and MLM in one of three ways: > This needs to be automatable, or it won't scale to very large operations. I suspect there's virtually zero chance a GMail sized operation will staff up to review requests given the size of their customer base. And once it's automated, there needs to be a strategy for dealing with stale data (e.g., old lists nobody is using anymore), etc. -MSK --00000000000030ce2805a9c8a867 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 8:43 AM Doug Foste= r <fosterd@bayviewphysi= cians.com> wrote:
= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mailing list M sends a message to User A with a request to e= nsure that the inbound gateway will accepts its message.=C2=A0=C2=A0 The me= ssage contains attachments needed to define and justify the request.=C2=A0= =C2=A0=C2=A0 I envision an XML attachment for use with automation, and a te= xt file for non-automated environments.=C2=A0=C2=A0 An XLST file could be u= sed to convert the XML to TXT, to validate that the XML attachment and the = text attachment are really stating the same thing.=C2=A0=C2=A0

The first thing that comes to mind = for things like this is whether and how spammers will try to use this to cl= ear a path to the inbox.=C2=A0 How do you know this XML blob is coming from= a bona fide list?

Anecdotally, spammers were the = first to adopt DKIM.=C2=A0 This wouldn't be any different.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The email administ= ration then reviews the request and replies to user and MLM in one of three= ways:

This needs to be = automatable, or it won't scale to very large operations.=C2=A0 I suspec= t there's virtually zero chance a GMail sized operation will staff up t= o review requests given the size of their customer base.

And once it's automated, there needs to be a strategy for dealin= g with stale data (e.g., old lists nobody is using anymore), etc.
=

-MSK

--00000000000030ce2805a9c8a867-- From nobody Mon Jul 6 10:03: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 8B63F3A1745 for ; Mon, 6 Jul 2020 10:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dTKBVIkM; dkim=pass (1536-bit key) header.d=taugh.com header.b=WK1NeXtn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moRQ_B-NC138 for ; Mon, 6 Jul 2020 10:02:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69613A173C for ; Mon, 6 Jul 2020 10:02:58 -0700 (PDT) Received: (qmail 52984 invoked from network); 6 Jul 2020 17:02:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cef0.5f03593f.k2007; i=johnl-iecc.com@submit.iecc.com; bh=D6NDc33xhe8aJyzqX+XyclPI3Voavv2zTk2tCDUdrzc=; b=dTKBVIkMn08YcaR4C5vKrB7CDDM8IHwerOumbHKsSpliSRtCNxF9DPhkXx78SWIIpPW+brdRpdOKOtjzWaAwQOdT97V9qHqYU8cQjCIaPUW+q4LegBmAvcJUQfWvX225sR370gCSRpOR5FdkVbj3+CDv+ija8Si41Kl3m/9Zlw5bgwPbms2Fbx/pwVSaiDS6EzuaOE+rNSCin2+jUuhipFeOyPvntksqnVRAQdO1wGT9Fp8VvabVDvoGKr/fHP9b DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cef0.5f03593f.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=D6NDc33xhe8aJyzqX+XyclPI3Voavv2zTk2tCDUdrzc=; b=WK1NeXtnssdGRFZLnxEW3XmWC1RXjbCoTdTLyofj7fyVH+5ZPvFdKxcX/HXsw+YVfUbN4TD/BJpchqGbrju2hGBE7Fa4WHvUhYHTmYAuTYPhIyN7GiNBp0RHa5nbvAnXmUFP8GWPD47Jjt3+ZdA6ljb+C8Sn4rXoDC7IEDPy2i1bJiKMs9jifbgV5KE++JWbtZBSqPpiD/P6aQgx6G4Snh4+2tayM99shZFJY8dFa9M9v78A7m7ZVfs236K2ONNw Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Jul 2020 17:02:55 -0000 Date: 6 Jul 2020 13:03:07 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20200706024251.8A4A41C598F8@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:03:01 -0000 On Mon, 6 Jul 2020, Murray S. Kucherawy wrote: > No, I'm not saying render them differently. I'm saying that if the second > signature passes, then the second one signed the bolted-on spam but also > told you how to strip it away to get the original. So, do that; if the > author signature now passes, you have the original "clean" message to show > instead of the hijacked message. If not, you have a spammy message to deal > with, as before. I don't understand this scenario at all. Why would I want to show my user a message forwarded by a spammer? If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list. R's, John From nobody Mon Jul 6 10:08: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 449003A177D for ; Mon, 6 Jul 2020 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFP8E8Vg-lLE for ; Mon, 6 Jul 2020 10:08: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 BD8D53A1778 for ; Mon, 6 Jul 2020 10:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594055303; bh=cV0xkV3071be0kr+As1EOFMSsPi3fUyh0v/sXJEtkpo=; l=1407; h=To:Cc:References:From:Date:In-Reply-To; b=A0JEDnWFJm7JYFABawyud2HhRq/kZuVe3VHKMQNM882Wn5UBrWiRFUNcePgsMv0bZ auPCF/rWnMgDFLt2AdRY95iC+Ci8necl2ixCPD2w5d9KmuDGyAIOBNchbOZiO3//4Q Bkn1xEUuXv1a2d0wG1rUuJZgnMOdcviyVRXG5rwRBVQRdlKqJg+zq1yxDaiw2 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F035A87.0000731C; Mon, 06 Jul 2020 19:08:23 +0200 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> From: Alessandro Vesely Message-ID: Date: Mon, 6 Jul 2020 19:08:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:08:27 -0000 On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: > On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: > >> For multipart messages, transformations may need to replace boundaries. >> In that case, the "restricted patch" to undo the transformation may >> require more data than it is convenient to store in a DKIM tag. >> > > Replace why? It might need to add its own, but it's easy to undo that. Oops, I thought MLM generated boundaries anew. It seems that's not the case. Still, the original Content-Type is difficult to reproduce exactly. You need to know whether the boundary= parameter is written as a token or a quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a few bits, the info to undo the transformation (a reverse patch?) could be stored in its own field, or even in an attachment. Another difficulty, IIRC, is reordering of To:. This can simply be avoided. > In order to be useful, this only needs to do what MLMs commonly do > already. We don't need to cover the universe of possible futures right > away. Agreed. MLMs code has no lack of conditionals. Probably this technique can address a class of mailing lists somewhat wider than the "no-changes" class, without trying to cover even one half of /present/ MLM possibilities. Shall say just enough to cover IETF mailing lists? Best Ale -- From nobody Mon Jul 6 10:12: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 E0C7D3A17A2 for ; Mon, 6 Jul 2020 10:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcTPzT5ZiLLA for ; Mon, 6 Jul 2020 10:12:08 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711D43A1797 for ; Mon, 6 Jul 2020 10:12:08 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id b4so35461379qkn.11 for ; Mon, 06 Jul 2020 10:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wGHxXBisYwTCPuAHWLAmEheCo2JMZuMy+anhwfNorqw=; b=rrDBjZ4+7S+xlwVLihUtM8aj31wSLfSESei7OXgDkL/UagD2WxJycQs13bOpFwNuk5 if2zFBiHppvcnyb7RhS1qe1GK6AjuRSm5barHCmWMkDhxopaAkP5CiN8pVGB2XKuFl2K aHipCxzQU6fE8hz/hv/KaD53odl2n/8RRlUH24E1VrVfxTx6zKFt+oZtmX3F7a8s+r+o 1tPfk5Ruvu1iKSJm1J5T2OXoI4Kh3MyRS61smhMIUBJLNzjFcMLbtwWhNBCbfsvfhsgA biu3H/TRtQ4y3chkapS7Vc1y+rNbB/t8RMO1WjUZ9yoEKY5v5T1yEVJA7MzOvw3IwuRU Qusw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wGHxXBisYwTCPuAHWLAmEheCo2JMZuMy+anhwfNorqw=; b=iPiiPsScmYCYcm3AUoAhdjiBXlMdLI4MIzjhDLOeUSJlfLwnF16Zip4RDtxMbzZo9D Zyzs1tFGYlxm2Y58Y37CjUkmtAELB6y7csjduf1alaZ742cSWxy8xnEqVhuycoIF7yNk rCE3XWijh6BxDPa2LDMl9cX2Yh6xH5+zLKroPvQiv4tYcie94d30BY9CVcaQJOGm+8nT /PZeWmElqu9B5ZUW1EqBswvZY/th/Ym3fce3ASyJPerge/vsPTAFfLeq+lErOEHyH82v WfUJNYspErlI1d41gzdZMkhnvgsR0f36o6YuKpH83wJjWqZJ6Ou8VEtfWGsELDapmTM9 eqKw== X-Gm-Message-State: AOAM533NmF9ebHvf8UhGxoH8OIY25I0T5NnKWaeOZAFa2ZZQbVd8HviO WneYAm4OCUsGT5OzO7MpJCAlYU52YoI= X-Google-Smtp-Source: ABdhPJx4tHfwvyVcGAHaQRrI8E6pC6IMwo0Jf9bfrueyysBWV1nJuV5nayb/VEJ5/2WPVgnikiPUfg== X-Received: by 2002:a37:4d8:: with SMTP id 207mr48101110qke.298.1594055527194; Mon, 06 Jul 2020 10:12:07 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:4855:e08a:7443:c16d? ([2600:1700:a3a0:4c80:4855:e08a:7443:c16d]) by smtp.gmail.com with ESMTPSA id k14sm21737669qtm.38.2020.07.06.10.12.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 10:12:06 -0700 (PDT) To: John R Levine , "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200706024251.8A4A41C598F8@ary.qy> From: Dave Crocker Message-ID: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> Date: Mon, 6 Jul 2020 10:12:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E9DF38F9D622B98DE82DEB25" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:12:10 -0000 This is a multi-part message in MIME format. --------------E9DF38F9D622B98DE82DEB25 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/6/2020 10:03 AM, John R Levine wrote: >> No, I'm not saying render them differently.  I'm saying that if the >> second >> signature passes, then the second one signed the bolted-on spam but also >> told you how to strip it away to get the original.  So, do that; if the >> author signature now passes, you have the original "clean" message to >> show >> instead of the hijacked message.  If not, you have a spammy message >> to deal >> with, as before. > > I don't understand this scenario at all.  Why would I want to show my > user a message forwarded by a spammer?  If the original sender wanted > me to see it, she could have sent it to me directly, or through a > legit mailing list. Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees.  Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature.  Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------E9DF38F9D622B98DE82DEB25 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/6/2020 10:03 AM, John R Levine wrote:
No, I'm not saying render them differently.  I'm saying that if the second
signature passes, then the second one signed the bolted-on spam but also
told you how to strip it away to get the original.  So, do that; if the
author signature now passes, you have the original "clean" message to show
instead of the hijacked message.  If not, you have a spammy message to deal
with, as before.

I don't understand this scenario at all.  Why would I want to show my user a message forwarded by a spammer?  If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list.


Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees.  Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature.  Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------E9DF38F9D622B98DE82DEB25-- From nobody Mon Jul 6 10:21:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250C73A17A3 for ; Mon, 6 Jul 2020 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxK1s0KB34UX for ; Mon, 6 Jul 2020 10:21:48 -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 B9F4E3A179B for ; Mon, 6 Jul 2020 10:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594056106; bh=i4VJnUCOsrYKT+2Nagm8CL0Nc/X9RC3CLdD33rJfUpE=; l=1023; h=To:Cc:References:From:Date:In-Reply-To; b=Ai02S65JGJpZ11FKDoATtnBqVfUA0sW7CMMIyDMwpZeQUd1wB9bL6vhjwWXqqdA3j 9mDwUwMeO3jOxRxxYn2n5MZRFX2ewHd7o5CzLM+L3Pg+irzd6p58KxIdWlJdc8f4IJ 4025Nr2ShR0jQOfwcCIITOM2+rAVEKO92X0WbY2OoMVrszNpLrhUz06c/nb+p Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F035DAA.000074BB; Mon, 06 Jul 2020 19:21:46 +0200 To: "Murray S. Kucherawy" , Doug Foster Cc: IETF DMARC WG References: <159398558133.21061.9212076992920148901@ietfa.amsl.com> <005301d653ac$31469d40$93d3d7c0$@bayviewphysicians.com> From: Alessandro Vesely Message-ID: Date: Mon, 6 Jul 2020 19:21:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:21:50 -0000 On Mon 06/Jul/2020 18:49:11 +0200 Murray S. Kucherawy wrote: > On Mon, Jul 6, 2020 at 8:43 AM Doug Foster > wrote: > >> · The email administration then reviews the request and replies to >> user and MLM in one of three ways: >> > > This needs to be automatable, or it won't scale to very large operations. > I suspect there's virtually zero chance a GMail sized operation will staff > up to review requests given the size of their customer base. It can be automated by having logged-in users interact with a suitable server-side program. That approach can work for (small) mailbox providers which trust their users. That set seems to be close to the complement of the ones who can use ARC, doesn't it? > And once it's automated, there needs to be a strategy for dealing with > stale data (e.g., old lists nobody is using anymore), etc. Yes, it would be an improvement of the current subscription reminders —a time distributed database. Best Ale -- From nobody Mon Jul 6 10:30: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 6CBE83A1826 for ; Mon, 6 Jul 2020 10:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 pgAIEIZ5X28m for ; Mon, 6 Jul 2020 10:30:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 34FB43A1823 for ; Mon, 6 Jul 2020 10:30:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RMWY1EWOV4008IIN@mauve.mrochek.com> for dmarc@ietf.org; Mon, 6 Jul 2020 10:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1594056298; bh=3NPVpsuyPfpG2nSjUf+A0TIksVYxJLWrWMxzK2Qyl8Y=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=g1oh4Z6QfxOsB4H+XzAT9wJk42pMnhEV9um6JvCcWEMagjHOfEt0v2ApTfGRjn+oT e3Y7c0fylgC1QNhkFAoDQOLDcGR8j0BtHEkXd5b1IpMkeaCGsV0obUIZ3edH9jYDin /n0QeGTrmrIbqZi8jupUcmD58764u0MucVCOGejc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RMU0VINAGG0076ZY@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 6 Jul 2020 10:24:55 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: "Murray S. Kucherawy" , IETF DMARC WG Message-id: <01RMWY1DCD340076ZY@mauve.mrochek.com> Date: Mon, 06 Jul 2020 10:17:42 -0700 (PDT) In-reply-to: "Your message dated Mon, 06 Jul 2020 19:08:22 +0200" References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:30:04 -0000 > On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: > > On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: > > > >> For multipart messages, transformations may need to replace boundaries. > >> In that case, the "restricted patch" to undo the transformation may > >> require more data than it is convenient to store in a DKIM tag. >> > > > > Replace why? It might need to add its own, but it's easy to undo that. > Oops, I thought MLM generated boundaries anew. It seems that's not the case. Depends on the MLM and what it is doing. For example, boundary marker regeneration can happen if you're adding a header or a footer to a multipart message. > Still, the original Content-Type is difficult to reproduce exactly. You need > to know whether the boundary= parameter is written as a token or a > quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a > few bits, the info to undo the transformation (a reverse patch?) could be > stored in its own field, or even in an attachment. > Another difficulty, IIRC, is reordering of To:. This can simply be avoided. > > In order to be useful, this only needs to do what MLMs commonly do > > already. We don't need to cover the universe of possible futures right > > away. > Agreed. MLMs code has no lack of conditionals. Probably this technique can > address a class of mailing lists somewhat wider than the "no-changes" class, > without trying to cover even one half of /present/ MLM possibilities. Shall > say just enough to cover IETF mailing lists? The problem is that list software wasn't designed with the idea of keeping changes to an invertible/removable minimum in mind. So you're going to see many/most of the transformations this document deals with done in ways other than what the document describes. So in order to make use of this document you're basically talking about a fairly major rewrite. I think that's unlikely to happen. Ned From nobody Mon Jul 6 10:41:25 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 BFA1A3A00C0 for ; Mon, 6 Jul 2020 10:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OscLtKmy; dkim=pass (1536-bit key) header.d=taugh.com header.b=c2gSSPoj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lmrbBWJi3h0 for ; Mon, 6 Jul 2020 10:41:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5423A00B0 for ; Mon, 6 Jul 2020 10:41:20 -0700 (PDT) Received: (qmail 66599 invoked from network); 6 Jul 2020 17:41:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10424.5f03623e.k2007; i=johnl-iecc.com@submit.iecc.com; bh=UU2H3Ik7jCx+mtD+uC1udZ4sH4gAfrCPSN318CUND0A=; b=OscLtKmy5sjnoG6q8bE/BENvFY+oV4BRIbekcWrbJdKdYSZn7fze6F+48QZVzUVXvovti6HqrNgA1Nc6pw6J9jU6hRJbQ/tpYn+YA+b1rvjfQQmHhmD0iPEB3+rGJtELQb7F5QsPrEaclZ2q85NtPXuD1IttcAdmW7hI9Z0/oTAVHyGlGdKNStXsWXAwMWrawE2OK5y+gfOdO5j8PGV1qAewi4dPnBXReZVWPZ/xkvix2EEXhilSfJfc0fBlk5wk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10424.5f03623e.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=UU2H3Ik7jCx+mtD+uC1udZ4sH4gAfrCPSN318CUND0A=; b=c2gSSPojEaRbqPLYRmXAZzN81oyblYqs1b/kVup3uWXCfuP5NSPf+7K8IeVt11mtSzP/Hw1MTsqe4XMRSQPvF3aJUL2+nHEa18/6P1aPUTdPsBzytr4KgXpFc7UmYtjnzWMkTmp3jqzxIJ/f2QeKcOxXImWFPZ6qZyZmc2ISXniki5fDKr/f5s1GVwPFpjjwq2HzSYkcKSCwSQvFARwBwvLfeQ9tPIIhGMO05Qu0Kr1L/eEn9ZJ6B1nWDLp8BBKO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Jul 2020 17:41:17 -0000 Date: 6 Jul 2020 13:41:30 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: "IETF DMARC WG" In-Reply-To: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-54802323-1594057290=:14747" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:41:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-54802323-1594057290=:14747 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 6 Jul 2020, Dave Crocker wrote: >> I don't understand this scenario at all.  Why would I want to show my user >> a message forwarded by a spammer?  If the original sender wanted me to see >> it, she could have sent it to me directly, or through a legit mailing list. > > Perhaps, like some others, I'm not understanding this correctly, but I think > the proposal has nothing at all to do with what the recipient sees.  Rather, > I've understood this as an attempt to reverse additions made by a Mediator, > with the goal of validating the origination DKIM signature.  Presumably that > is so as to use the origination domain's reputation and even permit DMARC to > validate. But why would I want to do that? ARC lets a credible mediator say this message was OK before I munged it. This proposal lets a sleazy mediator say the same thing, with advice on how to verify mechanically. A sleazy mediator takes a message from Paypal and wraps a big blob of HTML spam around it that will display on top of the original message. I get the spammy message, look at the signatures and find yup, there's a real Paypal message inside the spam. What should I do with it? It's unlikely the Paypal message was intended for me. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-54802323-1594057290=:14747-- From nobody Mon Jul 6 10:49:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86B3A0400 for ; Mon, 6 Jul 2020 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q6igxCVp9r4 for ; Mon, 6 Jul 2020 10:49:05 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45943A0797 for ; Mon, 6 Jul 2020 10:49:02 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id v19so29618815qtq.10 for ; Mon, 06 Jul 2020 10:49:02 -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=2mpFW0KTjG/q8tPdkiEKoXsz3iWu1kBo+vJSLiFrKn8=; b=MkLyhqc5S/LguNa91zjUyuyi0YWOh09wWcYM+yF0ctvNUj4emjJ+x5acepofjdEIk9 f04YoX0PKWbKNAMrtZTd0jQ68XIMZQZdVD12xmAexoHdLZG2FGCsFAx6yRC2a5Et7tm3 MfCWJ5x2iv5QnXECme/xGvNGpDiycoUyCy42JpmPNE2cT1X7cyFiE/CG4QBUkrDBsE+Y 20VO/ZJf3w4N1SIZNAEaHkIm4rdudTRZl11apb29zKRxqnEKnzvaIXkNh/32bclwfsKM GmgtZMcK/86UuEAdkNeqHRnxfQWNE3Sxl7+/6wPkoWfAa7mkkftA2DS223fRhv7VJoom g9iQ== 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=2mpFW0KTjG/q8tPdkiEKoXsz3iWu1kBo+vJSLiFrKn8=; b=SuJedIMQq6V5mw/EGZvSpUyabarj23ncUy8Co23gDq77O9aWfmMOYk4547KBGokipK suhoSdnX9sy+MQ4s7yAUcohszcO13aLLCihdzj75sHBd/pZChG/j1FltSZ0EqRnfByF1 93FBE/+4yQElr8edp+s6aOZwmb8Wv8qLMqwbZXWd76GXSgt+uEGd6UFjTcUKnENz4tFM LaJgBvG6Kj29dc7GV2+6TTZQsAsLlGznpJC4v0/CKiWcElaRkCqRqNsnUhm8PNeUKcs/ S5qCS/0E7C4n5z0Gy1bOizxDV5VESw5qPMavGwvgJ0A2ak4OlX3RxyTzhXjL50WOr3T7 qMWw== X-Gm-Message-State: AOAM533KlTcd0cN3oxSDnIEfnUfoGyRdqw11AtEviUMAoxdt2QXeivhw 3w1Qqy4F8p6ctCeHZ4sHIeBIMUa0p5I= X-Google-Smtp-Source: ABdhPJwpDmNWhV7HEiJOTKP90Wmkrt04/boVkFsZnf0V+iHp1s1YznahzDFsgDLTafDrrBHt7uzFtA== X-Received: by 2002:ac8:260b:: with SMTP id u11mr51137172qtu.380.1594057741275; Mon, 06 Jul 2020 10:49:01 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:4855:e08a:7443:c16d? ([2600:1700:a3a0:4c80:4855:e08a:7443:c16d]) by smtp.gmail.com with ESMTPSA id u20sm23681944qtj.39.2020.07.06.10.49.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 10:49:00 -0700 (PDT) To: John R Levine Cc: IETF DMARC WG References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> From: Dave Crocker Message-ID: Date: Mon, 6 Jul 2020 10:48:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:49:06 -0000 On 7/6/2020 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >> Perhaps, like some others, I'm not understanding this correctly, but >> I think the proposal has nothing at all to do with what the recipient >> sees.  Rather, I've understood this as an attempt to reverse >> additions made by a Mediator, with the goal of validating the >> origination DKIM signature.  Presumably that is so as to use the >> origination domain's reputation and even permit DMARC to validate. > > But why would I want to do that? I wasn't advocating or criticizing.  Just trying to synchronize that nature and purpose of the task. > ARC lets a credible mediator say this message was OK before I munged it. That's a very different trust model from allowing a means to directly vet the original signature. > This proposal lets a sleazy mediator say the same thing, with advice > on how to verify mechanically. Actually, it doesn't. The sleazy mediator cannot somehow forge an originator's signature so it validates. > A sleazy mediator takes a message from Paypal and wraps a big blob of > HTML spam around it that will display on top of the original message. > I get the spammy message, look at the signatures and find yup, there's > a real Paypal message inside the spam.  What should I do with it?  > It's unlikely the Paypal message was intended for me. A worthy scenario to worry about, but completely different from the nature of what ARC does and its likely benefits and weaknesses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 6 10:52: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 AAF533A059F for ; Mon, 6 Jul 2020 10:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n-2kfpGHn7X for ; Mon, 6 Jul 2020 10:52:01 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7898A3A0593 for ; Mon, 6 Jul 2020 10:52:01 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 80so35645851qko.7 for ; Mon, 06 Jul 2020 10:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=nqfJNvUq58g2uBepVy3o63ouMdpC5y/GXNuyMW8N4EM=; b=BP4a5epBXQLPszWjI3Das8tkJB0YQC98Yvl1FYEyRlq6ITmQ+CCBhbboDOZYfPMEMa K1AxrLy4+/RtgEUBLhq8PM9aOKrYqnnZdKpmenWxHY3UKrrrb3Zo9+bscQKTBY91S6qE USmuLh9hB6VslX7ymjOCBgwDvygQLd5aCbGWJeFsn8sGSF3d4aHQgxEJdqi8r9S2/o0t 7kHLut3prRrsUmoQ2Agfn/GtV1XJt/MY7l5uUZfrP1Mvt6YVmPxd2uiDqin6mz5wTpMB 56xUn0ScPagszTYxLQwO1rApdeCQ8ysKt3E36VVAt86cRHwiyMjyNmz7w+ww2UfJU0GB UWmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nqfJNvUq58g2uBepVy3o63ouMdpC5y/GXNuyMW8N4EM=; b=ILwmMArbKAVmQAoEczZz9Nf3UZQPTfR5wKW5TY88WjTZrROR20uRks+T7unZYOmIDD NbH5jk34kSNF/U4VG5sEpUh9IWai5q0XX3jktLrG6PeHw+X+KL1FzDfKMfjNSI3n0HcI 3AhZDlsrVUsYEJ6GMZ7cTWJfFZl49ED+g6gHHuxld1hRakjz7OErsaT5WRUt4aMppMEJ 174ziM5+WGUsZBFeI7QNnXt7I784nh1z5sKkvZcE2DKvV99A9vnc224A2zOAFawch+lx ai4Klj1hdSN3r02rRE7Zef/GJLIQOOzFXyAjfjrZ/lp6IzC4f7qnOiB8xjCxVr7wUAON 5/Sg== X-Gm-Message-State: AOAM533AA7KEsJk6eoV7sAHE/Te5PUSH0qwb8cAPUef8LXWdxlvFW3p7 GbOqBTTfcKAMTeev8k4j5M009UQ3RzY= X-Google-Smtp-Source: ABdhPJyd/UDQ0PThk+ermPs110CnnYmHFM8WOwtbMDpUx1Y4qTv7tMYbyAgfQis04+pfE2j1ooxIbw== X-Received: by 2002:a37:9b8b:: with SMTP id d133mr48361656qke.276.1594057920338; Mon, 06 Jul 2020 10:52:00 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:4855:e08a:7443:c16d? ([2600:1700:a3a0:4c80:4855:e08a:7443:c16d]) by smtp.gmail.com with ESMTPSA id t9sm21098165qke.68.2020.07.06.10.51.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 10:51:59 -0700 (PDT) To: IETF DMARC WG References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> From: Dave Crocker Message-ID: Date: Mon, 6 Jul 2020 10:51:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 17:52:03 -0000 It occurs to me that discussion about how this latest proposal might or might not have similarities to ARC should encourage everyone making a proposal to add commentary that gives a full sense of end-to-end use. That is, distinguish the details of how the specific mechanism works, from how it integrates into end-to-end service.  How is it expected to get used and why is that believed to be practical (as well as useful?) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 6 11:18: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 F29703A077D for ; Mon, 6 Jul 2020 11:18:39 -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 (1536-bit key) header.d=iecc.com header.b=IQN5mV+n; dkim=pass (1536-bit key) header.d=taugh.com header.b=BeNQ3e4f Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBFbTCtWiwDM for ; Mon, 6 Jul 2020 11:18:38 -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 59CA63A0776 for ; Mon, 6 Jul 2020 11:18:38 -0700 (PDT) Received: (qmail 84701 invoked from network); 6 Jul 2020 18:18:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14ada.5f036afa.k2007; bh=2ej2PZ0h696VrnyRGpHZYodMWf5jhGlyhVak35vC5oQ=; b=IQN5mV+nzwSO7TzSHywxCHG6mFoL4AOdINyrRblhHNi9u1Feze6swykcnVe+FKqGx7uZLhfI/ATA79XwZRSrrXw90Z6zIZFzo4pBiQ1LRJwN+tivNvlstlHD2l5folRoEnapLVU5z9sW4YvJ1vGoAmzl4eR0K+3X0FsCiWca6eiqdDVfVGLdxGgqZXPZq/BgiO8SNvhRYwGv00QU4Me7ZigQb1tIFbTQ6jZdChKk9BBs18biIj+wnJo4eQz/ZoZQ 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=14ada.5f036afa.k2007; bh=2ej2PZ0h696VrnyRGpHZYodMWf5jhGlyhVak35vC5oQ=; b=BeNQ3e4flgOe1B0HrAdI7NBdbOVgIjJ+FkeccJ1sN9odHQ6lYSkX8OPyh7sl5SkcHADBFv6aNl1hBp87/7pfiTlDE/DegYrIkyPyS7qkb7DzJvQIUGqlXcWpM/z3TRFS5dW0VGd1buGLuMTyPg3TsSL2XsIVWceHS4Z3Xn7WkfYCTybpL8smT4t7GfCeGNjLzLbZUGsIn3La/VafbVq25Hf+US5GNf8f75mBz1yJdTzFUpxKyF39K2KxKQd131S7 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Jul 2020 18:18:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 79A001C5D093; Mon, 6 Jul 2020 14:18:47 -0400 (EDT) Date: 6 Jul 2020 14:18:47 -0400 Message-Id: <20200706181847.79A001C5D093@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:18:40 -0000 In article you write: > >It occurs to me that discussion about how this latest proposal might or >might not have similarities to ARC should encourage everyone making a >proposal to add commentary that gives a full sense of end-to-end use. Agreed. Hence my point that this is much harder to integrate into mailing lists, and the useful signal you get, that you started with a valid message from some X, is the same. R's, John From nobody Mon Jul 6 11:28: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 8FD103A07C4 for ; Mon, 6 Jul 2020 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_hb8KkYMffM for ; Mon, 6 Jul 2020 11:28:41 -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 418573A07B7 for ; Mon, 6 Jul 2020 11:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594060118; bh=Vu/cz9lo5AsMhu4ZIiqZtEJ2OjKDQUbOpO71a7PxmiI=; l=2560; h=To:Cc:References:From:Date:In-Reply-To; b=B544FxE82hndG3ckmjOF3Shx2I+YW+wrgbIQ5RduqFlESfwyU/GtVJa9e04su2Bmq XisF20om8yxfrk5T9YPsABPv1fO7M6nusY9GeGK+FbiMrHhP7annRVQ068952vpGT0 fjsOeDRC8Bz/eDPH+1jB0TmbrtY4nx8c0NA5yyZwRs0iN0R4Ca6WqeURvlKDF Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005F036D56.00007B98; Mon, 06 Jul 2020 20:28:38 +0200 To: ned+dmarc@mrochek.com Cc: IETF DMARC WG , "Murray S. Kucherawy" References: <20200706024251.8A4A41C598F8@ary.qy> <70d4a6b5-23b3-be47-6397-34390d10920e@bluepopcorn.net> <3dfc7ac0-c5fa-8d92-75d1-1629134a5fae@tana.it> <01RMWY1DCD340076ZY@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <65f82beb-c5d1-f654-ed9d-09001b6233db@tana.it> Date: Mon, 6 Jul 2020 20:28:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <01RMWY1DCD340076ZY@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:28:43 -0000 On Mon 06/Jul/2020 19:17:42 +0200 ned+dmarc wrote: >> On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: >>> On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: >>> >>>> For multipart messages, transformations may need to replace boundaries. >>>> In that case, the "restricted patch" to undo the transformation may >>>> require more data than it is convenient to store in a DKIM tag. >> >>> >>> Replace why?  It might need to add its own, but it's easy to undo that. >>> >> >> Oops, I thought MLM generated boundaries anew.  It seems that's not the case. > > Depends on the MLM and what it is doing. For example, boundary marker > regeneration can happen if you're adding a header or a footer to a multipart > message. So that kind is going to go among forbidden transformations. >> Still, the original Content-Type is difficult to reproduce exactly.  You need >> to know whether the boundary= parameter is written as a token or a >> quoted-string, and, if not c=relaxed, spaces and newlines.  If longer than a >> few bits, the info to undo the transformation (a reverse patch?) could be >> stored in its own field, or even in an attachment. >> >> Another difficulty, IIRC, is reordering of To:.  This can simply be avoided. >> >>> In order to be useful, this only needs to do what MLMs commonly do >>> already.  We don't need to cover the universe of possible futures right >>> away. >> >> Agreed.  MLMs code has no lack of conditionals.  Probably this technique can >> address a class of mailing lists somewhat wider than the "no-changes" class, >> without trying to cover even one half of /present/ MLM possibilities.  Shall >> say just enough to cover IETF mailing lists? > > The problem is that list software wasn't designed with the idea of keeping > changes to an invertible/removable minimum in mind. So you're going to see > many/most of the transformations this document deals with done in ways other > than what the document describes. So in order to make use of this document > you're basically talking about a fairly major rewrite. Yet, setting no-changes does guarantee no breakage occurs. Hm... does it? I didn't carry out thorough tests. Looking at my own messages to this list, which are signed with l=, I see my DKIM signatures are broken intermittently. It would be enough to turn off base64 encoding. It is no major rewrite... > I think that's unlikely to happen. Which is probably why this draft was let expire. Best Ale -- From nobody Mon Jul 6 11:33:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FEF3A07C7 for ; Mon, 6 Jul 2020 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay6aRfcomkcq for ; Mon, 6 Jul 2020 11:33:21 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244F23A07C5 for ; Mon, 6 Jul 2020 11:33:21 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:6969:d55:4d3d:a50b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 066IXJar020508 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 6 Jul 2020 11:33:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594060400; bh=ROy69cHo3wuQuIaHl06qm2N0fh2mfYdUaeDgPnUS/pI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DMM3l4JdKaI7aF8zw8WLV1jVhrDIMoK8ITlPhzIOoOA4t4M6IUV/vaK29zhDxFOOv dax/tKyi0BmQ6ZqCQiP/VQLuPBQEETWb11XvITXc+rt3z6qIw1ZkjBNWcsXv5rM+sL bdBffar7A8ahfipsDQVpa3rHTvjXsLdtPQmgQliY= To: dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Mon, 6 Jul 2020 11:33:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:33:23 -0000 On 7/6/20 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >>> I don't understand this scenario at all.=C2=A0 Why would I want to sh= ow >>> my user a message forwarded by a spammer?=C2=A0 If the original sende= r >>> wanted me to see it, she could have sent it to me directly, or >>> through a legit mailing list.=20 >> >> Perhaps, like some others, I'm not understanding this correctly, but >> I think the proposal has nothing at all to do with what the recipient >> sees.=C2=A0 Rather, I've understood this as an attempt to reverse >> additions made by a Mediator, with the goal of validating the >> origination DKIM signature.=C2=A0 Presumably that is so as to use the >> origination domain's reputation and even permit DMARC to validate. > > But why would I want to do that?=C2=A0 ARC lets a credible mediator say= > this message was OK before I munged it.=C2=A0 This proposal lets a slea= zy > mediator say the same thing, with advice on how to verify mechanically.= Your use of=C2=A0 "credible mediator" and "sleazy mediator" emphasizes th= at we're depending on the mediator behaving responsibly. Given that's the case, why not just expect a responsible mediator to verify the DKIM signature (or maybe SPF) on the incoming message, check its alignment with the From: domain, then make whatever modifications it wants to make, then re-sign the message with the mediator's DKIM signature containing a tag that says it did all of the above? Yes, this is a "get out of DMARC free" card for mediators to use. But we're already dependent on being able to distinguish between credible mediators and sleazy mediators, and this tag simply says, "if you trust that I'm a credible mediator and this message has a valid signature from me, you should accept the message even if my signature doesn't align with the From: domain." This gets us out of the business of trying to define what acceptable and unacceptable transformations are. If the transformation was done by a credible mediator, it's acceptable. Many (most?) mediators do not currently require authentication (+alignment) on incoming messages. They could continue to forward the unauthenticated messages, but without the new tag. -Jim P.S. I'm still not sold on the value of From: domain alignment, but left that in here to avoid conflating too many different ideas. From nobody Mon Jul 6 15:41:25 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 E2DB53A0BA9 for ; Mon, 6 Jul 2020 15:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PP_MIME_FAKE_ASCII_TEXT=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=bku89VKa; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=Y5RuMzXz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHD4gdQvT9WA for ; Mon, 6 Jul 2020 15:41:22 -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 081333A0BA8 for ; Mon, 6 Jul 2020 15:41:21 -0700 (PDT) Received: (qmail 1954 invoked by uid 100); 6 Jul 2020 22:41:19 -0000 Date: 6 Jul 2020 22:41:18 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=796.5f03a88e.k2007; i=news@user.iecc.com; bh=MjXZVljbys7CL0Wej/5JcA94xgDofavoMLyneYZiXEE=; b=bku89VKaL4HAFv5sMMxgPnaJe8UU3xKusUmHoiEWmYhTptYOFwwbNOxHI+zkUv24DsVk4pnOrpdTo/ReIVMK+oy+uJENby2hq+kmVMwTfz93vdwr3Xuz/+ibC4/A+ikmM4XxebI7C3O7pQ51hiAad3Xlw/Cc6EtlwSjkuAR23tgkQZZd4JbKehzbDdjgqyBpPC/tVdLC3eTC62StPoLSe6WqddjgEiIgJ6XSGdlJBnGq5sMoD4cTnoIaHy7sqJmV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=796.5f03a88e.k2007; olt=news@user.iecc.com; bh=MjXZVljbys7CL0Wej/5JcA94xgDofavoMLyneYZiXEE=; b=Y5RuMzXzxlUMdzI8s5QFV0+eroTRTkMUY6wsVvIefIHGhoX+GEI7bFonMiTtCe9Z3lwk++p7ggqY/1NV6FIz5gL4sm7yAfD503T66L1MmvbBjGLe6QmSQ2iSef593b3Ym5y0ZTdFXDwE87eya8mugxV8LjyvEzvnfAxVKR1gdDMHojvXlVBvzi67DnA4pdCWEPf3rbGItjeUDuY6x1lEukxrALYShMNSQXJMIBZ5uVrrBsyzCLJXKVZ3qOVFiso9 Organization: Taughannock Networks References: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> In-Reply-To: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 22:41:24 -0000 In article , Jim Fenton wrote: >Your use of  "credible mediator" and "sleazy mediator" emphasizes that >we're depending on the mediator behaving responsibly. Given that's the >case, why not just expect a responsible mediator to verify the DKIM >signature (or maybe SPF) on the incoming message, check its alignment >with the From: domain, then make whatever modifications it wants to >make, then re-sign the message with the mediator's DKIM signature >containing a tag that says it did all of the above? According to people I've talked to about ARC, because mailing lists don't do that. One of the things that makes it plausible that lists might implement ARC is that it doesn't ask for any changes in the internal operation of the list, just slap an ARC signature on the end. It's also useful for other kinds of forwarding that don't change anything but since they're forwards, SPF fails. This proposal makes lists sort through all of the changes they make and try to figure out which ones match a tag and which ones don't. That is surprisingly hard, e.g., I found that when you have multipart/alternative and add a message header, it edits the header text into both of the alternative versions. Good luck unscrambling that. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 6 16:27: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 8EDFA3A0BEF for ; Mon, 6 Jul 2020 16:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi4yXMZByOF9 for ; Mon, 6 Jul 2020 16:27:43 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248A83A0BED for ; Mon, 6 Jul 2020 16:27:43 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:7d61:a71b:7455:76ee]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 066NRfk3024396 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 6 Jul 2020 16:27:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594078062; bh=/jlC653ptFIo7GS4qm+ViU5HhEaR782YIvsihcRp/kc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q5YsL3BLqZGZSs3YHOepsPVK58ZhYvRLESGsStVPKdcYYOjz/yG/Lu+2+LChbLbra 0EY/wvfGmDpcPb7wm9APy+djSINm9xwF8GeBvoBrT+8dQercLat0NHFieQzhoxDToD T1MR4zPKGpHXqiga7EAHW2JFfNekKusnYNXBkPOA= To: dmarc@ietf.org References: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Mon, 6 Jul 2020 16:27:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 23:27:45 -0000 On 7/6/20 3:41 PM, John Levine wrote: > In article , > Jim Fenton wrote: >> Your use of=C3=82=C2=A0 "credible mediator" and "sleazy mediator" emph= asizes that >> we're depending on the mediator behaving responsibly. Given that's the= >> case, why not just expect a responsible mediator to verify the DKIM >> signature (or maybe SPF) on the incoming message, check its alignment >> with the From: domain, then make whatever modifications it wants to >> make, then re-sign the message with the mediator's DKIM signature >> containing a tag that says it did all of the above? > According to people I've talked to about ARC, because mailing lists > don't do that. One of the things that makes it plausible that lists > might implement ARC is that it doesn't ask for any changes in the > internal operation of the list, just slap an ARC signature on the end. "Just slap an ARC signature on the end" greatly understates the complexity of ARC. > > It's also useful for other kinds of forwarding that don't change > anything but since they're forwards, SPF fails. If a mediator can add an ARC signature, they can add a DKIM signature. All this would add to DKIM signing is an additional tag indicating whether the message received by the mediator had an aligned signature or SPF. > > This proposal makes lists sort through all of the changes they make > and try to figure out which ones match a tag and which ones don't. > That is surprisingly hard, e.g., I found that when you have > multipart/alternative and add a message header, it edits the header > text into both of the alternative versions. Good luck unscrambling tha= t. Perhaps I didn't explain this clearly enough. Mediators don't need to sort through changes at all. All they do is check to see if the incoming message had an aligned signature or SPF, and include a tag in the DKIM signature that they apply indicating that. Receiving domains that intend to enforce DMARC would need to verify the DKIM signature of the mediator, and if the signature came from a credible mediator and the tag is present, accept the message as though it had an aligned signature. -Jim From nobody Mon Jul 6 17:57: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 E2BB03A07EE for ; Mon, 6 Jul 2020 17:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 456Ylq2MgS-3 for ; Mon, 6 Jul 2020 17:57:02 -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 8E93F3A07ED for ; Mon, 6 Jul 2020 17:57:02 -0700 (PDT) X-ASG-Debug-ID: 1594083407-11fa313a10319910001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id KWoI7Yn6BzMj3CBD (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 06 Jul 2020 20:56:47 -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=kZuaUj/Zk0ydOMM7zzKEZdAGgWCUhhVYJkdkZ/VrosU=; b=eyGb5K8R/C4vDjATRgGEJXca277mHjdj4C1byglFX+i9HqVXnqeav0hemUTPQLuqH tG5ZAjKOYzr0xki3w06Q1p5bYCaZzXQyliB57WCCmB9llVdxnt/X1V29Znwk8HWQ2 DHmEcb6e9slTWlMtlfOvLbt7dvqh1lEF99B6GEUZU= From: "Douglas E. Foster" To: Date: Tue, 07 Jul 2020 00:56:39 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt Reply-To: fosterd@bayviewphysicians.com Message-ID: <0dd5f575c0e944da832b73a713abba34@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=7c5d3c434dbf461faf6d719bc89151e3 In-Reply-To: References: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> X-Exim-Id: 0dd5f575c0e944da832b73a713abba34 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594083407 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: 2795 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.83025 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 00:57:04 -0000 This is a multipart message in MIME format. --7c5d3c434dbf461faf6d719bc89151e3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This surprises me: This proposal makes lists sort through all of the changes they make and try to figure out which ones match a tag and which ones don't. That is surprisingly hard, e.g., I found that when you have multipart/alternative and add a message header, it edits the header text into both of the alternative versions. Good luck unscrambling that. I expected that the tag would be a function of the algorithm used by the ML= M or forwarder, rather than the particulars of each message. In a face-to= -face conversation between MLM and recipient email administrator, the algor= ithm would be the topic of conversation, and would be the determinant of wh= ether trust was established or not. At the same time, you raise an important point: The tag will be most usef= ul if it will be reliably correct, but less useful if it is prone to errors= . In practice, the tag is likely to be fraught with human errors which int= roduce another layer of trust confusion: What do I do when the tag and th= e reversable content of the document are inconsistent with each other? We = have a lot of those problems already. DF --7c5d3c434dbf461faf6d719bc89151e3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
This surprises me:=

This proposal makes = lists sort through all of the changes they make
and try to figure out which ones match a tag and which ones don= 't.
That is surprisingly hard, e.g.,= I found that when you have
multipar= t/alternative and add a message header, it edits the header
text into both of the alternative versions. Good lu= ck unscrambling that.

I e= xpected that the tag would be a function of the algorithm used by the MLM o= r forwarder, rather than the particulars of each message.   In a face-= to-face conversation between MLM and recipient email administrator, the alg= orithm would be the topic of conversation, and would be the determinant of = whether trust was established or not.


At the same ti= me, you raise an important point:   The tag will be most useful if it = will be reliably correct, but less useful if it is prone to errors.  I= n practice, the tag is likely to be fraught with human errors which introdu= ce another layer of trust confusion:   What do I do when the tag and t= he reversable content of the document are inconsistent with each other? &nb= sp;We have a lot of those problems already.

DF



--7c5d3c434dbf461faf6d719bc89151e3-- From nobody Mon Jul 6 18:15:26 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 90FEE3A0813 for ; Mon, 6 Jul 2020 18:15:24 -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 jQShdkpxKm7g for ; Mon, 6 Jul 2020 18:15:22 -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 9DE943A0807 for ; Mon, 6 Jul 2020 18:15:21 -0700 (PDT) X-ASG-Debug-ID: 1594084520-11fa313a10319c00001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id BFMgacxhf7FPhDGW (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 06 Jul 2020 21:15:20 -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=oP+i1G2oeb3f4VX6sG+9MiaPr/Y7N8Srlg9i6VGlHfQ=; b=HEBCsP7PJ09D5ypku7lPHndEDlS5rroAnA3/WU5JCQKIo0z4mhSn9Qia9Z0bJS+WT 8ynZjC1yrz0BTDEdEurrpuqLPUqP6dYAiHAQZDOz1P3GWcpMBA7bPlE/O4ubpEHww jAJq8ena/QUzlQlhSR60nP3HgXybbysYfK9b/BTYI= From: "Douglas E. Foster" To: "Jim Fenton" , Date: Tue, 07 Jul 2020 01:15:12 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt Reply-To: fosterd@bayviewphysicians.com Message-ID: <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ab7e97ed78c24beea95b72c9df357c18 In-Reply-To: References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> X-Exim-Id: 3129f12e02434273915ed6f91a998122 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594084520 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: 10477 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.83025 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:15:25 -0000 This is a multipart message in MIME format. --ab7e97ed78c24beea95b72c9df357c18 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable About discarding From alignment: DMARC has been sold to big corporations as essential to defending their bra= nd identity. In response, they pay serious money to keep Valimail and it= s competitors in business. I see no way that we can put forward a proposa= l that will put Valimail and its friends out of business, while incurring t= he wrath of C-Level executives and legal teams at Fortune 500 companies. = Not that I have any of those people on speed dial, so maybe someone can pro= ve me wrong. But I have been surprised that one of the DMARC reporting co= mpanies is not listening to this part of the discussion and having alarm be= lls. About credible mediators: You are right that if an inbound email gateway believes a Mediator is credi= ble, then all that is necessary is for the Mediator to prove his own identi= ty. But what is the mechanism by which a Mediator obtains the trust of t= he email gateway? And by what mechanism does the Mediator know that the e= mail gateway has determined it to be credible? One option is to provide so much information in the email message that the = email gateway will grant trust on the fly. Murray's approach has appeal = because, especially when coupled with appropriate LIST-* and RESENT-* heade= rs, it provides all of the information needed for a decision to be made. = ARC has less appeal because it provides just enough information for the ema= il gateway to detect that something deliberate was done, but not much more.= Researching the credibility of the list would need to occur out-of-band = using LIST-* headers as a starting point. But there is a larger problem. = Even after the gateway decides the Mediator is credible, the Mediator is = ignorant of the gateway's decision, so the Mediator is unable to take advan= tage of that decision. The other option is for the MLM and the Email gateway administration to neg= otiate credibility in advance, with the subscriber acting as sponsor for th= e discussion. DF ---------------------------------------- From: Jim Fenton Sent: 7/6/20 2:33 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy= -dkim-transform-01.txt On 7/6/20 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >>> I don't understand this scenario at all. Why would I want to show >>> my user a message forwarded by a spammer? If the original sender >>> wanted me to see it, she could have sent it to me directly, or >>> through a legit mailing list. >> >> Perhaps, like some others, I'm not understanding this correctly, but >> I think the proposal has nothing at all to do with what the recipient >> sees. Rather, I've understood this as an attempt to reverse >> additions made by a Mediator, with the goal of validating the >> origination DKIM signature. Presumably that is so as to use the >> origination domain's reputation and even permit DMARC to validate. > > But why would I want to do that? ARC lets a credible mediator say > this message was OK before I munged it. This proposal lets a sleazy > mediator say the same thing, with advice on how to verify mechanically. Your use of "credible mediator" and "sleazy mediator" emphasizes that we're depending on the mediator behaving responsibly. Given that's the case, why not just expect a responsible mediator to verify the DKIM signature (or maybe SPF) on the incoming message, check its alignment with the From: domain, then make whatever modifications it wants to make, then re-sign the message with the mediator's DKIM signature containing a tag that says it did all of the above? Yes, this is a "get out of DMARC free" card for mediators to use. But we're already dependent on being able to distinguish between credible mediators and sleazy mediators, and this tag simply says, "if you trust that I'm a credible mediator and this message has a valid signature from me, you should accept the message even if my signature doesn't align with the From: domain." This gets us out of the business of trying to define what acceptable and unacceptable transformations are. If the transformation was done by a credible mediator, it's acceptable. Many (most?) mediators do not currently require authentication (+alignment) on incoming messages. They could continue to forward the unauthenticated messages, but without the new tag. -Jim P.S. I'm still not sold on the value of From: domain alignment, but left that in here to avoid conflating too many different ideas. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --ab7e97ed78c24beea95b72c9df357c18 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
About discarding F= rom alignment:
DMARC has been sold to big corporations as essenti= al to defending their brand identity.    In response, they pay se= rious money to keep Valimail and its competitors in business.   I see = no way that we can put forward a proposal that will put Valimail and its fr= iends out of business, while incurring the wrath of C-Level executives and = legal teams at Fortune 500 companies.   Not that I have any of those p= eople on speed dial, so maybe someone can prove me wrong.   But I have= been surprised that one of the DMARC reporting companies is not listening = to this part of the discussion and having alarm bells.

=
About credible mediators:
You are right that if an inbound e= mail gateway believes a Mediator is credible, then all that is necessary is= for the Mediator to prove his own identity.    But what is the m= echanism by which a Mediator obtains the trust of the email gateway?  = And by what mechanism does the Mediator know that the email gateway has de= termined it to be credible?

One option is to provi= de so much information in the email message that the email gateway will gra= nt trust on the fly.    Murray's approach has appeal because, esp= ecially when coupled with appropriate LIST-* and RESENT-* headers, it provi= des all of the information needed for a decision to be made.   ARC has= less appeal because it provides just enough information for the email gate= way to detect that something deliberate was done, but not much more.  = Researching the credibility of the list would need to occur out-of-band us= ing LIST-* headers as a starting point.   But there is a larger proble= m.   Even after the gateway decides the Mediator is credible, the Medi= ator is ignorant of the gateway's decision, so the Mediator is unable to ta= ke advantage of that decision.

The other option is= for the MLM and the Email gateway administration to negotiate credibility = in advance, with the subscriber acting as sponsor for the discussion.
=

DF

From: Jim Fenton <fenton@bluepopcorn.net>Sent: 7/6/20 2:33 PM
To: dmarc@ietf.o= rg
Subject: Re: [dmarc-ietf] Fwd: New Version Notificat= ion for draft-kucherawy-dkim-transform-01.txt
On 7/6/20 10= :41 AM, John R Levine wrote:
> On Mon, 6 Jul 2020, Dave Crocke= r wrote:
>>> I don't understand this scenario at all. &n= bsp;Why would I want to show
>>> my user a message forwa= rded by a spammer?  If the original sender
>>> want= ed me to see it, she could have sent it to me directly, or
>&g= t;> through a legit mailing list.
>>
>> = Perhaps, like some others, I'm not understanding this correctly, but
<= div>>> I think the proposal has nothing at all to do with what the re= cipient
>> sees.  Rather, I've understood this as an a= ttempt to reverse
>> additions made by a Mediator, with the= goal of validating the
>> origination DKIM signature. &nbs= p;Presumably that is so as to use the
>> origination domain= 's reputation and even permit DMARC to validate.
>
&= gt; But why would I want to do that?  ARC lets a credible mediator say=
> this message was OK before I munged it.  This proposal= lets a sleazy
> mediator say the same thing, with advice on h= ow to verify mechanically.


Your use= of  "credible mediator" and "sleazy mediator" emphasizes that
we're depending on the mediator behaving responsibly. Given that's the
case, why not just expect a responsible mediator to verify the DKI= M
signature (or maybe SPF) on the incoming message, check its ali= gnment
with the From: domain, then make whatever modifications it= wants to
make, then re-sign the message with the mediator's DKIM= signature
containing a tag that says it did all of the above?

Yes, this is a "get out of DMARC free" card for medi= ators to use. But
we're already dependent on being able to distin= guish between credible
mediators and sleazy mediators, and this t= ag simply says, "if you trust
that I'm a credible mediator and th= is message has a valid signature from
me, you should accept the m= essage even if my signature doesn't align
with the From: domain."=

This gets us out of the business of trying to def= ine what acceptable and
unacceptable transformations are. If the = transformation was done by a
credible mediator, it's acceptable.<= /div>

Many (most?) mediators do not currently require au= thentication
(+alignment) on incoming messages. They could contin= ue to forward the
unauthenticated messages, but without the new t= ag.

-Jim

P.S. I'm still n= ot sold on the value of From: domain alignment, but left
that in = here to avoid conflating too many different ideas.



____________________________________________= ___
dmarc mailing list
dmarc@ietf.org
--ab7e97ed78c24beea95b72c9df357c18-- From nobody Mon Jul 6 18:20: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 43E223A0833 for ; Mon, 6 Jul 2020 18:20:38 -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 (1536-bit key) header.d=iecc.com header.b=ervM5ZSX; dkim=pass (1536-bit key) header.d=taugh.com header.b=wnPFN++4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrnJMyMwZ4kO for ; Mon, 6 Jul 2020 18:20:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FA93A082F for ; Mon, 6 Jul 2020 18:20:36 -0700 (PDT) Received: (qmail 76613 invoked from network); 7 Jul 2020 01:20:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12b40.5f03cde2.k2007; bh=8xqzq+dCsb+gvg62N3NYDDtUxwk2OH0w74cTp/kz5TE=; b=ervM5ZSXqk+2tB0v+EIt/AsPX/HGAFl4OcmlBxusILF/nl7jNSw0Nhtgb9T7cCmZq3y/tvtbpDuQcbY0okrQyzMFd05rFRSuhHmP35koJxRPi7LhmrHiLYFHRZJlFh1TVO7xIbb6tsU+HXZfspz0jpLvfhoZ4tkZ4yrFuQ7oXHk3Ntz53rG1BgngCxlOzxqDORDN7k73UdjKzvgaHYjyYR0ZSeqgRIv/UyLKCXMh/11myi5Wk1SmTm6SjvKGgIlZ 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=12b40.5f03cde2.k2007; bh=8xqzq+dCsb+gvg62N3NYDDtUxwk2OH0w74cTp/kz5TE=; b=wnPFN++4NIvARhiasnzmPrddTPsQVbMqCiLT0DdzrNXSriGl4+kDrfkbc3LcxTF6zgUbZb7SE6bVye+WpcjEaxDjZYKyMqhdSkd9H4ATeqHJB4YrNj0QuRUb//7BsJnHGEe12KT4nBceWXuqkDPUfV7Rdd+1fcShk7u/WSBjqyNeViI6em2hL5zazPZ/cm137REDS/P4ikFdoRFulIHigx5OY3HFhYwEmxE8gckkBDO/70S66Jsx2yzjKBvox3um Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 Jul 2020 01:20:33 -0000 Received: by ary.qy (Postfix, from userid 501) id A0F5A1C5F7E7; Mon, 6 Jul 2020 21:20:47 -0400 (EDT) Date: 6 Jul 2020 21:20:47 -0400 Message-Id: <20200707012047.A0F5A1C5F7E7@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <0dd5f575c0e944da832b73a713abba34@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:20:38 -0000 In article <0dd5f575c0e944da832b73a713abba34@bayviewphysicians.com> you write: >-=-=-=-=-=- > >This surprises me: > >This proposal makes lists sort through all of the changes they make >and try to figure out which ones match a tag and which ones don't. >That is surprisingly hard, e.g., I found that when you have >multipart/alternative and add a message header, it edits the header >text into both of the alternative versions. Good luck unscrambling that. > >I expected that the tag would be a function of the algorithm used by the MLM or forwarder, rather than the >particulars of each message. You would be mistaken. List management software has a vast array of options for message handling. The changes to each message depend on both how the particular list is configured and what's in the message. R's, John From nobody Mon Jul 6 18:30: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 BAB053A0849 for ; Mon, 6 Jul 2020 18:30:05 -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 (1536-bit key) header.d=iecc.com header.b=WsUJE9cK; dkim=pass (1536-bit key) header.d=taugh.com header.b=aoBURSbK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K2-qtgfb-Pj for ; Mon, 6 Jul 2020 18:30:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C083A0848 for ; Mon, 6 Jul 2020 18:30:03 -0700 (PDT) Received: (qmail 81127 invoked from network); 7 Jul 2020 01:30:03 -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=13ce4.5f03d01b.k2007; bh=0VxuQV6D4GYmp0pZ+UPHi4tG6h5DSUQ4WjYxcS6sLn4=; b=WsUJE9cK7rNuvElUHxFJZbskUrG1VjmDzKfi4L9sjvbQIxsSfSjJxBTxrZ7oXmHq3+sHkoatDPtCj2QeK/XwtH1/DzaYMaimuF/2b6KSO6HdbmDELX2KyRgp1AfN6xZzW6dDM9jMDYnkJXC25+xA+zNE5MiOp9V+ssDExg+mDxim0IH+id1q2QYpwicckubZOSiQaTrgIlc8cFGA/cRARMbtdCQjjsIrMV4iUr7IgHh6C/AdCix7HdiyR7atjnLP 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=13ce4.5f03d01b.k2007; bh=0VxuQV6D4GYmp0pZ+UPHi4tG6h5DSUQ4WjYxcS6sLn4=; b=aoBURSbKdn0ATFDwDJ217jc48thgdmlyEmJHCsy+pa3UnngncrfEO+J85LJYYFLSQ98qGz7Cw/E1raytZTkcKVqB2lB5yNzKky4jAkRZ0r/C8XY7DaIUN7kMfdqImlEKZ2Qo5B53CQN87HrzsHjfpSbZkoyewUpShMtBEoqpCJnpP8lHrAHCEXmsXd7ClZZNWKLGJeQt0dp0aB3AYjIddI77V6U9ZEH5pFeFQzCbxP7YDfZvCW+ErVYALtB4HkZ6 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 07 Jul 2020 01:30:02 -0000 Received: by ary.qy (Postfix, from userid 501) id 9C95F1C5F887; Mon, 6 Jul 2020 21:30:16 -0400 (EDT) Date: 6 Jul 2020 21:30:16 -0400 Message-Id: <20200707013016.9C95F1C5F887@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:30:06 -0000 In article <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> you write: >About credible mediators: >You are right that if an inbound email gateway believes a Mediator is credible, then all that is necessary is for >the Mediator to prove his own identity. But what is the mechanism by which a Mediator obtains the trust of the >email gateway? And by what mechanism does the Mediator know that the email gateway has determined it to be >credible? Please see previous discussions about the design of ARC. There's reasons it's not just a whitelist of mailing lists. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 6 23:37: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 59E503A07A1 for ; Mon, 6 Jul 2020 23:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ7hNzlgfzQm for ; Mon, 6 Jul 2020 23:37:29 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220773A07A0 for ; Mon, 6 Jul 2020 23:37:28 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id e15so21936922vsc.7 for ; Mon, 06 Jul 2020 23:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iZXCfk/xcoaLg3IRDf6TFC1JiGRZLLJwC/GfOjhvvI=; b=TMpwH6YVgB1oQKPBYBIKGbwp+2FCA07JMMp1ztvi0VcrF9dvxy2DVxxIlBTk7Hwr2i kuDjo+gfGl0Ry2xxvvQr8Qzp98sZKEANZ3FhY1YEd6tH2DazJB7Ed823ylt801eLbI+T j7m1OgenDnBeM493+j3MfK+96ZGy8YGV3Sf3EZ59AUu+Xl0Qd2PBX55wwTZM5uwB69V1 WZz48gY4U6oQS73aHwA3QKwvZvd8fd1sPYVIMZGtKSK9vQLcyPO6tHlgxIgDL9rhgdtW jJPYX5ilpTcQTHjGuztmqCvgYNwldhWN4wI8v41pw/uDBfFkglTW/nXEQ6v7Jpe2IhrC YsoA== 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=5iZXCfk/xcoaLg3IRDf6TFC1JiGRZLLJwC/GfOjhvvI=; b=B4xHw2Lvu86vJvuFvG5z7ls6pS54/T0di+srHDkphjU4nc3nac/zi6ME9UeQuhaElO 0KzV10rThJ4oI873yc1kE8lyhgC/gVpZ4CbxKntpqGISOBwJCXRU1aQPTmkImPcQrEOz zulBkyOh3ZwNwtoyW9JraHMEOTfaJ99G5Kz2jacMHUltupE1u2iFInhqwf7s40ELusMR KZ85ov9Q7hQmhWOa5qJpeqqqoTavlF81qhOGIJYun4C/OajtVbj1iDnHt4saop7SFoTd SCHnMZtw9CFbt0epSsCvWykG7m7B+/GXiPUhcyqoMSujAOMbFJdpdNx9EUtFeG7LEfVr otsg== X-Gm-Message-State: AOAM533iE+COjQ1qQsYFVvQnRvGs53LwOnWmSvU+8qXH//yn4zJQB1OK tt5AgoMw2iBBUsen4dJVj8E/hLtbAUdcFVc8G5w= X-Google-Smtp-Source: ABdhPJwUgH+Wf3uFZa6nT6E+sn7BWNbTIExWsjVw23Q7EyqCnASLi5BJITA8WnIKVBLCNImbGyloeH13Y/Hskv35HVE= X-Received: by 2002:a67:f60c:: with SMTP id k12mr27547297vso.8.1594103847942; Mon, 06 Jul 2020 23:37:27 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> In-Reply-To: <20200706181847.79A001C5D093@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 23:37:16 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Dave Crocker Content-Type: multipart/alternative; boundary="000000000000977e2605a9d439db" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:37:30 -0000 --000000000000977e2605a9d439db Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 11:18 AM John Levine wrote: > In article you write: > > > >It occurs to me that discussion about how this latest proposal might or > >might not have similarities to ARC should encourage everyone making a > >proposal to add commentary that gives a full sense of end-to-end use. > > Agreed. Hence my point that this is much harder to integrate into > mailing lists, and the useful signal you get, that you started with a > valid message from some X, is the same. > There's a distinction though. ARC tells you "that guy over there said the original message passed", and you have to trust it. On the other hand, the transformations draft, when it works, hands you the original message, and you don't have to make that trust assessment. -MSK --000000000000977e2605a9d439db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 11:18 AM John Levi= ne <johnl@taugh.com> wrote:
In article <e0dca35e-7f1c-4e41-9e9a-0aa7feeba4a0@gma= il.com> you write:
>
>It occurs to me that discussion about how this latest proposal might or=
>might not have similarities to ARC should encourage everyone making a <= br> >proposal to add commentary that gives a full sense of end-to-end use.
Agreed. Hence my point that this is much harder to integrate into
mailing lists, and the useful signal you get, that you started with a
valid message from some X, is the same.

There's a distinction though.=C2=A0 ARC tells you "that guy over = there said the original message passed", and you have to trust it.=C2= =A0 On the other hand, the transformations draft, when it works, hands you = the original message, and you don't have to make that trust assessment.=

-MSK
--000000000000977e2605a9d439db-- From nobody Mon Jul 6 23:45: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 3852A3A07D6 for ; Mon, 6 Jul 2020 23:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL2eiNjIUiMZ for ; Mon, 6 Jul 2020 23:45:43 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 1A2853A07D2 for ; Mon, 6 Jul 2020 23:45:43 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id r7so9155853vkf.0 for ; Mon, 06 Jul 2020 23:45:43 -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=mQPYzs7O0Aj0sAXlhFXrYHqjaUBodHfHcmtSY2OQTgc=; b=gHvqikgUeRYEayDIXItZLWGM+OwOlpJ6rKcHm7kbFu9jJdrvtaKo/jug2NLYpwxHC7 M3bw4DTHuf2KCCa+s7BNtWpWJn0HnN7JarvjsWv3/oe8UoWop5gj0MORCJGqqxkwWuNd WvEj7dl+X64pvEPf7BkEnBLH9gyaa3n5gkH+3DnS3B5wjxwYzZ28tZmIGeEMqLDm4IEE zBokmgz7HWgB9u7vYDDwHSSnz4elWmQKScNEjJHAR9Ui+me1o/zlMf515F3bFw/WL2Cp zZBQunGjGLHJBnQ5KovmsphrwriGYLsHl59ay8vsiFOtyzmPRBh1gDSsAAPOq0KZCZ0e Ej7Q== 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=mQPYzs7O0Aj0sAXlhFXrYHqjaUBodHfHcmtSY2OQTgc=; b=S49E70ONIvB1TlQ8DatK+Lft5AcNx8OYf4yiQJdEItYXAl+CQL/tVyFvq83wd2DXFz ufVF1tqahEabLDrDpgm1mdYNmtD4oo57/yzOTbW2Hhq8j53DCDTo7/6Emmi8XMEtyTIw +FiIKEGdsvTClupTq/o4l2Z+JPU6oWWvUuwIOuJ4s3+WPgt8RKcflNvTQYgb1h4YDLQW UizR6OBTjcfNJKd3D+8Zk6/fScSuuMBhzgn84xNg0LiAdAt2kDB6WEEQHkKShFSi34W8 GvUPjgewgcZ5pONMgo97vWbzT6FDpr4EobbyG3qs2FCig5582rlOuAI+SgnGn9ogV0M7 G+ww== X-Gm-Message-State: AOAM533C0FttLGmiGPlmBKvShR9hdQe3qKN7sZCaRNU8NIyUk8wShzb0 drtcSL5g/KgMSM6XO6VDoSjCeH61kZ1TjxCWTiM= X-Google-Smtp-Source: ABdhPJxlVK7ufCOBdCSGBGPB3eI9A9/LqAv4zPdN2NWqz8gEOCliDuWeBudQdJtu3ntRtAY+Do9B84WxopUJyvorTo8= X-Received: by 2002:a1f:f402:: with SMTP id s2mr15701964vkh.95.1594104342124; Mon, 06 Jul 2020 23:45:42 -0700 (PDT) MIME-Version: 1.0 References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> In-Reply-To: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 23:45:31 -0700 Message-ID: To: Dave Crocker Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000c1e4a05a9d45784" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:45:46 -0000 --0000000000000c1e4a05a9d45784 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 10:12 AM Dave Crocker wrote: > Perhaps, like some others, I'm not understanding this correctly, but I > think the proposal has nothing at all to do with what the recipient sees. > Rather, I've understood this as an attempt to reverse additions made by a > Mediator, with the goal of validating the origination DKIM signature. > Presumably that is so as to use the origination domain's reputation and > even permit DMARC to validate. > Right, primarily. It occurs to me that if you can recover the original content and thus validate the author domain signature, you could opt to deliver that version of the content to the user, permanently reversing the transformations. But that's mainly a reply to John's point that a spammer could drop a blob of junk onto a legitimate message; the verifier could simply reverse it. -MSK --0000000000000c1e4a05a9d45784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 10:12 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
=20 =20 =20
Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees.=C2=A0 Rather, I've understood this as an attempt = to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature.=C2=A0 Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate.

Right, primarily.=C2=A0 It occur= s to me that if you can recover the original content and thus validate the = author domain signature, you could opt to deliver that version of the conte= nt to the user, permanently reversing the transformations.=C2=A0 But that&#= 39;s mainly a reply to John's point that a spammer could drop a blob of= junk onto a legitimate message; the verifier could simply reverse it.
<= /div>

-MSK


--0000000000000c1e4a05a9d45784-- From nobody Tue Jul 7 04:37: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 8EA563A0BC5 for ; Tue, 7 Jul 2020 04:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 wgh1Mb0Mjmh6 for ; Tue, 7 Jul 2020 04:37:37 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6413A0B94 for ; Tue, 7 Jul 2020 04:37:37 -0700 (PDT) X-ASG-Debug-ID: 1594121854-11fa313a1031bf60001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id ZWG3GaGQmgHfzS0p (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 07 Jul 2020 07:37:34 -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=ksq68mDcOmYLhWLLUD9QPClp8cddwIl2YWt61tGuUn0=; b=FZ5QFOkzNyIyLTGDE6SY4N1uGKgfw9+7ibwBNWsEZYYwK4+BSYsCr8+5Lovpewoqq 65wakD6q5tGtU2BnC1vhljqNbWjFb2EJsqQLiCgdIrNgqZK3PSwYhDXfXp6iudWTC ON2ypIw07kYApGl1kkZagEPD3Q4qaF8qaMqDQWTxM= From: "Douglas E. Foster" To: Date: Tue, 07 Jul 2020 11:37:27 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt Reply-To: fosterd@bayviewphysicians.com Message-ID: <99fa2652ae044dc4824e1b14f45826d5@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ae10f66e4d384c188a82684bc7367746 In-Reply-To: <20200707013016.9C95F1C5F887@ary.qy> References: <20200707013016.9C95F1C5F887@ary.qy> X-Exim-Id: 99fa2652ae044dc4824e1b14f45826d5 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594121854 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: 7445 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.83035 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 11:37:46 -0000 This is a multipart message in MIME format. --ae10f66e4d384c188a82684bc7367746 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was convicted that I was working from a reading of the abstract, and not = the whole document. So I read the whole document last night, but it did n= ot change my understanding. Given a first occurrence of a message which purports to be from a legitimat= e message-altering MLM, how does the email gateway make a disposition decis= ion? ARC does not solve the problem, because the ARC chain does not provid= e enough information to do so. ARC assumes that initial trust is obtained= by another method. Reversible tagging mostly solves the problem if the content is fully revers= ible. The email gateway can assess both new and old content for risk, can= assess both before and after signatures for identity verification, and can= choose which version of content to deliver to the user. But there are qu= estions about whether this solution covers enough of the problem to make it= the only solution. We also have the question of whether the tagging would= be too complex to do correctly. For a complete solution, the mailing list needs to be able to distinguish b= etween these possibilities: Fiction - the mailing list does not exist, but a spammer wants to look like= one to evade DMARC filteringUnsafe - the mailing list is poorly managed, s= o that it is little more than an open relay, or the content filtering is in= adequate, so that it is a likely source of malicious content.Unwelcome - th= e subscriber address is a work account, and the list purpose is not work re= lated.Spoofed list - a spammer tries to imitate a trusted list.Legitimate -= a trusted and wanted list that both subscriber and email administrator wan= t to receive. I don't see that we have adequately addressed all of these scenarios, but a= gain it seems that most of the issue hangs on the trust question. List spoofing is an issue because we do not yet have a standard for how a l= ist ID is associated with an authorized source. Presumably, we should perf= orm an SPF check on the list ID, or find a verified DKIM signature that is = domain aligned with the list ID. But there are no requirements on the for= mat of a list ID, so we need to start by defining how the list domain is ob= tained from the list ID. What is the process for obtaining trust (and a supporting exception in the = email gateway)? What is the process for notifying the MLM that the exception has been imple= mented? DF ---------------------------------------- From: "John Levine" Sent: 7/6/20 9:30 PM To: dmarc@ietf.org Cc: fosterd@bayviewphysicians.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy= -dkim-transform-01.txt In article <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> you wri= te: >About credible mediators: >You are right that if an inbound email gateway believes a Mediator is cred= ible, then all that is necessary is for >the Mediator to prove his own identity. But what is the mechanism by which= a Mediator obtains the trust of the >email gateway? And by what mechanism does the Mediator know that the email= gateway has determined it to be >credible? Please see previous discussions about the design of ARC. There's reasons it's not just a whitelist of mailing lists. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dumm= ies", Please consider the environment before reading this e-mail. https://jl.ly --ae10f66e4d384c188a82684bc7367746 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I was convicted th= at I was working from a reading of the abstract, and not the whole document= .   So I read the whole document last night, but it did not change my = understanding.

Given a first occurrence of a messa= ge which purports to be from a legitimate message-altering MLM, how does th= e email gateway make a disposition decision?  ARC does not solve the p= roblem, because the ARC chain does not provide enough information to do so.=   ARC assumes that initial trust is obtained by another method.
=

Reversible tagging mostly solves the problem if the con= tent is fully reversible.   The email gateway can assess both new and = old content for risk, can assess both before and after signatures for ident= ity verification, and can choose which version of content to deliver to the= user.   But there are questions about whether this solution covers en= ough of the problem to make it the only solution.  We also have the qu= estion of whether the tagging would be too complex to do correctly.

For a complete solution, the mailing list needs to be abl= e to distinguish between these possibilities:
  1. Fiction - the ma= iling list does not exist, but a spammer wants to look like one to evade DM= ARC filtering
  2. Unsafe - the mailing list is poorly managed, so that = it is little more than an open relay, or the content filtering is inadequat= e, so that it is a likely source of malicious content.
  3. Unwelcome - = the subscriber address is a work account, and the list purpose is not work = related.
  4. Spoofed list - a spammer tries to imitate a trusted list.<= /li>
  5. Legitimate - a trusted and wanted list that both subscriber and ema= il administrator want to receive.
I don't see that we have ad= equately addressed all of these scenarios, but again it seems that most of = the issue hangs on the trust question.

List spoofi= ng is an issue because we do not yet have a standard for how a list ID is a= ssociated with an authorized source.  Presumably, we should perform an= SPF check on the list ID, or find a verified DKIM signature that is domain= aligned with the list ID.   But there are no requirements on the form= at of a list ID, so we need to start by defining how the list domain is obt= ained from the list ID.

What is the process for ob= taining trust (and a supporting exception in the email gateway)?
= What is the process for notifying the MLM that the exception has been imple= mented?

DF

From: "John Levine" <johnl@taugh.c= om>
Sent: 7/6/20 9:30 PM
To: dma= rc@ietf.org
Cc: fosterd@bayviewphysicians.com
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draf= t-kucherawy-dkim-transform-01.txt
In article <3129f12e0= 2434273915ed6f91a998122@bayviewphysicians.com> you write:
>= About credible mediators:
>You are right that if an inbound em= ail gateway believes a Mediator is credible, then all that is necessary is = for
>the Mediator to prove his own identity. But what is the m= echanism by which a Mediator obtains the trust of the
>email g= ateway? And by what mechanism does the Mediator know that the email gateway= has determined it to be
>credible?

P= lease see previous discussions about the design of ARC. There's
r= easons it's not just a whitelist of mailing lists.

--
Regards,
John Levine, johnl@taugh.com, Primary Perp= etrator of "The Internet for Dummies",
Please consider the enviro= nment before reading this e-mail. https://jl.ly

--ae10f66e4d384c188a82684bc7367746-- From nobody Tue Jul 7 04:52: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 C92B93A0BD5 for ; Tue, 7 Jul 2020 04:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=N7AoHfod; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=CkzjJ6g3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La1GMGOob6Is for ; Tue, 7 Jul 2020 04:52:52 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B288D3A0BE3 for ; Tue, 7 Jul 2020 04:52:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=922; t=1594122765; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ZRZgfCSxqZHjPS6Dr6YhpHhAVSs=; b=N7AoHfodkzsYKKiSrUlvMm/zKhBTqX5e+nG2WOB4Co7CfO1fR3h7beTdQk6JbF /8KxZE9QcxvgCWPtwIPGPFyKaEZ32cOtYWkXmHe7V9fzy1OQQsyn99UY3vGaZIlI /3spmMCX0QMp71ng+jd4dhjC78eAdRPamstuVftm527v0= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 07:52:45 -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 555079199.78.4212; Tue, 07 Jul 2020 07:52:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=922; t=1594122690; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KUn4eUK RzxEW6/6qm2uOX48KzcSX408wIkLGHOb5c3w=; b=CkzjJ6g3pj3lDBTlcDZByV1 BfYtBfCDUILEF1Wy1Dnf5orGwG/cnZt4McPJCLqjFPysag+3fGKNGIAnAXiorXhY CvwOP4n9TAEHOx5YNM98PBWZLJKypXh5jrd96Jtqd1a2WgjVh4Y1EQCPzntkg7X9 CIBk3qiKV624bafuYb3Q= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 07:51:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 265865343.3.7064; Tue, 07 Jul 2020 07:51:29 -0400 Message-ID: <5F04620C.10603@isdg.net> Date: Tue, 07 Jul 2020 07:52:44 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Jul 2020 11:52:55 -0000 Our MLM/MLS has long supported creating a List Digest for various list. Each list created by an admin comes with an option to also create a digest for subscribers who may prefer it. What would be, if any, DKIM, DMARC and ARC consideration when digests are created? A few items comes to mind: - I don't think preserving the 5322.From is useful because there will be many authors in a digest. There would be only 1 from, the list agent. - A digest is probably the most modified form of a collection of list submissions. - I believe the MLM may create the digest differently than others. I don't recall a standard method for created a digest. - Based on my current view for the available list digests, they are on the lower side of having subscribers. Is a List Digest a non-consideration as an MLM output? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 7 05:08: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 7D49D3A0BFF for ; Tue, 7 Jul 2020 05:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGc1UopmJsmq for ; Tue, 7 Jul 2020 05:08:54 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B73A0BFE for ; Tue, 7 Jul 2020 05:08:54 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 5810C9F1FA for ; Tue, 7 Jul 2020 05:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1594123733; bh=51R3Z9SEvFFFCmkfrTzMYVRE2o/5eVj5Stbn7jwLUYg=; h=From:Subject:Date:References:To:In-Reply-To:From; b=FejwryFvWPwvnRhbPDvY33/AMGfxPEqOLFzhvbOWi+AwMTV/DIUmKgaXD2vPt1heC l1S38QpHlfPrEBazgVFu60N3hMYP2iCTwQjrW6s05uiMQ9Vvr0opA1qm6cveFKuvFv wffX4ys/g7+5JvrC5HJYc2GuvFhIqnXXGLe0ki2s= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_84B7031D-0E55-4BA3-BA7E-E0E539960976" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 7 Jul 2020 13:08:51 +0100 References: <5F04620C.10603@isdg.net> To: "dmarc@ietf.org" In-Reply-To: <5F04620C.10603@isdg.net> Message-Id: <99FD7B11-FE0C-491D-A8E9-519D86A23B3B@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Jul 2020 12:08:57 -0000 --Apple-Mail=_84B7031D-0E55-4BA3-BA7E-E0E539960976 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Jul 2020, at 12:52, Hector Santos = wrote: >=20 > Our MLM/MLS has long supported creating a List Digest for various = list. Each list created by an admin comes with an option to also create = a digest for subscribers who may prefer it. >=20 > What would be, if any, DKIM, DMARC and ARC consideration when digests = are created? None, really. In the case of a list digest, the MLM is actually the = creator of the message. It=E2=80=99s the list that is the 5322.from = address and all the associated authentication belongs to the list. The = individual digest contributors are part of the body of the message.=20 laura --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_84B7031D-0E55-4BA3-BA7E-E0E539960976 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7 Jul 2020, at 12:52, Hector Santos <hsantos=3D40isdg.net@dmarc.ietf.org> wrote:

Our = MLM/MLS has long supported creating a List Digest for various list. =  Each list created by an admin comes with an option to also create = a digest for subscribers who may prefer it.

What would be, if any, DKIM, DMARC and ARC consideration when = digests are created?

None, really. In the case of a list digest, the = MLM is actually the creator of the message. It=E2=80=99s the list that = is the 5322.from address and all the associated authentication belongs = to the list. The individual digest contributors are part of the body of = the message. 

laura

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

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

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







= --Apple-Mail=_84B7031D-0E55-4BA3-BA7E-E0E539960976-- From nobody Tue Jul 7 05:20:14 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 E2A2A3A0C0D for ; Tue, 7 Jul 2020 05:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L99qAR72BuvM for ; Tue, 7 Jul 2020 05:20:11 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A063A0C0B for ; Tue, 7 Jul 2020 05:20:10 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id B02988018B for ; Tue, 7 Jul 2020 12:20:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=393; q=dns/txt; s=default; t=1594124409; h=from : subject : date : to; bh=YlMQPN0R6poegX5cwn0GjoErO2hdCXIicvjhbvNeVSw=; b=xRsfS9JH8uoKlw/4nmx2L8HZdM9rftHo6oYKZg3g+s2GTQiYCE3oN3z7KWmk7MKTKBwiV NImS5YYRe5lpY3nm+o2FPZNJS/ZqPs1QpGZHDZHr/u/hkeGNp28xv8nYG2wexbl5Hb5wZQy bxyQ9LChiifqHwIePtSRzqnXY2DVvaY= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 960117FABE for ; Tue, 7 Jul 2020 12:20:09 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 07 Jul 2020 14:20:09 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <5F04620C.10603@isdg.net> References: <5F04620C.10603@isdg.net> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Jul 2020 12:20:12 -0000 Hector Santos skrev den 2020-07-07 13:52: > What would be, if any, DKIM, DMARC and ARC consideration when digests > are created? user posts to maillist should only be ARC sealed digist post could be dkim signed aswell, since content is dkim breaked anyway but both should still be ARC sealed then DMARC can test if it passes from original senders have i missed anything ? From nobody Tue Jul 7 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 26CA93A0C37 for ; Tue, 7 Jul 2020 05:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=GKwA+t5e; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=sIDiUUUx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDdqZKhmCQeJ for ; Tue, 7 Jul 2020 05:47:53 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12153A07E1 for ; Tue, 7 Jul 2020 05:47:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3121; t=1594126067; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=9tSN7SC4xNOcHPMsYKehDRe+CFU=; b=GKwA+t5eXQ3eb4sFLsjMkVuTya8+JZycvctdIyzuq6mOxCkhwYW6VE44s/K64R mtDKBkItU1GvEShv1Ci6JlTusONpeVfTPvTZ59YNFryFbvIJRLt8oHbdysg0kH9+ IlnuQJOuN8Vexm6ItN7Ma/FZ3cQkilVkIVtvxrIlKgTm4= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 08:47:46 -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 558379509.78.7604; Tue, 07 Jul 2020 08:47:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3121; t=1594125991; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/9dRXuQ roEJFQET1o2Spj4OSJAqxGaS9Jn4TUdQCOcs=; b=sIDiUUUxeblzk7JJ8ft663Q M3XaGD1fU+ugRrt2nwUEPF7HmTB/8fXPOpGQc/ugP3uRHxD57No447rvnC7IRWgd RTpE/rR5UWpioeHjgdCxkF1X9T5dFKX7RnOWsJpWZ4mLD9l43IgVEuJ5zlUeyZ1/ q3gu3ml5OXEo95zx55ZA= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 08:46:31 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 269166718.3.7060; Tue, 07 Jul 2020 08:46:31 -0400 Message-ID: <5F046EF2.2040305@isdg.net> Date: Tue, 07 Jul 2020 08:47:46 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 12:47:55 -0000 On 7/6/2020 7:27 PM, Jim Fenton wrote: > On 7/6/20 3:41 PM, John Levine wrote: >> >> This proposal makes lists sort through all of the changes they make >> and try to figure out which ones match a tag and which ones don't. >> That is surprisingly hard, e.g., I found that when you have >> multipart/alternative and add a message header, it edits the header >> text into both of the alternative versions. Good luck unscrambling that. > > Perhaps I didn't explain this clearly enough. Mediators don't need to > sort through changes at all. All they do is check to see if the incoming > message had an aligned signature or SPF, and include a tag in the DKIM > signature that they apply indicating that. +1. By far, the simplest "ADD-ON" thing to do -- checking the MLM entry points. > Receiving domains that intend to enforce DMARC would need to verify the > DKIM signature of the mediator, and if the signature came from a > credible mediator and the tag is present, accept the message as though > it had an aligned signature. +1, this would work. The term "credible" will need to be defined as to how it is established. Non-whitelisted local policy Authorized/Trusted resigners has been the central crux of the problem in the DKIM policy model. It needs to be automated and we can't get unfocused which the idea that "bad guys" can also be DKIM/DMARC compliant. Detected "Bad Guys" is a different dilemma. I believe the of the top goals is to raise the bar for everyone so that we can get to that secondary Trust/Reputation layer. The problem has been Signer Reputation wanting to push out DKIM Policy: Layer 1: DKIM Policy Deterministic protocol Layer 2: DKIM Signer Trust/Reputation The argument has always been by Mr. Levine and others, why need Layer 1 of all we need is layer 2? The answer is that Layer 1 is an deterministic immediate filtering process to remove the contaminants of a mail stream, similar to an osmosis process. It includes checking RFC5322 correctness, like double 5322.From lines, to address fake MUA from Display replay concerns. But the push to use only Layer 1 perpetuated the brush back and delayed the adjusted needed in Layer 1 to address authorized resigner issues that Layer 2 will need. If we go to back DKIM-STD, there was strong cogs efforts to remove or rather not recognized the Author Domain Identity (ADID) from a future DKIM Trust Assessment algorithm where only the SDID (Signer Domain Identity) and optional AUID (Agent User Identity) were parameters to a trust assessor. I had argued (and lost) that the ADID needed to be part of the algorithm, officially in DKIM-STD. But the effort was too strong to remove any recognition of its importance. The cogs had a hard time doing this because DKIM policy was too strong of a concept. It would simply not go away. 5322.From could not be removed from DKIM-STD. It could not avoid the fundamental idea that 5322.From is the minimum required header to be bound to the signature. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 7 06:01:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085603A0C53 for ; Tue, 7 Jul 2020 06:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=J3cEO4Lm; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=prEmpzvN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuYabWK2hpKC for ; Tue, 7 Jul 2020 06:01:03 -0700 (PDT) Received: from mail.winserver.com (unknown [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 F04153A0C51 for ; Tue, 7 Jul 2020 06:01:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1170; t=1594126861; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=H43NJ26L3csJ+3hcbqNuAIE84A4=; b=J3cEO4Lmmu0Rcb9njXkGBQmkR2p4HMEXE+dM29wYz+R5EBgHOIS8bViqmtIJg1 LsP5DIHVK4igwhellU0/6uIooq5XgYKzE6VERrB+qNpqDYZBtf08fMhmNUqaUCdZ 90njcjFTMEs7ZLx+Bs8fRJ1UJ38yaAbAEMs99qN40CAEo= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 09:01:01 -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 559174553.78.4632; Tue, 07 Jul 2020 09:01:00 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1170; t=1594126785; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LFUZLSn AIdZqWI8PgedHp2MXt7N43evJIv2HGMcqkoc=; b=prEmpzvN9/dJksOaWt2ra2V ZFskg5zwF1ACJYbcbqDfKEMuajbxvFLFv6i3rEMvltnhnL+VnCtKTp80/G4Ze+1X n3RSxq7eHIcqw0VMJuH9xSyG4A8zM+IFo1vp8Ju4d7LXrMYUelTWn490tQMC0iWr 00MFy5wZGrY2J503VWek= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 08:59:45 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 269959796.3.7228; Tue, 07 Jul 2020 08:59:44 -0400 Message-ID: <5F04720B.4070606@isdg.net> Date: Tue, 07 Jul 2020 09:00:59 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5F04620C.10603@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Jul 2020 13:01:05 -0000 On 7/7/2020 8:20 AM, Benny Pedersen wrote: > Hector Santos skrev den 2020-07-07 13:52: > >> What would be, if any, DKIM, DMARC and ARC consideration when digests >> are created? > > user posts to maillist should only be ARC sealed > > digist post could be dkim signed aswell, since content is dkim breaked > anyway > > but both should still be ARC sealed > > then DMARC can test if it passes from original senders > > have i missed anything ? Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC. Another thing that just came to mind is the number of messages in a digest. What if its set to 1? if possible. In our MLM, the admin sets this amount, not the subscriber. But I have seen another MLM, forget which one, allowing the user to set the digest amount. How would a digest of 1, if allowed, be different from a normal non-digest submission distribution. I see it as the only form of a MLM output that would have not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. The list digest agent can do what it wants without any debate. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 7 06:09:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9063A0C5E for ; Tue, 7 Jul 2020 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 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, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=h3Yig6Bq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AItnJl7z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UPzNpCQGXQo for ; Tue, 7 Jul 2020 06:09:13 -0700 (PDT) Received: from mail.winserver.com (unknown [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 1302D3A0C5B for ; Tue, 7 Jul 2020 06:09:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1127; t=1594127351; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=df4fhVTOuyoVVRUt/E2GsIlev30=; b=h3Yig6Bqh+500L2XvQpQqgHvmy4eHUnGqC0bE7BpBpKQBFqR+ArjPhYZ03A2hA Duu8hLdVvkiTl0eUEgqgzX0zqA/jgl3GmmR2vRQxyFkybVRwZYOkMZTvrzq8gwyG JCM/gNJkZLoeafa3ulYoAFAKcEnzd3tv1bKsK00AYhlaE= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 09:09:11 -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 559664786.78.2364; Tue, 07 Jul 2020 09:09:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1127; t=1594127274; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=l6wIQVz s5Bf8I7I+FFpBSDkSYr7YjIWIef73/ClG82g=; b=AItnJl7z6gaeJMg/8+SS9S0 XM1ZXr4AWjv5wkWUWnNDRVOuAZhUlbPvaTRDEkE3LDpQxdkjHM/BTuoP5Z1WO+tb mUS2WzXmYqJkPsKTikTfcVBN+1EfmKbu2NYGrZTndscCjgXy1tFUadztTq5hbgn4 sUQ65V43GaWNb5KTjoFI= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 07 Jul 2020 09:07:54 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 270450125.3.7036; Tue, 07 Jul 2020 09:07:54 -0400 Message-ID: <5F0473F5.7070305@isdg.net> Date: Tue, 07 Jul 2020 09:09:09 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> <5F046EF2.2040305@isdg.net> In-Reply-To: <5F046EF2.2040305@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 13:09:15 -0000 On 7/7/2020 8:47 AM, Hector Santos wrote: > The problem has been Signer Reputation wanting to push out DKIM > Policy: > > Layer 1: DKIM Policy Deterministic protocol > Layer 2: DKIM Signer Trust/Reputation > > The argument has always been by Mr. Levine and others, why need Layer > 1 [if] all we need is layer 2? > > The answer is that Layer 1 is an deterministic immediate filtering > process to remove the contaminants of a mail stream, similar to an > osmosis process. It includes checking RFC5322 correctness, like double > 5322.From lines, to address fake MUA from Display replay concerns. > > But the push to use only Layer 1 perpetuated the brush back and > delayed the adjusted needed in Layer 1 to address authorized resigner > issues that Layer 2 will need. Arggg, I really do need to take my time when I write. Correction: But the push to use only [Layer 2] perpetuated the brush back and delayed the [adjustments] needed in Layer 1 to address authorized resigner issues that Layer 2 will need. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 7 08:18: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 AF8613A0DE6 for ; Tue, 7 Jul 2020 08:18: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmi6-mxr4Juy for ; Tue, 7 Jul 2020 08:18:40 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673633A0DE5 for ; Tue, 7 Jul 2020 08:18:40 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 0CBC580184 for ; Tue, 7 Jul 2020 15:18:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=1389; q=dns/txt; s=default; t=1594135119; h=from : subject : date : to; bh=/lBhlsP6swXRXjjTxYcv44MIvrywEpZX3qqVbNTw4uA=; b=tsTmdJBRotn8+RdMLR6OVEo4cMhSYHsG/cyJ63TTwqYBkr/BCQrkaMWOslo5cSjTr0NRZ HNKhxXJ8kXDDPskvek2sK2VSCxUDvzJ/VFrJ5Y1204MmNyqrzmD+AbtGQIV/IsI9fLbOjJV 9zd+91+zfBAhaxXhilSaCPGAoPOmFuM= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id E40F77FAA5 for ; Tue, 7 Jul 2020 15:18:38 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 07 Jul 2020 17:18:38 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: <5F04720B.4070606@isdg.net> References: <5F04620C.10603@isdg.net> <5F04720B.4070606@isdg.net> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <1006aff1ccd54c5c7610e1072fe4a634@junc.eu> X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Jul 2020 15:18:42 -0000 Hector Santos skrev den 2020-07-07 15:00: > Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC. when i post to dovecot maillist i get DMARC PASS on my own domain, and dovecot maillist do only ARC sealing > Another thing that just came to mind is the number of messages in a > digest. does not matter > What if its set to 1? see above > if possible. In our MLM, the admin sets this > amount, not the subscriber. so if users do it it will break dkim mlm digest signing ? :=) > But I have seen another MLM, forget which > one, mlmmj ?, mailman can behave nicely aswell, more or less just unwilling admins that turns it into break dkim > allowing the user to set the digest amount. How would a digest of > 1, are digest not sent daily or weekly ?, it have never being on more then 1 msg > if allowed, be different from a normal non-digest submission > distribution. are how digest is done imho > I see it as the only form of a MLM output that would > have not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. digest is dkim signed from mlm, thats not the same as mlm forward and break dkim original senders dkim signing, thats why its diffrents problem to solve > The list digest agent can do what it wants without any debate. so can ietf of breaking dkim, but not provide a dkim pass on there own problem From nobody Tue Jul 7 09:27: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 1874E3A110B for ; Tue, 7 Jul 2020 09:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=rzir2iqf; dkim=pass (1536-bit key) header.d=taugh.com header.b=wsQoqyUb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOPxWhszdIYQ for ; Tue, 7 Jul 2020 09:27:43 -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 2A0B63A1107 for ; Tue, 7 Jul 2020 09:27:42 -0700 (PDT) Received: (qmail 9958 invoked from network); 7 Jul 2020 16:27:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=26e2.5f04a27c.k2007; i=johnl-iecc.com@submit.iecc.com; bh=ZdtCvTXsQZu83Dz+UgaCdoYZdNx1sC5gzvA8K1GNVgE=; b=rzir2iqfkdTp2iexPus3Jijb3HKGqIQAZ1SNraKjlNRyGP3PghPsq7PfMbeaRCPekaYMT9Zhz4xc0oVSWNlOka3jvgtsh4WZboeY1OsUnukawJcX6RnYVuCpiZwVZYLUh/fDTHht4/ruKtAVEPzHvdumIWlF/Dw25xCmQ0kmHCG8O4dc2gKARmyxg9Oj9onT9BKhkYKcqQ3qTiPKsCAeZZQkyGaQId2TjEfWvIVVMjEzj2gv7aVy+GE3TLPE6qbC DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=26e2.5f04a27c.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=ZdtCvTXsQZu83Dz+UgaCdoYZdNx1sC5gzvA8K1GNVgE=; b=wsQoqyUbOIGV9VeNNtViBXKIPiwyP2mANBg6Woc+hdOWMe6VizEjW1Dx+K3q2X538nVzWgcJIYO9enjK9f04U2zzyBgUSiqZ9QR6MhNSw+HoxqWvSBWiRJlvlpg5HngBmcqOizty8unq1p5tqokEr2QdZ6Ge3T6idXcseMUjJiwDuhO0gSYRHJxuZcfNI1UBmAlrGrFEirjCrN8csn/TvkMs67n2duHQnm+Nn8xCJAT6Q/uD7Z3rky7omFWZwmVg Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 07 Jul 2020 16:27:40 -0000 Date: 7 Jul 2020 12:27:40 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20200706181847.79A001C5D093@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 16:27:45 -0000 > There's a distinction though. ARC tells you "that guy over there said the > original message passed", and you have to trust it. On the other hand, the > transformations draft, when it works, hands you the original message, and > you don't have to make that trust assessment. I understand that, and I still don't see why it's useful. It's hard to imagine a realistic sitatuation where a recipient system would strip off the changes and show the original message, so the recipient has to trust that the mediator doesn't make malicious transformations. So if you trust them that far, why wouldn't you also trust them to report the status of incoming mail? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 7 10:09: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 CF9183A115E for ; Tue, 7 Jul 2020 10:09:06 -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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaJqqxB8-Ju0 for ; Tue, 7 Jul 2020 10:09:05 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17B13A11D4 for ; Tue, 7 Jul 2020 10:08:56 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:7d61:a71b:7455:76ee]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 067H8rXc009683 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 7 Jul 2020 10:08:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594141735; bh=L/PR2VWG9pRgoLnZ8yIxZtM388xbWLrZ8lJcWMu8gs0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CjygZ973qrlL42mi9Qve08QyRgSkHZvpdbLjlZn5SLzrUoQO/+xmZAPF25ocihw/Q QFj1SLUO4LQmnUFA22dRaP1sIVJxFLBAS/jPdaGKqzmPEG7D05BQFa0Gnc1qmiJMxL MQ03AFhMv/CODFGMZfE8OH4I3UCxhkCJ/nnb0tI0= To: fosterd@bayviewphysicians.com, dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <2cb64e63-dc8c-a32e-1296-d0bad4077a55@bluepopcorn.net> Date: Tue, 7 Jul 2020 10:08:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> Content-Type: multipart/alternative; boundary="------------2CC15DBD3E6001CA6EBC2351" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:09:07 -0000 This is a multi-part message in MIME format. --------------2CC15DBD3E6001CA6EBC2351 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/6/20 6:15 PM, Douglas E. Foster wrote: > About discarding From alignment: > DMARC has been sold to big corporations as essential to defending > their brand identity. =C2=A0 =C2=A0In response, they pay serious money = to keep > Valimail and its competitors in business. =C2=A0 I see no way that we c= an > put forward a proposal that will put Valimail and its friends out of > business, while incurring the wrath of C-Level executives and legal > teams at Fortune 500 companies. =C2=A0 Not that I have any of those peo= ple > on speed dial, so maybe someone can prove me wrong. =C2=A0 But I have b= een > surprised that one of the DMARC reporting companies is not listening > to this part of the discussion and having alarm bells. While deployment is definitely a factor for IETF standardization decisions, I would be very surprised to see IETF standardize a specification that does not provide the benefits it claims to provide just because it has been sold to big corporations. IETF doesn't need to share in the wrath of those C-level executives. Whether From alignment does or does not defend brand identity is a topic for a different discussion thread. I was trying to avoid muddying this discussion with it. > > About credible mediators: > You are right that if an inbound email gateway believes a Mediator is > credible, then all that is necessary is for the Mediator to prove his > own identity. =C2=A0 =C2=A0But what is the mechanism by which a Mediato= r obtains > the trust of the email gateway? =C2=A0 And by what mechanism does the > Mediator know that the email gateway has determined it to be credible? My proposal is largely a simpler (I think) alternative to ARC for assessing transformations. ARC also requires that the recipient's verifier have some trust relationship with the mediator, perhaps through an as-yet undefined reputation system. Murray's reversible transforms proposal is yet another approach that does not require trust to the same degree. > > One option is to provide so much information in the email message that > the email gateway will grant trust on the fly. =C2=A0 =C2=A0Murray's ap= proach > has appeal because, especially when coupled with appropriate LIST-* > and RESENT-* headers, it provides all of the information needed for a > decision to be made. =C2=A0 ARC has less appeal because it provides jus= t > enough information for the email gateway to detect that something > deliberate was done, but not much more. =C2=A0 Researching the credibil= ity > of the list would need to occur out-of-band using LIST-* headers as a > starting point. =C2=A0 But there is a larger problem. =C2=A0 Even after= the > gateway decides the Mediator is credible, the Mediator is ignorant of > the gateway's decision, so the Mediator is unable to take advantage of > that decision. > > The other option is for the MLM and the Email gateway administration > to negotiate credibility in advance, with the subscriber acting as > sponsor for the discussion. I'm not clear on which "gateway" you're referring to: the sender's gateway? But "researching the credibility of the list" sounds like the same problem as determining whether a mediator is credible, it's just being done by a different party. -Jim --------------2CC15DBD3E6001CA6EBC2351 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/6/20 6:15 PM, Douglas E. Foster wrote:
About discarding From alignment:
DMARC has been sold to big corporations as essential to defending their brand identity.    In response, they pay serious money to keep Valimail and its competitors in business.   I see no way that we can put forward a proposal that will put Valimail and its friends out of business, while incurring the wrath of C-Level executives and legal teams at Fortune 500 companies.   Not that I have any of those people on speed dial, so maybe someone can prove me wrong.   But I have been surprised that one of the DMARC reporting companies is not listening to this part of the discussion and having alarm bells.

While deployment is definitely a factor for IETF standardization decisions, I would be very surprised to see IETF standardize a specification that does not provide the benefits it claims to provide just because it has been sold to big corporations. IETF doesn't need to share in the wrath of those C-level executives.

Whether From alignment does or does not defend brand identity is a topic for a different discussion thread. I was trying to avoid muddying this discussion with it.


About credible mediators:
You are right that if an inbound email gateway believes a Mediator is credible, then all that is necessary is for the Mediator to prove his own identity.    But what is the mechanism by which a Mediator obtains the trust of the email gateway?   And by what mechanism does the Mediator know that the email gateway has determined it to be credible?

My proposal is largely a simpler (I think) alternative to ARC for assessing transformations. ARC also requires that the recipient's verifier have some trust relationship with the mediator, perhaps through an as-yet undefined reputation system.

Murray's reversible transforms proposal is yet another approach that does not require trust to the same degree.


One option is to provide so much information in the email message that the email gateway will grant trust on the fly.    Murray's approach has appeal because, especially when coupled with appropriate LIST-* and RESENT-* headers, it provides all of the information needed for a decision to be made.   ARC has less appeal because it provides just enough information for the email gateway to detect that something deliberate was done, but not much more.   Researching the credibility of the list would need to occur out-of-band using LIST-* headers as a starting point.   But there is a larger problem.   Even after the gateway decides the Mediator is credible, the Mediator is ignorant of the gateway's decision, so the Mediator is unable to take advantage of that decision.

The other option is for the MLM and the Email gateway administration to negotiate credibility in advance, with the subscriber acting as sponsor for the discussion.

I'm not clear on which "gateway" you're referring to: the sender's gateway? But "researching the credibility of the list" sounds like the same problem as determining whether a mediator is credible, it's just being done by a different party.

-Jim


--------------2CC15DBD3E6001CA6EBC2351-- From nobody Tue Jul 7 11:19: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 B32393A0EED for ; Tue, 7 Jul 2020 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYpMHTpfaGk for ; Tue, 7 Jul 2020 11:18:59 -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 A16AE3A0EE7 for ; Tue, 7 Jul 2020 11:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594145937; bh=V0cfQ0+3zxATmSOdx+eoNL3leatDjfLDN3A9oPvKKR0=; l=1769; h=To:References:From:Date:In-Reply-To; b=BX3KTA93Vq/Ewq+wSKmyXB7m0AZEhxOBWwx9dTBFPuBHu3R1299lcWXRywpMtEmCy c3nDBUU/ENyKQXMFLAwOvQMhAY8OMNaLDyQCDLHrYUOzQ/1IFvm4atbOxwhIol/nTZ Fg2twJTYI+CAdrEK58MRAJOiwr6eXAdgjsWgjdXM/Q9EUiTEDp2eXaNRf1U7A Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005F04BC90.00006654; Tue, 07 Jul 2020 20:18:56 +0200 To: dmarc@ietf.org References: <20200706181847.79A001C5D093@ary.qy> From: Alessandro Vesely Message-ID: <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> Date: Tue, 7 Jul 2020 20:18:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 18:19:02 -0000 On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote: >> There's a distinction though.  ARC tells you "that guy over there said the >> original message passed", and you have to trust it.  On the other hand, the >> transformations draft, when it works, hands you the original message, and >> you don't have to make that trust assessment. > > I understand that, and I still don't see why it's useful. It would allow me, for one, to honor remote DMARC policies. Of course, I'd still need to manually whitelist non compliant MLMs. However, when the number of those drops below a reasonable figure, whitelisting might become feasible. > It's hard to imagine a realistic situation where a recipient system would > strip off the changes and show the original message, so the recipient has to > trust that the mediator doesn't make malicious transformations. Agreed. Undoing the changes has to be done on a temporary file, solely for verification purposes. Undoing the changes would be illegal, if the footer contains legal claims. > So if you trust them that far, why wouldn't you also trust them to report > the status of incoming mail? I cannot trust ARC operators, unless I manually compile a trusted list, which is as unfeasible as whitelisting each MLM. I trust the original message as any other message. Allowed transformations are designed to not pervert the original message. Consider my notes 1 and 2 about l=, in a message upthread[*]. We can also specify limits on the size of subject tags and footers. Transformations that insert stuff before the original content should not be allowed —rewrite From: in such cases. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/oSX41FBGRGO_vP_4Qcd-rzIkWiI From nobody Tue Jul 7 21:43:31 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 4AE0F3A07B3 for ; Tue, 7 Jul 2020 21:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJUqA7KqDDAO for ; Tue, 7 Jul 2020 21:43:27 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42B03A07B1 for ; Tue, 7 Jul 2020 21:43:27 -0700 (PDT) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 0684hPAY019557 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 7 Jul 2020 23:43:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1594183406; bh=vNKA7ZqZgyg/cYn5kqZIkFxGgJhixXE4B2l+uA7l9g4=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=GJJHMXD5+VuPJ4Gt+Orggi3D4l2J0/sCyuVxtMVQ6NAgJmx31XvzXe8+iHLQj6cj9 Xo8vCr/R3MJ9r+VHXcz8a/k5lESCqWDY3tkDRsAh5xmlqVBQJHtO+fTY5p+xtqmlyp 4cGo1AsZuMwC5bTy14EPYJ+o3XcVnEHy1K0W4y1g= To: dmarc@ietf.org References: <5F04620C.10603@isdg.net> <5F04720B.4070606@isdg.net> From: Grant Taylor Organization: TNet Consulting Message-ID: <5ad304aa-3205-0cbf-f8bc-c418975bb37b@spamtrap.tnetconsulting.net> Date: Tue, 7 Jul 2020 22:43:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <5F04720B.4070606@isdg.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000701010100000406050206" Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 04:43:29 -0000 This is a cryptographically signed message in MIME format. --------------ms000701010100000406050206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/7/20 7:00 AM, Hector Santos wrote: > Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC. My issue with ARC is that, as I understand it, receiving systems have to = choose to trust each ARC signer's assertion signature. As such, there=20 is a massive scalability problem to trust random / individual server=20 operators (like myself). Thus, I'm disinclined to do much with ARC if my ARC assertion signature=20 is going to be ignored because I'm not on a trusted list. > Another thing that just came to mind is the number of messages in a dig= est. >=20 > What if its set to 1?=C2=A0 if possible.=C2=A0 In our MLM, the admin se= ts this=20 > amount, not the subscriber.=C2=A0 But I have seen another MLM, forget w= hich=20 > one, allowing the user to set the digest amount. How would a digest of = > 1, if allowed, be different from a normal non-digest submission=20 > distribution.=C2=A0 I see it as the only form of a MLM output that woul= d have=20 > not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. The list= =20 > digest agent can do what it wants without any debate. Mailman has the ability to ""wrap DMARC protected messages as an RFC=20 5322 attachment to thee outgoing message. This would be the 1-to-1=20 relation that I think you are talking about. Seeing as how the RFC 5322 messages are actually /attachments/ -or-=20 synthetic text, there is little, if any, concern about DMARC alignment=20 of the outer wrapper message. IMHO, The outer wrapper message would ideally be DKIM signed and DMARC=20 protected. ;-) --=20 Grant. . . . unix || die --------------ms000701010100000406050206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA53zcXtFD9dENby64EqrKqMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTExOTAwMDAw MFoXDTIwMTExODIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwIZcEJcuE7mUfxJnD I8oOSX/TvAhoP11agD++8L7Ok8fFJhJK0lOVRsq1M6lF2E2Vzuyffg2ppbecWvHcIRadsaiG imnrJQasdkhj/JUtqPUXnC0SVA0AzYLrLReQB+9j/jTgB5JnFLyC2lEn9KTA6JmDGjvVkv2T k+I2+v24nI4/2lGjD+jIKQiFXkE1uqablXJAw1c9Mh9d4/wjnIM9zLGv1i3xxOLdQ1PXSUZL 12wOy1r7CsGAnNSNhGaceB2tdhdleFEyIHgSgDWtWResHdu/ubZqFiHxaLRJlafOHMj3yC6x NOA1IdcNJsaRkQHxSkayKzeE5JK3TxlV83dbAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUU6bXebmKM+efFHN0MBjYuJO9Za8wDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8v c2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5j b20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmww gYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEaZ3RheWxvckB0 bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBADOWdJFXVQvdVPUy4ChriEyS 3wiEdWmLb3CGko4ps7uXgHoCk0V9oU38LjKTrcm/KOhLhBh2Wz3LxirbtgTP+YxpgkPxDEWO ee/o/TiLhVrTLiqZJIwjlZmY1lTmHuoXWQK3M0MJZYVrGgMJgQg0/+mZkRlEa67N4WETh7MH rKglv3HHy3LeU835KA8cpMxRbDvPiA8wdKHWgrl4LXOJKtI8rgmMJxUOCQdgI6DSEo/yYve0 /TxLLBlWAhve7e+/aYjKn3V5CpNOmqkRi7V2d6ZJ+RMQrJDtqitQAkzq8cH+CSTGagHzAxQp e00hH+aVwNioyaoNBezCCLirOjVdlFIwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZP MA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEU MBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEu MCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODEx MDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExp bWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB /975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMa XqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpG EGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0 PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J 4K0AMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/ aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRo b3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRw Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVt MnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1G wmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrN xP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ 2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb5 33JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7 crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq 4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0 ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR 87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5Zgt wCLXgAIe5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhA53zcXtFD9dENby64EqrKqMA0GCWCGSAFlAwQCAQUAoIIC VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MDgwNDQz MjRaMC8GCSqGSIb3DQEJBDEiBCBhNm3/G40Jn2xagHZJtdwwMzD3p+MuNHC2eqE/B7YDlDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEDnfNxe0UP10Q1vLrgSqsqowgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGW MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA53zcXtFD9dENb y64EqrKqMA0GCSqGSIb3DQEBAQUABIIBAKOh2hjZZ/AjIkuDtrPhRtcs6eVczXAyMH5dvXtA fDA96koKn521B8z+mED9GHVnbuUxpXEk1SXQFWbIcAhjT66h4AlwFMOaREY5a4DH2yT1yWfE 0vVkzDBbFMFQ59DJHmI0P/SdhWgfEN7DOZLB9klYL7LbjeErQ6G99a6yWKu0CFQW4i10AqrH Zknjvw3Tz0Ttbi+ExVVYIenl6vjcI2EboOVR6re4RE8Y64Jcb0aa7gMyWToGlf8nomor+G00 rvcU+EEYJn+DNE28t3zmlBQhvMaHgPAlfD8amFzY/0dSelut1DiuNvkmvkvaM05yblwYApGn 4J/zXTipYYSyEHMAAAAAAAA= --------------ms000701010100000406050206-- From nobody Tue Jul 7 23:50: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 7DAAF3A0997 for ; Tue, 7 Jul 2020 23:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 dWAUGcmdXXfU for ; Tue, 7 Jul 2020 23:50:26 -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 C19A33A099A for ; Tue, 7 Jul 2020 23:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594191022; bh=06Lvo9yqFPhDR+CC/J/UasxTfsSVvZaWM4x+AhOCtjk=; l=504; h=To:References:From:Date:In-Reply-To; b=Au30oVfmgRN0HTPE+8cRO6PtuxRt9gs9/aRcST2vt9vZCGAQOsUDS5L9/TuvKduJP 3U03R5pMmSLGWIE6qrNh962n9TKTbX3oaWPKs7+R1OpxXRcKenRo/BTkYNCtL89vZC 0Lc4+RQej4viEdgJAUYlYAwCo/mTBRrLnBRtDYFRCXldXI3MjhD2FMHxfqztM Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005F056CAE.00002339; Wed, 08 Jul 2020 08:50:22 +0200 To: dmarc@ietf.org References: <5F04620C.10603@isdg.net> <5F04720B.4070606@isdg.net> <5ad304aa-3205-0cbf-f8bc-c418975bb37b@spamtrap.tnetconsulting.net> From: Alessandro Vesely Message-ID: <6ff1f9f8-08b5-dc71-a2c6-1a95ec6a1c30@tana.it> Date: Wed, 8 Jul 2020 08:50:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5ad304aa-3205-0cbf-f8bc-c418975bb37b@spamtrap.tnetconsulting.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Mailing List Digest Considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 06:50:29 -0000 On Wed 08/Jul/2020 06:43:24 +0200 Grant Taylor wrote: > On 7/7/20 7:00 AM, Hector Santos wrote: >> >> What if its set to 1? > > Mailman has the ability to ""wrap DMARC protected messages as an RFC 5322 > attachment to thee outgoing message.  This would be the 1-to-1 relation that I > think you are talking about. Contemplated as item 1.6, Message_wrapping, in the DMARC mitigation page[*]. Best Ale -- [*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail From nobody Wed Jul 8 00:08: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 18BE53A0BF0 for ; Wed, 8 Jul 2020 00:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cgazRKMw5Pm for ; Wed, 8 Jul 2020 00:08:45 -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 B2C6F3A0BEF for ; Wed, 8 Jul 2020 00:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594192123; bh=zT8PqSpJUWmalfR4h9tICA14JeojMYccgvIvfsT/NH8=; l=1396; h=To:References:From:Date:In-Reply-To; b=Dc88EcAa9uNmZND3+Fe21sswe5xUOSFp8DzBPlTPGWphgpvrloazogb3M01EGGNZW NzfSYMrB1VW5pqYtTSUVpP9sXbMohw26rsRHKxPldYyvOZRS+7uV1gj/lN7aKISAjH wNapyQ7mYjM5WzCc6nrM6KQhk3uAqqrbGCOrjw0jM2pl0VKAZ6F/j3Ro2w1IK Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.000000005F0570FB.0000257F; Wed, 08 Jul 2020 09:08:43 +0200 To: dmarc@ietf.org References: <20200706024251.8A4A41C598F8@ary.qy> <7e9587d6-89ca-3dc9-1d86-4e376e091fe9@gmail.com> <3129f12e02434273915ed6f91a998122@bayviewphysicians.com> <2cb64e63-dc8c-a32e-1296-d0bad4077a55@bluepopcorn.net> From: Alessandro Vesely Message-ID: Date: Wed, 8 Jul 2020 09:08:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2cb64e63-dc8c-a32e-1296-d0bad4077a55@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 07:08:47 -0000 On Tue 07/Jul/2020 19:08:48 +0200 Jim Fenton wrote: > On 7/6/20 6:15 PM, Douglas E. Foster wrote: >> >> About credible mediators: >> You are right that if an inbound email gateway believes a Mediator is >> credible, then all that is necessary is for the Mediator to prove his own >> identity.    But what is the mechanism by which a Mediator obtains the trust >> of the email gateway?   And by what mechanism does the Mediator know that the >> email gateway has determined it to be credible? > > My proposal is largely a simpler (I think) alternative to ARC for assessing > transformations. ARC also requires that the recipient's verifier have some > trust relationship with the mediator, perhaps through an as-yet undefined > reputation system. The phrase /secret sauce/ is sometime used to refer to methods used to establish MTA reputation. The need to keep ingredients secret is due to the ill-defined nature of the problem, whereby reputation can be gamed if its mechanisms are known. That's why it is, and will be, as-yet undefined. IOW, ARC is useful to a restricted number of large providers who are able to maintain a reliable reputation system. Do they need a simpler alternative? > Murray's reversible transforms proposal is yet another approach that does not > require trust to the same degree. Right, a deterministic method. Best Ale -- From nobody Wed Jul 8 01:21: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 E03303A0788 for ; Wed, 8 Jul 2020 01:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V-HMO57kNqD for ; Wed, 8 Jul 2020 01:21:29 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 B20803A0C57 for ; Wed, 8 Jul 2020 01:21:28 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id 17so1990436wmo.1 for ; Wed, 08 Jul 2020 01:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zgh7ysHOVwB3E1yEs6QwxvW06TAFtI23IiiZWZxxDG4=; b=UQ8NZlnRNcqCvioU5npW/aLPLcK/ueYj28eCgTqj5aAyCc0599Y97BawVEv1iLsLtq cUsi6622t2/12qOqmfcn9A799iW3t/shxKF99xHsIqCyl6T9Dh7Aj6PJyJzabtlqVrWD ErZKsbcEgoWWqzRePALRNEVsmR3c8XdGUM4ZvBjMTBQcVjbc7JColimTTfGvcufJVbfg q6oYglKYdb2y/0nsblZfc9t14vC+OGfT8fLyh3QClkGEgQvsofw3XVts+Qu9kMnP9Zdj +4sfggdUrQX9/rA0qMMTfaiPN3aVypGvRn8XLTWCyoih5yjtjzoJ40qRmjve6++8Y9AH MUuQ== 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=zgh7ysHOVwB3E1yEs6QwxvW06TAFtI23IiiZWZxxDG4=; b=qxDMQztdCsn4Zv3qnSdVw8cQQDjddcxNYHJkAT33WNPKrcYjgoURa56I9czjXqWRuz 6aC6txNGcj3d6p2hQ1gd0UEqxuVp1OFqYMB5edUDHtGPkebid06jKpvlJXqVe271oOHX 6ZspgUguGkSV4XxE1Xctz25kJV825dzCdjlqZyPAkj9m627JyO2e52GL4s8er9BVV8/8 O6EWbf72nG956YGLiQlkpehRqCDhAO2UUdpi/IMPgyFhJU0ejXx0TKI1O+ttbsBFvhFR vKgLSljRpbSyfrDXK7X4O0kXEGC/E6qdOojL0CDZgQlOD72vUsRFsoObYZ3CsTRxJa5R J9FQ== X-Gm-Message-State: AOAM530p85utceqsWIsfiizkxl3/7ZIbWoktK+ZShSsfKZ+tV+LUvYAa jUP7MJnVOBYju7MkWlQIdwt8fwpRKe2STx70OfI4CQ== X-Google-Smtp-Source: ABdhPJy5yKzRFi2z7uVO8Gm6HVfENUqBNWd/myuLhmpFMkKm//YQXau+Ka8YFZVy4bUIuBJQ2X9munPLScItrzaLqN0= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr7771127wml.36.1594196487220; Wed, 08 Jul 2020 01:21:27 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> In-Reply-To: <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> From: Dotzero Date: Wed, 8 Jul 2020 04:21:15 -0400 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000052af7e05a9e9cb50" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 08:21:32 -0000 --00000000000052af7e05a9e9cb50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2020 at 2:19 PM Alessandro Vesely wrote: > On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote: > >> There's a distinction though. ARC tells you "that guy over there said > the > >> original message passed", and you have to trust it. On the other hand= , > the > >> transformations draft, when it works, hands you the original message, > and > >> you don't have to make that trust assessment. > > > > I understand that, and I still don't see why it's useful. > > At what overhead cost? You have to hold the connection open while reversing the transformations or you are not in a position to reject (vs accepting then rejecting). There are folks currently holding the connection while evaluating the DKIM signature but that is lighter weight than reversing the transforms AND doing the DNS lookup to validate the DKIM signature. > > It would allow me, for one, to honor remote DMARC policies. Of course, > I'd > still need to manually whitelist non compliant MLMs. However, when the > number > of those drops below a reasonable figure, whitelisting might become > feasible. > > An interesting dependency. When might that reasonable figure occur? What is a reasonable number? Would other receivers agree with you on reasonableness? Should a standard be predicated on this basis? > > > It's hard to imagine a realistic situation where a recipient system > would > > strip off the changes and show the original message, so the recipient > has to > > trust that the mediator doesn't make malicious transformations. > > > Agreed. Undoing the changes has to be done on a temporary file, solely > for > verification purposes. Undoing the changes would be illegal, if the > footer > contains legal claims. > Your claim is interesting. What possible legal claims might an intermediator make that would be legally binding on a receiver and be illegal to undo in a temporary file for processing? Are you a lawyer? Are you a lawyer making such an assertion for all jurisdictions? > > > > So if you trust them that far, why wouldn't you also trust them to repo= rt > > the status of incoming mail? > > I cannot trust ARC operators, unless I manually compile a trusted list, > which > is as unfeasible as whitelisting each MLM. > Or you use a trusted list compiled by someone else. The use of blocklists such as Spamhaus ones or RPZ come to mind. > > I trust the original message as any other message. Allowed > transformations are > designed to not pervert the original message. Consider my notes 1 and 2 > about > l=3D, in a message upthread[*]. We can also specify limits on the size o= f > subject tags and footers. Transformations that insert stuff before the > original content should not be allowed =E2=80=94rewrite From: in such ca= ses. > This is getting unduly complicated. Now we have to hold up progress on the effort while folks argue out what the size limits on subject lines and footers should be? Michael Hammer --00000000000052af7e05a9e9cb50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2020 at 2:19 PM Alessandro= Vesely <vesely@tana.it> wrote:=
On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote:
>> There's a distinction though.=C2=A0 ARC tells you "that g= uy over there said the
>> original message passed", and you have to trust it.=C2=A0 On = the other hand, the
>> transformations draft, when it works, hands you the original messa= ge, and
>> you don't have to make that trust assessment.
>
> I understand that, and I still don't see why it's useful.


At what overhead cost? You have to hol= d the connection open while reversing the transformations or you are not in= a position to reject (vs accepting then rejecting). There are folks curren= tly holding the connection while evaluating the DKIM signature but that is = lighter weight than reversing the transforms AND doing the DNS lookup to va= lidate the DKIM signature.=C2=A0

It would allow me, for one, to honor remote DMARC policies.=C2=A0 Of course= , I'd
still need to manually whitelist non compliant MLMs.=C2=A0 However, when th= e number
of those drops below a reasonable figure, whitelisting might become feasibl= e.


An interesting dependency. When might = that reasonable figure occur? What is a reasonable number? Would other rece= ivers agree with you on reasonableness? Should a standard be predicated on = this basis?=C2=A0

> It's hard to imagine a realistic situation where a recipient syste= m would
> strip off the changes and show the original message, so the recipient = has to
> trust that the mediator doesn't make malicious transformations.

Agreed.=C2=A0 Undoing the changes has to be done on a temporary file, solel= y for
verification purposes.=C2=A0 Undoing the changes would be illegal, if the f= ooter
contains legal claims.

Your claim is in= teresting. What possible legal claims might an intermediator make that woul= d be legally binding on a receiver and be illegal to undo in a temporary fi= le for processing? Are you a lawyer? Are you a lawyer making such an assert= ion for all jurisdictions?


> So if you trust them that far, why wouldn't you also trust them to= report
> the status of incoming mail?

I cannot trust ARC operators, unless I manually compile a trusted list, whi= ch
is as unfeasible as whitelisting each MLM.

Or you = use a trusted list compiled by someone else. The use of blocklists such as = Spamhaus ones or RPZ=C2=A0 come to mind.

I trust the original message as any other message.=C2=A0 Allowed transforma= tions are
designed to not pervert the original message.=C2=A0 Consider my notes 1 and= 2 about
l=3D, in a message upthread[*].=C2=A0 We can also specify limits on the siz= e of
subject tags and footers.=C2=A0 Transformations that insert stuff before th= e
original content should not be allowed=C2=A0 =E2=80=94rewrite From: in such= cases.

This is getting unduly complica= ted. Now we have to hold up progress on the effort while folks argue out wh= at the size limits on subject lines and footers should be?

Michael Hammer=C2=A0
--00000000000052af7e05a9e9cb50-- From nobody Wed Jul 8 03:16: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 DA0DF3A043D for ; Wed, 8 Jul 2020 03:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Bko8hvXdj5xy for ; Wed, 8 Jul 2020 03:16: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 5D4603A00D4 for ; Wed, 8 Jul 2020 03:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594203360; bh=rbvwnJfHjZgzlVO0NqkujqC7Lb9RQx2hxyHXT3rFMmU=; l=5933; h=To:References:From:Date:In-Reply-To; b=DH0kzOQqFWDEq/gAQo75tSNiv8zLgR7oj6UVI2L72WbrpoglY0tJEqAW6L8UtMkhZ NDmBFKx3Log+P/qeQkTzW+0ot/9Vdp+xDh+82bSFN6+iqbxb11LZFDgtc/iOxl+9yv F+48Rtu+xA+I1+g96wN1Da3slV+KG+QN9DOC37V50eay21j+fZSjjmbKCCSGj Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F059CE0.00003B6B; Wed, 08 Jul 2020 12:16:00 +0200 To: dmarc@ietf.org References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> From: Alessandro Vesely Message-ID: Date: Wed, 8 Jul 2020 12:15:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 10:16:08 -0000 On Wed 08/Jul/2020 10:21:15 +0200 Dotzero wrote: > On Tue, Jul 7, 2020 at 2:19 PM Alessandro Vesely wrote: >> On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote: >>>> There's a distinction though. ARC tells you "that guy over there said the >>>> original message passed", and you have to trust it. On the other hand, the >>>> transformations draft, when it works, hands you the original message, and >>>> you don't have to make that trust assessment. >>> >>> I understand that, and I still don't see why it's useful. >>> > > At what overhead cost? You have to hold the connection open while reversing > the transformations or you are not in a position to reject (vs accepting > then rejecting). There are folks currently holding the connection while > evaluating the DKIM signature but that is lighter weight than reversing the > transforms AND doing the DNS lookup to validate the DKIM signature. In principle, reversing the transformation shouldn't be more complicated than verifying a signature with l=. Skipping the subject tag while canonicalizing the header is not much more work than adding \r to each line (at mine, lines are terminated by a bare \n.) The addition of an entity may require to skip an initial part of the body, and then stop at the corresponding boundary. It can be considered a refined canonicalization, negligible w.r.t. cryptography. >> It would allow me, for one, to honor remote DMARC policies. Of course, >> I'd still need to manually whitelist non compliant MLMs. However, when >> the number of those drops below a reasonable figure, whitelisting might >> become feasible. >> >> > An interesting dependency. When might that reasonable figure occur? What is > a reasonable number? Would other receivers agree with you on > reasonableness? Should a standard be predicated on this basis? Nowadays, I honor remote DMARC policies on a few domains only, (paypal, amazon, and the like.) I cannot switch to the opposite behavior, to honor DMARC globally except for a few exceptions, because From: rewriting is considered dirty and there is no other way for MLMs which need to have a footer. IOW, DMARC is broken. If we predicate a standard which makes it possible for MLMs to comply, then honoring DMARC becomes possible. MLMs which don't comply can result in missed messages until receiving MXes whitelist them. Those glitches are justified because the culprit is the MLM in that case, not the MX. When there are enough examples of working mailing lists, that kind of explanation may sound acceptable to users. >>> It's hard to imagine a realistic situation where a recipient system >>> would strip off the changes and show the original message, so the >>> recipient has to trust that the mediator doesn't make malicious >>> transformations. >> >> >> Agreed. Undoing the changes has to be done on a temporary file, solely >> for verification purposes. Undoing the changes would be illegal, if the >> footer contains legal claims. >> > > Your claim is interesting. What possible legal claims might an > intermediator make that would be legally binding on a receiver and be > illegal to undo in a temporary file for processing? Are you a lawyer? Are > you a lawyer making such an assertion for all jurisdictions? IANAL, but I heard that argument by MLMs holding they cannot just omit any changes because blah blah. There are also forwarders who want to add disclaimers or spam reporting directives as a footer. Tampering with the mail they send sounds likely to be an offense in a number of countries. Of course, the same allegation can be made about the transformations they applied in the first place. However, MLMs should have managed to get subscribers consensus to do so. To endow a message with instruction to revert transformations should not imply an authorization to deliver the message with those transformations removed. The deal should be to supply that data for signature verification *only*. >>> So if you trust them that far, why wouldn't you also trust them to >>> report the status of incoming mail? >> >> I cannot trust ARC operators, unless I manually compile a trusted list, >> which is as unfeasible as whitelisting each MLM. >> > > Or you use a trusted list compiled by someone else. The use of blocklists > such as Spamhaus ones or RPZ come to mind. Yeah, I use both those blocklists. I also use dnswl, which actually can be configured as a filter to prevent applying DMARC policies. I only use it to prevent SPF reject-on-fail. The difference between SPF and DMARC is that the former has other means to do the right thing, so that dnswl works as a second level savior. The standard should describe a few (deterministic) ways to be DMARC compliant. At the moment we only have From: rewriting, which is not even specified. I proposed to use To: instead of From:, which would be interesting to experiment. Murray's transformations is yet another way, particularly nice as it would allow mailing lists like this one to resume working the way they used to. >> I trust the original message as any other message. Allowed >> transformations are designed to not pervert the original message. >> Consider my notes 1 and 2 about l=, in a message upthread[*]. We can also >> specify limits on the size of subject tags and footers. Transformations >> that insert stuff before the original content should not be allowed >> —rewrite From: in such cases. >> > > This is getting unduly complicated. Now we have to hold up progress on the > effort while folks argue out what the size limits on subject lines and > footers should be? It should not be allowed to insert text long enough (including trailing spaces) to push the original subject out of view. I don't think determining this number is the hardest part of the spec. Best Ale -- From nobody Wed Jul 8 09:05: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 4174C3A0F02 for ; Wed, 8 Jul 2020 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcjUx2-hx5y2 for ; Wed, 8 Jul 2020 09:04:42 -0700 (PDT) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 664A63A0EEF for ; Wed, 8 Jul 2020 09:04:42 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id d198so3450500vsc.1 for ; Wed, 08 Jul 2020 09:04:42 -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=plslv+cNON7193VKFaRXH5Nr4mmuLuSM670iiz32DVA=; b=KSv2cpchS6bo5VEQG8AyadOwCH+Jh8bPwI8Weiz9XjZ1SDTFCBSpUStXWQ1GYZpjV+ EZ9NYHOGgW85Diiomd7vJ6T3uys+EAS5MCjhEgbUhgSJpUB7Ja6gnb4cams9mfKIUw53 nmk7cILmMgTJXh+U78p3JmE3JPlOp4Ot9Dvh8vSNBhXTmpXQ/SvIr1QbeIaNrej4XCzH KJNzoH67tG6kH/ekmnWkP+W2iH9fE9hPcJ34uPRY1LLnn5x+xz4NjyL1nhqBz79xvpHP KnjtDNA2Eq8F9j+X8KxUEh1ZjZr4i1clLP2R6COTo+u71JgKp67McvNJF3bN7DtosC7Q YW2Q== 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=plslv+cNON7193VKFaRXH5Nr4mmuLuSM670iiz32DVA=; b=i+w6YovwEX17zkO08kAdkGOPt5n1ioasxoOI4DY/As69iWHOb7fCr/CZ8o1hU6Ec2U 7U0v/gaPMN139KwbIHDCVBK/1KG2Lv+xzEZZJviIDMFRmmt9ub4FFxuE8UyL8CpNiye4 ryQFgstvl1udAaywYUlhliZJQl+e7RQyrhrHjdQQJZWlQZMVqrYHYzhiSU11ob3KreyX KiP4clMx6opodbtUFYE8E/jgFvZzgv3/xxABZ9a3Cke+5kXt4CqpOMkCpTXIiPsRiddz gGvz8fvkiBtND/MKy6LyXShuM6p6tdoHuleJAMCduMcq47Iv3osDBuDqSV0mi1IvLMCb S06w== X-Gm-Message-State: AOAM533eSC6lY3LJ9xM/ysk47OgFdeSsL+SxyG46/2glueAt2VtmiRu1 icIlAeIbIW7JMdYV6xHjHKPOg8h3LSHPmsQ5g0E= X-Google-Smtp-Source: ABdhPJyppfXeeoPgMV8LzHmIAKNS3mRRSl+939i9k5IeydyDTqymHabBf2YjHi30rC6SeseXHlSjf58FCxzSjkXcfSE= X-Received: by 2002:a67:f60c:: with SMTP id k12mr32940202vso.8.1594224281286; Wed, 08 Jul 2020 09:04:41 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 8 Jul 2020 09:04:28 -0700 Message-ID: To: Dotzero Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fa7c8005a9f04312" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 16:05:04 -0000 --000000000000fa7c8005a9f04312 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote: > At what overhead cost? You have to hold the connection open while > reversing the transformations or you are not in a position to reject (vs > accepting then rejecting). There are folks currently holding the connection > while evaluating the DKIM signature but that is lighter weight than > reversing the transforms AND doing the DNS lookup to validate the DKIM > signature. > That seems to imply DKIM, which relies on DNS and cryptography, is more heavyweight than reversing text transformations, which relies only on the local CPU and memory and probably arithmetic. I'm not sure I agree. -MSK --000000000000fa7c8005a9f04312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 8, 2020 at 1:21 AM Dotzero &l= t;dotzero@gmail.com> wrote:
=
At what overhead cost? You have to hold the connec= tion open while reversing the transformations or you are not in a position = to reject (vs accepting then rejecting). There are folks currently holding = the connection while evaluating the DKIM signature but that is lighter weig= ht than reversing the transforms AND doing the DNS lookup to validate the D= KIM signature.=C2=A0

That seems to im= ply DKIM, which relies on DNS and cryptography, is more heavyweight than re= versing text transformations, which relies only on the local CPU and memory= and probably arithmetic.=C2=A0 I'm not sure I agree.
-MSK
--000000000000fa7c8005a9f04312-- From nobody Wed Jul 8 09:43:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625603A0F3D for ; Wed, 8 Jul 2020 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmlIs781KP5w for ; Wed, 8 Jul 2020 09:42:57 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 C96C23A0F3C for ; Wed, 8 Jul 2020 09:42:57 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id u133so11294813vsc.0 for ; Wed, 08 Jul 2020 09:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ldR8s8l1RFXC2GiEDT8oV4kZjCJPP6r9zu8NMUoMW2c=; b=tXGpxUYNZpY97438oEKfe7T04MHdZd7O7mwgN9TjTVgtlkv1aBOq8I29jQgelJdhzs WiKM53j0VINj4sHYPMDl+2MlGf/0SNtodKKWKjqqldYxXqXEm1xgNnENDPiDbwP0pxh/ PHOOuqjZsmPxTVRACbKamWV3gs3Sp9Qv8DLV7weSFo3c462zMkf6ePNPgW9/9oxN8TpL WSfz5/IQYJ0edLwKXqrBfatU6GGo6XjNBNwY7ZA3cuwQOlDHjC/xORbyJoN5z1cvnjYI X5gndMBtgkg3rJ6yj4NyEMmifyFQXHwWkRJSMkzAl5MJZTk3Vcnyr1f1yGFgoZOlTAnm p28g== 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=ldR8s8l1RFXC2GiEDT8oV4kZjCJPP6r9zu8NMUoMW2c=; b=qGH8tO0tuqA/jTqsMw14tDhPvdToe3BAspihtDPiHMPAOm+tBAkOz2LYgmXdOAp579 Ukyise9m6IERTLxP8PFDMj1+48lr/+60yuox3+nttzcuhJCiovEtbX1kma4DwXzIFcXI OKwYfjGKfnI/iXxwt7yQKAH15I7sD0DMs7SmQA77lwxDr4EZczM9GuxtPCFJqWV51jsE XA7+HIQex+xyU/0UDZbVoc7owpGBNLs2yQP7LZMT5OddWDEi7lD305uiiJasTE+CDgB6 ayaUggEYbvu0Nv+DFmfThUIzSH2Sh9bvVRTN7K6de9Wwi/215WfbDE7bDlIunA+EjCJp 25/A== X-Gm-Message-State: AOAM530OciH9VuugCWGI2zjobIfM2JzZSHx6JsMASMwAp01QP7iFySCk GInYmGE7M0pgDCLsRuYZDXfyDmvCaytyEhqY6e4= X-Google-Smtp-Source: ABdhPJyZmJDhk4bqQEYT3GZTIKzhCGOt+UZZnrqofRDsLxD/cie4fUHzKYOcPjuaGP1xzxZWTUKteukmdwidYwRvbnQ= X-Received: by 2002:a67:fd15:: with SMTP id f21mr7926826vsr.7.1594226576669; Wed, 08 Jul 2020 09:42:56 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 8 Jul 2020 09:42:44 -0700 Message-ID: To: Dotzero Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cb413d05a9f0cc65" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 16:42:59 -0000 --000000000000cb413d05a9f0cc65 Content-Type: text/plain; charset="UTF-8" I'm sorry, I got that backwards. What I meant to say is: On Wed, Jul 8, 2020 at 9:04 AM Murray S. Kucherawy wrote: > On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote: > >> At what overhead cost? You have to hold the connection open while >> reversing the transformations or you are not in a position to reject (vs >> accepting then rejecting). There are folks currently holding the connection >> while evaluating the DKIM signature but that is lighter weight than >> reversing the transforms AND doing the DNS lookup to validate the DKIM >> signature. >> > That seems to imply DKIM, which relies on DNS and cryptography, is LESS heavyweight than reversing text transformations, which relies only on the local CPU and memory and probably arithmetic. I'm not sure I agree. -MSK --000000000000cb413d05a9f0cc65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry, I got that backwards.=C2= =A0 What I meant to say is:

On Wed, Jul 8, 2020 at 9:04 AM Murray S.= Kucherawy <superuser@gmail.com> wrote:
At what= overhead cost? You have to hold the connection open while reversing the tr= ansformations or you are not in a position to reject (vs accepting then rej= ecting). There are folks currently holding the connection while evaluating = the DKIM signature but that is lighter weight than reversing the transforms= AND doing the DNS lookup to validate the DKIM signature.

That seems to imply DKIM, which relies on DNS and cryptography, is LESS hea= vyweight than reversing text transformations, which relies only on=20 the local CPU and memory and probably arithmetic.=C2=A0 I'm not sure I = agree.
=C2=A0
-MSK
--000000000000cb413d05a9f0cc65-- From nobody Wed Jul 8 13:09:02 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 4B6FC3A07AC for ; Wed, 8 Jul 2020 13:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSVWDYkezEAD for ; Wed, 8 Jul 2020 13:08:58 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 8DD9E3A077D for ; Wed, 8 Jul 2020 13:08:58 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id l2so4480577wmf.0 for ; Wed, 08 Jul 2020 13:08:58 -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=KgSYi3BODv/VePzSvAZpxTVlLIR92LSxiL24lsuP970=; b=pR6ch09PeyaPDk4A+YK80GpiOwfPAUYuIp2I7dlJBccaYNIrPdAVTNgIxjZP7bYKmd 5HkUGi0TYH8qiwB+hC/doRPz+hpK2gT80BDruSAWvkHYOyQqSA4WXjveysG+hLHypiM2 R3cQYjOc+qOQtRnAjqcUrHGmqKSFyanSSLrSEPXHQwJUA6/gN+9Sb7hn8TDORQdpzDBM 3QCsD2pdEBunIND62ai6no/CcswrruKvkMt6oyHEE/TwNVMJh8UFFkuiDmgSDY3Px4oY ZNYv+n/3CwoRaVRgVQ3LYZW9Y6Yx5oT3Om9AvzcXKCLEExxFBGFTcm4RhkeDn0N3/FSj eUhQ== 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=KgSYi3BODv/VePzSvAZpxTVlLIR92LSxiL24lsuP970=; b=HwwdlFhU9QqcLxzuEg8xENvN2/uVNugH1V7/v3Lb292osYBLPZA8UTpl/GvlQkSQq+ u8LkiOCEwls1G2pvAOWKrVGgwwf5wz/TZngnD1ksLaemVlQ7E7soT60wG08KKl5r8dyO VieGOwIeYEeOCOPLUbdbGR/CESsQZtVXqpUzoLDWvj99HFAFxm2fdpMhwTn4t7QjpBLg Zco/3KONKHQN8WyqnCdSCwHJkoVZOxKLRqkm0MomPH5vLu0oV58FdaOdN+7LcD8oWmip pQ0tleWJK0wp6mztmA/XMppWtPTjbqK4sHxpQ5bBFUI34DaQseznrpakPHak16ANC9sO yFEQ== X-Gm-Message-State: AOAM530V/4FR4EHzLteFx2PX/IiMV2UuE+QbsWCcMfIfKcQ3bO8O+6Z0 +SPG0R7fs2PUYBQCtH9bpBo9TgT1HleiUDhzXHE= X-Google-Smtp-Source: ABdhPJw2N4twxYb2k51r3glojFt622U/WIi0Ev5Tz/XsH0Q8SRBOg1muDMKIv/Tm+eG3ariLHvT5lUTkDqEAPQi74Rs= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr10458833wml.36.1594238937119; Wed, 08 Jul 2020 13:08:57 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> In-Reply-To: From: Dotzero Date: Wed, 8 Jul 2020 16:08:45 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000088c2e705a9f3ad26" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 20:09:00 -0000 --00000000000088c2e705a9f3ad26 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 8, 2020 at 12:42 PM Murray S. Kucherawy wrote: > I'm sorry, I got that backwards. What I meant to say is: > > On Wed, Jul 8, 2020 at 9:04 AM Murray S. Kucherawy > wrote: > >> On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote: >> >>> At what overhead cost? You have to hold the connection open while >>> reversing the transformations or you are not in a position to reject (vs >>> accepting then rejecting). There are folks currently holding the connection >>> while evaluating the DKIM signature but that is lighter weight than >>> reversing the transforms AND doing the DNS lookup to validate the DKIM >>> signature. >>> >> > That seems to imply DKIM, which relies on DNS and cryptography, is LESS > heavyweight than reversing text transformations, which relies only on the > local CPU and memory and probably arithmetic. I'm not sure I agree. > > Once you reverse the transformations you would still need to do the DKIM lookup to validate the reversed text that was signed. Simply reversing the transformations without validating doesn't give you much of anything useful. Michael Hammer. --00000000000088c2e705a9f3ad26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 8, 2020 at 12:42 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
I'm sorry, I got that backwards.=C2= =A0 What I meant to say is:

On Wed, Jul 8, 2020 at 9:04 AM Murray S.= Kucherawy <sup= eruser@gmail.com> wrote:
On Wed, Jul 8, 2020 at 1:21 AM Dotzero <dotzero@gmail.com> wrote:
At what overhead cost? You have to hold the connection open whil= e reversing the transformations or you are not in a position to reject (vs = accepting then rejecting). There are folks currently holding the connection= while evaluating the DKIM signature but that is lighter weight than revers= ing the transforms AND doing the DNS lookup to validate the DKIM signature.=

That seems to imply DKIM, which relies on DNS and cryptography, is LESS hea= vyweight than reversing text transformations, which relies only on=20 the local CPU and memory and probably arithmetic.=C2=A0 I'm not sure I = agree.


Once you reverse the transformations you would still n= eed to do the DKIM lookup to validate the reversed text that was signed. Si= mply reversing the transformations without validating doesn't give you = much of anything useful.

Michael Hammer.=C2=A0
--00000000000088c2e705a9f3ad26-- From nobody Wed Jul 8 15:37: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 B185B3A087B for ; Wed, 8 Jul 2020 15:37:09 -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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjoO4YYCy_YK for ; Wed, 8 Jul 2020 15:37:08 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F39B3A0879 for ; Wed, 8 Jul 2020 15:37:08 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:f5be:b3ff:b365:52ca]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 068Mb6Ce002687 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 8 Jul 2020 15:37:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594247827; bh=3bsvKViMI+sUXhjgTmpNcWX0v9liMw+e1DV4KNzGbDk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bQWux5aWTTMtFojnH/z9m9TVfW4Yj2DZZO/uHiWp7MSgV94rfJHSuo7dXTsApOJsJ YAAUpaJbTigeZkQ1eZx0a5PnhijsKT1H7NSbD+c8ZeQjP+UiTfxsftLljlSKWXSeiu DvkpG/q9asri1gZ9QNbH/c+u7JiegMuhLf3ggxIo= To: dmarc@ietf.org References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <304a73c6-fac4-f939-93be-507d5385cc61@bluepopcorn.net> Date: Wed, 8 Jul 2020 15:37:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------00314B75A32C54619EAEE048" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 22:37:10 -0000 This is a multi-part message in MIME format. --------------00314B75A32C54619EAEE048 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/8/20 1:08 PM, Dotzero wrote: > > Once you reverse the transformations you would still need to do the > DKIM lookup to validate the reversed text that was signed. Simply > reversing the transformations without validating doesn't give you much > of anything useful. DKIM lookup: do you mean the key retrieval? If so, that can be done in parallel with any of the transformation stuff, which is all local computation. -Jim --------------00314B75A32C54619EAEE048 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/8/20 1:08 PM, Dotzero wrote:

Once you reverse the transformations you would still need to do the DKIM lookup to validate the reversed text that was signed. Simply reversing the transformations without validating doesn't give you much of anything useful.

DKIM lookup: do you mean the key retrieval? If so, that can be done in parallel with any of the transformation stuff, which is all local computation.

-Jim


--------------00314B75A32C54619EAEE048-- From nobody Wed Jul 8 18:03: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 6BA823A0AD1 for ; Wed, 8 Jul 2020 18:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr0EyzZcOIBE for ; Wed, 8 Jul 2020 18:03:53 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 141943A0ACF for ; Wed, 8 Jul 2020 18:03:53 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id b77so205659vsd.8 for ; Wed, 08 Jul 2020 18:03:52 -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=un0IvqWdxkDep88aNQn5iHaS1QnxveFzCkqvrh6bVq8=; b=LivPDdtZo8KvHUdsMu1J6R4xzEioVeZV5fCwRCjrAIDdSKwlkQoAOjoO8HT3kG7kLB U8v9+m9zBrYRu7fNSPyZNwPxcksGPIDwLqq4MhuznTX9NVKwsDTtEOGgpj2w+Q114t1Y DHuXB4KWrTjNLv1/XkJlenoQwmEzWu//1DnhNIVpPF2k5eTg6V/bgzwxCXKQHuytYDk+ 4nnP1Jr8FJx2DP8bQwqpdMab0r9erp5S8K+zLbgQsoHrwRBNDS0ltrY8EDP7K6iNuQmG AxzgVwYFYDiVsn3TCZDMXH6A/gWBCIfxZZE/BCC6ZK/dbGiUnQZS+ufrkFROk8YPhGXF hMCg== 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=un0IvqWdxkDep88aNQn5iHaS1QnxveFzCkqvrh6bVq8=; b=IsYhQHTocxuNk65i5RcHuemDwJ8UzIhyfEriJRDA9DEwkbIFNVpdPlrqek9xivUmCv 4m7ZhwFld4SK5ihm1EKJ692ER9B9EnJkLrQUh8kP/lYS6mIrPDsaF6CCpF9YsKhDvuK5 aQPvYZX8JDfgKczemZX7XrQKTFSdENvrCchWwSOxFbFV1ofsZRXNDpVhBCwgtoFvwfD4 72nRvG8wz3qgPabcrTDVZvG97wYnqUT0+dwMD+vxGmX1w24xFHf2cwFVfls7mkSOxZ5l LGfa6cyB/DMWKMoM8urfsIb34IIv4ikf+eyVlgcgiHpt03TCweYPkmm8HJ9rrnUNbgdR PKlQ== X-Gm-Message-State: AOAM533Vf8ult+IbkFRUFnzElWNrRsc/jCpXKJxMAEC7IlNDL/mSz8Ha HO/tDadXAc9YBbUwnO4K6dnrojzNug7kwqBSACx9ew== X-Google-Smtp-Source: ABdhPJzZsA1u50FexsTpCkKpnyRpl732XuRo6R6ogFugOYCqtTkebO18JE/SOTpZh60X+yOfeXxTDZF4aoVlNUUMfTQ= X-Received: by 2002:a67:ed15:: with SMTP id l21mr45363922vsp.175.1594256631861; Wed, 08 Jul 2020 18:03:51 -0700 (PDT) MIME-Version: 1.0 References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 8 Jul 2020 18:03:40 -0700 Message-ID: To: Dotzero Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000391c2905a9f7cc02" Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 01:03:54 -0000 --000000000000391c2905a9f7cc02 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 8, 2020 at 1:08 PM Dotzero wrote: > > That seems to imply DKIM, which relies on DNS and cryptography, is LESS >> heavyweight than reversing text transformations, which relies only on the >> local CPU and memory and probably arithmetic. I'm not sure I agree. >> > > Once you reverse the transformations you would still need to do the DKIM > lookup to validate the reversed text that was signed. Simply reversing the > transformations without validating doesn't give you much of anything useful. > Of course, but both DKIM signatures will be validated with or without this proposal, which requires processing the entire message body anyway. A sub-optimal flow might be: - validate the MLM signature; it passes - validate the author domain signature; it fails - notice the MLM signature (which validated) has a "tf=" tag saying "subject,footer" - search the body backwards until you find the delimiter, and toss away everything after that, which undoes the "footer" - un-mutate the Subject - re-validate the author domain signature (you don't have to repeat the DNS stuff, it's cached); it (in theory) passes You could maybe do clever tricks like notice that "tf" is there and apply the reverses inline as you process the author signature, saving you a repeat verification pass. In any case, now you know the same thing ARC told you, but you didn't have to do more crypto than just the two DKIM signatures than you were going to do anyway, and you avoid larding the header as ARC does. I have less confidence in the expense of the MIME un-transformations because I've never implemented them specifically. I could take a run at it but there are probably libraries out there that do a better job than I would. -MSK --000000000000391c2905a9f7cc02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 8, 2020 at 1:08 PM Dotzero &l= t;dotzero@gmail.com> wrote:
=

That seems to imply DKIM, which relies on DNS and cryptography, is LESS hea= vyweight than reversing text transformations, which relies only on=20 the local CPU and memory and probably arithmetic.=C2=A0 I'm not sure I = agree.

Once you rever= se the transformations you would still need to do the DKIM lookup to valida= te the reversed text that was signed. Simply reversing the transformations = without validating doesn't give you much of anything useful.

Of course, but both DKIM signatures will= be validated with or without this proposal, which requires processing the = entire message body anyway.

A sub-o= ptimal flow might be:

- validate th= e MLM signature; it passes
- validate t= he author domain signature; it fails
- = notice the MLM signature (which validated) has a "tf=3D" tag sayi= ng "subject,footer"
- search = the body backwards until you find the delimiter, and toss away everything a= fter that, which undoes the "footer"
- un-mutate the Subject
- re-va= lidate the author domain signature (you don't have to repeat the DNS st= uff, it's cached); it (in theory) passes

<hand_waving> You could maybe = do clever tricks like notice that "tf" is there and apply the rev= erses inline as you process the author signature, saving you a repeat verif= ication pass.=C2=A0 </hand_waving>

In any case, now you know the same t= hing ARC told you, but you didn't have to do more crypto than just the = two DKIM signatures than you were going to do anyway, and you avoid larding= the header as ARC does.

I have less confidence in the expense of the MIME un= -transformations because I've never implemented them specifically.=C2= =A0 I could take a run at it but there are probably libraries out there tha= t do a better job than I would.

-MSK
--000000000000391c2905a9f7cc02-- From nobody Thu Jul 9 02:50:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D03A0033 for ; Thu, 9 Jul 2020 02:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZKYLCpw464P for ; Thu, 9 Jul 2020 02:50:33 -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 4613A3A0028 for ; Thu, 9 Jul 2020 02:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594288229; bh=LFJXKUOQJRGhtj8x9SzCmBu+NsT9+G/aqf1HAuCjw14=; l=2971; h=To:Cc:References:From:Date:In-Reply-To; b=DIWe2ffrjQ0d1lIVryJxUZ2Uiw+qb2Sj565FtCQYXG342a8GEXmIszLhAOP3NAEvu /njz/t3Jw7fv30hb/06dSCzlteBS8uatwydrplSEbLEfb2mfH/ag1AvIPm4ISP47ka pOFA7Sw0TmrfpZFGpHhGxgkXVwDTNDBDN2DoNpgSvuyLnryz9CMHuUOOP5yPZ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.000000005F06E865.00002892; Thu, 09 Jul 2020 11:50:29 +0200 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200706181847.79A001C5D093@ary.qy> <7c1baa62-5c58-0021-e80f-8f4ed431a7c2@tana.it> From: Alessandro Vesely Message-ID: <692ef2c3-0db9-4411-4a51-237927436f06@tana.it> Date: Thu, 9 Jul 2020 11:50:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 09:50:35 -0000 On Thu 09/Jul/2020 03:03:40 +0200 Murray S. Kucherawy wrote: > > A sub-optimal flow might be: > > - validate the MLM signature; it passes > - validate the author domain signature; it fails > - notice the MLM signature (which validated) has a "tf=" tag saying "subject,footer" > - search the body backwards until you find the delimiter, and toss away everything after that, which undoes the "footer" > - un-mutate the Subject > - re-validate the author domain signature (you don't have to repeat the DNS stuff, it's cached); it (in theory) passes > > You could maybe do clever tricks like notice that "tf" is > there and apply the reverses inline as you process the author signature, > saving you a repeat verification pass. > > [...ARC comparison omitted...] > > I have less confidence in the expense of the MIME un-transformations > because I've never implemented them specifically. I could take a run at it > but there are probably libraries out there that do a better job than I > would. It'd be a stroke of luck to find a library which does exactly that. Ned's note about the design of such tools applies here too. However, it doesn't seem overly difficult to do it from scratch. Let's consider a sample multipart message body, indented for legibility: --added-boundary Content-Type: ; boundary="original-boundary" [...original preamble...] --original-boundary [...original header and body...] --original-boundary-- [...original epilogue...] --added-boundary [...added footer...] --added-boundary-- [...epilogue...] Assume for simplicity that the author did not sign Content-Type:. Knowing there's an added boundary, you can skip the initial part of the body, start canonicalizing at the first entity's body, and stop at the next appearance of "--added-boundary". In addition, you must also check that there are no entities before the original part. So, all you need to know is that the original message was multipart. MLM code probably needs some rewriting in order to ensure that the original preamble and epilogue are kept intact (and without adding extra empty lines.) Some rewriting is also needed to avoid gratuitous header changes. I tried the above procedure manually on the message I'm replying to. It failed because the original message has: Cc: Alessandro Vesely , IETF DMARC WG whereas the published copy has: Cc: IETF DMARC WG , Alessandro Vesely For text/plain messages, instead, all you need to know is the length of the original message. If the author signed with l=, no action is needed. In both cases, the body hash can be done in one pass, except if the body is converted to base64 encoding. This list often, but not always, does such wrapping, and then signs the message again. Dunno if that's a feature or a bug. Best Ale -- From nobody Fri Jul 10 15:22:25 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 EB3D43A0B5B for ; Fri, 10 Jul 2020 15:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=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 jufLQ-JfbaIm for ; Fri, 10 Jul 2020 15:22:21 -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 ED0F13A0B41 for ; Fri, 10 Jul 2020 15:22:20 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2173.outbound.protection.outlook.com [104.47.57.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QD900LN3Y57FG40@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 10 Jul 2020 17:22:19 -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.7.10.221518, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.18.5740001, SenderIP=[104.47.57.173] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=anDRod8g0TS+czIItQwFFeATjk+0KztoYlCjkk+/CxAtCXCmZKZWL888jmF8HEvm9U5vHv9h0yWgO6opAY7HaCDZjz9W36mJ+S75HJRFmI6yA0WVWSFyHbHJXrE+Ru9/TYGHwQdwIRLxv9pvz4Wwsa0Fg69tPUNg5t3/SYCKLzXD8URhcLnBy2TZWdm80aBJNBjyTW/c1sM2W0g8j9ntppSTZoFXGemNf8dk9+TOu7YCj4dYqV3RGCDMqbzBsw33ByTo9evpBPQbrbQxjJWXQGfcqdhqsIXBgVC80+8eHOTlYLX/vnSST0+YqND4YUIE38dVwikbs0WwTHqqitlrng== 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=wTjVpfc9/pG9rh3JEW2p15Mkylze6SA1V68NJCeXbeE=; b=ajFsWrlqV5tk2ZXIGF2jSCR6cc3ZJ9Sxpc8fIP/kIzVhzkacKi8ScEVEn+27rVZzkF8ZjWTbK1oHwJnyXb2ETl5aQ3J7BQgzf9ar/r4e7yg9RtFb9a3Tsu4hvqBJI65ODJ8Ea9maF2okOIzfIEqcZEJCKBUXYb9jMwouUWsNXS/ZqFlMSLN3XqntvzshFpeQczpBquJ0OCsurxw69/LzvBT/8MyOoeUQC1y62DLMGRcsH0wPq5412A1ZMkp8g2JSxunMnocIfIfjQf5ysfY9FiPLjkNGsRFhtgX6H549A8crNDmIkwciGMmb3qgnHZSLPnHAzy7eyGwMBF43r1wAYA== 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=wTjVpfc9/pG9rh3JEW2p15Mkylze6SA1V68NJCeXbeE=; b=OaT837006gTP0xy48AgHZgQo1h+GpcWeN8UsWUQs/RJmMH6UHJXI4zLg/moueOwogRMJEt8+UQZ0ECGZ1AXC8HjKe/Q/hT4RBZ0jMoTO5W66NLhlxeR1Ry/nXHvt5TMYTDFZFj5rMAt+znBPkEWZ96ubL7WPeF/yeE03v6GJOcY= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB6508.namprd06.prod.outlook.com (2603:10b6:5:25f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Fri, 10 Jul 2020 22:22:18 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3174.023; Fri, 10 Jul 2020 22:22:18 +0000 To: dmarc@ietf.org References: From: Jesse Thompson Message-id: Date: Fri, 10 Jul 2020 17:22:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR17CA0021.namprd17.prod.outlook.com (2603:10b6:610:53::31) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR17CA0021.namprd17.prod.outlook.com (2603:10b6:610:53::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22 via Frontend Transport; Fri, 10 Jul 2020 22:22:17 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 77f533ba-5676-458e-3251-08d8251fb4ba X-MS-TrafficTypeDiagnostic: DM6PR06MB6508: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3826; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QFoxbHDcj87+E0XKnHBHcy0b8vszwdV6mmzvCaAbbOggXO7XTfcQLEEOwtpUchXQl4rOqdjORh1qlNnaEF8TxwMbBVewmbMgUfEw3HRL9FHeoPmjY67l/U/aj/f1MYFfYKOmxHmrELbQHw4GPoixbeGT3gYU8wI1JKFSl15VO0wEgi0f93LZvx2aQa8ifseEmvKPIsN5njWHU1lftOeswboALXzOhtxkSlFBde8WeZ+1mQ+1eaqjWOHdATHM6dN508HTIGYyfLvivij55wmtzyQTE1XjhlHdjsfqprcSXF5HBQeHYpwMRcq3U/A2l+WwmTjTm4QGYwx28NLMdy9VqpE5XoCsEUJHc5HFUQ6qFzDfPfN2eV2FipQKH3MfhXpgBv4ONPYBjSs/PixomwlcL/du72ChMoSlA4uIgymsn4E= 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; SFTY:; SFS:(346002)(396003)(376002)(136003)(39860400002)(366004)(316002)(786003)(66946007)(53546011)(31686004)(16576012)(75432002)(8676002)(2906002)(956004)(6486002)(31696002)(8936002)(44832011)(2616005)(16526019)(36756003)(86362001)(83380400001)(478600001)(66476007)(66556008)(6916009)(5660300002)(6706004)(186003)(26005)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: TH/4cocaAIoh6/CdnBP4M3FIl+Rv8BATxec0pf1hTU9zCa6szLXHp3I5yqyVpB/dQzM6SBEw8oSqebyYnX1aVyx8fLdW0TpGExv3OpLP5OWJjVHyLvKYsz0/GQc3fVMb3gDS3KS5fxJHLAvHNA3AFtIYPkY9hvg1Xz4YYRnZI0wQnmDlMKQULuiPEiWQBjwW+PlUJgGjXTa8QfVQpubUMt+ULuu/79CUIjEw0wMSZl3MZg6aLNxZlqh8QPC59mZ/Q2GFq8IPLBDQpJYbYPgLbhAtMelYXm6+OZM66bVSGfDFeFwHxHqBXbY3PONKHvO7ry4mE2Ge2oxlPM2bx8MjWnZm1CFAf0SjO/igtU3m9uOoBbJjaRZFkb+efaj0Iwjzr5FQ7iQae+VscqoDaDG3hpTOg7OqS123VhfG/Y2hUos+amn2djb3JJmgNwUak3m6JI6vz1wLrdedleIDO5XnkvWEixHswGea13ZekISuiJyG/0qbaKp7QMhCeEd+VWsx X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 77f533ba-5676-458e-3251-08d8251fb4ba X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2020 22:22:18.1928 (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: WLNtiEMhqnO2/NqJFTkWxPkb22a1KDKn99UpYKU266RRZsAFkrbKEhibzgGgQs6FT3Tk21fziK0Utv795K1FVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6508 Archived-At: Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 22:22:23 -0000 On 6/29/20 4:18 AM, Alessandro Vesely wrote: > Hi all, > > I mentioned setting To: author instead of From: author-like, near the bottom of a message[*] a week ago, but missed any WG comments on it. That setting would result if I run a mailing list "by hand", using a normal email client. I'd hit reply and then add a bunch of Bcc:'s. Of course, a suitable template would insert a subject tag instead of "Re:", et cetera. > > It'd be a cleaner solution than From: rewriting, inasmuch as it saves the association between display names and addresses, for the sake of address books consistency. The anomaly of seeing authors in To: fields, with some getting used to it, may even become a distinguished characteristic of indirect mail flows. > > How unbearable would that be? And why? Maybe some comments on this subject can bring out some more details about the rightness or wrongness of the various flavors of From: rewriting. If nothing else changes; as in: MLMs have to keep promoting the use of From munging to their list operators, then I think it would be useful for these MLM to also offer (and perhaps default-to-ON if it works well in practice) your idea of replacing the To with the author during the munging process. It would increase the odds that the author will be added to the recipient's address book, either manually, or via auto-collection by MUAs when they Reply-all (I believe that most MUAs will include the To in the recipient list if it differs from the user's own address) Recipients (and individual list operators) may still complain about the From munging, but I like your line of reasoning of getting people used to "distinguished characteristic of indirect mail flows". Recipients will still be saddled with "author via listname" polluting their address books (via address auto-collection). This idea doesn't solve that problem. Jesse From nobody Sat Jul 11 04:29:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FAF3A0DD5 for ; Sat, 11 Jul 2020 04:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 3QQrvN1Kb1ef for ; Sat, 11 Jul 2020 04:29:06 -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 DA4D63A0DC6 for ; Sat, 11 Jul 2020 04:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594466943; bh=rZl/hWuP+9ULgZenHkbAS8I+4aD2fo+MCzw5SR5Ymm8=; l=814; h=To:References:From:Date:In-Reply-To; b=C8bx1JuU+ZaorSqTdvec+74RTh+fLSUGTcnq0D/ujuhxly/2/JF4AAGs4wcgomIVx VhbDx6UKEF5sSdMNVOi0nV2Ryuy3Vc4epuHKyUef4rwKesF5mcnRRLIw7n7OlUkrUr 7n3MOHntTAgK3jlcjy3QRA88MxYrCWYeTWTcI8g0/qDDq2fPlHfM+6oiRjGpt 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 00000000005DC083.000000005F09A27F.00007EAA; Sat, 11 Jul 2020 13:29:03 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sat, 11 Jul 2020 13:29:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 11:29:07 -0000 On Sat 11/Jul/2020 00:22:16 +0200 Jesse Thompson wrote: > On 6/29/20 4:18 AM, Alessandro Vesely wrote: >> Hi all, >> >> I mentioned setting To: author instead of From: author-like, near the bottom of a message[*] a week ago, but missed any WG comments on it. That setting would result if I run a mailing list "by hand", using a normal email client. I'd hit reply and then add a bunch of Bcc:'s. Of course, a suitable template would insert a subject tag instead of "Re:", et cetera. > > Recipients will still be saddled with "author via listname" polluting their address books (via address auto-collection). This idea doesn't solve that problem. If the author is in To:, both name and address, rather than a munged field we'd have something like From: Mailing List ID Best Ale -- From nobody Sat Jul 11 16:03: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 0774D3A0957 for ; Sat, 11 Jul 2020 16:03: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=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 Kd0D92WZIfyv for ; Sat, 11 Jul 2020 16:03:42 -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 5077D3A0956 for ; Sat, 11 Jul 2020 16:03:42 -0700 (PDT) X-ASG-Debug-ID: 1594508617-11fa313a10382df0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id BTnKmAN2PN7Cujbg (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 11 Jul 2020 19:03:38 -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=h9PyQ1lrKsjiMSg41OE0ANdubmDrCb8aKwuwXl7plx8=; b=PTTZGAGYJc0gfu1Ah1GyfJ+RBOLggrPgg93FDgadSrKrtNkAojALR8SwfPukZfjfS mzyMGDXgG1/Q4au9nSv8pWokqDSc1h7uganvIE3FWJ+n2EtFk3bxBx3Wm6V5MlIJy bAD3x2tLmUykAhPmvHLKmfG3uiaNgenAj3ncdBOC8= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 11 Jul 2020 23:03:29 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers Reply-To: fosterd@bayviewphysicians.com Message-ID: <986a7cb9aef247e9ab6a42527b99b241@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0f25d795269a42989c5d2c7ebb16c299 In-Reply-To: References: X-Exim-Id: 986a7cb9aef247e9ab6a42527b99b241 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594508618 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: 7384 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.83135 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 23:03:44 -0000 This is a multipart message in MIME format. --0f25d795269a42989c5d2c7ebb16c299 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rewriting the Message To seems to have no characteristics that are likely t= o cause messages to be blocked as not trustworthy. This approach will not be detected as anomalous by an incoming gateway. M= essages to BCC recipients and messages to non-modifying distribution lists = are already received with the message From address being different from the= SMTP RCPT address. Since a user knows that a received message is for himself, a message that r= eports "To" as someone other than himself may cause minor confusion, but is= not likely to cause significant misunderstanding.. In sum, no one seems to be concerned about the integrity of the "To" header= currently, and there is no obvious reason why we would expect this to chan= ge in the future. For mailing lists that are insist on editing submissions, changing SMTP MAI= L FROM and Message From into the list domain, and the Message To into the a= uthor domain, will solve the sender authentication problems created by doin= g so. Just as importantly, it requires no special pleading to participant= domain administrators. DF ---------------------------------------- From: jesse.thompson=3D40wisc.edu@dmarc.ietf.org Sent: 7/10/20 6:22 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers On 6/29/20 4:18 AM, Alessandro Vesely wrote: > Hi all, > > I mentioned setting To: author instead of From: author-like, near the bot= tom of a message[*] a week ago, but missed any WG comments on it. That sett= ing would result if I run a mailing list "by hand", using a normal email cl= ient. I'd hit reply and then add a bunch of Bcc:'s. Of course, a suitable t= emplate would insert a subject tag instead of "Re:", et cetera. > > It'd be a cleaner solution than From: rewriting, inasmuch as it saves the= association between display names and addresses, for the sake of address b= ooks consistency. The anomaly of seeing authors in To: fields, with some ge= tting used to it, may even become a distinguished characteristic of indirec= t mail flows. > > How unbearable would that be? And why? Maybe some comments on this subjec= t can bring out some more details about the rightness or wrongness of the v= arious flavors of From: rewriting. If nothing else changes; as in: MLMs have to keep promoting the use of From= munging to their list operators, then I think it would be useful for these= MLM to also offer (and perhaps default-to-ON if it works well in practice)= your idea of replacing the To with the author during the munging process. It would increase the odds that the author will be added to the recipient's= address book, either manually, or via auto-collection by MUAs when they Re= ply-all (I believe that most MUAs will include the To in the recipient list= if it differs from the user's own address) Recipients (and individual list operators) may still complain about the Fro= m munging, but I like your line of reasoning of getting people used to "dis= tinguished characteristic of indirect mail flows". Recipients will still be saddled with "author via listname" polluting their= address books (via address auto-collection). This idea doesn't solve that = problem. Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --0f25d795269a42989c5d2c7ebb16c299 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Rewriting the Mess= age To seems to have no characteristics that are likely to cause messages t= o be blocked as not trustworthy.

This approach wil= l not be detected as anomalous by an incoming gateway.   Messages to B= CC recipients and messages to non-modifying distribution lists are already = received with the message From address being different from the SMTP RCPT a= ddress.  

Since a user knows that a received = message is for himself, a message that reports "To" as someone other than h= imself may cause minor confusion, but is not likely to cause significant mi= sunderstanding..

In sum, no one seems to be concer= ned about the integrity of the "To" header currently, and there is no obvio= us reason why we would expect this to change in the future.

<= /div>
For mailing lists that are insist on editing submissions, changin= g SMTP MAIL FROM and Message From into the list domain, and the Message To = into the author domain, will solve the sender authentication problems creat= ed by doing so.   Just as importantly, it requires no special pleading= to participant domain administrators.

DF



 

<= div>
From= : jesse.thompson=3D40wisc.edu@dmarc.ietf.org
Sent: 7/10= /20 6:22 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
On 6/29/20 4:18 AM, Alessandro Vesely wrote:
> Hi = all,
>
> I mentioned setting To: author instead o= f From: author-like, near the bottom of a message[*] a week ago, but missed= any WG comments on it. That setting would result if I run a mailing list "= by hand", using a normal email client. I'd hit reply and then add a bunch o= f Bcc:'s. Of course, a suitable template would insert a subject tag instead= of "Re:", et cetera.
>
> It'd be a cleaner solut= ion than From: rewriting, inasmuch as it saves the association between disp= lay names and addresses, for the sake of address books consistency. The ano= maly of seeing authors in To: fields, with some getting used to it, may eve= n become a distinguished characteristic of indirect mail flows.
&= gt;
> How unbearable would that be? And why? Maybe some commen= ts on this subject can bring out some more details about the rightness or w= rongness of the various flavors of From: rewriting.

If nothing else changes; as in: MLMs have to keep promoting the use of Fr= om munging to their list operators, then I think it would be useful for the= se MLM to also offer (and perhaps default-to-ON if it works well in practic= e) your idea of replacing the To with the author during the munging process= .

It would increase the odds that the author will = be added to the recipient's address book, either manually, or via auto-coll= ection by MUAs when they Reply-all (I believe that most MUAs will include t= he To in the recipient list if it differs from the user's own address)

Recipients (and individual list operators) may still c= omplain about the From munging, but I like your line of reasoning of gettin= g people used to "distinguished characteristic of indirect mail flows".

Recipients will still be saddled with "author via lis= tname" polluting their address books (via address auto-collection). This id= ea doesn't solve that problem.

Jesse
_______________________________________________
dmarc= mailing list
dmarc@ietf.org

--0f25d795269a42989c5d2c7ebb16c299-- From nobody Sun Jul 12 20:10: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 E6CAA3A0C23 for ; Sun, 12 Jul 2020 20:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ia916Y_Wbd for ; Sun, 12 Jul 2020 20:10:55 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AE73A0C16 for ; Sun, 12 Jul 2020 20:10:54 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 145so10934284qke.9 for ; Sun, 12 Jul 2020 20:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=IS+imVZfBqUfzCXC1+DNjd24gmdz8ONODWCxGv2U84E=; b=WLlU5OPtuvfzK8jLRzmZaxQYeFCy6gfcQCujl+36d+Bzvn7U7JSJEo45Uuym5HBicu mquwbpf6qp3rUBJAgFxzsmNgPUw8ZeDWUWK7Z2oXIcWEIYzcUl/g/792P3Bvj6MrxyQF PvTZSFZqxDE7p78+/ocfs+GadLUan2ziLlCVhfHtmDkWiBK8QzHH94ByG1dZEtCWEjp8 ONjQQAmeSwEmWs3tpsjFIXd91JEERXOUe3La9lDWrJ0Y0OFCNHXK8B2iOOpPvhuCcD6D l0qZTQAbslm3LIOFZPhiw5mm6VubtDT6Gr88eM137Of55Pfv7Bbv7/jcrZEY4hMCry/d Mk9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=IS+imVZfBqUfzCXC1+DNjd24gmdz8ONODWCxGv2U84E=; b=eD9gsIptP9A8b/zk4isxXNnP6L+LNSpaIRY1aryRwbOvgrZzTnQH2whKsW6MuwrKLH T3putfKa3mdv5h5K0lLiEp4Uz42OwbF7W5PDhmD06F4Odb5KpRUcKrqb+MKCSZ6KAQ21 63maGCVcXlhfNVrW5UyAjQVOVmc3JfBZzb9CwDBmgaVjmMugi70xj2299IQNb7WgShlu KrMM0M/K+A/AX9VciSMn8d4zXLiG61Z5lwF4lWfmt/MyCM1HQc3ncf3HZiqQ6V6H7DH1 nBiqxvUw+Cm10Q1Kxop4rZ3kap2Sl73MkNksJEHPbnEkc0OCjjmnPYbC5u9xFjIuEcsG g0bw== X-Gm-Message-State: AOAM531MJZc2jiDyTCq1sOUudRspBNVmiCbp6WWz3dNoa+R5BFu6HPEf Lk7TUBucmJ/nSD/aID4TCJ14588Udq0= X-Google-Smtp-Source: ABdhPJwh0yWMpF5dGub/14X6Ax7myM2DW9EJZzaiZrYOHDzy8tZmYerWepasaKiJSlMsmTBWlzVi0A== X-Received: by 2002:a05:620a:121a:: with SMTP id u26mr78051041qkj.398.1594609853801; Sun, 12 Jul 2020 20:10:53 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:dc7c:2910:2bce:82a0? ([2600:1700:a3a0:4c80:dc7c:2910:2bce:82a0]) by smtp.gmail.com with ESMTPSA id o5sm17899832qtb.26.2020.07.12.20.10.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 20:10:53 -0700 (PDT) To: IETF DMARC WG From: Dave Crocker Message-ID: Date: Sun, 12 Jul 2020 20:10:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 03:10:56 -0000 FYI, I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 12 20:20: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 B80063A07F0 for ; Sun, 12 Jul 2020 20:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TghE_fr6LnWM for ; Sun, 12 Jul 2020 20:20:29 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81ED33A0C21 for ; Sun, 12 Jul 2020 20:20:29 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id e13so10971995qkg.5 for ; Sun, 12 Jul 2020 20:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=D4se5ZXQxk2ZFPzJAMFS2zXWziQ0u8sQICCuAmZHBQc=; b=BWLL0QiYHi6BRr7jp/fwvClFw9igmqkBU5Ab2qEVfI3cWz7i58AmToquggQD48MPg5 w3au0Q49UrJaG1VKnddXkrhGBFCUAZr48VUsX6Tw2J9M8+ArlqXIpm0O8ATkAMBpgqMM E8Ze63MsTFsCRiAzKD4T+sK/A+Gwn5dU16qptUljJpc9EEyu77SoWd29/X25QENSa2t/ aZGsIFxAvqvLkTSFhR3roaSWHBbEYfc1LVn/I9HufkQOsqtmNkl8W63Z7KisyD5P4SQx 3Cf7XWJGxHNxcrobF/Bhgrko4YUVXP+Yu5SWLhnTIBbPiMSmfAZhovnIfthDJpFsppoi gQHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=D4se5ZXQxk2ZFPzJAMFS2zXWziQ0u8sQICCuAmZHBQc=; b=St+R+X3xAz3v0c7qA2y5bMw/U6FQ2UB7Ot7+KmEOqORmXJ4X6SzzkU+txcJUBbUk+c FosK2YupFsOGUVLxQ+AilY7BhEfgof6XSYepevl8x2WZ797vbACV6w2OB/OO7TgTqVEF Fafn+DFpkeQNhdwnzesmj8XcSnU88kbXfzj3WtI533t9kH1fnIojLAjdZBCGTtyevdvY NoZk4V+/yBVSY9jXo91AL/DeLgGosIYzXYuPLCarjhULfAV2eDFGt3kJf/g2drbvmgMV 8iXUHlbNdyUsjhwKUi4iWmD2UGqryH+wZmZpK2Cfaa2+W6UtRvnhhP7YOKJ2ApF3+0mL qdeA== X-Gm-Message-State: AOAM530iTr4h7dJzohu+z3TXzuqKiSMOfm8oZLiOMvvol6gAhZGfqP7N IiqRETwXnMGnk5+ZoBk4kbq0wsI1KYY= X-Google-Smtp-Source: ABdhPJxKl1AuEtqoPEdFafmPgMAQS8G55trqOoZxWC4ur8T753UWl4XoMJxtMrQYmlGuXq0dpPxJiw== X-Received: by 2002:a05:620a:2155:: with SMTP id m21mr68326969qkm.14.1594610428470; Sun, 12 Jul 2020 20:20:28 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:dc7c:2910:2bce:82a0? ([2600:1700:a3a0:4c80:dc7c:2910:2bce:82a0]) by smtp.gmail.com with ESMTPSA id g1sm18737197qkl.86.2020.07.12.20.20.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 20:20:27 -0700 (PDT) To: IETF DMARC WG From: Dave Crocker Message-ID: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> Date: Sun, 12 Jul 2020 20:20:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] 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: Mon, 13 Jul 2020 03:20:31 -0000 FYI, I've posted an initial draft for having DMARC use the Sender: field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 13 07:47: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 034283A0B02 for ; Mon, 13 Jul 2020 07:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 GC79aU6xIiW6 for ; Mon, 13 Jul 2020 07:47:04 -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 33CEA3A09A4 for ; Mon, 13 Jul 2020 07:46:45 -0700 (PDT) X-ASG-Debug-ID: 1594651601-11fa313a1038d950001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id N95Grv5j2qnyNRHv (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 13 Jul 2020 10:46:41 -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:subject:to:from; bh=yPhwXkMBhYV5NUCEyb9dE8v46AfPtGIH8k8rylDgbUU=; b=ES4d8U4PhBgVbh04maX12YN0t6iGRQ+2R6MHUexwUI6NFeVj4BeZnZnJWP94U0gSb 1lxW1OLLCKORB15ofaS74prPMzuuclQtnPsANcM/CJrJBm4kaTsRuTn1icdyVaO9b 30Ovylu372csjLE8oNy7ZCteX+orUZSyZwOiI95t4= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 13 Jul 2020 10:46:33 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: "'IETF DMARC WG'" References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> In-Reply-To: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> Date: Mon, 13 Jul 2020 10:46:33 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field Message-ID: <000001d65924$6701e340$3505a9c0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-Index: AQIQmE/Qm2aJvLiqZFeej2LGzH13SqiREjdA X-Exim-Id: 000001d65924$6701e340$3505a9c0$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594651601 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: 2773 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83169 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 13 Jul 2020 14:47:09 -0000 Let's clarify the purpose of DMARC and the problem of MLM edits: Modifying in-transit messages is a threat vector for both sender and recipient. The ability to constructively modify a message is also the ability to maliciously modify a message. And the ability to maliciously modify a message is also the ability to create a new message which looks like a forwarded message. In this respect, a content-editing MLM is indistinguishable from a content-fabricating spammer. Senders do not want to be misrepresented, and do not want their good reputation to be exploited by those with a negative reputation. Recipients do not want to be misled. Consequently, sender and recipient agree to enforce DMARC policy, to prevent this from happening. If a message is altered in transit, or forged in its entirety, the message will be rejected. There are very few ways to fix this: - MLM must gain the trust of the sender and recipient, so that it can be distinguished by a spammer. - Sender and recipient must be duped into accepting content that they do not want. RFC 7960 is worded to suggest that DMARC is to blame for the problem. The real problem is that MLMs have made their operating practices dependent on weak security. Santa Claus could run into the same problem: At least in the USA, he comes down chimneys, because they are unsecured and his intentions are only good. If criminals figure out how to enter and exit through the chimney, homeowners will start placing locked grates on top of the chimney. Given the choice between "both criminals and Santa" or "neither criminals nor Santa", most homeowners would be willing to give up Santa. Of course, Santa could ask for a key, which would create a key management nightmare. Or he could ring the doorbell, show credentials, and wait to be admitted. The MLMs are like Santa. They are trying to do a good thing. But the criminals want to use the same weaknesses that the MLMs want to use. Given the choice between "both" and "neither", DMARC-enforcing domains are choosing neither. Inducing or coercing them to use "both" mode is an incorrect solution to the MLM problem. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Sunday, July 12, 2020 11:20 PM To: IETF DMARC WG Subject: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field FYI, I've posted an initial draft for having DMARC use the Sender: field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Jul 13 09:29:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D3D3A143C for ; Mon, 13 Jul 2020 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cfBD8m20Yoea for ; Mon, 13 Jul 2020 09:29:47 -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 AC4ED3A1425 for ; Mon, 13 Jul 2020 09:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594657785; bh=gd2GUL5gTfrXFbWXOZ6zGw4dkMKFA18gF8AcQLXCAg4=; l=1562; h=To:References:From:Date:In-Reply-To; b=CaRufix9sNrf/ylzeyE56XbLuJsK8m1pFTxa0mtHt7c/ByRqlkxI1ign5Re0iVGps pLSO+DEEePXHYr+HgkNHr+/aFka92ksVjorCGtRDPB3Gm4PIEByp/9e512V9/kcWhU Lvf9rxARJkjp5NmlFyDZ54jjI8up2Y3bU+5yx1qyvIMFSOhxVUE9hUC1tUUhh 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 00000000005DC013.000000005F0C8BF9.0000356D; Mon, 13 Jul 2020 18:29:45 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Mon, 13 Jul 2020 18:29:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 16:29:49 -0000 On 13/07/2020 05:10, Dave Crocker wrote: > I've just submitted an initial draft to define an RFC5322.Author field: > >      https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations about the Sender: from this one. In particular, the 4th paragraph of the Introduction, "Because the current [...]", is distracting and unhelpful. I'd explicitly mention DMARC, rather than use circumlocutions mentioning generic email protections which use the From: field. Another use case of Author: is to indicate multiple authors. Like From: and unlike Sender:, Author: supports a list of mailboxes. Since, DMARC filters don't behave well with multi-address From:, using Author: can be a handy alternative for those joint messages. In fact, the current spec says: o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format; I submitted ticket 74[*] to address the latter point, which is inconsistent as either all or none of the mail belonging to a given domain is subject to DMARC filtering. There is no way to define which sorts of mail is "normally protected". The quoted rule deviously restricts the format of From:. I'd support making that a WG I-D. IMHO, it could be standard track and modify RFC 5322 if accepted. Best Ale -- [*] https://trac.ietf.org/trac/dmarc/ticket/74 From nobody Mon Jul 13 09:32:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236BE3A154A for ; Mon, 13 Jul 2020 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 bR9B83ZHAwVP for ; Mon, 13 Jul 2020 09:32:18 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 03D3B3A1578 for ; Mon, 13 Jul 2020 09:32:18 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id a14so6047302qvq.6 for ; Mon, 13 Jul 2020 09:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=hT+SnAYfkzuLyIoC2SdfIZYKj64962e7SiXEUZ2Tq7Q=; b=R/noTkLrpwgLF8XCD3sSS8M34ZVC7oErO+HZOZILR7nwL0zFdfgjIe9ft7xB7esnXF TUNARQtB0aLUxc+iQWzHEDpDTEFfJ5PjAeRSt7iU4RhV2exYPJytEQiygNXrrGutKL58 nSADta2kvtq0ezG+H//DqfLSPJ/KEUM6lYtYFJdHFNngzOg+p/tXtnIwfDU6ERhWTPDa eRUy2wULHegsfvLFIAzhHL56XTrqBjoM5/DoAPIq6eOazl9xXY+yYNjHsXYJheAI9N7K xaTYJGwGh6Za1XApEXDluEET7t0HWPXV78kSY91S/BUIgG4HHIxH8sT2CU2OXAuG6NiM /ESA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hT+SnAYfkzuLyIoC2SdfIZYKj64962e7SiXEUZ2Tq7Q=; b=FJfN6iP2n9Zbh83otJCHRsWEHnn5wLZt7eDBCScbpZJ3O2xkSGuSkGR0GZ03D5A9W1 vW8IU7yerNIZkcbl4ztNQtDt/O1XJWOnXAU6HUvc3M0vhmKAt7FHH2EPx0MjBkEsA36X o5LCggPSX79fVtfgqgchPg6Wmd/oWlrwxuAI8dzbTXzagHqvR7/2Wy5lc1SOGqU3QrAq BtPJzvBwgCy9bSPWn7lO32xPwJnkp5WHBgh5vlQ39BoJqkbs+yXmDxsl6pGV7VXRy6FS W+NRZeqWB0ywY5e7iCMMLXGly6Z08+o9/mr5Qwy5+gkR04llmVCiiQr5YEcNefy9sJIs 5nKw== X-Gm-Message-State: AOAM533lqQ7yUQHEfFsPR2RGriscjFju+EeqY7hBA6laQ9McL1lW1+Ak GG5LmWJxf5ipsxET6mmmb4bewTWVq6c= X-Google-Smtp-Source: ABdhPJztIoGDyeSwhcLdkziLkLHD2Te72QUL4LsqwXX8oMZXAaUuR+1afoeM2X3IvjNy5ZWRMdy0fQ== X-Received: by 2002:a0c:bd15:: with SMTP id m21mr267538qvg.61.1594657936380; Mon, 13 Jul 2020 09:32:16 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:401c:ce47:b522:3c86? ([2600:1700:a3a0:4c80:401c:ce47:b522:3c86]) by smtp.gmail.com with ESMTPSA id r6sm19051029qtt.81.2020.07.13.09.32.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 09:32:15 -0700 (PDT) To: Doug Foster References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <000001d65924$6701e340$3505a9c0$@bayviewphysicians.com> From: Dave Crocker Cc: 'IETF DMARC WG' Message-ID: <1539549e-b63e-ae46-e5bf-d53aad59932c@gmail.com> Date: Mon, 13 Jul 2020 09:32:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <000001d65924$6701e340$3505a9c0$@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 13 Jul 2020 16:32:20 -0000 On 7/13/2020 7:46 AM, Doug Foster wrote: > Let's clarify the purpose of DMARC and the problem of MLM edits: Thanks for the response.  What confusion about DMARC is there, that you felt needed clarifying, and how does it relate to the details of this proposal? Also, in terms of threats, how does my proposal make them different from what is already considered acceptable?  In particular, the current actions by Mediators that rewrite the From: field is, apparently, considered acceptable. > Modifying in-transit messages is a threat vector for both sender and > recipient. Technically, they are not 'in transit'.  In basic email terms, they've been delivered and then re-posted. Also, since mailing lists have been in operation for about 45 years, and since they are such a threat, perhaps you can point to some documented abuses by them? Lastly, I apologize, but I could not discern any specific substance in your note that relates to the substance of my draft. Please clarify. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 13 10:16: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 370713A15DC for ; Mon, 13 Jul 2020 10:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=FxTgsZgG; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=00nhVqEk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIzxOKBtzFV3 for ; Mon, 13 Jul 2020 10:16:06 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998783A1596 for ; Mon, 13 Jul 2020 10:16:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=503; t=1594660559; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=YffdSQhUkwaKYCx9m8J9hPrRtKQ=; b=FxTgsZgGwOJOBDoj0zZoGH6IouahcPA8pjNJs4gQc6pWYd8WxamBo0MzKDjGQ9 5Ft6oBTz4ex2saOazIeNbvhPhCwvgDlQuiHhAiORybebQXv180ywgH6xmqmn8SJt Az38yMfRQC5BJuDGAOtk9Pxrrby3BG3pMELOoyadQ12MM= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 13 Jul 2020 13:15:59 -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 1092866157.78.7296; Mon, 13 Jul 2020 13:15:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=503; t=1594660470; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/4wM2Dv UTsTM8mb+VqzKyl7nj0k4zErzTgFs4tYAG8M=; b=00nhVqEkTcHdz068+xcYyzE Ap8qI2WAlcnWwyOUhdVSETKrPQClbAbO+s+MJ+GfBRhNrz1ZsGDbv77B2/NFfcDz EE/+dy20NN9qhih/3P3JkPShMDPHoVKeWPse67rNLaO6LNfZLgo1MJ6ejUiJbMKX 0GLymGA5weJ7fUrQLsH4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 13 Jul 2020 13:14:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 803645109.3.17156; Mon, 13 Jul 2020 13:14:29 -0400 Message-ID: <5F0C96C9.8050104@isdg.net> Date: Mon, 13 Jul 2020 13:15:53 -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: Dave Crocker , IETF DMARC WG References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> In-Reply-To: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 13 Jul 2020 17:16:08 -0000 Before more review,just to confirm: 1) draft-crocker-dmarc-author A proposed new 5322.Author header? Is is required to be hash bound to DKIM signature? Will be make it a MUST NOT modified NOR rewrite it? 2) draft-crocker-dmarc-sender A proposal to somehow shift DMARC to DNS UP the sender domain for DMARC policy? Does this mean the Sender header is now required to be hash bound to the signature? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Jul 13 10:22: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 8BF2C3A1451 for ; Mon, 13 Jul 2020 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 Tfw2EvCTnNPF for ; Mon, 13 Jul 2020 10:21:57 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 195F73A14B7 for ; Mon, 13 Jul 2020 10:21:53 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id e12so10528296qtr.9 for ; Mon, 13 Jul 2020 10:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=AzMUoFsgFmD9/kkq46mApEq/30ecEprCaaEk/NuS86Q=; b=Twd3FMbbPdhxibWDihTMi8wRs4cOIBQFMZPgIz6vouqRwZMYpnBJBF5kuITjSyCCem 2OFr6u1al5NeqO19JBv8yrwYPqwg+bWondgu+JdCQvQqFwrqU3Q2BUplA1ecqxRxAZzT eU8VSpf5tNnLj7l417rR9nzg4LzyR84t4IeLK54XxFs3sQNfAxN1Y1fnhTI8qDJgKog4 IGolufpUvX4csprf9o9FD+Sq9/LYG+6IH6WahIL+urH73hQ5eFteFTClqdbg+emYAo/o t3bQtPiXY0mwkGM/GeE4GGEvouNGJ+UGYK0onimkyo06+NiMfvb+164Hr9fyh3LOYwWj dNhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=AzMUoFsgFmD9/kkq46mApEq/30ecEprCaaEk/NuS86Q=; b=A1B0FPVGT9+/8yz+j/206n5+U9Ri22Cyc4h2jIfRyxbykrl3bEzWtAFY82iGNiQfNk CHPQrGLppdxklKk5QZK1sCAo4GJsX+n2gK6QYg4ZCHwYkozE9UDjpP1v0e6yk5WHk4hW f10El4KcPA+lFIUCnA9rV4svrZUdHWuoq8sC/fLGCeWJR7jNTd+6mZEF49OXSjPF9iQ1 ybdxkC9unl+s6aSAQhmOLrYjJKZz4ps4NMk7+37yU0/50Vft6l/32+2KEMBEKkz5Inhc nehTgu5dRzi34Sgcyje3ehGuLbyjPC/aqXxTSYrgV7tsDgK1qpRdO2B8iFX5aDB3MjUC vYBQ== X-Gm-Message-State: AOAM533A1T2gGz6R/qO7CWiX6J8qgKyiCP4brG79wKqC8/tFkn6zsCM4 4pFS47PY5VqHc6jNBo1uZ3DhNsEOodM= X-Google-Smtp-Source: ABdhPJzaPl1vlvaJvIZk9pTiYu/zTIZouDk0eygIKbE0k6sU2yVYsD/ZqZ+D/NshatR0PMlLjt9IFA== X-Received: by 2002:aed:32e5:: with SMTP id z92mr383330qtd.328.1594660911930; Mon, 13 Jul 2020 10:21:51 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:401c:ce47:b522:3c86? ([2600:1700:a3a0:4c80:401c:ce47:b522:3c86]) by smtp.gmail.com with ESMTPSA id k197sm19723760qke.133.2020.07.13.10.21.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 10:21:51 -0700 (PDT) To: hsantos@isdg.net, IETF DMARC WG References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> From: Dave Crocker Message-ID: <23887878-4240-328a-4716-b67dd8d218db@gmail.com> Date: Mon, 13 Jul 2020 10:21:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F0C96C9.8050104@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC 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: Mon, 13 Jul 2020 17:22:00 -0000 On 7/13/2020 10:15 AM, Hector Santos wrote: > Before more review,just to confirm: > > 1) draft-crocker-dmarc-author > > A proposed new 5322.Author header? Yes. > Is is required to be hash bound to DKIM signature? No. In fact the DKIM requirement to include From: in the set of hash-bound text was a last-minute imposition by an area director, rather than a functional need set by the working group or larger community. That said, of course I'd expect signers to choose to include it. > Will be make it a MUST NOT modified NOR rewrite it? No idea where this would be mandated or why. > > 2) draft-crocker-dmarc-sender > > A proposal to somehow shift DMARC to DNS UP the sender domain for > DMARC policy? "DNS UP"? It's a proposal to have DMARC use the Sender: field, in preference to the From: field. > Does this mean the Sender header is now required to be hash bound to > the signature? cf, above, about the nature of the requirements.  Again, it would make sense to bind it, but mandating is a separate issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 13 10:27: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 7C4B33A15E5 for ; Mon, 13 Jul 2020 10:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 daScec5bQDlh for ; Mon, 13 Jul 2020 10:27:55 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 EB2473A174B for ; Mon, 13 Jul 2020 10:27:36 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id x62so10587967qtd.3 for ; Mon, 13 Jul 2020 10:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=UCYKfd/Mlng6STGLYdJIeK9LknGdQ4TXv30zA9oohkk=; b=cZf5XDrqZeEg5Ht7jOuR1FiFeauuau8lPwfKOk1dSKKpekpwl9A1huIErX5czOL9R0 uudiSyesaIV5piVFekTpt8p8gXqTdKoL680un1y63993OHMtfQqGLCXJCtdhzVKXl3OO 1OY0ulo8bBkxGEMqBmMO04PHGYtfxqnB5dyc6qZG5phkgvdl5WDtkTVceqfWzoV+U3aU cJdvVKzg/d1pJ/4HZRpjlR9TfvHBhXNNUt4beY/EB7cu1akyvnWsIrx3mvgvLos+/IhM lDE0BCJO9b+Lh22KNl2do9R7KKLWIjhdi90VG1Vd9qEnp2FrDZBJqwcNgsiTme4pASnv Z9NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UCYKfd/Mlng6STGLYdJIeK9LknGdQ4TXv30zA9oohkk=; b=XoTVjW0PN/2bZD4qecoNIpmLefFgZ7M6H+vd5lIA2Eyay4CvQNQMxBmtoNcYCQGVDt 1WW56w/0fklPRphTXBr/YwhC1AJkxfak3NDfI/ckZAr2AIP/lvhoVREIgNqiBV4IxJf0 HbaB3vpdpI/qDUX2lxO5KN9tFhmX+EfTfZo+w+wPNGUhIhBQ/IZWRsqepF5LcYOXWc06 90kGqYCWsAnbGyXLENEvTyPuGFB0wgKq+QBrarglkMWm65u8wDdYct9XoDzKza3XInYG pZbSnai5RZXSOtTv6xYc81bs/pFdKrZovj2ElLqk41iJJlhkjtNY4QvVU1XHjVnecjnk yZFA== X-Gm-Message-State: AOAM5309hG+Eja54agzocSD2y3lQMV7o1Chpid/juyfqFvyjvEMHhD7o jQUnZlnREKCPV8raJESkPckZi1fETR4= X-Google-Smtp-Source: ABdhPJwMFHLuH2DmMBdM5bDHQMIOvxjmgz2bN86KUuXMr0QfOPin3JxRmgELJ6yib2krSr/brtVB8w== X-Received: by 2002:aed:222e:: with SMTP id n43mr398885qtc.123.1594661255866; Mon, 13 Jul 2020 10:27:35 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:401c:ce47:b522:3c86? ([2600:1700:a3a0:4c80:401c:ce47:b522:3c86]) by smtp.gmail.com with ESMTPSA id u6sm21022523qtk.9.2020.07.13.10.27.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 10:27:35 -0700 (PDT) To: Alessandro Vesely , dmarc@ietf.org References: From: Dave Crocker Message-ID: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> Date: Mon, 13 Jul 2020 10:27:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 17:27:56 -0000 On 7/13/2020 9:29 AM, Alessandro Vesely wrote: > On 13/07/2020 05:10, Dave Crocker wrote: >> I've just submitted an initial draft to define an RFC5322.Author field: >> >> https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ > > > Dave, > since you also posted a second draft, I'd strike considerations about > the Sender: from this one.  In particular, the 4th paragraph of the > Introduction, "Because the current [...]", is distracting and unhelpful. Unfortunately, misunderstanding of the relevant human factors is often introduced in discussions in this realm.  People are remarkably resistant to the behavioral facts on his, so, unfortunately, it needs repeating. > I'd explicitly mention DMARC, rather than use circumlocutions > mentioning generic email protections which use the From: field. I've learned to write specification for the long-term, notably trying to avoid ephemeral references that won't apply years later.  The proposal here stands on its own.  Motivated by DMARC issues, but I'd argue not dependent on it. > Another use case of Author: is to indicate multiple authors. That's supported by the draft spec, since it copied From: syntax. > I'd support making that a WG I-D. Thanks. > IMHO, it could be standard track and modify RFC 5322 if accepted. The mail header is extensible.  Addition of header fields does not require modifying the base specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 13 11:28:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A003A1675 for ; Mon, 13 Jul 2020 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDJRD8eIGNW6 for ; Mon, 13 Jul 2020 11:28:33 -0700 (PDT) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 05F243A1672 for ; Mon, 13 Jul 2020 11:28:32 -0700 (PDT) Received: from pps.filterd (m0167076.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06DI7VtJ007799 for ; Mon, 13 Jul 2020 14:28:32 -0400 Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0b-00364e01.pphosted.com with ESMTP id 3276htngm9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Jul 2020 14:28:32 -0400 Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06DISTfg004499 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 13 Jul 2020 14:28:31 -0400 Received: by mail-il1-f198.google.com with SMTP id k6so10106264ilg.8 for ; Mon, 13 Jul 2020 11:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RqatdzFdDbE1P1KoF8bTd1yPStE8Pisib403dIEnnVg=; b=eHO1tMEQRxtcF309FpWEx4LeiiQqAUjFzomKYzuVpNbA9hra0YYfLb0ViRX8s43fhC o+v8wVMAAGwEmoYk9umKyJreyO3ruTFEGk+q5mOr6uyvt7Gb81Vo715t9DwCk1nz2wdO JQklOCGjPeGi+BFHpEDrac8eO0q+WXuiOgnIPklbbqDhDEbtrSSj39cl+pnf6Lqdq87o Xe2ok1L+lrhXVihh5PIvz59uV1XMls5cPRJI7qHxPZsnJrv8JWj0BWwKxuq0n63B64Yp CniG+k7m1q+X8U0ajnTIVx9taoyuCIGLJxP5ZZZ4dlG6yi4yvvi34Q7TBHkVGPaz+BLY 4qfg== X-Gm-Message-State: AOAM530zWSfS7OKtVjBLC22GayDk71KPX3xDILWpKObhPR4/jWJJ4KLs H9v3eLEeVyWGkm7jlxcyNq3A0owmr/qqOz+WA+nKMjo9z9sE+PMA+mZVfqTUsfzUrN8zi5wuC9b lcoz+ar9b9weZ5Hn0kMWPuPGHhO74pg== X-Received: by 2002:a92:c703:: with SMTP id a3mr941260ilp.159.1594664909020; Mon, 13 Jul 2020 11:28:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdlPBXPfQaBdGDhQ0x0Jgfr/JpugFW9Gdc0EjC1kQEJIftu9+d5iNFk0IT5BJj7VH4USg51AirPvsNolFzSM8= X-Received: by 2002:a92:c703:: with SMTP id a3mr941229ilp.159.1594664908490; Mon, 13 Jul 2020 11:28:28 -0700 (PDT) MIME-Version: 1.0 References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> In-Reply-To: <23887878-4240-328a-4716-b67dd8d218db@gmail.com> From: Joseph Brennan Date: Mon, 13 Jul 2020 14:28:17 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-13_15:2020-07-13, 2020-07-13 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 13 Jul 2020 18:28:35 -0000 > > > > 2) draft-crocker-dmarc-sender > This is an elegant solution. It puts the burden of change-- creating a Sender field in all cases, and a variant DMARC record-- on the domain owner who wants to send mail and use DMARC rules. The use of Sender complies with RFC 5322, since it is optional whether to create Sender when it is the same address as From. With this implemented, developers of mailing list software can stop figuring out which way to violate RFC 5322 in order to make mail deliverable, and developers of clients do not have to create and display a new Author field. Big win, for widespread acceptance, I would say. -- Joseph Brennan Lead, Email and Systems Applications From nobody Mon Jul 13 11:29: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 19FF73A167F for ; Mon, 13 Jul 2020 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 1N8Twc-x7rCZ for ; Mon, 13 Jul 2020 11:29:56 -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 C61C63A1675 for ; Mon, 13 Jul 2020 11:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594664994; bh=bGwr9kgmpovXWUNwMZBHD9UnaJdwym+CEEBcfEBwky0=; l=1724; h=To:References:From:Date:In-Reply-To; b=BjJ8iFFN4GEghJEYdiNJE4VVNx7iTca5f93Jg4iTQnuyOFixPvRqIWyWu6Wy9he+K l8HmMcSULvl9AVe493yCCyeJNAQHf/Km6OyzLxTCjVpRaxXj1p2e9NAwpSF8uh2Txw RD9Cm6j7Y1fjqfxoAd4ETvfYWOOjcfO/u5PJPK/8xmxt6YUtyOIEopJcEtw9U 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.000000005F0CA822.00005C32; Mon, 13 Jul 2020 20:29:53 +0200 To: Dave Crocker , dmarc@ietf.org References: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> From: Alessandro Vesely Message-ID: Date: Mon, 13 Jul 2020 20:29:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 18:29:57 -0000 On 13/07/2020 19:27, Dave Crocker wrote: > On 7/13/2020 9:29 AM, Alessandro Vesely wrote: >> On 13/07/2020 05:10, Dave Crocker wrote: >>> I've just submitted an initial draft to define an RFC5322.Author field: >>> >>> https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ >> >> >> Dave, >> since you also posted a second draft, I'd strike considerations about the >> Sender: from this one.  In particular, the 4th paragraph of the Introduction, >> "Because the current [...]", is distracting and unhelpful. > > Unfortunately, misunderstanding of the relevant human factors is often > introduced in discussions in this realm.  People are remarkably resistant to > the behavioral facts on his, so, unfortunately, it needs repeating. It'd be enough to say Sender: is syntactically and semantically different. >> Another use case of Author: is to indicate multiple authors. > > That's supported by the draft spec, since it copied From: syntax. > > >> I'd support making that a WG I-D. > > Thanks. Thank you. >> IMHO, it could be standard track and modify RFC 5322 if accepted. > > The mail header is extensible.  Addition of header fields does not require > modifying the base specification. Restricting From: to be single-address, or at least having all domain parts aligned to one another does require an updates= tag. Of course, ticket 74 has to be addressed in dmarc-bis too, or one of its parts, since Alexey said we are likely to split up the current document into multiple drafts. If the Author: I-D is going to be one of those parts, it's be convenient to recap usage of Originator Fields in the DMARC era in a single, short document. Best Ale -- From nobody Mon Jul 13 11:35: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 D06BB3A17D8 for ; Mon, 13 Jul 2020 11:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 XLCJpGtMV78A for ; Mon, 13 Jul 2020 11:35:34 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 D66193A16D1 for ; Mon, 13 Jul 2020 11:35:12 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id d27so10764336qtg.4 for ; Mon, 13 Jul 2020 11:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=VTWGy6xYJtmm/Z+dba1znWB/hZh2v/rWLP8qEoUl2Bo=; b=AFU9bl+DPPtf4934Jo+SpaZvkpLwdJmGWyny4zyzwzperrCyO5lTQwFDvCDMEUTjHc NQ47elI9RuiC4UoPqjOxMo4LbYdMvUqaA9aWHtLh9f4MCUMEl+hgQEIx8jnYL/X3jhb9 hDGypZLtU/KFAcUmqo5XWXmWqBx3rhlQkfNkg/jpC/Yl3DfEyCD6wTXR5WIMai5cIi19 1t1lfISoN1dm2RbFMuWAxsRtRQpPvURqZ+LwKllVw10zykPtIg/tNKuHpi/UtLcbs4Pv DBI4GpudzHxR7n5YqPWUYCycN3UxlIO8CozdGlu8+IcVrFBgwMqX7vWFeraHDgUBUilm o6Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VTWGy6xYJtmm/Z+dba1znWB/hZh2v/rWLP8qEoUl2Bo=; b=i3eze4f0thFYVCCOaM6rvrsaX/NkzKJxTRIaMvd0sYl/YXE2BeACOjCLKp+b2yhxKU 0Dqo8LKFN9hwU3kn82MSI6qnLcU8pRzsmq98L+J0MHvpjfrnN6MAoEPoKgYfPCmkV/PG wU4KGW9cAmjrcHIVGFplhPbxT0c6TBLQjyCboupHEAxDosfc8zoOFpZT04qfomwjxwJM bII0RAm7yIdCRNVrj+vBhoEzfwvFwVEzaMWeVr3EGUv3F7chy28ZuwHBnDvwmFEgCYzI hxX+lR0lLZw62orJVXCR51IJY5Ek8eORfhMgA99EA/veVhpeU8IRGS8AcYpF/8k43Tok wkmw== X-Gm-Message-State: AOAM532N6Es1lJG6khZKRtVIYBap/8alAW9tf0Uryp/qPmjaPWMdm/Qr zoISKnvlqKAdmWHtvju1y7km+xJ3VAo= X-Google-Smtp-Source: ABdhPJzWvyvfLLNdL1WECMaDsr//EPiI4kj+pCUsGTnDSGvpHkLdYzjcQqdd/xFvV31Khcu2/KYrAg== X-Received: by 2002:ac8:4507:: with SMTP id q7mr738533qtn.142.1594665311596; Mon, 13 Jul 2020 11:35:11 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:401c:ce47:b522:3c86? ([2600:1700:a3a0:4c80:401c:ce47:b522:3c86]) by smtp.gmail.com with ESMTPSA id p186sm20055192qkf.33.2020.07.13.11.35.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 11:35:10 -0700 (PDT) To: Alessandro Vesely , dmarc@ietf.org References: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> From: Dave Crocker Message-ID: <0c0da73f-d228-c393-6709-a9621c79befd@gmail.com> Date: Mon, 13 Jul 2020 11:35:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF398476C34344245C57DABC" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 18:35:41 -0000 This is a multi-part message in MIME format. --------------BF398476C34344245C57DABC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/13/2020 11:29 AM, Alessandro Vesely wrote: > IMHO, it could be standard track and modify RFC 5322 if accepted. >> The mail header is extensible.  Addition of header fields does not >> require modifying the base specification. > Restricting From: to be single-address, or at least having all domain > parts aligned to one another does require an updates= tag. ahh.  hadn't seen that was your point.  well, whenever there is an effort to do substantial revisions to mail format, this might be worth considering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------BF398476C34344245C57DABC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/13/2020 11:29 AM, Alessandro Vesely wrote:
IMHO, it could be standard track and modify RFC 5322 if accepted.
The mail header is extensible.  Addition of header fields does not require modifying the base specification.
Restricting From: to be single-address, or at least having all domain parts aligned to one another does require an updates= tag.


ahh.  hadn't seen that was your point.  well, whenever there is an effort to do substantial revisions to mail format, this might be worth considering.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------BF398476C34344245C57DABC-- From nobody Mon Jul 13 12:08:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC53A175A for ; Mon, 13 Jul 2020 12:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_4OcEEgx3K5 for ; Mon, 13 Jul 2020 12:08:19 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 1A9CB3A1786 for ; Mon, 13 Jul 2020 12:08:15 -0700 (PDT) Received: from pps.filterd (m0167068.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06DIefNS016975 for ; Mon, 13 Jul 2020 15:08:14 -0400 Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0a-00364e01.pphosted.com with ESMTP id 3277pwb1ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Jul 2020 15:08:14 -0400 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06DJ8CFr041872 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 13 Jul 2020 15:08:13 -0400 Received: by mail-il1-f197.google.com with SMTP id s137so10131618ilc.18 for ; Mon, 13 Jul 2020 12:08:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OHYeOu1JHLMo2otwF0xKEQ476zUPypULImo/Q9Kwpe4=; b=jC51a/+rERXr8vA2B87fIQbXel2pds+QNXyCQkkUu9bBdJdA241zqW0pdZNp7+tb/F NfSNPYPvaymRomWjtJQ/Ol2dYgV8yM4GfPJw9vWkSbcf6ayJGfU1oHwDdIsQfS1GES2c bCrB7JhN0grNR4uH8DLBN7EVPhFm3zwUd80r3yE9SubTe6l1BlLL3vktSB/+T4oyhqxb 7/NNPZbD9jwPU6kYq2zaZBtdwAQAUGqScZK7MXm2163E/9q0onRiG8SwFkLFbg0IINRm hIk1/1CbkVQP2TlxEIvCqVRYrwCL8zPW5J3m2DeeFVxwHe2/qPEdHiLNoOxLVaNlXFFS LAJw== X-Gm-Message-State: AOAM532gt8zv9g6kU7QUCgvUZME9ikIeqFTAz+gOxr1mAv97tEMQaYp+ 28f56CtMh7GjcTviULORR9noG5TyD9+E7chzfpHYG6lJdB4GTsGCJu3zZnQ8daXsbau8cZJUdhx ex/PEMkilPDtMRTe5fUvMC7e1j9eDzg== X-Received: by 2002:a05:6638:250f:: with SMTP id v15mr1723889jat.97.1594667291758; Mon, 13 Jul 2020 12:08:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuh/MZrgFZIYaWioTc1wLg0qy9aKXsD8yioItEv8lif1T/f0HSW6yUojiCcm9ESu9C4vd7fGGhfM2664SAW2Q= X-Received: by 2002:a05:6638:250f:: with SMTP id v15mr1723852jat.97.1594667291264; Mon, 13 Jul 2020 12:08:11 -0700 (PDT) MIME-Version: 1.0 References: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> In-Reply-To: From: Joseph Brennan Date: Mon, 13 Jul 2020 15:08:00 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-13_15:2020-07-13, 2020-07-13 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Jul 2020 19:08:20 -0000 We already have a field for author, called From. Why add another one? "The only required header fields are the origination date field and the originator address field(s)." By this, RFC 5322 refers to the From field. I think client software developers would be inclined to ignore creating the Author field, or else to create it and populate it with the same value as the From field. Mailing list software might want to create Author and copy the value of From into it, and then insert the list address into the From, but then, they run into "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." No better than where we are now, is it? -- Joseph Brennan Lead, Email and Systems Applications From nobody Mon Jul 13 17:23: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 F14383A0BE7 for ; Mon, 13 Jul 2020 17:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 FqKtzs75DOj4 for ; Mon, 13 Jul 2020 17:23:37 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 0487F3A0BE6 for ; Mon, 13 Jul 2020 17:23:36 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id g67so6788074pgc.8 for ; Mon, 13 Jul 2020 17:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=yz72FXXVgUxc6oT1KiMhVRKoaKQdpmMIWkQFt3q6HRM=; b=GNurEF8Mx/nVNqCKX6bkqrpPtSaMiLh1asSPI//RifXgxyGFWcRi8lOV+WD4NwwOwi 4KafbCseKc0jkooza7/8D0Nh4j+yDFWQkiTS27j9eOaZzllMSrW/XN2y6DxkxgbEYWeV cuZWmqfx7/ds/jKPkmGWuJhCYvGAbv5hNgn2cZgTypmvGDOaatO9CHbZRnEDJKJj4b1U 0HSjirCMprZduLxuZYa3z3gGj0pFgSRvB2kTinAg2e7QKQad4Q+gRW+p2CGbxXh04mLt F3DL8jRClhYm/qiVuxobb7kSzTtlj6qtwdW7+axcSTyuQ4ivNOTYNLnd582gPmThaAYj 6Kvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yz72FXXVgUxc6oT1KiMhVRKoaKQdpmMIWkQFt3q6HRM=; b=dMGNt+VerRExOqCgr2D+c8cpjDRxr2CHZe/nRa5o/jCEnCbJWEGRiQLTfdv7YGu4ex EhO+ZaMqZ7E4N5s9p4jwhhxotQZsyhF1uez9XXTwdRCBb/3i+XTKF80SwqzPRCBMiqzy v0Dfy7goYAx+4EjPBoWl5oTJhvk0Fwqx5fRFUvo75aPqKFyu0i5uH+NTjDed9wSClB2h OqT+oUhenYGXGA1z0iyI8iY0SOLgO4gZZUb+CfKupfPXtNeWq7GW1u7048/Je87mseuI kmL6GpJL3Rk/qpFUntvlbTKEHLimDogKvLfxUEDGNLqeYpiqROAHVzMM+hbC+6KSI9E0 YFyg== X-Gm-Message-State: AOAM530jCG7iSfuAnh5tQV69Kj8+6RFh3TKS/8RShttk0Ya9VVZDChhJ TaPK8ZzxfqXg1DJ1i2dzCZRz6v2NeEw= X-Google-Smtp-Source: ABdhPJzxqEotQj/oS9aq+ItHDNXxAqboMEX7TY6oqWQlks5K1o0Dzk8nxLOkNmt9LMXZCjTwsA3eMA== X-Received: by 2002:a62:1b4a:: with SMTP id b71mr2184833pfb.9.1594686216036; Mon, 13 Jul 2020 17:23:36 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:f0a6:57f1:7cd3:a35? ([2600:1700:a3a0:4c80:f0a6:57f1:7cd3:a35]) by smtp.gmail.com with ESMTPSA id b191sm14256142pga.13.2020.07.13.17.23.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 17:23:35 -0700 (PDT) To: Joseph Brennan , IETF DMARC WG References: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> From: Dave Crocker Message-ID: <94b264de-81a0-2f6e-7673-99279e630f9c@gmail.com> Date: Mon, 13 Jul 2020 17:23:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Jul 2020 00:23:38 -0000 On 7/13/2020 12:08 PM, Joseph Brennan wrote: > We already have a field for author, called From. Why add another one? 1. Note that the From: field typically serves two different semantic roles, author and 'handling agent' (ie, Sender:) 2. Pars 3 &6 of the Introduction lay the foundation for needing a new and separate header field. Simple summary:      These days, the original From: field is tending to get corrupted and we need some place to put author information that won't be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 02:52: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 036F73A0893 for ; Tue, 14 Jul 2020 02:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ogvwVCuyTiHH for ; Tue, 14 Jul 2020 02:52:28 -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 77CDC3A092F for ; Tue, 14 Jul 2020 02:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594720345; bh=3foqgv/GuSVGcJvLEHZuUxshkuKL6iDK7C+tcF9Xmnw=; l=552; h=To:References:From:Date:In-Reply-To; b=CgOXmScp0BwKzuu1A0Xo1f7FxC1w4D7Nbh2i4lCXGWPpVM+khJe/Nj4XhGQ3wFn2h ak4iZ+aR21e2UwZmIGyi8OjVNYO0FnFfwO3BMHW6DCOG9z1HLGXzIDmHyOwAaTJwCC hYrFJQQj+ZcLfcUVQganLXG860di5XkzZJyEvxGay6n2EYgPle4RnBeeJVscC 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.000000005F0D8059.000028C8; Tue, 14 Jul 2020 11:52:25 +0200 To: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> From: Alessandro Vesely Message-ID: <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> Date: Tue, 14 Jul 2020 11:52:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 09:52:30 -0000 On 13/07/2020 20:28, Joseph Brennan wrote: >> >>> 2) draft-crocker-dmarc-sender >> > > With this implemented, developers of mailing list software can stop > figuring out which way to violate RFC 5322 in order to make mail > deliverable, and developers of clients do not have to create and > display a new Author field. Big win, for widespread acceptance, I > would say. And phishers can also send mail From: fm.bank and Sender: regleissei.icu. To publish a DMARC policy would avail Farmers & Merchants nothing, then. Best Ale -- From nobody Tue Jul 14 05:30: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 1F9163A0B8D for ; Tue, 14 Jul 2020 05:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=RUiI8dx2; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=DN2UAnoI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfLLlzoCXw-q for ; Tue, 14 Jul 2020 05:30:14 -0700 (PDT) Received: from mail.winserver.com (pop3.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 9F4223A0B80 for ; Tue, 14 Jul 2020 05:30:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4241; t=1594729810; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=yZNzUYSHMqWfLcYNNz6O4VHGX3s=; b=RUiI8dx2mauzMBsTONtxXIKDdLWSHFHPUhfqoimGvUt56B+E0y9NWtXV+FrxFy 4EWdmu3C1lN8nrt9d5vh174UJTI4E3RLkCNQ/IGkt/sipphcVH1QvrmpqjLUzW7S IaI5GRxjgmaAqdG5jDeWSpek72gQwKigzkPrxLZZnNnnM= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 08:30:10 -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 1162117138.1.6484; Tue, 14 Jul 2020 08:30:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4241; t=1594729722; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pxE6o4+ w1+CKkmCwq8pmoOi6zcrnYB7GsI0qhJ00D8s=; b=DN2UAnoI9IQeB48u+sCh/dn iwDxk+KjNmeqXcw3RVbH/mJcGHXpdd4eYpEQs5qdagveuD9MAAMxR5N6B2ygtmdv Wu7pgO7F9z5yoPv0+tcPkoxfWlT24Io0SHDcFcqwLS+NMT4Mag3OiHgGnMvKPqko JSwByuJ/H0y7D3JDf4Vo= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 08:28:42 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 872897468.3.17848; Tue, 14 Jul 2020 08:28:41 -0400 Message-ID: <5F0DA550.2000505@isdg.net> Date: Tue, 14 Jul 2020 08:30:08 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> In-Reply-To: <23887878-4240-328a-4716-b67dd8d218db@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 12:30:17 -0000 On 7/13/2020 1:21 PM, Dave Crocker wrote: >> >> A proposed new 5322.Author header? > > Yes. > > >> Is is required to be hash bound to DKIM signature? > > No. In fact the DKIM requirement to include From: in the set of > hash-bound text was a last-minute imposition by an area director, > rather than a functional need set by the working group or larger > community. No disrespect, but I was an active participant in the DKIM WG and I don't remember this to be the case. Since DomainKeys, the 822.From was required to be hash bound to the signature. I recall this being carried on to DKIM and we did debate the merits of the binding requirement as the sole anchor and immutable object that remains with email. https://tools.ietf.org/html/rfc4870#section-3.3 and it did not change with DKIM followed up: https://tools.ietf.org/html/draft-allman-dkim-base-01#section-5.4 That has never changed. Let us keep in mind the fact DomainKeys and the follow up DKIM work, both had a built-in policy component based on the 5322.From anchor identity since the 5322.From identity was a hashing requirement. The original APIs for DKIM and Domainkey had SSP/ADSP lookup functionality. 822.From was selected because this header is not expected to be legitimately modified or removed in transit. In fact, the signer has a SHOULD NOT hash a header that could be modified or removed. This proposal will continue to perpetuate the idea that 5322.From MAY be modified. Yes, I do recall that advocates (mostly you and Levine) were against the 1st party Author Domain dependency requirement preferring instead a 3rd party sender, 3rd party signer authorization and trust model. > That said, of course I'd expect signers to choose to include it. I don't see how this can be escape. Something has to be sacred in email and right now, it is 5322.From which is not expected to be modified. Cracking open this door will have its consequences. >> Will be make it a MUST NOT modified NOR rewrite it? > > No idea where this would be mandated or why. Because of the policy component. We are here because the original design model aspect to bind an immutable object like 822.From is once again being questioned by these proposals by the same folks who never wanted it in the first place. >> 2) draft-crocker-dmarc-sender > It's a proposal to have DMARC use the Sender: field, in preference to > the From: field. Ok. >> Does this mean the Sender header is now required to be hash bound to >> the signature? > > cf, above, about the nature of the requirements. Again, it would make > sense to bind it, but mandating is a separate issue. I am not closed to either proposals but I don't see we can "safely" have it both ways. You need triggers and variant logics for backward compatibility and also for enforcement. We have the logic in place to resolve this issue. The List Systems need to be updated. Bottom line. If we are asking developers, signers, verifiers and resigners to "change" then it should consider what are the current change "requirements" versus anything new to perhaps simplify it, scale it, but most importantly resolve the all important 3rd party signers authorization issue. We spent 15+ IETF-MAN years in all this and we now going back to the 1st party vs 3rd party signer design model. Does the DKIM Service Architecture still applicable? https://tools.ietf.org/html/rfc5585 I believe it was settled that a DKIM Policy as a function of the 5322.From Author domain, the legitimate copyright holder of the self-signed signature, was a good thing to do to maintain a strong original integrity of the email. We knew the list integrity change issue was a problem. We said "make them resign" and they began to do so. We also knew restrictive policies will cause a list distribution problem with downlink verifying receivers primarily because we didn't have a 3rd party resigner authorization protocol. This is where we left it, never to go away, and its back again. How do resolve this without re-inventing email and introducing new headers? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 14 05:43: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 04E7B3A0BEF for ; Tue, 14 Jul 2020 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=R4oanWb/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=NurYPAyS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwzP5dEx5T6X for ; Tue, 14 Jul 2020 05:43:44 -0700 (PDT) Received: from mail.winserver.com (pop3.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 C4FD03A0BE7 for ; Tue, 14 Jul 2020 05:43:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=619; t=1594730621; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=GTwTNokht8is8tDdLjpMUFj08Do=; b=R4oanWb/5kW1hQYcXp9m37RlMECc3m7WBIYGTgG1jsqXxhMShknXsFcAuGtFI0 t9arj0LAZPdNWt3hkDmb8l+u9rHmCcFlAttUoY/6ZIbgvEFMv5T9uUIe8KZHAJ1P cTs5d+/DYvcfVw4lcn1T16Og44MrDdeh1QvUPcY2CP2RE= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 08:43:41 -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 1162927095.1.6788; Tue, 14 Jul 2020 08:43:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=619; t=1594730531; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XLr5EBm hlyFWlFnko+C8Do0VAXkIEXJZDCpWQSQKN4g=; b=NurYPAySwJbzNC5czXR4OlO 9cN64xX0xWTmgJsMvryrzYNtgzktHuRUte5qT38saxG+QjXY3/sQkhRaYQ10Kid8 rh5GFsN6KZEK1kLT6In5BVGV1rkFDLx+dluagKaruN4nwIOQkkNVl86zkVC03nlE fqgzFBWItzIEPniyMvR4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 08:42:11 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 873706687.3.14840; Tue, 14 Jul 2020 08:42:11 -0400 Message-ID: <5F0DA87A.6020003@isdg.net> Date: Tue, 14 Jul 2020 08:43:38 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <2a49d9e1-bf37-6801-d691-a8cf4cb10570@gmail.com> <94b264de-81a0-2f6e-7673-99279e630f9c@gmail.com> In-Reply-To: <94b264de-81a0-2f6e-7673-99279e630f9c@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Jul 2020 12:43:46 -0000 On 7/13/2020 8:23 PM, Dave Crocker wrote: > On 7/13/2020 12:08 PM, Joseph Brennan wrote: >> We already have a field for author, called From. Why add another one? > > Simple summary: > > These days, the original From: field is tending to get corrupted > and we need some place to put author information that won't be. Then imo, it must be an immutable header object and a requirement to be hash bound. This changes DKIM-BASE and the DKIM Policy protocol. Lacking this requirement, leaves open a variety of loop-holes. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 14 06:16:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E37E3A00E3 for ; Tue, 14 Jul 2020 06:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Rz07S1Tf; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=X0hxpHpj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUmoAwb9sgnC for ; Tue, 14 Jul 2020 06:16:24 -0700 (PDT) Received: from mail.winserver.com (pop3.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 44E903A00DF for ; Tue, 14 Jul 2020 06:16:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2215; t=1594732576; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=WXMIisGmwVHQKCHzXRlI+fx08nA=; b=Rz07S1TfGBJLQ5TKERwHAHHjHaF8KCuGwHX0ywuDgJjzhXwJoOYUm11aK9FiKm IWmDhZYikgIWaH3NmxPXCsEGbYJSg/6Qgs1xfrXEhnvyYz5CTplM8cSHFWa4keTc TP5s3jmLdk8QkfmI8almdol5H7JrcTM+RB/UpZib1F10Y= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 09:16:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1164882599.1.3076; Tue, 14 Jul 2020 09:16:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2215; t=1594732490; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IEFTjKT y3seWd8TgL/Bt5WhqPB54tp2ZBKPAAT895pw=; b=X0hxpHpjeGBdrph+wl48nRS r4GxBm44jiWAu4McrBpyAB2AIMM7/z/4VWyj7W9bV3OXZiuBifbj3yRVZgFGtfjf fM16uZcwEuoxhhykn6FkmoJb+nahXszEKOXIiRk6OYrAyV30BTC0pJe1KEwudqb/ NI0thMNbPZDMyIiu3ZEQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 09:14:50 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 875664984.3.16196; Tue, 14 Jul 2020 09:14:49 -0400 Message-ID: <5F0DB020.4040109@isdg.net> Date: Tue, 14 Jul 2020 09:16:16 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 13:16:26 -0000 On 7/13/2020 2:28 PM, Joseph Brennan wrote: >> >> >>> 2) draft-crocker-dmarc-sender >> > > This is an elegant solution. It puts the burden of change-- creating a > Sender field in all cases, and a variant DMARC record-- on the domain > owner who wants to send mail and use DMARC rules. The use of Sender > complies with RFC 5322, since it is optional whether to create Sender > when it is the same address as From. > With this implemented, developers of mailing list software can stop > figuring out which way to violate RFC 5322 in order to make mail > deliverable, and developers of clients do not have to create and > display a new Author field. Big win, for widespread acceptance, I > would say. Sender: is already set by most MLM, if not all. Error-to: is also set for compatibility reasons. The proposal for policies to depend on Sender with a From fallback does not resolve the 3rd party authorization problem. We currently have two identities: - ADID Author Domain (5322.From) Identity - SDID Signer Domain (5322.DKIM-Signature d=) Identity. We also have the well-defined and recognize distinction: - 1st party where ADID is equal to SDID - 3rd party where ADID is NOT equal to SDID The ideal DKIM model is to do a: - 1st party, no problem, with the self-signed signature. No need to do a DNS-LOOKUP if ADID is equal to SDID. However, there were consideration for a NO MAIL policy. It was determined we can do this a null public key. - 3rd party, Policy lookup based on ADID to determine if SDID is a legitimate resigner. We have no protocol for this. Adding Sender (lets give it an acronym SRDID) to the mix does not change the authorization problem. Under these resigner conditions, the SDID=SRDID would be expected to be the same domain this making SRDID redundant. One way to do this is with the ADID adding a SDRID or SDID DNS record which is how ATPS "Authorized Third Party Signer" works. Another way is use a non-DNS based conditional signature idea. There is also TPA. Supposedly, it scales better than ATPS as a DNS record lookup proposal. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 14 06:41:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEF73A0112 for ; Tue, 14 Jul 2020 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 qE5lzzNJ1a91 for ; Tue, 14 Jul 2020 06:41:56 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 8E62B3A00E3 for ; Tue, 14 Jul 2020 06:41:56 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id x62so12794042qtd.3 for ; Tue, 14 Jul 2020 06:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9TUHSgokapkw13mUSKuc0ZxZVKKYcorntlpJqSArNuo=; b=YhNPiV5xdzKLUmlKBjeY31YmSYKOonGmVvLySn08Ohd817cdCjCTIpAdaAjoP3cf6N 69jM7WCyLFu5l9utwk8u6JuKqzVeBs/ztFnUgKB63Qx6zl4gRAupyLP1kCp0HpADJyoo ObC0RTxkqFwbCOXnuTgvyQeQB5mOU0qSrUR3ZiDZbtUWMEM2kXRNWzBPg4qFRRnYZ2+h YrmG9iIrf88TdmC+X2EBq960f3eNTgVD2XU70HS7ZVIcarbd/2SQEHU0WMNNnxHMJEqm z+K5p0KhvuKZwvO9Zuk0n+vNnxL+7RIN5oR5wfG0oAQjMECi5wpud/s6PxsHBrd1H4By ObFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9TUHSgokapkw13mUSKuc0ZxZVKKYcorntlpJqSArNuo=; b=UWHrcLYPRno9NkBCxVkS4L57/WM+3CtXfAlqwRYWDndIHGRAM8EfjLVjd3559TuJTy QhiDKhIUrl0JJfTVigBpXIQXNh6n0Z8niUYCW39tgsK6mbCCUBm5MASQoy0hEeZa2lgK Dr/sFx3vVMCnMc3ajKRtMC5QazhkVNIg7/cItaqJ03bVXp6zEwN1A0gZA40DUr72jMdT 0BgJYrKk3ucoT87ZLga2ndr4w2ksIVzcZ3Otxjq+wwflzQ+f2vM16sG+gnhFg6k745Y7 Q4wgT7mkWibmHCxacKYeLVJqFYU+BRfxKXoUyJwQ61/TUYTAaTALjshz/nm0MfnK2oyK a7UA== X-Gm-Message-State: AOAM533omUt2Y408e1ynzrPcJ22m5088zk1iXyjtsbgVUyAPs1Sy7TCT IhPOSN2kYk5l0UjrfMJ86ItLP4a6lcI= X-Google-Smtp-Source: ABdhPJwSzgNejQiT2zgElbKqJ4y6Cez5ehZ8JqPgA8q2BPWaP2iPpocM0sXwPhlgMmPEXGSMlDUQXQ== X-Received: by 2002:aed:3fac:: with SMTP id s41mr4646418qth.86.1594734115233; Tue, 14 Jul 2020 06:41:55 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id i28sm22594416qkh.1.2020.07.14.06.41.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 06:41:54 -0700 (PDT) To: Alessandro Vesely , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> From: Dave Crocker Message-ID: <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> Date: Tue, 14 Jul 2020 06:41:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 13:41:58 -0000 On 7/14/2020 2:52 AM, Alessandro Vesely wrote: > And phishers can also send mail From: fm.bank and Sender: > regleissei.icu.  To publish a DMARC policy would avail Farmers & > Merchants nothing, then. If regleissei.icu publishes a DMARC record and indicates support for use of Sender:, per the proposal, please explain exactly what bad things will happen, in the case you offer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 06:48: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 A4D5A3A0400 for ; Tue, 14 Jul 2020 06:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Rg4iZvQR; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=xJ/bYfwn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R399TmyXBNd4 for ; Tue, 14 Jul 2020 06:48:14 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738883A0112 for ; Tue, 14 Jul 2020 06:48:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=776; t=1594734485; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=izlKvNc+7bn5Iv4V4hySanfMlx8=; b=Rg4iZvQRxPF12hPKLtH7bpYWAU3CI0R/Z0ErdqJ7nULJ3WBwFBkXHe7NMffnWD 1EnCmkD3TSS9y/DA9CINnqZ+VW8HBh0jiILOz6AfFrawjvF2R0xvVxn9nXTYRjPe tgJ+LJrQ0sPt1WyEh+iotQ7wtOxQjyzD65y783uv1o6R8= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 09:48:05 -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 1166792301.1.4836; Tue, 14 Jul 2020 09:48:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=776; t=1594734397; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rcU0SR3 MDXM+08AT9N/cdCRFIDSDN0KcZxA+1ZF00JM=; b=xJ/bYfwnRpw/NhnAf05YDWD Hg/joNi284NxwIep1IPhpITyFZJNjyJT25d4kS5n4nfXiJupSVcGKjbcC5ZBnjiI iHOhMwglAjKNgT3Uo52hi0oajWzMAIAWY9XIclopts24PdqdYcy9aAcs8m1xrdUn +UGWZ3WW8hkGs3O79ZoI= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 09:46:37 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 877572781.3.17136; Tue, 14 Jul 2020 09:46:37 -0400 Message-ID: <5F0DB794.4070506@isdg.net> Date: Tue, 14 Jul 2020 09:48:04 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Jul 2020 13:48:17 -0000 On 7/13/2020 12:29 PM, Alessandro Vesely wrote: > I'd support making that a WG I-D. I am having trouble with it, so ~1 > IMHO, it could be standard track and modify RFC 5322 if accepted. It will modify all specs related to DKIM where there is an Author (5322.From) design requirement. I don't see how a new "5322.Author" header changes anything especially if NOT defined with the following characteristics: - MUST NOT be modified - MUST be hash to signature. Dave, indicated it is expected to be hashed bound to the signature. That makes a SHOULD but not a MUST. I don't see how we can trust a DKIM-signature that has no immutable identity requirement to it. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 14 07:45: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 9C0F93A0827 for ; Tue, 14 Jul 2020 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Cq/vmoes; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=HNcAYQ2E Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyjHDKYOfLYK for ; Tue, 14 Jul 2020 07:45:35 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D1A3A079E for ; Tue, 14 Jul 2020 07:45:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5031; t=1594737926; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=cb0KdhoRRk/ECEUNelP7ae/z7yU=; b=Cq/vmoeskC7nrXp/tzhNBuOSvYsPM0KENnivvibBvfro0FIETgJgfNPNpQDmjk ksWWcqiXw2FtWfQN1iYImDNVYJswflHsWFO7j2hM6MG1lQ4ijkX9l9Ai3LsrnYEZ 0hxRLy629IPUio6DSq80FQWgrhyOCHO1tJrP0ldYVZjGg= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 10:45:26 -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 1170232466.1.5880; Tue, 14 Jul 2020 10:45:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5031; t=1594737838; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=aZkUcZz /1OyOZiH4ktkODTIHPsYC3Gwtj8VRuAteTYk=; b=HNcAYQ2ENEXgods+tnOZQj9 GDYU1jG1sheqkouEHgikTOSJXzF4CYHZglB3TtlB/L7eCfazKxHntUxd/zaSDuAT WPG/5Y0Mq5CgzYgpiwnUVXIq9PxMiHfTbEYSJIKKa5++dRqFX1CyqnFYwh85MIPq br4oHnVMLiJOykhWoF68= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 10:43:58 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 881013421.3.17108; Tue, 14 Jul 2020 10:43:57 -0400 Message-ID: <5F0DC505.5020009@isdg.net> Date: Tue, 14 Jul 2020 10:45:25 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org, Dave Crocker References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <5F0DA550.2000505@isdg.net> In-Reply-To: <5F0DA550.2000505@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 14:45:38 -0000 Dave, Take a look at how DomainKeys considered the "Sender" header. It may help your proposal for Sender. https://tools.ietf.org/html/rfc4870#section-3.3 Specifically, regarding the "h=" tag: If present, this tag MUST include the header that was used to identify the sending domain, i.e., the "From:" or "Sender:" header; thus, this tag can never contain an empty value. and also section 3.1 "Determining the Sending Address of an Email" https://tools.ietf.org/html/rfc4870#section-3.1 where there is a protocol language regarding From: and Sender: -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos On 7/14/2020 8:30 AM, Hector Santos wrote: > On 7/13/2020 1:21 PM, Dave Crocker wrote: >>> >>> A proposed new 5322.Author header? >> >> Yes. >> >> >>> Is is required to be hash bound to DKIM signature? >> >> No. In fact the DKIM requirement to include From: in the set of >> hash-bound text was a last-minute imposition by an area director, >> rather than a functional need set by the working group or larger >> community. > > No disrespect, but I was an active participant in the DKIM WG and I > don't remember this to be the case. > > Since DomainKeys, the 822.From was required to be hash bound to the > signature. I recall this being carried on to DKIM and we did debate > the merits of the binding requirement as the sole anchor and immutable > object that remains with email. > > https://tools.ietf.org/html/rfc4870#section-3.3 > > and it did not change with DKIM followed up: > > https://tools.ietf.org/html/draft-allman-dkim-base-01#section-5.4 > > That has never changed. Let us keep in mind the fact DomainKeys and > the follow up DKIM work, both had a built-in policy component based on > the 5322.From anchor identity since the 5322.From identity was a > hashing requirement. The original APIs for DKIM and Domainkey had > SSP/ADSP lookup functionality. > > 822.From was selected because this header is not expected to be > legitimately modified or removed in transit. In fact, the signer has > a SHOULD NOT hash a header that could be modified or removed. This > proposal will continue to perpetuate the idea that 5322.From MAY be > modified. > > Yes, I do recall that advocates (mostly you and Levine) were against > the 1st party Author Domain dependency requirement preferring instead > a 3rd party sender, 3rd party signer authorization and trust model. > >> That said, of course I'd expect signers to choose to include it. > > I don't see how this can be escape. Something has to be sacred in > email and right now, it is 5322.From which is not expected to be > modified. Cracking open this door will have its consequences. > >>> Will be make it a MUST NOT modified NOR rewrite it? >> >> No idea where this would be mandated or why. > > Because of the policy component. We are here because the original > design model aspect to bind an immutable object like 822.From is once > again being questioned by these proposals by the same folks who never > wanted it in the first place. > >>> 2) draft-crocker-dmarc-sender > >> It's a proposal to have DMARC use the Sender: field, in preference to >> the From: field. > > Ok. > >>> Does this mean the Sender header is now required to be hash bound to >>> the signature? >> >> cf, above, about the nature of the requirements. Again, it would make >> sense to bind it, but mandating is a separate issue. > > I am not closed to either proposals but I don't see we can "safely" > have it both ways. You need triggers and variant logics for backward > compatibility and also for enforcement. > > We have the logic in place to resolve this issue. The List Systems > need to be updated. Bottom line. > > If we are asking developers, signers, verifiers and resigners to > "change" then it should consider what are the current change > "requirements" versus anything new to perhaps simplify it, scale it, > but most importantly resolve the all important 3rd party signers > authorization issue. > > We spent 15+ IETF-MAN years in all this and we now going back to the > 1st party vs 3rd party signer design model. Does the DKIM Service > Architecture still applicable? > > https://tools.ietf.org/html/rfc5585 > > I believe it was settled that a DKIM Policy as a function of the > 5322.From Author domain, the legitimate copyright holder of the > self-signed signature, was a good thing to do to maintain a strong > original integrity of the email. We knew the list integrity change > issue was a problem. We said "make them resign" and they began to do > so. We also knew restrictive policies will cause a list distribution > problem with downlink verifying receivers primarily because we didn't > have a 3rd party resigner authorization protocol. > > This is where we left it, never to go away, and its back again. > > How do resolve this without re-inventing email and introducing new > headers? > > > From nobody Tue Jul 14 08:34: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 DA20F3A08A6 for ; Tue, 14 Jul 2020 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 lHPDZac8DZoX for ; Tue, 14 Jul 2020 08:34:01 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 2201A3A089B for ; Tue, 14 Jul 2020 08:34:01 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id m9so7661914qvx.5 for ; Tue, 14 Jul 2020 08:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=414KSEQvRGVHtQkNLxaSaKDR+EpVj+byngh1Xqk6qPg=; b=oUOV1VocTGa5gcMaXhXas7vEjI6nkCNd4y1jmJ3i0XOE6SdQ1+Uym+dEoIF/IPsdBN XAry+L0kcc6Nvj/+NAu7ViGabyq6rtWXXxHbas3j/5qrlqnoLl5fzGNSIDS+KbqWgAfn NFhhtqp8Hf3nv4XrDYUL6g8kZyJsBn5oZaddNTu15A53f/ByguULVTtG5UFcYSev8m2D AmZDb3aCsQ5Q77chxvAGRWrd1RttA4XT9pgtocyHIevkyc2N1dmM15jvINyINwVdIqt9 OHF4GiCETqumGiuhJaqLggQeTFS+LBfIFvAOFrp6yvuDT+iOet5/xrve7I3eiQdfYFHl /lUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=414KSEQvRGVHtQkNLxaSaKDR+EpVj+byngh1Xqk6qPg=; b=rL+MTF9atD/CKLPAbp1ADmoQIHPyeZZ1voF9FJnyPw3F9VdJEO3e7G/At+TJcVrtiZ GaviyoLDEiytGO+uUVfTazpAD/u4Q4ERTXaJh4yF2F/XAOJYj2TCAG0wgYLMkK/8gR3x qFdq3J2CLX5pfARAOviiOpixynyyrwF9V5YmqTF463wj0u+Q57HhgLpbKU3oFYMYl7z4 KzpT//FDA5mOkjm0wm7RnJNYrQ02HjRG7WdemHG2KS6cVfjKYqsJnofjvA1SJImaw04e saVvNTsiFPIAYNruf/uuTkCs+SninsH5pKuwj7Yo8FK5jwNHUt0Lh8piZR3bwdD19Gab /Z7g== X-Gm-Message-State: AOAM531bEE0wMjG6FgLFnX0KOI8Z78LAgVpUwJ064l43c9Fz/I1zEuKP GobC6kweqt7uetbrfhmSIY/qHGx8KGo= X-Google-Smtp-Source: ABdhPJzju6nCHqY8Fm8j0PzvbZA69CRmHV2VVkjHmy1nTyv3xxC1GLNJ+zmt8lSwf7IV/+J/1ygRTw== X-Received: by 2002:ad4:4106:: with SMTP id i6mr4966537qvp.191.1594740840000; Tue, 14 Jul 2020 08:34:00 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id 16sm22006197qkn.106.2020.07.14.08.33.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 08:33:59 -0700 (PDT) To: hsantos@isdg.net, dmarc@ietf.org References: <5F0DB794.4070506@isdg.net> From: Dave Crocker Message-ID: Date: Tue, 14 Jul 2020 08:33:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F0DB794.4070506@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Jul 2020 15:34:03 -0000 On 7/14/2020 6:48 AM, Hector Santos wrote: > It will modify all specs related to DKIM where there is an Author > (5322.From) design requirement. It does not need to affect DKIM at all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 08:39: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 35EA83A088A for ; Tue, 14 Jul 2020 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, PP_MIME_FAKE_ASCII_TEXT=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=Pq1NRyeS; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=JOQQvTaQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKrXIlTudGkQ for ; Tue, 14 Jul 2020 08:39:38 -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 0D63D3A08CA for ; Tue, 14 Jul 2020 08:39:12 -0700 (PDT) Received: (qmail 88042 invoked by uid 100); 14 Jul 2020 15:39:10 -0000 Date: 14 Jul 2020 15:39:09 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=157df.5f0dd19e.k2007; i=news@user.iecc.com; bh=A9f6ECBSeDGQw+R2NxeS+NSj/45f+M7Jiq/V0jFo9b8=; b=Pq1NRyeSlVD6F7s2VfVAXU5U3hg1uhBVYsCqlZg9QqYoHZYwnVowJcfgthd/wk2BTVz8iUMfkHP9dDivtgqaJqTM82jFxevjtV+Olj4E4C/6PC2waGK24uQHpP4ZIsh7eHiDtPdHoh1eNEwuyfbrQ7CPYcMfo02epAC6BX/q9Y+LgUxirmKqg6tYMIIRhHuxCt9JNF5mEYnPG+XPtLxt7KifIrNs7hKEZQiB9CKWVaGOBMB7jFhIwytqH7wBFiFv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=157df.5f0dd19e.k2007; olt=news@user.iecc.com; bh=A9f6ECBSeDGQw+R2NxeS+NSj/45f+M7Jiq/V0jFo9b8=; b=JOQQvTaQZUZwanpiU9mFPbKaBCxOkh4Ty6sYoWB/ZF/TzklSCNbBTUvPqyU9M/BHXSEmUCvySncmLd6iksxp+8sFkFnYhT647Lv9nr8zNP2SDHV71oSMTrRwOpR8JAIkTXMkhflBc8+7x4m03T/KdZJjbc7ITaAIMlHIVIlFf5J5zlgexxuHHW+eQMq855MXmxcyJUmR5AIgV3CK3lBlQ8/h01+vpUjGHCipOcnZzGw2fVh6b6x3ATeAsQCkiSWk Organization: Taughannock Networks References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> In-Reply-To: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 15:39:40 -0000 In article <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com>, Dave Crocker wrote: >On 7/14/2020 2:52 AM, Alessandro Vesely wrote: >> And phishers can also send mail From: fm.bank and Sender: >> regleissei.icu.  To publish a DMARC policy would avail Farmers & >> Merchants nothing, then. > >If regleissei.icu publishes a DMARC record and indicates support for use >of Sender:, per the proposal, please explain exactly what bad things >will happen, in the case you offer. It makes the assessment process quadratically more complicated. Now the question is both whether this from regleissei.icu, but what do we know about its relationship with fm.bank. Admittedly, since a lot of MUAs display neither From nor Sender address, it's not clear how much this matters. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 14 08:55: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 665F03A08E6 for ; Tue, 14 Jul 2020 08:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 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, MALFORMED_FREEMAIL=0.116, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4rIX7Cq0Tn8 for ; Tue, 14 Jul 2020 08:55:09 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035133A091E for ; Tue, 14 Jul 2020 08:55:09 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id b185so16043779qkg.1 for ; Tue, 14 Jul 2020 08:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:cc:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=4W9D9htN3aM7Ggp9CEMnKFk6PFn69OyRonmqXliV07I=; b=MW1v3DpHkAbPKi5mqsamL59LoLYdc4WviPq0t8ZCOsDoA0r6IRvhiABkk/oJXUCgOg FS5uQHEFVyzB7M2lbLYlIrpDEJa+uvmr6tL8QS92WzVibgMGentAf1bf+LdSu4hTSEo9 2/9B9MylCxiIyhIUpqTp8KrlSYQY1tYW6a6UtwakuDD5BTWRS0OC+w2MUf66PRxtUxpW i0rVqigayymGutBRw3kWmwdMg2QbXjanlEyUtU4vZqcMJDmyFJJl9ByCRs5bnAex5pO6 VvVj11AWkfR4h2nRR4m6BsqVRm/hCU0uKuyOTNHHnNLk70FwMuU6FSXe/zBsUCiP+Che NyfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4W9D9htN3aM7Ggp9CEMnKFk6PFn69OyRonmqXliV07I=; b=MEa+kzzE/kV3MpZ1uVh4q9APwJ37WfU7mv5lNKyo7Tj8AiyyKMz+rEAi9dyfuzRIFV aO+OvvmYDHLtikzdpRMbLtbRoGkHmu1mfJM2pndbGLLbei1RdIwimlLEQRL0OMhqD/Kv CGwDbmBvJWTpEeObEbT+8kP+DhhMpczRKM/cPtb4cR7fDDoBK5VUdPukO0tTeMa5UjBF LO5WR7IkLEtKgUWXxJuXF8IMvbnYUT/6Cyl02/Q42aApHsQdKmToxZqF3sMz2IIxfkso ObUWlCyyMWahcDb31bfFIUY8jDZsBg1wrGjediO358uhnwX/ta89P+jPjF4UOvI2C2HQ 7vpA== X-Gm-Message-State: AOAM532559DnM4Dhxj82MFKXxkk0jbEl5EUhSBQn/WeZzOqn5inZIZnE fCJSYw62eNEJlKx045lJMWXYb29z8I8= X-Google-Smtp-Source: ABdhPJxkZE+WoR5e8+HJctdlFykT8BVXEWdOt7hA/BuVtLKdgCF/FLhT2/D0UPoK/w9q30JQ7hp3BA== X-Received: by 2002:a37:9147:: with SMTP id t68mr5103960qkd.34.1594742107695; Tue, 14 Jul 2020 08:55:07 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id 125sm23770946qkg.88.2020.07.14.08.55.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 08:55:07 -0700 (PDT) References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <5F0DA550.2000505@isdg.net> From: Dave Crocker Cc: dmarc@ietf.org Message-ID: <1046c85e-4ea3-0f98-9a16-818060be0061@gmail.com> Date: Tue, 14 Jul 2020 08:55:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F0DA550.2000505@isdg.net> Content-Type: multipart/alternative; boundary="------------882C6A8170C61C5897C474AC" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 15:55:10 -0000 This is a multi-part message in MIME format. --------------882C6A8170C61C5897C474AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > https://tools.ietf.org/html/rfc4870#section-3.3 Many thanks for citing DomainKeys.  I'd completely forgotten that it specified essentially the same as I am proposing: > > 3.1 . > Determining the Sending Address of an Email > > ... > > In the first instance, the most visible address is clearly theRFC > 2822 "From:" address [RFC2822 ]. Therefore, a conforming email MUST > contain a single "From:" header from which an email address with a > domain name can be extracted. > > A conforming email MAY contain a singleRFC 2822 "Sender:" header > from which an email address with a domain name can be extracted. > > If the email has a valid "From:" and a valid "Sender:" header, then > the signer MUST use the sending address in the "Sender:" header. > > If the email has a valid "From:" and no "Sender:" header, then the > signer MUST use the first sending address in the "From:" header. > > and it did not change with DKIM followed up: DKIM eliminated use of the 822.sender field. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------882C6A8170C61C5897C474AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

https://tools.ietf.org/html/rfc4870#section-3.3


Many thanks for citing DomainKeys.  I'd completely forgotten that it specified essentially the same as I am proposing:

3.1.  Determining the Sending Address of an Email
...

   In the first instance, the most visible address is clearly the RFC
   2822 "From:" address [RFC2822].  Therefore, a conforming email MUST
   contain a single "From:" header from which an email address with a
   domain name can be extracted.

   A conforming email MAY contain a single RFC 2822 "Sender:" header
   from which an email address with a domain name can be extracted.

   If the email has a valid "From:" and a valid "Sender:" header, then
   the signer MUST use the sending address in the "Sender:" header.

   If the email has a valid "From:" and no "Sender:" header, then the
   signer MUST use the first sending address in the "From:" header.



and it did not change with DKIM followed up:

DKIM eliminated use of the 822.sender field.


d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------882C6A8170C61C5897C474AC-- From nobody Tue Jul 14 09:09: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 74DF83A0962 for ; Tue, 14 Jul 2020 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 RR2-p9RN5RaK for ; Tue, 14 Jul 2020 09:09:06 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9503A095F for ; Tue, 14 Jul 2020 09:09:06 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id e13so16079619qkg.5 for ; Tue, 14 Jul 2020 09:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=/UoxHen5C3vqM3U9stXmZTtOqBgz6El+UNEMemOFo+8=; b=aKkCGWDs6pFsyhYom139IdifZMN7z33k5HfAB8woca0bkBAjoT9A4i54VBHrVZgzGy YRu7bHXCtVYEBMZ77VbZhA4q5wutMuMKUrJjPAKJN3wdqDao9OSmrYiFcrQ9dMX5H7R2 A3YZR8/Ry2RQ5fZvvT+bQmVDfuxn+cVW1ZgxJXGh7osoC/XA1j0j+s5pvFTmlBpHri3Q iegwpxQs/2FWpz2QRudcCxs/1/6R0lWsEcBjgNlufEX8BHhvZcDj8Jp5rpNXt2U4MIQX pQTq+1PQPHy97vVXKvNfwRud8n0sETqJ/wr8LQc2Z/ZQuyfX0oiznXLNhF5wIBWY88n1 mY1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/UoxHen5C3vqM3U9stXmZTtOqBgz6El+UNEMemOFo+8=; b=O6b5SpCBNoDSjOJJqJP8hRWomgtdiLP8UcWgGtSaDWQHhtQGQ3YRQso9+K8wMFjwA5 DPr2LfcJ1HYjofFlNh3Ep+XmUxHUCRJFIyoNHN2eL9SmCWW+2ovD9agi4uL4yfokLmgO W1mD2W4m+hruYf7YiakvF+WuEUr3uOoJaJx+xNF7d9+geA2jZjjBxOaflawcXGwP1CrW v0bTUoXYES/b6jHbbiY4i49aWaHZfbMPSc/MtFxCUSbSBAK8Mu+KzS+H4QY0x0rOOFj8 tQVihk2Wa2cTjdGCf+KAvUq+W/4Fu2clwC42hPTseZVNzZ5o31RNfMpyvEV2MCXb9Xc/ BuZA== X-Gm-Message-State: AOAM531lmc2/Z4LVwFZaeXAoNY4dkXrP4Z002tUp2DS4WmZ+9rYBf5rf 9hCDkP/SkFhsXTQGjUuo4Hi9lHJUevg= X-Google-Smtp-Source: ABdhPJz6fROVsQeu4WWvo/ddZfYx2Tiy5AZ9J+Uhd5fK4m0lV6I7Mf+zOmRqqtkOlhqYPOpXZ3yUkg== X-Received: by 2002:a37:6343:: with SMTP id x64mr5274233qkb.114.1594742945199; Tue, 14 Jul 2020 09:09:05 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id y16sm24556088qty.1.2020.07.14.09.09.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 09:09:04 -0700 (PDT) To: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> From: Dave Crocker Message-ID: <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> Date: Tue, 14 Jul 2020 09:09:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC 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, 14 Jul 2020 16:09:07 -0000 On 7/14/2020 8:39 AM, John Levine wrote: > In article <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com>, > Dave Crocker wrote: >> On 7/14/2020 2:52 AM, Alessandro Vesely wrote: >>> And phishers can also send mail From: fm.bank and Sender: >>> regleissei.icu.  To publish a DMARC policy would avail Farmers & >>> Merchants nothing, then. >> If regleissei.icu publishes a DMARC record and indicates support for use >> of Sender:, per the proposal, please explain exactly what bad things >> will happen, in the case you offer. > It makes the assessment process quadratically more complicated. Now > the question is both whether this from regleissei.icu, but what do we > know about its relationship with fm.bank. > > Admittedly, since a lot of MUAs display neither From nor Sender > address, it's not clear how much this matters. What is, or is not, displayed is irrelevant, since that has nothing to do with meaningful protection. Analysis by the filtering subsystem is quite another and more important matter. So I'll rephrase my question:      Please compare and contrast how analysis is done now versus how it would be done with this proposal, and what dangers are created or made worse as a result of this proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 09:41:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB483A0AD5 for ; Tue, 14 Jul 2020 09:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XrhFNHHIHuXO for ; Tue, 14 Jul 2020 09:41:28 -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 6B4013A0A5E for ; Tue, 14 Jul 2020 09:41:28 -0700 (PDT) X-ASG-Debug-ID: 1594744885-11fa313a103ab2c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id krVMRNW29lmLJsGU (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 14 Jul 2020 12:41:25 -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:subject:to:from; bh=ZOreeq3uDJ8hqDv0Z3/9yXXL81U5EGtvdQkBQmL43h8=; b=Vd487mse4TA3l4CARaF4HjbMar2NEa9/Cz2kXFTg2wAcs2G6uioy8IZS2ee9TCtfD EKHSnEn8XAPWYAs/7x9GqsfVYdNQsI9zU0j4X54zmePmqrRFEjzlDXX0MuXrZtGtx z6VCROK3h78UX/3XkyspF6ET5OT2y9CwPFVm8utBI= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 14 Jul 2020 12:41:18 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> In-Reply-To: <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> Date: Tue, 14 Jul 2020 12:41:18 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field Message-ID: <002b01d659fd$99316f00$cb944d00$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQmE/Qm2aJvLiqZFeej2LGzH13SgKjPq82Ad1GnmsBG5o9RwLNR7gXAk0KnWSoPRW9AA== Content-Language: en-us X-Exim-Id: 002b01d659fd$99316f00$cb944d00$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594744885 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: 2422 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83195 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 16:41:30 -0000 Is not the whole point of your proposal to allow the MLM to authenticate = the message based on the MLM domain signature alone, while presenting = the document as originating from another domain? That is the very behavior that DMARC is trying to prevent. But since MLM editing is so important to you and others, it would be = helpful if someone would document: - what changes need to be made by an MLM? - what objective is achieved by those changes? - why MLM editing is the best way to achieve those objectives? - what impact would occur if the MLM stopped editing and had to pursue = those objectives with other measures? We cannot adequately address a requirement that has not been defined. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Tuesday, July 14, 2020 12:09 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field On 7/14/2020 8:39 AM, John Levine wrote: > In article <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com>, > Dave Crocker wrote: >> On 7/14/2020 2:52 AM, Alessandro Vesely wrote: >>> And phishers can also send mail From: fm.bank and Sender: >>> regleissei.icu.=C3=82 To publish a DMARC policy would avail Farmers = &=20 >>> Merchants nothing, then. >> If regleissei.icu publishes a DMARC record and indicates support for=20 >> use of Sender:, per the proposal, please explain exactly what bad=20 >> things will happen, in the case you offer. > It makes the assessment process quadratically more complicated. Now=20 > the question is both whether this from regleissei.icu, but what do we=20 > know about its relationship with fm.bank. > > Admittedly, since a lot of MUAs display neither From nor Sender=20 > address, it's not clear how much this matters. What is, or is not, displayed is irrelevant, since that has nothing to = do with meaningful protection. Analysis by the filtering subsystem is quite another and more important = matter. So I'll rephrase my question: Please compare and contrast how analysis is done now versus how it = would be done with this proposal, and what dangers are created or made = worse as a result of this proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 14 10:25:14 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 8C9303A0BF0 for ; Tue, 14 Jul 2020 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 JULWT2e40k2u for ; Tue, 14 Jul 2020 10:25:11 -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 435ED3A0AD5 for ; Tue, 14 Jul 2020 10:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594747507; bh=3chYz9oC4qfrC3tQHTZKVpO8G93Bdt984HsH/Ra3ut4=; l=986; h=To:References:From:Date:In-Reply-To; b=DG0qAIhiZDo1EiBk/nTAxIWoDnqZeW8fV8eAZMhMKTWQLTwjIb0NAOujZBrGm8APa 4Pkua+oPVf1GIgFFtGW7voMCtkb0LWjZPj5LD60QWUQP7dw4UjFF+EPRMmI6utKOWB COgoZvD16nM7POwgoC5PQDSgb2GGhMlBkImp6m2muM3v3rTMh4e2upbb3fJSb 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 00000000005DC042.000000005F0DEA72.0000724F; Tue, 14 Jul 2020 19:25:06 +0200 To: Dave Crocker , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> From: Alessandro Vesely Message-ID: Date: Tue, 14 Jul 2020 19:25:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 17:25:13 -0000 On 14/07/2020 15:41, Dave Crocker wrote: > On 7/14/2020 2:52 AM, Alessandro Vesely wrote: >> And phishers can also send mail From: fm.bank and Sender: regleissei.icu.  To >> publish a DMARC policy would avail Farmers & Merchants nothing, then. > > > If regleissei.icu publishes a DMARC record and indicates support for use of > Sender:, per the proposal, please explain exactly what bad things will happen, > in the case you offer. Fm.bank, Farmers & Merchants State Bank in Archbold, Ohio, is one of the early dot-bank switchers. _dmarc.bank doesn't yet exist, but it's planned, AFAIK. Regleissei.icu was one of the many light footprint domains spammers used. A year ago it had all DMARC, SPF, DKIM and whatever records. Now it's gone. At mine, I ban the whole .ico TLD. However, life is not always easy. I can enable DMARC on all .bank, and tell users to painstakingly check From:, and if they get phished I can tell them they're morons. Best Ale -- From nobody Tue Jul 14 10:30: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 6BC433A0C00 for ; Tue, 14 Jul 2020 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 8JrBtim9GmPs for ; Tue, 14 Jul 2020 10:30:46 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 42A5B3A0BFA for ; Tue, 14 Jul 2020 10:30:46 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id u12so13394365qth.12 for ; Tue, 14 Jul 2020 10:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AS88EPPZh6WZs8jYtVBzcKit0F0Xgyw/joHzQNtC++E=; b=MTtSoRkkatYaaSxlgoXHCQmlFGyWI7QqqNaz68zA70dytaPvAT9Q7aSmBT8YF6ge9s V6xm3zBiemVtyPlw/ANK2AcrR+5sfoppTq7LQnKto+0gnggcCYVxRIE5JQPxNVapkK3p g8iIM3YnE7R/UJ97VO6/vpBOQ/3hN8u5MCFmzpWuycPZIpN2L6Sheodc5/uFlkIyGOfL nsRstsQD1elsPVnaBXDmvDMaQrTg7yJg43e43IFNY19YHu2/vsFY03I+nWpWLWNASIQ8 ZyE25gfmkfRiNwK8Lck4kQgL5I2hLsBwp8+Z5bVbxcCuKEL3Rae0AARM7TyDOwMC6xvn KIkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AS88EPPZh6WZs8jYtVBzcKit0F0Xgyw/joHzQNtC++E=; b=t8++A11wH6sV5kEo5fdLk+aG4cwbrJzcn80kr2NXHLiPvAgsIyKLPxdm7veXjgq1oK pwFqcaKXt3kSo3CWR/6mpyTZhbxoFM4LfhF6OEak2qON1zkLp5jE92y2C0Kg4txowZjC O05bN91GNofSbV/sct6WdjJZBlHuJQxwWCxWVmLE8AKj5IE/bkZYOU+i0wg4MQqvCjgo DomOL6Q7u9S0AnBZgP3uLqfeOH9jfXOVaZwVHtd9tbZ1OYHwwMoUsse8SzpJn9Yjpg2r AS+khksG4Z1897sRtw09EvFiW1Nfy+dOLUCSQPZNinQ8Da8B03mzPoNY6+SDNNxmhNzL S31g== X-Gm-Message-State: AOAM530bRbXTNDNhAxgiKjfoQurRzWFjDPgKpfcMJEdz7s4KTPWbRzsU +OXqzuXoQUB18IhvBHUV7LG6muOBbLs= X-Google-Smtp-Source: ABdhPJziVax+MRC8WsgAKOEbz/XAZzYI5LtMSywSEVRvTXWHe7utboGOHNUlHWWyz+S6ouC0a6yntw== X-Received: by 2002:aed:222e:: with SMTP id n43mr5939191qtc.123.1594747845245; Tue, 14 Jul 2020 10:30:45 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id k197sm23484407qke.133.2020.07.14.10.30.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 10:30:44 -0700 (PDT) To: Alessandro Vesely References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> Cc: dmarc@ietf.org From: Dave Crocker Message-ID: <9ac83e80-0927-99c0-1ddf-4683545cc762@gmail.com> Date: Tue, 14 Jul 2020 10:30:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------03395FE517449D1DB875A0D8" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 17:30:47 -0000 This is a multi-part message in MIME format. --------------03395FE517449D1DB875A0D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/14/2020 10:25 AM, Alessandro Vesely wrote: >> If regleissei.icu publishes a DMARC record and indicates support for >> use of Sender:, per the proposal, please explain exactly what bad >> things will happen, in the case you offer. ... > I can enable DMARC on all .bank, and tell users to painstakingly check > From:, and if they get phished I can tell them they're morons. Forgive me, but I do not understand how your note, in any way, responded to the substance of my query. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------03395FE517449D1DB875A0D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7/14/2020 10:25 AM, Alessandro Vesely wrote:
If regleissei.icu publishes a DMARC record and indicates support for use of Sender:, per the proposal, please explain exactly what bad things will happen, in the case you offer.
...
I can enable DMARC on all .bank, and tell users to painstakingly check From:, and if they get phished I can tell them they're morons.


Forgive me, but I do not understand how your note, in any way, responded to the substance of my query.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------03395FE517449D1DB875A0D8-- From nobody Tue Jul 14 10:42:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A293A0C5E for ; Tue, 14 Jul 2020 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 z--cfBMZKhSx for ; Tue, 14 Jul 2020 10:42:05 -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 F41193A0C63 for ; Tue, 14 Jul 2020 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594748523; bh=IOYlMMDgiBPB7on5SDvlbtcSWjUxFU5zwYNS3SPefQw=; l=780; h=To:Cc:References:From:Date:In-Reply-To; b=ALvR+M+l334/3l2fsgzNR8v7bfGym/oA9OuV6/bewoNq7XcVsxUZN+DZV6IMZDoj1 hc+F8nBySyWWBo7YeR+hPBzesHzVWbXtuCBaJMjo4JNKOaUgjF4gDXIH6nmgVdFF7Y weNtgNe4qul8VJ3b+OeWXOKYkkMr8E2/QYlkGyzHsdwwvILzgvTSdr5zCRUHd 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 00000000005DC042.000000005F0DEE6B.000074FD; Tue, 14 Jul 2020 19:42:03 +0200 To: Dave Crocker Cc: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <9ac83e80-0927-99c0-1ddf-4683545cc762@gmail.com> From: Alessandro Vesely Message-ID: <632b0510-b379-ac94-0924-7f6176e08b4b@tana.it> Date: Tue, 14 Jul 2020 19:42:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9ac83e80-0927-99c0-1ddf-4683545cc762@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 17:42:07 -0000 On 14/07/2020 19:30, Dave Crocker wrote: > On 7/14/2020 10:25 AM, Alessandro Vesely wrote: >>> If regleissei.icu publishes a DMARC record and indicates support for use of >>> Sender:, per the proposal, please explain exactly what bad things will >>> happen, in the case you offer. > ... >> I can enable DMARC on all .bank, and tell users to painstakingly check From:, >> and if they get phished I can tell them they're morons. > > > Forgive me, but I do not understand how your note, in any way, responded to the > substance of my query. The bad thing is that _dmarc.fm.bank looses the effect of stopping phishing attempts, as the Sender: domain would override. It keeps the ability to generate feedback about authentic messages, though. Best Ale -- From nobody Tue Jul 14 10:48:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4D3A07F7 for ; Tue, 14 Jul 2020 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 Km5Po_mXTFFN for ; Tue, 14 Jul 2020 10:48:56 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FD73A07D1 for ; Tue, 14 Jul 2020 10:48:56 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id l6so16393735qkc.6 for ; Tue, 14 Jul 2020 10:48:56 -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=0xwvMUBZ8FdCBXJ1MgztjlKiBucsAeNZEO/XE3D51Mk=; b=fY7yJgWRzV4YPMy16Vy76vxgFnLjVs/udcvkdsAMi/s90jUg8SIakIW96PTtH0l5DN PpAzzOGDTFfsDwkTPzVMyuV1oKI+jSvO40BwOxD6OWbO9MMbTexvq/5ge7rCqQyFI5iz VD4mlhmGidhdSfxznUTORZYznASWLqnwJpATqlSX9WdnrIAgBZgBRipXjnpr2qVjWx08 7U0BxkiT0HuS+yI++7cjhlX/frAJ0+4GPEOD6rJRmwPBq4Ug+zuUg5M2StxVKpHA+yfW rQqr+tAckmwePgTL3AzH43w81S0Uq2X3nyvIJSYCcTMd881ZPw16q0MRVSibKZNKVKbF Dlpw== 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=0xwvMUBZ8FdCBXJ1MgztjlKiBucsAeNZEO/XE3D51Mk=; b=j2MCcKvT8E4jbHmTyTcOuYtvOT+cEUM8J5H74b5N+iIIZ3hn0aiHZ7krcBDYec5Qhu KsiHTdvTlu6yhxOjrKKvLsTEWtSa0/MxFBwpKzAfduitmfmIDzrGPQ6u6jvLqlRzMdWB V5kGpKJxl8LDikhZrjE3i1bNwjXWpS9c5o0WBe+GehxnAW09Kug+02lxQGI40bBuqGF4 9mneCfVo30AAXPzEuOWAJ5P/5byjmJkV8PHpzPO+Q92cFG5vVhIIdMUkQNCb/gOUX265 ofzGb9h9uWkU7ro56SpAE485xzxyGWYaugiOT2Mdlwqpb0wUOb6rSICKLEb9kTpQYYCq 5Wog== X-Gm-Message-State: AOAM532qT2nB0ODEl7aHb79neKA8u5YuOCqYodDUzJREtYcTO2vZ7QsT Q1DWKnplzGJvCkFODPcQqHfVf9CBufU= X-Google-Smtp-Source: ABdhPJyExXBD/2r1CaNaLKQleWQ+3CxVDzS6qPasc3gOEaUpgY8TzW2D0YOg0rrTtx6yK8/X45vh7Q== X-Received: by 2002:a05:620a:958:: with SMTP id w24mr5846251qkw.20.1594748935563; Tue, 14 Jul 2020 10:48:55 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id g17sm22567806qto.73.2020.07.14.10.48.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 10:48:55 -0700 (PDT) To: Alessandro Vesely Cc: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <9ac83e80-0927-99c0-1ddf-4683545cc762@gmail.com> <632b0510-b379-ac94-0924-7f6176e08b4b@tana.it> From: Dave Crocker Message-ID: Date: Tue, 14 Jul 2020 10:48:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <632b0510-b379-ac94-0924-7f6176e08b4b@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 17:48:58 -0000 On 7/14/2020 10:42 AM, Alessandro Vesely wrote: > On 14/07/2020 19:30, Dave Crocker wrote: >> Forgive me, but I do not understand how your note, in any way, >> responded to the substance of my query. > The bad thing is that _dmarc.fm.bank looses the effect of stopping > phishing attempts, as the Sender: domain would override.  It keeps the > ability to generate feedback about authentic messages, though. One more time... DMARC does not stop phishing attempts. So rather than asserting a sweeping conclusion as you've offered, please explain that specific bad effects that will ensue. I'm asking for substantive, technical and operational detail. Not broad, vague conclusions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 10:56: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 7EC483A09D8 for ; Tue, 14 Jul 2020 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUebGuO6bR6c for ; Tue, 14 Jul 2020 10:56:52 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE053A0E4A for ; Tue, 14 Jul 2020 10:56:30 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:f1f8:1912:ebe:ccce]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06EHuR6j000483 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 14 Jul 2020 10:56:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594749389; bh=8Be2gFgD/jt1iOzV0RxRU1pZkgZLyZtoZKOFZHvwiOQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B2G1LdDp4qUgZsl+YDf8jOM7I6w/60f1TtcPBoySAFL3ufsdPrwprFHyxSEJXf3tR nqb5IyoJedtmaA8kUOUplEPxujZlKepxZsYqdwtMb8zNcpO8ihTqrcr2fpozKgXJeA 5CijeQ0bpEKFCb5OxWAvRV+ZVr9siUMsnVtV41Gs= To: Dave Crocker , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <38fa1a61-4ebc-066f-89e9-d540aa768086@bluepopcorn.net> Date: Tue, 14 Jul 2020 10:56:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 17:56:53 -0000 On 7/14/20 9:09 AM, Dave Crocker wrote: > On 7/14/2020 8:39 AM, John Levine wrote: >> Admittedly, since a lot of MUAs display neither From nor Sender >> address, it's not clear how much this matters. > > > What is, or is not, displayed is irrelevant, since that has nothing to > do with meaningful protection. > > Analysis by the filtering subsystem is quite another and more > important matter. Not specific to Dave's comment above, I'm really struggling to understand what problem(s) we're trying to solve. The answers I get back say something about "defending brand identity", which is a marketing, not a technical consideration. IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the technical requirements. I am NOT volunteering to do this. -Jim From nobody Tue Jul 14 11:01: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 C3BFB3A086F for ; Tue, 14 Jul 2020 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xjC21uMFeKsa for ; Tue, 14 Jul 2020 11:00:58 -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 853F63A0843 for ; Tue, 14 Jul 2020 11:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594749656; bh=xk2FFxSOhIe17lP6HGU6KXT6BfiOXGQabhe8SFeyRyM=; l=1125; h=To:References:From:Date:In-Reply-To; b=DQFI1oyYjDbRbX86db50aOJ7AcuFaKhcwRz6ZCDHboeasLkbrGqsMypO/MLnbGWv1 pHAybTlGFg/j6BMMn+pX7Vzei9R2T7CqS+dR5fD0yn7jNpfyTalwHpD0aGcnRvI0Qf w8HRl/J0LaDRHY0c4XxJE5gZ6TEI57skya0Ir/ZCM64zaqVE6/cniHvdyHiYD 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 00000000005DC042.000000005F0DF2D8.000077D0; Tue, 14 Jul 2020 20:00:56 +0200 To: Dave Crocker , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <9ac83e80-0927-99c0-1ddf-4683545cc762@gmail.com> <632b0510-b379-ac94-0924-7f6176e08b4b@tana.it> From: Alessandro Vesely Message-ID: <2b0faeee-0fbd-711b-dfce-696beeb9df54@tana.it> Date: Tue, 14 Jul 2020 20:00:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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] 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, 14 Jul 2020 18:01:01 -0000 On 14/07/2020 19:48, Dave Crocker wrote: > On 7/14/2020 10:42 AM, Alessandro Vesely wrote: >> On 14/07/2020 19:30, Dave Crocker wrote: >>> Forgive me, but I do not understand how your note, in any way, responded to >>> the substance of my query. >> The bad thing is that _dmarc.fm.bank looses the effect of stopping phishing >> attempts, as the Sender: domain would override.  It keeps the ability to >> generate feedback about authentic messages, though. > > > One more time... > > DMARC does not stop phishing attempts. Uh? DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions). One of the primary uses of this kind of spoofed mail is phishing (enticing users to provide information by pretending to be the legitimate service requesting the information). Thus, DMARC is significantly informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures. https://tools.ietf.org/html/rfc7489#section-2.4 Best Ale -- From nobody Tue Jul 14 11:41: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 6C8F83A085B for ; Tue, 14 Jul 2020 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 i-6tZD8yvZdt for ; Tue, 14 Jul 2020 11:41:43 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 513C53A0859 for ; Tue, 14 Jul 2020 11:41:43 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id d27so13638167qtg.4 for ; Tue, 14 Jul 2020 11:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GBlMKJ/O8911QfrY3gn6j1B8NuyfOxNr04tkFHW8wIg=; b=SQFzZW6a9NP9T05bb9lrP0RvBmmHAuK6vYl/O7KfB38V1rrYwqp/+m163kwK3+NyRA kTJXRugXogr+zpACQBXwzifLNYvLFxiWYTAWR4FsDta3+XtKcTcB1NJ7rl2cNL3zba/O OujR31x3exBknYhJBoSe1E83Ss9Ic77AK/OPp0F62u02vmr+ca+aU5dn1Op3Ww4ckmOy X2ioigztgvOIydu09kvT3kXqAdB92zm/+NZ30OfL7Xps6saQzLEDotmHQSvlbV/efd0K NWO5N3lRyE8jih0BN3Qw0VAFWt5zKB9+cs61Yh+SAIhUT7P6irN3eqHca/GPaNHsAEb0 4GgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GBlMKJ/O8911QfrY3gn6j1B8NuyfOxNr04tkFHW8wIg=; b=hTxqCirkmRMif2f4BIDdce50MXK9NidMNnmIAw1loH34vQYk55ylLmtm+DJ/+wphtE 4A1CtApdHIqi8IVnBRjrMHLuOhIgKiczHyrFTBkmF+8C9SLCyZRpVs2SqCdLahrqKS/q nOxY30rKhpSVnSIh7VXAsu416KDh1b2aP+lqT29MToygSviUG7sj1hkvKbu3LYydFdeC bMiTYTMkEzdPi4Rr13pUHaK+yk3JY7k0GxqoJV1UghlutrWxTz/bvoTuMB6baVo0MSpC q4dbkJkFKuKtHf1gMxXAw0kvLJD8aZWA7eeSfUe6EGrCYug8ozcRbg3S6ZONxIeyB8Qv TQ4g== X-Gm-Message-State: AOAM5300LduU+XfviebjiCo21Twx+yt9X3zTkjRBK78cKI5nV0Q+Ydee j7WQhrJQnBcHaJ1/wqEBCJdoWgQiBPg= X-Google-Smtp-Source: ABdhPJwbqEoyRrj01RRjuzKH/GI+2xF0Thuv7bZtFyO+39vYvSlScmf/h6KHSFdnZFmywaIKIC3enQ== X-Received: by 2002:ac8:2f67:: with SMTP id k36mr6093178qta.345.1594752102340; Tue, 14 Jul 2020 11:41:42 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id x19sm26257396qtc.36.2020.07.14.11.41.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 11:41:41 -0700 (PDT) To: Jim Fenton , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> <38fa1a61-4ebc-066f-89e9-d540aa768086@bluepopcorn.net> From: Dave Crocker Message-ID: <856c6245-566f-290f-92d3-ad3e2c4cc56e@gmail.com> Date: Tue, 14 Jul 2020 11:41:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <38fa1a61-4ebc-066f-89e9-d540aa768086@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 18:41:45 -0000 On 7/14/2020 10:56 AM, Jim Fenton wrote: > Not specific to Dave's comment above, Since this is a larger question and, as you note, not specific to my drafts, please post it under a separate Subject and thread, rather that confuse the focus of the current thread. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 13:18: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 3BBD23A0BE9 for ; Tue, 14 Jul 2020 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 koK2pedx5XRW for ; Tue, 14 Jul 2020 13:17:59 -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 9C7EF3A0B93 for ; Tue, 14 Jul 2020 13:17:59 -0700 (PDT) X-ASG-Debug-ID: 1594757876-11fa313a103b0a80001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id QHItvVPFxk6NFciy (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 14 Jul 2020 16:17:56 -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:subject:to:from; bh=BiXEdxVYWYmvEeQr7DKGJcYg4D92AB1LMCvxmw13jWo=; b=bhKvyHsCOKmPCvKLM3PYibIxHfU636qNcLcbDMMptJSKRYzobAtK9qr3JfobsLO3w l0y6uSmrTDT6GH96p8TLOoTXxfL8IHwaNepWKkKfTbZfT/QqjRnUUyIZfKcyRmRVo O1ZcSSl0c7ukORhyc1YWEcT85OCn3SECJCLOHNWCM= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 14 Jul 2020 16:17:47 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: "'IETF DMARC WG'" References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> In-Reply-To: Date: Tue, 14 Jul 2020 16:17:47 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field Message-ID: <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQmE/Qm2aJvLiqZFeej2LGzH13SgER7ecTAaJQjRECoz6vNqhoSNKw Content-Language: en-us X-Exim-Id: 000001d65a1b$d7980790$86c816b0$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594757876 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: 2312 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83199 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 20:18:01 -0000 This is a beautiful proposal if one assumes that domain owners will want to change. Since we do not have them well represented in this discussion, it is a conclusion that needs to be tested. I have pressed Dave on the issue of how good ML domains are to be distinguished from criminal domains, a request which has not been answered. We know that, after an edit, the only signature that can be valid is the signature of the editor's domain. The recipient domain can therefore be presented with two similar messages: - a well-formed message that is signed by the good MLM domain and purports to be on behalf of BigBank domain - a well-formed message that is signed by a criminal domain and purports to be on behalf of BigBank domain Dave apparently assumes that the recipient system can reliably assign reputation to the two messages based on the signature domain. This might be sufficient if the recipient domain had a reliable domain reputation system. As soon as one is invented, deployed, and universally trusted, we can embrace his proposal. Without another way to distinguish good MLMs from bad guys, I do not understand how rearranging headers adds anything other than obfuscation. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Joseph Brennan Sent: Monday, July 13, 2020 2:28 PM To: IETF DMARC WG Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field > > > > 2) draft-crocker-dmarc-sender > This is an elegant solution. It puts the burden of change-- creating a Sender field in all cases, and a variant DMARC record-- on the domain owner who wants to send mail and use DMARC rules. The use of Sender complies with RFC 5322, since it is optional whether to create Sender when it is the same address as From. With this implemented, developers of mailing list software can stop figuring out which way to violate RFC 5322 in order to make mail deliverable, and developers of clients do not have to create and display a new Author field. Big win, for widespread acceptance, I would say. -- Joseph Brennan Lead, Email and Systems Applications _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 14 13:23:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647473A0BF7 for ; Tue, 14 Jul 2020 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 I4uYZRxZvoIx for ; Tue, 14 Jul 2020 13:23:49 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 1B6383A0BF3 for ; Tue, 14 Jul 2020 13:23:49 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id k18so13910595qtm.10 for ; Tue, 14 Jul 2020 13:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=hhSJPwTCK8BRr3hdV2EiKKyIZU5b8IklHxZG83waAmY=; b=bjFtIabBN4cTLx3sFVDaemHX79Y4rAx2KBKHI/ix+Dg2QzCGvVywDcQS8PHwL9DnGi 5YdB6YWhK6EViBpMSZKUXZiRyZQS1MlaWIPjnhiqB2X4cKBL+12VUcgFUlB3Gr9VYy+w B0gZMq6E1O6s2Xuba/T0Gl74vkZH8TTlSDx7GOiE77O1ToYIplQr5R1Y2rK+OtgGJEIN N8xRCJ0pXYNeAVRNQCv4gc8N0uOcX6EZ0D4Z+niLxmkT5RuXDcx8v8QK2sH5XV+9HJQG PYRIviTjBYFS4EVAW2is0tARcmZyx7aMwR/nhgKeK2+eTcchGFrH4wxOBwZkjGC//jYT +aOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hhSJPwTCK8BRr3hdV2EiKKyIZU5b8IklHxZG83waAmY=; b=RP9LVI4lmRVmXmAjsgn6MuglXNJXPwd8dsO5kGlZSsQEPw5SSGCYoZfdZ/4tHM0KPW ICrST9XL2+lh+6rpv+vmmaDQZlL6ptJyp4PCePTirIMomDCR156OQ2BZFXIEBv2B6qeG UpqsXBuC7iGkhsqjUkc+9xPFzCd6KLjqgNbbE1wVLj6erRSqjMpCis2mfMvbe4OTwO9Z ja1OB708Gscs8l6Lfq1BCyJlOJuOFAdzSxElmnpB7TPmgONm953LOK7l6vXGI1U5oDJn whrLZtP0SBSiLyN3pRe83/jJHWU6ADQcKblbAoeCXqG2AQEUH+p7Cls6e/ZXwMSh12LE FoTQ== X-Gm-Message-State: AOAM532yawOdwNYEP3EbDltpU7Dj4LGhiROjm7JDUNULCvh87akn0VOl HPvxwVscy9m3AqrY5gAicLGxfOIdSuk= X-Google-Smtp-Source: ABdhPJzGiPwYeprpjvJJeJTrG5esGwda8Hym7cbCumeriCl6/N305vVxP5gUE2rbo8c3aEzjFdVTVg== X-Received: by 2002:ac8:1a2d:: with SMTP id v42mr6572136qtj.279.1594758228041; Tue, 14 Jul 2020 13:23:48 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd? ([2600:1700:a3a0:4c80:48ac:cbf7:f87a:cfdd]) by smtp.gmail.com with ESMTPSA id x29sm59924qtx.74.2020.07.14.13.23.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 13:23:47 -0700 (PDT) To: Doug Foster References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> Cc: 'IETF DMARC WG' From: Dave Crocker Message-ID: <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> Date: Tue, 14 Jul 2020 13:23:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Jul 2020 20:23:50 -0000 On 7/14/2020 1:17 PM, Doug Foster wrote: > Without another way to distinguish good MLMs from bad guys, I do not > understand how rearranging headers adds anything other than obfuscation. I'll claim that this change does not meaningful change any of the threat vectors or protections against them that are currently in place. Note, for example, that we already have mailing lists disabling DMARC protection on the From field, in a way that distorts the original information but actually also still retains it.  There do not seem to be any complaints about the handling resulting from such mail. Rather, this proposal cleans up the email human factors while retaining the intended domain name protection. d/ ps. I was really struck by being pointed to the DomainKeys RFC and re-discovering that it actually specified the use of 822.sender for exactly the use I've proposed.  I'd completely forgotten that Delaney did that. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 17:30: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 C7F513A0990 for ; Tue, 14 Jul 2020 17:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=bZocuJOf; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=McSYbYIu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR9ea3UG49B9 for ; Tue, 14 Jul 2020 17:30:09 -0700 (PDT) Received: from mail.winserver.com (unknown [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 97FCD3A098B for ; Tue, 14 Jul 2020 17:30:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1433; t=1594772997; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=pcXhnv8tEubINiV0IpO5KYX8zyg=; b=bZocuJOfMgjySQ0y5Hag0C2tN581iXRo+uEYZC1D/S+hHSoHVGsJrfsRct9gz5 R69aYY3Lc8yVU7ds2r+QpP2RaUjRa4yj2tmyZoLWkr4wIqT36hdBIfcFcNuNaQSS buKFF0nICZotoGP8plfAf/HM2Pw/SDCNJf+t9yiw9pJF0= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 20:29:57 -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 1205303394.1.7948; Tue, 14 Jul 2020 20:29:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1433; t=1594772910; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uvyMa0E o1vlqN7TOl+2TIbYF1OH7Na8rguyRniIGXrc=; b=McSYbYIuyzFO/M3GDzKPCsA v5WVpIqvbvT+4YoIqjQ8442FKwTOBECLbWsDZV5CZpHCvAeDvfEzMWURQ0SgeXsu 9hCqL/D7Uvgl1NMpNW8p5umd0CaxaGnlCdmOOXGQAJAFIquZyUnyKRqrLgWPq6BI JCsdt/QNPyrh7p0J98Bw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 14 Jul 2020 20:28:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 916085312.3.17632; Tue, 14 Jul 2020 20:28:29 -0400 Message-ID: <5F0E4E06.3080403@isdg.net> Date: Tue, 14 Jul 2020 20:29:58 -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: Jim Fenton , Dave Crocker , dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <3bdc7ad9-5a2b-1f45-7596-d75bb5d5bb36@tana.it> <83b1a66f-a2c4-4848-01f9-6de740a0c7c3@gmail.com> <4f16303d-272e-aa19-400c-d51fb6303108@gmail.com> <38fa1a61-4ebc-066f-89e9-d540aa768086@bluepopcorn.net> In-Reply-To: <38fa1a61-4ebc-066f-89e9-d540aa768086@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 00:30:12 -0000 On 7/14/2020 1:56 PM, Jim Fenton wrote: > Not specific to Dave's comment above, I'm really struggling to > understand what problem(s) we're trying to solve. The answers I get back > say something about "defending brand identity", which is a marketing, > not a technical consideration. > > IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the > technical requirements. I am NOT volunteering to do this. We will reach the same conclusions. But if we simply remove RFC5016, Section 5.3 Item 10, then things will become very interesting: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. I was totally flabbergasted when this last item #10 was added. This was the "DKIM Policy Killer" and we have not recovered. The irony now is the third party signer impugning on the 1st party policies. 1st Party Policies Matters! -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Jul 15 00:48:02 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 216C23A088C for ; Wed, 15 Jul 2020 00:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DHIyamP8Bfff for ; Wed, 15 Jul 2020 00:47:59 -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 8BF2B3A088A for ; Wed, 15 Jul 2020 00:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1594799276; bh=OkaovtBaj9xEBq6ysljd005W0vvLG9of3gGJhFqCXck=; l=1711; h=To:Cc:References:From:Date:In-Reply-To; b=AL3fTzr2wCz+8PssMqmE5gkWvZvCAKYSE9c92mZt8vGGNnOAB/IDq/VmhVTuKUfUq IrxltimepK8LBHspOnxl9+79B/5B4YqFuiU1hmht6RTBO3+6oXLngg3AOf5W8SI5Go ithN3D3IlNRkBWT18sNr1s9E/a0gskTkgWEgosOQe06/1Sn3ZF9ThCsAlSIqg 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.000000005F0EB4AC.000036B9; Wed, 15 Jul 2020 09:47:56 +0200 To: Dave Crocker , Doug Foster Cc: 'IETF DMARC WG' References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> From: Alessandro Vesely Message-ID: <7e6c0ce9-c03a-abfd-0431-f0e7477aa995@tana.it> Date: Wed, 15 Jul 2020 09:47:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 07:48:01 -0000 On 14/07/2020 22:23, Dave Crocker wrote: > On 7/14/2020 1:17 PM, Doug Foster wrote: >> Without another way to distinguish good MLMs from bad guys, I do not >> understand how rearranging headers adds anything other than obfuscation. > > > I'll claim that this change does not meaningful change any of the threat > vectors or protections against them that are currently in place. > > Note, for example, that we already have mailing lists disabling DMARC > protection on the From field, in a way that distorts the original information > but actually also still retains it.  There do not seem to be any complaints > about the handling resulting from such mail. Right. I complain about MLMs _not disabling_ DMARC protection. > Rather, this proposal cleans up the email human factors while retaining the > intended domain name protection. While it's true that header munging miseducates users, this relief is worse than the pain itself. It does not, in fact, retain domain protection. > ps. I was really struck by being pointed to the DomainKeys RFC and > re-discovering that it actually specified the use of 822.sender for exactly the > use I've proposed.  I'd completely forgotten that Delaney did that. I agree that sender signatures are more important than others. My DKIM/DMARC filter sorts them after author's signatures, but before any other 3rd party's ones. That ordering is reflected in DMARC reports. Perhaps we could formalize Sender:'s role by inventing some kind of p=some, which requires Sender: alignment. The From: domain has to remain the consumer of aggregate reports. That way it can learn which senders redistribute its mail. Best Ale -- From nobody Wed Jul 15 02:30: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 0D0D53A080A for ; Wed, 15 Jul 2020 02:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_C=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xedmfqk2i8wc for ; Wed, 15 Jul 2020 02:30:04 -0700 (PDT) Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) (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 99E5D3A0801 for ; Wed, 15 Jul 2020 02:30:04 -0700 (PDT) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jvdjm-0006HO-IG for dmarc@ietf.org; Wed, 15 Jul 2020 11:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Wed, 15 Jul 2020 11:25:40 +0200 Message-ID: <877dv5p1t7.fsf@orion.amorsen.dk> References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> <7e6c0ce9-c03a-abfd-0431-f0e7477aa995@tana.it> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:DNNHfnpQ0DWJPzUOUgCKWs39fF8= Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 09:30:06 -0000 Alessandro Vesely writes: > Perhaps we could formalize Sender:'s role by inventing some kind of > p=some, which requires Sender: alignment. The From: domain has to > remain the consumer of aggregate reports. That way it can learn which > senders redistribute its mail. This proposal seems spot on. Some domain owners believe they have a magic switch called p=reject that prevents unauthorized third parties from sending mail with From: field that has their @domain. This is not so, and mailing lists are one of the reasons why major email providers do not respect their policy. I have switched the domains I control from p=quarantine to p=none. I would use "p=sender-quarantine" or even "p=sender-reject" if it was available. At the other end of the spectrum, domains which never ever participate in mailing lists or mail forwarding need some kind of "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the policy. From nobody Wed Jul 15 02:53: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 305A83A086D for ; Wed, 15 Jul 2020 02:53: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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=4n4uexFx; dkim=pass (2048-bit key) header.d=wizmail.org header.b=rPW1/sGG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lij-dueYXEgO for ; Wed, 15 Jul 2020 02:53:34 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 59C283A086B for ; Wed, 15 Jul 2020 02:53:33 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :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:Autocrypt; bh=mSw0Ol4xPF3K1xU3p9od976cPr6Rs1sVR6SJnjjzvVA=; b=4n4uexFxPKNZOpWbKPqYDJES45 i1v+53Qls4sEQMhyEslfNnjxGrAYfcaNzIcU6DV5n5sMIOu9sra7z0pfN2BQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject: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:Autocrypt; bh=mSw0Ol4xPF3K1xU3p9od976cPr6Rs1sVR6SJnjjzvVA=; b=rPW1/sGGVyBzZm3MWpk2c+ynAx G5/aH/xh2SiqgfT3+t6BuvDb8uVBMXtaYNYMgKJ5SmOY9TRZ7omfWoJzI+5oOULQb/W+zKB4lqvGO HvsPw/FX+mCPoZrNaGKgEQwY+kUrCCMPVRyxE5iqEogeSgKLKlB0R7Tj7p66alfu+UaPlWlZHfowp 0d6gR6ALaNX5rbp1RwPqlcor/OVHSUDlpRpQYoy563sGJ/vtaEFUUOYUIqcpQTsM/ev0ZIADnYhSy 3NhqqnRDQIN1rQDTqE0Zm4OM2zlj32QZH0FzaqOl8VR5KJT7oKMuQKpGHw/+4TpBl5jF4M/A8FKho WucQGbBg==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.102) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1jve6V-00AfO4-QI for dmarc@ietf.org (return-path ); Wed, 15 Jul 2020 09:53:31 +0000 To: dmarc@ietf.org References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> <7e6c0ce9-c03a-abfd-0431-f0e7477aa995@tana.it> <877dv5p1t7.fsf@orion.amorsen.dk> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: Date: Wed, 15 Jul 2020 10:53:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <877dv5p1t7.fsf@orion.amorsen.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 09:53:36 -0000 On 15/07/2020 10:25, Benny Lyne Amorsen wrote: > At the other end of the spectrum, domains which never ever > participate in mailing lists or mail forwarding need some kind of > "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the > policy. The domain owner doesn't know. It's his users that want to sign up for, and send to, MLs. Who should be in control? -- Cheers, Jeremy From nobody Wed Jul 15 05:16: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 B7A143A0CBC for ; Wed, 15 Jul 2020 05:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_C=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80P8VNAzOKkX for ; Wed, 15 Jul 2020 05:16:41 -0700 (PDT) Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) (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 748453A0CB7 for ; Wed, 15 Jul 2020 05:16:41 -0700 (PDT) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jvgL0-0009yC-VE for dmarc@ietf.org; Wed, 15 Jul 2020 14:16:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Wed, 15 Jul 2020 14:16:33 +0200 Message-ID: <87365totwe.fsf@orion.amorsen.dk> References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> <7e6c0ce9-c03a-abfd-0431-f0e7477aa995@tana.it> <877dv5p1t7.fsf@orion.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:N4jK2zKoXWJsjxFYp1yrD40Me0Y= Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 12:16:43 -0000 Jeremy Harris writes: > On 15/07/2020 10:25, Benny Lyne Amorsen wrote: >> At the other end of the spectrum, domains which never ever >> participate in mailing lists or mail forwarding need some kind of >> "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the >> policy. > > The domain owner doesn't know. It's his users that want to sign up > for, and send to, MLs. Who should be in control? The domain owner is already (mostly) in control. They will generally have authority over the email servers, which allows e.g. blocking all mail with a mailing list header. If the users do not like that policy, they will have to vote with their feet and send mail from a different domain. I do not imagine that any of the major "free" email domains will post "p=reject-yes-I-really-mean-it" policies, so it is not a terrible hardship. I checked a few of the major free email domains, they post p=none at present. When that is the case and when they apply their own judgement to p=reject and p=quarantine, what is the actual value of current DMARC? From nobody Wed Jul 15 07:33:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA073A0BDD for ; Wed, 15 Jul 2020 07:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 aEd1r4FwCjeO for ; Wed, 15 Jul 2020 07:33:52 -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 EB54A3A0B24 for ; Wed, 15 Jul 2020 07:33:51 -0700 (PDT) X-ASG-Debug-ID: 1594823628-11fa313a103c2140001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id XaYxOxwv6pb7fqzH (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 15 Jul 2020 10:33: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:subject:to:from; bh=Fv4tcTvDOCbroieurlvc4SmO3VeA+dIA+YaXgT2BtkA=; b=LuMFD4Et2WnI5DAZ+j/xpI/+c0YBNFn58ZtiFX8HluWDnudYxwQVHGyod9bseXysQ u/0ISQ+zhh4vzJJxuIOUF0IAjpInMWZsu6SHsW8RhmcIocSE2x2tTLco5AILIt509 +RHlU9FDbJ/vVryUHaY/6KlfFWQIi4sl8YVa7xkVw= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 15 Jul 2020 10:33:41 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> <5F0C96C9.8050104@isdg.net> <23887878-4240-328a-4716-b67dd8d218db@gmail.com> <000001d65a1b$d7980790$86c816b0$@bayviewphysicians.com> <137e82d6-7766-100a-cfbe-353947a519d2@gmail.com> <7e6c0ce9-c03a-abfd-0431-f0e7477aa995@tana.it> <877dv5p1t7.fsf@orion.amorsen.dk> <87365totwe.fsf@orion.amorsen.dk> In-Reply-To: <87365totwe.fsf@orion.amorsen.dk> Date: Wed, 15 Jul 2020 10:33:41 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field Message-ID: <002d01d65ab4$efb9c270$cf2d4750$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQmE/Qm2aJvLiqZFeej2LGzH13SgER7ecTAaJQjRECoz6vNgGt1YlDAR4DcSsAtrrWHwIqLe95AWnWhZkC4wiCb6gZr5gg Content-Language: en-us X-Exim-Id: 002d01d65ab4$efb9c270$cf2d4750$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1594823628 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: 1738 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83217 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] 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: Wed, 15 Jul 2020 14:33:54 -0000 Gmail specifies quarantine. Verizon.com, aol.com, and yahoo.com (common ownership) specify reject, reject, and quarantine respectively. Microsoft (live and Hotmail) specify none. Embarqmail specifies none. Which services did you check? -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Benny Lyne Amorsen Sent: Wednesday, July 15, 2020 8:17 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field Jeremy Harris writes: > On 15/07/2020 10:25, Benny Lyne Amorsen wrote: >> At the other end of the spectrum, domains which never ever >> participate in mailing lists or mail forwarding need some kind of >> "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the >> policy. > > The domain owner doesn't know. It's his users that want to sign up > for, and send to, MLs. Who should be in control? The domain owner is already (mostly) in control. They will generally have authority over the email servers, which allows e.g. blocking all mail with a mailing list header. If the users do not like that policy, they will have to vote with their feet and send mail from a different domain. I do not imagine that any of the major "free" email domains will post "p=reject-yes-I-really-mean-it" policies, so it is not a terrible hardship. I checked a few of the major free email domains, they post p=none at present. When that is the case and when they apply their own judgement to p=reject and p=quarantine, what is the actual value of current DMARC? _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Jul 15 07:46: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 60F463A0C11 for ; Wed, 15 Jul 2020 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=pKoUQhD7; dkim=pass (1536-bit key) header.d=taugh.com header.b=ohljQhsq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6gF1fpXhveJ for ; Wed, 15 Jul 2020 07:46:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7759A3A0746 for ; Wed, 15 Jul 2020 07:46:28 -0700 (PDT) Received: (qmail 99788 invoked from network); 15 Jul 2020 14:46:25 -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=185c9.5f0f16c1.k2007; bh=ZmY3+xczQkPSfkS9pT6p2kO9Q6Uum1XBGWUkJ4ZV95I=; b=pKoUQhD7+UB6ubv+2d5j62zWjDvHt2Z1J273h8/WcHAv4rfW96tQ1hUXPXmZ7g1UdO2dyz9hAzavJuuJGK6RC3P+A3aov0lWJayTrWZ6ff9JppmNxrPz7rtxZHIywc4wSixiQKXym6oTMOUKfjAPf1hgsuc7j17Y3shDrU7Xhr1NVNTMiL6Y+7QMxleJ8bZpOMbMyrbfPG6GZMWrzmK9Jn39EPVnKJThqANEAkNYmeahJ+f52OICzU5d9BnoGq3Q 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=185c9.5f0f16c1.k2007; bh=ZmY3+xczQkPSfkS9pT6p2kO9Q6Uum1XBGWUkJ4ZV95I=; b=ohljQhsqH95Ny7+FOVqwmlbeQwXurEEdT3wVdwUmxoFscXf4FSXEAgU6RUFSmwBHPAXh0YVnten2JmtBKE6JIlpERoDdPpPxN/nx99ZddFcgQtEj47jKnXp50Ond2CnKUJT/McK8wgyEV1H1AJqqTpVzme5d/Ag5CkTroy9UNDuBiz19RTK29kf0p+x0zkXWOnkVfhgz65fzAmUby4KiK6315DZRf8CIKuBybR3K5ZnbBfGL4ebF3pPbP+YN5TIG Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Jul 2020 14:46:25 -0000 Received: by ary.qy (Postfix, from userid 501) id 09EFB1CE2440; Wed, 15 Jul 2020 10:46:25 -0400 (EDT) Date: 15 Jul 2020 10:46:25 -0400 Message-Id: <20200715144625.09EFB1CE2440@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <002d01d65ab4$efb9c270$cf2d4750$@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC 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: Wed, 15 Jul 2020 14:46:33 -0000 In article <002d01d65ab4$efb9c270$cf2d4750$@bayviewphysicians.com> you write: >Gmail specifies quarantine. No. sp= is not the same as p= $ host -t txt _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" >Verizon.com, aol.com, and yahoo.com (common ownership) specify reject, >reject, and quarantine respectively. No: $ host -t txt _dmarc.verizon.com _dmarc.verizon.com descriptive text "v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:dmarc_afrf@auth.returnpath.net; rf=afrf; pct=100" $ host -t txt _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;" AOL and Yahoo both published p=reject after they had large security breaches that let crooks steal their users' address books, and then started sending spam to their users with return addresses of the recipients' friends, leading to many complains and support calls. They use DMARC to outsource the cost of their security failures to unwilling mail admins all over the world. Verizon.net has p=reject while verizon.com has p=quarantine. The former is for their ISP customers, with mail hosted by Yahoo. The latter is their corporate with mail handled by Proofpoint. R's, John From nobody Wed Jul 15 17:14: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 1C43A3A0C2F for ; Wed, 15 Jul 2020 17:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjMMRU30dz0K for ; Wed, 15 Jul 2020 17:14:52 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0CD3A08C1 for ; Wed, 15 Jul 2020 17:14:52 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:ac3c:eb64:30aa:9764]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06G0EoUq003288 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 15 Jul 2020 17:14:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1594858492; bh=9X8oFgpVFiILsESf3PtYTinLHL7sBv8JqTgHP+OuqrY=; h=To:From:Subject:Date:From; b=L7rvrqisDL0jNEQHWGU9imANaOC/RYGQA0+hXU7QpDsG1PiI4Mygna2euGm7GidR1 mk4GivXdrDsupPnbOJx68NZJteZO1spUNG8eYbdmCPPthGLcm+pczKMvB/XoIfbcG9 SYL8xQZ5s7sBHuJEqdMeAPrEq0GxMZfOuk3ka+UY= To: "dmarc@ietf.org" From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Wed, 15 Jul 2020 17:14:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 00:14:54 -0000 Unburying this from a different thread. I'm really struggling to understand what problem(s) DMARC is trying to solve. The most common answer I have heard says something about "defending brand identity", which is a marketing, not a technical consideration. IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the technical requirements. I am NOT volunteering to do this. -Jim From nobody Wed Jul 15 18:31:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494493A0861 for ; Wed, 15 Jul 2020 18:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zZcvRFrm7eFO for ; Wed, 15 Jul 2020 18:31:33 -0700 (PDT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 5B0373A085B for ; Wed, 15 Jul 2020 18:31:33 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id j18so7958750wmi.3 for ; Wed, 15 Jul 2020 18:31:33 -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=lvT5aIwigSxOel6Ji0smcMs5CwRYUTj3c6emA6OVKNI=; b=CoNzkwb5c0o2x+AoyOz5RrE3XztEUi+cdTSi0UQM6VSAJkq9julJfj/pPLj8x9eNsQ GuY5fcuu+31EosdDq10tkrifDhZpqGnozD/T6Ms6ewxoTKMh4cmpzR0GZfq3y0b3L67O iPFjHiyl9iz0DPoBuQTMlurLkn7u7lU7ClfznFBkU5Tcx0mK33jA0ULt40h5puM8c5xg rGGD3TGV+arPftnvr6OehRpphBGtyESgDdiVcbiQ46U9uNYOX3jUWaivYZnDPAzJLSnY 3BO5KE1aAoHKi+62VeTAg3Iygej8MwQgiQrk0RLmD0CfM2HKLHanJSWhMfwvl73BhEQG B+dQ== 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=lvT5aIwigSxOel6Ji0smcMs5CwRYUTj3c6emA6OVKNI=; b=AqwWReapyGosNmBCLW+ReJ5gL50xhMD3h+8eFs5TgEfRn+OYG4LrbL9Krkaw2pipKB oH2iKFrZNr+n1BMqjRDQgJRL4jDGKO0atfJKgYStXVU0oQl0Ct+8xWweGnYkgg3uAe7B XPbB9sQnxYpSyhZXZyyyQ3KyTvB72CTctY8JEySqRVtbfg1nkPsyx1NsNOd9v6I4HJWL KxlgTJwacB1pwGaPudn1m1VpQaVTzhE3FyhIiRvLPmrEJIwRO685lPuvShjzBNV8F0uv XRE4trVE/tTNMZA8wxTQ5rKt/o/Tzc9lkJqmTd8YSevUPUNDLiSCuNP6z+MT7MdevNnO OzAg== X-Gm-Message-State: AOAM532kRkczEqf5WW4YvQG2tvJ8d+wQLXP8OlLSDR8AJl++ra1/2RVa PXztpXFPW2o1nneRPAtqZI39P5IGeRcd07xpTRNilQ== X-Google-Smtp-Source: ABdhPJxAJQ76JIG64M3tZVtdlBefJMsUjhNRqwBkOeVYxONCz2iIghYWZG7c8VN8pZZ42LZWGrmi6gVzm8fyhZWDnlE= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr2049856wml.36.1594863091733; Wed, 15 Jul 2020 18:31:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Wed, 15 Jul 2020 21:31:19 -0400 Message-ID: To: Jim Fenton Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000c579505aa850002" Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 01:31:35 -0000 --0000000000000c579505aa850002 Content-Type: text/plain; charset="UTF-8" As part of the original DMARC team and having worked with anti-abuse for a long time at scale for a large set of websites, I can speak to my motivation. It's not really about defending brand identity. The data shows (although it is not mine to share) that end users will click on anything based on the right social engineering. Love, money, etc. are powerful motivators. The first thing that DMARC enables is for a brand/domain to signal to validators/receivers that the domain has control of it's mail streams and is identifying those mail streams using the combination of SPF/DKIM/DMARC. This enables receivers to process those mail streams with a certain amount of confidence. This leaves open the question of when good domains go bad but that falls into the realm of local policy on th part of the receiver. I think anyone who makes an assertion about "DMARC policy" needs.to remember that at best it is a request to validators/receivers. Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there as reasons why DMARC is "irrelevant" to solving problems such as spam or phishing. It doesn't solve spam but it does have an impact on phishing, if only to push the bad guys to "push reality". If I get a phishing email from a bank that is not my own, I as an end user am less likely to fall for that particular phishing scheme. It makes it easier for validators/receivers to differentiate real from Memorex. It's also important to recognize that the environment isn't static. The bad guys are always thinking up new approaches as the old/currnt ones yield declining results. This evolving context is sometimes brandished against DMARC as an indicator that it isn't useful. My experience with a number of brands/domains that were aggressive in implementing SPF/DKIM/DMARC as well as other measures, we were able to drive down abuse against those brands/domains by over 95%. Did the bad guys continue to test both external abuse as well as probe for weaknesses that would enable abuse through the systems? Absolutely. Did they move on to other brands/domains to abuse? Absolutely. When Jim asks the question "What problem are we trying to solve?", perhaps the prior question should be "Who are we?". Michael Hammer On Wed, Jul 15, 2020 at 8:15 PM Jim Fenton wrote: > Unburying this from a different thread. > > I'm really struggling to understand what problem(s) DMARC is trying to > solve. The most common answer I have heard says something about > "defending brand identity", which is a marketing, not a technical > consideration. > > IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the > technical requirements. I am NOT volunteering to do this. > > -Jim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000000c579505aa850002 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As part of the original DMARC team and having worked with = anti-abuse for a long time at scale for a large set of websites, I can spea= k to my motivation. It's not really about defending brand identity. The= data shows (although it is not mine to share) that end users=C2=A0will cli= ck on anything based on the right social engineering. Love, money, etc. are= powerful motivators. The first thing that DMARC enables is for a brand/dom= ain to signal to validators/receivers that the domain has control of it'= ;s mail streams and is identifying those mail streams using the combination= of SPF/DKIM/DMARC. This enables receivers to process those mail streams wi= th a certain amount of confidence. This leaves open the question of when go= od domains go bad but that falls into the realm of local policy on th part= =C2=A0of the receiver. I think anyone who=C2=A0makes=C2=A0an assertion abou= t "DMARC policy" needs.to remembe= r that at best it is a request to validators/receivers.

= =C2=A0Yes, the issues of cousin domains, homoglyphs, etc. are thrown out th= ere as reasons why DMARC is "irrelevant" to solving problems such= as spam or phishing. It doesn't solve spam but it does have an impact = on phishing, if only to push the bad guys to "push reality". If I= get a phishing email from a bank that is not my own, I as an=C2=A0end user= am less likely to fall for that particular phishing scheme. It makes=C2=A0= it easier for validators/receivers=C2=A0to=C2=A0 differentiate real from Me= morex. It's also important to recognize that the environment isn't = static. The bad guys are always thinking up new approaches as the old/currn= t=C2=A0ones yield declining results. This evolving context is sometimes bra= ndished against DMARC as an indicator that it isn't useful.=C2=A0
=

My experience with a number of brands/domains that were= aggressive in implementing SPF/DKIM/DMARC as well as other measures, we we= re able to drive down abuse against those brands/domains by over 95%. Did t= he bad guys continue to test both external abuse as well as probe for weakn= esses that would enable abuse through the systems? Absolutely. Did they mov= e on to other brands/domains to abuse? Absolutely.

When Jim asks the= question "What problem are we trying to solve?", perhaps the pri= or question should be "Who are we?".=C2=A0

Michael Hammer<= /div>

On Wed, Jul 15, 2020 at 8:15 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
Unburying this from a different th= read.

I'm really struggling to understand what problem(s) DMARC is trying to<= br> solve. The most common answer I have heard says something about
"defending brand identity", which is a marketing, not a technical=
consideration.

IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the
technical requirements. I am NOT volunteering to do this.

-Jim

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000000c579505aa850002-- From nobody Thu Jul 16 12:26:44 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 83FAC3A0BC7; Thu, 16 Jul 2020 12:26:18 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159492757852.14301.51281259493882178@ietfa.amsl.com> Date: Thu, 16 Jul 2020 12:26:18 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 19:26:19 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (0:50 requested) Tuesday, 28 July 2020, Session II 1300-1350 Room Name: Room 1 size: 1 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/dmarc.ics Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: None Conflicts to Avoid: Chair Conflict: dnsop dprive extra jmap cbor cfrg kitten Technology Overlap: saag uta People who must be present: Alexey Melnikov Murray Kucherawy Tim Wicinski Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jul 17 09:02:02 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 DAE0B3A07F5 for ; Fri, 17 Jul 2020 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=At3s4SsH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=hbwmh1pb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dpoFqcIOGS1 for ; Fri, 17 Jul 2020 09:01:58 -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 8D17D3A07EE for ; Fri, 17 Jul 2020 09:01:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1845; t=1595001707; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=fzepwMQO9RIaQJT+PZND3JcbM9U=; b=At3s4SsH5Ve00aJd009TwGO2pA+MogJk0A6W4rEJZdVIqQUEmX8FuTW5FciBzF bqb+Jp2nlBqtD6SgGCR91Im6UH/JoMVD/Zs+Pb8EDmrg9rOW5Ofd3eF71Y+mmTp3 QO3jJu7xQm98iQ7hntz58vd8aXPpCnTj+Yjprb87bYwqU= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 17 Jul 2020 12:01:47 -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 1434010578.8424.4588; Fri, 17 Jul 2020 12:01:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1845; t=1595001612; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4Jw10gh DZ9Quw+ZV6UzSf/HCzUflwVJwXJuRaObyVuY=; b=hbwmh1pbHKfU8ZR4ctnH6un UOsW0wlBrBo6Hw8sPNpwWH6Mb8EBgO/RNdkWPEQupEIHV+aUCuH+uRuvjEUKdKOO KtXa5sG6ycVJq3xyeV4WKl+Z4lzreel4zORcD5mCOVaX6d7GTTTOvApGmbh0t9qM nFUgZzm0BVYjioi8amWk= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 17 Jul 2020 12:00:12 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1144787265.3.24088; Fri, 17 Jul 2020 12:00:11 -0400 Message-ID: <5F11CB6C.3050101@isdg.net> Date: Fri, 17 Jul 2020 12:01:48 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Jul 2020 16:02:01 -0000 On 7/15/2020 8:14 PM, Jim Fenton wrote: > Unburying this from a different thread. > > I'm really struggling to understand what problem(s) DMARC is trying to > solve. The most common answer I have heard says something about > "defending brand identity", which is a marketing, not a technical > consideration. > > IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the > technical requirements. I am NOT volunteering to do this. Jim, if we review both RFC4686 and RC5016, I believe we might find there is not much to be changed. However, imo, something will have to be done regarding RFC5016 section 5.3 item: https://tools.ietf.org/html/rfc5016#section-5.3 5.3. Practice and Expectation Requirements 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. This provision with strict protocol language "MUST NOT" prohibits any DKIM Policy protocol, formally called SSP "Sender Signing Practices" and now today, DMARC, from impugning on 3rd party policies such as how a MLM operator via local policy exceptions can ignorantly and blinding destroy the integrity and resign the mail instead of just honoring it. This language would have be updated or removed and just leave the implicit idea that local policy always prevails in all SMTP situations. Have a good weekend, be safe. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jul 17 11:30: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 491D43A0A38 for ; Fri, 17 Jul 2020 11:30:55 -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 jx2ZtA5Y5jtA for ; Fri, 17 Jul 2020 11:30:54 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0029E3A0A21 for ; Fri, 17 Jul 2020 11:30:53 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id k6so8156625ili.6 for ; Fri, 17 Jul 2020 11:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=E0cnsdsGVaGkaRULdXyoqIpnOI1/NAL0yltli6m81Bc=; b=XQRWynvIWpkzelxlrrRE/m0J8FGHxRqityW80IJf3/L8++1oYEv/f/WzTOT2+wbRzw RrXFFAQowvtvQxoEkBF2UtM9YdajW9eJBorE9wrS7FZqXlzmOx4la9gsxiYgWh+8HR0W gYLVp2+6HRZvOF9UfRg8Mt99rYoNW+3mH0rnM= 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=E0cnsdsGVaGkaRULdXyoqIpnOI1/NAL0yltli6m81Bc=; b=qSgysApy4NqlJ+uQOmw7sjV+TLVvhdwdbJkZKZ0wqP2/WIQRkW4zmevUYAkBnButdB pmaZZm34Ntaw/8tOD5hj4uPHX6gfWsUrbG+DHPZkMcBouvnhjSL+cWkLqge+SZu2kMIO JdEKABM2BRHngWMdhNqHHl04OSGcW7GBTVpiJqjq4jHYndTy+m0iloBGBEX9wATJ9qkM LMll+7Zm2hWA+yq3CfplGaT+od8OFnHEwUgxsQ2U6rBSU+wXGxJ/37EtPhNcE2oiL6OQ 80q7SKsvvabxxaQ587/I4EgODwNyZiEbkr3LPrHISI9+0IqCLrAR2as+pRhu7tdmmhgt XGCw== X-Gm-Message-State: AOAM5318PkteNTsRftXwXHnjiJswtFoQZ7ZIZeYn2Ny8++XgGUX8B/fI +CSEE0kR2g6y2fwSuvVJbuqDgwKOwZzLgABx8QW7V2kBVyc= X-Google-Smtp-Source: ABdhPJzbRAXYVQS/XoJrUm8qVtsqDnfJR7IssIWA49BrNVCCnVd6BMFn7J2q/DDuUdRBfNr67NgfkZV2g8ZGByH9z8s= X-Received: by 2002:a05:6e02:1082:: with SMTP id r2mr11430502ilj.263.1595010652227; Fri, 17 Jul 2020 11:30:52 -0700 (PDT) MIME-Version: 1.0 From: "Kurt Andersen (IETF)" Date: Fri, 17 Jul 2020 11:30:39 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000056e0d805aaa75bb8" Archived-At: Subject: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Jul 2020 18:30:55 -0000 --00000000000056e0d805aaa75bb8 Content-Type: text/plain; charset="UTF-8" Dave writes: However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user. I'd counter by personal anecdote that we have had to undertake security remediations because of messages which were forwarded by our CEO to other employees for responses which happened to contain malware and/or bad links. Presumably, the cachet which was carried along with "important person says look into this" overcame whatever native caution or skepticism might have prevented them from falling prey otherwise. --Kurt --00000000000056e0d805aaa75bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave writes:
However, for all of the real and serious demonstration of users'=
 being tricked by deceptive or false content in a message, there is no evid=
ence that problematic content in a field providing information about messag=
e's author directly contributes to differential and problematic behavio=
r by the end user.
I'd counter by personal anecdote t= hat we have had to undertake security remediations because of messages whic= h were forwarded by our CEO to other employees for responses which happened= to contain malware and/or bad links. Presumably, the cachet which was carr= ied along with "important person says look into this" overcame wh= atever native caution or skepticism might have prevented them from falling = prey otherwise.

--Kurt
--00000000000056e0d805aaa75bb8-- From nobody Fri Jul 17 11:35:17 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 C3B5C3A0A3C for ; Fri, 17 Jul 2020 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 0r4b-aKOlhTR for ; Fri, 17 Jul 2020 11:35:13 -0700 (PDT) Received: from mail-oo1-xc43.google.com (mail-oo1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (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 79B073A0816 for ; Fri, 17 Jul 2020 11:35:13 -0700 (PDT) Received: by mail-oo1-xc43.google.com with SMTP id z23so2020262ood.8 for ; Fri, 17 Jul 2020 11:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=1YgxPSmvh54eylcglrcWcGtSmhWy/mr5lho7fZqYFdc=; b=AKgimeMr7MejfYBtlrto6sIE5J+FSLLUTMtR2ANKF5s+Qfzl9sVisu+rW230jIA6bD OSIdrx0w1Ay6zYAwopspfwgE1ak2QFYB7CUpKPqg+1zdKVznV+5zdSVf2aNi2ZdJJl66 31AquzV6vSejwkRGIbZqTbi/80SJjm/AVpW2JWdmdAzlI4JeGrkE5b2VdaXWW4gmfBAf X6uBsMj6y/Bmepv0+ld1RXtwVnxswyZnMfjsCRqHW6kyG9XRueXABNGcZmBLBxWJU66B sUU5bcQlvAgrHvpzhbeXxcrjtm8iIaX4g5WEG2vin8iLI+dVZwLLbmwM+ijs2PH+Yeqx mQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=1YgxPSmvh54eylcglrcWcGtSmhWy/mr5lho7fZqYFdc=; b=gexcNTeU90hZ8t+wqQgOfyG0QVzm4euOjkVwlmdjT8E6b4lj9N3tjA+MlaE3qoby82 hWy4BRJPVcKIbPjs1vcqlwyd8hWxbpgx4r2JPeLwDfJs3YQSJYs0KUfpOoJqqBSjnghx 88OVIfsW6rzkVk2Ec8aSGtOkPTWvhmPpl0TcFnQtPqXCPoVvlsCa+NEHYrjQ4FdqQFtO l92+UXrSsKASX5+63Uc3hyCNQjcTa7UgE1ZQ0c2P3Ibk3KKcpzGzDVaEngiIfxthdgz6 ojMP13KE/fywQ9+SVM2oHGBA6I2gaR40MRwCdzUIEdt3sY2bcBcZirXU0iBMvmhIEjd6 Y7Lg== X-Gm-Message-State: AOAM531YJiRjovg1SR0lVNznt69iSPF9Q9FpX9xXcngzv1AbWd2Yb109 jDCcMXhTWBfzj7JByedC3llP5NynZto= X-Google-Smtp-Source: ABdhPJxgfqTzyVeGV9xzuvsDemiWV0H1A00GRAy1urW/uNLVz7qunCEyk2ZjoJlqfFiUw7rMnNa3Vg== X-Received: by 2002:a4a:b006:: with SMTP id f6mr9763708oon.13.1595010912483; Fri, 17 Jul 2020 11:35:12 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:39b9:ee99:c817:8bd8? ([2600:1700:a3a0:4c80:39b9:ee99:c817:8bd8]) by smtp.gmail.com with ESMTPSA id 108sm2056812oth.48.2020.07.17.11.35.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 11:35:12 -0700 (PDT) To: "Kurt Andersen (IETF)" , "dmarc@ietf.org" References: From: Dave Crocker Message-ID: Date: Fri, 17 Jul 2020 11:35:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C30B88A34651FFCCC025982B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Jul 2020 18:35:15 -0000 This is a multi-part message in MIME format. --------------C30B88A34651FFCCC025982B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/17/2020 11:30 AM, Kurt Andersen (IETF) wrote: > Dave writes: > > However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user. > > I'd counter by personal anecdote that we have had to undertake > security remediations because of messages which were forwarded by our > CEO to other employees for responses which happened to contain malware > and/or bad links. Presumably, the cachet which was carried along with > "important person says look into this" overcame whatever native > caution or skepticism might have prevented them from falling prey > otherwise. Except that the problem isn't the email address, especially since almost no one sees those any more.  And the display name isn't protected. I'm not quite motivated enough, or I'd have had this message contain:    Kurt Anderson and it would have passed the necessary tests... In other words, when we talk about threats and we talk about mitigations, we need to be careful that they align properly. (I suspect there's some irony in my choosing 'align' but it was not intentional, though I'll take the extra point for noting it.) -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------C30B88A34651FFCCC025982B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/17/2020 11:30 AM, Kurt Andersen (IETF) wrote:
Dave writes:
However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user.
I'd counter by personal anecdote that we have had to undertake security remediations because of messages which were forwarded by our CEO to other employees for responses which happened to contain malware and/or bad links. Presumably, the cachet which was carried along with "important person says look into this" overcame whatever native caution or skepticism might have prevented them from falling prey otherwise.


Except that the problem isn't the email address, especially since almost no one sees those any more.  And the display name isn't protected.

I'm not quite motivated enough, or I'd have had this message contain:

   Kurt Anderson <dcrocker@gmail>

and it would have passed the necessary tests...

In other words, when we talk about threats and we talk about mitigations, we need to be careful that they align properly.

(I suspect there's some irony in my choosing 'align' but it was not intentional, though I'll take the extra point for noting it.) 

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------C30B88A34651FFCCC025982B-- From nobody Fri Jul 17 11:57: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 F06763A0062 for ; Fri, 17 Jul 2020 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 qqf_sBn69dfN for ; Fri, 17 Jul 2020 11:57:35 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D2D3A0061 for ; Fri, 17 Jul 2020 11:57:35 -0700 (PDT) X-ASG-Debug-ID: 1595012253-11fa313a103fb0c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id eFg3E5Jns5LOCMS8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 17 Jul 2020 14:57:33 -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:subject:to:from; bh=scQKeBPeCg4PeYiS+zpD4wa53yk/h02Q5M/EeVGr5Nc=; b=B1MQiZvJJ3FmSV7Ea426We26kGCHMsWLPlyF4UMwn2huv1+m6c8Nqw8B/lr8OrTjv KzfkVivKlqdDeYlgmwhUnEQvFtnKqvKoJNLAtCS9ff2WjA+CMlD0UfJ91Fxa4Dknj itwXT2DwLmw1WqO+sHy9mxpqLxQyuaXEF0tI3Q79Q= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Fri, 17 Jul 2020 14:57:26 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: References: <5F11CB6C.3050101@isdg.net> In-Reply-To: <5F11CB6C.3050101@isdg.net> Date: Fri, 17 Jul 2020 14:57:25 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] DMARC threat analysis needed Message-ID: <003001d65c6c$1c5f2870$551d7950$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC3u6y5BaD8VeOrNq3nQJhb0ovUHwIETSi1qzk0iOA= Content-Language: en-us X-Exim-Id: 003001d65c6c$1c5f2870$551d7950$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595012253 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: 5152 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Jul 2020 18:57:37 -0000 Hector, I think I am reading RFC 5016 section 5.3 differently from you. My paraphrase: This SSP assertion is allowed: "Example.com says: Example.com messages can be considered authorized if and only if they have a signature from our domain." This SSP assertion is not allowed: "Example.com says: Example.com messages can be considered authorized if and only if they have a signature from our domain, and DO NOT have a signature from OtherGuy.com domain" The second assertion is not allowed because Example.com should not be "impugning" the validity of a signature from OtherGuy.com. Example.com is not empowered to be a reputation service for unrelated entities. However, the language of this section directly supports the DMARC implementation. To solve the MLM problem, you need to explain how MLMs become authorized by the author domain to send on behalf of the author, without authorizing spammers to send on behalf of the author. It seems that we have an architectural problem because the current infrastructure assumes a single author. In reality, we have multiple situations that involve multiple authors. For example, this message includes your entire note, and your note includes part of Jim's note. But those notes no longer have valid digital signatures, so there is no proof that I have represented you correctly, and it is technically possible for me to rewrite your comments entirely. A similar problem occurs if my spam filter adds content to a message as it arrives into my domain, content that is really intended for "internal use only". The additions will break incoming signatures, although this is tolerable because signatures are not checked again, as long as the message remains internal. But if a message is auto-forwarded to another domain, the additions are probably inappropriate and the message no longer passes Sender Authentication. I would like to be able to preserve the original signature throughout, and remove the internal spam filter content when the message leaves the internal domain. Consequently, I am dreaming about an architecture that allows mediators to add content under their own signature without voiding the signature of other sections. The concept is a combination of John's ARC project, which uses nested signatures , and Murray's tagged content, which acts as a change log. It would allow an MUA to clearly identify the content contributed by the different authors, and it would contribute to solving the MLM problem. It is easier to imagine how it could be used to identify additions, such as a message footer, then to identify alternations, such as a URL rewrite. And the whole thing may be too complicated to implement in a way that is upward compatible with the present architecture. But it would be a better model of reality. Doug Foster -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Friday, July 17, 2020 12:02 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC threat analysis needed On 7/15/2020 8:14 PM, Jim Fenton wrote: > Unburying this from a different thread. > > I'm really struggling to understand what problem(s) DMARC is trying to > solve. The most common answer I have heard says something about > "defending brand identity", which is a marketing, not a technical > consideration. > > IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the > technical requirements. I am NOT volunteering to do this. Jim, if we review both RFC4686 and RC5016, I believe we might find there is not much to be changed. However, imo, something will have to be done regarding RFC5016 section 5.3 item: https://tools.ietf.org/html/rfc5016#section-5.3 5.3. Practice and Expectation Requirements 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. This provision with strict protocol language "MUST NOT" prohibits any DKIM Policy protocol, formally called SSP "Sender Signing Practices" and now today, DMARC, from impugning on 3rd party policies such as how a MLM operator via local policy exceptions can ignorantly and blinding destroy the integrity and resign the mail instead of just honoring it. This language would have be updated or removed and just leave the implicit idea that local policy always prevails in all SMTP situations. Have a good weekend, be safe. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jul 17 14:00:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938803A00C9 for ; Fri, 17 Jul 2020 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IHKCpiaI; dkim=pass (1536-bit key) header.d=taugh.com header.b=YlWeS3L6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v89mI9MpMO-U for ; Fri, 17 Jul 2020 14:00:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A593A00C4 for ; Fri, 17 Jul 2020 14:00:55 -0700 (PDT) Received: (qmail 92961 invoked from network); 17 Jul 2020 21:00:54 -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=16b13.5f121186.k2007; bh=zWGcGquWywpQ4/o9MBcCiHUYFAJ4x4GTmIvGCLN9ew8=; b=IHKCpiaImcJ+ThdeGF7MTQisJcPzQ9nRmOMuv0zptKoQjbNBm6Zk7rzOQcStT7ipeR9Oy6zz2fTuOVSTvxQx20WC4NiDvDX0H5kug7uH8l9KDq0uG7+sWRAHLrsG0O9E/yX4N7W34oH2UZfPZHuNWlOCwMRjv3eG7p5Kc6orgxhX7wV1tEZUJU1DTt+kGe7JoNp6kqMFxu5E2HjT5QFmQr1k184UW4kVH81bZ0l5MLV2djSaZdDJs/t4wNSovBpu 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=16b13.5f121186.k2007; bh=zWGcGquWywpQ4/o9MBcCiHUYFAJ4x4GTmIvGCLN9ew8=; b=YlWeS3L63bFyRHyTGRSW1HWe8Y22NDLpoUKWDyl8Tu3NSm8SjuTvghpAVWUDnvWYNulHu/UeJPuaUJuiDJOp7FaHYUwc/nP3imFPWNOnq5Nkiaw0VnHPhVMt+Uz96BhFs0WVJU1rf/rIa4p+9tmH+WB1EJdbpFrjU+WKJHFJVDd/898tV9WbxIt+f5qQYbqvQ5ud5Td/iy9CQuNEBcmkplp59MJBe/zL9CT7nMQF/cmUOVTvRR9znWHtGyjWq3Yf Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Jul 2020 21:00:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 674D61D2C431; Fri, 17 Jul 2020 17:00:53 -0400 (EDT) Date: 17 Jul 2020 17:00:53 -0400 Message-Id: <20200717210053.674D61D2C431@ary.qy> From: "Dave Crocker on behalf of Kurt Andersen" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Jul 2020 21:00:58 -0000 In article you write: >> I'd counter by personal anecdote that we have had to undertake >> security remediations because of messages which were forwarded by our >> CEO to other employees for responses which happened to contain malware >> and/or bad links. ... >Except that the problem isn't the email address, especially since almost >no one sees those any more.  And the display name isn't protected. Do we have any recent numbers on how many users see the From address rather than or in addition to the display name? Signed, uh, someone From nobody Sat Jul 18 01:45:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA63A00B3 for ; Sat, 18 Jul 2020 01:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bwVbTyE7PByq for ; Sat, 18 Jul 2020 01:45:16 -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 448263A00AD for ; Sat, 18 Jul 2020 01:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595061912; bh=/jzkH7LHlPNioBbu6zpXVTIjjTcRKKaxfww3KOCOAFQ=; l=1310; h=To:References:From:Date:In-Reply-To; b=BBZdnw6+8qdmq8S8S8Yuq9RWQ88FSpjWjJBjOGm4MkWqlqaJZKvHpAt6kVW1NSMNq Kccxpv9zprrIewDnbCE9fwzVMHJ1gD85PZkbttmiIG8wRqKHdVr57YxuXSBn/I79D8 1KwT20MkrfN8IN+R5HgPe+gwEhPNNwJAkxLDDbkk/PqipA8VKUiwqjZwdNjNE 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.000000005F12B698.00000AA3; Sat, 18 Jul 2020 10:45:12 +0200 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> From: Alessandro Vesely Message-ID: Date: Sat, 18 Jul 2020 10:45:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200717210053.674D61D2C431@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 08:45:18 -0000 On Fri 17/Jul/2020 23:00:53 +0200 John Levine wrote: > In article you write: >>> I'd counter by personal anecdote that we have had to undertake >>> security remediations because of messages which were forwarded by our >>> CEO to other employees for responses which happened to contain malware >>> and/or bad links. ... > >> Except that the problem isn't the email address, especially since almost >> no one sees those any more.  And the display name isn't protected. > > Do we have any recent numbers on how many users see the From address rather > than or in addition to the display name? Similar problems are typosquatting and homograph attacks. I heard the latter is being addressed also in email clients —which implies they target users who look beyond the display name. We used to hold that DMARC does not cover those topics. Why should we worry about display names? DMARC filtering is designed to operate at the (edge) MX, not MUA. If applied consistently, it grants a well defined kind of protection. That is just a building block, not a silver bullet. Our problem is that DMARC filtering cannot be applied consistently, because of MLMs. Lowering DMARC's contractual obligations is not a proper solution. Best Ale -- From nobody Sat Jul 18 10:17: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 0DA5E3A0AE9 for ; Sat, 18 Jul 2020 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biW-1gxzWd7B for ; Sat, 18 Jul 2020 10:17:04 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3966E3A0AE8 for ; Sat, 18 Jul 2020 10:17:04 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:b16f:a75a:9bf2:784a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06IHH2BU029729 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 18 Jul 2020 10:17:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595092623; bh=+DPZi2HZIRB4TibGseMeORMVa0KBlJ5Zk7u7mLBa/Es=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YA9+oI0BzZCaAcJ39odYIn05zfDR/uNrdZA6PnHZ6r0/sUYZdoZ7p8ZEAdw1LqcZm aP65SHx1zVTdSxnKieJndQA4E7exgbvAeDuc12tuJNVkCIrjQokeyEgnWcsO82zhmL QTefZEOUHQ+u+N2CFGXLzYX56Wjucd5vZtVMIEYw= To: dmarc@ietf.org References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Sat, 18 Jul 2020 10:16:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E4703AE7EAF72B4EE23E969" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 17:17:06 -0000 This is a multi-part message in MIME format. --------------4E4703AE7EAF72B4EE23E969 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, On 7/15/20 6:31 PM, Dotzero wrote: > As part of the original DMARC team and having worked with anti-abuse > for a long time at scale for a large set of websites, I can speak to > my motivation. It's not really about defending brand identity. The > data shows (although it is not mine to share) that end users=C2=A0will > click on anything based on the right social engineering. Love, money, > etc. are powerful motivators. The first thing that DMARC enables is > for a brand/domain to signal to validators/receivers that the domain > has control of it's mail streams and is identifying those mail streams > using the combination of SPF/DKIM/DMARC. This enables receivers to > process those mail streams with a certain amount of confidence. This > leaves open the question of when good domains go bad but that falls > into the realm of local policy on th part=C2=A0of the receiver. I think= > anyone who=C2=A0makes=C2=A0an assertion about "DMARC policy" needs.to > remember that at best it is a request to > validators/receivers. That's correct, but domains publishing DMARC policy need to bear in mind that some validators/receivers will honor that request and that it can create deliverability problems for their outgoing mail in some situations= =2E > > =C2=A0Yes, the issues of cousin domains, homoglyphs, etc. are thrown ou= t > there as reasons why DMARC is "irrelevant" to solving problems such as > spam or phishing. It doesn't solve spam but it does have an impact on > phishing, if only to push the bad guys to "push reality". If I get a > phishing email from a bank that is not my own, I as an=C2=A0end user am= > less likely to fall for that particular phishing scheme. It makes=C2=A0= it > easier for validators/receivers=C2=A0to=C2=A0 differentiate real from M= emorex. > It's also important to recognize that the environment isn't static. > The bad guys are always thinking up new approaches as the > old/currnt=C2=A0ones yield declining results. This evolving context is > sometimes brandished against DMARC as an indicator that it isn't useful= =2E It's not that DMARC isn't useful. We need to consider (and document) the threats that it is effective against (unauthenticated mail claiming to come from a domain from which it should have been authenticated) and those it is not effective against (homoglyphs, display name misuse, etc.). And then we need to consider the collateral damage, such as against mailing lists and their users, and do a cost/benefit analysis to determine whether the benefit justifies the breakage. With 5 years of experience since RFC 7489 was published it's reasonable to revisit these issues with the benefit of that experience. > > My experience with a number of brands/domains that were aggressive in > implementing SPF/DKIM/DMARC as well as other measures, we were able to > drive down abuse against those brands/domains by over 95%. Did the bad > guys continue to test both external abuse as well as probe for > weaknesses that would enable abuse through the systems? Absolutely. > Did they move on to other brands/domains to abuse? Absolutely. > > When Jim asks the question "What problem are we trying to solve?", > perhaps the prior question should be "Who are we?". Part of the reason I ask that question is because RFC 7489 Section 2.4 says, "DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions)." If restrictive DMARC policies were only applied to domains that were used for transactional email, we wouldn't be having this problem with mailing lists and the like. -Jim --------------4E4703AE7EAF72B4EE23E969 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mike,

On 7/15/20 6:31 PM, Dotzero wrote:
As part of the original DMARC team and having worked with anti-abuse for a long time at scale for a large set of websites, I can speak to my motivation. It's not really about defending brand identity. The data shows (although it is not mine to share) that end users will click on anything based on the right social engineering. Love, money, etc. are powerful motivators. The first thing that DMARC enables is for a brand/domain to signal to validators/receivers that the domain has control of it's mail streams and is identifying those mail streams using the combination of SPF/DKIM/DMARC. This enables receivers to process those mail streams with a certain amount of confidence. This leaves open the question of when good domains go bad but that falls into the realm of local policy on th part of the receiver. I think anyone who makes an assertion about "DMARC policy" needs.to remember that at best it is a request to validators/receivers.
That's correct, but domains publishing DMARC policy need to bear in mind that some validators/receivers will honor that request and that it can create deliverability problems for their outgoing mail in some situations.

 Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there as reasons why DMARC is "irrelevant" to solving problems such as spam or phishing. It doesn't solve spam but it does have an impact on phishing, if only to push the bad guys to "push reality". If I get a phishing email from a bank that is not my own, I as an end user am less likely to fall for that particular phishing scheme. It makes it easier for validators/receivers to  differentiate real from Memorex. It's also important to recognize that the environment isn't static. The bad guys are always thinking up new approaches as the old/currnt ones yield declining results. This evolving context is sometimes brandished against DMARC as an indicator that it isn't useful.
It's not that DMARC isn't useful. We need to consider (and document) the threats that it is effective against (unauthenticated mail claiming to come from a domain from which it should have been authenticated) and those it is not effective against (homoglyphs, display name misuse, etc.). And then we need to consider the collateral damage, such as against mailing lists and their users, and do a cost/benefit analysis to determine whether the benefit justifies the breakage. With 5 years of experience since RFC 7489 was published it's reasonable to revisit these issues with the benefit of that experience.

My experience with a number of brands/domains that were aggressive in implementing SPF/DKIM/DMARC as well as other measures, we were able to drive down abuse against those brands/domains by over 95%. Did the bad guys continue to test both external abuse as well as probe for weaknesses that would enable abuse through the systems? Absolutely. Did they move on to other brands/domains to abuse? Absolutely.

When Jim asks the question "What problem are we trying to solve?", perhaps the prior question should be "Who are we?".

Part of the reason I ask that question is because RFC 7489 Section 2.4 says, "DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions)." If restrictive DMARC policies were only applied to domains that were used for transactional email, we wouldn't be having this problem with mailing lists and the like.

-Jim


--------------4E4703AE7EAF72B4EE23E969-- From nobody Sat Jul 18 10:21:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40E3A09DB for ; Sat, 18 Jul 2020 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGNK84Fuul13 for ; Sat, 18 Jul 2020 10:21:55 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF133A0985 for ; Sat, 18 Jul 2020 10:21:55 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:b16f:a75a:9bf2:784a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06IHLssX029780 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 18 Jul 2020 10:21:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595092915; bh=LKgVAZhFeuLk7+hWzHIRS8imYahUvZszYtlkZHLX+h0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=j7ht08lgus/WcWhgcCUOApNSx3asG4IX9r7IWkeHoarusNUZrodIltwELncc8fGph Vcby5EJ5DIJz9CKZG9JnY7pRV0lU7UmY49HkW71Kg30Ed4CEWKTajl5W6JcaSZAPf3 7tGckNLVPWcFOzy5UFPSB7gdeabM/CZDSgDtEn90= To: dmarc@ietf.org References: <5F11CB6C.3050101@isdg.net> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <5ef11b97-7263-4cc1-38c7-d89986eff85e@bluepopcorn.net> Date: Sat, 18 Jul 2020 10:21:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F11CB6C.3050101@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 17:21:57 -0000 Hi Hector, On 7/17/20 9:01 AM, Hector Santos wrote: > Jim, if we review both RFC4686 and RC5016, I believe we might find > there is not much to be changed. However, imo, something will have to > be done regarding RFC5016 section 5.3 item: > >   https://tools.ietf.org/html/rfc5016#section-5.3 >   5.3.  Practice and Expectation Requirements > >   10. SSP MUST NOT provide a mechanism that impugns the existence of >       non-first party signatures in a message.  A corollary of this >       requirement is that the protocol MUST NOT link practices of first >       party signers with the practices of third party signers. > >        INFORMATIVE NOTE: the main thrust of this requirement is that >        practices should only be published for that which the publisher >        has control, and should not meddle in what is ultimately the >        local policy of the receiver. > > This provision with strict protocol language "MUST NOT" prohibits any > DKIM Policy protocol, formally called SSP "Sender Signing Practices" > and now today, DMARC, from impugning on 3rd party policies such as how > a MLM operator via local policy exceptions can ignorantly and blinding > destroy the integrity and resign the mail instead of just honoring it. > > This language would have be updated or removed and just leave the > implicit idea that local policy always prevails in all SMTP situations. Despite its use of normative language, RFC 5016 is an informational RFC and is therefore not binding on anything or anyone. I was primarily citing RFC 4696 and RFC 5016 as examples of the type of analysis I am hoping will be done for DMARC. > > Have a good weekend, be safe. You too. -Jim From nobody Sat Jul 18 10:24:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F033A0AF5 for ; Sat, 18 Jul 2020 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN7EDoLXJauk for ; Sat, 18 Jul 2020 10:24:18 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213B23A0AF6 for ; Sat, 18 Jul 2020 10:24:17 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:b16f:a75a:9bf2:784a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06IHOFjN029799 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 18 Jul 2020 10:24:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595093056; bh=NA80kO9K2J/iWg6zwEUi3d438X0Vtj9qyttCiQHESKo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZlbPgjyt5Gc9Y/X3qDiWSZInNvygkeZs11c72w75wv7MgLuvrA0dWMI/MYYNgZgEG p5DgvicnbGfwZNCfA5yOKCkzRNcBezy0h+tNVDtnLz92w/Q68Pw54djpHnPcKi1rpN 0sbjECfKvOTq2x2gEDBh8iX6BeIxFUNmYW8luFKE= To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: Date: Sat, 18 Jul 2020 10:24:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 17:24:20 -0000 On 7/18/20 1:45 AM, Alessandro Vesely wrote: > DMARC filtering is designed to operate at the (edge) MX, not MUA.  If > applied consistently, it grants a well defined kind of protection.  > That is just a building block, not a silver bullet.  Our problem is > that DMARC filtering cannot be applied consistently, because of MLMs.  > Lowering DMARC's contractual obligations is not a proper solution. > > You lost me there. What do you mean by "DMARC's contractual obligations"? -Jim From nobody Sat Jul 18 13:11: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 E10863A0CFC for ; Sat, 18 Jul 2020 13:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 7qLXjIhJbsmP for ; Sat, 18 Jul 2020 13:11:54 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0393A0CFB for ; Sat, 18 Jul 2020 13:11:54 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id a21so9347003otq.8 for ; Sat, 18 Jul 2020 13:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=oJXn7Ym8CifI64qgBanKLPJ9fukJ8VSYhJlBgRMlgzs=; b=o4doFqx2VJiezk71QJZYVw85BKAi41VYyhOsuhJ6Rsw2nqgpbYQgUFRa2Odsi/nirk FDYNlgSpa+uFgvvJXGhzacpzuj9l+hwJR0aBdrEM7GwWmHszhovoEwj1K08qsXax5CT5 VvuFLRPlxK1s5x1GTh4NEhpxtWRaIodUThN1ZxklfzCBxOCdiXYrlLwW7su64KuWkiLO ZVUYMMhgfcKkZ1BL4ZnaenaiqgffzmrTxcQFCUR11u+fyFYbt/BLB8VblekfIRx7cnkW XcUfqJvslVF1hksIcUPIk2NmYX1p59HbmnUCrALwE4AszBYm73pPJzTFc2qhM+2ALYC6 TlbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oJXn7Ym8CifI64qgBanKLPJ9fukJ8VSYhJlBgRMlgzs=; b=oxt9YolGKX74n0tphTE0wFGoSoqhZ/h7uYcAiuEkLO1E5KBZQk1ihi4hPVBjoPQPET r/IXexh7Pw5KCCrGHqEZsfZCAZePItNRFC+YUZzXFXcPAJpi6wJLM7/y3HYnOkiqrl0j 0zlypSJ923rOegdXjc7EEX0zo+sjdhDVFSG0QFWQUx0OegKBXHWEB0ZPj/KBaXjjyM53 OBpSsEJgvP2MsPRDu3Pcf8CwtnNJn+/cnDwjPXq2Mjmtr0F382STWRV4uo3MGGzqy0iw EWJV0Ryj403Nq/OK16tzlv/YCXVoH7Io2Pn5/IoeUw/mrwno4tDn02hm5rGUk+yUW/OJ Sv+w== X-Gm-Message-State: AOAM532VUzCGOm30OMeq+nZ3ZzToswU7nQoze6rBy/8e3cS8ofaq6ykV PxkzaV7CBjuWWON1riP1tNDqNYaTOVs= X-Google-Smtp-Source: ABdhPJzZ1GIWyCZ3uRlGflMPfiIpLy5xxl1PJ7xHHG70u6trchFTNDfIReOMD4URokJdtGXUE6rdfA== X-Received: by 2002:a9d:4b90:: with SMTP id k16mr13483038otf.69.1595103113796; Sat, 18 Jul 2020 13:11:53 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:e11f:3900:91ad:f362? ([2600:1700:a3a0:4c80:e11f:3900:91ad:f362]) by smtp.gmail.com with ESMTPSA id o8sm2658167otj.29.2020.07.18.13.11.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jul 2020 13:11:52 -0700 (PDT) To: Dave Crocker on behalf of Kurt Andersen , dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> From: Dave Crocker Message-ID: Date: Sat, 18 Jul 2020 13:11:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200717210053.674D61D2C431@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 20:11:56 -0000 On 7/17/2020 2:00 PM, Dave Crocker on behalf of Kurt Andersen wrote: > Do we have any recent numbers on how many users see the From address rather > than or in addition to the display name? Thereby making clear that this is a spoofed message, since I wouldn't ask a question like that, potentially distracting from the substance of the topic.  Beyond, none vs. some vs. all, the numbers shouldn't matter. There is ample evidence that trust markers presented to end users do not produce adequately differential (and useful) decision-making about whether a message is trustworthy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 18 17:14: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 D22923A0EA0 for ; Sat, 18 Jul 2020 17:14:06 -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 dL7gY6iFQKjE for ; Sat, 18 Jul 2020 17:14:05 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727F13A0E9F for ; Sat, 18 Jul 2020 17:14:05 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id g4so3961929uaq.10 for ; Sat, 18 Jul 2020 17:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqtNjoM97FGf1TFl3Dn5pjQmNFVJiCseEfnALkdFu1c=; b=RYo9S3sDrxzeRHBD/hPmjAXxHoD2kNnJUn7LMVwU0VupluO5crkp03eRV8ExmGFm+v F+CLx6T5PIxYEWOXJc5W4q2/E1oBj4X1ukxjB0YCX5BwC4D+JG9r7FJXFNurw8xqqXDV 0iG4tlJmFnRjhzyVSFLe0G4X2TZ0+1VW1FBX8eWaZhrjCtxyTj82o69bK/2J71C+1nYD Od5l/UJ0Mn6PLK9A+9flVUwl17dscsPu80XqihdihlJ+tDGfFsrKHv2jrBSoSn6Imp3a bDjCGYAD1XO/16rxxu3VY8vJ8zSGGhxH4fdRvmgjcviYBVsZTrZNaAf66c2sEm7dPTMf GI0Q== 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=qqtNjoM97FGf1TFl3Dn5pjQmNFVJiCseEfnALkdFu1c=; b=XWJoF0knglAyAX+vcAMceJCD6ouIpweFqTwJRBO9wyDWyo3FX8gRlRnD1/oBO0+zlq iumxPgJ3VLKRNG2gk70zkqvKMeb3eryRPpoPm2rFN6midSuXOBxuKEsLvtGZCNpiF4he ZkmGpSfLnVNyAkMkMz91fAOmegoj7/uqX4KJArhR83OfNPp2ElTTVDkb1oIYg6jmhimN yWnaTXXGAJd9DeLtD7Q77jLvIan/QlWJhv0nJaiCb7A7wQhtNDoUaeutfvvcxIfW6wyM oEy9V8nZTE5BOF4aQRJG4ApJG4WkmMMq6toc+rG9TGVpkw4KbaCANKAIswpMBeKDZXr3 P0sA== X-Gm-Message-State: AOAM533QNrM70SN6kYIWTgtbuSOh8PezH+KXh/NuDxDr+SinbIPHtclp 5HttSFMsY0FUxKEJvYPtkUUy06401JZ/m6fVBbnsSQ== X-Google-Smtp-Source: ABdhPJxHoeU/cMN7H5hrEk053hbLRzJegsBC+tDRGtC+jWkruXlnERnkiZQV7A1G3bqfaj79TQK5i+wPGPBk5/nuGyk= X-Received: by 2002:a9f:2a8e:: with SMTP id z14mr12233681uai.47.1595117644328; Sat, 18 Jul 2020 17:14:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 18 Jul 2020 17:13:53 -0700 Message-ID: To: Jim Fenton Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000090b2c005aac044ba" Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 00:14:07 -0000 --00000000000090b2c005aac044ba Content-Type: text/plain; charset="UTF-8" On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton wrote: > Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there > as reasons why DMARC is "irrelevant" to solving problems such as spam or > phishing. It doesn't solve spam but it does have an impact on phishing, if > only to push the bad guys to "push reality". If I get a phishing email from > a bank that is not my own, I as an end user am less likely to fall for that > particular phishing scheme. It makes it easier for validators/receivers to > differentiate real from Memorex. It's also important to recognize that the > environment isn't static. The bad guys are always thinking up new > approaches as the old/currnt ones yield declining results. This evolving > context is sometimes brandished against DMARC as an indicator that it isn't > useful. > > It's not that DMARC isn't useful. We need to consider (and document) the > threats that it is effective against (unauthenticated mail claiming to come > from a domain from which it should have been authenticated) and those it is > not effective against (homoglyphs, display name misuse, etc.). And then we > need to consider the collateral damage, such as against mailing lists and > their users, and do a cost/benefit analysis to determine whether the > benefit justifies the breakage. With 5 years of experience since RFC 7489 > was published it's reasonable to revisit these issues with the benefit of > that experience. > DMARC did attempt to document these shortcomings itself, for example in Section 12.4 of RFC 7489 which covers display name attacks. I imagine this would be carried forward into the standards track version, unless the working group wants to entertain the idea of breaking it all out and re-hashing it first. This working group also produced RFC 7960 which talks about the problems with respect to mailing lists. Maybe we have more data in the last four years? Still unresolved, IMHO, is Dave's point about whether the RFC5322.From domain truly matters. -MSK, most participatorially --00000000000090b2c005aac044ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 18, 2020 at 10:17 AM Jim Fent= on <fenton@bluepopcorn.net= > wrote:
Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there as reasons why DMARC is "irrelevant" t= o solving problems such as spam or phishing. It doesn't solve spam but it does have an impact on phishing, if only to push the bad guys to "push reality". If I get a phishing ema= il from a bank that is not my own, I as an=C2=A0end user am less likely t= o fall for that particular phishing scheme. It makes=C2=A0it easier for validators/receivers=C2=A0to=C2=A0 differentiate real from Me= morex. It's also important to recognize that the environment isn'= ;t static. The bad guys are always thinking up new approaches as the old/currnt=C2=A0ones yield declining results. This evolving context is sometimes brandished against DMARC as an indicator that it isn't useful.
=20
It's not that DMARC isn't useful. We need to consider (and docu= ment) the threats that it is effective against (unauthenticated mail claiming to come from a domain from which it should have been authenticated) and those it is not effective against (homoglyphs, display name misuse, etc.). And then we need to consider the collateral damage, such as against mailing lists and their users, and do a cost/benefit analysis to determine whether the benefit justifies the breakage. With 5 years of experience since RFC 7489 was published it's reasonable to revisit these issues with the benefit of that experience.

D= MARC did attempt to document these shortcomings itself, for example in Sect= ion 12.4 of RFC 7489 which covers display name attacks.=C2=A0 I imagine thi= s would be carried forward into the standards track version, unless the wor= king group wants to entertain the idea of breaking it all out and re-hashin= g it first.

This working group also produced R= FC 7960 which talks about the problems with respect to mailing lists.=C2=A0= Maybe we have more data in the last four years?

Still un= resolved, IMHO, is Dave's point about whether the RFC5322.From domain t= ruly matters.

-MSK, most participatorially
=
--00000000000090b2c005aac044ba-- From nobody Sat Jul 18 17:17: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 F1E093A0EA4 for ; Sat, 18 Jul 2020 17:17: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 aCBzL1MCbD1T for ; Sat, 18 Jul 2020 17:17:02 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF613A0EA2 for ; Sat, 18 Jul 2020 17:17:02 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id p6so3961537uaq.12 for ; Sat, 18 Jul 2020 17:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c4LZ0AHtia9Z7kZcUazjkzdgWtpBd2cu6uJNLA3cTzw=; b=bhvoF1XNJyYars6XPcJvzcRDaf1dDa9hnTOVU5ZeF8QxKbIT36XnnThIxnXCMhYy7P +WbI2gSjx7xA7vwpk1lTQIXEyLKhvoUVspIu+icROjLu6VnUBpNB3vGdkQrwqWuZyh+C o9D1RySTiCfnQIwURq/mdABBfldrjAJjOqJ8JSxlYTLiN7lzU4aeuTtpOK9fXwCZ1O25 49fhBQjUHRF9qoPiZIvtTQBkeubRyNWRIvOlJNUWhiHsqY8ucyrD5FXpsfQwTaHrMb7n FqUWD3m2L+/QqugnT38NOsUEjzpzsNucrM6t0UDmf4J4rQlmfVI8u3aa7HJaJTen3hCG D+sQ== 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=c4LZ0AHtia9Z7kZcUazjkzdgWtpBd2cu6uJNLA3cTzw=; b=hOWl9SlW8l/3KoPcrriEEzgSeTAVAhuRgHXD1jaxFHLqcdcKg/4HQGJwAWren0+0YM wawU7t+ZrPVp3ql2IdKrcpDmqRvqZ8m66gdnC3DO124RQUy9OnHewS+uzoa8cI1JlqOt qegRzxbocV7v+peSkYaA+pjiy0Kmq5TPgU8aRwUGyizhqKdqWgCiwn1JxKZgkOzaZKjC mF6sDQR2FJ3BQLwpiXE2uYECrRRkuSIVCOdg7C3+KV2aAW5xXt7h0qGvIdmMmVjg3w8h 21/WB9PudjXIRqAqJynRpLs285OBZWduxvoF88mQZAP0/+atmcL0iJ/WFRLNrWVjjekN FWTQ== X-Gm-Message-State: AOAM5334KXZNUIprvWQ9tgBmBaU75EVb8YrnVGonj5Ex/isHVexTokoP zPrOCkuvZxU6OqYmzY4RM/TnkEj8/IAg0BRibQk= X-Google-Smtp-Source: ABdhPJzxzTYnle3NZtNRbFgCYnI360JiKkIh7QBGSa0CmPqpBhJExj0ZEYkcizAAS2MKBGTErAc4Qb+1zT8/H/H5BDc= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr5699632uad.87.1595117821573; Sat, 18 Jul 2020 17:17:01 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> In-Reply-To: <20200717210053.674D61D2C431@ary.qy> From: "Murray S. Kucherawy" Date: Sat, 18 Jul 2020 17:16:50 -0700 Message-ID: To: Dave Crocker on behalf of Kurt Andersen Cc: IETF DMARC WG , Dave Crocker Content-Type: multipart/alternative; boundary="000000000000213e4005aac04fc2" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 00:17:04 -0000 --000000000000213e4005aac04fc2 Content-Type: text/plain; charset="UTF-8" Brandon Long, if you're watching: On Fri, Jul 17, 2020 at 2:01 PM Dave Crocker on behalf of Kurt Andersen < johnl@taugh.com> wrote: > In article you write: > >> I'd counter by personal anecdote that we have had to undertake > >> security remediations because of messages which were forwarded by our > >> CEO to other employees for responses which happened to contain malware > >> and/or bad links. ... > > >Except that the problem isn't the email address, especially since almost > >no one sees those any more. And the display name isn't protected. > > Do we have any recent numbers on how many users see the From address rather > than or in addition to the display name? > > Signed, > uh, someone > At some point in the past, Gmail decided to show the email address only unless that address was in the recipient's contact list, or if the recipient had replied to that address previously, or something like that. In those cases, the RFC5322.From address was trusted, and so the display name was shown. Is there logic like that still in place? Any other UI developers got a policy here? -MSK, sans chapeau --000000000000213e4005aac04fc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brandon Long, if you're watching:
=

= On Fri, Jul 17, 2020 at 2:01 PM Dave Crocker on behalf of Kurt Andersen <= ;johnl@taugh.com> wrote:
In article <cd9258e6-3917-2380-dd9b-66d74f3a64d3@gmail.com> you write:
>> I'd counter by personal anecdote that we have had to undertake=
>> security remediations because of messages which were forwarded by = our
>> CEO to other employees for responses which happened to contain mal= ware
>> and/or bad links. ...

>Except that the problem isn't the email address, especially since a= lmost
>no one sees those any more.=C2=A0 And the display name isn't protec= ted.

Do we have any recent numbers on how many users see the From address rather=
than or in addition to the display name?

Signed,
uh, someone

At some point in the past, = Gmail decided to show the email address only unless that address was in the= recipient's contact list, or if the recipient had replied to that addr= ess previously, or something like that.=C2=A0 In those cases, the RFC5322.F= rom address was trusted, and so the display name was shown.=C2=A0 Is there = logic like that still in place?

Any other UI developers g= ot a policy here?

-MSK, sans chapeau
--000000000000213e4005aac04fc2-- From nobody Sat Jul 18 18:32:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F04A3A003B for ; Sat, 18 Jul 2020 18:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 NVa4KI7iSOGr for ; Sat, 18 Jul 2020 18:32:21 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633BD3A0039 for ; Sat, 18 Jul 2020 18:32:21 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id l63so11391399oih.13 for ; Sat, 18 Jul 2020 18:32:21 -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=ZVUDtCh6wMK+bQRGEC2euHmtYqqdloiTVnrOcsHNDH8=; b=Z7CjICD+SENpwKsDEY+k13dKkNlOUqAFT1qG9T1sAZpkh+wdWDg+1dC0DUwbB+EoIP rhFCtH/Hf9N85RucLCOnH2ivvsTKp6OQg+oWE+K4SHlaqrroE51FbRng/11HJBEX2ooA 5bwWOTfG301iJHvSwIKgaTa/Y5T7X6FvLfmKmSnAB3VCEpn/AGxvseey/cYQmb+D5qcY ZmPfIdx6bdmoWW8rnCd9OZzaqxN/FPHTpyxBF1EKXgiFvX7YB9a2/n1fOaUwX/IX4Ly/ NinFlQsT8ucPSLLP/k4U737NgdSTzzwUes68QWiCig1qY0v+470gsZJNe6kIEMqRJqVA NRfw== 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=ZVUDtCh6wMK+bQRGEC2euHmtYqqdloiTVnrOcsHNDH8=; b=tGQyvl02DQRwHrz/oIZV81lpkEuEkj8Exbj0Big1z+NVTlXFi3xrDWpXnL9ne4rHmA 8wOyEk8Nj6nrun1bxgn/WDkhpI3SpdJBFSZbxwo7PEAVay9O5/585wbpA0HIyq7xpEpX qX1sidGdSfSTr+q0KQGesQQrQ9o8yq0XVo/J4AzpXbrCkLRYWgmHu2MPXuxFkgGq3q26 KVVbFHPHD4JVarNf+ebLmsAV4Wh7GFbt2ba8P76mOK/h6zH4mxqIaISkbfZfcMfijUF1 0yZ5il6TAzw7ETXIUzROuXcfq+VIF3WGmxwi1FxWCMlrRTJ5GP7cUXuu/85dplt+MvKm wPiA== X-Gm-Message-State: AOAM530fG+0L7FRzrdbdWVPiKZGFbDcX4ps/irw30B7KZG8HnDeFgGpV hp9wgtKJDaIFsV9PgJjdQ2p7F3aVebU= X-Google-Smtp-Source: ABdhPJzW5HslXgyo0JbM9eufbi2D09IAccxvNk/yVr+roZo7T4Ogj+CoT+34nlOMielw2yd4DyNnkw== X-Received: by 2002:aca:fccd:: with SMTP id a196mr13396975oii.92.1595122340314; Sat, 18 Jul 2020 18:32:20 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:e11f:3900:91ad:f362? ([2600:1700:a3a0:4c80:e11f:3900:91ad:f362]) by smtp.gmail.com with ESMTPSA id y26sm3186606ooq.3.2020.07.18.18.32.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jul 2020 18:32:19 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> From: Dave Crocker Message-ID: <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> Date: Sat, 18 Jul 2020 18:32:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 01:32:23 -0000 On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote: > At some point in the past, Gmail decided to show the email address > only unless that address was in the recipient's contact list, or if > the recipient had replied to that address previously, or something > like that.  In those cases, the RFC5322.From address was trusted, and > so the display name was shown.  Is there logic like that still in place? If end users do not reliably make trust decisions based on /any/ of the information in the rfc5322.From field, then how is this question important.  It seems to be seeking precise data about something that isn't even secondary. The persistence of thinking that end users are influenced by trust indicators is pernicious. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 18 21:23: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 A95423A08BD for ; Sat, 18 Jul 2020 21:23: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vG3aduI0nEs for ; Sat, 18 Jul 2020 21:23:50 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EF83A08BA for ; Sat, 18 Jul 2020 21:23:50 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id l12so4049719uak.7 for ; Sat, 18 Jul 2020 21:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HikvOiCHrBwVNLYyzNxDLHJDyE2ZVBrfrsaflUKSBhc=; b=Gs3DRkYBDlTENW0B8eDUWOB4yAmfgbQKLA+1xaWO5zHw6XPyJKsn1Ce5hT2jC4jR1x gRu18qgjyZygIqWt+2FUgxKj71Gww1QLTi89303b9Dlm79BwjRYKnh9Xwu+v1+9HAwsk ori2TAXW8msOZocFLHElTnWzUhtNHnNpf5If+XBaB8PT8nF2UyKmMMAtsQhMk12/31QK 1TeyQKyRxq6dGNKUW/eMnx5x3vwDKS3OpyXwe/tfzqaAJJYv/EydZCtK+d2jLyQpghzb WaGl1NDI0tP9zDhJftmI4X3SOKzJFfLSb7TVtv5Fo5XpqjVgCfQ5qLFTplWfAkB28du0 vAEA== 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=HikvOiCHrBwVNLYyzNxDLHJDyE2ZVBrfrsaflUKSBhc=; b=NTgbVnsk4Ww3aMXtmLe6MBcJCHPB9MJS0GCrGsCLTspo3Y8J34Bqar2nAr8XzVvyap 4H9+saKTkQVJWCCpM/ISoH7Y0OUr2Zq5NMEXQ3nMfSCi2n6O8aFphpbDuLRMG7YfQDRx JX0c4GuSPTuxljpTTPYpM0E8CBIk8mDv8X9HOVgv+jhZetqgw6c1WJVOH9whDKFfcP1P qdJV/0XtzI3XrmB4s1emLxoyJyJUX4MgEuQnkq5JjNQD8EMk864eRRihCVnv2gFQv2zF 0JchBEqVFErz2M4Y4V5Daa0AsK02/OJSKSbSy5nMgQIAA29jvO4K88gPjs2HWO/sN8vd Kpzg== X-Gm-Message-State: AOAM532lLtQe0ZustxcSguiPt99/jAqdnr2m+Hmt1pDRYtflRBltayU5 m09w347T59DsWiJY5WLmD+UcYxvpLYheydEpJfw= X-Google-Smtp-Source: ABdhPJzH75D9hUO4WzuLMlNOzuZrtP1uOEnStWEN9JKO6De7skm/IzQ+IGq9WC9VRhKQuTlIbmOm3ZG+sVJWZOaIiR4= X-Received: by 2002:a9f:3806:: with SMTP id p6mr11888290uad.101.1595132629235; Sat, 18 Jul 2020 21:23:49 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> In-Reply-To: <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> From: "Murray S. Kucherawy" Date: Sat, 18 Jul 2020 21:23:36 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bc3fb205aac3c116" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 04:23:52 -0000 --000000000000bc3fb205aac3c116 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker wrote: > If end users do not reliably make trust decisions based on /any/ of the > information in the rfc5322.From field, then how is this question > important. It seems to be seeking precise data about something that > isn't even secondary. > Google strikes me as the kind of place that would make a decision about what to show users based on data, so I was wondering if they have any, because I seem to remember them talking about this back when DMARC was in development. While I'm intrigued by the discussion about the domain name isn't visible and thus may not be as important to protect as we originally thought, I'm less convinced by the notion that all of the RFC5322.From is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case. -MSK --000000000000bc3fb205aac3c116 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 18, 2020 at 6:32 PM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
If end users do not reliably make trust decisions based on = /any/ of the
information in the rfc5322.From field, then how is this question
important.=C2=A0 It seems to be seeking precise data about something that <= br> isn't even secondary.

Google strike= s me as the kind of place that would make a decision about what to show use= rs based on data, so I was wondering if they have any, because I seem to re= member them talking about this back when DMARC was in development.

While I'm intrigued by the discussion about the domain= name isn't visible and thus may not be as important to protect as we o= riginally thought, I'm less convinced by the notion that all of the RFC= 5322.From is disregarded by the preponderance of users when deciding what l= evel of trust to put in the message's content.=C2=A0 That suggests we b= lindly open and read absolutely everything, and I suspect that isn't th= e case.

-MSK
--000000000000bc3fb205aac3c116-- From nobody Sun Jul 19 02:40:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2FC3A0C27 for ; Sun, 19 Jul 2020 02:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4seZZR6oYxAW for ; Sun, 19 Jul 2020 02:39:59 -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 A30473A0C22 for ; Sun, 19 Jul 2020 02:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595151596; bh=DV9DlLGZH+kY0v9gZ3Vmcm1hVFGCDDduZceZHzwrS1E=; l=1113; h=To:References:From:Date:In-Reply-To; b=DF22LDGmTOUJisXwlmpLoY0Mly4dvWO5Xsi0zR0YGEZOJSxw/E8WDJCXv8WPO7u1q RIeJNO4gfhoOKDT1wcuS4sCs/vYws7ShHfOv1KCamZ7LcOm1nZcb3PgK/DyvpFvNoO u8DiKfn0VU+eKW8yt4kqHV8RcHod2bEIFvknkVFDegQa4LYVz8U3LWiFrPfSr 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.000000005F1414EC.00000FD0; Sun, 19 Jul 2020 11:39:56 +0200 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> From: Alessandro Vesely Message-ID: <7b658b75-2235-04a9-b9f8-bcc9d40c15ed@tana.it> Date: Sun, 19 Jul 2020 11:39:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 09:40:05 -0000 On Sat 18/Jul/2020 19:24:10 +0200 Jim Fenton wrote: > On 7/18/20 1:45 AM, Alessandro Vesely wrote: > >> DMARC filtering is designed to operate at the (edge) MX, not MUA.  If >> applied consistently, it grants a well defined kind of protection. >> That is just a building block, not a silver bullet.  Our problem is >> that DMARC filtering cannot be applied consistently, because of MLMs. >> Lowering DMARC's contractual obligations is not a proper solution. >> >> > You lost me there. What do you mean by "DMARC's contractual obligations"? One is filtering on From: o Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain. https://tools.ietf.org/html/rfc7489#section-2.1 Here, authorship should be meant to be something rather akin to a formal copyright holder, whereas the Author: field addresses moral attributions. In that sense, authorization to rewrite From: is granted by BCP 78.[*] OTOH, filtering on Sender: doesn't comply with the quoted purpose. Best Ale -- [*] IANAL. From nobody Sun Jul 19 03:14: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 80CD53A07CB for ; Sun, 19 Jul 2020 03:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6KV_KNGnyKei for ; Sun, 19 Jul 2020 03:14:40 -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 225AA3A07C8 for ; Sun, 19 Jul 2020 03:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595153676; bh=Yuywzf9DtM55cntLocwJbztdMI/PVvhnAPaKBIfME3w=; l=1805; h=To:References:From:Date:In-Reply-To; b=A4Z9k9LoKVEGsgdtR8OmTUuGc7F2irP4+oOIYcahPTbTnoE5RKuF3S7tIkqkX/zoI lLrqGY2oDQfC7K57eUrpqaeJw2OnR/d8PCdAS+lM3/KQbkrcuZckF/ddHdIrJUfWGk /cLOyDLeFUIhDw3O1GEEanTIRfXKR7E/iMpmEnWBZbevUiw2w5xIRoB1fxQZ1 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.000000005F141D0C.0000141B; Sun, 19 Jul 2020 12:14:36 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> Date: Sun, 19 Jul 2020 12:14:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 10:14:42 -0000 On Sun 19/Jul/2020 02:13:53 +0200 Murray S. Kucherawy wrote: > On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton wrote: > >> Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there >> as reasons why DMARC is "irrelevant" to solving problems such as spam or >> phishing. [...] >> >> It's not that DMARC isn't useful. We need to consider (and document) the >> threats that it is effective against (unauthenticated mail claiming to come >> from a domain from which it should have been authenticated) and those it is >> not effective against (homoglyphs, display name misuse, etc.). [...] >> > > DMARC did attempt to document these shortcomings itself, for example in > Section 12.4 of RFC 7489 which covers display name attacks. I imagine this > would be carried forward into the standards track version, unless the > working group wants to entertain the idea of breaking it all out and > re-hashing it first. I think the WG charter is clear enough. > Still unresolved, IMHO, is Dave's point about whether the RFC5322.From > domain truly matters. While the opinions of big players are relevant, you yourself mentioned that they tend to follow DMARC design. Perhaps, some years ago, it was the importance of From: domain which inspired DMARC design. Now, it's DMARC which determines the importance of From: domain. Filtering at MX level followed DMARC development rather closely. MUA behavior lags behind, but seems to be plodding through. We might suggest guidelines (for example, bewaring of at signs in display names), but it is their task to find out how to highlight domain misalignment. The more dependable is DMARC filtering, the greater are MUA's motivations to follow suit. Not the other way around. Best Ale -- From nobody Sun Jul 19 05:13:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287993A097D for ; Sun, 19 Jul 2020 05:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cjLERlcm_cjT for ; Sun, 19 Jul 2020 05:13:51 -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 6274F3A097C for ; Sun, 19 Jul 2020 05:13:51 -0700 (PDT) X-ASG-Debug-ID: 1595160825-11fa3107a810c70001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id kJwfsot2BRqQNEtH (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sun, 19 Jul 2020 08:13:45 -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=from:message-id:subject:to; bh=vseg8aein52Dh2mIAZE7bTGUWklskWLUdy+mkg6w1kk=; b=iYwSwda2mQeVb2Z2wjU0Iwbl02+8eNEkLo3cv9C5pBE8NjET1/jkJyhgWPntX8YDz NGdNke2cjBRLFuuuPPTC6cyJ5hbFeCal7FHRnh7Z8UmfHB5DWdYt4+VngvI0XLmLn 9rBNakosYDUAlIFGQYQjukTz6zQPpZd+tcWeeuhzM= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 19 Jul 2020 08:13:38 -0400 To: Dave Crocker , "Murray S. Kucherawy" Cc: IETF DMARC WG Date: Sun, 19 Jul 2020 08:13:37 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Message-ID: MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=b810581c61a84b17844412b76c8e9b28 Importance: normal From: "Douglas E. Foster" X-Exim-Id: eb91e0bcb3f74629b13b9149e3558397 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595160825 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: 5771 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83307 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 12:13:53 -0000 This is a multipart message in MIME format. --b810581c61a84b17844412b76c8e9b28 Content-Type: multipart/alternative; boundary=05e67c83495e4a4fa89868be3846e97a --05e67c83495e4a4fa89868be3846e97a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your comments mply that for non-MLM messages, the only purpose of rfc5322.F= rom is trust.=A0 =A0A related action would be attribution:=A0 after an atta= ck, whom do I blame?=A0 Domain owners do not want to be attributed to someo= ne else's crime.But obviously, there are other purposes, such as searching = and sorting.=A0 =A0These also depend on accurate values.=A0 =A0Consequently= , spoofing affects multiple=A0 functions which are important to domain owne= rs and message=A0readers.=A0=A0You asserted again that nearly all MUAs hide= the From address, then ignored contrary data.=A0 =A0Gmail and Outlook have= significant user bases.=A0 =A0No one has identified the long list of MUAs = that hide, or indicated the market share of those MUAs.What has also not be= en explained is:=A0 =A0why it is an uncoscienable burden for MLMs to use rf= c5322.From addresses of the form user=3Ddomain@MLM?=A0 Any such attempt is = weakened by your assertions that From matters to no one.Any MLM can create = their own rules by operating in a dedicated domain which issues domain acco= unts to its subscribers.=A0 But as long as it chooses to operate in a share= d realm, it must accommodate the needs of others within the shared realm.DF=
-------- Original message --------
=
From: Dave Crocker
Date: 7/18/20 9:32= PM (GMT-05:00)
To: "Murray S. Kucherawy" =
Cc: IETF DMARC WG
Subject: Re: [dma= rc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security cons= iderations
On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote: > At some point in the past, Gmail decided to show the email address > only unless that address was in the recipient's contact list, or if > the recipient had replied to that address previously, or something > like that.=A0 In those cases, the RFC5322.From address was trusted, and > so the display name was shown.=A0 Is there logic like that still in place= ? If end users do not reliably make trust decisions based on /any/ of the information in the rfc5322.From field, then how is this question important.=A0 It seems to be seeking precise data about something that isn't even secondary. The persistence of thinking that end users are influenced by trust indicators is pernicious. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --05e67c83495e4a4fa89868be3846e97a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Your comments mply th= at for non-MLM messages, the only purpose of rfc5322.From is trust.  &= nbsp;A related action would be attribution:  after an attack, whom do = I blame?  Domain owners do not want to be attributed to someone else's= crime.

But obviously, there are other purposes, such as se= arching and sorting.   These also depend on accurate values. = ;  Consequently, spoofing affects multiple  functions which are i= mportant to domain owners and message readers.&nb= sp; 

= You asserted again that nearly all MUAs hide the From address, then ignored= contrary data.   Gmail and Outlook have significant user bases.&= nbsp;  No one has identified the long list of MUAs that hide, or indic= ated the market share of those MUAs.

What has also= not been explained is:   why it is an uncoscienable burden for M= LMs to use rfc5322.From addresses of the form user=3Ddomain@MLM?  Any = such attempt is weakened by your assertions that From matters to no one.

Any MLM can create their own rules by operating in a= dedicated domain which issues domain accounts to its subscribers.  Bu= t as long as it chooses to operate in a shared realm, it must accommodate t= he needs of others within the shared realm.

DF



-------- Original message --------
From: Dave Crocker <dcrock= er@gmail.com>
Date: 7/18/20 9:32 PM (GMT-05:00)
= To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF D= MARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Respons= e to a claim in draft-crocker-dmarc-author-00 security considerations

On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> At = some point in the past, Gmail decided to show the email address
> onl= y unless that address was in the recipient's contact list, or if
> th= e recipient had replied to that address previously, or something
> li= ke that.=A0 In those cases, the RFC5322.From address was trusted, and
&= gt so the display name was shown.=A0 Is there logic like that still in plac= e?


If end users do not reliably make trust decisions based on /a= ny/ of the
information in the rfc5322.From field, then how is this ques= tion
important.=A0 It seems to be seeking precise data about something = that
isn't even secondary.

The persistence of thinking that end = users are influenced by trust
indicators is pernicious.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___= ____________________________________________
dmarc mailing list
dmarc= @ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--05e67c83495e4a4fa89868be3846e97a-- --b810581c61a84b17844412b76c8e9b28-- From nobody Sun Jul 19 05:40:26 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 79BDB3A043E for ; Sun, 19 Jul 2020 05:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 EKbFRmhrSRoL for ; Sun, 19 Jul 2020 05:40:23 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513973A043A for ; Sun, 19 Jul 2020 05:40:23 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id k22so12195462oib.0 for ; Sun, 19 Jul 2020 05:40:23 -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=+IMdLFT2B9yr7lbHNlVkAFFUj7uEffv5pgDQeMxunMo=; b=jaN0ZkrxqPx0BlmfL44zs0760A0ZwEUc83avWa0jOZQjKUwr2ud71bb0TCf2Db7SqC zt6Tkhg+hQh9TqGR9/+X2k5Rp7H59+WRIP1VPa156Z6ODvK2ahGfJcmHAPaZFIpfWTJr wC8KCKsi3FE5rRyA+UJOjuj0ug/IopndNWmZorCT9rkh2U2f5LG6uxeX4N3WPMC57sVe bHrT3l/pG/aiLTEv7YhvK1P72FjWBiZXbqlSrcZuOL75SK7rw5juKeLi/XxXDiJGqBMw Ei2UF9kgnBi0lh24WcCrJbaqj2xyRRkFanuwYO1QRj1OIzilurYjd5SMME8lOtFXzSVn aZhQ== 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=+IMdLFT2B9yr7lbHNlVkAFFUj7uEffv5pgDQeMxunMo=; b=KwIGAOQ7GEZfnpKQmD6cxBdK7zBLbGvUXMfQ8jVu8MFp43au1dnYXz1KxOvNfZxrWX 9cGdsEbm1WLUj0YcOkHqQyOB06OIk+Xb4RCONFAxoOYBowzRmTBc7rcx+Ky04HbOtSnj Y9kx11aQFcMRoxXdN7RDLOg5VxRvgJwxO0b+rwuUkVDREq8ggBEmIbX2efswg5AlCMwz zZn5pleGUJP9bjvpaLXp9HJuqpL+RgNJ9okcgyTv+mePp22XxpVh62rsIEkdi6tmJcWt hcot4600qDY3AddbK56i3xVqjLb3UVzrsBz7djzLJd2N+RtdP1OwpVj3oXGu2bbjejzW VriA== X-Gm-Message-State: AOAM533ermuu2FVyiOulwm2SGn1orP2idRIw8aQu8QzXChEfBL2a7bxL XYIx+r7xcFwQRt7TDmPcQR9zmQpaZ84= X-Google-Smtp-Source: ABdhPJxQPLpQBbUlzaAdemYMvzMHngez4iMIW9jQLPVgZkOX5hmABTxcEE36UF3QFKi33j4gyupxNQ== X-Received: by 2002:aca:5a41:: with SMTP id o62mr14843107oib.87.1595162422358; Sun, 19 Jul 2020 05:40:22 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166? ([2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166]) by smtp.gmail.com with ESMTPSA id s4sm3531885ood.45.2020.07.19.05.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 05:40:21 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> From: Dave Crocker Message-ID: <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> Date: Sun, 19 Jul 2020 05:40:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 12:40:24 -0000 On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote: > At some point in the past, Gmail decided to show the email address > only unless that address was in the recipient's contact list, btw, I just logged in to gmail's web interface -- I normally access via imap -- and it is only showing display-name text.  No email address for any of the messages.  As far as I can tell, I have no address book at gmail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 19 07: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 EE22A3A07FF for ; Sun, 19 Jul 2020 07:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZoJBiyk4z0ty for ; Sun, 19 Jul 2020 07:46:51 -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 E65433A0475 for ; Sun, 19 Jul 2020 07:46:50 -0700 (PDT) X-ASG-Debug-ID: 1595170008-11fa3107a811940001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id bYVjx3yd3w5IPg4G (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 19 Jul 2020 10:46:49 -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=from:to:subject; bh=RvVPhvGzhFCsP9vd6DlwTmYC/6yxcfiABP1dPrbEl+A=; b=K/3f8QGc5jyhg9/Aq377NBT8Q691fDFS7Ed+HD3uRmOJwquz2+axmPVPz10F0REYG lzTh6F+K1+iqazHA8BInwJQ7MiEmyzPBvA27AX/i0b68sfz3e+VZw3gUrufkJf6Fx r34rgvKL94kSiMSxKEoF8X1mk16ASmb+NIKzjTx4Y= Date: Sun, 19 Jul 2020 10:46:39 -0400 Importance: normal X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations To: IETF DMARC WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_240386616361700" From: "Douglas E. Foster" X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595170008 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: 562 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.45 X-Barracuda-Spam-Status: No, SCORE=2.45 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_TG383d, HTML_MESSAGE, HTML_TAG_BALANCE_BODY, MISSING_MID X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message 1.50 BSF_SC0_TG383d Custom Rule TG383d Message-Id: <20200719144650.E65433A0475@ietfa.amsl.com> Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 14:46:52 -0000 ----_com.samsung.android.email_240386616361700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzLCBHbWFpbCBpcyBhIHdpbiBmb3IgRGF2ZS7CoCDCoFVzZXIgaGFzIHRvIGhvdmVyIHRvIHNl ZSB0aGUgZnJvbSBhZGRyZXNzLCBpbnN0ZWFkIG9mIGZyaWVuZGx5IG5hbWUsIGV4Y2VwdCB3aGVu IHRoZSBUTyBkb2VzIG5vdCBtYXRjaCB0aGUgcmVjaXBpZW50LgpudWxs ----_com.samsung.android.email_240386616361700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2Plll cywgR21haWwgaXMgYSB3aW4gZm9yIERhdmUuJm5ic3A7ICZuYnNwO1VzZXIgaGFzIHRvIGhvdmVy IHRvIHNlZSB0aGUgZnJvbSBhZGRyZXNzLCBpbnN0ZWFkIG9mIGZyaWVuZGx5IG5hbWUsIGV4Y2Vw dCB3aGVuIHRoZSBUTyBkb2VzIG5vdCBtYXRjaCB0aGUgcmVjaXBpZW50LjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBz dHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPjxicj48L2Rpdj48 L2Rpdj4= ----_com.samsung.android.email_240386616361700-- From nobody Sun Jul 19 08:04:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F183A0953 for ; Sun, 19 Jul 2020 08:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 LfnbtSWnQd9t for ; Sun, 19 Jul 2020 08:04:18 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 ED0CA3A094B for ; Sun, 19 Jul 2020 08:04:17 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id 5so10272072oty.11 for ; Sun, 19 Jul 2020 08:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=INU0RQtCuXBc7V3VRIUBDx395dSz19KLyQl6K8d55w8=; b=Sj5PAWcgfbllS1pwU+NF7jzpkIZazpRrjWehP11xlLjpgrz9uAWBnKrrBk3gUGy2/y 8pBOJKvrC6xJDO2FgJCYnzTYlz5EMr7fNvZMjeiZCFUfC5wpDKEQcGVJaiW1pwibl3H+ aHtf+WLh7/rFWVNaEHRdJe4kO5WVBUotbm00gXyEiOX+mERzD/7LiAEmakqqANMSS7dq cEFofx/Yzh0LicEokCGHQYKJOZBsSWBsQvp3a+6QoDRz+pZPmhLuZ9c+acctAlJphCOV IZtcpd0lQpSpjyS6+ntvC20UIG9QWbIPp00bvvLKcy1EpNLOM3Oj3KymtQ7I5wQ/Hf6W Ka2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=INU0RQtCuXBc7V3VRIUBDx395dSz19KLyQl6K8d55w8=; b=CrROWRprTyRxxY0I0QKE9aWWZ3TAh9fbkkYresuYv4aFrfrf/PKQ4vcCW/3UYxOA7Q 7svOnTspVL0ATO/C7MmwqvOS2UDP52W3KCYC2PhBTi5qTah1GhvhbaP8gvbJqIq0k0b8 WLo95wcTBMOQlFzf1aMLSMWTdZ+CpMQbFYPKepyWM3utMAY83bHeBStZrfcUP9RW9xqZ zX5Kb+8sN63ajjqwdHbLCopacPJ7fqltuv4at6skgagbs9WoqxgEBYFtfQTr8FbUHl3l E74JCoamYN6welwHWLZsxI1XWjJMs98JIzSUZmkINmjlUnGZ+R9Tts1NwJUdtsJ51cfh RP3A== X-Gm-Message-State: AOAM532DhD4BOVosMVJxKW0CsMP69rroBlWALqxSSOYevJnvA965HCBV iMOwdgIz8vfKnLJOZ2YnRkk1SEziy80= X-Google-Smtp-Source: ABdhPJzkxLEyEf0iNSxIkr6As96LZb2ubNXLmSePRiUUMLzACzmhXmfjt2JnTDhsxCMStfWsUe/d+Q== X-Received: by 2002:a9d:7515:: with SMTP id r21mr16484514otk.208.1595171057065; Sun, 19 Jul 2020 08:04:17 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166? ([2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166]) by smtp.gmail.com with ESMTPSA id h22sm3516760oos.48.2020.07.19.08.04.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 08:04:16 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> From: Dave Crocker Message-ID: Date: Sun, 19 Jul 2020 08:04:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7666BA205D57982DDC2FC578" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 15:04:19 -0000 This is a multi-part message in MIME format. --------------7666BA205D57982DDC2FC578 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote: > On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker > wrote: > > If end users do not reliably make trust decisions based on /any/ > of the > information in the rfc5322.From field, then how is this question > important.  It seems to be seeking precise data about something that > isn't even secondary. > > > Google strikes me as the kind of place that would make a decision > about what to show users based on Perhaps, but since we don't have their data and we don't have their decision-criteria -- which might be quite different from what is needed here -- then it's probably a good idea not to make assumptions about the utility, nor to put all of the human factors marbles in the google camp. >    I'm less convinced by the notion that all of the RFC5322.From is > disregarded by the preponderance of users when deciding what level of > trust to put in the message's content. That suggests we blindly open > and read absolutely everything, and I suspect that isn't the case. 1. That's not what it suggests, at all 2. No doubt there is a better way to put this, but I'm not thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:  This demonstrates why the IETF is a very poor venue for conducting human factors discussions. Again: There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------7666BA205D57982DDC2FC578 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker <dcrocker@gmail.com> wrote:
If end users do not reliably make trust decisions based on /any/ of the
information in the rfc5322.From field, then how is this question
important.  It seems to be seeking precise data about something that
isn't even secondary.

Google strikes me as the kind of place that would make a decision about what to show users based on

Perhaps, but since we don't have their data and we don't have their decision-criteria -- which might be quite different from what is needed here -- then it's probably a good idea not to make assumptions about the utility, nor to put all of the human factors marbles in the google camp.


   I'm less convinced by the notion that all of the RFC5322.From is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at all

2. No doubt there is a better way to put this, but I'm not thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:  This demonstrates why the IETF is a very poor venue for conducting human factors discussions.

Again: There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------7666BA205D57982DDC2FC578-- From nobody Sun Jul 19 08:08:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175403A095D for ; Sun, 19 Jul 2020 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, PP_MIME_FAKE_ASCII_TEXT=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=u++D+WYJ; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=pXyqu+8r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyX3gRMXkoxU for ; Sun, 19 Jul 2020 08:08:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F7B3A095C for ; Sun, 19 Jul 2020 08:08:16 -0700 (PDT) Received: (qmail 50805 invoked by uid 100); 19 Jul 2020 15:08:15 -0000 Date: 19 Jul 2020 15:08:15 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=c66a.5f1461df.k2007; i=news@user.iecc.com; bh=x79n1STEroYxQgw/GIjdi+pgGJvHlOlUUEYSOC/Bdu0=; b=u++D+WYJmFoJNbCLwNzwcaSYOzEGOQhrxf8NK72IDjKTPatNdZwi+6rRxVqHpa0Z6NDByDALyykj11jOvVRmJXqiZVMwGUIOX20xCELWBCm4ZnsAwD3IAdJLC62rFxj+ku0mFBBRpCMADQZX6Mn+Eupkz5gp/qGUg7bPUsXW9p0wCh84qlhF/F6mH86kDAMBWqIhphr8BdqK8Bt9Tdt9hvj6mUo8PqwGcngayAq6OE/BKPOSN7atRZu+3pCDzSNd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=c66a.5f1461df.k2007; olt=news@user.iecc.com; bh=x79n1STEroYxQgw/GIjdi+pgGJvHlOlUUEYSOC/Bdu0=; b=pXyqu+8rtXPVSrV4WO5lnep1OkUuM9NLXt0uri7lB8iQFUJaivULYUqU7f8Jo9qESV2MolnVFhhQDwi1d4xeV66AWxMNY69jCXIgG/2mYCWgmPdZAyIoo7rrxJoNTFrsYf0/8yd1GyjUL42H6jvFOMjGCUZrn4Ir+wTWjeV0lYcCK/YFQ53wCIDg5Kz1IQyHGaFGFD4peFmTEp3nxr/Tn7AhJWsFNAhVEhByjR6txtnCrtWTFtumhD8hgm0RTpKY Organization: Taughannock Networks References: <20200717210053.674D61D2C431@ary.qy> <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> In-Reply-To: <20200717210053.674D61D2C431@ary.qy> <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 15:08:19 -0000 In article <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com>, Dave Crocker wrote: >On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote: >> At some point in the past, Gmail decided to show the email address >> only unless that address was in the recipient's contact list, > >btw, I just logged in to gmail's web interface -- I normally access via >imap -- and it is only showing display-name text.  No email address for >any of the messages.  As far as I can tell, I have no address book at gmail. I just sent my Gmail account a test message from an address that never existed before, and it only showed the display name in the web site and the iOS and Android apps. This tells us that at least at one big gorilla, the header address isn't something that users see. This leads to two questions, one being why the From address is a better authentication handle than, say, DKIM d=. The other is that if the users don't see the address, why do we care if mailing lists change it? I think I have some reasonable answers, starting with the way it screws up replies. something we know from experience that Reply-To can't fix. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jul 19 08:13:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC33A096B for ; Sun, 19 Jul 2020 08:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 tkExI_HSetVc for ; Sun, 19 Jul 2020 08:13:21 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 5665F3A0967 for ; Sun, 19 Jul 2020 08:13:21 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id j11so12363472oiw.12 for ; Sun, 19 Jul 2020 08:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ErnrGwaYSKvFR2uHqmHcfOTe5elFNFvlmhKfYHP/68k=; b=tg9B2jeeI1inqc8VECgMnvJU36TSCJ67q7h3ZwtQ+H31WQBi8SKRjMraGWBneJOLRX BFyRkEaW/5ti5qsxtBsx8QwwfOBJUH4FPGuYwcNIOM8EYdTmAgCOGXuQO6k09phH1Aud OSxdn+2+KJe1AegiDuwdUJgr+s5QxfdcBkSjgZD6LPa9uTYBYzr4kiJ4iQqBjLqVm4hY iZwyI7cjhCEDi9zcNmDyilAImdwPFSpzuxLGH89w/zBzEeqkLA7v1ybG71B5QN+nCo8D XhkEnsjvPA1a9TXzOtjNMMfa9oXf7l94+J9nYiLbqpKfjSZDAU8rsl8FopcF6oTOkp08 4vLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ErnrGwaYSKvFR2uHqmHcfOTe5elFNFvlmhKfYHP/68k=; b=oH6j8DBZK3wNDMO2Xt6IngbT0hu6jVDnNrvStqqPSs9Yjrj9MYRG2UoAVKghi7PD/t Iiw1cDLEv1fdMea+x+AvuPlbsrsVvlrbWj8D6JaLILESMRE60PvVmISg6oGXIT4IeIfZ AugoDEraDQGrBOwO3HN9Z2/Q0cxFOqgZ4q5F8qvy2Odcwe6rte3qFXNhOYc2QL7UKh5m fAUBlMoMBTXQwcs9GK5i+pORudOseYvD4oF32xSRs16/fkrHWdRFR4oQHPiuOO+DLEKg 8Zx9tXsNHttEvzm4hOp33Oi6KTljEFi27hWxjEONa3Y0eDt3AtY+15ZnPWJvBShEeptX XNSw== X-Gm-Message-State: AOAM532fmpsG85Aqd7bt517vAO/7WnIn6/+0s8kTeDi9q64+YBgfO5Tq QkljXhIl21eeE4grPEWnMsNkVdaqGrw= X-Google-Smtp-Source: ABdhPJyv7+G42v/ZcYwOf0FaUWU1KZerLKXmt36kN+6OBgAYJosFEPtjNom6sRIeKCGS7+tAtT8o3A== X-Received: by 2002:aca:1016:: with SMTP id 22mr14016780oiq.66.1595171600499; Sun, 19 Jul 2020 08:13:20 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166? ([2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166]) by smtp.gmail.com with ESMTPSA id n141sm3463077oig.24.2020.07.19.08.13.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 08:13:20 -0700 (PDT) To: John Levine References: <20200717210053.674D61D2C431@ary.qy> <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> Cc: dmarc@ietf.org From: Dave Crocker Message-ID: <6eeee2ed-1112-335c-6bc2-b426de97f709@gmail.com> Date: Sun, 19 Jul 2020 08:13:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 15:13:22 -0000 On 7/19/2020 8:08 AM, John Levine wrote: > This tells us that at least at one big gorilla, the header address > isn't something that users see. This leads to two questions, one being > why the From address is a better authentication handle than, say, DKIM d=. I think the possibility of d= hasn't been considered seriously. I'm not going advocate, but it's worth thinking about this a bit, just to make sure we understand it's implications. I've thought (assumed, recall) that From: was chosen because it is the only address value in email that is required to be present.  So it gives you a domain name to start from and then look up for a DMARC record. There is always that domain name, even when there is no authentication information. It's only possible to use the d= if there is a signature.  So a downgrade attack would succeed by merely removing the DKIM information. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 19 08:20: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 D76353A0978 for ; Sun, 19 Jul 2020 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=YnIFFX5z; dkim=pass (1536-bit key) header.d=taugh.com header.b=Lmbygkf1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oht2Nmk7yxQ8 for ; Sun, 19 Jul 2020 08:20: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 129793A0974 for ; Sun, 19 Jul 2020 08:20:08 -0700 (PDT) Received: (qmail 56547 invoked from network); 19 Jul 2020 15:20:07 -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=dce1.5f1464a7.k2007; bh=2AW5PSGNNgdZ/6lqdX5SepB2ByhfuG6Bx2vEfYscw9Q=; b=YnIFFX5zhSMCTNxayh7BpCAx0IFVcOtFBErX1x3DvZkeEv2RoQCnbYmD4o5VpuiwFjyPsV+Dvm2BPAhwUH5kJgX6xupjJjT7t/AHHVCL54KELNvhoBhbNDPPpg2JdTssxdmL2+JVostMMd/eL/hhXh6clpbeHydAqNdfnqlJTZqroijBbD2COVZpMGRzfdS9+cIK9M+Lif+5qvhD9LT+rD8cLgdI/Ln41bP2RD+jvAGvM1SCSOmb0EB8tVYFujIJ 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=dce1.5f1464a7.k2007; bh=2AW5PSGNNgdZ/6lqdX5SepB2ByhfuG6Bx2vEfYscw9Q=; b=Lmbygkf1wSb8NVC1izl5e44tHIhW8518bpZGJWXfA17SWlzXXqKQSW/ALdWucvyE4W1gRZXgqOUX0dTkO4mKemRn7l3Uw5MYHhD+KZBQJLbe4VXWt5wYMg1MqUY29RpiqmER95YN/kuRLLhyVQjELBvOhRmrV2fUT5idkvhj/z4WAyU67L3uMHpqUAqemig8zkCuzozsb1Mqwm7FIIMfmg1Cnb25ssL25afsTQ/kYLahzKgPQmLNNDRO3KgW2z4g Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 Jul 2020 15:20:07 -0000 Received: by ary.qy (Postfix, from userid 501) id 09C7E1D39711; Sun, 19 Jul 2020 11:20:07 -0400 (EDT) Date: 19 Jul 2020 11:20:07 -0400 Message-Id: <20200719152007.09C7E1D39711@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: johnl@taugh.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] no from addresses nowhere, Response to a claim X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 15:20:11 -0000 In article you write: >I just sent my Gmail account a test message from an address that never existed before, >and it only showed the display name in the web site and the iOS and Android apps. Took a look at the mail programs that come with my iPad and Samsung phone, neither of which show the From address either. You can eventually see the address but it's not easy, tap on the message to open it (thereby enabling the phish in the message of course), then tap on the name to see the address. R's, John From nobody Sun Jul 19 11:08:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8C63A0869 for ; Sun, 19 Jul 2020 11:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrKJc6SUnnIp for ; Sun, 19 Jul 2020 11:08:18 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237D13A0867 for ; Sun, 19 Jul 2020 11:08:18 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id b13so4351955uav.3 for ; Sun, 19 Jul 2020 11:08:18 -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=oWfv39dnP4A1MUdpu96wkIbq2mRdtfkuc8S5WcRahc0=; b=KrqCiLln7XPKXnQrPYzc2Z+XfUw1IPTIZZommdI6llsZtWdsver9Lv7SZ4dDqUvoX7 QbmbESUGuqpzptlG4Ld1eYMefwlLDq9DBfZuQC2+lx1BUAXgMKpKWdy6MbXSyScudFIa e7CYGGreEyChIb3v0zsWc0moyYL0k6ezTPr3w6PYm3YlZJ0QJlsHmMPr0T3q0iJbhG/0 jIZF4Ei0929k3IKOE2mIN3f9l6gukXBgvr9/OoCZe7GMA0M9RbxLuMvMPGPijCSSwV5W EX+HlGsBH8e3+wMNDZY4nwb47bwecV5KM9qjuDl7oly4kRPvKtpOPIQcjHaRnEKtel3W pxvw== 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=oWfv39dnP4A1MUdpu96wkIbq2mRdtfkuc8S5WcRahc0=; b=nQHFFfgeyjlVknF7BfW2rVeT2CmNyUW4eHJKuP0ILcViLjoE1QVqr1rMMuGr0JRXOC 7BviB/EekYqysHjC03yjb4VlRU1Dz0Sec8XMBjigzdkwm4+4b0qnfL07tczzerFdqGPI 0Wur/rAytqTjhoIus+R5tGUnACJ5/c7Bz99UL7DkySODHQ6AUGMF2FQyl/Kxv3p26lCT VBBUtVk2AclSWmsts82h9rmgdjxEsvL6ucanNz1Vqo3l4Ut0haYmt6O+v9QWG8VzLjDQ UZwKykrLsBDCHQUaydfLgNEyPk4eRoSN4CVbvgDJ6x4t1tnSiEclpGG8QdVR6TkSfd4T 8SXQ== X-Gm-Message-State: AOAM5314A6rNrQbQ6MLm9KhThw2VIMB1tYVmpD2/jRb95CegS1xkBYuz DrOogPENc1UyAuErJF66KiV+kCl4kVyYL0QjNqU= X-Google-Smtp-Source: ABdhPJzuNd+mPfkS53MOJTxZo0RlHVajztaLAKTP/yUWsvR3IOb+Ohj1joJN5OXqcZouuyEtXhrWyJ3x/+jAqGZlzZ0= X-Received: by 2002:a9f:2a8e:: with SMTP id z14mr14036266uai.47.1595182097038; Sun, 19 Jul 2020 11:08:17 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 19 Jul 2020 11:08:05 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003f00cb05aacf4604" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 18:08:20 -0000 --0000000000003f00cb05aacf4604 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 19, 2020 at 8:04 AM Dave Crocker wrote: > On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote: > > On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker wrote: > >> If end users do not reliably make trust decisions based on /any/ of the >> information in the rfc5322.From field, then how is this question >> important. It seems to be seeking precise data about something that >> isn't even secondary. >> > > Google strikes me as the kind of place that would make a decision about > what to show users based on > > Perhaps, but since we don't have their data and we don't have their > decision-criteria -- which might be quite different from what is needed > here -- then it's probably a good idea not to make assumptions about the > utility, nor to put all of the human factors marbles in the google camp. > Certainly it's only one data point, and as I recall it's the one that got the most discussion during the early DMARC work. That's what made me think of it. Data from multiple sources would of course be better, and I'd happily solicit other possible sources. My employer isn't in the inbox game anymore, so I don't have any of my own data to offer. I agree they might be quite different, but they also might not be. Don't know unless we ask. > > I'm less convinced by the notion that all of the RFC5322.From is > disregarded by the preponderance of users when deciding what level of trust > to put in the message's content. That suggests we blindly open and read > absolutely everything, and I suspect that isn't the case. > > 1. That's not what it suggests, at all > Then I don't know what else you might mean by "end users do not reliably make trust decisions based on /any/ of the information in the rfc5322.From field". What other data exist upon which to make trust decisions in the display of a mailbox? > 2. No doubt there is a better way to put this, but I'm not thinking of it, > and this isn't just my second thought on the challenge, but quite a bit > more than that: This demonstrates why the IETF is a very poor venue for > conducting human factors discussions. > No argument here. > Again: There is quite a bit of experience demonstrating that providing > trust indicators to end users does not produce reliable -- ie, useful -- > decision-making by end users. > We appear to be talking past each other. I wasn't talking about trust indicators, but rather whether the RFC5322.From domain is visible. I don't have any reason yet to think trust indicators are effective. -MSK --0000000000003f00cb05aacf4604 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 19, 2020 at 8:04 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
=20 =20 =20
On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
=20
On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker <<= a href=3D"mailto:dcrocker@gmail.com" target=3D"_blank">dcrocker@gmail.com> wrote:
If end users do= not reliably make trust decisions based on /any/ of the
information in the rfc5322.From field, then how is this question
important.=C2=A0 It seems to be seeking precise data about something that
isn't even secondary.

Google strikes me as the kind of place that would make a decision about what to show users based on

Perhaps, but since we don't have their data and we don't hav= e their decision-criteria -- which might be quite different from what is needed here -- then it's probably a good idea not to make assumptions about the utility, nor to put all of the human factors marbles in the google camp.

Certainly it&#= 39;s only one data point, and as I recall it's the one that got the mos= t discussion during the early DMARC work.=C2=A0 That's what made me thi= nk of it.=C2=A0 Data from multiple sources would of course be better, and I= 'd happily solicit other possible sources.=C2=A0 My employer isn't = in the inbox game anymore, so I don't have any of my own data to offer.=

I agree they might be quite different, but th= ey also might not be.=C2=A0 Don't know unless we ask.


=C2=A0=C2=A0 I'm less convinced by the notion that all o= f the RFC5322.From is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at all

Then I don't know what else you might mean by "end users do not reliably make trust decisions based on /any/ of th= e information in the rfc5322.From field".=C2=A0 What other data exist = upon which to make trust decisions in the display of a mailbox?

2. No doubt there is a better way to put this, but I'm not thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:=C2=A0 This demonstrates wh= y the IETF is a very poor venue for conducting human factors discussions.

No argument here.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Again: There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

=
We appear to be talking past each other.=C2=A0 I wasn't talking ab= out trust indicators, but rather whether the RFC5322.From domain is visible= .=C2=A0 I don't have any reason yet to think trust indicators are effec= tive.

-MSK
--0000000000003f00cb05aacf4604-- From nobody Sun Jul 19 11:10:02 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 E702E3A0873 for ; Sun, 19 Jul 2020 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqmFJ0y68EhY for ; Sun, 19 Jul 2020 11:09:54 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 915503A0870 for ; Sun, 19 Jul 2020 11:09:54 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id p6so4344322uaq.12 for ; Sun, 19 Jul 2020 11:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ObCO7zyi4Y9kWf4Q5wEN9lSb0juR9gZqe5BVpuH3g/g=; b=cjqGdS4ejPjP8X0KOtnZhfYcNftZoCXUM1hVnjqRMZN7ePedZemDWZBfjNcjs1Gzfa MEMPUDetOYIJNnTJiDhQWHYaFfnjG8abuzC7CMbV4rlCE6bFA75T3Esjy+klwxtHhbuM TOjI7LGQeoHn7fgqAlF6BXSCJzC+LNPGHP1tq7MUNIvuEyVVXPvxN7XyMjtPFUm4E8g+ WJETjvrzlnIwBehVjkFw8xFYsmRbdAOXIG17F3R1R8xlY9HtDZjXU+YppGR/TCWByZAO 2cKaWY10S28ONMf7tCibb0dMzPuMb5KOWcJXy089A6layEGUS1RycwaxPwLD7Ab/2l9Y PkTA== 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=ObCO7zyi4Y9kWf4Q5wEN9lSb0juR9gZqe5BVpuH3g/g=; b=L3wkzINQ3Bw0Pm1iggOctOW0bfp/9a59RBwSq3g4DEwTVV3Jl13m8GgiNzHKTIgCzZ uxRnMPwblS/PynyTe2nhlGeSg0Dk8lYcRNqufVjFtTYVIMfjbxIqQv2z1AOjN5czv7fs yL+v+paMW/eioHsIuBJcLTWGL8vQO77GVCQ7ohFgqKV5j/H+iTEH7s/PX8QFG949tvlt 7lM1j/k7ln0jUVlq5qIW+A8UDXggMi7+Pcuf96ZakL5muuKxaWLX+TtmaloLbboA8rWM FGqdfRFNoC15CjTETyydeCrhPrXi7sq0DbI2ysJXlM4uIruWk4pNmllfGa1Qu7n1fQq2 8W2w== X-Gm-Message-State: AOAM533RI0mqJWkJuFFhdA1NiXPdTtzYlx21LSouQf+uL/oPaL5RNAcm o3P62O5FS9Bkq5RkGjqY9fhrJt1u1w5cTpfkJdj9NQ== X-Google-Smtp-Source: ABdhPJzOsBywQVgTBWKDyADZgNFJmIAWw6u6sq2ikye3FAySDw4zAcNadUT3pvlv3Gpza8lB8RzBnmMmtEuj/2rnZ40= X-Received: by 2002:a9f:24c2:: with SMTP id 60mr14151087uar.67.1595182193377; Sun, 19 Jul 2020 11:09:53 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> In-Reply-To: <0bbf7999-0b40-401f-24d0-09eb1c8ec2d4@gmail.com> From: "Murray S. Kucherawy" Date: Sun, 19 Jul 2020 11:09:41 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fd07a305aacf4ba0" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 18:10:00 -0000 --000000000000fd07a305aacf4ba0 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 19, 2020 at 5:40 AM Dave Crocker wrote: > On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote: > > At some point in the past, Gmail decided to show the email address > > only unless that address was in the recipient's contact list, > > > btw, I just logged in to gmail's web interface -- I normally access via > imap -- and it is only showing display-name text. No email address for > any of the messages. As far as I can tell, I have no address book at > gmail. > Same. That's why I attempted to invoke Brandon. -MSK --000000000000fd07a305aacf4ba0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 19, 2020 at 5:40 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> At some point in the past, Gmail decided to show the email address > only unless that address was in the recipient's contact list,


btw, I just logged in to gmail's web interface -- I normally access via=
imap -- and it is only showing display-name text.=C2=A0 No email address fo= r
any of the messages.=C2=A0 As far as I can tell, I have no address book at = gmail.

Same.=C2=A0 That's why I att= empted to invoke Brandon.

-MSK
--000000000000fd07a305aacf4ba0-- From nobody Sun Jul 19 11:14:02 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 70EAE3A087D for ; Sun, 19 Jul 2020 11:14:00 -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 xvNOE0Ke3fj7 for ; Sun, 19 Jul 2020 11:13:59 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 38F513A0878 for ; Sun, 19 Jul 2020 11:13:59 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id q15so7375097vso.9 for ; Sun, 19 Jul 2020 11:13: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=n4e1JFzX39ESEgWPFiowEfoU4SZatgRQ3tZSXQq4qiw=; b=FU10KzeNXLmWwN1pssJmu8Yi4l1p5UPzU+sVz0fxz30dliVX5gCLE1jgLavOZkHM9u OvjrOiLyX85KvVhNdsRV6xtx5x3Aav3VTyZqOpjSeZrrl7Av3q/aL7x/TvpsITwvfCpw 9ogJYAjb22d0xjMR1kS7rk5My1VztrnpuU7KNB4ttFfQPnuV9i05lyMkPceRAfDKQeuR N6a6v2TlFMspHYQm1AyqRbE8HYZ3dL5lIxoeXMiD80PKz0EsgfqxeTgcCdORZw3vcYyZ kkK4fyjmbHFfCPwRv3CIpyJiFEBMMGS3nTBDVhHtYPTtRmtAr8iDM5gRztUZo0hZ8gGX s36Q== 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=n4e1JFzX39ESEgWPFiowEfoU4SZatgRQ3tZSXQq4qiw=; b=LhwY3Y2zw2y4mRVwMmLC2s+p9F0tIOOMKv8V1CvdoFaJwbj9ecJ8RaKNU17xEnF4xA mZv/WirlKwHYhZVMF6QydhSkgl0fZmVKmXgfgRGAvozbJyuj+/bCDHBwaNLvUbXKxjJM 8rglJJt5NUCj/NnjMPZRRVq2ra+5USo+F3Kw+M12pnljjTMJrIKQMWnu9RdAlb3Ket+r K+YXKO1yARR6LXBve5dQ1UIbQ43edjA+IeGtu/STFS18sGvcQNb0PhZhBty1rTz+AIuB iuEYUthGvoW2Hh1usTvWBkobICR3aLGEFRyXnsT7VqOH/0nQ9oAqLnxM0VqQNbkUfyfE gJmw== X-Gm-Message-State: AOAM5311ZJaI7qRVsIxlMABFju0RMdZjXBGsDrj4yYJqorahUTIdnyrj ls1L65GwzuVZFwMBrrYsRUE2G7/hWbi+KXIrRLT31Q== X-Google-Smtp-Source: ABdhPJzPGnONWyFyXZmAKk6GujRXqMNxcQEkSX+QZvyfRjwy8VgFRZVACFDWZAlluHKsnahgSG+8aTyyZNnFBdb422I= X-Received: by 2002:a67:bd09:: with SMTP id y9mr13165622vsq.13.1595182438178; Sun, 19 Jul 2020 11:13:58 -0700 (PDT) MIME-Version: 1.0 References: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> In-Reply-To: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> From: "Murray S. Kucherawy" Date: Sun, 19 Jul 2020 11:13:46 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000094647b05aacf5a5e" Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 18:14:00 -0000 --00000000000094647b05aacf5a5e Content-Type: text/plain; charset="UTF-8" On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely wrote: > > Still unresolved, IMHO, is Dave's point about whether the RFC5322.From > > domain truly matters. > > While the opinions of big players are relevant, you yourself mentioned > that > they tend to follow DMARC design. Sorry, I said what? -MSK --00000000000094647b05aacf5a5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 19, 2020 at 3:14 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
> Still unresolved, IMHO, is Dave's point about whether= the RFC5322.From
> domain truly matters.

While the opinions of big players are relevant, you yourself mentioned that=
they tend to follow DMARC design.

Sorry, I = said what?

-MSK
--00000000000094647b05aacf5a5e-- From nobody Sun Jul 19 11:33: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 40B253A08ED for ; Sun, 19 Jul 2020 11:33: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 hS2FRdB4vVtH for ; Sun, 19 Jul 2020 11:33:50 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBEC3A08EC for ; Sun, 19 Jul 2020 11:33:50 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id e4so12663784oib.1 for ; Sun, 19 Jul 2020 11:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=frtl2LCo0qOmUMRlRdjdbwM165al3u3NG9UH+jMbLIE=; b=nyOCfVeXnlT8oc9mvU9H6NRB1wX8h9coJLD2W22Le+IrxJvjJCLdOI8LrBiMtOSkAR /zdMeFgiZYDyNKRfUSLSzS3BzzXbRg/lIUSffuK9/7qsAmjL5JnwNUdYgUYf8kWkhEk7 oH8fKTtm0qNoHM2gLOwDOsgg2dltyhWvrc1bbDp2LrmIhXaIdLmLSV785kdiYnlhWI6A JBHKzmpslUwaoe3ELqaRiE5pZM5stl067NqTpG4nRwov1DvICRHlyNPcLWQOlpvB7ErC Bp5cHC1nHzIXJl8U+PZo4rgpd8Lfm02VSZID/MI49N5s8ZgZZiPedhDvDmgagdrWKQns s/AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=frtl2LCo0qOmUMRlRdjdbwM165al3u3NG9UH+jMbLIE=; b=mxESnmPF+qYj8doZC3lsthCGBmyqATAa/4jh6GhluNnPdnSZfIUmU5IImnTs4AwU54 0R9YrYXF/Aj9UhJKgJ8dZjaTNiq9NgYn9C+mrf+1ymqxGb8NjxWtSfrZZzUwKLROn85J Ejw3HnkLM5zcfy03MMU4Sr4E6ZQKBDEMAN8w+64Ot+5Usiw+5w8muxckfsFk/tKKDDSG /jmD1Ni3uFrHaZKEeBUqIrSniqXsg5U1u+QgTLDX2OwRV3F/lBwDUNY2zyU8KU1f/fEj JJyAwCH0AIbW1jIcNI+MtGpnDcS9X7+fZCCPEs2KV91Hq25ehim6wNye+51QFjMhbtWb DEsQ== X-Gm-Message-State: AOAM531drzfWcZXUNMl2znxZd+IA01fOf6wmMTDV8SE2g4cfENv7rHr6 1IA7+RPeOp5eCLuIZFX05NOR/0jzuXw= X-Google-Smtp-Source: ABdhPJx7ZfT5KV5yOnIgtM4LRjOVzBydxIGDXARwyYyz58+YCR/fIL7Km4Kncf75kAS9G/6OYy7OIw== X-Received: by 2002:a05:6808:6ca:: with SMTP id m10mr15619782oih.85.1595183629116; Sun, 19 Jul 2020 11:33:49 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166? ([2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166]) by smtp.gmail.com with ESMTPSA id o23sm3125986otl.0.2020.07.19.11.33.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 11:33:48 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> From: Dave Crocker Message-ID: <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> Date: Sun, 19 Jul 2020 11:33:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------712D6B056CB044085E6782F0" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Jul 2020 18:33:51 -0000 This is a multi-part message in MIME format. --------------712D6B056CB044085E6782F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote: > > gain: There is quite a bit of experience demonstrating that > providing trust indicators to end users does not produce reliable > -- ie, useful -- decision-making by end users. > > We appear to be talking past each other.  I wasn't talking about trust > indicators, but rather whether the RFC5322.From domain is visible.  I > don't have any reason yet to think trust indicators are effective. > The view that the From: address, or domain, or Display-Name is used, by end-users, for assessing the trustworthiness of a message means it/they are used as trust indicators. The track record is that people are unreliable at this. There is quite a bit of distance between 'unreliable' and 'blindly open and read absolutely everything'. In any event... The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users. Really.  Nothing. To the extent that anyone wants to make an affirmative claim that end-users /are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*) By contrast, say that this work provides input to a receiving filtering engine made the work easy to explain and understand and defend. d/ (*) I've seen one posting here or somewhere else that noted that letting bad mail through can lead to end-users being deceived. I'll claim that while true, it is not relevant, since the behavior happens after DMARC, and the like, are relevant.  That is, DMARC, etc., do not inform the end-user behavior. -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------712D6B056CB044085E6782F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote:

gain: There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

We appear to be talking past each other.  I wasn't talking about trust indicators, but rather whether the RFC5322.From domain is visible.  I don't have any reason yet to think trust indicators are effective.

The view that the From: address, or domain, or Display-Name is used, by end-users, for assessing the trustworthiness of a message means it/they are used as trust indicators. 

The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open and read absolutely everything'.

In any event...

The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users.  Really.  Nothing.

To the extent that anyone wants to make an affirmative claim that end-users /are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*)

By contrast, say that this work provides input to a receiving filtering engine made the work easy to explain and understand and defend.

d/


(*) I've seen one posting here or somewhere else that noted that letting bad mail through can lead to end-users being deceived.  I'll claim that while true, it is not relevant, since the behavior happens after DMARC, and the like, are relevant.  That is, DMARC, etc., do not inform the end-user behavior.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------712D6B056CB044085E6782F0-- From nobody Sun Jul 19 17:05:02 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 449C03A0BAB for ; Sun, 19 Jul 2020 17:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LStMpNAEeOY for ; Sun, 19 Jul 2020 17:04:59 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 896173A0BA9 for ; Sun, 19 Jul 2020 17:04:59 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id j186so7587755vsd.10 for ; Sun, 19 Jul 2020 17:04: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=Lfr+Y4NRkMsQztSyxcUzb6k+PZPLd64gi6a0Cn5VdAE=; b=Wn2sTeJsSoXnQvIbk6UUhr/UKhh9Og2knSAXyxtDSS3ybY9LFYzVH7RrZ/sUyn09D5 JxcoKR9GUtGBdwMwj7DmyiKzQ3gpab+Zz1nTs2uSPsvRDwo48NSd0kUjC3xwj+BiuEu0 UABnOUvpsxny6I/VxXhu/4tC1ihujYxqO7lLo8UUx8qKtqiwcK7TMXpv+vw5RXZ6DxE7 NxQaiLDyUjx7P1ZJt0bsTIdw8iFWZwSyGn4lPZeBQgr5sEiTAptaZB0da4C11wqDD7tG /RpzNOCaLNu8RspqZchZY4aftAxj0PoYkZkKEnkqv34Ozoh0YJrjA15Yp4ftAlerUCL8 QSIA== 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=Lfr+Y4NRkMsQztSyxcUzb6k+PZPLd64gi6a0Cn5VdAE=; b=i4a1wDL6pM18MhNov3DkBlQM5BAXhZOuvcqfjK1yc20NFSsD4TZwufGlHywm1JxVfT oaPitYO3FA4uD3zXHwmFpdEOnTcDUl1/fBE6fz78qKDhyKQo4IiYH4wZVBfWvGRlGe7m wMMucM5zwBLU8+w/fZPzQamch79gjil7wXGUn/vwfOVmSkXsqNyKAYGusxKJ87UCicWg O+/NBNLErXjnvmEQm9ep3xaOgjYR0BJjNpNoyTMI0y5IMYm3EAJ3jdiIejzOSeRNOzHs x3XlMab8a1N1QS2NGBAlm4YXWp5H4o86Q6QPlOf+WrV5Bu5ELDZCPDQVLIRrgrAH4IC3 St5Q== X-Gm-Message-State: AOAM5309JA3utGh7gXP74O7sBnBOupN4DQ/2GHf7q6mJk9JGcG0LzEWH X4Nz0Ppc9mO7W8kq9k89+nAq3Y1OqFD7eWb2g+0= X-Google-Smtp-Source: ABdhPJwTQg6hzTEKBVaGFZbsI7/fiSSfFdH9uVbwAcZ7/ZXkhsHg3iNsEfwCc5XBf3qSgafpbjfB71aQDlQH+mm9LKQ= X-Received: by 2002:a67:bd09:: with SMTP id y9mr13713734vsq.13.1595203498424; Sun, 19 Jul 2020 17:04:58 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> In-Reply-To: <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: "Murray S. Kucherawy" Date: Sun, 19 Jul 2020 17:04:46 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000de3f6f05aad441fd" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 00:05:01 -0000 --000000000000de3f6f05aad441fd Content-Type: text/plain; charset="UTF-8" On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker wrote: > On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote: > > gain: There is quite a bit of experience demonstrating that providing >> trust indicators to end users does not produce reliable -- ie, useful -- >> decision-making by end users. >> > We appear to be talking past each other. I wasn't talking about trust > indicators, but rather whether the RFC5322.From domain is visible. I don't > have any reason yet to think trust indicators are effective. > > The view that the From: address, or domain, or Display-Name is used, by > end-users, for assessing the trustworthiness of a message means it/they are > used as trust indicators. > > The track record is that people are unreliable at this. > > There is quite a bit of distance between 'unreliable' and 'blindly open > and read absolutely everything'. > Is there? If there's no part of the From field that can be considered reliable, then by opening even this email am I not exhibiting nearly-blind faith that the indicators I can see (in this case the string "Dave Crocker (gmail.com)") have not been falsely generated? How is this message, in terms of its trustworthiness, different from any other? -MSK --000000000000de3f6f05aad441fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 19, 2020 at 11:33 AM Dave Cro= cker <dcrocker@gmail.com> w= rote:
=20 =20 =20
On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote:

gain: There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

We appear to be talking past each other.=C2=A0 I wasn't talk= ing about trust indicators, but rather whether the RFC5322.From domain is visible.=C2=A0 I don't have any reason yet to think t= rust indicators are effective.

The view that the From: address, or domain, or Display-Name is used, by end-users, for assessing the trustworthiness of a message means it/they are used as trust indicators.=C2=A0

The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open and read absolutely everything'.

Is there?

If there's no= part of the From field that can be considered reliable, then by opening ev= en this email am I not exhibiting nearly-blind faith that the indicators I = can see (in this case the string "Dave Crocker (gmail.com)") have not been falsely generated?=C2=A0 How is = this message, in terms of its trustworthiness, different from any other?

-MSK

--000000000000de3f6f05aad441fd-- From nobody Sun Jul 19 17:52:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C124B3A0C4A for ; Sun, 19 Jul 2020 17:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 21RK8rRFVJj9 for ; Sun, 19 Jul 2020 17:52:48 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536953A0C49 for ; Sun, 19 Jul 2020 17:52:48 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id k4so13144042oik.2 for ; Sun, 19 Jul 2020 17:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KTolY6UtiueKpQqOPQK0bG3fnBx7ULmX+jv0aw3a+QU=; b=DexPU6XI/g2VdV5U9JzkJqAFKRX82drVWr2kYlt27OJaPSNxsj/l7KQ3UqW6Rax1iI nVP5ds61kvSh75ClzOHvRKws0GbKmWgZmZ7q2IEoEPVO4NIsmwYSl00xXmvFj9ZC3Qkd NBz0EP3mzdHrLnz32NsthSJQEr4Xmi2XekVvqcS3Tgz/j4XeCU2fdIVAhHMik5upbZYP 5C99laBEuqCY8B5PN+FEw0GnPUEv9AmOq4hAGfRCQVGWLXtv8/aDcqkknvm4bMEqbxjM DyMvU+pOf2+wXZdTpTG2KBN7ieLDMeNz1Gm3ILhyQDKQ20SnluJht6xpPiH1wLuP+NZe U0+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=KTolY6UtiueKpQqOPQK0bG3fnBx7ULmX+jv0aw3a+QU=; b=juRaq8g/PSi72QrKwb8xpLjtsRQe5+Kt8mb57UwukZprhzKJ/IGMYAKHke3qK6ESWu 7qAvS1519AWmuIZzgD6j0Fw/qdLUgzlqVmSQXwU1B8/B15EVfp5EU9bK/GhxdOvYYEVB wWiYb8EvvvsVpZuktzXt/BNvgw7IXe8/Dg242Ldp5BM/WQcsRSTYhpGl5ap+Ya3v+DlB RIfv/Dy+fyV91JEKhXZur1S2KEoDshKPLbuGwwWC6QGhnE8Ai8Ks3IgEY+BRihbOu7Bh VhCyhUVpIe57xOVc0GdRczJHGnuzmlQ6+gfcpJcBJH9roakyJosn2V3ICgw6Gw5C+9Ip yn9Q== X-Gm-Message-State: AOAM533f+2b2robzA0ZP9zWPafWWtr9o50gMQuuTVfy0ryG9hKlx+SIL ViLp5TMM/UZsPfju9p0X8rfNFx3yIew= X-Google-Smtp-Source: ABdhPJxn2eevwU4iP1tQ7DYiMJE2orBqIuDdBPg3t4G+MwoUH++cjKJs4vizxB49IO1J84FSklZ3mA== X-Received: by 2002:aca:524c:: with SMTP id g73mr15635298oib.150.1595206367276; Sun, 19 Jul 2020 17:52:47 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166? ([2600:1700:a3a0:4c80:fc69:4fcf:5c0d:166]) by smtp.gmail.com with ESMTPSA id c7sm3233131otm.19.2020.07.19.17.52.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 17:52:46 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Dave Crocker Message-ID: <0f93b44d-7a5b-996e-b260-75f6f1de0234@gmail.com> Date: Sun, 19 Jul 2020 17:52:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------327D9A1A8416A8ACFBF3BE39" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 00:52:50 -0000 This is a multi-part message in MIME format. --------------327D9A1A8416A8ACFBF3BE39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote: > On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker > wrote: > > The track record is that people are unreliable at this. > > There is quite a bit of distance between 'unreliable' and 'blindly > open and read absolutely everything'. > > Is there? Yes. > If there's no part of the From field that can be considered reliable, > then by opening even this email am I not exhibiting nearly-blind faith > that the indicators I can see (in this case the string "Dave Crocker > (gmail.com )") have not been falsely generated?  How > is this message, in terms of its trustworthiness, different from any > other? It's an act of curiosity, not faith.  You know that mail can be spoofed.  You might even suspect that I'm capable of lying. (Silly, I know, but...) Or that I might be wrong. (Truly a foolish thought.)  So the process of deciding on the validity and worth of my message is incremental and heuristic. Human evaluation processes vary, but mostly are pretty complex. Except when they aren't, though then it's often problematic. Mostly, your line of comments is trying to apply logical reasoning, which is rarely helpful in assessing human behavior. All of which is why this is a really terrible forum for making assertions or, worse, decisions, about end-user behavior. Whereas talking in terms of receiving filtering engines is both simpler and more useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------327D9A1A8416A8ACFBF3BE39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <dcrocker@gmail.com> wrote:
The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open and read absolutely everything'.

Is there?

Yes.


If there's no part of the From field that can be considered reliable, then by opening even this email am I not exhibiting nearly-blind faith that the indicators I can see (in this case the string "Dave Crocker (gmail.com)") have not been falsely generated?  How is this message, in terms of its trustworthiness, different from any other?

It's an act of curiosity, not faith.  You know that mail can be spoofed.  You might even suspect that I'm capable of lying. (Silly, I know, but...) Or that I might be wrong. (Truly a foolish thought.)  So the process of deciding on the validity and worth of my message is incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex.  Except when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning, which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler and more useful.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------327D9A1A8416A8ACFBF3BE39-- From nobody Sun Jul 19 18:51:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4E13A0CFF for ; Sun, 19 Jul 2020 18:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FgA2fMyISyM3 for ; Sun, 19 Jul 2020 18:51:51 -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 21C783A0CFC for ; Sun, 19 Jul 2020 18:51:51 -0700 (PDT) X-ASG-Debug-ID: 1595209906-11fa3107a814040001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id VDjrAQycc3SqrgFL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 19 Jul 2020 21:51:46 -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=from:message-id:subject:to; bh=JZdAldERpFz7KExDtHgaPWVUnUzltkQ6zeY7O/n+Sr0=; b=pO0k75sQpuY4WAlTUWERrZmO4tjVTjje4hkZCOLLvO6BV8RIBvDWgeDenhzxFGIIt aMH1ZAAeYEEKDoc1aiVC+zx29JoR+rjuWqkkTgprmFd45OwV8XyGvwm1oJL1HucZa knUzHybK5KDpGAvxLDTtjan6txcdaRhq+R5Fgn9ko= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 19 Jul 2020 21:51:38 -0400 To: IETF DMARC WG Cc: IETF DMARC WG Date: Sun, 19 Jul 2020 21:51:36 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Message-ID: MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=59e1dca42f234869ad762804fd58113d Importance: normal From: "Douglas E. Foster" X-Exim-Id: bf5b68c74a3c487ca8a07a0a27061e47 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595209906 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: 6516 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83321 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 01:51:53 -0000 This is a multipart message in MIME format. --59e1dca42f234869ad762804fd58113d Content-Type: multipart/alternative; boundary=b1b212fd33944daeb709255fd56ce8ed --b1b212fd33944daeb709255fd56ce8ed Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ultimately,=A0 this becomes a question of power.=A0 =A0Do domain owners hav= e the right, with the help of their correspondents, to prohibit spoofing (u= nauthorized use) of their digital identity?Or since they are technically le= aseholders, not owners, are their rights conditional?=A0 Specificslly, do I= nternet insiders have the right to declare their spoofing control efforts t= o be based on foolish premises, both unnecessary and inconvenient, and ther= efore not allowed?
-------- Original message --------
=
From: Dave Crocker
Date: 7/19/20 8:53= PM (GMT-05:00)
To: "Murray S. Kucherawy" =
Cc: IETF DMARC WG
Subject: Re: [dma= rc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security cons= iderations
On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote: > On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker > wrote: > > The track record is that people are unreliable at this. > > There is quite a bit of distance between 'unreliable' and 'blindly > open and read absolutely everything'. > > Is there? Yes. > If there's no part of the From field that can be considered reliable, > then by opening even this email am I not exhibiting nearly-blind faith > that the indicators I can see (in this case the string "Dave Crocker > (gmail.com )") have not been falsely generated?=A0 How > is this message, in terms of its trustworthiness, different from any > other? It's an act of curiosity, not faith.=A0 You know that mail can be spoofed.=A0 You might even suspect that I'm capable of lying. (Silly, I know, but...) Or that I might be wrong. (Truly a foolish thought.)=A0 So the process of deciding on the validity and worth of my message is incremental and heuristic. Human evaluation processes vary, but mostly are pretty complex. Except when they aren't, though then it's often problematic. Mostly, your line of comments is trying to apply logical reasoning, which is rarely helpful in assessing human behavior. All of which is why this is a really terrible forum for making assertions or, worse, decisions, about end-user behavior. Whereas talking in terms of receiving filtering engines is both simpler and more useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --b1b212fd33944daeb709255fd56ce8ed Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ultimately,  this becomes a question of po= wer.   Do domain owners have the right, with the help of their co= rrespondents, to prohibit spoofing (unauthorized use) of their digital iden= tity?

Or since they are technically leaseholders, = not owners, are their rights conditional?  Specificslly, do Internet i= nsiders have the right to declare their spoofing control efforts to be base= d on foolish premises, both unnecessary and inconvenient, and therefore not= allowed?




=
-------- Original message --------
F= rom: Dave Crocker <dcrocker@gmail.com>
Date: 7/19/20 8:53= PM (GMT-05:00)
To: "Murray S. Kucherawy" <superuser@gmail.c= om>
Cc: IETF DMARC WG <dmarc@ietf.org>
Subje= ct: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 s= ecurity considerations

On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <dcrocker@gmail.com> wrote:
The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open and read absolutely everything'.

Is there?

Yes.


If there's no part of the From field that can be considered reliable, then by opening even this email am I not exhibiting nearly-blind faith that the indicators I can see (in this case the string "Dave Crocker (gmail.com)") have not been falsely generated?=A0 How is this message, in terms of its trustworthiness, different from any other?

It's an act of curiosity, not faith.=A0 You know that mail can be spoofed.=A0 You might even suspect that I'm capable of lying. (Silly, I know, but...) Or that I might be wrong. (Truly a foolish thought.)=A0 So the process of deciding on the validity and worth of my message is incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex.=A0 Except when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning, which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler and more useful.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--b1b212fd33944daeb709255fd56ce8ed-- --59e1dca42f234869ad762804fd58113d-- From nobody Mon Jul 20 01:42: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 3C8E13A0895 for ; Mon, 20 Jul 2020 01:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 31wpB6oBU8WM for ; Mon, 20 Jul 2020 01:42:28 -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 929D93A088F for ; Mon, 20 Jul 2020 01:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595234545; bh=s8kf+DY6fdIh9GmPZlO+3nFz7H11IjXn2wW44y3X4tk=; l=1118; h=To:Cc:References:From:Date:In-Reply-To; b=DEZf+cl9q/Fc9v/Yx0E3i9KOHii5QnKaR/m7FDEzaCZYh+5CoCZ5ah4xbLxurZq5f MktERpESLxstGToPfwNRQ8SiU1q1gyiiGvBQkmtL+XBuK+fFfJtqaHXJmKmbxMyNTG jBUV8ZRRCiHd6g3WbJTGt86Bmvw2q1FOl3VdDyCRhqfiwh7OjdqMsBRVtpYHC 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 00000000005DC07C.000000005F1558F1.00007CE2; Mon, 20 Jul 2020 10:42:25 +0200 To: "Murray S. Kucherawy" Cc: IETF DMARC WG , Brandon Long References: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> From: Alessandro Vesely Message-ID: <96e11fae-99f5-b552-b959-6adf9d085a42@tana.it> Date: Mon, 20 Jul 2020 10:42:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 08:42:30 -0000 On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote: > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely wrote: > >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From >>> domain truly matters. >> >> While the opinions of big players are relevant, you yourself mentioned >> that they tend to follow DMARC design. > > > Sorry, I said what? Google strikes me as the kind of place that would make a decision about what to show users based on data, so I was wondering if they have any, because I seem to remember them talking about this back when DMARC was in development. [https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/] Brandon hasn't chimed in, yet. I Cc: him. I'd guess he can confirm that efforts to highlight the domain name in From: addresses, if any, are inspired, or at least encouraged, by DMARC development. By hijacking From:, DMARC tweaked email core somewhat, for the good and the bad of it. We can either go ahead or retreat, a threat analysis being needed to make that decision. Best Ale -- From nobody Mon Jul 20 01:44: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 A05293A089C for ; Mon, 20 Jul 2020 01:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4ufK-dp97yP2 for ; Mon, 20 Jul 2020 01:44: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 486B83A089B for ; Mon, 20 Jul 2020 01:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595234668; bh=olC5bSmMifr3Q7qNqyC6uOb0lcXdy2xwefZ/WoMoNKI=; l=915; h=To:References:From:Date:In-Reply-To; b=C3PDJ2vAksM5uJt6dDuTXi3UJmFwon1I1EM80GpY5602mjOWio+UBN9zCYbqca3OZ 1PqoaJsLb8IPE2SqfjdNxV9/uZ+7qmKlDTtywO0bLe5sfM9QdMo2Gpzx7u20xjRYsm bT/HcQNnqqEPDXY1RJSOoAI4K081uz966HIADBoYz+8rxfh4+e1Lj8rcenXF4 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 00000000005DC07C.000000005F15596C.00007D4E; Mon, 20 Jul 2020 10:44:28 +0200 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Alessandro Vesely Message-ID: Date: Mon, 20 Jul 2020 10:44:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 08:44:32 -0000 On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote: > > The essential point that needs to be made is that standards like this MUST NOT > be cast in terms of what end users will do.  In practical terms, this work has > nothing to do with end users. Really.  Nothing. > > [...] > > > (*) I've seen one posting here or somewhere else that noted that letting bad > mail through can lead to end-users being deceived. I'll claim that while true, > it is not relevant, since the behavior happens after DMARC, and the like, are > relevant.  That is, DMARC, etc., do not inform the end-user behavior. Aren't those two paragraphs self-contradictory? If DMARC were dependable, maybe users would learn to trust From:. Or maybe not. Avoiding end user considerations cuts both ways. Yet, we can trust that if we do a well-defined, clear job, then the whole system will work better. Best Ale -- From nobody Mon Jul 20 01:59:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAA13A0A2D for ; Mon, 20 Jul 2020 01:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlBmJuxD-lqn for ; Mon, 20 Jul 2020 01:59:50 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 715DA3A09DA for ; Mon, 20 Jul 2020 01:59:42 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id F1D739F149; Mon, 20 Jul 2020 01:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595235581; bh=iXG760UfwcuO7U/ZwBiZCiZTyzCMbDNYOEUeQZ9evIs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=XNPl/DBwSqiF6D6hhULfqzATKdzssZPHJV4gUEKsjMiAw72EpUKvuVFg16/Vhtc9g 7G83V96UmSGwQtLOikiBDxIrhjEj9vDzgE5jGoXqWSnpXDUkNhiO1/B+bNI/nNLONY gS/A7/L93+HFDZ+fjyqdLJ3ERk71pBopE1GKZsvk= From: Laura Atkins Message-Id: <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2273948B-C3BB-4551-875E-6FC5B9AC8CFF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 20 Jul 2020 09:59:38 +0100 In-Reply-To: Cc: IETF DMARC WG To: "Murray S. Kucherawy" References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 08:59:58 -0000 --Apple-Mail=_2273948B-C3BB-4551-875E-6FC5B9AC8CFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Jul 2020, at 19:08, Murray S. Kucherawy = wrote: >> I'm less convinced by the notion that all of the RFC5322.=46rom is = disregarded by the preponderance of users when deciding what level of = trust to put in the message's content. That suggests we blindly open and = read absolutely everything, and I suspect that isn't the case. > 1. That's not what it suggests, at all >=20 > Then I don't know what else you might mean by "end users do not = reliably make trust decisions based on /any/ of the information in the = rfc5322.=46rom field". What other data exist upon which to make trust = decisions in the display of a mailbox? There was a research project done by an inbox provider and a major = supporter of DMARC presented at a MAAWG meeting a few years ago. They = tried adding trust indicators to the message list but found no = statistically significant behavioral changes by users. Given the = conference policies, I hesitate to mention it here, but there is = research. There=E2=80=99s also a conference paper I found, done by a = computer science research team at VA Tech that looked at this as well.=20= This question is actively being studied and there is research out there. = We don=E2=80=99t need to speculate or bring in individual opinions, we = can look at the different studies folks have done.=20 > 2. No doubt there is a better way to put this, but I'm not thinking of = it, and this isn't just my second thought on the challenge, but quite a = bit more than that: This demonstrates why the IETF is a very poor venue = for conducting human factors discussions. >=20 > No argument here.=20 > Again: There is quite a bit of experience demonstrating that providing = trust indicators to end users does not produce reliable -- ie, useful -- = decision-making by end users. >=20 > We appear to be talking past each other. I wasn't talking about trust = indicators, but rather whether the RFC5322.=46rom domain is visible.. I = don't have any reason yet to think trust indicators are effective. Most clients these days seem to be hiding the RFC5322.=46rom domain from = the individual end users. Mail.app on OSX does unless you change that = setting specifically (and it seems every few upgrades they reset the = setting and then hide the checkbox again). The iOS mail app doesn=E2=80=99= t even have a setting to change that I=E2=80=99ve been able to find. I = seem to remember the last time I set up a mailbox on Thunderbird = (pre-2016 election as I was tracking some candidate mail) they also hid = the 5322.=46rom address.=20 There was another comment elsewhere about why not change the 5322.from = address if it=E2=80=99s not visible to the enduser, and there are 2 = reasons I have for that: The ability to search for mail from a = particular author and the ability to block mail from a particular = author. Rewriting the From: address always breaks the first. Some = mailing lists point the Reply-To: to the original author which means = some kinds of filtering can trigger off that. Other mailing lists point = Reply-To: to the list address, which breaks the second. Both things are = important to mailing list usability. laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_2273948B-C3BB-4551-875E-6FC5B9AC8CFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 19 Jul 2020, at 19:08, Murray S. Kucherawy <superuser@gmail.com>= wrote:

   I'm less convinced by the notion = that all of the RFC5322.=46rom is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at = all

Then I don't know what else = you might mean by "end users do not reliably = make trust decisions based on /any/ of the information in the = rfc5322.=46rom field".  What other data exist upon which to make = trust decisions in the display of a mailbox?

There was = a research project done by an inbox provider and a major supporter of = DMARC presented at a MAAWG meeting a few years ago. They tried adding = trust indicators to the message list but found no statistically = significant behavioral changes by users. Given the conference policies, = I hesitate to mention it here, but there is research. There=E2=80=99s = also a conference paper I found, done by a computer science research = team at VA Tech that looked at this as well. 

This question is actively being studied and there = is research out there. We don=E2=80=99t need to speculate or bring in = individual opinions, we can look at the different studies folks have = done. 

2. No = doubt there is a better way to put this, but I'm not thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:  This demonstrates = why the IETF is a very poor venue for conducting human factors discussions.

No argument = here.

Again: = There is quite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end = users.

We appear to be talking = past each other.  I wasn't talking about trust indicators, but = rather whether the RFC5322.=46rom domain is visible..  I don't have = any reason yet to think trust indicators are effective.

Most clients these days seem to be hiding the = RFC5322.=46rom domain from the individual end users. Mail.app on OSX = does unless you change that setting specifically (and it seems every few = upgrades they reset the setting and then hide the checkbox again). The = iOS mail app doesn=E2=80=99t even have a setting to change that I=E2=80=99= ve been able to find. I seem to remember the last time I set up a = mailbox on Thunderbird (pre-2016 election as I was tracking some = candidate mail) they also hid the 5322.=46rom = address. 

There was another = comment elsewhere about why not change the 5322.from address if it=E2=80=99= s not visible to the enduser, and there are 2 reasons I have for that: = The ability to search for mail from a particular author and the ability = to block mail from a particular author. Rewriting the From: address = always breaks the first. Some mailing lists point the Reply-To: to the = original author which means some kinds of filtering can trigger off = that. Other mailing lists point Reply-To: to the list address, which = breaks the second. Both things are important to mailing list = usability.

laura 

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

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

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







= --Apple-Mail=_2273948B-C3BB-4551-875E-6FC5B9AC8CFF-- From nobody Mon Jul 20 02:44:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B663A07C2 for ; Mon, 20 Jul 2020 02:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_C=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsuDkOYQwldN for ; Mon, 20 Jul 2020 02:44:05 -0700 (PDT) Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) (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 63FB73A07BF for ; Mon, 20 Jul 2020 02:44:05 -0700 (PDT) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jxSL5-0008aC-NP for dmarc@ietf.org; Mon, 20 Jul 2020 11:44:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Mon, 20 Jul 2020 11:43:58 +0200 Message-ID: <87zh7ur069.fsf@orion.amorsen.dk> References: Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:H0PiOUOdFfk913zAcxHp3O5LDxU= Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 09:44:07 -0000 "Douglas E. Foster" writes: > Ultimately, this becomes a question of power. Do domain owners have > the right, with the help of their correspondents, to prohibit spoofing > (unauthorized use) of their digital identity? Domain owners are free to use the court system to assert trademark rights and copyright. They are also free to apply whichever seals of digital identity that they want, of course. > Or since they are technically leaseholders, not owners, are their > rights conditional? You seem to be laboring under the impression that domain owners have a right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email with your domain in the From: field and no valid DKIM (or whatever) signature, of course, but I have a hard time imagining which right you would assert to make the suit successful. > Specificslly, do Internet insiders have the right to declare their > spoofing control efforts to be based on foolish premises, both > unnecessary and inconvenient, and therefore not allowed? No one, certainly not "Internet insiders" of which I am certainly not one, is stopping you from doing whichever spoofing control efforts you want on your systems. Feel free to keep p=reject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket reject. If you want recipient mail servers to change that policy you can either do it by convincing their administrators or by getting a law passed. So far you appear to favour the latter approach, with your focus on "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking body, so it appears there are better venues for you. From nobody Mon Jul 20 05:32:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF793A08CB for ; Mon, 20 Jul 2020 05:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 H_VsGqMggJXZ for ; Mon, 20 Jul 2020 05:32:11 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9783A096D for ; Mon, 20 Jul 2020 05:32:04 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 22so22104339wmg.1 for ; Mon, 20 Jul 2020 05:32:04 -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=o5wZygNmGVfbWmAn3Acep7nnymHcbJkUfOgdejmr1rM=; b=UHQAS11jmRd+LntZpWqoyafuQomZNyiuV3Zz53gjHBDlKq8a+ObT9ktXmGc8GzQ3od AHLiOXphmsh9SEr1AKtH0LgYc8qNnJu2yU1dy1OZq1CS3CBkfNDn+8Sg7uvLcZ/pEjLP rSFZroZueeCRUAl5LnYi05c5ozvZpqLKQLe+LVrWPDantQ9WrOfXb8RL9ds0Gm1PHtOa h9nDkbQpBUIV7PdoONQR322oA6L4YdZOV/j3vah8+C7KtLleWUBSDXUeBatnXsDMmfMd Csk9YcPZHVVq4qLwQG88wuIlTICIxRUpvQzB4sJTsNaO0Rdl2o0Ngi03amaZnUm/pa1+ tnCQ== 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=o5wZygNmGVfbWmAn3Acep7nnymHcbJkUfOgdejmr1rM=; b=fak/AdhaEOSQcWA9CjBp5CdjTNbt3RgKxPTRQhanwZL0+mmZGkVwmfpVH9s8d9r0KA KRjUD+GhKKU2AcPXtdvzITOQQ4XOvkAoLLlDtpjQ89ns6qNytt6ZZuBLvenamwOhbwPl /beP3EKg9SwZdYTaCZK4U0ebAQ+sxFCqVmIaGKz4zp4U+lnDSBO2TlE76/AIcOz3USF5 q7iyuA7gEx47a1Q+P8LtnibcEmG8cssGiT6AH/KXs5bsud8EKmD2ZxFWxQ6UQalWbRVY 5cIUjp1J1Y7G+TTwszET0AIwi9rC0FBY10nsTFTu6gyjc9NApisufbMEob/51h0XF+Rl lEFQ== X-Gm-Message-State: AOAM531Grv3WDkqPWtk/1km17HPZ8vNsQJ/Yap2v71bSdfWyVO+O3rh9 Jos1uHr8esnfeRfc5G6aknxo8wsIgay3uA4o2+W96w== X-Google-Smtp-Source: ABdhPJwrOmquX4CIhDQJ5CFRLuLRqar1s0gCGaN6daSGjiTHX5fk8TOQuEvEbX7fcQ0znBCnyNBB4BfZ87oWIKBkFzk= X-Received: by 2002:a1c:6408:: with SMTP id y8mr20812375wmb.122.1595248322512; Mon, 20 Jul 2020 05:32:02 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> In-Reply-To: <87zh7ur069.fsf@orion.amorsen.dk> From: Dotzero Date: Mon, 20 Jul 2020 08:31:51 -0400 Message-ID: To: Benny Lyne Amorsen Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000978b4e05aadeb17d" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 12:32:13 -0000 --000000000000978b4e05aadeb17d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 5:44 AM Benny Lyne Amorsen wrote: > "Douglas E. Foster" writes: > > > Ultimately, this becomes a question of power. Do domain owners have > > the right, with the help of their correspondents, to prohibit spoofing > > (unauthorized use) of their digital identity? > > Domain owners are free to use the court system to assert trademark > rights and copyright. They are also free to apply whichever seals of > digital identity that they want, of course. > > > Or since they are technically leaseholders, not owners, are their > > rights conditional? > > You seem to be laboring under the impression that domain owners have a > right to compel mail recipients to respect a DRM scheme. This is not the > case. You can try to sue Google to force them to reject incoming email > with your domain in the From: field and no valid DKIM (or whatever) > signature, of course, but I have a hard time imagining which right you > would assert to make the suit successful. > > DMARC clearly recognizes and documents local policy. > > Specificslly, do Internet insiders have the right to declare their > > spoofing control efforts to be based on foolish premises, both > > unnecessary and inconvenient, and therefore not allowed? > > No one, certainly not "Internet insiders" of which I am certainly not > one, is stopping you from doing whichever spoofing control efforts you > want on your systems. > One might point to the fact that DMARC was just such an effort before it was publicly published. While there was much criticism of this when it was submitted to the IETF - "You just want us to rubber stamp this" - there was no such intent. It had worked well within the group of senders and receivers implementing it through private peering that the effort was made so that any domain of any size, both senders and receivers, could implement it if so desired. I think the adoption rate in the wild speaks for itself (volume of mail covered by DMARC). > > Feel free to keep p=reject on your domains. Many mail servers will keep > using that as a signal among many others, rather than as a blanket > reject. > > If you want recipient mail servers to change that policy you can either > do it by convincing their administrators or by getting a law passed. So > far you appear to favour the latter approach, with your focus on > "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking > body, so it appears there are better venues for you. > You have left out one significant way of convincing receiver domains and their admins. We used to have our CSRs (customer service) tell people who received spoof emails (resulting in phishing, malware compromise, etc.) from emails claiming to be from our domains that they should contact their mail provider or email admin because the problem could have been avoided if DMARC were being checked. We would even provide them with the details and a form with all the information in non-technical terms. It is amazing how quickly a provider pays attention when their customers/users are complaining to them that the provider could have prevented the heartache and grief but chose not to. Again, this was for domains sending transactional mail with only a limited number (intentionally) of role and support accounts. While IETF is not a lawmaking body, it has an impact on the decisions of lawmaking bodies just as the decisions of lawmaking bodies can impact the implementation of standards. One need only look at the "great firewall of China" as one example. Michael Hammer --000000000000978b4e05aadeb17d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 5:44 AM Benny= Lyne Amorsen <benny+usenet= @amorsen.dk> wrote:
"Douglas E. Foster" <fosterd@bayviewphysicians.com> = writes:

> Ultimately, this becomes a question of power.=C2=A0 Do domain owners h= ave
> the right, with the help of their correspondents, to prohibit spoofing=
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.


DMARC clearly recognizes and documents= local policy.
=C2=A0
> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly= not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

One might point t= o the fact that DMARC was just such an effort before it was publicly publis= hed. While there was much criticism of this when it was submitted to the IE= TF - "You just want us to rubber stamp this" -=C2=A0 there was no= such intent. It had worked well within the group of senders and receivers = implementing it through private peering that the effort was made so that an= y domain of any size, both senders and receivers, could implement=C2=A0it i= f so desired. I think the adoption rate in the wild speaks for itself (volu= me of mail covered by DMARC).=C2=A0

Feel free to keep p=3Dreject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". T= he IETF is not a lawmaking
body, so it appears there are better venues for you.
<= br>
You have left out one significant way of convincing receiver = domains and their admins. We used to have our CSRs (customer service) tell = people who received spoof emails (resulting in phishing, malware compromise= , etc.) from emails claiming to be from our domains that they should contac= t their mail provider or email admin because the problem could have been av= oided if DMARC were being checked. We would even provide them with the deta= ils and a form with all the information in non-technical terms. It is amazi= ng how quickly a provider pays attention when their customers/users are com= plaining to them that the provider could have prevented the heartache and g= rief but chose not to. Again, this was for domains sending transactional ma= il with only a limited number (intentionally) of role and support accounts.=

While IETF is not a lawmaking body, it has an impact on the decisio= ns of lawmaking bodies just as the decisions of lawmaking bodies can impact= the implementation of standards. One need only look at the "great fir= ewall of China" as one example.

Michael Hamme= r
--000000000000978b4e05aadeb17d-- From nobody Mon Jul 20 05:50: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 1E48C3A097B for ; Mon, 20 Jul 2020 05:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_C=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed4faqAfABwj for ; Mon, 20 Jul 2020 05:50:01 -0700 (PDT) Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) (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 1D38C3A097A for ; Mon, 20 Jul 2020 05:50:01 -0700 (PDT) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jxVF0-0000Ql-VT for dmarc@ietf.org; Mon, 20 Jul 2020 14:49:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dmarc@ietf.org From: Benny Lyne Amorsen Date: Mon, 20 Jul 2020 14:49:54 +0200 Message-ID: <87v9iiqrkd.fsf@orion.amorsen.dk> References: <87zh7ur069.fsf@orion.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:k7ulmyFTT1lBinKlllWlDzDBTi8= Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 12:50:02 -0000 Dotzero writes: > One might point to the fact that DMARC was just such an effort before > it was publicly published. While there was much criticism of this when > it was submitted to the IETF - "You just want us to rubber stamp this" > - there was no such intent. It had worked well within the group of > senders and receivers implementing it through private peering that the > effort was made so that any domain of any size, both senders and > receivers, could implement it if so desired. I think the adoption rate > in the wild speaks for itself (volume of mail covered by DMARC). Volume of mail covered by DMARC seems to be rather unimpressive unless you count p=none as covered. > You have left out one significant way of convincing receiver domains > and their admins. We used to have our CSRs (customer service) tell > people who received spoof emails (resulting in phishing, malware > compromise, etc.) from emails claiming to be from our domains that > they should contact their mail provider or email admin because the > problem could have been avoided if DMARC were being checked. We would > even provide them with the details and a form with all the information > in non-technical terms. It is amazing how quickly a provider pays > attention when their customers/users are complaining to them that the > provider could have prevented the heartache and grief but chose not > to. Again, this was for domains sending transactional mail with only a > limited number (intentionally) of role and support accounts. You can obviously do all that, but that is not what Douglas E. Foster advocated. > While IETF is not a lawmaking body, it has an impact on the decisions > of lawmaking bodies just as the decisions of lawmaking bodies can > impact the implementation of standards. Using the IETF as a way to get laws passed favouring ones business seems at best underhanded. From nobody Mon Jul 20 05:56: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 0C2DB3A08E5 for ; Mon, 20 Jul 2020 05:56:06 -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 UdUD9ZxU1jpx for ; Mon, 20 Jul 2020 05:56:01 -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 1EE233A08E1 for ; Mon, 20 Jul 2020 05:56:01 -0700 (PDT) X-ASG-Debug-ID: 1595249759-11fa3107a817080001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id D22t5WVj6yg1nLoP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 20 Jul 2020 08:55:59 -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=TrmKY5W4h+FgCDTkpqDGFZYy3ZnK2SM6K0OnYhiLOFI=; b=W2SqBntt1jeUl2eBczrIvgme4/CmrLd/Tb6NCi6tayTw39y6zGwagm7mI2pxuNRCq f83ZpTaJutO0DvqgOvlKUSTIT6tn5rq6P0zibgBSxpEgAKXL7fqjYcVZlT8BX/6b8 NobzCSmIr8oaSzCffzABzVPN/6krE9yy4liUzanFk= From: "Douglas E. Foster" To: Date: Mon, 20 Jul 2020 12:55:50 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Reply-To: fosterd@bayviewphysicians.com Message-ID: <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3992d382d2644686971b17439cd67822 In-Reply-To: <87zh7ur069.fsf@orion.amorsen.dk> References: <87zh7ur069.fsf@orion.amorsen.dk> X-Exim-Id: 3829fac4748a48d0b752403450843bd5 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595249759 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: 7106 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.83331 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 12:56:06 -0000 This is a multipart message in MIME format. --3992d382d2644686971b17439cd67822 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The court system is a poor substitute for prior deterrence or attack disrup= tion. DMARC seems to do both. The Internet limits the utility of legal remedies because of the difficulty= of attribution, a problem which also DMARC helps to solve. Litigation is= also hampered by jurisdictional boundaries that create little risk of cons= equences for the perpetrators of crime. This forum was proposed for upgrading DMARC from informational status to st= andard status. Instead, it has become a conspiracy to demolish it. The= MLM problem will only be :"solved" if DMARC is completely abandoned, so th= at spoofing is once again uninhibited. Therefore, moving from normal IETF= "suggestion" mode to "enforced" mode will be necessary to achieve what MLM= proponents want. It is not what I am advocating; quite the reverse. I = am advocating for MLMs to stop spoofing and make their peace with DMARC. DF ---------------------------------------- From: Benny Lyne Amorsen Sent: 7/20/20 5:44 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author= -00 security considerations "Douglas E. Foster" writes: > Ultimately, this becomes a question of power. Do domain owners have > the right, with the help of their correspondents, to prohibit spoofing > (unauthorized use) of their digital identity? Domain owners are free to use the court system to assert trademark rights and copyright. They are also free to apply whichever seals of digital identity that they want, of course. > Or since they are technically leaseholders, not owners, are their > rights conditional? You seem to be laboring under the impression that domain owners have a right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email with your domain in the From: field and no valid DKIM (or whatever) signature, of course, but I have a hard time imagining which right you would assert to make the suit successful. > Specificslly, do Internet insiders have the right to declare their > spoofing control efforts to be based on foolish premises, both > unnecessary and inconvenient, and therefore not allowed? No one, certainly not "Internet insiders" of which I am certainly not one, is stopping you from doing whichever spoofing control efforts you want on your systems. Feel free to keep p=3Dreject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket reject. If you want recipient mail servers to change that policy you can either do it by convincing their administrators or by getting a law passed. So far you appear to favour the latter approach, with your focus on "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking body, so it appears there are better venues for you. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --3992d382d2644686971b17439cd67822 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
The court system i= s a poor substitute for prior deterrence or attack disruption.   DMARC= seems to do both.   

The Internet limit= s the utility of legal remedies because of the difficulty of attribution, a= problem which also DMARC helps to solve.   Litigation is also hampere= d by jurisdictional boundaries that create little risk of consequences for = the perpetrators of crime.

This forum was proposed= for upgrading DMARC from informational status to standard status.   I= nstead, it has become a conspiracy to demolish it.    The MLM pro= blem will only be :"solved" if DMARC is completely abandoned, so that spoof= ing is once again uninhibited.   Therefore, moving from normal IETF "s= uggestion" mode to "enforced" mode will be necessary to achieve what MLM pr= oponents want.   It is not what I am advocating; quite the reverse. &n= bsp; I am advocating for MLMs to stop spoofing and make their peace with DM= ARC.

DF



<= div>From: Benny Lyne Amorsen <benny+usenet@amorse= n.dk>
Sent: 7/20/20 5:44 AM
To: = dmarc@ietf.org
Subject: Re: [dmarc-ietf] Response to a = claim in draft-crocker-dmarc-author-00 security considerations
=
"Douglas E. Foster" <fosterd@bayviewphysicians.com> writes:

> Ultimately, this becomes a question of power. Do = domain owners have
> the right, with the help of their corresp= ondents, to prohibit spoofing
> (unauthorized use) of their di= gital identity?

Domain owners are free to use the = court system to assert trademark
rights and copyright. They are a= lso free to apply whichever seals of
digital identity that they w= ant, of course.

> Or since they are technically= leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that dom= ain owners have a
right to compel mail recipients to respect a DR= M scheme. This is not the
case. You can try to sue Google to forc= e them to reject incoming email
with your domain in the From: fie= ld and no valid DKIM (or whatever)
signature, of course, but I ha= ve a hard time imagining which right you
would assert to make the= suit successful.

> Specificslly, do Internet i= nsiders have the right to declare their
> spoofing control eff= orts to be based on foolish premises, both
> unnecessary and i= nconvenient, and therefore not allowed?

No one, ce= rtainly not "Internet insiders" of which I am certainly not
one, = is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=3Drejec= t on your domains. Many mail servers will keep
using that as a si= gnal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy y= ou can either
do it by convincing their administrators or by gett= ing a law passed. So
far you appear to favour the latter approach= , with your focus on
"prohibit" "unauthorized use" and "rights". = The IETF is not a lawmaking
body, so it appears there are better = venues for you.

__________________________________= _____________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--3992d382d2644686971b17439cd67822-- From nobody Mon Jul 20 11:35:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7C3A07D6 for ; Mon, 20 Jul 2020 11:35:06 -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 8_gQ5iiXuGyb for ; Mon, 20 Jul 2020 11:35:04 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FECC3A07D4 for ; Mon, 20 Jul 2020 11:35:03 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id q15so470785wmj.2 for ; Mon, 20 Jul 2020 11:35:03 -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=kf1LTYTlIJfRKoIG+QrkaAM9ZYgWJTIToAONBgB+34g=; b=cKDLlBKn3TVygPsDHqJ6OEsjnBg3xl65IPkAx94kFDbaSpk/CDWW6E5ou+DMo4A9Zl 73aO5VUQRCqjQ+0Z+rDjWD4lJbXjdYrUzCgGEW9POT2ds1VaYHHc/lhxGioI0KTIYObH 3HzkrGP0WuibBkIhkJtoWFgT0RpU00ywUsnDShtO1iNuYRwPWn0L6I03NMsZDXaYInny 3CiDbfHLAegLqpH+slaLK+5Dsl1bFhUFQU96jIiYUUbO/aaJcP2PEiJewnI4vZHhOsuH dk0lE6KYBCYVDNcbTjdeymGK7C6SzdvLxJG/yGmREae03d2eNmdpgHm/Ar9mb0yK20Ji UOYg== 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=kf1LTYTlIJfRKoIG+QrkaAM9ZYgWJTIToAONBgB+34g=; b=SXKz5ours6aPvYiYkPmaMvZBZJr1V5QQJWheos3HKq8KXOZxtHKJ88XOVDC8GV4R9i wcTkKvrHM+bPeQMt9eGXwU/n77r8ShQL95PXkth2ymsu3h070VL10HKDRznqCgGk+W7e EAfcOXYwL2IdWYRv4FNo+zTQaLVU9Pa7XW//bP6UjWcJGCGOKu/T26RRjZTTZ5ta1JlT VHqTdTCIYvVuTzUsHAhB1ehGigiT5smTiD7/Ot82hmJfUFwhrnyb6wDW5NgJmjZBq+VN 8BZdsV6wkTwzK5KyySmQnV3rWIsDoQ/dWRsps6EuYHVL4dpeQzp6S5RQYebHIlBipyzO rlFw== X-Gm-Message-State: AOAM530j2c6uZ5rJG5l08X7bg3sBTILs7fShQTW4C7BLTMJAqIeTOtvm C+G/ZUjDLeXGaDoDavShmDwmQe4XkGkFoogB9Q7v+e/d8b8= X-Google-Smtp-Source: ABdhPJwjV2v6/fmUMPyr/RbVbh8GMwkrmpigL+GiRIdCbSG/EYXi6ehDLSURXOb9oXvR13JuQOxfe8fAtj+LNmKgDFk= X-Received: by 2002:a1c:4c0e:: with SMTP id z14mr593083wmf.54.1595270102100; Mon, 20 Jul 2020 11:35:02 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Mon, 20 Jul 2020 11:34:51 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c1c62905aae3c331" Archived-At: Subject: [dmarc-ietf] Returning focus to DMARCbis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 18:35:07 -0000 --000000000000c1c62905aae3c331 Content-Type: text/plain; charset="UTF-8" There's been a healthy discussion on the list over the past month that's touched on several items within DMARC's charter, but are out of scope of the currently chartered phase of work (phase III). As Chairs, we've watched this discussions closely, because successful mitigation of loss of authentication due to indirect mailflow is a requirement for the success of a standards track DMARC document, which is the focus of DMARCbis. ARC has IETF consensus, is being actively deployed, and needs time to succeed or fail against its experimental considerations before the group revisits the work -- which would require a rechartering. We have a good deal of work to do on DMARCbis, and many open tickets. As we discussed we want to track all issues in tickets. The chairs will use the active tickets to lead the list discussion. We will get to all the issues. If you feel that there are items that were raised in discussions that still require group discussion, please add them to trac ( https://trac.ietf.org/trac/dmarc/report/1) per the process Alexey laid out: https://mailarchive.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/ If you have questions about this process or need help filing a ticket appropriately, please reach out to the Chairs directly at dmarc-chairs@ietf.org. Thanks, Seth, Tim, and Alexey --000000000000c1c62905aae3c331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's been a healthy discussion on the list over the= past month that's touched on several items within DMARC's charter,= but are out of scope of the currently chartered phase of work (phase III).= As Chairs, we've watched this discussions closely, because successful = mitigation of loss of authentication due to indirect mailflow is a requirem= ent for the success of a standards track DMARC document, which is the focus= of DMARCbis.

ARC has IETF consensus, is being actively deployed, an= d needs time to succeed or fail against its experimental considerations bef= ore the group revisits the work -- which would require a rechartering.
<= br>We have a good deal of work to do on DMARCbis, and many open tickets. As= we discussed we want to track all issues in tickets. The chairs will use t= he active tickets to lead the list discussion. We will get to all the issue= s.

If you feel that there are items that were raised in discussions= that still require group discussion, please add them to trac (https://trac.ietf.org/trac/dmarc/= report/1) per the process Alexey laid out: https://mailarchiv= e.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/

If you ha= ve questions about this process or need help filing a ticket appropriately,= please reach out to the Chairs directly at dmarc-chairs@ietf.org.

Thanks,

Seth, Tim, and A= lexey

--000000000000c1c62905aae3c331-- From nobody Mon Jul 20 11:36:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8BC3A07D6 for ; Mon, 20 Jul 2020 11:36: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 9J6QG-3LnWBJ for ; Mon, 20 Jul 2020 11:36:35 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FDD3A07DF for ; Mon, 20 Jul 2020 11:36:34 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 184so499121wmb.0 for ; Mon, 20 Jul 2020 11:36:34 -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=kwF3Kojn5GGh4ZZUwaL7XitWik4TfLz+GYXdSpwmNCw=; b=VfOumeDd1Utp+8CqF5uGJrVKPqzidfXsbGwFSxv4HCB0HiCa/qrFFHfjqsY+Ha9HU2 EH1u7ihsv6qV+YWkK8UqChHUB8JGgCvUnqSfTLcpBgiWjptmbGbjG2NWJOqkekPT4mFI 37fxmjM3zUePAqkPuLc45hOyfGR6/z5cgdwjqj+6DXUebtD9vHTe6rhuHTDcMojImhrT ZKBXOJXL0K8gB782m3CijR00xccLOTbzzuUWIjcN46nE/YFF3jJyAYPUQuvUU67WVWgN gNfeCWx7r5LTKQJsoUcMakabdsPF2QsBUts4Hga62AN+Lx4KJNhL+tE5UeBYZGU+Qeu0 Os0Q== 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=kwF3Kojn5GGh4ZZUwaL7XitWik4TfLz+GYXdSpwmNCw=; b=jUpp6gYUR0qTYSnKzSiYc2Fo7S3cBzTFd0fnOdjk/S0RDE3L4cARmRmi7/+qPbDJKf 68bWbF0Im2zyDcGD0jmrMY17XiAtBzmrSJ89PPsZyjEw9h7bhznzFh/C2rGylMMFg+9C 0TGsxEavc62gBAVTNlGEU5qd264ivmrtHV7fO1b1OGcy2ruMO2wDylD5pGLz+7Bl9JZM i7ZpOHOPPOL3fSYL71rfHT+dZtLkxbi34v1irGuErmE4oWB30ZpGpTfkUMMaaLqoUJLa y5GE4T89etKS3qzb1EVttM+o0i8CStzpbFLe49meMs8WLntSFrWtOS2WKaIBXd0gQpn5 6XGg== X-Gm-Message-State: AOAM5305L7wyunacDpm5dNrrTqVrhWde4mjm/Trn9cfQ6rvtQjj64c4t jvKjj94l+1xNT2qJR/qNFzXnMdy4nc5+EeHAnROjIVwsQ5s= X-Google-Smtp-Source: ABdhPJyqfD+DeppwfDxj0/OW3mAgRxV/lGIXkGwpnLea/DxB+PjJm8toYfIKtRkTw5jKx8zxBLqG9p74Y2sGez3piTk= X-Received: by 2002:a1c:3954:: with SMTP id g81mr558314wma.73.1595270192864; Mon, 20 Jul 2020 11:36:32 -0700 (PDT) MIME-Version: 1.0 From: Seth Blank Date: Mon, 20 Jul 2020 11:36:21 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002ab85905aae3c968" Archived-At: Subject: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 18:36:36 -0000 --0000000000002ab85905aae3c968 Content-Type: text/plain; charset="UTF-8" We have a session on the books for IETF108, and would like suggestions from the group for the agenda, otherwise the chairs will choose relevant topics. Items in tickets or from the past month are all fair game. Thanks, Seth, Tim, and Alexey --0000000000002ab85905aae3c968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have a session on the books for IETF108, and would like= suggestions from the group for the agenda, otherwise the chairs will choos= e relevant topics. Items in tickets or from the past month are all fair gam= e.

Thanks,

Seth, Tim, and Alexey
=
--0000000000002ab85905aae3c968-- From nobody Mon Jul 20 15:05: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 0CA4C3A1001 for ; Mon, 20 Jul 2020 15:05:33 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 83de2DdKh_uY for ; Mon, 20 Jul 2020 15:05:31 -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 425EB3A1007 for ; Mon, 20 Jul 2020 15:05:30 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2048.outbound.protection.outlook.com [104.47.66.48]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QDS00GLQG15DI40@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 20 Jul 2020 17:05:30 -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.7.20.220017, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.18.5740001, SenderIP=[104.47.66.48] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wh5rGWiv4zPyIMAY8uCUuqWNGeit+ZAKA9qvEi3VCgwgrF4HGuttu3N5nR5DFBvY+JXEptuP22ZN7XY9mxp1jIxol+Ql+rUsVFV/fnvfoQ5d3ZlybFYDYxAfPDY/BAw0JF0urrd/J/0BjdRF1PDf7eKmOf2AYxyIu1z3PaXwUcedYFwpZb425ZSmltppk8KZxoUHpRwywNfp1RoIvKtO/OIOSa8K91O41L90sTjd2SqHc7HpLMpaj19Yfgne3q+moaNZPmlOBwE8DGqaCqhu3AVUar7kUoOqPAH2D5YTwHbWuNmhL1Q/cz7jA26B3GSgU6eKQ8tNLrX/tlGJThQ0vQ== 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=Hj8m1TOr74/5jAjYnLdp4mSAHDcEnGsXJbaPi0NcigQ=; b=T1QS30jeCduk5jMhbWiuecemLvsMLyC0kzZBZyd3pfhAuiz1I1wDfbOTvdm9OHaoi0emMUBMlGkB1XFE7Vohlb9EwmXeoJnoaB9yQm9Cb0RALSv4B6bs1lIs65x2y8GDML4YpbZZdX2LcMoPoMEvypkRuHwkU/5Olu5GCQd0BTs/v48GPvJwf4vAbHzAzwLT0huEwbN4Nl8lACSc4DvBF0xS4AY4niZ4KOb8EfLqthBIe2Jj+ikg4ZTGZqs/0aBXdZl6+pC9kBhbPcu4Lxhi5k/10c4Zf9nsZOPfDhuB1sFr8aZiWEeLPtAUupYO89Dgc94OooXNOg/hq39qWXGJzg== 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=Hj8m1TOr74/5jAjYnLdp4mSAHDcEnGsXJbaPi0NcigQ=; b=L71yjmFBdFy2OUx6CtCCWLXvzXPC67fEchi4rb2Jo4EHloZI/QiS9Q8rBaiNvNJjXVZLTURHrdrcmtcQ8iaUcd4D7cIRxpQ/tFSW2rGQIinIEsx91sFJAOHEcBWzwbS0T7jaTAK+1z+uzuwj2HxN1rSzafWrQsgZ7xRrqWpNbMs= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB6217.namprd06.prod.outlook.com (2603:10b6:5:125::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Mon, 20 Jul 2020 22:05:28 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3195.025; Mon, 20 Jul 2020 22:05:28 +0000 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Jesse Thompson Message-id: Date: Mon, 20 Jul 2020 17:05:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR16CA0029.namprd16.prod.outlook.com (2603:10b6:610:50::39) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR16CA0029.namprd16.prod.outlook.com (2603:10b6:610:50::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Mon, 20 Jul 2020 22:05:27 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d5826bec-24fa-4b88-2c0f-08d82cf90315 X-MS-TrafficTypeDiagnostic: DM6PR06MB6217: 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: 3m11P/xPIGHurw4xmuDs3p3Pbf08xR0F5DFQUkG+TRRbr+oIMzScTyhmPOmmIQPoT0w5HNSs6nSztUBGizDWAQhfa4tZVhJrBzzSOKt+QqT1SGuBChN8/wgAoT2OdPCCHnO4eUhaVnwJf021JQ4EmMj3M5imylVCF/FHDc27elTeE/ZPPDSv5g7706Ev07QaqGD9+TJvIf9z3fX9dPzuUe5LCFXRuwb4/C6IVIlhgrX7aFJOsaqriXsBUBy66jI9BJsieXPYAADJ9FRh0RmL1toViOA+w8Jv00j5wQllX1lvpDdi2VAikDYFGZ9FyF94jGuoBo17yx41i9Iy3IjPlQxNKDuYR3Jzkm+5ZuVMXjtFk3YB1y/LhdsJVx6KecIERxjzo1Y1xFLBBigSmFnX3yJYoQyiQB2RxklBi88ltyQ= 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; SFTY:; SFS:(136003)(396003)(346002)(376002)(366004)(39860400002)(75432002)(8936002)(31686004)(316002)(786003)(16576012)(26005)(16526019)(6666004)(36756003)(186003)(6486002)(478600001)(2906002)(44832011)(31696002)(86362001)(8676002)(6706004)(2616005)(956004)(66556008)(66476007)(66946007)(53546011)(6916009)(83380400001)(5660300002)(15650500001)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Lpzc57XB2uU79EPqurefseuQOKMM+zYhMZp+3gpHcqka0ThBSmsCcGVeRf6zKZlEs/QlWbTXnYPT0XhuRhY3nKPpDT4wdbfbW1hcG4dsPLUA4uTunWlMX87AIkDYgXQL4dNxVGLEZpenaTXlxpJtWzoOCGHFDcwPn38bIlJOkmryKMru8pWC6i24LWqKAsVV89dhC4xUeaonDvcB5wN9UNQrYEjG1mRo6+6tF1HnctUl9Lzy9vgdBCVZPPI7lZ9SzS+N5+qjC0OXuus46VarJjNZOdxZK+QVx87xYxcEbZuIES2Zqhuk6BIJWeaKR02zJnpshHhjhIpq0vCYPUZ/ZL4VRi/t4qHT1ggeRSxfDkUSGdeG9vQfHS+9+w7jcg1ibmZzG4zgaVlxHcHveI0OddQa/38dY2QTpFnt5b7Mp4c2KYsYKQs15MxQ6wscqkf6+RTuMUpojtSZ63TpeuS06jkPtpQLYRs3d6vcMr7Nipl9c+AZ04qg0uTFcuLQACuV X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: d5826bec-24fa-4b88-2c0f-08d82cf90315 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2020 22:05:28.4962 (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: wk0Et5iWhgyoAHIuiKERu+eEA2s8B4gDfai84y7M/T0unxgaIwkB2LlJFBrC9SoU74XVdKb2frvr2vshzIr82g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6217 Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 22:05:33 -0000 On 7/19/20 1:33 PM, dcrocker@gmail.com wrote: > The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users.  Really.  Nothing. > > To the extent that anyone wants to make an affirmative claim that end-users /are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*) I'll take a shot (admittedly, I'm having trouble keeping up with all of the points that have been made): We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC-ignorant to one that munges the From. It rewrites the friendly-From in addition to the From address (this touches on Laura's point that even though some/most MUAs hide the domain, recipients still *see* something different) We have a DMARC policy published for our 500ish domains, and an increasing number of the domains of our external list members are publishing DMARC. DMARC enforcement (outside of our control) is also increasing - which motivates us to accelerate our transition to the DMARC-friendly MLM platform (one that rewrites the From) ** We have had many complaints from users about the From munging ** I could try to quantify, if that's the only way to prove the point that end-users matter and are relevant to this conversation. It calls into question whether we (or any domain) should publish DMARC policies. Gmail.com doesn't publish a DMARC policy, after all, and many people (such as some on this list) are using gmail.com to subscribe to lists, and they don't have to suffer the consequences of DMARC. Why should the rest of end-users suffer? (some might say) Granted, we are a university. Maybe these are just faculty being hyper-sensitive to how their messages are appearing to their peers/students. But isn't that enough evidence that end-users *are* relevant? With time, maybe we can change these end-user expectations, and From rewriting will be the new reality that people will accept. The To-rewrite strategy seems interesting, in a "From-rewriting is here to stay" assumed world, to force MUA behavior and to help mitigate the auto-collecting address problem. I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary receiver will trust their non-munged mail. Giving the receivers a way to un-munge (if they can and/or want and/or trust) would be a productive path forward out of this situation. I think that we just have to agree that From-munging by MLMs is a permanent reality. It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented. Jesse From nobody Mon Jul 20 15:47: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 57DE33A1063 for ; Mon, 20 Jul 2020 15:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3aVb0jBdlnU for ; Mon, 20 Jul 2020 15:47:05 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 840843A1065 for ; Mon, 20 Jul 2020 15:47:05 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id p25so9381778vsg.4 for ; Mon, 20 Jul 2020 15:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=slS56rBgHok4+oQASj4nOpaLSf6za7UpAmJwW4yoeJY=; b=oaicn7sZikFWuBL6lIh7wIxXHkFzI71jghBnV6fL5+IKoBTS71CZIf3PUVcSxhdLcG Y1LsU6uZKJ7w6Rz4UwEqvYfSAS6RtTv9sdlrcHXgEPUwgEGLK4rd0gLYdk4wbAtOCPd2 P9LI/v5X4mE7mC5pmnv9s/any68a6xVJRlRrKf/o8ZVzwcvfmRioEBOS3tH4CkkyfWTV 7fQV2kzJ6Eo6UU2UyYVkUBlolGUp/6axdYGtsMZMVzD0K5NFMnFOavrha74y0oPQlbg7 5m1h0yiliFbb8uIPEHlv4Zz7d5caHCHf/2YBzHLG0Ryos12QNHXfcM1DQCDpIOH/uWF/ FNAQ== 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=slS56rBgHok4+oQASj4nOpaLSf6za7UpAmJwW4yoeJY=; b=iqGn4Lbyw+t3OqQ6kdNuhEqUNKPBdV8WoUwEN54IH25c1EKOWl5Ec8g7hmeFHDfWTY KS3HzwX7nDOFLUDOHuHQ/BAzIPj9MkYW0y91pVb4FGM0JMquVSeSnrkl9V5s4Pdsg4Ci 3zS7VQTEWQsh0BlrEoRuWXfvz4l5yi1Ks/8u81PsXq+N5S5wDZUDIyZvYrX2Ms0XORTT fw0j0icxFSbmIIwF681sIDy5S8sAnxPG8LW2UvZIKs6LSVcB1TcwK/AuAov/XbIyWfGa oUfXpi2VIAn2lsNQTkogjAyVZhcYq5WPitLeQmHDnXggZxfcIYSLTyPuqPTT5WtV8HtS /fyA== X-Gm-Message-State: AOAM532C4bBaRwoGCBKpLzCCoM1caeGpQsNwLvWMzI8s0NCSyQ9Te6O5 kx8SnOdGAOdXhicXxhjC6wk6qtnAUVx0r5dgKelj X-Google-Smtp-Source: ABdhPJyEVF7/sMv1fLN2GCec9XTVjwTil8EZ/9ohVifJay5N9xsZ8KKf9HiZzBWLv4ggylFsa2+iUBCM3RhAcM8mUCY= X-Received: by 2002:a67:643:: with SMTP id 64mr18491591vsg.32.1595285224084; Mon, 20 Jul 2020 15:47:04 -0700 (PDT) MIME-Version: 1.0 References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> In-Reply-To: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> From: Brandon Long Date: Mon, 20 Jul 2020 15:46:52 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000019476a05aae7496d" Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 20 Jul 2020 22:47:07 -0000 --00000000000019476a05aae7496d Content-Type: text/plain; charset="UTF-8" >From the abstract: "This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed." The mail from the same "author" is not treated the same because the message has been modified in an unknown way. It's not the path that matters. As for the changes suggested, the draft doesn't speak to the intermediary problem directly, but presumably you mean that an MLM would replace the Sender: header with itself, and then DKIM sign as itself. In fact, any originator could generate "original" mail (in the sense of the old days of email greeting cards and "share via email" web forms) with a >From of anything as long as the Sender has an aligned signature. And publishing the special record allows any originator to override the existing policy provisions that DMARC provides. This seems like third-party authentication without any authorization. This proposal seems equivalent to removing alignment from DMARC, since the message can now be signed by anyone as long as they put another little bit in dns and another header on the message. Changing the trust anchor also won't help the forwarding problem. Imagine that an anti-phishing filter learns what "good" mail from random.bank looks like and associates that with their domain as a trust anchor. As soon as you forward it through another service which switches that anchor, now you're limited to knowledge of what goes through that anchor. Maybe that's ok. OTOH, if part of the benefit of DMARC is the policy hammer, do you lose that benefit because anyone can override it? Another way I'd think of this is that DMARC says "there's one true source of this email"... and adding Sender into now brings in multiple concepts of who the source is. I think this makes the problem a lot more like the discussions we've had over having multiple From address domains on the message, which wins? Now others are talking about p=no-I-really-mean-it again. Your draft also implies that adding a Sender header changes where the report goes, even on auth failure. Brandon On Sun, Jul 12, 2020 at 8:20 PM Dave Crocker wrote: > FYI, > > I've posted an initial draft for having DMARC use the Sender: field: > > https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000019476a05aae7496d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From the abstract:
=C2=A0 =C2=A0"This affects end= -to-end behavior of email, between the author and the
=C2=A0 =C2=A0fin= al recipients, because mail from the same author is not treated
=C2=A0 = =C2=A0the same, depending on what path it followed."

The mail from the same "author" is not treated the same because= the message has been modified in an unknown way.
It's not th= e path that matters.

As for the changes suggested, the draft doesn&#= 39;t speak to the intermediary problem directly, but presumably you mean th= at an MLM would
replace the Sender: header with itself, and then = DKIM sign as itself.=C2=A0 In fact, any originator could generate "ori= ginal" mail (in the sense of the
old days of email greeting = cards and "share via email" web forms) with a From of anything as= long as the Sender has an aligned signature.
And publishing the = special record allows any originator to override the existing policy provis= ions that DMARC provides.

This seems like third-pa= rty authentication without any authorization.

This= proposal seems equivalent to removing alignment from DMARC, since the mess= age can now be signed by anyone as long as they put
another littl= e bit in dns and another header on the message.

Ch= anging the trust anchor also won't help the forwarding problem.=C2=A0 I= magine that an anti-phishing filter learns what "good" mail from = random.bank
looks like and associates that with their domain as a= trust anchor.=C2=A0 As soon as you forward it through another service whic= h switches that anchor, now you're
limited to knowledge of wh= at goes through that anchor.=C2=A0 Maybe that's ok.

OTOH, if part of the benefit of DMARC is the policy hammer, do you lo= se that benefit because anyone can override it?

An= other way I'd think of this is that DMARC says "there's one tr= ue source of this email"... and adding Sender into now brings in multi= ple concepts of who
the source is.=C2=A0 I think this makes the p= roblem a lot more like the discussions we've had over having multiple F= rom address domains on the message, which=C2=A0
wins?=C2=A0 Now o= thers are talking about p=3Dno-I-really-mean-it again.

=
Your draft also implies that adding a Sender header changes where the = report goes, even on auth failure.

Brandon



On Sun, Jul 12, 2020 at 8:20 PM Dave Crocker = <dcrocker@gmail.com> wrote:=
FYI,

I've posted an initial draft for having DMARC use the Sender: field:
=C2=A0 =C2=A0 =C2=A0 https://datatracker= .ietf.org/doc/draft-crocker-dmarc-sender/

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000019476a05aae7496d-- From nobody Mon Jul 20 15:51: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 08B423A1073 for ; Mon, 20 Jul 2020 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdXOD7KLgjQk for ; Mon, 20 Jul 2020 15:51:48 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 260093A106F for ; Mon, 20 Jul 2020 15:51:48 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id x13so9355004vsx.13 for ; Mon, 20 Jul 2020 15:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rl0sP3ZGdNFQ8s9cYTaAKJe4emYzTThsslejVbpg1QE=; b=PZtxohFMrBmdWseqMEel26/e6hqht8y4FHTwuZVWarYWtJl8gmmd4vuD4FbRXs89XM tZ3iaEGssEZ4S1O6dCxEd2qdXP7msRxengUatcf5N8Ds2xHKT6q9uERSRM89RRzzF53j wHpD+hsFr7dSn0rflKaATrgf7msUVxp7P8UaxH0zDtPEZRon7wqTSy38wVzpqwNWW0ZP dfqIZb4+CnT70LSqpYh0enFcQ9mRzI/ittxpN5fXDmsORuMqMo/Ci+1wnOZJyLp9cZhm w0sWLbe6iqMsDjSPqD+rFxfSGEX3OKjA91FENeOYg79qTZsZPvc01OEVblHZfBAl2EES 6GQw== 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=rl0sP3ZGdNFQ8s9cYTaAKJe4emYzTThsslejVbpg1QE=; b=V24zKEivlruCZOCI3KMuz+r8TA6fMAimBtH8s3zdZHcps0F71zxWHt/ZdNawZz3enU Z1kA69X33M30FckWREI3hiMDGdIzMIPF6A6cy+s1xvPeORV9ARdSlzC//JVw+6KOe3Dj QZnfkKVYc8RQLrvL0LHcKxQb0Y6VMhHShZSFdRtO6NY/KUJKbKg2cl7Z/D6akfP43T/3 /09u/1mNYsOFoAGqVWqYeRMrdYyINU4fMWIYmX17scDRsnVqEN6oU45o5aCpWqKeOJ+z m+U4EqcbfKLVS7XnxPFU7EHANk/U22/w0k7JoQ6NNTAAAHgL2hBayoOzGFmdVM7h3jL9 RMRw== X-Gm-Message-State: AOAM5316Gjly5ziF+ZpLMTel8cbx1hUuTQsk7SoxswcTsf6oE+njO/Hu LZl6INkSSzp57NedjW6tDkpi6/MPJjSXZgc8DPAx X-Google-Smtp-Source: ABdhPJxO0zGu4MpXlWKSfpfvg9by7KN77CU3vRTMmQ2opTVB41cj61t5+M+3xq3utLTAL/CMQMRP5ecpZqmXwfGIGto= X-Received: by 2002:a67:6281:: with SMTP id w123mr17393946vsb.114.1595285506892; Mon, 20 Jul 2020 15:51:46 -0700 (PDT) MIME-Version: 1.0 References: <04ecbbf8-ccff-a771-8e8b-fc2b582b0431@gmail.com> In-Reply-To: From: Brandon Long Date: Mon, 20 Jul 2020 15:51:34 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f495a105aae7596e" Archived-At: Subject: Re: [dmarc-ietf] 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: Mon, 20 Jul 2020 22:51:50 -0000 --000000000000f495a105aae7596e Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 3:46 PM Brandon Long wrote: > From the abstract: > "This affects end-to-end behavior of email, between the author and the > final recipients, because mail from the same author is not treated > the same, depending on what path it followed." > > The mail from the same "author" is not treated the same because the > message has been modified in an unknown way. > It's not the path that matters. > I guess SPF is "path" and dkim is "content", but I think my distinction still stands. As for the changes suggested, the draft doesn't speak to the intermediary > problem directly, but presumably you mean that an MLM would > replace the Sender: header with itself, and then DKIM sign as itself. In > fact, any originator could generate "original" mail (in the sense of the > old days of email greeting cards and "share via email" web forms) with a > From of anything as long as the Sender has an aligned signature. > And publishing the special record allows any originator to override the > existing policy provisions that DMARC provides. > > This seems like third-party authentication without any authorization. > > This proposal seems equivalent to removing alignment from DMARC, since the > message can now be signed by anyone as long as they put > another little bit in dns and another header on the message. > > Changing the trust anchor also won't help the forwarding problem. Imagine > that an anti-phishing filter learns what "good" mail from random.bank > looks like and associates that with their domain as a trust anchor. As > soon as you forward it through another service which switches that anchor, > now you're > limited to knowledge of what goes through that anchor. Maybe that's ok. > For example, if you receive the message via forward, does the trust anchor become your forwarder? That seems like the opposite of what you want. OTOH, if part of the benefit of DMARC is the policy hammer, do you lose > that benefit because anyone can override it? > > Another way I'd think of this is that DMARC says "there's one true source > of this email"... and adding Sender into now brings in multiple concepts of > who > the source is. I think this makes the problem a lot more like the > discussions we've had over having multiple From address domains on the > message, which > wins? Now others are talking about p=no-I-really-mean-it again. > > Your draft also implies that adding a Sender header changes where the > report goes, even on auth failure. > Another thing, there are definitely domains which host mailing lists and original content (ie, any GSuite domain for one), is there are a problem with using the "mediator" version of DMARC on every record? Brandon Brandon > > > > On Sun, Jul 12, 2020 at 8:20 PM Dave Crocker wrote: > >> FYI, >> >> I've posted an initial draft for having DMARC use the Sender: field: >> >> https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --000000000000f495a105aae7596e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 3:46 PM Brand= on Long <blong@google.com> wr= ote:
From the abstract:
=C2=A0 =C2=A0"This affects end-to-end beh= avior of email, between the author and the
=C2=A0 =C2=A0final recipien= ts, because mail from the same author is not treated
=C2=A0 =C2=A0the sa= me, depending on what path it followed."

The mail f= rom the same "author" is not treated the same because the message= has been modified in an unknown way.
It's not the path that = matters.

I guess SPF is &qu= ot;path" and dkim is "content", but I think my distinction s= till stands.

As for the changes suggested, the draft doesn= 't speak to the intermediary problem directly, but presumably you mean = that an MLM would
replace the Sender: header with itself, and the= n DKIM sign as itself.=C2=A0 In fact, any originator could generate "o= riginal" mail (in the sense of the
old days of email greetin= g cards and "share via email" web forms) with a From of anything = as long as the Sender has an aligned signature.
And publishing th= e special record allows any originator to override the existing policy prov= isions that DMARC provides.

This seems like third-= party authentication without any authorization.

Th= is proposal seems equivalent to removing alignment from DMARC, since the me= ssage can now be signed by anyone as long as they put
another lit= tle bit in dns and another header on the message.

= Changing the trust anchor also won't help the forwarding problem.=C2=A0= Imagine that an anti-phishing filter learns what "good" mail fro= m random.bank
looks like and associates that with their domain as= a trust anchor.=C2=A0 As soon as you forward it through another service wh= ich switches that anchor, now you're
limited to knowledge of = what goes through that anchor.=C2=A0 Maybe that's ok.

For example, if you receive the message via forw= ard, does the trust anchor become your forwarder?=C2=A0 That seems like the= opposite of what you want.

OTOH, if part of the benefit o= f DMARC is the policy hammer, do you lose that benefit because anyone can o= verride it?

Another way I'd think of this is t= hat DMARC says "there's one true source of this email"... and= adding Sender into now brings in multiple concepts of who
the so= urce is.=C2=A0 I think this makes the problem a lot more like the discussio= ns we've had over having multiple From address domains on the message, = which=C2=A0
wins?=C2=A0 Now others are talking about p=3Dno-I-rea= lly-mean-it again.

Your draft also implies that ad= ding a Sender header changes where the report goes, even on auth failure.

Another thing, there are definit= ely domains which host mailing lists and original content (ie, any GSuite d= omain for one), is there are a problem with using the "mediator" = version
of DMARC on every record?

Brando= n

Brandon



On Sun, Jul 1= 2, 2020 at 8:20 PM Dave Crocker <dcrocker@gmail.com> wrote:
FYI,

I've posted an initial draft for having DMARC use the Sender: field:
=C2=A0 =C2=A0 =C2=A0 https://datatracker= .ietf.org/doc/draft-crocker-dmarc-sender/

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f495a105aae7596e-- From nobody Mon Jul 20 16:05: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 0C4CB3A1088 for ; Mon, 20 Jul 2020 16:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk6qjwaaO-Ke for ; Mon, 20 Jul 2020 16:05:25 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 5B3203A107A for ; Mon, 20 Jul 2020 16:05:25 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id m6so9375873vsl.12 for ; Mon, 20 Jul 2020 16:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ya4GLjdrIJJwJktKKeF4d+elzy1dxHZRULjUWCxCHvs=; b=gNzr78QID90QqxPRDoMIw3TNCYBev6Ig1L0hBxUKSZdFCDQMG6azO6ppwaP70iouqL JAAvGl2l1wwTSZilJBrDz83vn2NFRvesRBnd8FewnNWxUYSOzf9UCx1hk4j3VPdQjgaY tOa07YBT2TCr58O1OTglhNRZw9g2GeId3LzZfNFv9L+qH0TQDGgAKY9R8N5rwODADX4g /ZlMjSOuRuc69fQI81DnklocoG43mx20J0ri4UdYuYRGs1RESLn10Dh4yIi944Xdb83P iJUmKtpoj6XkAvUN2+oqzWvvrItiabuuHvfYf3cT+pTBsz3Lb6d0F0zMKxrtXshfZa6L nP/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ya4GLjdrIJJwJktKKeF4d+elzy1dxHZRULjUWCxCHvs=; b=AvO2MaqDyODFqIrWo2Mp4k2D3SkqPtHX4BioCxb1EdYnM5bDRmwi7jSj0UPnxdp9Sc BIWTwZk/N0chJXYkPazyfh+PBPCUGCVY24dDcv6zkWZTueDHklg8rPJBC7TwHgJwSk+s PCToemHC/11eo4n+im9IEonDkT1V82HN7mFpM9luMr58OAJ5aDNgiA2L2CtjmBHnenEu ooSHAH/dFMz7mjpmT8k9Fa4qbsjNOw93SML8I7PScXmemWlZttW1SYJzf4nq36lsb2/l JJgYArqBUeH0kMtcTI+ULTDHpdk/TjA/9YTNSIlGlXf42fwwwyCh8zsW6mIR/ZB/ODil 0Y2g== X-Gm-Message-State: AOAM532Nv6IRLCuNwM0rvjJT1tYwgZm5j07ogAh6v9vM+tDCb9Ss/n0l RpA4wqIuGQ2EDIV7oMMuit1Kq2BTYPajWmeHTK/mTTA= X-Google-Smtp-Source: ABdhPJzsyWJhaS6/ksXz1lYfN33JzkYb3iGjzs5lbudOvjDxITkwH5jt02eLVQ5oi6FbbgpBS77Gguxtt5lLEKEr3vc= X-Received: by 2002:a67:6281:: with SMTP id w123mr17433200vsb.114.1595286324042; Mon, 20 Jul 2020 16:05:24 -0700 (PDT) MIME-Version: 1.0 References: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> <96e11fae-99f5-b552-b959-6adf9d085a42@tana.it> In-Reply-To: <96e11fae-99f5-b552-b959-6adf9d085a42@tana.it> From: Brandon Long Date: Mon, 20 Jul 2020 16:05:12 -0700 Message-ID: To: Alessandro Vesely Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a9646b05aae78ac0" Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 23:05:27 -0000 --000000000000a9646b05aae78ac0 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely wrote: > On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote: > > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely > wrote: > > > >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From > >>> domain truly matters. > >> > >> While the opinions of big players are relevant, you yourself mentioned > >> that they tend to follow DMARC design. > > > > > Sorry, I said what? > > > Google strikes me as the kind of place that would make a decision > about what to show users based on data, so I was wondering if they > have any, because I seem to remember them talking about this back > when DMARC was in development. > [ > https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/] > > > Brandon hasn't chimed in, yet. I Cc: him. I'd guess he can confirm that > efforts to highlight the domain name in From: addresses, if any, are > inspired, > or at least encouraged, by DMARC development. > > By hijacking From:, DMARC tweaked email core somewhat, for the good and > the bad > of it. We can either go ahead or retreat, a threat analysis being needed > to > make that decision. > I don't have any information on that, I was never on the abuse or frontend teams. In general, UX changes go through review and user testing, but the bar for such changes might not meet the rigor being asked for. Yes, we continue to make changes to the display of the author of an email address with the understanding that it affects the handling by at least some of the receivers. I think everyone understands no UX changes are going to stop all attacks, but I don't believe anyone has shown that changes have no effect at all. I've invited some folks internally to these discussions, perhaps they can add to this. Brandon --000000000000a9646b05aae78ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 1:42 AM Aless= andro Vesely <vesely@tana.it> w= rote:
On Sun 19/= Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>>> Still unresolved, IMHO, is Dave's point about whether the = RFC5322.From
>>> domain truly matters.
>>
>> While the opinions of big players are relevant, you yourself menti= oned
>> that they tend to follow DMARC design. >
>
> Sorry, I said what?


=C2=A0 =C2=A0 =C2=A0Google strikes me as the kind of place that would make = a decision
=C2=A0 =C2=A0 =C2=A0about what to show users based on data, so I was wonder= ing if they
=C2=A0 =C2=A0 =C2=A0have any, because I seem to remember them talking about= this back
=C2=A0 =C2=A0 =C2=A0when DMARC was in development.
=C2=A0 =C2=A0 =C2=A0[https:/= /mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/]


Brandon hasn't chimed in, yet.=C2=A0 I Cc: him.=C2=A0 I'd guess he = can confirm that
efforts to highlight the domain name in From: addresses, if any, are inspir= ed,
or at least encouraged, by DMARC development.

By hijacking From:, DMARC tweaked email core somewhat, for the good and the= bad
of it.=C2=A0 We can either go ahead or retreat, a threat analysis being nee= ded to
make that decision.

I don't have an= y information on that,=C2=A0I was never on the abuse or frontend teams.=C2= =A0 In general,
UX changes go through review and user testing, bu= t the bar for such changes might not meet
the rigor being asked f= or.

Yes, we continue to make changes to the displa= y of the author of an email address with the=C2=A0
understanding = that it affects the handling by at least some of the receivers.=C2=A0 I thi= nk everyone=C2=A0
understands no UX changes are going to stop all= attacks, but I don't believe anyone has=C2=A0
shown that cha= nges have no effect at all.

I've invited some = folks internally to these discussions, perhaps they can add to this.
<= div>
Brandon
--000000000000a9646b05aae78ac0-- From nobody Mon Jul 20 16:14:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F303A091D for ; Mon, 20 Jul 2020 16:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKY7zX81AEke for ; Mon, 20 Jul 2020 16:14:24 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 E24983A0914 for ; Mon, 20 Jul 2020 16:14:23 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id p25so9410501vsg.4 for ; Mon, 20 Jul 2020 16:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M0biaHuq++YRZwsIvS94gyXRn8k0sPxlFQoi+fTro3Q=; b=V/YSw3FVDVyBG9IrZ7H9v9SOhMtTX0baVkPzBaPnjMAlVsAWrSwsoRW+ejdSfsfb44 QNtkS5ghkzfcxGUX1fAi94Rzyout750I/31lXh3sBYJ2JmmpTXrYihHRAazfyXfPrUx1 FPDB9+7e5sM2MsGjUsQ4JBgP1Y5xaMPpIzCwo8sruHkhDyafG6YGgbfk+34ijxePCBSb A/3YNlXLAQCgy6ghZCXjVgBOGNSEvqVu7DAy5i8JwvVgJPBwNPfImWauOXD4Rp3pC+6G Lhbm2aRaOcP+UA6HC5igW44P7tmFRBlnY7+0Zc8fPod2trKfCHF8U2ru82vD8Csvy51l SWdQ== 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=M0biaHuq++YRZwsIvS94gyXRn8k0sPxlFQoi+fTro3Q=; b=KwMm0pB5fAMNeenoDeLCKfFfyCtWVkNq5CipZyCn5c3n+nZvG7yff+tELCMSpBypaP ohrO2zOmhpsvXBTZ7C89zv1da1xeQ4mh5H9tX2XuHhX3bgk0lOpOWtltOfyrcSSMGUBO nTE5ubxGc7cWvZoVVNUX/lF7zAEpIgAmmhEUXKONFfnct+B+D7gUdanf1gNKMaSpwivs FfjBtFsc/z1uxvmC/G27mP3JhacP+n8e9JZQwXUhUi9XhpH2ebsNI6dZw+l0+ulnMZlN mZOvnm3QD5bhJddlDrAb7fllreOC+McpzSngebPBc3N4+qCohlgCgdSncX21steKW2Tr LHRQ== X-Gm-Message-State: AOAM530izMxJzmbTmLgJmybAcW654ESxIM46Dqn+hVOF8Kxzx0N8zs9j KRWn1ONVGv/92HiVxK4AWge78CQe9gN9UWCDO1LAOJU= X-Google-Smtp-Source: ABdhPJyaNLAFidq9baupTC+zi3ueOXisMUN/Rrz/1Z38Et9ppDQIImMGMUwHHCYm3meHeWbo2pXgyS0834rIwyWpMpk= X-Received: by 2002:a67:6281:: with SMTP id w123mr17460044vsb.114.1595286862181; Mon, 20 Jul 2020 16:14:22 -0700 (PDT) MIME-Version: 1.0 References: <20200719144650.E65433A0475@ietfa.amsl.com> In-Reply-To: <20200719144650.E65433A0475@ietfa.amsl.com> From: Brandon Long Date: Mon, 20 Jul 2020 16:14:09 -0700 Message-ID: To: "Douglas E. Foster" Cc: IETF DMARC WG Content-Type: multipart/mixed; boundary="000000000000bcf42905aae7aa11" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 23:14:26 -0000 --000000000000bcf42905aae7aa11 Content-Type: multipart/alternative; boundary="000000000000bcf42505aae7aa0f" --000000000000bcf42505aae7aa0f Content-Type: text/plain; charset="UTF-8" The decision is complicated. Ie, from this thread, John's spoof didn't get caught (but note the image isn't his) but Dave & Douglas were treated differently: On Sun, Jul 19, 2020 at 7:47 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > > Yes, Gmail is a win for Dave. User has to hover to see the from address, > instead of friendly name, except when the TO does not match the recipient. > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000bcf42505aae7aa0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The decision is complicated.=C2=A0 Ie, from this thread, J= ohn's spoof didn't get caught (but note the image isn't his) bu= t Dave & Douglas were treated differently:



On Sun, Jul 19, 2020 at 7:47 AM Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:

Yes, Gmail is a win for Dave.=C2=A0 =C2=A0User has to hover to see = the from address, instead of friendly name, except when the TO does not mat= ch the recipient.



___________________________________= ____________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000bcf42505aae7aa0f-- --000000000000bcf42905aae7aa11 Content-Type: image/png; name="Njji5tVVfFo.png" Content-Disposition: attachment; filename="Njji5tVVfFo.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kcv4ljuf0 iVBORw0KGgoAAAANSUhEUgAAAl8AAAG6CAYAAAA23iOxAAAgAElEQVR4Xuy9D1zV5d3//zzA+QNH EFKJwhbkUir2C73vBdu0kXclS73HtBZZfANdelrKUCrwFhlDnJBDCamOLpVuNsO7dNzT+mI2o3Qb tN3C7pGBfRVWkAgaR+DA+c/vcX3OAQHFP/kv1/V5PHiInM+5/jyv6/P5vD7v9/t6X6q+vr4+5CEJ SAKSgCQgCUgCkoAkcFUIqKT4uiqcZSWSgCQgCUgCkoAkIAkoBKT4khNBEpAEJAFJQBKQBCSBq0hA iq+rCFtWJQlIApKAJCAJSAKSgBRfcg5IApKAJCAJSAKSgCRwFQlI8XUVYcuqJAFJQBKQBCQBSUAS kOJLzgFJQBKQBCQBSUASkASuIgEpvq4ibFmVJCAJSAKSgCQgCUgCUnzJOSAJSAKSgCQgCUgCksBV JCDF11WELauSBCQBSUASkAQkAUlAii85ByQBSUASkAQkAUlAEriKBKT4uoqwZVWSgCQgCUgCkoAk IAlI8SXngCQgCUgCkoAkIAlIAleRgBRfVxG2rEoSkAQkAUlAEpAEJAEpvuQckAQkAUlAEpAEJAFJ 4CoSkOLrKsKWVUkCkoAkIAlIApKAJHDNxFfHKRM1f/9fGj6p51jr57S3Hae9rQ2txo8bxoxl3Nhg brzxRibdfjuT/7+7GR0QIEdLEpAEJAFJQBKQBCSB657AVRVfJ774gt+/W0HN3//GsdYWvAGVy4VX n0v5F1cf3d09OJwurDa78uNUqRjl78+ECbfzL5On8MO4HzBuzJjrHrzsgCQgCUgCkoAkIAl8PQlc FfF1suMLfv/O2+x9fx8WqwWXww4OBzgd9Dls9Il/nU76HE76nH1Y7TbM3T309FrQ+Om5KXQ8qH2w 2h14+aiZM/tH/GjmLMbeIEXY13Payl5LApKAJCAJSALXL4ErKr5OfnGSt955m7/U/hW7w47dZsVu tWKzWHBYhAiz4bRb6bNZcdmsOO0O9Hq9QrPHYsHca8HZB6PHjMV3VAB4+2B39eHo6wNvb35w/w94 /OEEggIDr98RkC2XBCQBSUASkAQkga8VgSsmvux2O9v+67fUfVSLv96P423HsFlt4HQqbkZv+pQf 8buwfrnFlw0/X190Oh14edHdY+FYWxsWu4MbgkMYFXgD9r4+jrW34631xe6Ef4t9gGd+YkCj0VyZ gWsu4Uf3rqa2v3TNWG6LuZ+nn3+Oh++8RnFonYf47arVbHmnlqNWGDs+mgcNK8h6eALaK0KhnTcf +y7PVY9l3o4/s3ryFankq1Go6UN+vfbXVDYF8sgLa4kP/Wo0S7ZCEpAEJAFJ4J+HwBURX6c6T/Hy xg2YuzoI9B+Fd18fXZ0mbFaLIrCEy1HEe2nVKrQ+3qhVKrxF3BcufLxU2B0OXIATFafMPbSd/AIf Xz360YFo/EbRbbXT5+2DzQWd3T2MHXcT2emZBI6+AhawAfHlT+gd4wnobOZISxc2zW0kl7xBVsxV FmDWQ7wy5xFe+NgG/qHcMQ6aj7bQhT/3vvB7Xnt4/BWYnddOfHW+k8IDJTHs2DaPC+6Z6R2yn/sb DxQ+x/fchtQRjib+WN5C6EPfI8yj3ZtKnmF1+yOs/lkswVdIz1+BAZJFSgKSgCQgCVxHBC67+BIW r1VrVmHtMRF8w2gCdDrFuiVEltNhx+FxMapcDtReoPH2Vv71wYWqrw+rrZdTXV3YnS5U3j6KyOro MtNjd6D280cfNAZ9QCBmu1NINb7o6qbleDtBo8ewbnUearX68uLvF1/+cyj5Wz7fB5rffJofPf8u J0IT2PnuKiZfGXPTWfvR/tvHmbryQ4h6lt+9vog7tdBZtZKH5pXRMjaB1/evIuayt+faiS86j1DT HMDkO8ddxLiaaDpsZtzEUM6pvcx/ZPXCvXxvUzaxnhM/LEziv29/gdUzgy+iPnmqJCAJSAKSgCRw 4QQuu/jatPVVPq6rYWyAniC9L6M0GnRqb5w2K159DrxVKtReXmjV3mi8wKtPBNrbFFFmt1no6urC y9tbSDEsDgddvVZ67C76fHxQ+/qjHRWAWu+PxQHeOh2neqy0tLZz9NNm/u3703l28ZIL7/2FnHkW 8QVHeGVmHC98PJa52/7Mr2KEIttLfuaveLPqKCcYyx3fTyIrdxEx49r57WOxZFZrmbv1z/zq+1qo yWXq3NdoueNZ3n1rERPaq3klczVb3v+YTsYy4fuLyFqbxJlGtU7eTPoOz30AD7z4ZzbN7re6HWHL onTebB/P/KJCHm5fybfnltEZPYeHrR/wZvO9vPZhPjGD2qjU82ASWStFG90grEd2k5O5gV01R7Fq Q5k8+1lWr5zFBO0w8TWhlpw5j7P1KEQ99wZlT9+JlmbeWZVF/pvVHLVqCb3zAZ7OzeFxoQ5rRmhP P/8jRmbNO8RzHxQh8KD8/wiZH6wl5n0Dd5Tcywfb5jGOTqqMP2OlsYpmxnHnrExezH3wTIuYsHw9 8zce+u1z3CPqMNXy25d+zd5DJhgXxbzUn/Egb7Ni9Rs0nbKD36089B9ruev9ZyisbKcHP0bfPo/V 2Q8yXIKZD5fz8svl1Lbb8Qv7Lkk/fYrvhQoT2Ue89NTLtIf50XIIZgqXZeBhygtfpPyQCfXN3yVK X0v7d9eS/eAVsNBeyFyW50gCkoAkIAl8JQhcVvFV8Ye97Nr9O7zsvei9VYz21TJ2dAAhQYGo6EPj rULj5YWPlxcqnOCw47LblMB7l1jx6HIogfZ9KhUOZx9mq5VOcw9WZx/evn6o/Ubh4zuKPh8dFieo dDp67S6OnzxFy7ET/KPlc55dsoS5s2ZePrhnFV/wfsoUknZ3EZX5Hr+b30n+/T/EeNSfOx54gDs7 q9lV3QL35nGgZC7WLQ8zLfdvhCa/wYGVURx55d+5f+3H3Gao4A/PW3llpnAjwtg7opjAUWo+PoH2 3jz+UDKXofaeQ+RM+yFbW0JJ3l1J1p0jdNMjdk4oH2vwv20Om96ayzszH2HrUY27HuvHVB/tQhO1 grd3JjHBWs2K+59gW4uG0KgoAppr+fiETWnzH1aGsqs/5mvbG8RsfYSUvScY+8B6frdxFuOxUpU5 g8e2taAJvZvJ47s4VH2UrrEz2fhuIQ8ecYuvIe15dxVCs7qPIxhnzeNI5gesjdHSvHUucw+l8MHa 76N957T4CngnhXvXBvDijlxirLtJmbUK7QsfsFZRbIOOIeKrjXeyV7A39BlWPHUn5nfWkr33LrLX xhN6sZYv84esTX0Nv6d+zlP36Pm8fC3ZlbeTXfg4YYr4+iVN3/sPVsy7i0ANHC55hl82PUT2czMZ Z3qHl7Nfw/TIS6y+SPF1qreP7P/uoqLOQqeljx//qy/ZP/RntK/q8s1zWZIkIAlIApLAVSNw2cTX yY4Ons/M4NabgsHajcrai85LxQ3+ekJuCMJLcTN6ofH2wsfbC29VnxJ877BbcTqsivhyOp3YnUJV eeFwCRekHbPFitXVh8tbDWodKq0OvDWg9UOl9aXb6uD4SRPNrW18/rkIxNfy+qaNjB1zw+WBOIL4 qsr8Do9tO8Edz1Xw9nwrb255i3ZtNLPn38v4zt0svGcpe5nJxvpCHuwvI2oF+3fOpOqxWJ6rHo9h 9x5S29OZmryTzugV/G7t/QRwlFeSFrDt6N3kfvAmjw8JdKpmxT1PsO3Ebcp3088nvkLnULIzn++P g853nmaq4V2s0TkceP0xxg2y3okg+vTmp/n2z96FB9bzl42zCGjfwZPTMvhg3JPs3L+IIx7xFX1v KDUf/A1ue5LXdma6rXP9/Q24n7WvryBGa6XmhSdI2d3pttCNX+sWX4PaM3xwjhhnkdy8ig9yx7Nt 3lxqFu11i6pB4muciLezjmPCOCG2rOxOjmLbrA/YNneYS3Kw+DK9xYpnanlg0wq3a9H2IWsXvs3d hdk8qL44t6P5j2t55u27KVz9IG7b1Uf8+qmXUT/3EkkThfgqITS7P0i/id+mrsaU9BLPRAnLmI0/ rk3m7bsvXnwlbzXxzkfWIcge+VcdhQmjL88cl6VIApKAJCAJXFUCl018vbz1VT45/DETxt9En7kL LN34evURoNMSNEqPl7DBeHujVfug9vHGWwV9Lid2Ib4U65cdh9OOzeHC6QKny4XN4cTqcGBxOrH1 qXCofHB5iTgwNV46YQXT0+twcdLUxWetxxXrl83l4kezZpGy8KnLA/KCLF/jaa8qIeeFEt4/1EKX zVO15n421r/Cg/1C58g01r77GO/P/Cm7A4SoyWTcln9nWu7HZ2lrKMk7KskasrLwIi1f0Xl8+Lrb enbohRnMNB51i8WnJyj11ayKZc7WFqJX/YmslifO+Px0o/rdjv1/0RD9QiVlD3tET78b9Sy9UCyD kze6xdeg9pxxqnA1Gtp5YdudrJ1bRdLetW4X5GDxZT3C7hfWsvWDQ7RbwdrezoSVH7Bt3jnEV1MJ zzz/NqYhsYA3u1cyBl6c+Gp7awXPf/JDSlIVZybQxlvPPc8nj5SQes9w8SX+/2sCswt5XFkx+eXF V+izx8/AFaBT8XGujEu7PBe5LEUSkAQkgatL4LKIr5bWYzz/i0wm3jqe0KBAHF0mNC47/mpvRql9 FNGl06jR+KiVf4X48vLywuW0IwL0HXYLDpHzy+lCpPCyO5w4HC7FCmZzObA5UQSYvQ8ceCkizI4X Gr0/TpUPp7p7+PTz4zR/3qpYyrzUWsq2bmHs5ciEP0LMV/79cRiPjnXHcd25m4X3L2Wv9Q7mrV3B w+M/Jv+x1VTTL77gyAszuN/YzgPzHqBm2060897gQO5pF6T/vc/yq3m3DRr9ACbERDNhyGLKfhGk 4YEXD7Jpdr+77QhvPvcrdnWG8nhuJg82e9x8V0R8adBgwyasWG/l833RvpqVTJ1bRkvoTHJXzhzi Kg24815i2nPPL744xAuznsd673j2tj/GXuFyFDQGia9O4yzm1Saz48W5jNda2W2IYtu95xFfbW+x 4vlP+OGmVO4ZvnrxIt2O5j+u5pm3vz3U8vXMy6h/dmUtX2cTX/46FfVSfF3du6WsTRKQBCSBy0Tg soiv1et/RcPhj/nW7RMIHq3HKcSX046ftxd+Pt5oVKDTatGqNWjUanx8fFCp+nC5XIrly2634XA6 cAmXo7NPSTUhhJdwQ4qEqkJ0CYuY1enA6nTh6POiz0eDSq3FofJSgvKPtZ+g/aSJzm6zcu5DD81k aUrqpWM6Q3xZOfLm0yQ8v19Z7fi6iF0SMVbzhGUnhw+FS69zB0/ek8EHg8QXh9byb7M20azRYLMF MG/bn1kdA9Z3Uvm24S26RFlvrVLceCLwfVf7vTx8ljQWzb99mH9b+TeIXsHbJUlM8Kx2/NG8Mo76 z6Tkw0K+f+hM8TXgdvTEoQ1xO277M+ntbrej9oH1HBBux869PDtnNVXjHmPT63M4pLgdRTqL3/D4 BwtYtPsEofN+wx9yo9H2uyi5A8PON0hXlmDW8ub7GmbPvhNtfwzauSxfinXuAeZuFa7KDyh60CMs B4mv5lX3knzUwI4XZxFwZAfPG17A+rPziC9aeGtFNn+6M5X/ePwu1G21vP22iW8nxRJq+yNrk8u5 eXU2j4e5lzsOX+1oa6nlkP12osTnSszXNvyeyuaZe9Q0vbWW1XtvZ8VAzNdgt+PgmK8HGNdeSeHq 1+j5EjFf0u146ZexLEESkAQkga8SgcsivhKf/gneOLl74u2EBAXgZe2lr6cbb4cdPx8vAnx9UXt7 K6JL/Hh7eytB9e4YLztO8eMS2w0p/kYcdmERcyiCzOFyidB8RYCJ9BNWp1P5ceJNj81Br/ixO+i2 2nAAZrOFXouNMcEhGI2bL531QJ6vsdwWFUpAZwuHjp5Q8nzN2/gGq4Xpp/l1fnR/FrW2sUQ9EI32 yF6qj9pAcz9Ff3sFt4Gqlpxpj7C1BRg7h5L9+W63Goc8Afc2NGPvYPIEOFLzMSfGP8lb72ZyRliX tZb8mY9jPCrOv40JAdaBPF/RmW9QNn/CwOrCIW4+ay05gwPu+Zjqj88WcO9PaNQdjGuvpbblLAH3 Isnq+B08eX8GH3SJ2LPfK7Fn/QH3aEKJmhyK9UgtH3fewcp332S+Z/XlOd2OCooXeCC5WVn12K+9 hrgd298h07CSHbWdBETPZdbYWj6+8wW2GYZRGr7ase1DSl5+jcpPTNj9wvhu0k956nuhaDDx4UvZ vPwnO9/7+Us8NfFM8SWC5l+0/5SXnrpLmUtitWPhy+Uc8qx2fPynTxE7sNpxqPjCdpi31r7Itr+Z 8Lv120zkL5geuPiYLxFwn1p2ij8fsdFl6UPEe/3ihwEy4P7Sr25ZgiQgCUgC14TAJYuvf3z2KfMX GwgNHsuksFsY46fF38cLH7sVH6cDX28vRo8apaSYEKLLy9tH+elTiSSqfTiFxUtkue9z4eVy4iOi YyxWzGYz3T1menp7QQVeGq2yr6NLpcLmdNHV20tHZzc9NjsOcYK3D1pff7rMPXR1mzH39lJQtIlb vhF2aWBHyHA//2fP8fjk0z7B5ndW8uyqt6hp1zLhwZlMOPQau4/ewfN7f48nxIqazFjmbGvBf+5m /rL23tPZ6Nur2bJqrZJqoqVLS2jUA6Tm5vCwsCCd7WivZcsLuWx5R5wPY28TGe6fJf3hO1FaNJKl acR0GO5K3KkmfsWumpZzp5qYDEe2PMxDuX+DO57lbZEug2bef2E1+W9+wMcnwP+2aB5+Pof0B8df sOXr0gbqq/5tE+9kP8OfYjeR3Z9U7KveZNk+SUASkAQkgStC4JLFV+l/bWdL6WuEjAlifPAYNC4b 40b5EeSrRe/jha+XCr1Oi9ZbWLy8FAGm8hIbC4FLiC/lN3GIrYb6sPX0Yu7u5osvTnLiixN0nDql iC8//1H4jfJHrRGCRGRlVSvJWHvt7mz3Xj5aNDpf2r8w8YWpE7Oll0fmJTP30cQrAk4WevkIGI1G 1q5d+6ULvO+++3j11Ve/9Pev1BdN76zlpfaHeObx26F2G6sLPyF29Wpmyi2LrhRyWa4kIAlIAtcF gUsWX5lr1vCnqir0Og2Bflo0fQ6+Of4mbrohAF+VCy+HFT+NGn+tVkkzoREB+Mo+jCq6u7sVMSUC 7c09Zjq7u/ns0xZ89X4EBPij0WqwOx2cONlOt7lbEW5arVYJ1rfbnXj7qIVkU9yNIv2EbpQ//+8f nyriS7gm7/72d3huxerrYiBkI/8JCSjJXUuoPNROj+Lu/BnPfE+uUPwnHGnZJUlAEpAELorAJYuv +alLafjkEwL8fAka5YfeB8JvHoe/2guVpQeHuRONykVw0GhUTic+KpWSbkIlMt2rtUome7O5B9Op TjpOmbA7+/DRabA77PRaenD1ObHZbPj4eDN27FhuCAqir68Pi7mXPpUXKi8fJSXFyVNdaEf5K/s+ ftHZjamrm1u/OYk1hZsuCog8WRKQBCQBSUASkAQkgStJ4JLF12M/TeH48c+VeC2Nqg9/jRffDL2J MXotAWovRvmAzluFq9fMyePH6TV346VS4e8fwKRJk9BofRXhdez4cY63tSkJVvUBAfThwtnnZNTo Ucp+jSImzM/PD28vL060tStMHE5h8NJid8Jnx1oV65dKq+XkqU7aO0yE3HIrxa++fiX5ybIlAUlA EpAEJAFJQBK4KAKXLL6++6NHwOVA663CX+3DOH9fwm8ah7e9F5e5E0enCVuX+Omi+5RJSawaGODP hAkTiLp7CqMC/Gk/cZJPP2vmpMnELd/4Bv4B/u6A/D4nWl+tYiUTaSlUXmCzWWk95hZfVrsDH7VO ifk6IeK8lJWPTlpPfoGpu5txN93M1m2/vygg8mRJQBKQBCQBSUASkASuJIFLFl8PJv2E7q5OsNvQ 4SQ4QM/d3wznxlG+yqpHP5ULH4eNIL0WR6+F7s5TWC29jBo1Ch+tFp2fH+aeXjq7u1BrtQQFBSmx Xd4+7qD8XmsvFptNyQvmdDmxiJWQ3T3K34TlSyW2HfJWKxnwu6w2RXi1tLVh6u5hTPCNvL6j4kry k2VLApKAJCAJSAKSgCRwUQQuWXw99mwG//jHP1A57Gj6nARpfYj6Zji33BCg/K5XuVA77Khx4d3n xG6x4rDb0Pvr6em1ohvlR2dXNydOnsSlgjGBQYqbcXRQoGIBc/a5sIlErC4HnV1dmEwmenusSv4v YfUSwsvZp8LW54XY1eeztnZa2k4orsexN4ZQ+vp/XxQQebIkIAlIApKAJCAJSAJXksAli6+frsrj 4N//rogrLU40DjvfuvUWJgSPYYyvGr1XH/7eMGaUHluvmc5TJsxd3XipfZTkqTeMG4vFZud4e7si rERaCrGaUeerU9JL+Pr5ovJGCbLvEZYzcw89PT2K+NLo9Kh99bjwwWTuRWw9/OnnrRw78QWneszc fmckhS/KgPsrOYFk2ZKAJCAJSAKSgCRwcQQuWXwtLyxm74E/4evjhd4LVL1dRNx8M9+8OZixvmpG qVwEaHwYpVFj6e6kp7sLS69Fiefy1mq5MeRGJXHqiS86aG1txVsE0ov9Hl0OvH18GB00Wkk9IVJ7 CTekSDHR1d2NTaSa0OgYNTpI2cvx+MkOumwOPmn6jNYvOpQNtu9/8AekL//5xRGRZ0sCkoAkIAlI ApKAJHAFCVyy+NpS/ns2bd+BjxBLNital4OJN48j6vbbuEGrRtXbjd7LhbrPxamT7Tjtdnx1OtQ6 rZIqwldkv9eoFavW5y3NHPv8c7y94IYxNzA6MBCVtwofjYYOUwdqjQZ/sRJS5UXnqW4l3kut9cPl 5UNHr4VPP2/jyKefYrY7UKk1PPHkAhISnriC+GTRkoAkIAlIApKAJCAJXByBSxZfjc0tPJKahk+f C43Lic7l4ObAUXzv7kgCtT5YTCcZ5QVeDjv2XjM+3l5KTJfFYqHHZlWSrPZYrbSdaKf5s8/A1cco vS83hoQQeEMgNqddif0a5e+PTqdTUlFYLDb6XCocfdDnJbYc8sFstdP0+edU1fxNWfmo04+i7M1y brnl1osjcsbZPRz5435O3TaDKTddXFGflmWT9a6aeXkreHDs4O/2cLA4k6K6iaRsMDBFfXHlXsmz T+19gWfrpvHi0u/gZ/8rBU9v5u/DKvzWwiKePPECz+5sPktTxvPIqhXMPPkaPy2somfIGXfydNES ov2uZA9k2ZKAJCAJSAKSwFebwCWLL9G9Oc/8jJbmZnSqPtROG/5qFbH3/Atj9b70dpxAh4uuE+34 qPrQ+/kqIsput2O12ZQtgUTsl9iLUcRyaXzU2B1idaNKye3VfrJdEV7fnPhNxoy5QYkHczj7sNmc WK12rHYXNif0OpwcbvwHf/zwL8pqx4l3fot33ztwGeif5J1frubID/J5evLFqSS3+DrOTT/4OWvm hpxuS89fKUjfzN/td3/1xdeSPXwrd7h4HCokD6xN58C388mIHaSq6l7jZ6V+pOQ/woTLMAqyCElA EpAEJAFJ4J+FwGURX+s2l/Dmrl2IEHovmwUhp6LvjmR88A1o+xx4O2zgsNFnt9PT3a1smi3SSbj6 +kAlds0WqSXUqFTetLcfx2q1Khnt/fS++On98A8cza233opOq8Xaa1Ey3iviy2anx2qn1yryezn4 6//+nfr/18jxk1/w1DMp/Dx71SWP02vpyzhwshd8ApgwdykZD4TQc2QPr27dw99P2PH7xr8yL3ke 0TedKcyE+Cr6LABO3UJK7iN8w9OaU5XryPoTjD7mR/w6Yfn6iFeWlPON/1jBTGFd6/kzecv+zNR1 y5jqd5hXl73GiVv8ONYAD/78ecbuWEZ570T49DCj5wrRY6d+x3/yauVhTuHHN+55jKcToxh7ZBvP Fvbw5Lqf8C3RvAsQRGdYvqT4uuQ5JAuQBCQBSUASkAQGE7gs4qvl+HESl6Ri6+lG5ejFTwUTbgkh YsKt3Dw2CC+7FW+xaball380NtLWepwxN4xB7++Pj48GP/0otDpfJZGqyPMlLGKdXaewCiHnp1Os YIGBAWg1GlxOFw6Hg66ubqwWBxYhwhwuJbnq3vcqFeHVY3fwx7/UEhx842UY7WGWr55aijLfwC9x GU9O9uXY28Xk/el2MnJ/NCCu+itVxJd9OtFH99CTkM2Tk4QCEuW9wJHvTufUjkYevCDxtYFP71lC 2tyJjFbbqS5exmu9s8h4Zjrf8FNjr3mVZ3f48fR/zCPC/leKfrEN9fx8no78jNfSN2Kfn8tPJqk5 UraCV+xP8qvEiSNyuZbia9OmTRw9evSsbbvttttYuHDhZRhPWYQkIAlIApKAJHBtCVwW8SW68ErJ f/LbN8rwwYGWPgJ8fbjj9nAmht2Czhv8fX3x1Wloa22l/Xg7AaMCcLlApLLX6fzQaLT0Wi2ofLwV q5gQXjaRuFWnwdHnQi+C9EV6CoeDnq5ubFa7Yv1y9YHN0ceJU13s3fcex0+aSDL8lKxf5F4mskPF V8+HG3j23TtZ8x//xmhRg/0wr6W/hvqZ1cwb5l8T4qugZx4rbykn77OZrJl/F+pje8gqPMm81Bt5 45efMPOCxNcb3PScxyqGW3y9F5lLRqzSAug5yTF7ADeNFuLOTvX6Zbw3WXzuR31pNq+ygF8l+vHW L9ZzLMEtxEY6zhvzdUs8a34+g9Phbz2M5HYcHvP1jTm55Dw0ZsS6hUU0PT39DAEmhFd+fj56vf4y jaksRhKQBCQBSUASuHYELpv46uo28+iCZJx2C06LGS+XlZBxgdx+63huCBiF1sebUb46XHYnDruD AP8Aujq7cLlUeHl54+Xlo8RzifgvVCJzvRfe3iqhzhRLl0bjo+T6slosWHt6sfT0Kt8VJ3d29/BR wyc0HD5Ct83OXw/9P0aP9giTS2Y7VHyd2PsCWUcf5OVFUZ6ST/LOL1Zz5N/PjAlzi69H+NXcTop+ +RH35f6Esb/P5hUWsOa7h8j6RSPxSsD9+fK17RkAACAASURBVNyO5xFf9laqy97grYZWeuxgP/UF NyXkKeLM3vAaz5b6kZZ6I9t+eZiZ+R4X5AhcrqXlSzRpuACTwuuSJ7AsQBKQBCQBSeArRuCyiS/R rz+8/wEvvvISXaZ2HNYe/H3VBI8J5Jabb+Tmm27C0duL02bHT6fjphtDsInYLm9vJe+XiPMSFjC7 y0WPpRetVqu4HB1OOzarDfqcdIt4sa5uVCLhlwt8fMSG214cO97Gvvc/wOaCVeuKiZ/7yGXEfB7L Fx7L18IRLF+nHuHFReEcLF7NgcnzGPt/32Js6vM8aN8zRHy9uqz8tHXrjJivc4uvY2+vJq9hOisX f4exwi05YPkaDfaPeDW9HPU9ARw8NY1fLYriXMsGrrX4GizAxO/S4nUZp7IsShKQBCQBSeArQeCy ii/Ro1//53+yfcd/4XRY8Fb1oVP7MFrvx6QJE5SAe7XKiwC9njFBAeB0KJ87bL3YbBYl35eI5dL7 j0aj1Skuxu6eLiXpam+vx9rldKJVaxV4Qqwdbz9J3Uf1fPg/NTyTvoLlWTmXGewp3vtlJtXfzSYt dgzqgZiv5/nJZDWf7jVS8H44aSPEfBUo4usu7HWvsXzLIew3zSTnuXsZLdyPA5avVt76xQv8/bvP kxLry7G9myn4PcwbCLg/t/g6UrqCghMzWLnoX/E79mdefamcnh/ksvIBYf2z8/eN6RTVwLfm55Jy z7nzPHwVxFe/ABP/SlfjZZ7OsjhJQBKQBCSBa07gsosvp9PFshXLqf3fGlT04ePlhdbbC3+dLxG3 346/ny8+fX2MvzkYa/cp/LRqfLxcOB1WJeD+RIcJtc4XL29vZVWjsHbZ7Tb6nA7F2uWl8kaj0aHx 1tDc8jl1H9fzydEm7v7OVErf/L0SL3a5jxN/NJJX+hF+/76CnIdC6GnYwyule6j3rHZ8JHkeU0dY 7dgvvuAo29KLOTHXI4CGiC/oqXuDgi0fcKTHjwmTw7HX9PDgBYovTtXy2kuvc+BoD363fYfoMY18 esv/IeOhWxQUIiD/Zxt7eXJdf44tISh/Qf1Z0mecN+YLiHjC7dJ0HyPHfMlUE5d7JsryJAFJQBKQ BP4ZCFx28SWgfNHRwZL0ZZw8cQKHzUZvVyddX3QwJnA0Ed/8JndOvB1frRrsvTisvWjUXsr/hfXr ZIdJaCwlvkvEeol8YN7easUNKdyM4kObzc7nLceob/iEps+OMSpwLPv+p5aAyxbn9c8wtIP6IOK+ 3p5IjkicqvxZWNo2cOKJ1Twpk3D9kw227I4kIAlIApLAV53AFRFfirXFbqfIWMzmrVtoO/Y5nSdN +OAiMmIS373n2/zL5LvReatw2S10mk7Q3WnC20uFCNx30qdYvkQAvvhXrdYq6SYsvVZMHadobT1O U+OnnPziFP+e8ATZBS8q4kweZxKw93zGgY1GDt7zPGnf81irju1h1aYenvz5mekxJENJQBKQBCQB SUASuLIErpj46m/25pIt/GzpEjTePug1Wuw9vahVKv5l8l3Efu87BOh96XNaoc+Or1ZLW1ubknxV bKotVkGKNBPm7l5Oneqira2dY8eO03qsFY3Wj+V565j7+P+5soSu59LttbyybDNHbnuEtKX3DkoP YafHrsbv4hL2X88kZNslAUlAEpAEJIGvDIErLr5ETz/55DAvvbSB/y7fib2nB5vZjA99TI35V267 NZSg0aMU16PTblPA9LscxXZDHac6OfmFiS86THR39WB3uIj70aMkPZPKbbePnCz0K0NYNkQSkAQk AUlAEpAEJIFBBK6K+Oqv7/PPP2fTyy/xxm/+k66Odrq6bMT8yx3cdmsIAaN0SiLV3u5uJdC+y2ym w3SKU51d9PRacfR58cN5yTxpSCEkdLwcRElAEpAEJAFJQBKQBK5LAldVfA0m9D8fVvG7su384/Df GeXrTYBeg8tmUbLX+2jUqLzV+Gj8mBT1babNmE3EtyZfl4BloyUBSUASkAQkAUlAEhhM4JqJLzkM koAkIAlIApKAJCAJfB0JSPH1dRx12WdJQBKQBCQBSUASuGYEpPi6ZuhlxZKAJCAJSAKSgCTwdSQg xdfXcdRlnyUBSUASkAQkAUngmhGQ4uuaoZcVSwKSgCQgCUgCksDXkYAUX1/HUZd9lgQkAUlAEpAE JIFrRkCKr2uGXlYsCUgCkoAkIAlIAl9HAlJ8fR1HXfZZEpAEJAFJQBKQBK4ZASm+rhl6WbEkIAlI ApKAJCAJfB0JSPH1dRx12WdJQBKQBCQBSUASuGYEpPi6ZuhlxZKAJCAJSAKSgCTwdSQgxdfXcdRl nyUBSUASkAQkAUngmhGQ4uuaoZcVSwKSgCRwbgK21g7sIUHoJShJQBL4pyIgxdcFDmdH5S5K8/ZQ U9WGGTWBUVOYlvooj8aPR3OBZfSfZi7J5Inkj874lvrJDP6rJNr999rNLM0OJ7d8uufGa6MxbyVr mhLZZIwc+K65ahdFhp3U1JtRh4QzJdvAkqTw020aKCea5sIijIU1tLSCPiKS6YVLSIwNUsqy1e9j Q1Ip1bVm1BGRzClMY26s+5Zva9rPFkMp+yvbsevGEZ6QwJLC6YzXiU87OJhXgLHwMCaLnvCExEGf DeuipZqCkDwOnBr09+/PZ0vlbNytOMvRWk1B7C7uqswlLmSAII0lRozZB2lstRMYM53EEgPTwoZ/ v4OK2PlsfH/Q37VqAiMmEp1tYL4YO8t+cgLXURN4DxlNy4lW+uQ5LNWsCcvjw5A5rKtNJPxc43y5 yrnIuXRJpzdVszmjjOrKFtpNKFwmGxJZYJh0/oe9aR+ZITsJrypmQVQ/r2b2Ja3EWD+ZtIoUogfG 6+JaWZ30OKURuRRnnJP4xRV6PZ5dv4v0uMM82pTGlOux/bLNkoAkMCIBKb4uYHJ0lK1hmaGR8IwF PJowkWBMNFbsojT7AKSuIj9j0sUJMIuZDpNtoGZ77XZykhq5r2IVc6PcUq45bynGkCxyk4LA0kZ1 dgFF+YfRLFrF1n7xZamjKKIIe14WSxLGY68qJSeumsjKYhI9D8T+cpYHGlmcaufR8jTioqCxpIic VDuJ9VlMD2xgc0wOjUlZLDeE01G+gZxUG4n1y5kW2MyOmHQOxKSxPG8KgaaDlMbnUR2zik2Fk+go y2FxXiAp5QYm6w6zPWEN1TG5FOed5cFZu5mF8SYSK+cT2S9ydHqCAs8uX821FRQlbOHDpnAWNeUP iC9zeQGLU808WpFGXJiNg6kryaufQXHlbIKHjKcQX4vYHZNFVmooavGZxURj2WYKss3MqV/P3BAh vow06CCyZBPL40/bGMxla1hsqMEUNvsCxddlKOcC5uPlOaWR0qh09kfNJyVjCqGB0Fa1iy2Gfejz iskS8+5cx3DxZWmmImElpa1TWV6xgMjAL99KKb487Go3szjOxPxWKb6+/GyS35QEvpoEpPg637hY DlIQUUBH9npyk4Y+2s2VRSyNa2F2fT6zLTtYGvcRkfE2airaMFsgNMFAWt6Uka06ihjwCB/DenIN /eU3syN2A5qSfGaHtbErNp09IbOYodvDTl3KafGlPABLCSrJZ0lCsFt8xR/knsr1zI1QJNxAOZMr i9jObNKS+kVRHUVhBVCylRSdkYUJNlKaUnDb1ESdi6lO2khufCOlhhruMi5giueB2mFMZ1HZfWys jKY6bhHvxW8k3+CxoFUWscigIaPewKRhbJXvGdVMDjTR2ArBsbNYkBdHuCi3tYLMsJ2Mr9yEIQao LCI5qYXo7Ik0ph7mvvp+8dVBRdxiDsQXk+upU4jThnoIjwoeJoLd4mtP3DrWZ4wf1JqDFIXkYTb+ huVx1eSEbEcfr+egZRabyqZ5rD5m9sUvpTowmJraSeRfiOXrAssJFBzKZ7C1wmPVbK0gPeIAM5py md66g6Xxh5kU1cL+ChvRZeuJLklmp246VO6jOSyR/MpoWjKMlJY10NZqh5BQpualkZIQzMGkRWzQ LWGjcYqbhUeg68s2sUBw7T+EpS5kO+GDhLoyY0qKKDXNYHnq8NEbNpiDxVdEI7vicyhjFlnlc5nk EdbKeI/Uz0DoqNyBMWM3NcLaGjaR6YVpLIgLQoivzZbpRLYe4ECVGX1UNI+WLCEuQvSojeqMIjaX uC2toXFzMBhnM0mUV5LJ4rJgok3VHGidhKEqi+jWCoypOzlYa8KOmuDYOAwliUysXENy9nhyPePa mLGYZWWRrGoyKNdAc+FSVtbex3eqttOavYmsBI8ory9lcVwb8+vTmDJgJXW/oHyU6jnPtJ+csA3Y Cjd6Xp6qKQgrI6xqAe1xmzHHBdFQ0oDGkEVx3ngajEa25FUr14To65xCA7OjxItVAe/9A/xujWRB VRbTQ0bu+xnXz/nua/JzSUASuKYEpPg6H34hAuLNzG9dzrTBLinle41sjkjncOpG8mP3sTRqO5q8 fFalhqNpqiAzaifhlZtOu2XOUpe4yaeXTSW/ai4D8qB1F5kJNgyV4m82OlrtBIXoaUhdSJ5lkPjC zMHUdPJebMGulO3HXa/kk2vwlDSknKGV26qMLI5vI6E2i+iKTJJLoodYjg4mPY4xMEuxbg092qiI W8rOqCw25YExIg+bcSspsZ6zmnaRHlXtFhJDrB82qpOSKaqfhsE4h0m6RnYZitgXaKC4fBpBtNFQ 0Yw+ZgrjxfdMHXToggiy7CMzbA9TB8TXQYrCtqDJngVluzlYbyMoZgaJxrlnsbacTXyZaS4zkpPU zIza9cwN84iQshk0JNUwoz6LaYoY3EdmbB2zs00U5IVfsPgKv4Byzie+FkdtR5+9irSkINSBwRxO +jF5tdEsK5/PpEAN6oo1LC4cT1qFgSkhNtpKCkhP1WBoTWNyVRGLkmBJfYoiDmxCDKfqyapdMMxt 2kF10jKKasOZbriPyTGTiDxDvJ7j4ugXXxVLCMzOYbsljvzKRMIHXSPnFF+WfeRElaHOW05KUji2 iiLSE9pIqM9Fn/Fj8iomMr88jRlRZg4IV6Ylka3lU2nOWEZOZSRpZfOZEtLGvqQcSklkXdk0KMlk vsHEjPIMHo3Qowlroywih8bUfLIM49GYGtgct5K6+HWsNzSSE7abybX9LziLKa0N5dEq8eIi5s1i alI3kVCfTmbVo2wqd4tyIdJyTPNPi1sPIuXvrfPZWDJFeXFYFHcAW3waW8ui0Yh7SEYQq6omszts JdVRi8gyTkFPMOqqNYpFOqEsjdkx0GAsIC8bEmuzmN462PJlo+EcfT/j+jnffU1+LglIAteUgBRf 58FvK8vhiYxgsjxvxENP73dr5VOcdJClMTXMHhAdzZRGLaM5+79YHj9CJYpVbQMYN5IWd9r1Jt7g c+oXsH6Y6+5M8dVBdUYpdVGzSUgIxVxZSkFCDRPL17EgRqNYAs5Wjq2+gry47ZCdT1ZSMG3GdBYP tlAAdanJFFiWsNU4ONqkg4OpORRURrK8UriWhAXJiKbcY60S3RQWrIj3iBbWwDNifmzY0Jy2Tgkr QlQdswa5FM8gJR7yg8WXiMMKLKAmYjLzCxOVB3B1xgbKTHNYf1a343w2VqndLkflsGMPDOWevDTF CqjEfIVs566qVehTF/Nhktt60WHMJL0+gfWxuxQLyYVavi6knPOLrxrmtJ4Wr9UJP8YYsoqt/ULY 0kGbSU9wiAabqY2WyjIKEto836nDGFGAuVDMKRRL2JaIrBHip8w0llewp6yGuqrDtJgCmRg/m/mF bkvSOQ9FfBlpCVGjjhgPVWamlOdj8MQJiu+eS3xFV+SQXHgX6wZeOsy01XYoZR02/FgR/lsL3XZY W8UakjPEGAjxsoaOwq0sj/dcL027WBpVrVx3k8szWWScPKhMG+YmE4QFoxeu/qZG9qWuYU+EeKkI dltQEzaRG19NTkwNgVEHaYsrJje+hpyIA9wnhLiwRMZ8xOwmj3tesDUWkxI7zFVeZWRhkpq0+gWQ sZgtponYKjUsqDegTl3IBt1yivPMGMPWYDZu9VzvwrqazM6YdRQPWGaFFW0ZNYaN5EbtHOR2rFO+ O1Lfh77oXNNniqxcEpAELoCAFF/ng1RZxOPxZlJahwVjK99zx83UGTyWr5jDJJiW4w6Zd99ED2eM LL7MZTkszA4lq37BIBeduCGn05hRPNRNBGdYvmzla1hUGEn+INFRZ0imACGaJp21nI6KzeQZqgn2 xImJR4gQaYtKotk4KPD9oOFxjLpBli9LIxVJa9jeOo208kSPlakBY1geNuG6PK/l6yygR3B9DTlz uPiimoJA8QDcetoVpFjbxMPydFyYuwyPOI7KICPVszBCpycwRH9aAA6Ir2KmVwm31XSKKyI5EJtD W14xia1reOKixNf5yzlTfO0iPcJjLWzdweKYwyQOzCMQ4qssapDrtPUgO1JL2V3RpgiL0DANLRVq Ej2CTRHpJgMbjXY2CHfXgBt66BjYLKAZZKkyNx2kInUDOy2Psr4iblj83LDx84gvU1IGq4yRtGUs Y2VZOGlVaQOB9meKr9P9nFiylGWVs9k6sKDkdPlnxHxVFPB4RjC5VWGUisURusFiWrhWQ5ldu55Z VZksKpvKxoo4j6vfRmPZFjZn76fRpCcoIpxAUw1tse54RfHSsbRyDsVJB0gvuYesuD2kV8ymOGEf y4zRrKuYTpByHXtcimGlLEyCtLO41LEcpCiilNCKNDDk0VNowJywGX1ZChjWYC4ULyhCQBVBWf/L Shs7YhbzUeqguYyN/fFPKIJsfdye0+Krf0HHCH1PVMIM5CEJSALXCwEpvs43UmKFXlgRHXnF7viN QYet0sjiuAZmiMBtEfN1UeLLxv6EZErDhPtukGvPsp814k271h17MvgYbvlSLFYlUymuOh1oPiC+ Cs3DyrHRXJJHTraNGWXLmRszaPF6lZHkBEgbsO51sCt2kTvmS/S59SDG+A3URc0nq3AawQMPbBF/ tYgDCZ7zRGOVWC3NoLL6e9DIjtgCWlLXkdJvtRCWr5hG5ihWhREG4gzx1W8Z2EpukqcPnpip++oH r4g8Lb7OjPkaVNcg8TU3ZB85Efu4p3wy7xl6MNQmElp+8eLrfOUECrE7WCQoFsAGt+XqvOLLRnVC MkYWkF8y3T0W9TtYGlXDjNZc4gRHEagtFjYUgjEvTHFpD41WBHP5GpKFO7I+5fTiB4FFzIV4M0vO F+R9xmpHMb7p7NTNJ78iTnGhK6J+hH5Gl2eSPMRK1cHBwt2Y4xLR5A1b7dgvvmons6s/TrFf7GOm rclGYFgQYhXx0PrENXmAyIpcFijz3c1uc4jnpUJwi2thanwdNRH55IrQgbgmImPraIxZNxBTqIi0 ihmkhJWxWZc29HodmErCrb6IXRHToaSDhHoD5qRF7AyMhnKxeEVwHi6+zmf52u2OL1PGYlCM5ln6 frErrs9325OfSwKSwJUlIMXXBfBtK1tDuqGRidkLSIiPJFjXQWPFbkoz9mFLWkV+3iQ04kZ+UeJL WI1yBrkg3A2xVRSwrOw+1pV4AqYHte8Mt2N9KUuj9jO+xL3a0Vy1g4L4PQSXFWOwbBhSjrmiiKVJ LUwrS2NWxGknnCZQ5BBqwBiVQ7Mhi+Wp4ZjLN5BpMCvxYNNDmpWA/11hBpbnRTKgkTyrFJUg57xg UioMRAc2siM+hz0xIpB4+ApQGw2pi1lZFU1W+QIidQ3sSMhjd8gSikumoBdB8xXNaGKnuAPw+48z xBc0G9NJN4ZiKFvAtDAz+1NzMDbNOou1ZqSA+xHEV4SZ/QkLKa3Xo0/IUoL0hXVxwPJlaaOuopnA WE9c2uC5M1jEnaecUCFQRXxT5XJmhLRxwLCGDeXBLLkg8eV+YJcGplFcEo3eItI75LChPGjQilBh kc2hGtAb8skfWMgxmOtBiqLyqImazfyMqUwK0WNuqmNPxmb2hxk8Cw/aaCg/y5iIYs6WakLEOcZs wZyaT75IE3GufnpivvSFnrlbYWRlUjNzakXM10ji61HMqYtZUzuN5WWPEhlipi4jh5zySWTVGggt Gya+qjazMO4wM6pWMTdCQ0dlKXnxO2lL6F8xLDhlUtEaRFyFWCHcgDFiJftaw0lUYsE8vIQrPWo3 pkCYXDYotcawe4dYHbswtQ5NrIFiTwxasuEw+oQMJRZMw3DxBWIl9eIMOwnlacwWq5CNBeT0x3yZ xMtJAzOqljMjQs3hc/Q90hMzecb1cwH3N3mKJCAJXH0CUnxdIPPBeb5MqBkXFck0QwJzEsLdq+Mu VnyZ9pETtou7lADf/kbYOGhYxntx60jrtw6dS3yJtV8VmzFm7KOu3o46LJzo7CUYEoKpG1KOWL24 iC2D810p5fox9f/+VokNstVWsMGw3Z3nK2wiccY0dw4w4Xa97z16hnOKfoINSrxOBwczCjD2rz6L TyTFOH1I4PXAV4VQSN1AWVkjJoblBBu+2vEc4sudW2wDWwrraLO4V7DNN4r4r+GNvFjx5bYILRTx U8KaGcZQ8SUsbGE7mVh1lkUUQ8TXecqhjf2pRZSWHcakCyU6Yyrm7I+YKtJ+nNfyJcZqFwVJZdQ0 gT4wiPCEyVBWTfCAO8u9Wm9Jhp5FTcOtgacZ2Zqq2Z5Rxn6R5+u4HfWtoUyMn8OCPM/4eVbTjq/c 6l6BOvg4m/gS1i6RliWpkckV60mJFcJ4hH72r3ZM3a3kqNNHTGZWoYG5se7VjkPyfA1YvhIJtzSz X1npeRiTSU1gTDQJRgPThbgabvmig+rUPIwljdh0eqWOaWJlZtOMAdekeKHJKBerHMVKXxsHk5JZ VTuHDbWDFsDQwb64RWxoPU/KEYXJBuyFW9yrf5t2sDRiJ8Fl/TFqZ4ovMCurHY151bS0iv5MYXae gdnCUmdpYEdcHtur9MyuKiYxYuS+y9WOF3gjl6dJAl8RAlJ8fUUGQjbj+iDQkFFAXVLaIMH81Wy3 iCcULml33JI8Lo2AeClaRGnEKtanDk5Zcmmlym9LApLA15eAFF9f37GXPb9YApY6dmSbmZ4X/dUV NJYOmpsa2ZO0gbaM4iFJYy+2u/J8lNWkbbX7MSbVMLVqZCuiZCUJSAKSwMUQkOLrYmjJcyWBrzqB KpEbag+2OAO5ZdPPvWLxq96Xr0D7RHzhsow2IvOyyDAM2rbrK9A22QRJQBK4fglI8XX9jp1suSQg CUgCkoAkIAlchwSk+LoOB002WRKQBCQBSUASkASuXwJSfF2/YydbLglIApKAJCAJSALXIQEpvq7D QZNNlgQkAUlAEpAEJIHrl4AUX9fv2MmWSwKSgCQgCUgCksB1SECKr+tw0GSTJQFJQBKQBCQBSeD6 JSDF11UfOzMdrWqCQuRubCK79+VncSXKvEKTxNJBhyWIoJH2tbxC1cpihxLoaO0gKOQ6TkUr55Gc 0pLAdUdAiq8rMWTKRse/wZS0io3GSE7LLLF9ySK2R+WTnzp8q+Mr0ZBrUabYHy8Pm3ErKQMbAJ+t HedmccYWMxfUlWFlnrHl0wUVcpVOamBz1AYoGXmvwKENMdNYtpMy434O15owWdQERoQz2ZDIAsMk 9xZXl+sYxG2iMZ1F5TPYWjH9vHWITd2LdBlsKhy0UfxFtencc+dLl+/ZeH1GU+4ZG7h3iJ0Ayqay qfz8/bvQrny5uXuhpQ8/b+g8urp1f9k2e773JefZuWpV9mLNm8g6ZeuzYcc55sEl9kR+XRK4aAJS fJ0PWdUuisr1zEgVmw9fmLWqIWMxBU2h6CthTv1ypg1YNmzsj3+CnbHFrP+nFV9mGisbIGrYBtln cD43i47aalp0kURGXIysGFbmV1p8HaQozIi+/Cz7RJ6FVUNGOitLNEzPe5QZceEEY6e5ag+lqbsw p667vNveWJqpqzQTGjcJrqr4OvfcuRLiq82YzuKKGWy9bsXX0Hl0XYmvLznPpPg630NLfn49EJDi 63yj1FrHjoxSdpc3Exg3ndmpc5gaEzTImjWsAMtBiiK2oC/PIjRjKe/Fryff4LZyNRemk55xmB5d IKGGNIrzIod82Vy1g6LU3dTVmyEwlCkZKSzxZNXuqNyBMWM3NcrG1/0baI9HIwRG/GEi48zUVbZh MmmIzJ7PPfU72VneQpslkOjC5aTEu9tgrtqFMXXnwAba0/JSMHg+G9wYc0kmC0uCmR7YSF0r2Anm vsIU5ooNf8UGyiO1h8HWC/H7BszxE2mrqKPDZEcTNYslJXPRl5ybxeCHiPh9py6OwPpqGpvM2EMi ebRkCXERQ8XwGXyTGlga9SGTUvXUlYhNuAOZaDCQljfFvT1Q60FKDVvYV9mGWRdMZOp8lmR4PhsM QzCO+4hJcTYaas3YLRrCUw0sSXJnPDfXVihMD9aasOPe6NtQkkhkoOB9tjEN5ED8Moz/bYIbxxFt LD7rRuoDTVAsqXuYVFmMIWZon22Vu9hSG05iaiT6i5oLbVQrG1Q30NZqh5BQpualkZIwfsgm8eey fNma9rMlqZT9tSY0UVOZrKumLiLLY/kS5RexuX/D9bg5GIyzmaS8iJhpLNmsbCbdKDYHj4kmUdkc u3GI1fRSyq8rLMKYV0MbwUxOCKelpIM5wy1fym4Au2mx+BEYM4esyrkEjjivh98oxOboBZSWNWOy QHDMdBJLFhAdgrIx+GbLdCJbD3Cgyow+KnrQfHVvpL1F9L0V5bM5hWIj7Q52xKTzUeomshL0YNpP TtgGbIUbyU0KAks1BWFlhFW5N3x3Hx3sGzaPppYnn6NuG80lRjacwf1sL5Ujj59ybygbz3RdAzX1 JsyEM6dwBraSMt6rNWHWTeTRsjTP9Xnp8+xc1xeWRioMRWwvb8EWMpHpsXb21N7jsXyZGXEetLrv m5OiWthfYSO6bD0pUQ0j3g9GvjePPA/O92iRn3+9CUjxdaHjb2qkumQXu4zVNAZGEpeawJyE8DNc MebyNSzMm0h+1VyCxO/ZweTWLiBcGciUFwAAIABJREFUqedc1p5mdsSs5CNDPllJwZhrS8mMq2N6 VT6z2UV61C6CjVkYEoKxVW4nL2EfoSXFpIRVsDRqO5q8daxKHY9d1PmjOsJfySfL4Pl/RjBZ9QuY 1LqPnKhSyM4izRDqKaeayIpiEqOGghA32CcMJmZU5GOI1WOuMpKe0EFi7XKiTedoT1zzoAdoA8aw DKqjlpCvbHXTSGlsOnUJxeSnBp7TCjhUfP2YvKqpZFSmEB1ipi51KTlNCWexVpzF8hW1HXtSGhl5 k9HXbycnbj+RlcLa1Myu2HR2hRnIMk4juLWaLfFFNBpOi+Wh4kcwzmdVajia1moKYjejNxZjiG1k c0QOjalu3hpTA5vjVlIXv471GYw8pmEXbvlSrDPGSPJrEz3zaIRJq4i0C5sLwSWZLC4cT1qFgSkh NtpKCkhP1WBoTSO6aQdLYw6TYFrOyOKrkdKoTA7GLSdLvERUbiYnfjfmpDw2FYbTkLGMnMpI0srm MyWkjX1JOZSSyLqyaWgqilic1Mas8uXMjYG6jEzWVE4lvyqS3QMu6y9fPmVrWJwBCyrSmB4m6l7J hvJQlrSe6XYcYvlqOte8HmqBFe6t5OxgsioXMEnXxv6kTLYEpihhBjVJPyavYiLzy9OYEWXmQNJK jJZEZb6K7y1OtZNQlsbsGGgwFpCXDYm1WYQXLiandT4bS6ZAZRGL4g5gi09ja1k0msoikjOCWFWV OMydNtzyNXLdKNxbmF6eQWKMhgbjGvIKg1lSm8IU3eA5ZTv3+HnuDbMq81kQo6bOsIiVJYHMqcpX 7iN1hsWssSxga0k04j5yafOs4RzXVzAHDcLLMJusstmEm6oxxhfwnu5RNlTNRX+uedC6g8VR29Fn ryItKQh1oI0DcSPdD2wjXsczakeeBxfmJ7nQB5A875+NgBRfFzmiHVUVbEnawgHdbNad8TDsYF/c YvYlFHveVuswRhRgM24kJU5ciucSX23sil3MrsDZJKROZXJMOEGeG2JboXCN3MfGiriBDZ0bUheS 07qArdnNpEfVMKM1lzhhVVBcbR8xuynLHd8yOK6iJJNFxsmD4iFEjFQyxsB+a8VpGOKmmVwylY2V /XW2sStmKTWpmzC05ozcnrJAtgw8QIXlKwdz4VbSlP5DXWoyRaSxqXDiRYivx9k8qI0jx3WcTXzV IGJ94kJE7ULgLuNwxm9YHrGdxVENzBr4DMxlOSQX3nVmvIiH4ZzW5UzzjElDxkLyTAa2GiMxN5kg LBi9xUxHUyP7UtewR7EABY04pnDh4kuM9cr6hEFxVyLOZyV76j3jpYtkSVMW08Tb/AXOhWhLB20m PcEhGmXz6JbKMgoS2pgjBIoo53ziq3YzC+PaWNC0nGiFiY3qpGTPONkxhq2ho3Ary+M9j6CmXSyN qlbmZWDqsDlnaaOxHkKjOk7PncAvW/5ySEpmV4wQv56oHyEmo2qYfZaYr8Hiy3yu60wIoEH3CpsQ RwmNTM5OYEZcJJPCTouz6qQfK9fU1kK3ZdtWsYbkjPHk187hcHwyO2PWUdzfNs+crDFsJDdiOwuT 1KTVL4CMxWwxTcRWqWFBvQF16kI26JZTnOd+jTt9nCm+zl73o7QkJGMMWT7QLnALG9Og69Ndbt05 xi+X6PJMkgfdRzrEfaUkmuLK2cpeosq9o2wqWyvi0F/qPMN2juvLTEHIBvTlWzHEuFuu1K20LU5h PeI8UMRXjXu+K/fJ0nPcD6ZRM8K9+Vzz4CIfLfL0rxkBKb4uaMA7aCjbze7CfRxsDSY6dQ5zkqIZ P3yVmnjARGyhJdAPtadcu6kH4pawsXw6QecUX0DTQXZk7+S9isO0mPSEJTxKijEOW8ZCckwGfive iD2H8tAov4+NhWZyYg4zIAyGxzkN+n9wxmKWFbahHvyWawHi0/jNsIeL4lqomM1vy6I9NZrZF5fM nvhi5tdnjtyeinC2DxFfQ4PvhZDII4WtFym+SiNyKc7wPHgq1vC48jAbbgU4e8zXadE0SHwFGnn8 vvewj+4fKU83A6eT1WRgiENYcee1Kw/B/r83Fy5lWeUcflMeTUvZFjZn76fRpCcoIpxAUw1tsavc 7rcRxjRcd+Hiq61wKYtLpgyyfNkwt5owW8BWv5O8+OYhoulC5kJ060H+f/beL7apa9/3/bwQoxPV N0iYgxRLF8hVC9k8xH3Y9kPrsJFMIx0jcfHWIdtrcRUXqZ1LauOsheKCZCOEfVVwxCpOkdakEkwk 1vJKr445XOEtpbFuF3H7YO8H4geWgeqacCVHQnElIi9lKw4vV2PaSWwntgOkKW2GnwjzzxjjM35z jO/8/X5jjtjQLeLjs7pw7NzTxsz4Nk6uV3yNX+Y3Q+2ce6SwlF4/fUZ4PD7lq4uzXOj4I1Pbty0/ BzrdhU6OZkJ0Dnn4pk94P+sXnVSFrBde9f6n+S8Df2BK0QgNVATRwndc2P0N77UQX3nxQtPoOat6 8alM80zfHGNMTTOVKbBtj4XDVz7lVN8OPexYa6+X+c0Z4QH/gPu2T/j7kFYOLZalWfklRIjFoVlG 99+ic/w0KBf5zysK8/3XaR8bBOVz5q98tSwyGouvRmU7eXDoQ26ktq16/t9WK6HNpZsKXg377wuO p2pfzOpf1JbEl/6y+Lp2xiLTjZ6v8zP499zFkqkKxeoewk6CKStpWxM7EOLL9gMn586ij3D3RpuP Bw2fYxFCX9sO1jW1yJO2LAEpvlp1fSbGZ31fM7vfinPoOH3HVocal24hJh//o+N8oVpWJp2ncS70 3ec9fYBo5vmaJ5+apc0mkqkXeZ75nhv9KrND1zi9IDxNHzT2fFW8FPog0kR86SGksX+p8mbB4rNZ 5rbvYledkCwPqCtvs4iQYY+f/HmNU0/LScpreuJWeb5+fvElwmdlCVklvvZ8zSeH8pyo8mYxN0t+ oR3z7rok/4o38bjwLumcFvVQy2VOow095ve27zk4HuKUng+3SLrfw/XdwvNlbtinl5Tp9Sfc62/l 3/H2+BcMHqqvW/mNvd5j1dwWToPwgnCKSzcPs0uIcT1kWfGgrtfzdWiWk8v8FrmvfIyqr3Z8weie y3CzesXrPLNPF+nY087UsoesItsWHjN+foZ3znfyTU/FXoTn65Xu38b3unfp0opY18OJad0Dqns5 qn61nq/fN7HrOs/X08dML5h5RywIWZjVc4s+V3dx9ukg8w3F13Gmm3m+BtpJD3zM3f2H4eZz+h8p zA98zO0OK9xZ5OSjQQ7WhAdFQ1ok3AuRrAu/E+T7f6uvtF5+iRHjzNM52nbvor3mvg+a9N8OXtR5 xRuLr8P88Lp2pj97jZ6vsudr29iKna14r8uer4Z2UC++MreajAc0fI6DfbMN7aA2o7fVRCOPbzUC Uny16vGnD0jPdWLtafEdoIUHjO7/nBfqSoitfOtKOLFHeEL2ku7/Ldd3n+HS+YPs6KgOZFRyG5QQ Z4f20j53H/XQZWbPfMU527dr5nztunmV0yLna53iy/p0HL/tNjuunEXp38u2R99yuU9l/rwIk9Z6 Ico5X7O8Nxbi02PtzKifc+HiDpTM6YY5X3p96nO+6j47Ue35asyinLS85D1Y7Ulo7Pmqueezu7Vs qsXXsRliNj9/6xnk3BUruxamudvv53bHIFfHrLW5fJVcKpQznLv4LqRucbH/O96+c5VT3OKjvh/4 IBXEtb+N5/ducfHYbWb7g2jqtnK+ylp92j+Nuucyzy9e0hdDtM89Jp1p4+2+vcuh5RXTFDk4nxFQ X2A9f4IPDu2lY/s8s6n/4Jsrd5laOMy5jMLBqlyt5uJrkPljHm51nObqTSvtC3k9J+vLOzv4+Okl +ubWEXZkWuf3ve20zqQtc4sLfbd5Xsn5ejD0CZ9n3ufs2AkOijy9Mxe4cOcdvZ57713mE2We43dO c7QHHl8Ux/55Vc7XK99//DKfDM1z4o5I+n7Od8oF/ji2a82cLz1kpr5D8M4J3ln4pvFz1lcrep/f vMAnFzsY1PMQF8mrF/jsyl5Cj04x21B8naRDz0N6QX+l7dPqZS5Ucr4O7xah78/5aOgBbYcUro69 D0LoKD/Q3n9GzwVbnUckQoQrdvRAaeT5OsmuO2Uux/V8s23Mjqtc6J/GmvqCk/urB8JFmvbf2Ho9 X+8z9bp2lhLh50bP19vL9Tx35yR7F+5zo+8i31RyvnZU2rumHdSLr4o9rz0edDDW4Dn+dOFyQzuo DxC3mmrk8a1FQIqvDerv+TuX+UiB009P1yWvgj7An9mhH3t7/DKfDXzPXN8f+LNIPq4qX6xEHB26 zZRY7ShW3w18yKeVlXliUv9y6Ft9JeS2PW/z/plTfChW2zXxdK01Ac/fizFaWTVJR+MVfvrb7JV2 3ts9TfqeWM1m5YSq0NeztNqxQX1WrXZs5Pk6yPM7jVm8mvii9p7nZ/msWpjWiK82eJbmlnKL8Xuz vKCdzpoVeVUdo4uv7zEPtPFgbFpfVfX+eYUP+8208Zz00EXUm9Msbm+nfb+F9/dPc/dp2TPY1rBP 57k/5OeyOsPeK1c5t/s6v1XaOPPsNCvB5doJMX/nLrfVvzGVEataoWP/2xzsP8qJISvmJe/VOoW4 JXOXywNjTInVhh072NtvgbE0u8a+QulYj/gSYfI015XrfJuao22/lff2PCa9W+TzvQMLeb7TV1P+ wNzcNjpsVvr1FY36+lCmVZXRi2lm9GOHOaWewrqn7jtfr3F/saJQrKacmevgoHKQeXV2Tc8Xj8a5 0HeDKd4j+HSQzkbP2apxYpb00CjXRfsWttG+/11OqJ/S19PWJOwoFkyUVzvqdXsm2v4uRy+K1Y4V cTf3Lf7dX/Liyg0uKTtACOr9t9k1VpU/V1OXWjs6mvp9g5Bnuezpmyrq+ftMP3tRHkcarHZu1n9r erqq8kOrw47tr21nzZ+vHeLFYehLbo1NM9+xl8PH2kmn/omg/p2vKtb1drBKfInVz43Hg8Zjc2M7 2KCpRd7mV0pAiq9face+brNWJ9y/7h1/wddvyvfCZrnbf5e3x04t51D9gonJqksCkoAkIAk0ISDF lzSPNQlI8VXn+arxoP0ERpMZ53rmIKcGVn2X+ycoTN5SEpAEJAFJ4OckIMXXz0n/DS5biq9NFl9v sC3IqkkCkoAkIAlsLAEpvjaWp7ybJCAJSAKSgCQgCUgCTQlI8SUNRBKQBCQBSUASkAQkgU0kIMXX JsKWRUkCkoAkIAlIApKAJCDFl7QBSUASkAQkAUlAEpAENpGAFF+bCFsWJQlIApKAJCAJSAKSgBRf 0gYkAUlAEpAEJAFJQBLYRAJSfG0i7K1a1OKz57zYvaN2y55XgbHwnOcLO9hRv6H5q9xLXvPKBJ4/ e86O3S2223rlu/+yLtww297AZm9MneZ5/mwbO3av3tDoVaq6MXV6lZLlNZLAm0lAiq83pF+ei02v 73yANn749UVKqzaJjZr1TYtPVzacbnXBaxx/dJfP+n7ghNh2ido9G1/uro+53vMl3LzKqZ6Xu7L+ 7MU7n/Pbi2/zR30Lktpfs2OvV+qbdfWrfsft+dgFPhl7j6/uHKZ9U778/zLc6rYnanjpes9rUXa1 beubn9/ng0dfcHTPy9R5g8+te95e7e6L3B/4WN+E+9JQ7Z6vYuP47/p/y23bH/liaB61bu/WNcvb kDq9WkvkVZLAm0pAiq9WPSP25rvTzgdD7/HOBr0FrlXkr1Z8Za7zSd8cH1b2LFy1SXYr/svH7zO6 R6X9zldSfK2bWZMTnz4m/WwHFtuuNTZrbnzdrPoZn4x/gPZGiq95pu89hp532dvUO7re81qArrZt XXw94INHl35e8VX3vL2aqSzy3bHfcvvQVb5oKr52rI/3htTp1Voir5IE3lQCUny16plnD4iduUX8 Tp6OvsMcHTrOe7YdjScssRnw0C2+FZs1b9/F2wMnGbxoRbw/CuFxe3sfHY/STD+d58Xug5y4+Sl9 +9tYFl/qPBd6vue9zMogLo6JCe/qncNUB3tWCbZn43y2//vyBsLPYvy+7+8cPLbI1Pgs8wvQ2a9w WmzUXef5EpvGqkO3SWcqm3Yvb7a7yPTNLxm9eJ+ZZy9o32PBeWUQ16F2eHaf6wM3+D41y/z2DvYe O8mnV94vb/C89FtIM7r/Mn/7/+C//K8HOZU6R/uZ33B94TAHn33P96l52sWG3RUGMEta34z5MbPP XsDuTt67eJrB/na+PfYH1P97Dv6rCat6ldPHasMh85lxvQ33M3O8YBu7DvWh3DzJQTEJL0wzrozy 9Z0ZfVPsw4de8E3mn8uerybH2m/6+WRsF9a5NN8/ewcldY7D3OeWckPv33mx+fnQh3x65l29X+ZT MUaH4vrm53R08u6ZQT5V9tLGLN8NXebWWJ65BdhlO8zJm6ew7q42vjwx22f8fegrzvW3w9x3XNjz JYtXrhEa2AELaS7vGWNP6gtcHQ+IKdf55t6MvsF2e4+F4+ppjvaIzcLX0S+irmLj9MpmyG03/Xw0 ZqZv+2PSj+aYX9iF5cppBo/VeT1SQkjHmVn4L3TYjnNOhdGe/+CdoXYe3HzA7EIHbysVGxNNe9aY Ve1j9wB1/3Xm+3bw+OZj2pRzXL24g/SZUa7fFBtX1296LjaIvq5vTj0tNga3WTmpb9o9veKJ2V22 /3f6FnmcmefFQht7hxQ+FZvR12z+3ryeDZ/ZPVO1tn3vX/j+0H/gfHSad+fW1weCwfN7MdTKRvdi o+vDV05zqk/0d55vz6iM6Rt3t7Orz4lyxcXB3U3Gkfo6CXvd3sRW9I22V3N8ezzAZ2d+4D+3d9Cp nObqxYNV3dXI89VgrLA9WDUGHK6x+1YDsDwuCfw6CUjxtd5+nZsmffMud9U00x0H6Rvq53j/3roQ 4TS3evykbYOcu2Kl41maG/2jPDgkJpN3SA/8dy6m3uPMvUGsu+d5MPR7Ljzt170Ii8thx4N8e+gT vj92teLyn+Xuod8zpVQm5ar6thRfPV/TdvESwaG9tD0dx99zm733vuLU9qqw47NvudBzC86f47TS yeK9r7nYn+bg+FVO7hbX/A3LvSCu/ZBXL/CZ+g6hzEnmhz5idOEUl1QrO+buox66zPPzX3H2WHst 0VWer//OxfG3+fDOaT7omef7gQDqwskyAyF2rpg5Pa7w7u5FZm9e5rOhNhQRHt3ezPP1mOv7LzA9 dIlzipm2ucdc7wvw4Ngf+eLMLu4rn3D56VHOjR1l71wa9dhl/rb9BF+mjjLb8JgLIb4+VOb44M4Z Tuxvp23PPN8e+oy7exTOqe+zS/TvsVGmlS+4pCwSswX4u3KJcwO7mM/cwt/3gMOpS3yQ+RzP+V2c u3eKd7bP8t2Anxsdg1xTD9aI+Okzn3Dh2Ydcu/ku3Bvl477vWTx2Gm3MStu9UTxndhBMnWBm4GPU hQ+5dPN9dm1/Tlr5jMtPj3NtvI+ZdfZLvfj6rTKP816IU7Z2nt/5nD8obXwqQsXVYhpY5fnq+ZoX A6c5c9FC+6OvudD3HQeFjfXkuduQVX0o6wHqngDpno85p75LOx08v/IHLtw7yOmxD3l39yzfDlzg Fif549j7tI2P8snALM47Z3HZ4MEZP5/fe49LqYPEl8JgQnxV2/+zNJcPXaddvYpyqEqkHWpez2bP bHuNbc8znXrOLpuZ6XX2AfqzN8a2i2cZHNjL4vgon/XP0v/oHB3nP+Hyo/c5O3aCgx2zfKtc4PrT o1y6d5SZJuNIbZ0WSTexlcYcjzK9Ls9XVdhxf+OxYq/0fK13lpHnbSECUny9ZGc/T41zQ3h8th/l j5mT7K2+PnOdj/pmOfX0LNbKpLU4fhmP0s65pwpzA7/hesc5vrryjn5VdX5Re1XOlxAhH9+0cvXe UXY9vctntgc4H53l/bpQSkvxZZviqPCC6dfludXzB/Ln/y/O7l8RX2+LslRLVf6TyPfwoIp6np/l wp4bLA6c4OiAFUvPisdPCIXPxjs5ceYo1r6DmBuFedYQX+Le2pXy2/Ti+Od4zpi5lDmJeeE5s3Pt 7NrdxuLcLDP3xrjcP8vxZ6INzcTXIvNP52DPLtoX5nn+dJpvhz7nm/2C9TyXd39J+x0NxVbuLF14 6G3ey9cNj5XFVw0bPbT0GOfTEH2Vt/f5sQt4rvwTf0y9z9ShT7jbcZT+ofew2PayY8kGhJDqn8Zy vp8P+g7yzp46gbpkQymVjwa2cfrRKTjzCTfm3mbxXhunHilsG/qIL7ef5erFvSw+K3vddnSIds/w WB3l4r339D58sc5+qRdfZR6VHLhn4/j3f897j1bauVTF1eJrSve0lnkI790f+OHMnzm7/+smrOpz 7YT4+px5VeN0n/Bolv9+fkXj7JKH8+ldft+T5ujTc3QMVeyz8hyxMMv0I+jsec6NavFl+4Hjz87y fqUfHp/5iItzCpraXuUha9anLmaaPLPmBqJivc/Giu0s8ZhnNvOcbftnubGn1maZ+xb/nrtYUl9g vth4HKmvU2NbOcrs0nO+imMH6ZcVXz3CU7v2WIEUXy85y8jTtwIBKb7W1cvPeTwWJ37lW+4/24V1 6DjHB6yrBcf4ZX4z1MG5R6coyysgI4ROnpNzZ2HgN9zaH+LqmYpkG/+c31SER7X4ap/7lgtioM18 geXO7wmk+rkmvB91dV0tvu7y2f70StjR9gP9c2crSfVLE2Ot+Np15hP+cGWWbTXhQuDYaf48ZkWE JG9d/Jape0+Z297JP59RGBw6SPtCnu/Of038zn1+ePwCU+9hTqof8v7+ulq2yvkSzM7s0r1pe5/d JzZ0i/j4rC6kOve0MTO+jZPrEF/TYze4fv47pufa2bF/Lx1zU8weCvLV+ZnypJX5AtdSIrTuReok OL4DtdGxVEV8jb2ne5T0cO+9UX7zL3/jxf+yrbYnOg7r4vrg0/vEzt/mb+M/MDPXzp7+Ewyqfezd LsI7Y4ypaaYyBbbtsXD4yqfl8FL1b+E+o/tv0Tl+GpSL/OcVhfn+67SPDYLyOfNXvtIFpB4mPnOX +5kXtO/vZG/HLFNzH1TCqOvrl1XiqxKC1GukT/Tfrk981QicKvHVoTZnVdNwIbZGYazcPha+40LH H5navo0a0gudHM2E6Bzy8E3fkme4+kZVifTC83WsoAvXpaBZ/srv+cO94/z5zq4VkUbzPp1v8sw2 El8iZLieZ6Ncn6Pl/LnqZlQ9/yvJ+/cZ3f0lbXc0LGrjcaS+To1tpY8f+hpxXG/OV23C/fNGY4UU X+uaZeRJW4uAFF+t+jsT47O+r5ndb8U5dJy+Y/WhxqobrMPztS7xxTzfHfuI+KHT/PPYlzw9f63i Eait7HPhmakWBxXPjO4pEjlf6xBfbwuP29i/cO1eRWAIb9SzWea272IXszx+BHv1pOx58uO3uNz/ gHfv/REnPzC3+yB7d4vzH/ONcpFb2z9EG3u/diIR4rNvtnHC/bL4OsFsvweVU1y6eZhdQgyK1XQ9 U3zwLERfM8+Xvuruew6Ol8NmYkVWut/D9d0rnq9tYxqDhyqer2VvVdnztfaxNcRXRUifqPKmMDdL fqEd827Ip2Zps+1lF4s8z3zPjX6V2aFrBPtmmV4w887+doSX5sGVUT5Xd3H26eCyMCjXrBwmurv/ MNx8Tv8jhfmBj7ndYYU7i5x8NMjB7WWvUH4oxNmhsi3qdqB7ro7Snllfv2yk+Fot8P/M2T1f6y8d a7Oq9/zViS8eMLrnMtxc6TOYZ/bpIh172pka8NR4kFl4zPj5Gd4538k3PRdZVDUGhfiy/Z3jT89V PMaLPFA+5jKn0dRtK56vjvLLUaN6rlogUvXCZK6z7aU+fP4yfVDjdX7O/Stx5vv+if849CXtYxpK xWbrPV+NxpHaOjW3lZmGHN8jL1Y0tky4rxJfPY3GiqucpHYMaDXkyuOSwFYgIMVXq15++oD0XCfW nvV810jkfH1G+tBpzl1cyvm6zH1bkKtX3mFqvZ4vERq78zkfnZ9hx9zbfPhocFXujT5VCw+OyBG5 d5YPds/yvfI5X97ZxacvIb6sIhfMdpsdV86i9O9l26NvudynMn/+KiHbdzWiRs9jOvSAw5kgu86L vKOTBG8exizymPo/40bHp1xT36310AlBaHvMB6mzfLBfTJz1b+1Lnq/jTB/zcKvjNFdvWnXPmsjz +fLODj5+eom+3WIiuczzi5f0RPD2ak9dSoR7f+CDlMhNa+P5vVtcPHab2f4gmvo2D4Y+4fPM+5y7 c5K9C/e50XeRbyo5X3MNj60hvpgmZvPzt55yTt+uhWnu9vu53THI1bEOxkTemVIRRZU8uNkzX/Hp wmU+udjBoJ7rt1jOnbuyl9CjU7Vha9HvY5/z0dAD2g4pXB17H0SIVPmB9v4zei5Y28J9Lu+5zPzF q5wb2MHi00oOGyIMfoJZPcendb+8qvgqC713CN45wTtzdxsI/D9z9thME1bWulzJevG1uNxnes6T yI88c4ELd97hXEZh773LfKLMc/yOWGQAjy+KY/+8Zs4XyhnOXXwXUre42P8db9+5yilbdc5Xsz61 8qCZ56vOtss+36U8q9Z9sJTz1X7lHJ/2m5kfVwkM5DmeETlfH3P50eGanC/1Udm7KUKhDcVXdZ32 PObLhrZykl3jjTgeZab/t1zffYZL5w+yo6Pam90g4V4XuysvQCtjxSWOLtSOAS8y93mwsBerbT1j aqsBWh6XBH6ZBKT42uh+E6sdlet8e2+OFx27ODhwEqVqteP6PF8i9CJWt13kwbHgqsTslSqLVXSj 3BIrorZ3Yj3zHvPn/857j86t2/NlFRP+vRijlRVXiDovr+BbJH9T5cvzaabnXrBt917eP/8pH/ab aausZBsXqzqprMZSXeXVhdW/hcfE+i7ydaqdo6mrvH2lkfg6SWfmLpcHxpgSK9g6drC33wJjaXbp 4ah57g/5uazOsPfKVUJKddKz1ilhAAAgAElEQVT2c9JDF1FvTrO4vZ32/Rbe3z/N3acflEOGQsgN fcmtsWnmO/Zy+Fg76dQ/EdRXOzY+pud8VXsWRbuepbml3GKp3Z19x1HUo7zTUQ4Hjg7dZkqsdhQr IQc+5FOxulSs4hwa5bq+cm0b7fvf5YT6KX1idWL9T4T8dn/Jiys3uKTsgKcxfr//NrvGVvKf8mOX uXwmzYy41+69WPt38ODKIidFruFceYVhq355VfHFo3Eu9N1givcIjndyfU3vqhBfYuVlY1a1za4X X8L+83ynr3z9gbm5bXTYrPTrKxoFs3mmVZXRi2lm9GOHOaWewrqnLuzY8z3mgTYejE3rq1zfP6+U bXfVasfG9Wzq+aqz7ZNL359b77OxtNpxKK7bjLBb5xUF1yGx2lHkLYrVjtPMIVZ7Ojl5xcW7ldWO DcVXXZ3+5VETWxHh8DU5wvM7l/ls4Hvm+v7An8Uih+UOa7zaseFYUVcni+rhwrPyIpsG2Y8bPSrL +0kCbxwBKb7euC5ZqtA013s+54VayYN5Y+spKyYJvIEE3rgPwL6BjH6uKs19y+Uz7Xyqrs5j/bmq JMuVBDabgBRfm028ZXmLzD+bLedXqWbOpupWVLa8Xp4gCUgCer5gjVdOMnlTCMyO3SK9/0T5u3Ty JwlsUQJSfL1xHT/Pt8c+Qs2YOTp2jpN6Arn8SQKSwEsRkOLrpXDJkyUBSWBzCUjxtbm8ZWmSgCQg CUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTz JQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+b y1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJ SPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQB SWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKA JCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8S kAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8 ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAU X1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAE NpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgC koAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJ QBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uW JglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1 xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJSAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBz CUjxtbm8ZWmSgCQgCUgCkoAksMUJSPG1xQ1ANl8SkAQkAUlAEpAENpeAFF+by1uWJglIApKAJCAJ SAJbnIAUX1vcAGTzJQFJQBKQBCQBSWBzCUjx9dq8ixQKBkwmw2vfaTNuUCgUMJlMm1HUG1jGL6uv 3kCAr1WlUqFAyWTC+Fp3kRdLApKAJPDLJyDFV6s+zKk4nRkGH6ocWXVuiclhO6PdMWIec6s7tT5e jOOxRjgQS+Drrju9aT1a31qcUYh7cMacJDTXqgmwEHVjT7hIr3FsfXff2LNKcYUe1Uoi7qGe7MRg DyPmGAlf10sUusF99RIlr+vUqv61LPeFk6TSg79NJTPau67bbMhJL2FrxZgHa8xBMuqmqaTPabjc WQbTI7x8S0pMqR68kTQzhuPcEPd40951Jofp8UHkldq3Ib32EjcpEVd6UHvixBVz1b9f5nl6ieLe 5FNfwtbf5GbIuv3yCEjx1arPWogvMYhp1sRPL76KOSZTRbqPWJpPck3ak9dcOJLuNQXWL0l8FbKT 5AwWbF0v40MpTzgb1let7OZlj5dypCaLdB2xQJX4Sik9+N5SyYy8vGR52Sosn/8yE1J+iomCiV6L maZ6KBvG4S7gz7yK+MoSdLh5osSJOEwYjW+a8gKk+Hplc/tZL6x67rZqPOBn5b+FC5fiq1Xn6xNR ggNuA+nYFEVjN3YlSMjdTUFz4wqn+Qc72fe/H8X0P6dwJmK4zVCaHMb+4UM8E3EU8UI5FcTuhUgy gKVRmev0fK14RioerEIUtz2BK63hMuaJ+32EE1kKRQNmmxN/OEBvPojDc5MnpbfYaVGIRhWq33Nr xVeRbNRPIJIkWwRjtx2vP4TbUhY7hckwvlCUVB7MvW6sBY0ZTwbNaYB8HL8vTHyqgKHLgevAE2IM k9bFQ56JYICRWIp8yUiXQyEY8qDftpQlOuwjkshRMtlwWYtEHzpbeL6KBO0+Cs4efkxkyBeLGCwK 4XDlnlWcc9V95Y6QCHQ3bWNtFxWZ0nwE1ElyJRM2lwPiGeyxGK60B3usE5cxQzJboGjoRvEPUPrr CDH9bwteNYK7SwiGPBPhAKOxKXLFEgZjNw5fmBFXF6zp+XKRDzsImDRiHhPZ2LDeJ7kCGLpsePxh FFutAJ3y21FKYdIjNr08zdVLpPNPpEePYKBAzOMg7kyiuQzkYqKPE0wVwNTtwBsO4RL1bGLz9XK3 2vNliJVZuI0ZEqLtmHH4IoQcWYbtXm7/CG919hKIqbhMjW1B2KIj0YmjkCRR+N9477/+v/w/fxcX 76TLrRL3mRpzFPaZUgmGNJK5IpgsuPwRAkfE1NrE/lqNA62ONxFfgtGaXJxln66obyCkMZkrYjBZ cHqDBFxdGEjht4co2k1k4lMY3BrDeQ/XDG5MTxLk8kVKXS78H5uJj2pk8kXo9hBRFSwGKGajBAMq iVyBUkmMBW6CER8249qer6gphF09QDTho+x4LxJX7GjW+OqXy0IKNRAimspRKIGxqxclHMHTLexc jB9BAmqCbMW2fOEQTmFb+QnCgRFiqTxFg5leJUhYsWGk1NgeaTCmmaA4peELqKT0vi6PzSPu7toX AWHPrjSehIarorCyYQfuJ8Mkh5/gXo5slMjFg/ozkRVsDSYsTj/h0JFV3vdW5iCPSwKtCEjx1YqQ eHCPRCgdj6CFjmDMqng8UfapCcT8tuJNAc3lJOlJojmNZIMOXNEClkCCqNuEeNiVYpBkSEyKDX4b IL6cqUGsoya0aACLIU982E3QGNbLLazT8yVCfs5gCUWN4LFANurFEzYQSKg4S1HcTo3OsEboiJGc OBZI0R0R4itH2OkmbVVRfTaYCqMo18g5bpAZsTEVduJJWomoAXpNeWLDHsKLPuKqg9ywA++MB031 0FWcwO/xctvgY7Jp2FGIr38l3h0mFnFhJovqcpFwreWJrPV8FZq1se4VuBhXcITBp4VxmQvEhz14 /92Ef7Isviy+AgP/I0rAYiDld/CbmImPY1E9dCz+Fv2eHu1FTMIOtZNINESvqUQ+5sUVbCOYHuVI fiW8XS2uDfkpsgYLFmK4HTEcMQ2P0GpRBbd2AG15oizblC76Q0a0RIDuYhzFPsykwYWWDmHT/45i T0RxZodxemdwqxEUm4Gs5sWj7SScGKFX1KWhzdd6nerFl8VfYCAqWBgpTAziDBgIJ0fozVV7vkpN bMGpe/5swSIDqorSZcBgzhOxKxTDaf2ZKzTjWIzhcUQwBFTCrm5KE8O4fD/iTajs0xrZn/OVvcnL T3IL8dWQi3hxcqrsDGiEXGZKqQiKEmdfJM5Ibxa/9TckLEE0vx2jwUw2eIDfZZzciI3Qa8oSdh7l Wunf+EsshM2QI+xy8tCTRnPlCNo9PFFiqO4uDMUpgm43aWd9qLEq7Oh+iGKP0BlNEBDqS7cXDWs8 Rm1WRYmJQTsBAsRGnJgNBSaGXXhnvCSjLgyTwzh8Myiqqo8fqaAbJe0kFneQdLmI7gvrY6mpEMPr CtMWTBAyBBvao22y0ZhmQnO6yXhiqC4zxWwYjzuDKx7VX4BXfuIlxEnSnUDT1VeWsMND3p9k1Kyt pJXoIi2BXdPwWYyUchoel8Y+LUmo4RtzqwlEHpcE1iYgxVcry6i8NSlJDaf+2l8iNWzHS4T0iKUm lJVTnbizwyRHu4i6PGQPmEj+OEBS7SbqcpEdTDLSLFllI8TX1DB270Ps3kHcDhsW84qvYn1hRwcJ j1V/243rLjvxy6E6y8IyXFTqQpc5wg4nD70ZtM4wdk9BFxNLzUz5rXh1T4wBv1WhGEwzeqQygec1 XI4k7vQAKXsAg5pkSZvqk7pmX4fny0PBv3JPUZ4PleSq0bJafBmJNWljdOn1uPL2r59rTxBfmoF0 T2MMR6IsvqyalXi87EksxNzYow4SsXKuWjHmxhpzkY66MBYLusfPbDJQKuTJpSN4h39EER7Lwtri a7n39IkwSNHl5WOXA1u3ae0wX2mCQeso3fE4ntwwjpsGenIZurU4nvwg9lELsZibrGIltFOr4jSl T9Y6yy5N9xSsbfO1Lw/14quaBTqnOK5kFFehWnylmtiChj0uGNqXmYKo24r4oglHR6K2P4QXJp8V XthCWcCtaX/CY9xqIGhxvIX4asTFGnfhSLhqcuamgnY8BT/pUSPBumdG5DsGjBrpin1PDB4gZIqR 1NUSiOMiB1XkchXzBTCbMZaKFPJZYgGF6AFNP3ftnC+TLqpGTFHdM1z22DlIrJHPJ+xXeK5MxhLF fE73DAuBFY97yA9adW9tMlBRLKU82Rx0GRO49ed9hXcxl6Vg6iLna2yPIwZ/gzFNiCoHmtGDd8CJ 3dZNo3VPujc17iIRdWGaCuJQivjFS0HVS88RYSv5EiazCUOxQC6XYEQR4jDD6OqE39c0GHn5Vicg xVcrCxDiy5MnmAwthwuFyHJmFDKqg0R1HpHIa1GKBGMWrrlSDKhdjCh5/NFuRsXfyVGWdMeaxb6G +HLZE5VBrUg2FmE0miCVmYF9dtz+ML5eE+sTX1ZiLgdJt3h7XpqRVsIUwbwHpRSshBFFK4q6kIm7 Mmhtw/SMmKvCFpBXXbhyg6RD/0Dp8ZKgjbaaxnfhHfOQ7hdv2JUQrTieGsY60k2sImKqL1lJuBee L4VSOL0s2vSwG2HSqzyM1eJLeCkbt3FFdK4Iz4ySQRVhVf03yWDPKJZ4RXxVJZzXJ6CX/3bqHgFT JVSjiXitqYvuLshOGvClhThpIb6EsJuKEhmNkkg95EfDARyKvxKyqaZTDhVFHQmGs25GulQGUm5u 2mIMZt2EzBpxxUjUZSOQre8LsASSRK2xJjbvrBF9q8RXdfJ9MYZb3CsZxV0tvkrxxrYQj+NKu7HH hSBxVTxSdeKrCceeqBNnWiGtOWsXlbQoc/k9Q7xeicUe3gSLOtYDfDzmJvN/BEjr/9GGNZjUvdk1 v1biqwGXA6oQWsGaBRX6c5pwk4x2ErGLLP4Vz0vZ9qMkKity6hefVIuvXEyE/uJkC0bM3d2YCpPk rFGSoUbiq4vS5CD2gAk1qfDE4yDmTFD7MlJudXEqSjAkQpoljOYuuo15Jotu4nHhibISta/hfRap F54iwVV5f4Xm9ug2NBzTyE+iRq4RS07xpGikx+ElOOJGj35W/wrCIypemDQOqA68pUj5xaMmv7Gc FjASm6KAia5uM6WpFPvCD6X4ajVPyuMvTUCKr1bIdM+XWKW1IpxSfuH5EhN8reer/IYeAPc+Epkj xNVOwuJvh4nEjIuEWjch1Jf9MuIrLib0ygozIfpcD3UPirOYJVsyYxHJ6MU8qagPRetETY9gXlfY sZXny4Mj6alK2i97xdJKI8+XHa8u1gwMW70YIitCSfdK6G+aWfw9PgzqyrFi3INdFd6PZqsdX1V8 bbDna13iy8mU8AgsBsohUjE56AN/Es96xFcxz1QOuvXE9iK5iTBebxr7GitjRVjOmbDiKsQhGMfz UPy9D0cujTESx9cthKiVyL6VSVx4dAv5AgaTGaPwBjS0+Raer/WIL1JNbMFEUSw4aCi+RMirMccl z1cirlTydApMahr/sNuZdDeyvzovYqmg51OVfwZMXUaKIm9q6X9MXVQ5lCt6vPFqx1UrQqtEqWjn Ks+X346nWPF8rSm+Vlb6NhRfjgROZxx7NKqH0ET/Cm4ho/B2NhZflCYZtocwhhWeeOM4q/KkVoar KfwipOmJonq6dZGre3y18vO62vM1RTTyhJ5/LeL7b8LeVzxf+QmVuMGB+a+uhvZoKDQa0wKYpvIY LN2Yhf1mEwSVYX5U1hDHev6ag6g9wD41giGSQHfM1edaqp2oekhXtHYKv9VNMSjFV6tpUh5/eQJS fLVipud8qZiCMTR3F+RjKC6VTjWuP7wTSg+hnSoxnw2TUThs7CiJEt0+ketl1Ac8bwJsIZHkbBTu CyayBiy93avzTNYpvnpFXo93BiWm4jaJZFQFX6KLcFrDnhB5RTsJR0c4YirpuUEubR/RRACTmNSi PUQ1L5Y6/3x1wr1483cES3qi+ErOF/jEQFzScDmjHAhrBI4Yycd8uH2TKzlfDjdpRznnyzCloXhC ZCs5X3r+00MnqurFZiqSCit44iJvKQBBccyNpil0lyYJehT+ynpyvtbv+aruK5Lexm2sc2ro+WHh NnzaiJ7zNeH38LvbxuWcr+pPLTT2fDlIeqxEdqrER3oxlnJ6zpvv380EU1HcxRaeL/0lII5djeKz GSv5LWmcq/JxRF65yCMKkzU4UUWulz7BRMiZ3EQrCz6KE4M4Av+o5PUZyE8E8XgzuGJxFEMzm2+e 81Xz2Ylqz5feviTuuKon9U81tIUQXWIibyi+yp7Whhwp53y9FdIYcXZRnPTjFs9KQqUz0sj+RL5U q4GgxfFX9Hy59edJo7Mm5ytGZyTBqMj5elXxZY1id2fwxKN4ugwUUmEUzzXyrr8svzSu/amJkp6n 6EsbKHV5135hLE0yaPWyGEigukyU8hMEPV7+ioe7CR9mPefrRxRNJOCL1E8PnqRjJefrQBgtIHK+ 4gy7g+BPEMLf0B5dDxuNaU5idg8Pl0RgYRK/28uMt5x3u+rdVrf5NBhdK7mSVeKrW7ycivExLvJl i+U8yFAKy58yqE1DFq9pO/LyLUlAiq9W3S4eTneSA9YSD58UKZZM2MVqJKdYjSS+nTWIe/jfyfdG yKhOkXSB9XcPcd8tf6tLn4z9JQIi9GKqhDT8b6GuteR+neLriFi15fcRik9RMHTh8DpZDKdxJMur HSeCPkLCdV4yYOq2owRHcAs/fC6KxxMkWXLxFzEpV7W9frXjlObXVyvliuV7ePwhPJXVjmKi9oVi +io5c6+TrlwMvOWwXCkXK692zBYxdjmwm9IkOyPlMGApRzwYICzqrdfNgTcYwiXqJsSIX6x2zFIw WHA5DCQe2jcw7FjfV3ayTdpYaxZFUqqXgJoijwmbs4dC7EfcySjOZO13rpqFHY3ZKF5vmMkCevK0 xWWFWIKdItfN2CrsWF4N5hMrsQql8qo434od1tZXeCOPEDFHSOveVuGR/VfidjHxLvV69Yq08v1c /jCBI+ayN6CJzVeXte6wozGL6vYQyRrxCG9dV2Nb0G2xSdix1IyjpXr1YAmjvio0iGITD18T+2s1 DrQ6/qriy1RePRwIxZjML6129BNwiRV7YrXjWmHHdXi+FCMTQYVQLEsRI8YuO+59D4nMiHCmi3Sz 73yJ8OC/xuj+UxL1yNrJcLn4MN5ggnzJgMHUjdPxFskoDOsRgqXV0gmy+oprF8PBAMK0xGrHYGW1 I8YufSwNuS0Ya1ZI1tmjvkp17TGterVjyWjG5vIT9vWuvYBC9+p9yEPPxEo+a3XYsZhC9fpQU2KJ t5Euq5ueH1XSdpFDtwW/gdbK5uXx1yIgxddr4XuVi/Nogxo9o00+ObHWbV/m20uvUq31XlPIkiqa sHUtuYeq8nEseaayJbosXZV8mxKTItRRlaOy3mLepPOKuSnyxm66l7yFYqGAM40nrbKcBvYmVVjW RRJ4HQLCvl1TfNwqR/V1ypDXSgJbnIAUX5ttAOLbOw+t+nd81v8rUZwYxhEyEknWeqzWf48NOlNP mn1SDnmKTx7EvHhE5CCpcsQwyaDIcQtEGXGaKWU1vG6NTjVB6LXjOhtU/1e4TU5z4orb0TQfFrGs PujG98RDPOqW3/95BZ7ykjeVQJFCLk9a9RI2BEmEbM0/nPumNkPWSxL4BRCQ4usX0Ek5zYUznMfi 09A8dR8Q3PT6V31wtGjQwxmKCElWPva58gFWETroxlH5IO3rptRsejOrCyxliflFuLQcwhFhFH/Y V0nK/VlrJguXBDaOgB6WU0iYXEQ08S26jbu1vJMkIAnUEpDiS1qEJCAJSAKSgCQgCUgCm0hAiq9N hC2LkgQkAUlAEpAEJAFJQIovaQOSgCQgCUgCkoAkIAlsIgEpvjYRtixKEpAEJAFJQBKQBCQBKb6k DUgCkoAkIAlIApKAJLCJBKT42kTYsihJQBKQBCQBSUASkASk+JI2sAEEihQKBkx1WxZtwI3lLSSB n4HAxthzoVDAZJLfa/gZOlAWKQm88QSk+GrVRW/Kl+Vb1fMnOC72eOxRrSRWbW5d/qp9KSw2wi4x OWxntDtGzCP2D6n91W/8+xNUc+WWYoNxdx5/ZpTeDSjop617NcMNqGyDW6SGrfiMKsmAhdduzwbz /ela/Tp3bm7P671zIe7BGXOS0FyV3R7WeWUpjtLjJeu6QTzUW3VtlrDDxZPhh6hH1nmvTTxtxbYK +K0+DGqyvHH1K/9Ee93k/RlG13iYq+36lYt45QtzRBUP4cQMJXuY9Mv28SuXKy/8NRGQ4qtVb5Zy pCaLdB2xrL1fWKvrf8HHG4uvIrnJKUqWXrqNJeJKD5o1sab4KmQnyRks2LrW3iNuQ/FssDh4bbHS tHHVDDeUQs3Nqiep1+6LDeb707X6de7c3J7Xe+e82KQ56X75ibkivhKLnRy/EWekd+m5ebPF14pt ZX/94ktsv+SI49B3+TBh/EV/QXq9Fi3P22gCUny1Ilrt+RL/9mSw2ouk03kKRSNW7zDO3E1Gkzn9 b3tA1bfWQWwGGw4wGpsiVyxhMHbj8IUZEdsK6fdJ02MtkXlYhJKBA+JL8Ppmuq/7K5GLBwmIDZjz RUoGExann3DoCGZ9g2UfBWcPPyYy5ItFDBaFcNiDvmd2KUt0WGxunaNksuGyFok+dDb1fHkeunGF 0/yDnexzR0gEqrfrFvuM9zBiFhsBm8nGhglEkuQKYNA3PA6jVL6MX9Pqmg2QjXT1evAHFcTeyGIj Z3usE7cxQyJboIgZhy9CSDBfFgcKSYebGW8S1VmZvMQxTx5/cpTeGsh54n4fYbGht74JsBN/OKB/ 3VvUPbTowlqIL28U7ouM4OoSN1jaPDhJVuzD223H6w/hthRQnS4ySqXsYhzFOkwxkCSq76w+waD9 GpaYn7x7yXu4nn4JEElmKRm6cTpNJJP7UBM+uuvMpZSLE1za2Lzbid2YILmv3vPVuC+W+LoMGdIF KGHGHQyXN1WvEV+N7cwo+kg9QHS5fkXiih3NGl8t0JefqRLptHiGoMsVJFLZHLkotuMKqCRyBUol 0T9ughEfwmxE/1wzuDE9SZATtt7lwv+xmfioRiZfhG4PEVXBIrqrkEINBNAm8xQNZmzutTdgzmn1 9mzRNzQXz5PYSF7fDD4c0m0gH/PgDBoIJVScphJZ1YU7ZkX7P8H30U2elN5ip0UhGlVY92ZiuviK gNNIKtlJOD7KET1yWSe+qjaoLon2uIYJBsQzvsavSdtfhmGrvig/5808X03GRNFFk2F8oSipvIEu hwNzJk5bsOz5amrXSg/X3nJiSMbJdnmJRT2YpjT8IZWkeDirN42n8fNevUk3pm7sSpARd92YnI/i cQVJ/ghv7TThDCcJda1sFl7fFxNr1G3dtvC6U4G8/o0mIMVXq+6pF19HIhj9cTRPF8IzZPemsARj qO7y345wJ2oygDnmwaF2EomKbTpK5GNeXME2gulRjuRVnEciGIZjRJVuDIUJBl0hjOEN2ANR1NeV wK5p+CxGSjkNj0tjn5YkZBGT/L8S7w4Ti7gwk0V1uUi4hNfKRGrYgXfGg6Z66CpO4Pd4uW3wMdki 7NjM87UsvjwZ3I4YjpiGR+jPqIJbO4C2SkCUSPkdKA+dqKoXm0EMlh78Mx5iMQ+mmAeLv8BANErA YqQwMYgzYCCcHKE3txJ2NIUduB96SWpOPXSTDTvwFPwkR3prBG5pYhDrqAktGsAiyhp2EzSGSYZs TA4e4HdJG34tjLurSMLvZvgfPt2bIfraGSyhqBE8FshGvXjCBgIJlX3aSllMDmNX4pQcEdKjRzCk /FhDZqJxK9Hl0G2LfvE78D7xoKoeuouTBBWFv5Y83F3FrhyqSTtUVJ8NUmEUzzUK7v9RG3Zs0hfC bi2+PAN/iRGwGSmmgri9BQYTwm6rwrrN7KwrjmKP0BlNEBDqUAhQu4Y1HmNVZFrcRzxTwzE08Szk o7idKgeiSQLdgouHJ0r5+TIUpwi63aSdceJKFxOifzJObsRG6DVlCTuPcq30b/wlFsJmyBF2OXno SaO5CmguF1pnCG3EibNl0mAAACAASURBVLkwQdDj44k7TnRVhWo9X8XJYZzeGdxqBMVmIKt58Wg7 CSdG6DUUiHmchA0BYh9nUTxJ7NEYvm4Dr+f5irAvpmIOuYgYQ8RVJ6Ya8SXa6ibZE0YNHMEk2qP4 SNujJHz1cjzXtO3rZ5hr0RdLL1mNxVeh2ZhYEP2u0RnWCB0xktUUPKEs9htCfLWwa+UAv8s6iGgB egwGzIYkiiNIyacREeNyKoKiJLBGE3jzjZ53E5rTTcYTQ3WZKWbDeNwZXPEo7npFq3u+0ngyKk5D 876YqK+beRMiAK3mNHn8jSAgxVerbqgXX84knmQUl3gb1Y+lUdKaeFEt/+3KMpgZ5UixQL5kxGwy UCrkyaUjeId/1M91FcR5GQbTYjPqcgWmgnaUYpj0SK3nqFX1Vh8vks+XMJlNGIoFcrkEI0q4/AZ5 pDyZFfxpRisFp/xWfKgkQ0WGewJ6rkaoUgXhBbFq9pY5X+sSX8pDFHuQosvLxy4Htm5TAy/f5Kp6 UIzhsYrJO447I+pkJR6veBPEoG2P4xJ9UqgXB2k8SQ2XcYqgw0spuFrcloQ48j7E7h3E7bBhqRoc hXAMGFXSFSBlodZNLC4GaavuyREioPzLoTqdJD1Jovsi2L0GIskABB2Eij2U0gb8yRCGoAOfIULC V6rKm2vSL4Eig9YAJm0lh6Y0oWAd2VflWapUIRvE7p7Bv2xXJSYHrQRMWq34atIXep/HHCSj7kqY PY/mcpL2JFH3qVU5dc3srMjEoJ0RU5REoLvirXSQWL5nldVWniGPeC70eanMMTMocptKFPMFMJsx looU8lliAYXogZX2BIwa6VA5uUgIiZApRlJXfGXPmMhFjDsSOKufW6EHdduusqPlKlWLLxMTipXQ To1kpQx073HVM1SIozj9TAFmReQ9lu3h9cVXAp8xhscZxhCIo7oKKzlf5vp+Fg7VQawhI1oyRE2q lc63asyqa3tOt/F1MFTMLfuipeeryZhojblwJFxVdlfhLMYtUwu7Vg4Q2hld7qNC1I09al8ZIyjn 8YlnOWGPNnjehZ070IwevANO7LZuGq4fqhZfueZ9Uair28uP5/KKXysBKb5a9ewq8ZVhMFMRTfXJ +NXiS3f1h9BSeTB10d0F2UkDvrQQCSLsmCdYNVDmVSeOjEJGdVaJEvHGd5RrT8qVbHP8ia92Bhj4 64/l/9j5b/wlHaJWrpVd+yOxKQqY6Oo2U5pKsS/8sCK+lkJdFdHnt6MQJu2bWRY4y3oiNYx1pFv3 ONW+/NUm3K9LfPm6KExFiYxGSaQe8qPhAA7FT1ix1SYk60Irij1R7SWZZNhaFoa+J3XioBjDbY3h TEZxV4svyqIh6U6i6WKoRKR+YtIRFMnGIoxGE6QyM7DPjtsfxtdrWp2gPjlIj/BaJdykXQ6SbuFV WXqTLU/aak+cuCfPsH2ErmgEg89Lwe+n6A1hVsMUfQqloBBS1QxXJ99PVfWL2xrFUc1jKojdZ1gd dhT1C5jQkoHlCVh4/JRSeFXCfaO+QIQME/9GZjmru0jMI7x0CWKiHssLGprZGZQmB7EHTKhJhSce BzFngqguIGrtOTP8BJczw+BDlXIeea34ysWCBNQ42YIRc3c3psIkOWt5oi17VVe8PfU5esviq0fF +pvbFNvaap92k0sXK7XPT7X4MhB12Qhk26i7EstSGLkysX8Y7yKYWPGSbIj46oaC8LD6S/jig+Q8 7nLCvWF1P+shYVee4YejFY6VpopnuEnbi+tlqJhp3Rctwo5NxsR9Ebvumc6MLq0mKBB1OUgNZhil hV0rBxgVz11l4BI2f/RanvruNujeZxu5Bs87+UnUyDViySmeFI30OLwER9x01+eCVIuvVPO+oK5u raYbeXzrEJDiq1VfryW+liaKhuJrBITHYTFQDu+Jh3fpDXRJfLkyKEm17DGjRGrYjtcQWfaylKsl 3vzzFEqVShrNmMkj0lnKPyPmrloPkv7Wp3ai6qEYcc4UfqubYrCF+AqVGO4Rq5TECsby3Ytxkbsj 3iA3QHwpBqZy0G0xY6BIbiKM15vGHktQGylZw/NViOG2a9iXPF/VnpmG4qvsfXAm3UT2RQgh8tFW L78q5bNkS2YsYkFAMU8q6kPROlHTI5QnJjGhVLxby+JL4WEzz5fLqHt+bpo9GOI5Pk6GKIq/TU5K iRLDCREWW6f4CpTW8HwNYh0RIrAu5ysbxOGewZsW4ZCy/Sy98desdmzSF8pDD9aog0TMXRHc5ZDP k+E0qjmyLL66m9qZKHqSYbsIpSs88cZxJjRcptX23FXUcDYSX13CaxPHHo3qIXTRnolBKyFj2RO1 ltiq7q9l8WWP4XA/qeIijDtPrmSky1QfBqr1fMUVK5F91eG8EoV8AYPJrCdal6aCeh7oAVuBdMlL XHPpHsONEl9QIK448Ret2PIJ8D9EFZ4gT7WHs4nnS8/Ta9z2dTPUvYfr6YtGYcdy3zUaE1d7vqpW O5pa2HWdwClEXdjj1V409OhDwWDGVGz0vAcwTeUxWLoxU6KQTRBUhvlRqeRqVs8T1eJLeJub9IXw fFULw1bTjTy+dQhI8dWqr19JfIX4h8dKZKdKfKQXYylHbNiD79/NBFNR3MVyngsDKpqvF6bCek5C jxYnoGcHv/pPH/SjPUTjIoepWM5RCaWw/CmDeiRbFeoql7HsYQlZKrlWbjRNobs0SdCj8Fda53yJ pNLQTpWYz4apbunP8uDuSuB0xbGrUXwil0jPqUjjXJUHJASDyHGq5HwZRR5Wbc5XTVisifhChCQd GgUjONR6kVdufzkPZSfh6AhHTCU9F82liZBegHxD8eXDJPL7giW8NTlf4NNFhhCuCnZ/CoMtREJ1 onuUxN9OtZJ3tk7xFbLoPHw/etAiHrpLKYIeDzfXzPkSXiMX8Z4IWqAXQ1bF4xmh4KrL+WrSF660 yPnK8d8iUUacRnLCftS3CNblfHU1tTNhw+XcPV/aQKnLqzNYM9tl1adcqjxfergpgycexdNloFDJ Ycu7/qK/pKxbOChUuJRzpMylLJriRt0ZJjF6pK5eJart2ZAaxhH4RyW3z0B+IojHm8EVi6N0TRF0 esi4Y8SE18np5UdvHM1lphz66iGqebGYIJeapGDqxaYv1mjyqyTc76t+KSlOMOj4Hf/+YxuOP4lw bFmYJK11OV9WjXjAUhfOX7KJtdueqrPxht5D4Y1eV180El9lD2rDMbEkQqwR3gppjDhN5EQOZWAK q57z1cKu6wVOPobbGWFnQCPk6sKQi+F1Byl640QMgQbPu5OY3cNDTxTV042xMInf7dUX7WhLi3aW uq0+56tJX0xK8fXqk9mv/Eopvlp18CuJr1F6s1G83jCTBTAazFhcVogl2ClyqozijT7BPiek41lK JgtOX5CAs+v1VzsWU6heH2pKLMEz0mV10/OjStoeI64Um4gvm1hSRMwvVjtmKRgsuBwGEg/tLcKO IjQyiHv438n3RurCprWrHcWqMZ9YhVkoYWjW5lKWmD9QrofwTvR6GA4quidvVU5SM/GFSIi248t7 mEj4Gqw4yzMR9BESYdqSAVO3HSU4grvb0CTsKDxORaY0PwE1Qa5Yvs7jD5VXBZZVHR67j1IgVV7l mNdw9kbY96elfLv1ii8bFLNoPh/qZI6iWLllLRHLWImtsdoRsQrOFyI2VcDQ5cRpzpDorA87ihDS 2n1RErlQqgGnKUtC3KPbiTcYwN1dt9qxqZ1VPIUiPPqvMbr/lEQ90iDRuJn4OlJgIqgQimUpYsTY Zce97yGRGbeeGzS1XuEgwlH5ScKBELFUXr9Xl0MhGKqs8q0bA2rt2U4uKkKfK3br8ocJHDGR8jtR HrqIxcr5h8WJQRy+f+CLa7hKUTyeIMmSi7+kPWScTuKVhQIvLb7EvUXi/4dxunXxJVxrop9HiE3l KRnN2JxNVjs2afv6BaxxnX3ROOG+1GxMtIgFqSqBgMpkHsy9LnryMUrDle98NbPrNQROMaXiC2lM 5sQ4KFaDLq1ubfy8V6921JkuX1PXYzXiq3lfiIR76flqNcluzeNSfP0c/b6FP9y6ubjLYbeRrmhV Yvzm1uD1SyuSm8ph6LaUw9dLCdNRB8nYUlL865eydIfVCfevcW8xSbmm+Dg5uryw5DXuJi+VBCQB SeBXQ0CKr5+jK6X4+smpixyPfC5OwJvEGVtjufhPXoONKkB47xyonRGioV5MhRRhRXzHTAjK+s8K vH6ZGyO+ihRyedKql7AhSCJke32P7us3Td5BEpAEJIE3hoAUXz9HV0jx9ZNTz2kuXOECFp+q53C8 XibdT17d5gXk4/jFh1OnCoiPOFqcXoIBJ63Sh16l1hsivvRke4WEyUVEE9+5e5WayGskAUlAEvj1 EpDi69fbt7JlkoAkIAlIApKAJPAGEpDi6w3sFFklSUASkAQkAUlAEvj1EpDi69fbt7JlkoAkIAlI ApKAJPAGEpDi6w3sFFklSUASkAQkAUlAEvj1EpDi69fbt7JlkoAkIAlIApKAJPAGEpDi6w3sFFkl SUASkAQkAUlAEvj1EpDi65fet6UChZKJVVvU/dLbJeu/pQiUCgVKJtPaWxBtKRKysW8ygUKhgMkk v53yJvfRL6VuUny98T2VI6p4CCdmKNnDpDVX1QQ1RdDhg0iCQPcaW++88W37JVawvEHw7xLdBBOv +vHWZn36czDJo7kcxJ0JYh7z5lcgp+FyZxlMj9DbtPTyptdqT5y4Yq76d2U7o0bXTg7TIx6TNe6/ Id8123xir1li1abVawBPDVvxGVXEZuyb/RPb8Yzsi69sZr8hFajeyuvVb1iIe3DGnCRqxuBXv99L X1n9fUh9w/Q8/sxoi2fmpUuRF2wSASm+Ngn0Kxej7yMWxxFTcXeZqN23epJhawijJsXXK/N92QuL MTyOGG9Zcjzcp5HwvcJX5pv26ctWaCPO/5nFlz6RFPBnpPjaiN5sfQ8pvlozWn1GXmwmn3TXvQC/ yp1e8ZpSjtRkka4jFkxSfL0ixDfnMim+WvZFiVw8SEBsCJ0vUjKYsDj9hENHMCPeqHwUnD38mMiQ LxYxWBTCYQ+WYlk0ORMxlpwJhagbR8KlvznVOK5LOeLBAOG42Ny5vJG0P6hgE5vzuoIkf4S3dppw hpOElt9UC8QUJ/6EONiJM5wg8A8Fq7YTz76HxBI5isZuXIEIIafwZpT0zZRFO6YKYOp24A2HcK3x mXThDbDHOnEZMySzBYqGbhT/AKW/jhDT/7bgVSO49WvFRrUBRmIp8qLu1RsWFyYJ65s8i82MBTdf 5cvsJbKxYQKRJLkCGLpsePxhFJvYfDnPRDjAaGyKXLGEwdiNwxdmxFX2bhQmw/hCUVL65rturAWN GU8GzWkQO/OiBgJok3mKBjM299JmulC9aS6mbuxKkBH3y3/5Ph914Uy4SQxO4fKWCCdGsC19Pr9h e6uMLL9Gn3aLeoeIpnIUSmDs6kUJR/B0GyjbTCeOQpJEwUIgruKqMZ4mvNZTH71qLcRXfoJwYKS8 KbXBTK8SJKzYMDbrK/GW7slgtZdIp3MUitDlChLx9dbZ/gTDdi+3dTPuJRAT7WtkUz+R56vZM9Pg 2TfE3DiiDuIxD2VfYYGou+w9jLqNL/2s/f/s3XF0W9dhJvhPtknIUgSxMaEmIpOo4pEnpDdjsqcS OdYE1JwETMdCasWwehJosiYypQOLDcHOBHCPCDhMQHpiwD0l2JEMm9uA3ozgnpXhURrIWxPJDglX LinNLuGmglJroDIp6DQCHVOQKelRsrTnPoAUABIgCFI0BH/4TyLew72/e997H+6970GvDCEgji1U Q2OZO2aTPzad/IFo+cfoTXbYdDWL/GJDvseNAjUaDapDfpTbEz9aLUX8sItfUAjHoazTQq0MILg9 MfI1ZKzHC5u0UAT9CNeY4PPqgaznkSj8VgscgTBicQWqm7SwOmzyLxzke/yJka8eiB/VDiAgjvEG Lcx2G1pk5DjCXnEOCyIsfi+7Tg2TtQf65I/Zyz/MvahV6shXHOMOPQyBWji8TrRkziDK55BFjkXJ AY1hEOelTahsMMLrTfyY+q1XHOMeC2zuEUQkFZp0GsAfgtrng0GaOxbiGBuLIhZXotFkhjYyiP6g ODaUUNvccM6dp7NdbzjyteTV+k56A8PXUq0lOrwuALXHA0uDElLEA4POg+2eIHoaxEH9GPx1Dvhc OlQjDLdOh4BOTN9APhn7NHNTOeICp8WYIQi3VoSMuZeEUasGxrNauN0mNCnECcwA66QBPp8BNfIo yRgMITdEvkh/LRz5arBEsNfhlgNX1GuC3lUpT7c0jJqhNU1C73bB2KRA2GOCwVMph4fmjP2K8NVg iaH1FS9sDQq5fAd8KnzT54UY6JHLG7djrL8JYYcWhmAjXG5xko3CZzbAMWuB361F1KqGSbLC52yB KjYCq96EKVMQ7sYA9BofND4PDDVAxGuE3lMLT8AClc8AjbsKLq/4WRoJUZ8JOns57GP9aIl5odd6 UOXwoKdFiYjXBINtFHUuEb6Erw6eqh54nFpUx4ZgN1hwXu+H1yDBrdUjZPDBratGPOyAQR+Czr/c acOIvJ9wRwD9LTG4tTqEjLfaczxbfdPaW2Sd1DYV05hq2GCDT5RbEcOQWQfTpAlBr050IjTZ42h1 u2GsUUBRnb4uKpbDS2XP4p9ZnpzhKyK7erc74OkR7eiDSedAuV2EfVP2toq6oW1xQWn2wWOsgyIq 2s6NWm9QniJPe6WNfEkYz9qnNBi7DdOO2Y6ZZlGHbMd+jR8GtRuNPj+M4ios2lQbhD7ggSa8zGPN GkOrVxxrSsSGOqC1KeAIOtEs93c3Km0e9OiqIY26YDT6sd3lh7M59RwC5OoHmcdN2GOEoScM9Q9E +EqMgo1p3HBbmoBRB4yGFxDTv5IMX7V4MqyBy2NDvUIBZcSe9TzSNNKBxn4VPF4bGsR5zKyHXelA sEcFT57HnwhfT442wOpxw1AXl/dhnTLC79VD4TdCa5dgdLtgaADC4vh3KGALuKGVcllFYFcbITkC 0IeMMPiqYF8seCH3sSjlGPmK+43QOACLxwFddQx+swGmEypYR5LhSxwLVj88hhpIfiPUplE02H1w 6xP/1jiq4A7a0JDreqN0Q6sNoeOsGy0c+Vrqyl30f2f4WrKJ4ohGJaiqVVDEY4hEAnAaxcUnhP4W Eb4MiFnH0N+SSDCj1kZY4EawpyExauFLfjuWT85jMATdSL/2jcBcb4PCHURPU7IwYmqr0YNGvx9G xfLCV6OnEX5/8ltZ3Ad9ow/aoAeVtkb0VHrkciVeC8s+RyGvg0nZT8ynh9qrQSD5LT/u06PRp8OY twqORiPi9lv1TwSLIPRjHtS6NdAFamEy6aFRN6Fm7noR98OotiOuM+GbOg2a6lS3vsnHY/IIWrVK AfHj2JExF0zmKRjHPPJnpg/7R+DQaHHWFIKn1gOtNghD0Ds/MnSrHloEdRp4lAaYWrVQN9VBVciP PY7boZZHu3rk0a609gUQdmSpb2YfywjUop5iREmllBCPRuRv0MYxrdyOSq+wV99q08x95fDK6r+g z+cY+UppT12y/eKRMGKqOtQge1vpYuJCMQbDmAeJ7URw1SLUcRbullzhaxTWrH3KDYXlNqz5WvSY 8UKvynXsxzFkVKO/3ge/sQZiSko7ZkDQrcGosfBjDSJwqf3QBb1o9OvkkfKgVz8/WjhuV8MQs2Ks vyV99Gup4yZtP8ljX5zDVHao9ZOwjrmROIVJGOlohE3lmQ9fPZXe5HlDwlCOujkVVqhNZ6E2dUCv aUJD9dwBn+hf+Rx/iTVfvlvT+TEvdGofdAEPFLZGeBrFer+5MadEnwoagnDEjTmsVHCoDThbV4fI CGDKsVYz17GoyBq+4vAZGuFRB+C/Nc0BvdoHjZj5ECNfqecmeQRrTD6nydcCOXCF0RHqRwty9Lka hq8lL9d30BsYvpZsrMRwvtM3jhhUqKmrhjQ+iu2Os8nwJb5Rjc0HJzH6YYQDYyJJxcT6IC/Ufh/U fi304Q4EF5w0RdDyQp0yPQmIEa1kIFMtM3z5NLdO1nKI80ETdAHGJtjC5SjPqG+DLQivPn3sPXMR 8uL/1iLoUcBWb0IAmfutgUkEx+oI/C4XvIEgxs5LqGrUwWK3QVujQGzcC1e/F4HRs5hS1EJjtCam spLD/h4xr6iqQV0NEB5RwDLmxXaHGkbJjjHn3Nxr4qTn14XgqbSi8cCriJdn1FClgyfYg6boCNyu F+ALjuN8XIl6jQl2px51eYcwCSNmNb7hl7BpfhsJly5Vo/WVAOS1yWL6OEt909gzwld83At7jxuB iARldQ3qlFGMxPW3wpdfXIAzpqrndpjDS6fIszy5Rr5E4DTEYV9sPVauz5bDV/JbulzWPMOX5Icx a5/yodp5G8LXoseMCF+5jn1AGumA2lkHr1+DwPyIqASvrvBjDfNfmLyodYugZUdIzA0mX/K6o4B+ YX/Iddy4EoEt1D+XemPw6jQY7QihHx2ot6ngEaMuyc8QXyKMkmM+fPXLNziIwCO2y1U3BcI+F/q9 AYyGJoHtauitDljEvGOex5+Y5hzUBOCdn1sfQke9E9VeD1Q2DYL6MXjmvgXg1jS0PWbIYbUdbvVj GEQj6hEGDD74xJD7Iq9cx2L28JXs28YQ3PPTEyPoqO9Hg38ufIXQEUoG3NTpQ/nQSA1fOfocw9eS V+s76Q0MX0u0lhjdULur4PY55bULYsTI2qhH3J5H+EIcfqMankYXNH4Lwh1B9GfO8YmglTnyFfNB r/ZAXcjI16IXEg+Utka4tntTFohLiEVjUKiqMxbxL7xrMmv4kke+TFC4boVPsS4jMVKoRDw8jpiq CXUqQIqNw2cTsdSGoKMekQhQ11ANBeKIDDlgMo1B7fOj3t0I26wtMY0rQo58ogrCMOZFo08LTdCQ suA1cdIbM4bg2e6CRn8eprGU6dl4FBGxDk0FRMajUDTUoRoSYuEA7EYzpowLg2fW7iCP1rlQ5fHC OH9DoIQxmxb2cheC/U3Z6+vWpj9CIS18jcOqNuC8wQu3oU5+nzzS6EmMdskjX1nDV+LOy8W9PFBH s/hnlidX+Ip6oNUI/7kRLCA65IZfocF2ny5rWyVGvgoIXxiFOUefCtyGacfGLOFLhJzsx74I26Mw a3qgsqgRtMdgFlOFChEICj/WUsOXaPcFI19WNQzxzJGvXP1AHDeZ+0lZcK+yQ6OfTDluEl8ybMm7 HcVI1K3wlbtuilgYYakaDWKIOx7FqNcCo6cK7jEbVHkef+mfJw6GxEigNihGPZc58jVvJUa+xAh9 EDZY5WlT46JLDnIfiysb+Uo5FnKEr4Zc1xuGrzspWy1ZVoavJYjkb5reenj9Yh1DPLFWqmcUDc+H 4G4JJ9cSZBn5EktEh4zQOCNQSvWwLrK+Sh7mN2tgOp9c86UUayXyXfMlpmhMiNt86NFUA34Dsl1I tOMd0NguJddLKBAdssNgCkEn1qxkrMHJe+TLq0Ukdb2aKo5RhxEGv1i/ZYNkVsMya4HXpUONWAPS oYNd4UDQeBY6nR9qtxeWJhHSxBqsMWj9yZBY6Ybf2QylFJHXkFlOVMM+6oVeElO3XtQ6PLC1KBH1 WaC3jMyv+RJrsPz1DrhtLaiWwvAY9XBXOhDoV8Elph3mAk5y/dmkKSgv1I+MjiCmakbTIjcfzI84 iCnkRab/pBEz1MYpWIJuVNqz1NfZnD5FlBq+MIKORhNmbQG4dSpIUbFWzYSXYcCPxRq4nOErMfLn WtTLg6p8y5PPmq9aBzw2sebLD7PeDlhfRfPLX8zy2V7o48sIX8mArRc3E9QoMJ6jT02Zsox8xcYx FFagobkufUG/aMDlPGpifrRYjFjnOvYTw5/ySHdAgkLjQqCnSW7n+FDhx1pq+Er0dw+q0tZ8+VDl CqA/bc1Xrn4gjhsfDFoXNvV44NSqkmslx9Eor/kSX2DEceOCx9YMRdgNg8GJmO7Wmq9b4St33XRn xXrNyuRCdkley6nzbIc3oIUv6/GXvnZNXvMV0eGorwdNyjjG7XoYzxvg9+gAsTbKLsk3+9xa8wVY Ah7oclrNrfkS5+k4hjo0sEyZ5HVkaQ9WkfI4FsW1wGNCQ8a6hZhYj+Yoh8XjlNd8DVkNePJV5a01 X6lfRHKEr7pc15sasbRisTVfUl7nsCXTAN+wpgIMX0txx0fhNlngHhW31yhR06hH/ZQbY2qx1iO+ ZPiCNISOxicxpj2KYPLkvOAjpTB8Vhtc4i6h5N2OZrsxMdKWc8F9HCN2PUyDEdTZA3ArbFnDl1i/ EvbaYXMHEI5JEHdO6awO2BK3EaW98g9fOqjS7tRUJO6itPdAJ+bzYqNwWGzJu+SUqGkywOowokmZ uPPSIu4gTZZFa7HDphVzjF6YTA6MxAClohoNukbAF0ClWBPXIEZd7LD0+OQ7NqubtaiJ+ABTcrg/ OgKHrSfxeUi/8zL1bitJWY0m3dydkInRM782dS1JpkjiPYkbKTK9xLdlPUJ6P/y6WJb6Zuwvo00j fjNM9gCikgIKVR20mk0IegHzWD8axChYjmlHKZdXdTb/zPotfbejPXm3I5Q1UJvs6NE3QJHrs1MX B8sfl2PaUQrDrTfAFVbC4AvAUpN6929qnxLX38XDl1i0XG/dBPdi06MFhi+9Itexn5y2Ctuh+XIA ja8k+mfiVfixlha+VIm7e209PoxE4/IxqzVZYdMtvEs3Zz9oSN41aXNjRL5LWNxN6INkTtztCBH4 5buSY1DUaKGtDiFQtdi041J1E3epWtAjlmhIot3UMNqd0Ncp0u52TD/+0vuiPPIFLVTRs4hKcShq 9MlzRuKzxz1W+RwWiSf2b7D2wDB3t2NWq4znfMX8MGqtkCwBeNJvHUauY7FF3KlssCMo6XB0rAdz S3Tn2nzUbYLN5nE4JQAAIABJREFUPYooVGjS1iPmm4I+uMgXkVzTjrmuN5pAlvCVzzlsqQsd/77W Agxft11cDPGLdWHBxLogvgoXiIUxGlehScwjyq/ESTXuGIMz/UxY+GdwyztUIApPhwf1/bfWLt2h FWGx70CBeGQcUWUd6uZGxOZusEpdBnEH1otFvn0CDF+3zVbcuRZFJOiEybsdbr8FBTyO87aV7o7c sbz4+zyM8gNngYjPBIOYAQu60ZI+e3FHVo+FXoFA2Av72Ub5GVh8UWCtBSIeLXR+NTweCxrE42Ls eljEdGnm1OZaF4yfV7QCDF+3rWkSi+3N4zUwuBPPCONrpQIpDzKMK6CsUcMoph3kh7PyRQEKUOBD EkguHXH4w/KSh+omHawOS/ImrQ+pTPzYohZg+Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSgAAUo QIGiFmD4KurmYeEoQAEKUIACFCg1AYavUmtR1ocCFKAABShAgaIWYPgq6uZh4ShAAQpQgAIUKDUB hq9Sa1HWhwIUoAAFKECBohZg+Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSgAAUoQIGiFmD4Kurm YeEoQAEKUIACFCg1AYavUmtR1ocCFKAABShAgaIWYPgq6uZh4ShAAQpQgAIUKDUBhq9Sa1HWhwIU oAAFKECBohZg+Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSgAAUoQIGiFmD4KurmYeEoQAEKUIAC FCg1AYavUmtR1ocCFKAABShAgaIWYPgq6uZh4ShAAQpQgAIUKDUBhq9Sa1HWhwIUoAAFKECBohZg +Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSgAAUoQIGiFmD4KurmYeEoQAEKUIACFCg1AYavUmtR 1ocCFKAABShAgaIWYPgq6uZh4ShAAQpQgAIUKDUBhq9Sa1HWhwIUoAAFKECBohZg+Crq5mHhKEAB ClCAAhQoNQGGr1JrUdaHAhSgAAUoQIGiFmD4KurmYeEoQAEKUIACFCg1AYavUmtR1ocCFKAABShA gaIWYPgq6uZh4ShAAQpQgAIUKDUBhq9Sa1HWhwIUoAAFKECBohZg+Crq5mHhKEABClCAAhQoNQGG r1JrUdaHAhSgAAUoQIGiFmD4KurmYeEoQAEKUIACFCg1AYavUmtR1ocCFKAABShAgaIWYPgq6uZh 4ShAAQpQgAIUKDUBhq9Sa1HWhwIUoAAFKECBohZg+Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSg AAUoQIGiFmD4KurmYeEoQAEKUIACFCg1AYavUmtR1ocCFKAABShAgaIWYPgq6uZh4ShAAQpQgAIU KDUBhq9Sa1HWhwIUoAAFKECBohZg+Crq5mHhKEABClCAAhQoNQGGr1JrUdaHAhSgAAUoQIGiFmD4 KurmYeEoQAEKUIACFCg1AYavZbfor/HTgZfxfvMf45H770lsPflTDJzcgq//4eewftn74wYUoAAF KEABCnyUBBi+lt3aC8PXr4c9+Onm/dA3fGzZe+MGFKAABShAAQp8tAQYvvJo74tv/xQnfvozvDNz D+7bsQMb3zkLxRfmRr7exajnNdz96Nexc3MeO+NbKEABClCAAhT4SAswfC3V/BdP44eeED7+8B/i S/cr8OvRV3Fs5B38zlc6E9OO4u+vzuBhwx7ct9S++HcKUIACFKAABT7yAgxfS3SBi6MeDJyrh/Hr DUhMKk7i9eeP4Wpy5Ov9cS+O/eYLMHzhtz/ynYkAFKAABShAAQosLcDwtYTR5OvP49jMF/DHj96P xPL6izj9Qw/eaRTTjtfxs//rh3hndxu+VLU0Nt9BAQpQgAIUoAAFGL7yGvn632D8+s75ka+fPn8M 74uRr0+fw6s/PI/fM+zFp5M3PrJLUYACFKAABShAgVwCDF9L9Y+L4/B6RrHxS3+IvbUb8e7pv8ax /+eX+NRXOrEXJ+A5+zkYHtmeHBVbamf8OwUoQAEKUIACH3UBhq88esD754fx2k9D+OVFYPOnP4ct Mz8DdhvxuXM/RGi7AY/WctgrD0a+hQIUoAAFKEABAAxf7AYUoAAFKEABClBgDQUYvtYQmx9FAQpQ gAIUoAAFGL7YByhAAQpQgAIUoMAaCjB8rSE2P4oCFKAABShAAQowfLEPUIACFKAABShAgTUUYPha Q2x+FAUoQAEKUIACFGD4Yh+gAAUoQAEKUIACayjA8LWG2PwoClCAAhSgAAUowPDFPkABClCAAhSg AAXWUIDhaw2x+VEUoAAFKEABClCA4Yt9gAIUoAAFKEABCqyhAMPXGmLzoyhAAQpQgAIUoADDF/sA BShAAQpQgAIUWEMBhq81xOZHUYACFKAABShAAYYv9gEKUIACFKAABSiwhgIMX2uIzY+iAAUoQAEK UIACDF/sAxSgAAUoQAEKUGANBRi+8sS+efMmLr1/GdeuX8f16x/kuVX62+65526U3XMPNn1sA9at W1fQPrgRBShAAQpQgAJ3tgDDVx7tN3vtOqYvXoIIYKvxEsGrYvMmlJfdsxq74z4oQAEKUIACFLiD BBi+lmgsEbhi706vWvCa+zgRwFT3VXAE7A46WFhUClCAAhSgwGoIMHwtoXjx0gyuXpXS3jU7O4t/ /Mefy//3r/7VZ1FeXo58/y91R+vXK7B508bVaEfugwIUoAAFKECBO0SA4WuJhnr3vYsL1nj9z9On 4ff/tbylVvsH+L2dO5Hv/6V+nFgDdt9vbb5DugqLSQEKUIACFKDAaggwfC2h+OvYbxa844f/50v4 m//7Nfn/f//fP4yv/++PI9//y9zZb6s+vhrtyH1QgAIUoAAFKHCHCDB8FTDydfrUKZw48WN5HdiX v/yIPPKV7/9x5OsOOTJYTApQgAIUoMBtEmD4WgI225qvn//8rLzlZz9bO7/mK5//S/04rvm6Tb2a u6UABShAAQoUsQDD1xKNw7sdi7j3smgUoAAFKECBO1CA4SuPRuNzvvJA4lsoQAEKUIACFMhLgOEr LybI67vi71/G9RU+4f6ee+6Bkk+4z1Odb6MABShAAQqUngDDV+m1KWtEAQpQgAIUoEARCzB8FXHj sGgUoAAFKEABCpSeAMNX6bUpa0QBClCAAhSgQBELMHwVceOwaBSgAAUoQAEKlJ4Aw1fptSlrRAEK UIACFKBAEQswfBVx47BoFKAABShAAQqUngDDV+m1KWtEAQpQgAIUoEARCzB8FXHjsGgUoAAFKEAB CpSeAMNX6bUpa0QBClCAAhSgQBELMHwVceOwaBSgAAUoQAEKlJ4Aw1fptSlrRAEKUIACFKBAEQsw fBVx47BoFKAABShAAQqUngDDV+m1KWtEAQpQgAIUoEARCzB8FXHjsGgUoAAFKEABCpSeAMNX6bUp a0QBClCAAhSgQBELMHwVceOwaBSgAAUoQAEKlJ4Aw1fptSlrRAEKUIACFKBAEQswfBVx47BoFKAA BShAAQqUngDDV+m1KWtEAQpQgAIUoEARCzB8FXHjsGgUoAAFKEABCpSeAMNX6bUpa0QBClCAAhSg QBELMHwVceOwaBSgAAUoQAEKlJ4Aw1fptSlrRAEKUIACFKBAEQswfBVx47BoFKAABShAAQqUngDD V+m1KWtEAQpQgAIUoEARCzB8FXHjsGgUoAAFKEABCpSeAMNX6bUpa0QBClCAAhSgQBELMHwVceOw aBSgAAUoQAEKlJ4Aw1fptSlrRAEKUIACFKBAEQswfBVx47BoFKAABShAAQqUnsC6qfcu3iy9arFG FKAABShAAQpQoDgFOPJVnO3CUlGAAhSgAAUoUKICDF8l2rCsFgUoQAEKUIACxSnA8FWc7cJSUYAC FKAABShQogIMXyXasKwWBShAAQpQgALFKcDwVZztwlJRgAIUoAAFKFCiAgxfJdqwrBYFKEABClCA AsUpwPBVnO3CUlGAAhSgAAUoUKICDF8l2rCsFgUoQAEKUIACxSnA8FWc7cJSUYACFKAABShQogIM XyXasKwWBShAAQpQgALFKcDwVZztwlJRgAIUoAAFKFCiAgxfJdqwrBYFKEABClCAAsUpwPBVnO3C UlGAAhSgAAUoUKICDF8l2rCsFgUoQAEKUIACxSnA8FWc7cJSUYACFKAABShQogIMXyXasKwWBShA AQpQgALFKcDwVZztwlJRgAIUoAAFKFCiAgxfJdqwrBYFKEABClCAAsUpwPBVnO3CUlGAAhSgAAUo UKICDF8l2rCsFgUoQAEKUIACxSnwoYWvK9J1xKavQpJmcfPmB7gbN1B29wey0rUP7sYHN+/Curvu hkJRji2/tQHry+8qTkGWigIUoAAFKEABCixDYE3D12XpA8Teu4qyuz7ARsXNZRQTeF9ah+s374aq Yj02KO5e1rZ8MwUoQAEKUIACFCgWgTUJX5elG/hNXMLme2/g7rvWrajuH9y4iekrd+E+pQIbFBwN WxEmN6YABShAAQpQYM0Fbmv4Ws3QlSkzF8JUm9djffnKAt2aq/MDKUABClCAAhT4yArctvAlwtGv 3r2Kj29c3vTiclviNzPr8Mn71q94RC3r50YH8RV1L0JzbyivxPamL+JJixmP1SmXW9yC3x9/5Rt4 0PIGKnX/DaedjQXvZ+GGYTz7xUfgPr/ILmu78MaJVlQv8Wkj5t9Fq+/SwndVPY5X37CiYRVLu2q7 mj6FAecAhicqsN/hxL6qVdtzgTs6g8Ntg6jqXm5ZCt2uwGLe9s1mcdJpQODBw+huqbjtn8YPWEOB ojvm1rDu/CgKZAjclvB19dpNTMevQHnv2njHrwAVynuxvuw2jIDNh69NqKqthjIeRWTyEmbLt8Mw eAxPN61NALv94ascldtrUZ1anZpWvOjUQpVn+CqvqkWdqvzWu1U6PPfC11Czkm4QexlfbXwaY6sc 5CYG29Eb249e0x5sSSny8oo6g7eHA5jesQ+7VhzeFg9R06HjGDw2jHPTQFkZUFaxA3v2H8DeB+aC yVqFrwkcNzsx2XoY7Q8sT2l5717d8DVzyonO1x5Eb3cLtuQoSL7vW15divvdo1Y1epRu+C11eRc0 f6cJnDw+iaqHd2Nb8vhanWMu76LyjRQoaoFVD19ixCv23toFrzndi1eALb917+qPgM2Fr02PYvCt Z9EMIPrKk/iK5SeYqvoqXv2JHQ2K29/Gtz98VcHgH8bT+Z+H5ys9N/JVb/0f+O/fWGqcbJlWtyl8 neprxY92ONC7N9cleamyXsCJLgvO7R9EZ/1S713q7wtD1ORQL/re3IYDB/ejPpkQZy+EcGzgGC7v PYS2+o0A1ip8AdMTb2N26/0rCKtLGYi/r274wswk3o5txP3blhhFy/d9+VThDnmPFB1HRNGAuqW+ XaXWJ1+nmZPofSKA3S92Y4/opgBW55i7Q3BZTAosIbDq4Ssau3Lbpxqz1UlMQVarVnm4bZHwBUTw /N7fh+NsJXTev8NzTQCkCH5sfxp9Pw7hvKRAVZ0GT/Z04YA8NRnFDx79d7CHtsPofx1P1QFzYWqT 7i/x9061/J4h+1P43ishxFCN5sdqEfWcwNnG7+PUyzooMqcdUz/vElBZr0Gn7Xs40JAYupIiPnSZ /wJD4UlIiirUNX8TT/d8Dck/pxDOTTvexvCV0yZHWaNOfEH7Im7NiNbCEvhrPFkjIfJKD7pcJzA+ KUGxvR5fNn0PT3+5BgoE8K3PHoRf+XnomqYwNCThwKsJ87lXaKAdfcMxXMYGbN6hT46KXMDJARcG hydwuUyFun1t6Nz3AOTrxoVTGHC9hOGJaXnkSdPWiQP1kxhod2I4dhko24wd+m50760CpkM4engA gfA0oKqHvtOEFvHVf+IoOnvDUFVdQDi2C9853IZtk8M44hzE6Zh46wPYeOYCdvYmpx0nT6D7yDT0 3zmA+zNH5mZCOOwMQdPdivvl8HUE0/VbETsdRgxb8VBrJ9r3JIfiZt7GiSNHcDwUw+UNW7HzQCcO 7qlC7LgZljN78WLXHrmOE0c70Rv7DzBc+6/47zsccO4ToXQWp5xP4Ed1IqRew1FzN6ZbB5IjXxdw auAIXjp5DtNl2/BQqwntuysQ6mvH0W29ie2nh9Dd/iYeOtwNMYN44UQXuib243B7HU47DTiOnSif PIcL07PYsrsN5rZdqEiGr+NlGlRMDCMcA7Y+1AZz+25cW7TMrTjcWY9rZ46i70gA4elr2LBtD9pM bdglqnDKiQOvPYjD3S0Q8Ws6NIi+gcRIYsWOPWjrbEW9+EPa+2Zw5mgfjgTCmMYGbNvdBlPbLnnk bHqoG50jKuwsO4fw5DRmt+xB+6FWyDl40X6ySOibncDQkcM4dvqdRJvsb8fBlm2Qm3k6hMG+AQwn Cog9j3eidZfYRwiH2wYQe2ArZiYmEJveiAf278eDE6/htfAFTM9uwZ52M1rlyqS8Im5o9WGYg/1o Fl8S5X9HYA06AbsY+fLAbxFj03GMuk2wuUcRhQp1WitcPS0LlxxkeM68fQJHjhxDKAZU1O2DqXMf 7o8dR1fvMUxcvAZs+AwePuTEAyOLHXPpRZ15+ziOHDmOUEy04UNoPdiG3VXZjp0hHHF6k8fOTqgm zmGbuQ8HtvGaT4E7Q2BVw9c770qouDfxrK4P6zV95W5svW8Vh6IWDV/ASMfvotV/CYnRHiVGzF9C q28K5VUPokF1CeHQeVza9Hk4f/IDPKZaOnxFfvAYHu55C7PlVahvqERs/C1MzgJYNHzVY9T6JXzN O4nK+r1oqY5iyP8Wpir34oWf9KFFEULXF/fDG6uC+rG9qI6cgHdsEps0R/C3L2iQPlF6u8NXPLeN MkdZexR4xfUCnveewtSmWmgf+xoOmL6GutFOfMF4AlObtqOxbhNi4bdw/lIVDL7X8XRDMBG+hB2A 8k0PovPVV/Bkxtxn5rfwieNm9IZ2o8u8D1tnTmHguwO4rHfCvHsDQn1PYHCjGb1tOzBz0oWuwQp0 DrThAWSOfF3AUHcXAlXt6Gqrw8yQE92BB9Dt3IcqEb663sQO03fQtmsLyjGJ4+YunKw/hO4D2zBz agDfdZ2DxtEnrz87M2BG4MFudO7aiNmJYQwMHMe5mQo8oD8ob//2YDfefKgbrfeL8PUMzu0yo/vx euDcILqdE3i4LxF43h5sh2v6cfR27kLZmQF0PXMB+17swp7p4zB3ncO+w2bs3pioR/iRF2GCC+0/ qkNv715smQ2hr/0YdvT2Yu+WybTwNXncjK7Tu3Ho0D5six3Hd7vPQNPXhZ1netE+vAeHu3YDJ3vR fuQcdhw8jMQ/O/Hmnj6Yd5fJ67oGcRBO825UiDBpOYzLj/fBvCvxtyMXNDjUpceOmWE80/UjbOs+ jNayxcts3jWBwXYnpvVOdO4GQgPd6JvW47B5FzamhoXpk+g1H8OW9m601Sfed3haj76M92041Yd2 70Z09rbhgWsn4TQPoKz9RXTWl2N6qAvtxypwsNeM3VtEe1swslOEUxE8s/WT9LOhHHQnHka3uQWq d4bg7A1gW7cTB6oS+wtsM6Or9QHgzCB6neewxyH8Qzjc2oeY3oHuli2YCR2G5ZnT2PpHDnS1bMH0 SSfMx7aiu+8A0mfAI3Br9YhYg3A2KRD16KALdyDobMa4PO2YCF/SUAfUTiVcvh40SX50aO1QOIJw yokt5ZXqOXMKfZ0vAa3fwcHd5Tjd1wVvhQmHW+8HljvyNXMKzs6XsKFNHB8b8c5xJ7qHd8j12Zbn sfNQ7/LD18UrN9H9o0v4m3+4ivjVm/jD37sX3Y9swuZ7b8MSlg/rosjPLUqBVQtfV6QbuH7tyupP +y2TTUx73l127+o9hiJL+Bq1/ht8zTuFWvPf4LXHTuGrn38aY4ov4oU3nkeLUpoPR/Lfn1QsMfJV mVz0Xgmd53U816yENNSJncYTuLRo+KrF6NGXMRKvRMsBHRqUc+FOBJBhPF39Mr7S+DRCYp3UT6xo kEI46vYjWqnGgW+oM77NZltw/yBswVeQzyxitgX3asf/i5eaT+S2eexU7rIumHa8VVed+y/RWaeA NPI0Hra9AaV8M0I8Gb5qYfD9Nzy9cKhP7lHp4WsCRzt7Md0m1jMlhpnECEf76T14seshnDvcjoHL +2Fu2wMxezUzfQ1lFRtRnhm+pk+gqz0EjQg3YiRk9hScT7yGB0UQmj6KTudltB0WoU18wAl0dYbx sBx+xH+kTh9OYNAsQo8Zu6+FcLjrOLaZD2Hv9EvoDOxEX2c9ZoadOIKDMO+ZyFioP42h7nac1njQ tbscM9OTuFZWhQr5M8ToydHkon4RproQ2/8iOu9/E92dp6ERZYG4CL6GB53daJkcQLt3K74jghhS w5fw6kasNRFIAPGZnXhL8yLMDwyj2yxCXRtmj1jw5sZtODfzEP68cyNeaj+Gz/SKULhwalEOJNOt GGivy1hwfwHHzRZMiKndXVnKvDHRfuf2dOLgww9gC2Ywfa0MFRvL00a0ykQYFH7JUTDMvI3h00D9 nvtRkRYqLmDyWgWqKkTdZnGy14DAzsQNAHL4eusRHDXvkvuJHG6vmXC4bRtCWftJ6klsAoOdTlw7 eBht9yf+f/LUECarWrBrY2afmMFJZztek0ce30lpOwAzw+h9YvjWtN4FEUwncWCgHZkz4BG3Foao HcGeanj1Oox/MyCHqsSar+TIl1jLKqlQoxJhS4LfUA+vNgivLmNOMsVJ9jxeD4dT9A/RhQfQPrAB ZhGYlhm+Zk460f7ag+jrTYxQiuNhoO0IysyH0VqecexcOIEuSwgPH+5KOXYGUNG1/PBl8Exj6IyU dpXZ/3vr0ffVzcu88vDtFFiewKqFrw9zujGzyu/OrMOnVmv6MZ+Rr7q/wE79q5hq/D7eelmXGFka 6cS/NpyApDmCv3+hFkdzTTv2SHjiwYMI4It44a3n0SLOf6M27NT/lbzPRacdo0E8a38Or4ycxVRy lAeohN77d+htiuDo1/bDOnYJ2LQd9U278GVdKx5rqckY9RIFnQtf5aiqb0TN/LDYdhxwWtGSx3qQ ufCVvuBegQbT83ha0buEzXa8kqusC8JXEN968D/Cv8jNlVB/H28NKtElRr6wFy/8vA8tWY6H9PCV GkqSG4T60Hp0G3rFqNXMBIa9R3Hi1DlMVzyAvQfasE+e3skY+ZoYRLvlNUyLlfHzr62JuymvZVxA xLd552UcPNyGxDU4JXypTsLZNYH9zgNQneyFJbQPh9sfwOypPljCD6Ov9X7MnuyDc6YVXS2TC+6S POVsxY8e7EOvPNcXwtGXjuH0xDSuYRbT0xuxPzm6Nhd4nPUBmId3ok+eghQX/E4M73Ri/0Q3XlId Sq6LSw1fYhTmGbx5LbWewI7HRUCZwVFzH9B2ANNHhrGzeydGusPQdKpw9DDQKTwXWdclh923NPCY d8pTkrfudpwblRuEyDuLlxmYnTyJY97jePPMNMp27Ia+TY9dYp1cSliYPdEFy7lHMNiZCE5pr9Tw NTuJk95BHA+9g8vXgNnpaVTJdVsYviYGO+G8dhCHRZLK2k9SP2mRvjb354lBdDqBg4fFdHLiJYc7 iNGkyxnhK2NN1YUTMFvO4cBg54LwJU81GmNweOvg1I2iNeCUpyDTwpcUgd/hhCcYRkwCpFgMNbYg vPrs4Ut4/vFLE/KNIPOvij04JL5gLDN8iSnp9La5gBPm5HrKLYscO72X0SaPPs8dO4WFr6pv/3pB V1CuX4ezPStZC7q8izDf/dEUWJXwdenKB7jrxlWsW1ccQ7WJ0a9VehJ+ljVfz37x9+E+L0aq/g7P KZ5KBAz54p8IX3MjV5Lmz/H3L9QvEb7ieOLBP0FABIa3xLThUuGrCj949EuwhxRoND6LpzQKDNn/ I9yhufAlOnMMo68M4hX/GxgZTQS0Kv1f4rUe9dpOO44uZaOFIldZF4Sv5Jqu2VroHd9Cc8ocqkJV j+aGUGLka1nha27ka249U/rI18xEDOVbq1BRPovp0AC6+i5DnzJdN7/gXv5Gfg6PvNiJXZnrtJJh a37kS35vlpGvimH0PjODtt69uDzYicGt3ckLf7d8oRc3CUwP9WKwwozOXecWjnx1deL0wy+ia/dl DHeLINWLQ3urUJ428iUv9EKncxr1O8KYqO9F957EmIMYhbC8uRX1F8JQmXshL/9KG/l6G4PtLlwz 3Rq9ST19vj3QDu/MDkxf24lecz1O93bhzBYVzpXtl4PjYovq5TvhZtoWHflKTIkmwteiZZ6dxuQ7 s1BtE9O5M3j7aDeeCWvg6G3BlsyRmtSRr9kLeHsC2Hb/FpSnvG/muBnd5/Ym74TNPfJ1K3xtw4Ws /SRVZ+HI18zkGcQ2PoBtyBz5Sl1zlznytYzwhTAcWgskdTUCsa8h4GyGfIpJGfkSo2P6kAE+lw7V Cgl+Yz286tzhq2xYTDHvxuHuxLrBtNcyw9eMGEV7bWf6yFf7EZSZFhn5kkeNV2fka7HwtWn9Ovyc 4eujmYjWsNarEr5+8S+XoFIW/pM/l64CU++vw9XZG3LVxSMjNm8APr7giM5fJha/gc984mP5b5Dt nQvCl1js/SS+anlDvtvx5Z/Y0RR/OTm1thcvvNEnTzuO27+ERz2TiWnJJ5U4+rWHYB0TYW0YzzUr EP3BY/h8z1tILLifm3asgs77Op5rUuSeduyJJcPa3EjZ3FRcMnwpX8a33WNQqL+F3sdqgLk6VH4V L5+yQ9wfcOuVz5qvOKKROJQ11YuMnAE573YU4Umeks1i03wqd1nnw9dX8eobdjTM3+xQjkb76/ir A+LuShE0Q1A9pkHN3IL7ZYUvILHmaw+6zHux7dopHO4ewOX9Ys3XrLwe6vTObpj3bRNDEeh+ZhL7 5CmPxBTfmw/9OQ61JNZxnejqxpt1nTh04AGUXQjhtdemsbN1T2LNV+q0o1jz1dWF03WHcGj/Nkyf PoJnjkwIc6r+AAAgAElEQVQk1nyljHyVHTejb6YdzgMVGO41I1DvRO/eGRzv9qKi04w9FXNrvkw4 9Hg9ysMvobtvEvv6urGnQkzZ/QlO138H5n1bMH16EM6BCdxaGyPWSnUhMLMDjyfXiCXTF5ztRxBS 7YdDHqnKDF+CoRPOCU3Cq2wSJ48FAE0rdm8Rs619eOK509j2R3OjRd1of2kSO82Hk9OUiWnHgVk9 ujv3YuvMMFxdR1HW1ofO5JqvbCNfwCJlFhf69uOoMneh9YENmDzxDLre3AmHmC5dsObrOKo6xfvE kqpe9MX2oc+8O21t2IXBdjwz+Qh6O3dj4+QwDju9uLz/sDySmDnteCt8VeTsJ2+fmkTFLjElCoht eieTa75iw3A9cxxb5cXiyTWD2zrRLRfwKLqd4VtrvuanjOWEnH43Ya6RLzG+7dBA54lD4wqiX/52 lx6+xu1qGM4b4XNpoYz4YDE6IJlyh6+K6WH0mo8n19BVYPrMCRyf2AH93vtRPnsSTsNxbO3txoFt iRN55jrL2ckQwtd2oF78XV7z5cWGtm607yrDxAknegM70DW35ivj2DnR1YXhukPoTjl2ClnzxWnH lV8iuYfCBFYlfP0qdhGbN6ZPQeRbnMuz6xD9zU1MTN3ETHLqfUM5UPXxdfidynXL/g3Iuc+NX76O T1SuwjO45p/zVYnt9VVQxicRPj8lP+dL/8Ix9MpDLxmLyqsvITyWuuAeGLfuwaPeSXkasLEGiQX5 QDJ8qbG8BfebkmvEylHVqEGdFMJIaBKz2ASd9//DczV+PPHFP0FA2g7NY19EdfwNvOI/C0n9ffzt oC7juV23ph0ra2tRnbK+VlHTiuecWsQdX8Je9/lkkFz41K7cj5pYwgZLlFUKJKZkZ8W0qAZPOvvQ EunEw2LBPTahqr4WqvhZhM5LUDuG8dJjhYx8JcLFyYEji97tODs5jIG+o3jzFxeBzTvwUOtBtO9O RJILw058dyCEDfvFHYJV8h1vg0deku9Wu7ZB3AV4EG27q1C+IHyJqbLUux3FHVsTeOCQuNtRBLNB VBzqwp6Zk3A+48UFceebpg7hYz/CZFkFduwTdxeKS3liuvLargpMnEzc7biztROdybsdZ84chfPI awhPb8Bndu7GttgZbNQ75fAhXmJa67vnHsafy+u65l6JtUbHd4i7FueWb6cvuMfsJIYHjuDo6Qlc RgV27Hkcna3ibsW59UgnUP/nTshP8pgU65HOJAOreEMifB2b3YmN75zGxPQGbNuTfrdj9vC1eJkv nBrAkZdO4py4U+4z9djfnrzLNMfdjqq6fWhr3wf5kWlpIS35AN5zl7Fhxx7sVr2NiW3t6N63LUf4 ul9uz0X7iRxShrFTrHeTbyK9dbej6CM7DxxE2x4xMrnU3Y5z6/WWH74QdkBjiMp3PSazV/q0Y2wI VqMNvlAcykYdtJUhnK1zwGvMePZM5t2OZ46jb+A4wrFrKFPthL7zYOLuXkzj1OFuHHnzGnZ/JzFC mhm+EuvlxJRtojOKux37jiT2Je52PHCwDXvm7nZMC1+Zx464U3gSdd3LX/MlFtx3/tVF/F1kFpeu 3oRY7/XdR5RccJ/vBZzvK1hgxeFr+v1ZrPvgCsrSJv7zL8+ZSeCff3MTV+bXLSW2vbcc+OTmdXjw 0/nvK/Wd169fx4271qPiYwU/QTOxuyxPuP+GyTz/WAf5fcnHKTz74xAmLykSQcHWdes98TE82/EU jgYngarP47EW4BXPG8CCR02cQgy1aG4ux6j/LXnBvVhHhoxHTSQeJfEcfhyOQ1n3KFqUP4E3GEej Yxh/9ZgK8fGX0WV/QQ5ll8orUdvciqd7vommBWu4cj3h/tv4yYlvyo+5+Ir1LBqcf40Xv7xwEdiS z/lawiZ3WSWEj3biW44goqhF58uv4Mk6CZEfO/E91wmMnp8CKmvR/Ni30WtRQ5XnyFdhvWrttpo8 3iUvqO+9zY/enzxqxhFxJ2dibnGNXit7lteHU+Y1ouHHLF9AvrHlGHaItZVr2Y2XX1JuQYF5gRWH r0j0Iio3iadvFzbyNRa5gV9Nr0PmjxCJ1WNiv//2/sLWkYnwFYvfRE31nXLXSgzjo3HUNYlnVeHW tKT2L3G6Xy3/H18fIYHZt3H0uwOIadrRtmdbck3NDC5Ml2GLfBfeyl8zF05i4LuvYcd3xKMMVr6/ /PdQePj68Mqcf+2K6Z02mw1er7fgIn39619Hd3d3wdvfng1ncOqwE2/tPIjHd23ExPFn8MzwDhzq u3Wjwu35XO6VAqsnsOLw9fYvYvjtivKCw9do5CZ+Nb14hUT4+vwKwte/vDeL+z9TuXpat3FPsR8/ iS+YglDUN6JBOYXx4FlMoQp67+vobWL0uo30xbvrubvnzsSAMuDatY3Yts+Ezj2rkJTeHkD7d09B td+MQ/vuT0x5rdmrwPD1oZZ5zXD4QXkIiIe7imffnX7nMjZs3Yn97XPTnXlszLdQoAgEVhy+/tcv fg1VxfqCw9f4L25i8j3gWsazWcvuBrYogV3bCx/5+vV7V7HjM6twoVqLhoqH8YqjF88PhXB+SoHK 2kY8ZunCU82r/HM9a1EXfgYFKEABClCAAlkFVhy+/umXv8LHN28oOHxNTCXWfL03A3yQuNkRd98F /NZGYGsFULOl8PA1NX0Z2z/9CTY/BShAAQpQgAIUKBqBFYev6OQ72PSxjQWHLyHxz78B/il2E/Er CZePrU+Erk99vHAnseZrOv4+Pl29tfCdcEsKUIACFKAABSiwygIrDl+/jL6DzZtWFr6u31iH6zeA GzcSy+7Fs1rL7l6He+7KXIaff+0ZvvK34jspQAEKUIACFFg7gRWHr/O//Bfct/neFY183Y7qivDF acfbIct9UoACFKAABSiwEoEVh69zv7iALRWKZYevm1iH996/ifelm5CuQR75Sn3dcxegKAM2lK/D xz+2DnetW94omAhfd9SC+5W0IrelAAUoQAEKUOCOEVhx+Hr7F1P47YqyvMOXCFmz19fh0pUb+JeL wHuXIT/ZfvZ6uln5PSJ4Qf6Zoa0V6/AxBbC+PP+pSBG+7qRHTdwxPYYFpQAFKEABClBgRQIrDl/L fcjqxSvAL6aAyIXljWRtqwS2Va6T74LM53XnPWQ1n1rxPRSgAAUoQAEK3OkCKw5fy/15oX+KAWcm by54rtdSkHffdROf/eQ63P+J/B49sWo/L4TLiJx8Axe3fwm/+8mlSpn+94sBB779D5+H60/+DTZc +5/4syf/Ej/L2MXnnujH41MOfPvV6CI7r8Z+exf2vvsSDvaN4nLaO+rwZP+30LhheWXiuylAAQpQ gAIU+HAFVhy+RPGX88Pa/+vXN/GzxXJGHg7i8RP/+lN5vFH81PVq/bA23sXQM72I/Ptn8WTD8n5C aUH4+tbr+FxPF1qyPnT/Mv7W+RT+duez+NM9KanqH16C6Ycb0PHsfiz8Wev8PPguClCAAhSgAAWK Q2BVwtfEv7yPLcq78qrRWoWv2KWb+Mxv5zlHmaPkLz31n/C3714B7lGiRvcn+FPNJ3A58jr+D8/r +NnUNWz49O9Bb9Cj8ZMLgxnDV15dgm+iAAUoQAEKfKQEViV8XbryAfDBVdx919JTgr98F/jFu8tb 7zXXIp+5bx0+fd/S7fPBjZu4p3w97i2/e+k3L/mOjJGvyyH0W49hw9f/Ex5vuBe/eu2/4vtv7sCf 9nwFn87Y14cZvl588UWcP39+0dpt374dTzzxxJI15xsoQAEKUIACFFh9gVUJX6JY/xy7gvs2Fhaq Vrta786sw6dU967SbtPD1+VTf4Fv/6QO/+XQF7BZfMK1t/HSUy+hrL0X+ow5wSXXfH1qH/7Ld76E W0vJsk87Zq75+vSjPfjew9mT6MzMDJ566qkFAUwEr2effRYbN658VHCVgLkbClCAAhSgwEdKYNXC 1+z1m7hy5bL8ZPoP83Xtg5u4994NKL9ntcqRHr6mAg48fb4FR75Zn6zmuxj6bi8if7BwTdiHOfIl CpcZwBi8Psyeyc+mAAUoQAEKJARWLXyJnf3qNxI2r//gQ7WNX70bn/i4YhXLsMTIF5IjX0/kMfL1 ISy4nwtgAoQjXqvYLbgrClCAAhSgQIECqxq+RBk+zOnH1Z1unBO9iP/xjBVjD3XjP++5D2Xza74s +KOGMvwy4MafjfwO/nORrflK7Q8igIkXpxoLPEq4GQUoQAEKUGAVBVY9fN24eRO//s0VbF6tJVd5 Vnb6MvCJ++7FXeJXuVf5NXXSje//8Aw2/EEXvvfwJ3D5H1/H8z98HT9P3u2436DHv83nbsdFnvP1 2f/wffzpHnn1GAA+amKVm467owAFKEABChSdwKqHL1HDK7M3cPnyVdxbvjb1vXIN2LTx3lVc57U2 5eanUIACFKAABSjw0RO4LeFLMIrHPfzq3av4+G2+A/I3M+vwyfvW5/WYi49e87LGFKAABShAAQoU m8BtC19zFX3nXbEI/zrWrfJ04M2bN3Hx6j3Yet9qLq4vtuZheShAAQpQgAIUKDWB2x6+BFj88geI z8yi4t4buCuPB7HmQhZryqYv3wXlxnIoN6zGQ1RLrUlZHwpQgAIUoAAFillgTcLXHMDM1Q8wNX0V yvUf4O78fo1o3u76DeCSdDcqN6/HxvUMXcXcqVg2ClCAAhSgAAWyC6xp+EotxoX3ruLipcvAzWu4 Czdx9103cc+6xBPyr99chxs31uEDrAPWlaNCeS9UFevZjhSgAAUoQAEKUOCOF/jQwtcdL8cKUIAC FKAABShAgQIEGL4KQOMmFKAABShAAQpQoFABhq9C5bgdBShAAQpQgAIUKECA4asANG5CAQpQgAIU oAAFChVg+CpUjttRgAIUoAAFKECBAgQYvgpA4yYUoAAFKEABClCgUAGGr0LluB0FKEABClCAAhQo QIDhqwA0bkIBClCAAhSgAAUKFWD4KlSO21GAAhSgAAUoQIECBBi+CkDjJhSgAAUoQAEKUKBQAYav QuW4HQUoQAEKUIACFChAgOGrADRuQgEKUIACFKAABQoVYPgqVI7bUYACFKAABShAgQIEGL4KQOMm FKAABShAAQpQoFABhq9C5bgdBShAAQpQgAIUKECA4asANG5CAQpQgAIUoAAFChVg+CpUjttRgAIU oAAFKECBAgQYvgpA4yYUoAAFKEABClCgUAGGr0LluB0FKEABClCAAhQoQIDhqwA0bkIBClCAAhSg AAUKFWD4KlSO21GAAhSgAAUoQIECBBi+CkDjJhSgAAUoQAEKUKBQAYavQuW4HQUoQAEKUIACFChA gOGrADRuQgEKUIACFKAABQoVYPgqVI7bUYACFKAABShAgQIEGL4KQOMmFKAABShAAQpQoFABhq9C 5bgdBShAAQpQgAIUKECA4asANG5CAQpQgAIUoAAFChVg+CpUjttRgAIUoAAFKECBAgQYvgpA4yYU oAAFKEABClCgUAGGr0LluB0FKEABClCAAhQoQIDhqwA0bkIBChSTQByxmAIqlaKYClVQWaRYDJJK BWVBW9/ejYq5bLe35h+lvZfOsVTsrcbwtUQLjZjVMIY08PptaEg5t0vjdmj1Qai9fthS/7BaLS5F MeRxYdAXRDg6BQmVqG5QQ/9NCwzNqtX6FHk/Qx31cFb7ELBUw2+sh7veD7+xJv0zIm5otSF0nHWj ZVU/fTk7G4ddbYTkGENP03K2kzDuNsDkGsOk4lH8YMyJ5kKv06NWNB54GVPzH1+OTVV1aNJ2wGpp RvVyirVG7424tdAG9Qh69UjtOXGfAY3uWvgCFtTdprLc6lsZ/WnVPk+COEb763zwGZanf/vLtsxK RjzQ6cPoEP1zmZve9rdnlG3V7KJ+mA1W+M9LqLP64TPcrn5SuNCouREWpRtBW8OCnUh+I+rdjQj4 DR/6sb/yNin8WFpKN5dhrm3jI3YYLF6E4tVo9QaQ1gRL9J2VeyxSspgXenUAujEPdFEHNPoorKH+ go5Xhq+lek18BGatESGNF35bA+RrtjQOu9aAMZ0XPmNd4v9W9RWBR6+DK66GyWyEpq4aCimK8UA/ ehwRaFY58MXCI4goGtBUo8gevqQIRkfiqGlpSLuAr2q1l9xZHJGRcUgNzahb1tBAGHaNHueNfrg0 KiiVK2gxEb4Mk7AEHFCL3UhxRMMB9NtciKhd8Dtbim7UotTDl/jC4GkM3PnhKyxO5jFYQ0UYvjLK tloXtrjfgEbXdni8JjQolVCs4NBc8vRR4BvulPB16zy+rJNjiookn/8LOZaWoi00fI2Y62GRHPD3 NEEp+kfKBy3Vd1buwfC1VLve9r/HR63QGcbQ6PGjp0nCqFUH41k9fD4DahDFkN0Gp28UUUmJGo0R 9h4DGkT/j43AYemBbzyKOFRo0Fpgt2lRs8QJJuYzQOPYBEegHy0Zx1HYa4W/0ghLS7U8YvWCQg/V +QAi0TikGh2s36yGv9+DUDQO1BngchvlEbt42Au7zY1AJAZJUqC6SQ+7y4ImZSEjX1H4rRY4AmHE 4mJfWlgdNiwckJMQ8dthcwUQFuVTCAMrHD0t6d8S5W8TPmgDPuirAWnEDPU3zsIw5Ic8ADduh9oE uIJa+OdGvlRuaA0hNKoljI1FEIsDNTo7XJbmjHAYhltngCs0BWyqRI3eDb9JCb/dBod/HDHRZs0G WO1GNKmAmFcPTaAKmlgQgVgDbH43dKnDRXL4isN+tj9tBFCMhGr0Y9D7RZmz11vh00Pj1cDvm/um HINXr4FfG4BXr0TEZ5W9xmOAqk4Dk6MHuqU6zBJHQH7hK1ebZu/jS3mJPtozq0NjzA9/OA5ljQYW lzNZpyiGHDb0+8YRiUtQKOugsTjg1IlGz6+PRTx66BxjuIRKbNe7ELDVQRwjNlcQ4TigrFPDZO2B Xj4g01+5yxbPsh8FhjrU6FGljITE/TCq3aj3ibYv0Eoaglltwquim1Y1w+ZzQycNwW5zwjcahaSo RpPODLst49iRqyQh7DPLdY7EAEVNEwxWB4zi4IaUs0/Fxz2w9rgRFFiqBuisDthaMkYQFynbJvsS 7ZrtnJh68RzqgNYSwOQlBSqrmmD7s3q4/3MI9fUR+IMSNA4/nM2xrMfqcs5/6S2f+7wkRfywWxyJ /lqnhVoZQHB7sr2lMLxmC1yBCCRVE3SNcXjPauWRL8Ui5w5NNJtvjjYr8LqRGojnbKrOBxCKxSEp G28dd1n2D2/msdSQo++swDDjOIyNumHr8WAkEodC1QCtyQ6brgbjdg2M3vO4hE2obDDB6xXX28Qr ntl3fK0Y1fUgrlYh5B+HQu+BOWpIzujUALFRuG02eEaiiItjSW+FI3mtyGmFOEbdFtg8I4hK1WjW 1SLqvQRD2siXEzCrYYEDQWdzcoBmFFaNBQpXMH20TswgJa9bHPnKK7pJGLdroQ+q4bFKsFkmYfR5 oKuWMO7QwhBshMstwkcUPrMBjlkL/G4tolY1TJIVPmcLVLERWPUmTJmCcGtzfTOJw29ohL3Kg7El 5taGOmrxZEiLH/icaFaF4dB+GS9IX8NRXw+aFBE4dFqcNYzBo4vArjbgvNEHt74Givg47Ho9xrSJ 6cXlTjs2D3WgsV8Fj1dMxUbhN+thVzoQ7GlKHwUUHU0XgNrjgaVBCSnigUHnwXZPED1pI/hReHRa BA1BeLRKhO0a6LwxNNhEIFEh7NDAGLcj2KO4Ne0owleLC0qzDx4x+hj1Qq91o9YbhG3BHFpiujLu GINTDs8aGM9q4Xab0CTKbzXAOmmQw7TSq0eTPY5WtxvGGgUU1Rnrb7KEL2AU1kYDJi1j8NR7s9e7 xg+D2o1G+UItMoYHOm0Q+oAHmrAZWtMk9G4XjE0KhD0mGDyVcARWME0KIJ/wVZO1TRsQztHHxQk7 l5fcR4NNsHoc0NfEEbDqYb5kwZhHB0l8yXBXweXtQbNKQtRngs5eDvtYP5pH8uxjSP+2HvMbobVL MLpdMDQAYa8JBocCtoAb2ozZ+pxly7Ef0U5qmxLuoA2iG8f9Rqg9jfD79IitwAppo0vieNYjWO+A 2ybOH0OwGy0YU3sRsGR08JgPeo0PGp8HYtYu4jVC76mFJ2BB9UiOPiVCo8YOyeKBS18DadQFozGA Rm8AmR+RXjbxhS1bu2oRyWGQuWBCnvr2ahD06aES5wv5mPbCoVNBoVQhIi7AWY7VSN7nv4zzbc7z UhgOjR5jGjfcliZg1AGj4QXE9K8gaKvDqFkD06QBHrcBNfEhWA0mvKqwYCQZvtKOBcUYLNl8Vdnb TCroupH6JVqc0xPXhud9TrSo4hi1amGYNMnHXSTr/hMzH3MjX/FcfSea69yeyzBj6jZ53q60edCj q072QT+2u0TwVmJEfHmrXqTPi+Mute/I598DCDTY4bGqoVRUI2yfW04DeHQ6eKp64HFqUS2OJYMF 5/V+eA1iECO7lZhW1joAi8cFXXUUPpMBlkANHOPp045No2Z5gMARTJyr5QGEHpV8DKYdrfN93AeG r7zCV2Kq0aHTwxNRotnph1s+k4sGNyJuH0N/S3I4S1xMNUHoxzyodWugC9TCZNJDo25CTV6jwVF4 tBr4ksFILp58gXYgLCUKq2iwwO81INxRD5tShLREhxadqEflk08SiX/Xy2th/MZqxKMxoLoaSimO WDQMn80Ib61HXsew7PAlOpbpLNSmDug1TWiozlaxOKJRCapqFRTxGCKRAJxGB8rtIfRnLBwTAUEf NiPYXwOvzoBwrQrBqVYE3XXw6nQIdwThbA6nhy/tWOIbiPzxEbi1WoQ6zsK9YFFaavgagbneBoU7 eGvdWNwHQ6MHjX4/dGN6qL1q+P3G+W9ZaV0ka/gSJxwdxvRi+kuZo95xDBnV6K8X7VKDqEcH7ZgB QbcGo8ZG9FR6EJxPpqLcBsSsKf0r3/6a8r68wlfWNs3dx9X+3F6ib9mU7vkvEpIc8urgE77xmDxa XK1SQIpFERlzwWSegnHMA+14vn0sNXwp4TM0wtOYumYx0S9EsPemDWEmjo/Fy6ZHKNd+tBH5Wy1c 4ktEHD6DGl6NHz6x/iPH+WApq7SAE7ZDrZ+EdcyNuVOLbNejhCfYI4e++Zc88mZHXGfCN3UaNNWp kl+CJAzl6FO2KUNGX0+s+REmC9Y3LTLtuLiduHhnPycmjtWUomeGL20QhjFv8pjOfaxud+V7/stc R5bjvFSd6S5hpKMRNpU4V8YXnDvkAOBRz498pZ47xKhw+rkkxdc0maXNIH/ZXP51IzN81aNHLnOi p0hDRtT318vnNSnr/lOPJVXOvtPfImU/x+U0TA9f4vynCejS1qOO29UwxKwY62/B6LLCV3q/m7+u 6QLQin4V9M7PYiTarVH2iIjPWNRqkfNA1AOtRvTRzDVf47CKWRm7uE5BPo7EPhd8UZLXTieuWwxf y7iYyQ3m2g5v8hsvJD+M9SYEUI7ytP3UwCSmn6oj8Ltc8AaCGDsvoapRB4vdBm3OaSRxMm+EI23k SwSmOET2ivlN0PsTw9wifDlTvhVkrsNIDV8Rnx02tx/hmBLVdXXySFyk0Stf6JcbvloQR9jnQr83 gNHQJLBdDb3VAcuCecfEtJLTN44YVKipq4Y0PortjrMLwpd84THGYfc14AXdKFrdNXAao7B669Av /h3sR4siZcG9GPlKuwEgz/BVJ4KWF+qAD7fWZ4/A3JgIZKazeqj94mSgW3xtW46RL3OjAZdsY3Br 4znrLY10QO2sg9evQUCrR7gjAHEy8+qaYAtn9iWgwRaURwALfcnhK6BDYH6qM7Gn9ItDljZtGsvZ x+WwmsNrwdqgkQ7U91TDK74RylMBPfCMRgFVDepqgPCIAhb54ptvH0u9YIhvuBoE9WK0d+4qn/j7 YjeRZC+bHmNL7EdcIEySAwFxERWjTgEv9Mrc54OlrNLCl3CyqeCZO9eIBhPHiC4Kc8aUt9yW4164 +r0IjJ7FlKIWGqMVDmMN/Dn6lDWqx5dfiKI8/eQFhcYlX/jSVkcsteZrrl39dejPdU7MyEELRr5S j2n5S1H2Y1Xtyff8lxm+cpyXFAvd5ZF3yYGg6fz8l7T5+5FGzWh01smj5mLaMfVYENvl8o0v2mZN UEqFXDcWhq/ETVTJug91oH7uS0/W/SNl5EuxxPlIyn6Oy2WYcdNCImjZEeq/dYtJIpCJG4TEl+5l jHyp574QJc5v88e3mGk48CrimR1dpZO/yMTnbzjLtNIioNVgTJ49Sp5P5Gu+D5pFFtyLuiRmaCSY 1f2o8yZnN1JP3Ck3rjF8LeOKtvDusFGYG01QuFLvvpv7VqVEPDyOmKoJdSpAio3Lo00O2BB0a3Mu ypYvii4lnP6FUyWJC6YmJXzdOsCyhi+NSP5+qL1eefpPrAMZ6mhEjzIxyrLc8NUcDSMsVaNBDOXF oxj1WmD0VME95sT/394ZQieORWH4VxO1qKKKKmpRRYHKqIxiVdTGxWVNo4giKiiqMmbjopY1G7WM aRQoqlpFFaNSlVGMyqg99yUtISUBOjNnC+fi5pwOffnuy3v/u/e/r/kmRDFW7xyeKIsS6DsMOhpW zhbxBRJWNqBdILz/gIl3jhH9W6kjfFQRCmY/QHx1t5ymqWwj+5CfMl+vEF/JfABFf4AeBqKzsPK5 kzn6yhB1S8bMidEXqWoSCR24F/kUe4I4iiHVG/ieHgFhTHXOxULTze2o80EH+mNaApRKY6oiKJ3j dawKG07xdSoXOCYiyih8sxG4Kho0LrEwpZmP3mq/OUZzeV0qOTzztbFBPQtDAw+7MmjZYcE0PmNA J3dfRQ1V68FuVhvii3yO+r6Zrwh3S6DVbkDCCsubEUzzFnIwQetj+ZxKAjUTC+suWMpAxlIDL5LZ +4qvUIZfMV+KdtcX4ktd4Or+yU9Z/a5S5isfv/LD56b4qlyXGuTdfIR566GXdlflsoGU+bIgeev1 nil0LTsAAAZqSURBVN4t2aNM+UvxFY8r+KI8Zjpet28UPV/bxZeOWum+pGD2XHasV65HSVCxxlUy 3CPzNZChr16R+SoTX70AivY5F1OqWUZYkt+3Xsvtf0XxpYl1wP11shaxucrWi25Hekf0GH07ge23 hSB/0X/N4usAxVVMkW+05hf8Q1RbHxnQJ+S3sJGQCe+bhbGrokneoisVjpSa8pLFFPOkhQ/tLRmN ZAlfVzGKutDN39G7bIpux4fZGJ4XIqauuo8fcFdQ7KWLD50etXvokzH0poQ48zFE6l+iHHSo+GoL r84ZRmPyEyTCY6L6FxiH9kZ9W5xgxpfZNR2r1MM0nKP95z28p1rKM98Ec7rWI0zQslLzOQlEMwS6 w1l28vgR4osWUwXm58zzVSPP2qbna3fma0u349BFJPsIhl2s9njuu0H6rJRlCDOvHJlIFftr5leS EN040M17qOQPayVYzqeI6+9FV+pBn5i8PX0sZRsDo4OmlCC69zEchGhch6KELpo8tsbUwirvkduY 40M0aRF+VeYrFTjumYfJ9Xtx2ie/pPWpAWc+hjLbb46Jg4RxieGZh4A8OjMTipPA3PB8AVbobzZO bFyxki26uaxcfWLs+B7KtGrw40RkJlMfZ9V6sJvVk/jUqMmjGcFVNMw6Bc9Xx193XT9NAuFhmkD2 xrC6dOgbQddu0ZsEUBcVc6oWQOu5SP02TUjLAKbmYGVOMKbOlxcn9hnSsaVenO3C1aycL3nxT19f Lb6q31UqF71GfFWvSxG8norJpQvffg9p4UHXrxGrmedLvAsafN9AK5nC0Q38jbXna+NdiCr4diYl MRvjYvS6fWNf8RVdlX1/F9PcuyTN+6XrUe+2am2vYlj0fJGlxsf5hucrwLkb4uOhnq8y8WUhi2n6 LjWSBXxDg3c2QpiVNsuyhPVsTTZ9F1ozFnuF+eml5yvN2y2FTzNMgJpWcvUNi6+Dtq7nH956LxKl cJ8756S0Q80ZQm1JosNiZNmiW2kl1dDs6hiMDNFhSK23+pc067DVMZVEmI49cc/X3fIx7eZqdaDo BoxeS/yfbWKruBilnq8abhwDw2CBFWqoNWVoFw9wH9O7n9Yibt97vqijy8KQyokJPbMMw7mGRs+c /6zm8EwL3pzazmpodjRcfvFwK6d+p+JHeFr+eID2b2r4FbypwWE2Rlp1+xHii/bIBYKBDZe6NbNu x75jiOycOBXvynxtuedL1vqwjW5aqtznuRcOlN9CdP7JNx9Qhx2Vh0Ms4kR0/qy7z9Ky6iTvBTxg Gotu16GP8O4zvn57h18u2lD0AWwtnUvUXVga04o5votXVdmxuRjDNEeYxhAG2bbaAYIQZ+THa+85 x0Qp/gpa/xOi9y7uPRkLfyAYLlfp3NQHQ+gl3Y7bBQSZZFe42/E9YhN3z+HeUkk8C8Z3sKJ56Wk6 3EUNehDCqt3Asa5Ft3RSa6DbK+92pC5Zi7qKs3nTsxzYvabIhJXPKZqqHqys0wz0O9R1F9jG9CqM 7dIrE18WWlVrYmHOVouv6nd1//WvWOvcsS5FxJ261GNIzR56jXuE56PUP0WHhAF1Oy4QS22oioTw Qd5adkyXgjK+aRfq1pi9ct/YT3wZaFZ8f/FdWpatR7vWuCqGhTkQT0ewhwGm0VO34wC2ml7hdJDh vlR8NYFoipE9TPdibN5K8GKNypdoxfuTxmmZ1NHVZCT+Y+k9X2Tx+ODW4DzvWYWHZfF1wK71s350 NcGV8w7X1wVvxc/6ffy9TIAJMAEmcNwEeN940/GjzmclUDDxSzzDudGz5+t/CmU0GSG8MKEXs0X/ 03j41zIBJsAEmMDbJsD7xhuNTxIjihbwTQuPVyG84gWdW4bN4uuNxpKHxQSYABNgAkyACRwBgTv6 6xRjQLHhf1T3+lNTLL6OIK48RCbABJgAE2ACTOB0CLD4Op1Y8pMwASbABJgAE2ACR0CAxdcRBImH yASYABNgAkyACZwOARZfpxNLfhImwASYABNgAkzgCAiw+DqCIPEQmQATYAJMgAkwgdMhwOLrdGLJ T8IEmAATYAJMgAkcAQEWX0cQJB4iE2ACTIAJMAEmcDoEWHydTiz5SZgAE2ACTIAJMIEjIMDi6wiC xENkAkyACTABJsAETocAi6/TiSU/CRNgAkyACTABJnAEBFh8HUGQeIhMgAkwASbABJjA6RD4D/4R 02eeKbmhAAAAAElFTkSuQmCC --000000000000bcf42905aae7aa11 Content-Type: image/png; name="QrRiFA4ZFCr.png" Content-Disposition: attachment; filename="QrRiFA4ZFCr.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kcv4ljuy1 iVBORw0KGgoAAAANSUhEUgAAAfsAAABZCAYAAAA5KI2DAAAgAElEQVR4XuydCVRUR77/P91Nd0Oz qoALiwjBNUbMRDGJUScKyQs6MS7vRU2emMQtZiLGoD5RY1QclSxooqLGbWLU94zGGZd/4pJxnYhm AkZFBUGCoAiI0NDQe//P7QZERNzIvDym7jmeI9331q36VN361m+p2zKbzWZDHIKAICAICAKCgCDQ ZAnIhNg32b4VDRMEBAFBQBAQBOwEhNiLgSAICAKCgCAgCDRxAkLsm3gHi+YJAoKAICAICAJC7MUY EAQEAUFAEBAEmjgBIfZNvINF8wQBQUAQEAQEASH2YgwIAoKAICAICAJNnIAQ+ybewaJ5goAgIAgI AoKArOhmqdhnL8aBICAICAKCgCDQhAkIy74Jd65omiAgCAgCgoAgIBEQYi/GgSAgCAgCgoAg0MQJ CLFv4h0smicICAKCgCAgCAixF2NAEBAEBAFBQBBo4gSE2DfxDhbNEwQEAUFAEBAEhNiLMSAICAKC gCAgCDRxAkLsm3gHi+YJAoKAICAICAJC7MUYEAQEAUFAEBAEmjgBIfZNvINF8wQBQUAQEAQEASH2 YgwIAoKAICAICAJNnIAQ+ybewaJ5goAgIAgIAoKAEHsxBgQBQUAQEAQEgSZOQIh9E+9g0TxBQBAQ BAQBQUCIvRgDgoAgIAgIAoJAEycgxL6Jd7BoniAgCAgCgoAgIMRejAFBQBAQBAQBQaCJExBi38Q7 WDRPEBAEBAFBQBAQYi/GgCAgCAgCgoAg0MQJCLFv4h0smicICAKCgCAgCAixF2NAEBAEBAFBQBBo 4gT+18ReV1nBL7k5FObfoFR7k7LyIm7oCrFYTLi7taC5eytaeHrTqmVLAgP8cXFxbuJdIZonCAgC goAgIAj8OgT+qWJfrtPxj59/JuNyBsWlxSgVTsiMCsxmPWYqUKhA7eKMQu6M1aTCbJShsIFCZsXL 04WgdkF0e6I7bm5uvw4NUaogIAgIAoKAINAECfxTxL6srJxjJ0+ScuYMlZU69IYKlAo5Hq5uYFUi k9mwyQ2YbAZMZjCZbdhMarAqUFjBw9MZVw0gM+Hi5kpIu478LqwH7kL0m+CQFE0SBAQBQUAQaGwC v6rYa7Va/p6czA8//gRyGRqNBqUTyG1WNC5qmnk0Iy+3ECe1EwqVFaPNjEFvtAu+zOqCQuYEFjNF RVcpvXkNucpGl65PYEWB1aIirGtXwp8MQ+MirQTEIQgIAoKAICAICAL1EfjVxN5sNrP/bwc4e/Ei yBTIZDKwWZBZzMitFhQyGQqFE8jUWOUKrBgwy83IZQqQKzDpwag3YjYYuVFcQMH1K1gsZsK698TV swWgwWy18mTXx+j3dE8UCsWv08O5G3ilTzyp1aWrvAnuNYCJ02IZ1tnj17nnvUrVpvHV/HjW7Usl ywDe/uFETohjzrAQ1Pe69qG+L+TrEc8Qm+zNyO0/EN/9oQr5p16UufIPDEg4T6fYb9k7MeQB753L uiG/Z35qMBN2f8f0zg94OanMe2446/N6siD5K0b5SNcXcmLlHOLWHyFL68OYLYeY88Ac71VGGosH vExSlh9jdh9ijr3euXwd/Qdij5ShCotj745oHpTGg7YeUol7bjib89yJSDrE6shHeE6qn7/gcew5 EMsDd8WDV75pXFFykjUJaziU7cXwJQkM9msazRKteHgCv4rY6yp0bNv+P+TfLMRosuDs7IyTkxMy sxWVDDQqJ1SAyWKltMKC1ckJo0VHWUU55RVlVBr06HVG9HojripnWrVqhbNaja7CiLtHK1xcmmM2 aSivrMBg1BLarhWj/v0FNL9GEl+N2Lvj18kfD20umXllGFXBjNmwjTm9HmEie5h+M6Sxcshwlpw3 grsfnXwgNyuPMtzps+SvbBzm/zCl3uMaIfYPBvVOsTccnk7vMTsoUnnTqXsYw2av5I0HVK57l3Gn 2Od+NYqXZp+kzP05FuxZx6iHHR6FW3g1fA7JfqPZcXQWDa5TTsym98it5AHuESs4tiqCh35KmojY n5jVhwUeSeye9gCdXrKPubGniUiM5VnXhkZgNsd35uH30rMESRMrkL1hEvGFw4mf3A/fqs8ebAyL s5sagUYXe5PJROKyj0m/fAkUCtzc3VEqlcgAm9GEymrFRSFDbjGhN5gprjTj1rw5rh4abEorMoUN Z2eVw+WvVGMor0QuV3GjsJy8K6VcvVpJebkT164ZKCy6gau7DJUKIgY8zbKP3sbJqZEt/OrJxn0I G04vpq9kK309kVemHaDI71V2HJhP91/HnK53rBV+NYres09C2Pt8s2U8ndWgPTGbl6TJ1ftVthyd T69Gr48Q+wd78O8U+9x1w3huwWn8Rm7j2IKwByuu6ux7l1FH7NUbeCUqnlSjNxFL/8rqQXYXw8Md DyD2J2Y9zYjNRY77uA9g2dGVDHpYtW8iYm/ITSFT3Z3OD9QFJWSn6/Bp70eDWq87Tvy4/Ty7ei79 qk48mRjNX0KXEB/l+3D9La5qcgQaXezXrl1NeWUZLu7uKFRKkMmQyUFusaHEgosM+z+F1YjRYsMg d8GmVmPFRqW5ArPNIgX1sVpMGI2SG9+M0SBDW2ymrFTB+fOFlJYqMBrd0Li6ozfewGLVU1RQyMgR z7F44djG7aR6xB4yWRn1IkvOezN08w981EtaAexn8ayP+PpEFkV406lvNHMWjKeXTyFfjejHrGQ1 Q9f/wEd91ZCygN5DN5LX6X0O7BlPSGEyK2fFs+7webR4E9J3PHMSornTaaDl6+iniT0CEUt/YHXN DJrJuvHT+brQnzeWJTKscDY9hm5FGz6EYYYjfJ3bh40nF9OrVh3t94mMZs5sqY4OZIbM3cyb9Rm7 UrIwqP3oPuh94mcPJERdR+xDUpk3ZBTrsyAsdhtbJ3ZGTS775s9h8dfJZBnU+HWOYOKCeYySViMp d6lP3Z5qqH6Hp/PEmB3Q51WGcdLO2eDTk1ELEpnT984ZtNqN79dnCCG5+zmRC/69RhC/LLaGqzZl C3HzV3E4LQ+DRzC9hsXx0bQ++FDtxvdj4ITnKNy1g+RCD8IGxfFZwkAcxrGWtK/iiUvaT1qeAbVf GIMmz6sKpdwu9p2T+jFkvWTnVh2qAay6sJLIuu03ZLJr/hwSd0nhmWqGcYzq7EHK/Pspo5bYb1+B zyyHB8hv6Fr2JvRxWNfa3YzuOYUj6luL18PvPkn0bgN9lv7ExkFH+GPHt9nt8RxDexWxb5+BUR8N YN+7q8mqqW8npu3/K/VHR5KJ6/kam7XPMTTyPNt3G4hYeqhmrKbN70fU+jzCRo7DJ2UHh89r8Qgb yJxlixlkB2sg7asY3l96hEyDD70iO5G7/QBZtd34DTwvNeGbga/ikbKDlM6L+XnVQAr3LeD9JTtI ySoD7070HRNH/MRwHCOngbFbzctnAGP6atm3K5VC/Ok1YTGfTQy73WORmcTAkWnEHlmG9Jhj/zuT WUcSYL5k2a9n9zQpiKLlRNJkZiedIBcfOg+cxdIFkVXjqtagkCz7Sad56atYekofl6Ty1fI17E8r AZ8wRsZMJpK9xMVvI7vUBJq2vDQzgS6HJ5F4qJAKNHiGjiR+biR1JV+XvpMVK3aSWmhCE/QM0W+P 5Vk/FWR/RUx8Gj5+BaQV9uSD5WMJytvHioTNnCqUbtsDn+wMgmITGRXUuFOtKO3XJdCoYr9n926+ +WY7Yb8LQ28y4+XTzB6rl6xts16HRinDBQsauRUnmwmzBcplagwyJRWVRlzd3DDLbJSWl6FykqHX 6zFWGvklOx8fryAuXixEpfaj4LqBX7JLULu4glMFZeXFYFPgolERO+XfGDWif+NRq1fswTFBlhE2 629884a2KlbqTqeICDprk9mVnAd9FnFsw1AM1VbdmG0cmx1G9YQUPOFbDk4zsDJKmpSlOSiMELJI OV+Eus8iDm4YWjUZVTcnjXnPvcz6vNox2XqaWiWuDttKhXvwEFbvGcq+qOGsz1I57mM4T3JWrTiu IZm4Aa+xOU+FX1gYHrmpnC8y4jdmGwdn+7GrOma/eRu91g/n3f1FeEd8yjerJPEzcGLWC4zYnIfK rxvd/ctIS86izDuKVQcSicx0iP1t9TkwH2mNVHMYUpnXUP2qxF4KV0iMQ7TJ7EvOw+j9KjtOzr/D rVzNGNzxC+tU0x73gSs4tiwCj9ztjI6awZEybzqFB6POTSU1DzrF/pW9E9VVMXvJMvUjrLMHuSnn KTKq6LPkEBuH+aDdNZHekw9g8OvJoF4epO07wPkyP8Zsl2Lxt4t9ZNoGFietYntyEe5hUQzrNYBR 0wbWiZ1rORz7AtHbixwMfcpIS82yu98TDqyj732VUS323vTp48OJI+cx+r3Klj3zby0c71fsjY6e Ubl3I+aLd1H/ZRUrN5+kyL0TA4eNYNTkEfUsRsFQ5cLXSuN3zEleGbMDbcSnnFo10C6M1WKPKpg+ kWGo0/azP6sMqV9OLYuAE7Ppbw8BeBMc7gdpp5H0mRqxT2vwedFW5WpUVR7vyMUcm5zFKxEfcd67 J0MHBaM9vIP9WRA+/zu2jvJpeOxStTgygnfYAPr6F3J492mKqG/Bk0nSwJFkzjpCQi81ueuHMjTt XY4k9CXF7sZ3iL1h37v0SfBg6fYF9DLs5t2B81EvOUKCfYVwN7EvYN/cOPb7TSJubGd0+xKYu78L cxMG4/eglr3uJAkxG9GM/YCxPV25ujOBuYdCmZs4iiBJ7OP+Tuhk6TtfVOSxMzaO42EzmTsqCN3J NXy4NINn4h9c7Esrbcz9SxnfntWj1dv496dcmPuyO56S9SeOX51Ao4l9aWkpY17/TzybNaNHeE9w UmCxWHD3dKPkZhFBAS0xlBfjqbJx8dxPZF84g5tXMzo91RvUnmi1Rpp5+1F0owRXd08UTjKMRj2/ ZF3mclYeMquGX7Jv4uruj0LhRaVBhlrjQmjHQHS6MlJTLtphGfQlHPzuT/h4ezUOvLuIfbWr0p4A 9oaBr9ftoVAdzqA3+uCv3c24nlPYTxSrLiQSWV1GWBxHd0RxYkQ/YpP97clfMYWOWK42PI5vEgbg QRYro99kc1Y3Fhz5uk6MtcpqKrpH4li12PsNYcOOxUiGr3bfRHpPOIAhfB7HtozAp5Z3Qkq6m547 kR6TD0D1xFy4ndHPzeCIjxSjHU9mldiH9/Ej5chpCB7Nxh2zHBN+dXs9BpCwJY5eagMpS17j3d1a hwfCP8Eh9rXqU7dz7lW/eK3Dsi8Ln8dJe/2Teb/na2wvqp0Ed6vUGst+5CYOLghHXbidV5+bQTID WHZ6JSFLXyAqKYtOEzaxeqQfFO7hj0M/ItUuKiM4YU/Q82bk5kPE91LXLNC8R27i1IJwcg9vYFey Af+B0QzqrCZtSVV59oTAsjsS9Gpc8GP+wrHZ9cRtJTf5c3NIVg9g1dGVRHrcWkBVJxneswyqxb4W Xe8BrDoglVf12X2LfSfGbN/EnO5VF96XG1+qcz9GbNYSPv8QW4el8seeb7PbMIBlJx2u/Gqxr0mc TEug/8DVZAW/z4ED0eS++7R9EX3n944EvZCq3Ie7PS+9djkSM90jFrF31VC7tWzYNZEnJh/AY+AK Di6LQJ22ncTt5yFsBNP7nnc8q3cbu32PODwhDGDV6ZVEqg3sGv8k7+6HiKSfWB15u0BnJg1kTO58 jizwZ/PIoaSM328XcUfMvsqyl/J+DD6E+EjXGtg9JozNA4+weWgdD1Vty75kD3GTUolYHedw1RtP kjBuL90S5xKpfDA3vu54ApP2diMxPhLHLHmONWNXoIxdTrTqK2ISKhi7fCxdpK8K9hA3LZWXlsdV 5Q2cY/nYNXjFPbjYj1lfwr5zhtse/eFPOZP4qmfjzNWilAYJNJrY79j2NevWrsXd0yH2Pt4t0VWW 20Vb4yJtoSvnet4lMNzk5x+P0srbHT9/f3JvlhPWsz+6chU2mQdGkxqjEYpLbuLv15rz589isdio KDNSUFiCVaamUm/iRmk5zhopk9+AxtWDnMtaWjRvg8bZhRdf6MTMaa81Ttffl2XvT+GJDcxbssHu Ei6rsoqocddWuf0zJSttBIejJDepI9HJZ90feG7B+XrqWm0l1v7qAS378EWc3OLwDtwuRo587GrX cPj8vzMn7zWH+NWbvV7txq+ui4rwJdJkXjU5VYcl6mmF3fPRfZVD7GvVp+6p96rfVv+P7GJv6LOI UxuG4lGT8d6N2Ue+5o06iWd3ZuNnsnjAiyRlSRbZJnzm/84eDrnjcI9iw+n3yayTja/9+g26TTuK +9C1/JzQR4p5sGtJPIm7kskqqu5wcHhrHkLsT0ynx8gddkant0jtAw7H8MSYPRgiVvDzqggKazxE d1kw3Cb23vh5a8mTvDPVCx6pzPsV++qFajWg+xF7yTv03GtsLqruEy27xj9tF8Y+S39g4yCPGrF3 eMT84baYfK1FVvWujzoxe497PC+jTtSzC6NwN+OiprC/SHLUdKN7rwiGjRnBIGk3zb3G7rDUe4Q9 6ljjkut+QiFLNncmYegJovcn2F36t4m9IZPdSxJYfySNQgMYCgsJmX2EzSMbEPvsDUyatpcSpbLW kG3jyLT3ejCxL9gTx7SMl9kQYw8OSIrOnthpZAzfQIxvHbG3u/UrGLumSvx5eLH3e//6HY+bh7OM 8wtEXkHjiFXDpTSK2GtLtSxNTOSHYz/g4uJK+46daNu2HWq1Elc3Z67nZ3Mx7RStfJxp5mqj8Go6 fi3dUDqruZRXQPsuT1OmdSU7uwxPjxCuXy/Dgo0OHUK5eP4sxcVFqNUuOLtqOJ9xHoVKgZuXOze1 N1GonbDZXCi4ZsKkd6alT2uKb17j5PEkPNwbYf/9XWL2DuHwdsThO+9m3IAp7Dd0YmRCHMP8z7N4 RLzdiqyOzWYueYEBSYVEjIwgZfMO1FWJWtWi5N7nfT4aGVyrtzwI6RVOyG2JTdWiqyJi6U+sHlQ9 0WTydexH7NL6MWrBLCJzq9zmv4rYq1BhxChZ6XsW01eqX8pseg/dSp5fFAtmR90WevDo3IdehQt+ A2JfbfVWif2s3xGbrCJszGImhteasKVchb4e7LqH2FcvTrwj4vhoQhja7dN5d3PWo4t9n0Wcti9m wLAvhh4TJLH/1BF3vm+xV9Fpwja2RuzglaEbyULyBP2V6fZszvuM2T+E2Fe78KtS826beVRVi7Tc 6ph9g2Jfa6FbR+zVVW76uz0vfHWXLZfaNHZ9tZFd+5M5nJqHkaqkRf9lDY9dj/0PJvaksWTgNAx9 /NlfOIL9CX3t22Fri71k/Y9MHcP2pUPxVxvYPSGMzX3uIfZ2CzuDl1fH0LNudv0DuvF1x+OZtLfH 7Zb9pBUoJ9dj2UsehZjGsezrE3t3ZxkXhNj/M7SeRhH7I8eOcuLY3zn8/VFcNR60aOZNixY++Pp6 g8xMXm46Xp4gt96khZeNVt4q1Eo9RlMFWrOVawVGTPqWFBWpkMtbYzS64OnRHCelgpLSAqxW6cU6 hciVNnKuZVNh0GJ1MqByUWMwSdvyvSi8KkOOBwGtg7l67QoJSybyh4HVK9dHYHmH2BvI/Hoir047 as/G3yLFniW3+UjJcq1yMWu3M7rnDIfrrzoRq8pdmatSYTR6MHLzD8T3ujWhl9WKrUqJcrsK+zCs nm19uV8No//s0xAex94N0YRUZeO/MnIrWZJVejKRvml3in2Nm7wqj+A2N/7mH5he6HDjqyM+5ZgU X9Xu5/0h8ZzwGcHqLUNIs7vxpe19mxh15E3G7y66ZTFWu/zpxIQd26pEJZWvD6sYNKgz6uqwQgOW /b3qF29wuPEf1LKXst8PLgizu/HtYYkqN77/EkfCm5R3sHfVQPsCJXffdjK7D6Wvz5377G+37Dvx 1YhnmCW9d6CqH1Pmv8CQ9Y8g9jVu/ChWHU20u/EdZebVeFvu341fndNRKw+geo+9YTfjukkhpmrX +q2kz9sS9O4q9q+y4+idORKSO/pEbD9GbC+yW88hNUZqGZlS7oHqORJOrqPz0qoEvXrF/l0KY58m ensDbvyqBdDdnpf63q+QuWs2ifuN9JrgSBgt3DWR/lK+heQxWaBlnH1c3GXs3nNxdOfWl7QlEQxd L4WwjrCsys1fW+xT5vdhTNYEti8diEfmdqZNWIJh8j3Enjz2xM3l751jmDmqC8qCVPbuLaFHdD/8 jMdJGLOTNvFzGRXkSMevm41vzEslzRRKmPS9PWa/Gc3YuUzqqSR7TwLx+0OJq47Z13bj2+8bx6HO M5k7PIiSUytYuCL7oWL2wo3/CDrUCJc2ithv/fq/yb70Cz8cS8ZT44W7xgObVYZ3i2YEtm1NRkYK rVqqKbieRrtAV5ROWgJau6LTl9j32F+5VoG2pDlmQ2sMBh9cnH2RoUbtouLC+TM09/GioCCfCkM5 Wn0JFipx8VQQ2rmjfd+9VuvEt7v/gdrJB43Kg4LCXGbPeZPo16WNco941Oyz9yY4zA8PbR5pWUX2 ffYjV20jXjJtc7fwyoA59i1OYRHhqDP3k5xlRHLjS/FhhwFenbQFeA9hw9HFjoxdqhOOjKi8O9E9 BDKlZDD/0ew5MOvOl4gYUlkcNYqkLOn8YEI8DDX77MNnbWPrGyE12e+3uc3rJsBxnuTz9SXoORLa fAqlhLV6EvQk96r/dkYPkJLbqi1GyXJxJOih8iOsux+GzFTOazsx+8DXvFG1O6AhNz73ql9Vgt6D ir2UoBcc7kjQk9pTs+87dwuvRs0huQzcg3vS2SOPlNQ8PIau5VhCMF81aNmH1wibKvg5IkOKOLH/ vD0BMXjCXzg4zfjgMXvqJOhVJzlWJehJEZMHF3vpXT7VfSUt1L5j4zBt1U4Sqd3d6KzOsyeEGlHd no1fV+wN+xnX7W32G6UEzggmJiQyqvbbeQzJvP+clENRN59E2o0iLYwcyY3Tzw93ZOPXK/axhNRK 0OsU7ofhrgl69T8v1ZZ/7XCU4cR0+o/cQaHfcwwbFIzhxB62pxZVLaL8Gx67HvfyhNSzzzVtCRFj cu1Z+dUh/dvc+IX7mDVhNttTtXiED2WgdyrnOy9h84Q6uRx1s/ELTrJhxUYOZZRg0gTxTPTbjH3W DxUlnFw+lxV/N/HsB8sZ2/5OsU/fMImlprdZPtYeiUfKxk9csZO0qmz8UW+PpV91Nv5tYg/GvEOs SNhQlY3fBddzeXSe++AxeylBL2ZrKT9kGinT25Di9R++7CES9B5Rou738kcW++KbxWzethV9mYEf T/wDm1GOb/OWWM0y1Co5nbuEkpNzhhbNZFRWXsHVtYyjh/bxeBcPwnuFYZSZqTS6cCXHidxsGUqn diiVPtisSoKC25F9OYPrhfnI5U5U6HVczr1Mx8dD+V14V5ycXVCofTifdp3t/3OYlt4hWIwW5E6V vDkuiuGv9KR5s4fd4FuF8C5v0HtjciyjqpOX7FbhbN6fv4eUQjUhkVGEpG1ktz0+fGuLUsqsfgzZ nGeP+55K6HPrbXeFyaybn2DfepdXprZPpjEL5jFMcrvWdxSmsm7JAtbtk84H72DpDXrvM31YZ0es 926W9F23Bzpu4th69xG7UvIa3nrXHTLXDeOlBaeh0/vslbYPksvhJfEs/voI56XYaHA4w6bNY3qk /31Z9vYKNFS/hxL7TMJHRuNxYguHc8Gn1wg+Soit2WqoTdvCvPmr2JcivZTIm06R44lfEE13j3tZ 9n1Am8q62DmsPJyJwSecYX0NfLX5JGp7VrkPi+u8Qe/eQm3vAPvWu8W7UmvGwcTZcTXj7N5l1PcG PezJhS8lnMdYtTuib+4G/vjuMg5nGfAJG0Kkz1HW7y9sWOyrtsT9cckRculEzJavmVhLm2pe+FPP S3eq6y258teFfMZrDYh95+qtd0uOcB4f+owaAOs2csS/1hv0Gnhe6n9zouSNW0Dc0j2kOB4Yetm3 lUZUbXdrYOw+hGV/v5Pv/8nz7ImB2wiVcgVEqP3/VBc+stj/I/UnTv34D2RmBT8cP8m1X67RLiAI lZMSrGa6dO5AyY0cvJvBuTPf81hbFzxc9ZSX5NHj6a5UOpnJLzJgNQdx9owWjfNj6A0uyJ3UmLFR oi21W/h5+VcpLrlB9ye70uHxDhjNBpxdm1Omc+Vvf0vh1ImLBAeHYqiooLW/G336deTZXu15qrtj JSsOQUAQEAR+TQIJCQkkJSU99C1efvllPvnkk4e+/te5UMfJ5Qmc7vE2o3u6kr1zIQsPhTIzMZr2 v84NRam/EoFHFvtvvztA1qXLKHDh/NnzZF3KwMvNDQ93VzQqJVaDCY3CQjONkcyzR1FZrxPaxgMX hYUnenThH3lp6BUedAh+kRPHc2ju25mKSieKtDqcpF/FU6nQGsspLL6C0sXCwEERlJXpsBgVOLv4 8/3hS/wjJcP+Ot7mLdy5eDGFvn2epG+/J/H382RgZL9fCZ0oVhAQBASBpk9Al76HNWt2cupqBZo2 PRg+6W0iq9/L2/Sb32Ra+Mhiv+Obv1JUcNMu9tmZWaSnncVJYaO5hxtOVhkqmZqWXu6U5WfgzA0U xjxaesqw6cowqyzc0OjxbtsJL83jXL8mp6RYjlnmhlztilXpjNZoxqS0kJlzHoNVx9BhL6Nx8aT0 hoXMS8UcOHwOC0pcnG3IZJXcuJlD/+d70a1bKC2auTFi6KAm01miIYKAICAICAKCwMMQeGSxX71h HYZKM85yDTcLizh/JhWbUU9rb1+sejNqmStqmY3mnnCz6CIySy7Fhek0d3fhhcERZJblcTn/JvoS T7y9OmLSaZDJvDAYZZTrbeisVswKBdnXc/H0aUGv3n3tW/OyMopI/fkiGldXAtv6ceVKBk5KEzeL c4mK+j1qFzmBfi156z9HPAwXcY0gIAgIAoKAINBkCDyy2K/882pkNieczArKS7Wc+/EU5TeLadvK D4vOipPMlWbu7nh5yblZms6Jkztp4YP9fYWqZf8AACAASURBVPbP9u/JqUs/c/qsns7BgbT17YoL rXFR+lJRbsMmc8Ygc+JmpYHMvFw8fPxw8WzNmQs5GPRqjCY9zqpK3NzkKJ3MOCktBAe3xlWjwElh wdXVmdkzYptMZ4mGCAKCgCAgCAgCD0PgkcX+0/WfY9GbkBllmCv0XD5/loriYoJaBqKwOtPMzZ+r V6/i3doFi7yA0xnfcTL1Cv0iPPF7rDVWlYLrBSUEtuiATauhLN+JNl6hyMxuVFTKqLRZ0JllpOfm o5c5U6gFrV6OVws/lEozpoosZNykVcvmtGntTVDbVpTrboLNjEbjzOz/mvEwXMQ1goAgIAgIAoJA kyHwyGK/aMVHFBYUoLIpUdlslOTnYdLqaOnVEk8XH4quVuDq7kGZ8Toyl1K8AvQYFAWUVF7DJDfQ JrAtZiNczSjEWxWA7qqStj5P4ObUmpuleirMRm5WGMkvrcCq8uJyQQVWJw02hRKTuYTWLQw0c7fh rJLToeNjFBZcpUUzD8rLtQQEBDBhfCP/Cl6T6XrREEFAEBAEBIF/FQKPLParN60l41IGzgo1cosZ fUkh2qJibHob3h5tUNmaYUWOxsPKmcxjPP9KZy5dPUlxZS5+7aRX2+rwcvOh5JoWP/fHMBS54VTZ ApXNF5nMBaVGRUZODmUWGWovH85m5GFTu2CwSO578FBX4tvCFb82vjjJwWazYjYZ7Nn5rVq15M03 3/hX6UvRTkFAEBAEBAFBoF4Cjyz2/7NjGymnf0bj7ApmAyZ9KcX5+RReLaJlcz+8XPztv36ncjZz Q3eRoG7OXCs9i4evgpMpZ+jW9XFclJ4oTDKupN+ghbI9rvK2yI3NUDl7ckNbxJWCAtSezXF29+ZE Spr9vfgWWQWtW3kR5NcCN1c1SoWckpJinBSOn0tUOanp2KkjQ4cNEV0vCAgCgoAgIAj8SxN4ZLE/ cvgox4+fwGAyARZUKitX834hLzsXtdyF9gHdaOXtQ3HpZfKLzhDYUYmzVwWVlgI0Hi7YLM7YTHKU ciVXL9/A170zly+WY6jQ0NovhOKyGxxNTiakfVeMFjmVehs+rbxp2dqDFt4eWE1mwIrNasVms4DV BsiR2+T8vn8/nnnumd9IB5tI/vw9/vb4Amb0+w3/pGPON/zX8kpGLx5Jx38CudL9S3j/4vOseOcp av+e1z/h1uIWgoAgIAj8yxB4ZLEvKixi3ao/ozdbsMnNKNRWCgrzuJx+CV2Jjj5PDaAw7wrtgry4 WXYJt+YlhPUI4Jf8C/Y348mtGimXDnc3DaeSz3Lmp1wC/bvj4d6Wto915fS5M/wj9QwBQR1o5tUK L8+W+LRogYwKKiq1qF09kOS9Wuxl0h9VYj9+0ji8fbwfsTMryDx+lNLgF3iy9aMUJcS+PnpC7B9l TIlrBQFBQBC4PwKPLPbSbb74fC35RaXYFDZwsaKruEnmhYtkpWfgbHXhyqULvPbvL9KhUzPOpR+g Y5dWdHw8iLy8PDRqT/LyrqJSKfkp5Wf8/DqjLbdisXpQWmFFoXKnvNJGm9ahuKi9UcldUcmUKGVW TBYDlTYzVplVCtZjs9mQ2ax2sW/ewpu3J42/PwoNnnWDfQvjyfy3xUzs/ii2pxB7IfaNMBxFEYKA ICAIPASBRhH7A3v3c/LHc5jlgLMFhZOFKzmXOf9TCtez89AobAwf3JfkE3to5S/HJisj8DF/Ksp1 lN8sJ8DPn9KyEgKDQ8i7XkxW9jVUrj74t+3KDa0JjVsbXFQ+KGVu9u18NukH5eQyzFYTVqUMiyT2 WHFE661I1n2vp5/h+f6/fwgkt1+ycfp7HLtRCU4ehAydwoyIVlRkfscX67/jTJEJTeBTjBwzkvDW 9SwETFns+3wtOy9qUbbuRginqegrufE1JH/6HjvphueNy1wrNePZPYqogDT2Hb5CUSm07jead4e2 RyNVpyKLfev+zJ6zN6jQtOLJoW/y1rOtUJLOF+9tpChAw7WLEPlBHFHeV/jbuj+zMyWfCqV07n/y Vr+ABl3kRSmbWfnlD+SYPAjp0IKirFa89YnDjV96dpv9u8xS8Ax5mtHjhtPVE+wW+d9d6FiRTmbw m6wYH9YglwbLqXLjmy5uY9Gqy/SOmUJkoJKKzIN8sX4PZ4rAs8MLTBz/AiEax6JpZ2V7yEnHc+hi O09xCAKCgCAgCNydQKOIfUnxTVYl/ZlKswWryoybu5qykutknDvDxZ9+JsTfF7nlBuG9QmkToEFv LSO/qAi1UoWbUoVK4cT1wgJc3dw4fymdEl0lbR/rRqlORmGxjKDg7rg4+6B0cgMTmPVWe4xfoVBg lpkcYi+zoZAc+jIrTnIZ77zzLm5Suv4jH3Us+4pUls3ahub19xjd3YVrez9n0d9DmbHgFQLr3Ctz axwfX3meGZP64116hC8StlHxh1tiv1kzmnnjn8Kz9EeWzVpL5uPjmTc+DM+igyz68B+EL5jG7z0h 88s4Vla8wuzxT6G8uJn5n94g6pM/0lsjif1n5PT8I1OHtsdTCTlb5/LxteeZ8U4fvK8dZFniCQJj 4hhet3LVdS39gY9nfYf3+CmM7ACZ2z/n45PtmCqJfemPfPzhbrzfmMLoDnBm66d8UTqYP70ThkkS +//nwejY/6R3aw00xOVe5Vx8nqVDK1iZ8B2eb0zjrcc97eWtnLUNXn2Pt7o78dO6hWzzHM9HrwbY xX5j5UBmTHqeQM3dvS2rV68mKyur3hEQHBzMuHHjHnl0iAIEAUFAEPi/QKBRxF5q6PcHD3Po+ElM MqNd7DHpKLyag6m4mCMH/x+Do55B42bGx9+VckM514u1BAYEUJybg5ebO9rScrvge7TwpFPXJ7h8 pYiDh1Lxb9eT4Md64KT2AJsT+opyrGYbTjIFGhc3yisrkMlsyCSvAmYUMhvPPP00A/pHNhL/28W+ 4uRnvH+gM3+a2R97mp0pnY3TN6KcFM/I2r/vzRW2zfqc0lcX8NbjkiDVduM7LPu/da9O1rvBvg/j yfxDdaggi83T/wzj5trLrCjKx6RphafdgD3HF3/cSeuZcUS1lsR+G61jpf9L311h86wkTK/H28VZ Oq6lHORaq/53zTcwnfyMybXbUytBL1Bq6+Fu/Cm2j6OtpVkcO2um67PtwZ5YF8mad8Ls92mIy+Ab 9yjnVEvCK9Io6uvwnNSU9//aM++DF7BnXVzczPtfuvDugoFcu89ER51Ox/Tp0+8QfEnoFy9ejKur ayONEVGMICAICAK/bQKNJvZ6vZ6Pl66i3FiOWiVDhR5zRQnZZ87i7aUmKNCDC5k/gbMJd29PdGYn XFRqQtv4UlJQRIXOzM8/n+H9ae8jd1JyMuU8m7Z8ywtRb6FQ+VCq02OVmZArTLi5u6At0WK1yHFR uiGTKZDLrMhkFpydnXjv3ak4Ozs3Evnbxb5o/xLmZEXa3daOo65QV9/2HF+8t7OWEN9D7G/LC5DE fi2Mq1pAFKWybes+frpSigkzpTdcGDx/bj1iX/ee90YgueP/62IkK6pEm1pi731HW2+V50isuyX2 DXEZXvRpHWa3lzP5vy+jdHIh8A/TmP2SQ+yl8t7/7ysonWq1wfNppi4eTul9ir10ZV3BF0J/7zEh zhAEBIGmR6DRxF5C8/PZNLb95a8oZFaUGO3/1DYTZTevYjYWUlgixaPz6NojDN9WAfZtcqGBbThx 7ASHDhwnqG0wPZ/uiW9rP8orLOReq+RmuQYXjS9WuRNGm5FKYwlubq6Ua8txcXHHZpAhR2a37CWx Hz50KF27PN6IPXUPy54qy75amGvuXGXZv76Atzrch2V/V7Ev5VjChxzrMoWpL0mx99qCfm/LvuJa OkWa9gTeZbffA1n2phtk5kBgSAsq7mXZ1+Jyh2Vft5y/d2PeGPgi4TRPxk4jKhAqjn/G+3/vxkex fRx5CzXHgyc6Vgu+VISw6Bvx0RBFCQKCwP8ZAo0q9lKr9x/8G8f/nowcC3JJ8OUmXFTSO/S0VOoL kFGOV3MXvL29cJdi6hYFFy6kk3+9CGRKNG4e+LYJxMWlGUUlBopLzdhszthQY4/KyxXI7OlmMvte eukdOnKkTHwLzzzdi/79n29k+KX8beEskp+Zy9R+LVDWxKan8VZ3JTn7k/j4cDumNhiz74N30Q+s TNyGqVbM/jY3/l3F/gZ7PpzLT49P4d1/a0FpyjaWfZlL+My5DA+sK/Z1Yvb2e35H60nSuXfBclvM 3syFrZ+xLKV9Vcz+Bz7+8Htaj3/HHs+/sPVzVha9wJ/eecoRs69l2d+K2dfDRbpHg+U49tkX7V3C /FPdmDHzBQIrpGu+w/v1KYzu7knpxYPsyWnH8IgAfnoAy7661ZLgS4dw3Tfy4yGKEwQEgf8TBBpd 7K1WK19u2kJOzhVkmJHLzDirzCjQ2d9lr7CWolKZUUvb9GRWjHoZ2nI9CrUalbMLRqsMhcIFq1zN jRIdrq4tqoRehQxnrDYlVosMm1WBdC+5lJqPldDQxxg1cgRyuT1436hH0fEkFn15Ds0f4pj3Uisq Ln7Hyi+/40JVNv7wMSPp3UA2/rZzWjQB3eioTKP0mQ9qsvHvT+yh4uI3LFv3PRdKlQR2f5rAG+lo hk5jZIfLdWL2UmrArWx8kybAno0/Wsrcv7iRyVtbMeODF6j7uoCikxtZtvVHcio86NozgKKLHjUv 1amdRe/d4TlGv/EKHauz8WuLvRS3b4BLw+VUv1Qnnz0Ll5DcYQqzhwZguvgNK788aues9O7C8HFv 8vtA/m+8nKhRR6AoTBAQBASBRyPQ6GIvVae8XMf6DX+mTFsKNoPj52dlBmSySlRyAwqZEZOxnIqK CtQqd7vF7ubpgZNKjVZnwGS2YZUr0VUaUandpZffYpOpHAJvc8JsAovFahd7pUyGh4cbkyZNxKXR 4vSPBvW3eLUpJcmRiFedbPdbrKSokyAgCAgCgsCvQuBXEXuppmazmQMHDpKa+g9kMhMKmwknhQln lRWVkw2byYDBYMDd0xuDyYxNCrrLZRhNFpA7YVM4YTBaMEmijhPYFFViL8disWG1gtUCT/f4HS9E Rth/+EYcdyNg4qdV8RzrPoV3e/6GX9UrOlAQEAQEAUHgVyHwq4l9dW1TT6dy4MC3dnHHZkKpAJVS hsJmsQu2QumMwWjGIr35TiFHJpdjk8uwWMFgMqJUqrDYZNhsMqw26bU5MrDJ7Rn4/xbxAt27dftV wDS5Qk0VmJQa8f75JtexokGCgCAgCNybwK8u9lIVbty4wamTJzh3JtVujkt74e0/TidXYDHL7OIu WfXSYbHZsGKRftrG8bl02OSOv202FAonunbpytM9nqZF8xb3bqE4QxAQBAQBQUAQ+Bcn8E8R+2rG Wq2WU6eSSfv5NFaLBZnkrrfJkDs5IRntFovJLuiSlS/l2TmpVVRWVtq/UzopCXsijJ6/64mHu8e/ eLeJ5gsCgoAgIAgIAvdP4J8q9rWrdTUvj/T0dK5dLcBktqA3Vtpj+HIF9vi73EmORqPB38+P9o+1 p3WrR/rJufsnIs4UBAQBQUAQEASaGIH/NbFvYhxFcwQBQUAQEAQEgd8sASH2v9muERUTBAQBQUAQ EAQah4AQ+8bhKEoRBAQBQUAQEAR+swSE2P9mu0ZUTBAQBAQBQUAQaBwCQuwbh6MoRRAQBAQBQUAQ +M0SEGL/m+0aUTFBQBAQBAQBQaBxCAixbxyOohRBQBAQBAQBQeA3S0CI/W+2a0TFBAFBQBAQBASB xiEgxL5xOIpSBAFBQBAQBASB3ywBIfa/2a4RFRMEBAFBQBAQBBqHgBD7xuEoShEEBAFBQBAQBH6z BITY/2a7RlRMEBAEBAFBQBBoHAJC7BuHY+OUor/JTX0zmnk1TnGiFEFAEBAEBIF/TQI382/SrFWz msYLsb/nOChgV793OPbq5yye4HvPsx/+hIusDfsMNnzOm2GQHD2KLzsu4PMZ7e5e5IUveadfAa/n TyX84W/88FeWXGfQpBLGrO7AEFcoPZfLpDVFHCy04tvGgwnRbZnYRWkvX59XxLw119iRYaRU6cRT Pdrw8Vgf2qsAYzGTxl1mS8WtqqhD/UiNb0VLrKTvy+adbSWcqQDfNu5MGBvExPaOchs8jBXs2JjD 4uMV5JgUdO3Ris/fbum45x2HgYNfZfPhfh0ZJjmBoV5MHxvIED+5/cyG2lZTVEkxb8YV0Du+I2Ps C7YyZk5KJ6mw7s1ciP+0MxP97qzF9dQrTN1wg2NXLeDpQtTgABZGueMpMcy+ztQ1+ezJNoNGTf+o ABYO9qSlgzB71mQzz95WOaGdW/DBpAD6Vy0cc05mM2ljMT+WSG1rxsK329L/voazlWPLzzDVNZjk aPc7Kqw/nkHHnS4cSfAnEDNn9mUzdZuWMxVVdRgb4LhPXi59plUy/atQou7Vb/bvpbJymLmthB8r IDCoOXMmBxLle6s/3ttwg4NXLTh7uTJibDAfhNU3JspJjLlERvQTLPe5SuSU6/xY9/4+3ny3vC09 an2evucCkftd2ZUYQFf75xWsj8/kw9NG6BbIyVFWPrxrXzTcQGks3bPuuhLem5ZF6cgw1j7raPPt R51+0ZWxcsUvJKUaKJCer7CWzBnbih6ut19Vml1I4s4bHDynJ6fCCkoFgX6u9I9oyYR+7lVj6b46 qBFOkp6PLPRvd+UT1zz6zDXwwYbH6N8IJf8rFlFbM25uncc7W3uzeufzVA8BIfb3HBX/LLH/iWVB SbjuXG0X+5upyeQ5P87jHes8rbXr21hir7/JxZ27+S6/J+/GdLgnkVviVkvsTYUMi7kKw4NZG+FK aWoOb63QM2JJR8b4VpAYe4G97YP5YrQXviUlLE7IYm+XUIeAZP9CeLyJOfEBPFUtxEolLV3lkH2F PvEVjIkLYUwQpO/J5A87lXyxJpjeDdbUyrE153grrxlfxvrTw1RGYkIGOzq358gotzuuvL7vIuF/ UbL8gyCifC2c+iqD4afc2ZcYQPuShtrmKKo0/TrvLc3jm0INH6+uFnsr+hITpTV3M7F3eSZJrgH8 Nab5nRNrwXWGTSug5dgQPn7WGUP6Vd5ceIOWb3dheVglM6dkkh7xGGsHu6EuKGLqh7noRz7O2med yNl3gcjDrnwZ60cPjZEdKy4y0+RHcqw3nnn5DIor5qnYEKaHwvGNGUzK9mZffCsC79nb9y/2nicv 0WeFkSExIUzvLOfMtkxeT3VlW0IAXR9Q7EulstbYmB7XjpFtLBzcmM6b2T4ckepcwymUj59VUXAo i0EbbCxcHkrUHY9LLbEPg9ISE/rqNuvKmLcwj9LhHdjUz/kWiexcBsVd50cfX3v/28W+IJ9BU4p5 KT6Ukd4VLJ5++a590SDS+6q7iYOJabz2dzMvTe5+H2Lvwp7Es/b+3va2D+2lhUliOom+7Tg9Vlom SoeZMzsv8dp+iHq5FdE9PWjvJS0iTKSfK2HLtnx20IxNM/3pWu9i+J4D5SFOMJOeWo4h1IuuhVf+ 98Re/xPbYy7jO+F5ngu7ZQk/RIP+Vy+prRkFSdN559sXWC/E/kH65Haxl1ZPO5xfxOtCMpezdZha Pc5/bPgjL3as5wkpOcv2CWv57lAeJSXgGtadIUlTGRSm4uaGWbyz1ZfwkmSO5QfTt1Muh78tgZY+ hCd9Tu+dY25Z9vpcjs5I4sut6ZToXfEb/B+8m/Qi7bJvt+x1J3aRFLOD5FQdyqD2PLfoXSYMvrv5 Zsy/yLHEHezakEJJx3AGzn2Dof2aQUExH665ypY0I3qlit6DA1g+2BNPTJzamc3UnWXkoKL/s85k HLIQs7oD/U9dpNseV/Yl+NO+anLZEf8zSV06si/CSOKKMrq+HUD/qsn4+r4LhB9uRnJ8S5D+v1dG fy8TZwtt+Hb2ZWF0S7pK5568RNAKCx/MrRL7fZkM/4szX1RZYqXp+cxcc509dgtPw5DRQSzs6Wz3 Frw57ipd4x8npsqC1heUc8bkTA8/p3oGgJlSnRxPaYFhNHBsWyZvZbRg39yWeB5qoG2DNZCaRbfl RqKGu3BmYyVDlleL/e23uX4og77blHzxaRC965tQ0/N587ATH4z1rhJhK3sSUlncpiNHRmnQ68zg 6oQkS6V5hby3MN++EFjYRc6pNacZnt2cbTMD6KHUs0cSe9qSHONFzs6zRGa04rQk/FKVdEW8NqmA Z+Pr9y5IXpiZK/LYkW3BM6g5/ZUlHA8KcSzMjOVsXpHD4lN6DJJF3dlCUrYHyQltyEj8mfdcQzg9 ttoDUMp7Y7Nxju3GQlfJstfyVISc44cqKHV1pv9LgSyMcnPU6bbDxOa5Z9jxTBe+jlQ7vtHpOVMo IzRIbW/PHzLakBzbvOpaE+npBjyD3GipguupvzBpzU1+LJHRvocnARklOI99guVhtS1kMweXn+O9 igCO1JQjeZnKSYzLJqe9kr3nNGyTxL7gOq/F5XGwFNSeSoZM6sLCUOtd+4KSUlauySPpnJ4Ck8Mb FTO2HWPaO5F+j7pLTb1+PIPh+5U8pSumdPAty77hfjFTihOe0rjSlbMyIZNvQkPYV7Wwlcr8w04V n88NoOW5K7y38SY/6hT0HtyK0ON55AzuyJi0S/Yxs2+su32MSV6mSWtu8GMJBIa14KmSQgpeeoJN QflELqzkqTArP57Tc12n4Knh/gy5ep2lp/TkGBW8FB3KJ89KfWcl/XiVh6bQikGp5Kln/fhirLTY vU/Lvh4P3cdjHfPD9XO5zKzx8Gh4aXggC/tpcLaX/QulPTTkpOrI0VlpGebHnC5aFu/UkVNiJbBf WzZFe+FJAckz1rK1eh6MGcLzg9tRn+zrts5j3CI/FqS+icPnquPoq+PY0Wsxn8Y042JSEusWJXM5 X5rvwxmSOIFBvVzhDsPsMl+GzaJg0VdMfbH24M9le6/pnItZzZxXXaHkKPOCPsOYuIoF0c1An8zH QVsJOvEmhS+uRfdiMy5uuIhqwhxez5/n0Ix+3/POi7vJ02vw6jWEOYeG4ntiF8Kyv6fu1xX7f2fR id7MOPQu4a10nI2ZwrzsV29bQTmKNJIcPZ4k/Rss3vAcvs43SZ4wnY+zh7Dq2xdhwyzemFDCCztn 8B8dXVEFXWZtLcu+tkvm4ox3mHeoO1N3vs6TXnlsHzyL7zrOYfWEk7fc+PnfMy/sS5g7h6kT/DAe +m8WvZrM499+zuthtzfSeOEo/z13B98f0uE3+AUGxbxIeI0HQc/KuDS2tAli09jm+JYUMikuD+ex j7PQdJnwzTBnZjtG+hjZvDSDd04588X6Djx7XBJvL5LtrnfpcAjVVGUwF2LqJiEY2Dz3PEvtAuLK wcSfeTOvGcsntaSrZJWsyWGLxp/Dcd60NJaR+GEm8zIsjkYo1Uz+oCMftHeCkkJek7wJI0NYHqlB fy6PtxJKeWpuZz4gjz7xBsZEKzm4U3Iry+j6jD8LR3k1aM2WHs8gfIWWAlyY80F7Yto74ViYNNA2 nYHrSjUtJe/GuBtE1Sf2uhImxfwCY7uwvGd9i416BqKumEkxV2CSZNlXX1PGhzEZJF214dsjkF2x Po725OUzbG4e31e5EdQ+zdi0JJj+rlYOJqbyoU9tj0Y5H066RMHoJ1jes66L2GEJ7w1rx5eSuJ+7 wusLiyiNaE9ytAvHlp/jrcKWbIv1JVRXwsyFl9mibGkX+zP2hUnt+0hin0nBqCfYFJpPnynXoW87 No31wjP7Kq8tvEFobFc+6VK3DtJ1OTiP8oVDhRzMs+HbpRnTo/3p7WVmj7SIDArkpcIitmQYwMed CdGBjAxycljg0woJfbs9C3sqyNiTyfCNOvrPDLtN7PXpv9B3oZ7JiR0YWTM8rZzakMZU2rKr83XC N6sdYi/xLcgnckoZk9eHElWzUKuvL8wcTDzLeyZ/dk32JlBl4ODydN4s9CV5bgt+bKju0n2kMR1X zEsfBFCacIEfa8S+oX6pXlxZObj8DG8eNmNo04JNc4McYRxjGTOnXSEgtjNjSrLpm6gnOjaEiUEm NiekMzVNxRwprORazJvTihny6WNElTi8TIFvh7Kwp5Od42sby+k6uZtD7KcUoB7dkW1RGgzSM7NU x+NvdWRTpLPj780qvpQW5Hm5RMZpeWmm41nSZ+czPO46XT/oxsL29yP2Vs5sOMfwcx58ERdAb2UF KxMuscEvhOSXdfa+9o0O4ZN+zlXPfzGhMV34RPKETUpnR5tA9sX52L1Bg6bkktOjLftivGkpeVim 3KD/ktoL3ptc3Lqb3Unf81O2L09OGMLrMeH41nL6SOL7p45f4vutwwNrF+OOu+l+YjG9U//EOzEm Xt06lUG94GLSxyyaC6+nzuH5kroh17uJPVyW5vv8N1i14Uk4tIzxLx7DOHgq67eGozq0jDEzmjH/ RHd2B80mOWw8c5KexBVfLs+4Ffq9zbKv0gYh9g8s9qNY6zWH1YkOd7dx5594bVF7PjkxFP86ZRnz C9A5+9LMy4guO4+LSctYdKi3/VzXDbMYn9S91nW3u/Fvib2RtR3nUZK4nqkvVs0y+blc1jejnX5H jdi3v6M8Iz9FjyGpVl2rq3d50Tu8N9dI76SpvBHd4fYVbEEukVN0RK/uwMgqK7w0r5zrXirOJp51 WOqSNWsXmFwip+mYIMXsS6T/3+TxydIkq8aQnstrC69zpks7smOb1yJj4tiai7x1zp0v4tvS234P K3rkdmuiutw+08oZI4mmspSVG27iGeHHyCA4tTeLt/Yo+CTxMR4/foGw/W4crvEmSML2MzNdQ0h+ 5gbdFhbjLHkJRnkTYCxl6dI8zjxTvxv/9q4zc0aa3LbJ+SAxlCG6+2yb7u5in7MzjT6nmjvc0Pcc c5LBUEbiwky2+ATW7/IvKWHm3CyOhYVyJNrdHs+fucfGkFG+9glx84pM5hnbcDiuGcerPSzV/UYF iTEX+HF4GJvqxoPTfyF8oZE5q6tFSgphrgAACJZJREFUrYqpl7QwszAp+hc8Y7vavQnSUVrl9ZBi 9mppUbRNwcK57RjpB+mSF+aLckLffoKvQ6/fGitVfS7lAkwiiNOT6tj2kldmTDYHfdz5YKwf/b2M 7NnwC4srWnIkvhkH555lZrYLI6IDiOksI2N/LpP2K/g4MZSuxyXOLUie27Jq0SkJSialt1n2JjbH n2OpJBi18hD057KJ3CDj4/i29Ei7RMcN9xL7qo6s2xclekqVzrR0tVJaoOfM3my7WB1O8OF4A3WP 8tKzeW4Ge/u1Z1M/Gytj026JfYP9UieXwqhnx4oM3iv0cYRqUrPou9+DfbFubI5NY29EF3ZVeUz0 Jy/RcY2cTfawmLTQz8LwdmeGpEocfTg916fKe1I9Zqos+2nlRC/v6Fgo1Z4HpL61C7ye6fb4u5mc Ahu+vkqcdSZy8or5MCEPxoaxtqfuPmL2ZXw4KfP2hWlJBWeMKjxPpdfpazi15gyv6/xIjVEyb1IG 10dL95HGahkzx2ZSOqnaw+NYaDBZWnTUMYbyz7Jrwsds+taXNy4sZlBQ7e91JL86jrVBc1i9qAN2 Sz+pJ58feo6UwWPY0esTPp9RrQSSlf4eKRNWsaDX7jr5VXcXe04kMS5aydQLb8KMd1hX0h7jIRVv XpiAMmYcnzn/F58v0pEU9Cd0Sbd0obaBWFvsjVXaIMT+nhPvnW782xLnvv0To2b4szj19TvE3u5W n7GLn1JNuHb0o51XASklL9wS+6297Va+w110N7Ev4GOvtXgdqlpJ1q5vLdeQ74x3eC+xAGXtVagU nBw8lU3SivC2durI/fZ7dizaRXK2K49PGMSQ6N50aKUC+6RiYeGG4DqJMnr75HMwqitf96tKhDIW 8dqYGwyxJ+hZST+UxVtrSslAhm9Qc8b4lLFeGXhrMjdWsHlpJotLvFg+M6BK6OvpAHu51wiN78JL +88xVdmOI9HVcfZyPoxJJ2P4E0zPPk/kX0yo6+ZlhQVx4WUtfT+sIFqyWKoiGZLV3m2bM/vmqpg6 KZfjJuneMp5/q5a7uKY60mSQQc7IJ+yCeM+2SdfdVeyr6jy4K5uq2dkF9zzzrjpuqO7Rjsuxze0L Hn1BETMX5nK2SyBf2t2d9R+S0HbcqWFfYgsOxmaQM6orn1S7qkvyGTSp2B5SCFyTyoe3WdySZZ9O zugnGHPqHMMlS1Cqg2cLto0189pGJf+/ffMPifKO4/jL6vToom6r6cq0C7VsuyjCpdBgzigGwRZH B25M5h9tHhn1QERrQp0jM2vRLSa7NaTGKgS3cJnhCJxtFVmxXXa6yxskLSUV8s7t8n40G9/v85w+ Wpr9sf/2/euOg3ue5z7f594/nzpdYe3WKS+bY4totYfZ9FEvaw9aR8uFIsI4lUiDLOhFaKz2s+Ni hKBhOlmvzSWnu1+1oi09rN//iIpqy0gRTlja69tfxpM/wLLPB+U5QBJ7Di7AX9YlAfpkvuZoyMw8 gK06gyRXG5+aM/AoZo0gatfz3koc/nbsgVS6lDjBjHC87Hdu2HU2fjx/1+0NRCGurId0JRvFMg08 zwH2GulRZ5FGuoiWvumVjsScl4xYTTHOh17g4qEUbjgnPvddgU6KOuZxduc8UgTw6sFexFkTzeUp xUkVgAd598grrLnSIR22hvygdJ7W6u8JQdZaXtRAXez5HqwVS8mqu0lRdBG+0rjt8YjTzjbOr4uD /dCoyyGPNcT2ePlSvg+z/VQmG0RxVBC1y0P0MYMsi4GIP0TalqmC/QNKi7tJdi5n7xjQhesnblEU SBvjHPY2dpB7fS43nTOpipf/JDHVuQi692xZwf5Xxb6L0tfSTIPrHM1XoywutGFTClhleTJvizYd pkQx87HPRvdbW2ku/IJ9xTG+z9tKu3Jctd/livLLxvclATiy8aepg334V45mf0tq0w5wHOChy0Go sAZT7TZwVBJyHcOR58VtOQq14rV6tInAvk/Dhv/B/j8DezGMSu4p+9itLJaNSJHTx9W8VPZTAvun KHtPMzVXkynM/41dWht/iXsXJbVv8lVLnDyAcBYCxmSSJ3mUL+RrpenAGc7V3yPZuY8qu0EqML2y v3v5TxpNc0lp9OGyqPmxXPJPM6i18R8RDMAcM1r2/Q+nne1a7mpAlBY+qejikmUhJ0UmPXIP/c2X ZXfwvrNs1N6WZS7hGGRgdLVRlaoV+eRBRxXG4cAf5F5Rc/84IIYDYfoMiaQLS710rE0nm+MC7F3z MXZHR4paRrORu3UdMq8UKlldwkq+IwGnZvXw5NcW30MTgb0oGZY9lN0G8dSCulTV1ysJB2BKZIl5 BkHhiBwaINmuRhMj3E3kxuWDakFMm6eIF1RnYxbu4i4iig7Q5JMSAxLs1zR6ebtnAR6NTKiZ/X1y Kqw4TGGZZ6rLQHqshzecY5X9peo2dgi3RFP2STrrPXj5NivqTWobPxqjNzadFMOwmh/zgNLSHrKc VhQ0tXcsk7Vy9sNShW0Wyv4DI539WkzDNFJShzm+08clPbHUXY9VAFEoDY+ikiMQFncnt+wr2Rvw jVN7WmShU/Yylrlg5udDOpflmp/5n/2lI46PGYzB7Jmz2C+s/qjOxg9MNos5nPjQT+fGbE5uUOc3 OqeFBL+e6NyXsLzuNlX9CWgtBSKxx2BIID0/g9Z1AXInnEvCk/eQtucc1UtZXu+lfMFSvlv9YGRP qE+LqHGaOytTllZlrn9hNmedKUSEE+WZTNmPB/eng32O+K1/SKSmQkQKcYXtp/c5lL10ZvSRU1c/ 5e2JbKKbDWNcHHVP2UOCAAhlrzX9nwX2GV5q8ir5MbyY1xUbtuJVLNSLpvEYIcHYjclt407xNQp8 eygwh2h+lrLPu0fR/d3kyu/2ctRSScw9PrMXn6kRcEN2AZwYoNDnIFRcwhlzLtRHKfJtw2qcOthH NWz4F17fQ6IWvL4XAAAAAElFTkSuQmCC --000000000000bcf42905aae7aa11-- From nobody Mon Jul 20 16:20:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFA73A0979 for ; Mon, 20 Jul 2020 16:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmFbvm8mwoUP for ; Mon, 20 Jul 2020 16:20:17 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3A23A092F for ; Mon, 20 Jul 2020 16:20:17 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id p25so9416246vsg.4 for ; Mon, 20 Jul 2020 16:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=12LHBV8D9XiqYcIJtQn0TweM8lHzYd/F+suF1nYVoyA=; b=kY7h8PQULgnP6SEEkc8xqr3UOhHs85SZyHqsj0pisqO8E2TnvuD7RCGQsECMR80kvX 62InljrPZU2p7teS2WmikruVKUze3tjOjvprj611rXDNZ7XCiUyhJruGJpfj86lYlmud m9yJfDuaJY7BEaC2+Z/iXHPDxnaQn7Ieh7BtJM3WDv7j7VoP9fjLrYFF6ndD7etskbf+ ueDWP8JEcW9KzvizBNSB7Qtfrxsn5YwfTsce1tm1qnB/+ycBWRYuRowTT/Yp8YW2VsUt V8+P3slGTd7H1DWCOC8byurBSgju2e715dODaLKpJzOuQa2iDh3LXS6okA8GyrwSfuQK 1y7A== 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=12LHBV8D9XiqYcIJtQn0TweM8lHzYd/F+suF1nYVoyA=; b=UwLYZAlm/iQzT2QxJVqxISA5PzvWpobN8fUne0909McdaWxI61Mez5R8aKwF7xKKcT 0FcyHWvG79Cg3PKLPKjZBpWtQ6Qe5yNbhVQlMEZFKXGTLM26BTrBVgqTdjc5DSGROWKf VU2Sb7991snks1jCp0+gmoF399pvzrpoXuYl2JWf09sni6GOJdPVtO4IpKbgGZcYMztF lFqEWgdGDyC8z10bZp6EEO8BrHSfJ5i2ycYISfo8aoeXThd7Hix6uxINRH4BZD5r5kWV zI6x27EyX8C7bcpyvciV5QakjCcGvaA31p57KhdHAKJ2iluhkXN7HCHu6mlgoqpAUqQR iLhQ== X-Gm-Message-State: AOAM533fm3qKNyNLhtQ/eyCY3RRPYw09g6g2ircvEQM4OvGnUh8OKnbk a7DoC2PcjID33FdrtUSIyN+1GhVCluJEpRJZkFTR X-Google-Smtp-Source: ABdhPJxGfAbj5fGeByjkaA0cVWxL4lzqkaTVDS5pueVaf6X/LhDtWNcHoW3y0x2yqtf9pU+igTKJpaO2otQVJdj/rjw= X-Received: by 2002:a05:6102:1002:: with SMTP id q2mr18627460vsp.238.1595287215978; Mon, 20 Jul 2020 16:20:15 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> In-Reply-To: <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> From: Brandon Long Date: Mon, 20 Jul 2020 16:20:04 -0700 Message-ID: To: Laura Atkins Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d35c8205aae7bff8" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 23:20:20 -0000 --000000000000d35c8205aae7bff8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins wrote: > > On 19 Jul 2020, at 19:08, Murray S. Kucherawy wrote= : > > > I'm less convinced by the notion that all of the RFC5322.From is >> disregarded by the preponderance of users when deciding what level of tr= ust >> to put in the message's content. That suggests we blindly open and read >> absolutely everything, and I suspect that isn't the case. >> >> 1. That's not what it suggests, at all >> > Then I don't know what else you might mean by "end users do not reliably > make trust decisions based on /any/ of the information in the rfc5322.Fro= m > field". What other data exist upon which to make trust decisions in the > display of a mailbox? > > > There was a research project done by an inbox provider and a major > supporter of DMARC presented at a MAAWG meeting a few years ago. They tri= ed > adding trust indicators to the message list but found no statistically > significant behavioral changes by users. Given the conference policies, I > hesitate to mention it here, but there is research. There=E2=80=99s also = a > conference paper I found, done by a computer science research team at VA > Tech that looked at this as well. > Was it us? If so, I can push on folks to find and make it releasable, but I don't recall that we had such a presentation but I've also been out of the loop for a while and wasn't there are the beginning of DMARC either. Ie, I know the ecert goldkey stuff failed on this, but don't think I ever saw the data. Brandon > > This question is actively being studied and there is research out there. > We don=E2=80=99t need to speculate or bring in individual opinions, we ca= n look at > the different studies folks have done. > > 2. No doubt there is a better way to put this, but I'm not thinking of it= , >> and this isn't just my second thought on the challenge, but quite a bit >> more than that: This demonstrates why the IETF is a very poor venue for >> conducting human factors discussions. >> > No argument here. > >> Again: There is quite a bit of experience demonstrating that providing >> trust indicators to end users does not produce reliable -- ie, useful -- >> decision-making by end users. >> > We appear to be talking past each other. I wasn't talking about trust > indicators, but rather whether the RFC5322.From domain is visible.. I > don't have any reason yet to think trust indicators are effective. > > > Most clients these days seem to be hiding the RFC5322.From domain from th= e > individual end users. Mail.app on OSX does unless you change that setting > specifically (and it seems every few upgrades they reset the setting and > then hide the checkbox again). The iOS mail app doesn=E2=80=99t even have= a setting > to change that I=E2=80=99ve been able to find. I seem to remember the las= t time I > set up a mailbox on Thunderbird (pre-2016 election as I was tracking some > candidate mail) they also hid the 5322.From address. > > There was another comment elsewhere about why not change the 5322.from > address if it=E2=80=99s not visible to the enduser, and there are 2 reaso= ns I have > for that: The ability to search for mail from a particular author and the > ability to block mail from a particular author. Rewriting the From: addre= ss > always breaks the first. Some mailing lists point the Reply-To: to the > original author which means some kinds of filtering can trigger off that. > Other mailing lists point Reply-To: to the list address, which breaks the > second. Both things are important to mailing list usability. > > laura > > -- > Having an Email Crisis? We can help! 800 823-9674 <(800)%20823-9674> > > Laura Atkins > Word to the Wise > laura@wordtothewise.com > (650) 437-0741 > > Email Delivery Blog: https://wordtothewise.com/blog > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d35c8205aae7bff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 2:00 AM Laura= Atkins <laura@wordtothewise.= com> wrote:

On 19 Jul 2020, at 19:08, Murray S. Kucherawy <superuser@gmail.com> wrote= :

<= div>
=C2=A0=C2=A0 I'm less convinced by the notion that all o= f the RFC5322.From is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at all

Then I don't know what else you might mean by "end users do not reliably make trust decisions based on /any/ of the info= rmation in the rfc5322.From field".=C2=A0 What other data exist upon w= hich to make trust decisions in the display of a mailbox?

There was a research pr= oject done by an inbox provider and a major supporter of DMARC presented at= a MAAWG meeting a few years ago. They tried adding trust indicators to the= message list but found no statistically significant behavioral changes by = users. Given the conference policies, I hesitate to mention it here, but th= ere is research. There=E2=80=99s also a conference paper I found, done by a= computer science research team at VA Tech that looked at this as well.=C2= =A0

Was it us?=C2=A0 If so, I c= an push on folks to find and make it releasable, but I don't recall tha= t we had such a presentation but I've also been out of the loop for a w= hile and wasn't there are
the beginning of DMARC either.=C2= =A0 Ie, I know the ecert goldkey stuff failed on this, but don't think = I ever saw the data.

Brandon

<= div>=C2=A0

This question is activ= ely being studied and there is research out there. We don=E2=80=99t need to= speculate or bring in individual opinions, we can look at the different st= udies folks have done.=C2=A0

2. No doubt there is a better way to put this, but I'm n= ot thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:=C2=A0 This demonstrates wh= y the IETF is a very poor venue for conducting human factors discussions.

No argument here.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Again: There is qu= ite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

=
We appear to be talking past each other.=C2=A0 I wasn't talking ab= out trust indicators, but rather whether the RFC5322.From domain is visible= ..=C2=A0 I don't have any reason yet to think trust indicators are effe= ctive.

Most cli= ents these days seem to be hiding the RFC5322.From domain from the individu= al end users. Mail.app on OSX does unless you change that setting specifica= lly (and it seems every few upgrades they reset the setting and then hide t= he checkbox again). The iOS mail app doesn=E2=80=99t even have a setting to= change that I=E2=80=99ve been able to find. I seem to remember the last ti= me I set up a mailbox on Thunderbird (pre-2016 election as I was tracking s= ome candidate mail) they also hid the 5322.From address.=C2=A0
There was another comment elsewhere about why not change the 5= 322.from address if it=E2=80=99s not visible to the enduser, and there are = 2 reasons I have for that: The ability to search for mail from a particular= author and the ability to block mail from a particular author. Rewriting t= he From: address always breaks the first. Some mailing lists point the Repl= y-To: to the original author which means some kinds of filtering can trigge= r off that. Other mailing lists point Reply-To: to the list address, which = breaks the second. Both things are important to mailing list usability.

laura=C2=A0

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

L= aura Atkins
Word to the Wise
(65= 0) 437-0741
= Email Delivery Blog: https://wordtothewise.com/blog







_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d35c8205aae7bff8-- From nobody Mon Jul 20 16:21:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A13A092F for ; Mon, 20 Jul 2020 16:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OPfUapODTfQ for ; Mon, 20 Jul 2020 16:21:11 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3473A0979 for ; Mon, 20 Jul 2020 16:21:11 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id s20so9420323vsq.5 for ; Mon, 20 Jul 2020 16:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Asg0Ila/D2dTIltY0CYKP6TaJRz2MOyDPLKe4N5RAE0=; b=oar+PeOR8xR8sBeC5lbfgGWW4qxCFDrq8AFR/i8cNSKmuiirehLBy8WvPLZcnlNHSh 4dXHnL7en/dDMlOACvICQ2h3X0r4/1PRrzBLvGH8hW5KtTTmSCyJt0x3tW6/K+AwJMJJ 6YJH8cKnZVB/cggWxacUua93eN6CzbLjXEMyAUtgFMxALFotDM6N3P5fg3td3yX5krV2 I1MAO2bqFDWmBJ5yFHPfTU1eb6r2mfKs/if+v7A3DuvgoFdkGFRKKDnMjSSVQy+cZnDt J14/ISdFfL21jOSeewT2cmaOpwZAEF/8V3MpOqYLluuoK8PATyt9u2HYogadJYHjhiVm MxVA== 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=Asg0Ila/D2dTIltY0CYKP6TaJRz2MOyDPLKe4N5RAE0=; b=CbA0FECfkOr/jKaVcDG+g9c3A0fdaUm369PRJ9R6mKPcDreJEDCgCPmaWPs81YibCD yaFT1hQeKWdlVK8Ga4EdBYLAmcfU3r1IZWJCMVeL+9YHmM/2fy73k4IeckL6OzCEZpSW lZ7JzGDNfp2vf9KhM4UTKgzFy76u5vTYh3nL5ObKedLD0HEOEB0OjsqH9fH2zINeq/lQ S9A+LfgjgcV0xv5bdHRoVpYrdeFPFTCZZwam3lkHS50BieodyFGzRxsqgdgzYMDOvwRc /5voF/7IdTsFo1Xa7BAUqysD2RWXk8JNjHFUjh5D02Vnx4MssRLCItTat2tiNopNYP6Y TKWg== X-Gm-Message-State: AOAM530OQaxgxAEBCJtDc4dbW2UW5bpzXFIboIZzNgYR9WMyt72cr47g 54OE1ImXrcYFe56fjLpb+O7LQfmG1JcDVcMUEqGF X-Google-Smtp-Source: ABdhPJzRFqJ6EXCROwBcNb/Ba5M/VO0b1n2GxWKoIJbqDQr21rPrPW7f6ErLDYEVr5cAko97s/P8OiLe9F3FGPSVIjo= X-Received: by 2002:a67:643:: with SMTP id 64mr18586425vsg.32.1595287270387; Mon, 20 Jul 2020 16:21:10 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> In-Reply-To: From: Brandon Long Date: Mon, 20 Jul 2020 16:20:56 -0700 Message-ID: To: Laura Atkins Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000011643a05aae7c3d5" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 23:21:14 -0000 --00000000000011643a05aae7c3d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2020 at 4:20 PM Brandon Long wrote: > > > On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins > wrote: > >> >> On 19 Jul 2020, at 19:08, Murray S. Kucherawy >> wrote: >> >> >> I'm less convinced by the notion that all of the RFC5322.From is >>> disregarded by the preponderance of users when deciding what level of t= rust >>> to put in the message's content. That suggests we blindly open and read >>> absolutely everything, and I suspect that isn't the case. >>> >>> 1. That's not what it suggests, at all >>> >> Then I don't know what else you might mean by "end users do not reliably >> make trust decisions based on /any/ of the information in the rfc5322.Fr= om >> field". What other data exist upon which to make trust decisions in the >> display of a mailbox? >> >> >> There was a research project done by an inbox provider and a major >> supporter of DMARC presented at a MAAWG meeting a few years ago. They tr= ied >> adding trust indicators to the message list but found no statistically >> significant behavioral changes by users. Given the conference policies, = I >> hesitate to mention it here, but there is research. There=E2=80=99s also= a >> conference paper I found, done by a computer science research team at VA >> Tech that looked at this as well. >> > > Was it us? If so, I can push on folks to find and make it releasable, bu= t > I don't recall that we had such a presentation but I've also been out of > the loop for a while and wasn't there are > the beginning of DMARC either. Ie, I know the ecert goldkey stuff failed > on this, but don't think I ever saw the data. > Hah, and of course that was supposed to be private. Brandon > > Brandon > > > >> >> This question is actively being studied and there is research out there. >> We don=E2=80=99t need to speculate or bring in individual opinions, we c= an look at >> the different studies folks have done. >> >> 2. No doubt there is a better way to put this, but I'm not thinking of >>> it, and this isn't just my second thought on the challenge, but quite a= bit >>> more than that: This demonstrates why the IETF is a very poor venue fo= r >>> conducting human factors discussions. >>> >> No argument here. >> >>> Again: There is quite a bit of experience demonstrating that providing >>> trust indicators to end users does not produce reliable -- ie, useful -= - >>> decision-making by end users. >>> >> We appear to be talking past each other. I wasn't talking about trust >> indicators, but rather whether the RFC5322.From domain is visible.. I >> don't have any reason yet to think trust indicators are effective. >> >> >> Most clients these days seem to be hiding the RFC5322.From domain from >> the individual end users. Mail.app on OSX does unless you change that >> setting specifically (and it seems every few upgrades they reset the >> setting and then hide the checkbox again). The iOS mail app doesn=E2=80= =99t even >> have a setting to change that I=E2=80=99ve been able to find. I seem to = remember >> the last time I set up a mailbox on Thunderbird (pre-2016 election as I = was >> tracking some candidate mail) they also hid the 5322.From address. >> >> There was another comment elsewhere about why not change the 5322.from >> address if it=E2=80=99s not visible to the enduser, and there are 2 reas= ons I have >> for that: The ability to search for mail from a particular author and th= e >> ability to block mail from a particular author. Rewriting the From: addr= ess >> always breaks the first. Some mailing lists point the Reply-To: to the >> original author which means some kinds of filtering can trigger off that= . >> Other mailing lists point Reply-To: to the list address, which breaks th= e >> second. Both things are important to mailing list usability. >> >> laura >> >> -- >> Having an Email Crisis? We can help! 800 823-9674 <(800)%20823-9674> >> >> Laura Atkins >> Word to the Wise >> laura@wordtothewise.com >> (650) 437-0741 >> >> Email Delivery Blog: https://wordtothewise.com/blog >> >> >> >> >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --00000000000011643a05aae7c3d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 4:20 PM Brand= on Long <blong@google.com> wr= ote:


On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins <= ;laura@wordtot= hewise.com> wrote:

On 19 Jul 2020, at = 19:08, Murray S. Kucherawy <superuser@gmail.com> wrote:

=C2=A0=C2=A0 I'm less convinced by the notion that all o= f the RFC5322.From is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at all

Then I don't know what else you might mean by "end users do not reliably make trust decisions based on /any/ of the info= rmation in the rfc5322.From field".=C2=A0 What other data exist upon w= hich to make trust decisions in the display of a mailbox?

There was a research pr= oject done by an inbox provider and a major supporter of DMARC presented at= a MAAWG meeting a few years ago. They tried adding trust indicators to the= message list but found no statistically significant behavioral changes by = users. Given the conference policies, I hesitate to mention it here, but th= ere is research. There=E2=80=99s also a conference paper I found, done by a= computer science research team at VA Tech that looked at this as well.=C2= =A0

Was it us?=C2=A0 If so, I c= an push on folks to find and make it releasable, but I don't recall tha= t we had such a presentation but I've also been out of the loop for a w= hile and wasn't there are
the beginning of DMARC either.=C2= =A0 Ie, I know the ecert goldkey stuff failed on this, but don't think = I ever saw the data.

Hah,= and of course that was supposed to be private.

Br= andon

=C2=A0

Brandon

=C2=A0

This question is active= ly being studied and there is research out there. We don=E2=80=99t need to = speculate or bring in individual opinions, we can look at the different stu= dies folks have done.=C2=A0

2. No doubt there is a better way to put this, but I'm no= t thinking of it, and this isn't just my second thought on the challenge, but quite a bit more than that:=C2=A0 This demonstrates wh= y the IETF is a very poor venue for conducting human factors discussions.

No argument here.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Again: There is qu= ite a bit of experience demonstrating that providing trust indicators to end users does not produce reliable -- ie, useful -- decision-making by end users.

=
We appear to be talking past each other.=C2=A0 I wasn't talking ab= out trust indicators, but rather whether the RFC5322.From domain is visible= ..=C2=A0 I don't have any reason yet to think trust indicators are effe= ctive.

Most cli= ents these days seem to be hiding the RFC5322.From domain from the individu= al end users. Mail.app on OSX does unless you change that setting specifica= lly (and it seems every few upgrades they reset the setting and then hide t= he checkbox again). The iOS mail app doesn=E2=80=99t even have a setting to= change that I=E2=80=99ve been able to find. I seem to remember the last ti= me I set up a mailbox on Thunderbird (pre-2016 election as I was tracking s= ome candidate mail) they also hid the 5322.From address.=C2=A0
There was another comment elsewhere about why not change the 5= 322.from address if it=E2=80=99s not visible to the enduser, and there are = 2 reasons I have for that: The ability to search for mail from a particular= author and the ability to block mail from a particular author. Rewriting t= he From: address always breaks the first. Some mailing lists point the Repl= y-To: to the original author which means some kinds of filtering can trigge= r off that. Other mailing lists point Reply-To: to the list address, which = breaks the second. Both things are important to mailing list usability.

laura=C2=A0

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

Laura Atkins
Word to the = Wise

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







_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000011643a05aae7c3d5-- From nobody Mon Jul 20 17:58:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD993A1252 for ; Mon, 20 Jul 2020 17:58:34 -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 Xj_4tYRar12I for ; Mon, 20 Jul 2020 17:58:33 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 085173A1250 for ; Mon, 20 Jul 2020 17:58:32 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id i24so59305uak.3 for ; Mon, 20 Jul 2020 17:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GdD2jrv3UtSumG102GYrQO86UliXkJic5vV18l/gpaw=; b=BKKPuiGfIHegwS60ogUAVPNEREn4YpsKzWn8tsHKRhYYaFbyXfuRDHq16pvUGeCWfE O+CB+aJpYyY2MjODrFw8QOQ/e2/DrDy76KS1EcqKLLMzqaw4uM7vdGjHnvmwsq8ceF/n /4wT+jWVBlXdfvVyQIwFapBwr/io7uO+WozMqrIsOYHqNBVTeILxtEA2cSoG8X2WTegg xbpepSJe9JibGhjOMQHojUeIShEKVhkL1yT/yP51dF75nnUqvPov8zdzB0xTpv3jVeIx dw7Kmz3nHykNvplNQsTrwLoOk128xbOWw/9+nP910/3e3/+x2KApJQAS/FSLjfJGiZnW nLtg== 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=GdD2jrv3UtSumG102GYrQO86UliXkJic5vV18l/gpaw=; b=fkuwWTQaEyze/nJFV9vwQF96qAnOcgwN40AlkG1+gP5YBlaM5ROVCP7s81LktHHakl VTOAXRonxfgNMWjsQZy73rCJ47liQVqMN0NnLt3uu6wLGsUY0pG0b5xof/XLVjBeDsoD 1kV52vxuv2maaFj/1I7XRqvjM6EGmnRAtIzj5bjOyvH1tkrpIesakudohG1zQ5U+qwLd MjE57sryb8iQ5DGGLvXkOHvlQ7xvaxI7502fmrFEAGCuCIZ33oJFlbd16cr4x0ZkkDaI ls4s3d3zu50weySLEx2j0Nqi/cr9CY7udYvKngB5bjIROBeKTtl6DrWkU1tt9zfT7uwb /6bQ== X-Gm-Message-State: AOAM5305LyOpjlweZJqG5kULBY78v4Nc03X+EhjPYNJDx4PRHxVelDT0 6Yp0H+pJj31Wj0GFvc3t4WHv/nui3ChIo/uFivo= X-Google-Smtp-Source: ABdhPJzpwIqLJewPaGLe3+PsGrbga3OtZC+BQPeFowUe/9NigsNE5T6jADorC6lRYbGCTfs2B5PuNl9a0HGh69yM3K4= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr12027315uad.87.1595293111972; Mon, 20 Jul 2020 17:58:31 -0700 (PDT) MIME-Version: 1.0 References: <108ffa74-4cf5-5348-5a7d-713e0413ae29@tana.it> <96e11fae-99f5-b552-b959-6adf9d085a42@tana.it> In-Reply-To: <96e11fae-99f5-b552-b959-6adf9d085a42@tana.it> From: "Murray S. Kucherawy" Date: Mon, 20 Jul 2020 17:58:20 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG , Brandon Long Content-Type: multipart/alternative; boundary="00000000000040777c05aae91fea" Archived-At: Subject: Re: [dmarc-ietf] DMARC threat analysis needed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 00:58:34 -0000 --00000000000040777c05aae91fea Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely wrote: > On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote: > > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely > wrote: > > > >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From > >>> domain truly matters. > >> > >> While the opinions of big players are relevant, you yourself mentioned > >> that they tend to follow DMARC design. > > > > > Sorry, I said what? > > > Google strikes me as the kind of place that would make a decision > about what to show users based on data, so I was wondering if they > have any, because I seem to remember them talking about this back > when DMARC was in development. > [ > https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/] > When I said "back when DMARC was in development", that meant Gmail had already done what I described, not that they were inspired to do what DMARC said. Gmail was part of that effort, in fact. So no, I didn't say "they tend to follow DMARC design". The order is backwards. -MSK --00000000000040777c05aae91fea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 20, 2020 at 1:42 AM Aless= andro Vesely <vesely@tana.it> w= rote:
On Sun 19/= Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>>> Still unresolved, IMHO, is Dave's point about whether the = RFC5322.From
>>> domain truly matters.
>>
>> While the opinions of big players are relevant, you yourself menti= oned
>> that they tend to follow DMARC design. >
>
> Sorry, I said what?


=C2=A0 =C2=A0 =C2=A0Google strikes me as the kind of place that would make = a decision
=C2=A0 =C2=A0 =C2=A0about what to show users based on data, so I was wonder= ing if they
=C2=A0 =C2=A0 =C2=A0have any, because I seem to remember them talking about= this back
=C2=A0 =C2=A0 =C2=A0when DMARC was in development.
=C2=A0 =C2=A0 =C2=A0[https:/= /mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/]
<= /blockquote>

When I said "back when DMARC was in de= velopment", that meant Gmail had already done what I described, not th= at they were inspired to do what DMARC said.=C2=A0 Gmail was part of that e= ffort, in fact.

So no, I didn't say "they= tend to follow DMARC design".=C2=A0 The order is backwards.

-MSK

--00000000000040777c05aae91fea-- From nobody Mon Jul 20 18:18: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 3BCE53A126C for ; Mon, 20 Jul 2020 18:18:34 -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 ocTKdh-SVRGe for ; Mon, 20 Jul 2020 18:18:32 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 B65943A126A for ; Mon, 20 Jul 2020 18:18:32 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id g4so5667675uaq.10 for ; Mon, 20 Jul 2020 18:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLl0d+eXp/0wqwJxBcK/dXH00Dazzeo4paXQ44ixkFk=; b=Zf1+nvmKVzjkjfZOcpG/w/iOiZaSyOtwg8rbneK9MVl4I18E15kudYOpnhfL9OEpMs ReUevrOiZNhryCfZCHVk0Sdk0Ex/djhqOf088scuD2EVlv9Quvo6l/0/sglWwndASgPx RLsA3woy2xl7Gnb8e2r+vQW1Gz+xXKSedEHQxiYIYQR2Eazyx+hZHcaSzuXNUFFxlX7Z 1xixVSZpDJaUPIpnxqgDjl/Qja8ewVvr+s4uqhvAEOEmJu0v6T7g7MtbTQqP4vLiWpQr a7H1vmG/y/Jfk3Poj/TFdS8j24T6EurjKTasAwiA6e+DlcDDDSnD6klvPPeBzOxF+cIx IpzA== 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=VLl0d+eXp/0wqwJxBcK/dXH00Dazzeo4paXQ44ixkFk=; b=bSfLLEZKUzTBsAogKeXRPSH8JCgEGJX5x2vvnFRt6OkHaEW4oWeOAZG5WfnE3/pjA6 s8uMvpCRspgOKFL6Hk5Cns3lKYTMb7wGfQ/tERcnyCD0FAF1j9TyNhd5H6vd1q6OHaIF 26kDDrRu5oam1uotQYyveMAVsm3pISk+SKq+ymC0Vhv18NAU16KZWphRVJPzpSnUU1Tv QYgSi3NBoqYmVvkh1j1fKFmIx9mQe5BS93iNouZHJdC+R39F9yq90XFBhh/7pICLds1Z QYGUVwcfMFQDpVvA0/TEfPKJgXudJ8vJJsDZYwfEiyqqYXqP+Q24JlejBv5S/R4qJeop oIBg== X-Gm-Message-State: AOAM531Gfzu54RkmvJnS8bB9i81+SmS+TT2JhDmXfRneGGYwKUAOcFuE 4Emg2NEAxBlbf15lClxbOO4jFLV+ZMTCjHvEXGijBw== X-Google-Smtp-Source: ABdhPJx8ArNaavvcliAKT2ujgwmqIMIdy39cv7Y0erMnL1YudMdeApt3a5yc2xeljfkNP1I3abZnDdxsT2g3qacToQ8= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr12075865uad.87.1595294311676; Mon, 20 Jul 2020 18:18:31 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> In-Reply-To: <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> From: "Murray S. Kucherawy" Date: Mon, 20 Jul 2020 18:18:19 -0700 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c27d8c05aae966c0" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 01:18:34 -0000 --000000000000c27d8c05aae966c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins wrote: > There was a research project done by an inbox provider and a major > supporter of DMARC presented at a MAAWG meeting a few years ago. They tri= ed > adding trust indicators to the message list but found no statistically > significant behavioral changes by users. Given the conference policies, I > hesitate to mention it here, but there is research. There=E2=80=99s also = a > conference paper I found, done by a computer science research team at VA > Tech that looked at this as well. > I remember something about the former. I'll see if I can find a public reference to it. "Data, data, data; we cannot make bricks without clay." > Most clients these days seem to be hiding the RFC5322.From domain from th= e > individual end users. Mail.app on OSX does unless you change that setting > specifically (and it seems every few upgrades they reset the setting and > then hide the checkbox again). The iOS mail app doesn=E2=80=99t even have= a setting > to change that I=E2=80=99ve been able to find. I seem to remember the las= t time I > set up a mailbox on Thunderbird (pre-2016 election as I was tracking some > candidate mail) they also hid the 5322.From address. > I could be wrong but I seem to recall that at the time DMARC was published, this wasn't the case. (See my previous remarks about Gmail.) But I agree that it does seem to be the case now. I'm not sure we've ever fully faced the idea that what MUAs choose to display needs to be factored into the evolution of these protocols. For as long as I've been working on this, it's been the opposite. -MSK --000000000000c27d8c05aae966c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2020 at 1:59 AM Laura Atk= ins <laura@wordtothewise.com<= /a>> wrote:



I could be wrong but I seem to recall that at the time D= MARC was published, this wasn't the case.=C2=A0 (See my previous remark= s about Gmail.)=C2=A0 But I agree that it does seem to be the case now.

I'm n= ot sure we've ever fully faced the idea that what MUAs choose to displa= y needs to be factored into the evolution of these protocols.=C2=A0 For as = long as I've been working on this, it's been the opposite.

-MSK
--000000000000c27d8c05aae966c0-- From nobody Mon Jul 20 18:34: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 7E3073A127B for ; Mon, 20 Jul 2020 18:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 fT5UH-IefrGM for ; Mon, 20 Jul 2020 18:34:01 -0700 (PDT) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 628D23A127C for ; Mon, 20 Jul 2020 18:34:01 -0700 (PDT) Received: by mail-oo1-xc33.google.com with SMTP id s190so3597345ooa.13 for ; Mon, 20 Jul 2020 18:34:01 -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=ZI3mnh/76ot+CkI7WWp27hi6QryYxTHsH5exuyMhIhI=; b=Q4JzS4QPXe44kW/sFaiCMNZ/4Wws+BH4FnjXfembv27f0n+GHMcBdl0WATTEPkS80n fAMogzAsWEXPitamwDP5OuYg6PigcgqYHZCRFovXDD9+8lhXEuh8askCyqPdobTFSuym 6T9iybDX6wFLmHOoiwMGcT0qPFbdQI1wVANcrP5qu65cYryLW51TwWPlS0EbuZ9HRCIL 5iedcfkAGpoIoAwvacaf61WoCyVfrAlY6Xi5eI+SdfUtBXCbdIKlHlLDyKVsD+ICxynt YaKd/wGRVRfktOM539xpnTk8fh9sApnrAqpBAllBuG5Qh72ZY/DpVyvqzIHsghA3KpGc /cIg== 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=ZI3mnh/76ot+CkI7WWp27hi6QryYxTHsH5exuyMhIhI=; b=Fjsh0GXa+9/YzBZOB0SE4q6LX+1XgKQTz8TcJvtqmVyzamVUcycpgDoZ1KmEd26T50 RxmZkaQXaDhqed2Vpi9GmP620UhSgd6tG6PQy57mJAQkmRT4nEN+tHWNMPHDzBmWd9Cg 5wdXZmuzxsJDiHaecpBUSPvwFxFDNyp56yrcuJ/kuuqBcOgkt6jt3DlaS1Dc9qCgUa4+ fpRclJCZNNVRDA3hOYRMlKffk27DsZhyFJvOWvF8Jm61Bwrargr0kIjijhvNqNoQHc7+ zRaSdHE+C3fAv6fO0+9qykuzJfle5gZxFAq4FRWDcKcRGNbfz8pNHGbdtObjwVzlB7MG k7Tw== X-Gm-Message-State: AOAM5314SQCycB55imJYhzYiFgtdAw7clkf7Srqhz8ZOd1Q6ie1cAEKa kfD8cro+uJ3vLDOsYsMYuUTCCBqBd+E= X-Google-Smtp-Source: ABdhPJwQmwIW64szJHs0dE32KQrTyPfLFq5zU/U/+LuCoFGUqbXPHSDmHqUf4ftnJUuhuLkoEr2llw== X-Received: by 2002:a4a:8257:: with SMTP id t23mr22127456oog.60.1595295240432; Mon, 20 Jul 2020 18:34:00 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:e59e:c7bf:acd:5516? ([2600:1700:a3a0:4c80:e59e:c7bf:acd:5516]) by smtp.gmail.com with ESMTPSA id c96sm339098otb.16.2020.07.20.18.33.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2020 18:33:59 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> From: Dave Crocker Message-ID: Date: Mon, 20 Jul 2020 18:33:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 01:34:03 -0000 On 7/20/2020 6:18 PM, Murray S. Kucherawy wrote: > I'm not sure we've ever fully faced the idea that what MUAs choose to > display needs to be factored into the evolution of these protocols.  > For as long as I've been working on this, it's been the opposite. Although various people keep citing affecting display based on dmarc, that's never been the essence of its motivation.  Which is good, because users are not affected by trust indicators. Really.  Not. It's entirely reasonable to start with the idea that it might (or should) help end-user evaluation, but human factors don't serve the master of that kind of logic. To date, online experience is that users are essentially impervious to trust indicators.(*) Rather, DMARC serves to provide some clean data to the receiving filtering engine, which is the only venue that matters for email safety.  (Well, and originating filtering engines, of course.) Not the MUA. d/ (*) Obviously, if you have some data to the contrary... -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 20 19:56: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 EE4BD3A13E9 for ; Mon, 20 Jul 2020 19:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IwTWUoJk; dkim=pass (1536-bit key) header.d=taugh.com header.b=tnmep5UF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1zraKhCPu1B for ; Mon, 20 Jul 2020 19:55:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D413A13A7 for ; Mon, 20 Jul 2020 19:55:46 -0700 (PDT) Received: (qmail 69928 invoked from network); 21 Jul 2020 02:55:45 -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=11124.5f165931.k2007; bh=ILHfs2wHZn6ZRox2EQEJKg1R+hH1cl7HzW/bTnj/ZEA=; b=IwTWUoJkCDA1RRh76lcvbtnooohVUN1AgqLGZK5uqcISFbJk0euZbe9Vwi7l2UKHZIvI0PjdRqJDOBj/N7MaeVZhVXrXsDpRemGH3VCHUfVPhb0l6lIHOyjujEmt/Q8xRgYgRudTy8hoaS9BQdXG9oAc9zXLRKKZlHS4t7gzDs4JXiQf/kZZXCgwYQpC/nok97nfeIMUo5juRVemgbjtdENGwbpuGtKd2l3UONAF+5rvogkwU+sOIrQHF0U4aMxN 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=11124.5f165931.k2007; bh=ILHfs2wHZn6ZRox2EQEJKg1R+hH1cl7HzW/bTnj/ZEA=; b=tnmep5UFs+LMLK+EfLTM9cByIK1etQOtnuwkoit0iaHBetrKWYBDc5YDY2fPV7uY4LkDkFMchMqX/lSJmMO/HuHe2n3O6lxI64z+QrYd1OSGiI+qlgKInjth9W4+VN0hI/Oj7cpK7GeWlBVJMtIXaVbyy3p3ug2o39+6pQgF/C3F4B6w9vLQxyvIEqHGYZxmWzes4PLAHXdDPulinSg/h3a924AVJJT1rrbFDwBlwIx1aZKWljiMUxUqn4vitr7s 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; 21 Jul 2020 02:55:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 27E961D58026; Mon, 20 Jul 2020 22:55:45 -0400 (EDT) Date: 20 Jul 2020 22:27:15 -0400 Message-Id: <20200721022717.A51D31D57B7C@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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 02:56:04 -0000 In article you write: >Why should the rest of end-users suffer? (some might say) > >Granted, we are a university. Maybe these are just faculty being hyper-sensitive to how >their messages are appearing to their peers/students. But isn't that enough evidence that >end-users *are* relevant? With time, maybe we can change these end-user expectations, and >From rewriting will be the new reality that people will accept. I don't think the claim is that users don't see anything, it's that they're no good at using what they see to make security decisions, something that has more to do with mental models and metaphors between what's on the screen and reality. >I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. >In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary >receiver will trust their non-munged mail. Giving the receivers a way to un-munge (if they >can and/or want and/or trust) would be a productive path forward out of this situation. We already have a couple of ways to do reversible message munging, starting with MIME message wrapping. In principle it works fine, in practice it's awful because MUAs don't show wrapped messages consistently and often in ways that are painful, e.g., you can see the original author address but there's no button you can push to respond to it. Unwrapping a MIME attachment is a lot easier than the proposed DKIM unmunging but I doubt either is going to show up in MTAs any time soon. Perhaps you could do it in the mail gateway. R's, John From nobody Tue Jul 21 00:59: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 882C13A14C0 for ; Tue, 21 Jul 2020 00:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiIyw5D5XmAh for ; Tue, 21 Jul 2020 00:59:48 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF83A14BF for ; Tue, 21 Jul 2020 00:59:48 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 752279F149 for ; Tue, 21 Jul 2020 00:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595318388; bh=P9xHGagGDNY8me9IVtC9iB4XLkaq9/l8NcufI2TMA3I=; h=From:Subject:Date:References:To:In-Reply-To:From; b=BOA50ZQFG6+adNik1WY6XU5L4P4ryBmMBITY9RFNhVL3spwek83OasFdjSJQJZpiX Yy6V3Ep1Bcchkvr4wbVcVGmo4dXmInXwnqE1PQEzrtW8XCer+wYcZ2ZphF+VmrY+Xk U6cp+CuesbGZ0+VPUDwWsIgtqgULbB76ceZtxfIY= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_0043228A-A02C-4EBE-9C46-4F2AC0292BA0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 21 Jul 2020 08:59:46 +0100 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <42D76A26-D947-4759-AF2C-8857568D3497@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 07:59:51 -0000 --Apple-Mail=_0043228A-A02C-4EBE-9C46-4F2AC0292BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jul 2020, at 00:20, Brandon Long = wrote: >=20 >=20 >=20 > On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins > wrote: >=20 >> On 19 Jul 2020, at 19:08, Murray S. Kucherawy > wrote: >=20 >>> I'm less convinced by the notion that all of the RFC5322.=46rom = is disregarded by the preponderance of users when deciding what level of = trust to put in the message's content. That suggests we blindly open and = read absolutely everything, and I suspect that isn't the case. >> 1. That's not what it suggests, at all >>=20 >> Then I don't know what else you might mean by "end users do not = reliably make trust decisions based on /any/ of the information in the = rfc5322.=46rom field". What other data exist upon which to make trust = decisions in the display of a mailbox? >=20 > There was a research project done by an inbox provider and a major = supporter of DMARC presented at a MAAWG meeting a few years ago. They = tried adding trust indicators to the message list but found no = statistically significant behavioral changes by users. Given the = conference policies, I hesitate to mention it here, but there is = research. There=E2=80=99s also a conference paper I found, done by a = computer science research team at VA Tech that looked at this as well.=20= >=20 > Was it us? If so, I can push on folks to find and make it releasable, = but I don't recall that we had such a presentation but I've also been = out of the loop for a while and wasn't there are > the beginning of DMARC either. Ie, I know the ecert goldkey stuff = failed on this, but don't think I ever saw the data. Wasn=E2=80=99t Google (which doesn=E2=80=99t mean Google hasn=E2=80=99t = done similar work. Following up offlist.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_0043228A-A02C-4EBE-9C46-4F2AC0292BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21 Jul 2020, at 00:20, Brandon Long <blong=3D40google.com@dmarc.ietf.org> wrote:



On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins <laura@wordtothewise.com> wrote:

On 19 Jul 2020, at 19:08, = Murray S. Kucherawy <superuser@gmail.com> = wrote:

   I'm less convinced by the notion = that all of the RFC5322.=46rom is disregarded by the preponderance of users when deciding what level of trust to put in the message's content. That suggests we blindly open and read absolutely everything, and I suspect that isn't the case.

1. That's not what it suggests, at = all

Then I don't know what else = you might mean by "end users do not reliably make trust = decisions based on /any/ of the information in the rfc5322.=46rom = field".  What other data exist upon which to make trust decisions = in the display of a mailbox?

There was a research project done by an inbox provider = and a major supporter of DMARC presented at a MAAWG meeting a few years = ago. They tried adding trust indicators to the message list but found no = statistically significant behavioral changes by users. Given the = conference policies, I hesitate to mention it here, but there is = research. There=E2=80=99s also a conference paper I found, done by a = computer science research team at VA Tech that looked at this as = well. 

Was it us?  If so, I can push on = folks to find and make it releasable, but I don't recall that we had = such a presentation but I've also been out of the loop for a while and = wasn't there are
the beginning of DMARC = either.  Ie, I know the ecert goldkey stuff failed on this, but = don't think I ever saw the = data.

Wasn=E2=80=99t Google (which doesn=E2=80=99t mean = Google hasn=E2=80=99t done similar work. Following up = offlist. 

laura 

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

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

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







= --Apple-Mail=_0043228A-A02C-4EBE-9C46-4F2AC0292BA0-- From nobody Tue Jul 21 01:08: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 D105A3A14D0 for ; Tue, 21 Jul 2020 01:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA6SNAkt9fdW for ; Tue, 21 Jul 2020 01:08:54 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 338A03A14CE for ; Tue, 21 Jul 2020 01:08:53 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 115A49F149 for ; Tue, 21 Jul 2020 01:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595318933; bh=kfgHtyVUx2V1HMYULzUCE0DS3Vr5hQbgAtp1ow2v1lQ=; h=From:Subject:Date:References:To:In-Reply-To:From; b=WTVGo+spKYTSV0BFi7FMO/8SLvaxvR5+Q23ycEq/07hpRxjoZOBMFhJZgJTTTMla/ BVsg1BgpeGkgUAMa9AAR6u5gHb4FYsY/yacmjkDEDEEBLUV0GSTqr5lnzh3KI05FA8 4fUjhjHWKnvuvqjYrE2+a8ikKQASuvxJgi27lYvI= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_D75B1193-D617-4247-B6B3-FC7D5CB76226" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 21 Jul 2020 09:08:50 +0100 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <9A436C27-CECC-46DD-B365-1FCF9366E64F@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 08:08:56 -0000 --Apple-Mail=_D75B1193-D617-4247-B6B3-FC7D5CB76226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jul 2020, at 02:18, Murray S. Kucherawy = wrote: >=20 > On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins > wrote: > There was a research project done by an inbox provider and a major = supporter of DMARC presented at a MAAWG meeting a few years ago. They = tried adding trust indicators to the message list but found no = statistically significant behavioral changes by users. Given the = conference policies, I hesitate to mention it here, but there is = research. There=E2=80=99s also a conference paper I found, done by a = computer science research team at VA Tech that looked at this as well.=20= >=20 > I remember something about the former. I'll see if I can find a = public reference to it. >=20 > "Data, data, data; we cannot make bricks without clay." = https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.p= df = is the conference talk I was mentioning.=20 I=E2=80=99ll be honest, I do think both phishing and UX has evolved = significantly since DMARC was initially announced. The protocol has not = kept up with the evolution and it=E2=80=99s benefits are much less = obvious than when it was initially launched. We=E2=80=99re forcing a lot = of damage on normal email usage, for non-obvious benefits.=20 > =20 > Most clients these days seem to be hiding the RFC5322.=46rom domain = from the individual end users. Mail.app on OSX does unless you change = that setting specifically (and it seems every few upgrades they reset = the setting and then hide the checkbox again). The iOS mail app = doesn=E2=80=99t even have a setting to change that I=E2=80=99ve been = able to find. I seem to remember the last time I set up a mailbox on = Thunderbird (pre-2016 election as I was tracking some candidate mail) = they also hid the 5322.=46rom address.=20 >=20 > I could be wrong but I seem to recall that at the time DMARC was = published, this wasn't the case. (See my previous remarks about Gmail.) = But I agree that it does seem to be the case now. I don=E2=80=99t remember, either. I think clients were going down that = route, though. I know, for instance, that the iOS mail client has never = shown the email address, always the friendly from.=20 > I'm not sure we've ever fully faced the idea that what MUAs choose to = display needs to be factored into the evolution of these protocols. For = as long as I've been working on this, it's been the opposite. When we=E2=80=99re basing a protocol on =E2=80=9Cwhat the user sees=E2=80=9D= and =E2=80=9Cwhat the user can trust=E2=80=9D then I think we have to. = DMARC says =E2=80=9Cusers can trust that mail from @domain.example is = really from @domain.example=E2=80=9D but if the user never sees that, = how do they know?=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_D75B1193-D617-4247-B6B3-FC7D5CB76226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21 Jul 2020, at 02:18, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Mon, Jul 20, 2020 = at 1:59 AM Laura Atkins <laura@wordtothewise.com> wrote:
There was a research project done by an inbox = provider and a major supporter of DMARC presented at a MAAWG meeting a = few years ago. They tried adding trust indicators to the message list = but found no statistically significant behavioral changes by users. = Given the conference policies, I hesitate to mention it here, but there = is research. There=E2=80=99s also a conference paper I found, done by a = computer science research team at VA Tech that looked at this as = well. 

I remember something about the former.  I'll see if I = can find a public reference to it.

"Data, data, data; we cannot make = bricks without clay."


I=E2=80=99ll be = honest, I do think both phishing and UX has evolved significantly since = DMARC was initially announced. The protocol has not kept up with the = evolution and it=E2=80=99s benefits are much less obvious than when it = was initially launched. We=E2=80=99re forcing a lot of damage on normal = email usage, for non-obvious benefits. 

  =
Most clients these days seem to be hiding the = RFC5322.=46rom domain from the individual end users. Mail.app on OSX = does unless you change that setting specifically (and it seems every few = upgrades they reset the setting and then hide the checkbox again). The = iOS mail app doesn=E2=80=99t even have a setting to change that I=E2=80=99= ve been able to find. I seem to remember the last time I set up a = mailbox on Thunderbird (pre-2016 election as I was tracking some = candidate mail) they also hid the 5322.=46rom = address. 

I = could be wrong but I seem to recall that at the time DMARC was = published, this wasn't the case.  (See my previous remarks about = Gmail.)  But I agree that it does seem to be the case = now.

I = don=E2=80=99t remember, either. I think clients were going down that = route, though. I know, for instance, that the iOS mail client has never = shown the email address, always the friendly from. 

I'm not sure we've = ever fully faced the idea that what MUAs choose to display needs to be = factored into the evolution of these protocols.  For as long as = I've been working on this, it's been the = opposite.

When we=E2=80=99re basing a protocol on =E2=80=9Cwha= t the user sees=E2=80=9D and =E2=80=9Cwhat the user can trust=E2=80=9D = then I think we have to. DMARC says =E2=80=9Cusers can trust that mail = from @domain.example is really from @domain.example=E2=80=9D but if the = user never sees that, how do they know? 

laura 

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

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

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







= --Apple-Mail=_D75B1193-D617-4247-B6B3-FC7D5CB76226-- From nobody Tue Jul 21 01:17: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 56CED3A14EA for ; Tue, 21 Jul 2020 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB7RZy_Dykat for ; Tue, 21 Jul 2020 01:17:07 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id D6B613A14E7 for ; Tue, 21 Jul 2020 01:17:07 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id DE86A9F149 for ; Tue, 21 Jul 2020 01:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595319427; bh=hX3+jp7lMwiv/L0GZ2BI6836eqelT7rcd99lCIKyNxs=; h=From:Subject:Date:References:To:In-Reply-To:From; b=fRNTgjaYrWYtgxO0dAAxZ3Vvt1ECXxOZHN0cH4iPhzp0okA4fWb30PGfr/G9NbDp9 xpcD4NuTCrIptlZu/kpsTgpuAdyrbtpgkMT3qXp1GDddrkbzXlSrj7M5hAcHdOfMb1 mfyBwDngAph6KpZR5f9PoUrwpXD5cvg88+jN2veU= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_126DC4D3-084C-4CF9-82F8-3512DAFFDC0F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 21 Jul 2020 09:17:04 +0100 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <75071ADE-8460-4C36-8912-3FD9C46B606F@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 08:17:09 -0000 --Apple-Mail=_126DC4D3-084C-4CF9-82F8-3512DAFFDC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jul 2020, at 02:33, Dave Crocker wrote: >=20 > On 7/20/2020 6:18 PM, Murray S. Kucherawy wrote: >> I'm not sure we've ever fully faced the idea that what MUAs choose to = display needs to be factored into the evolution of these protocols. For = as long as I've been working on this, it's been the opposite. >=20 >=20 > Although various people keep citing affecting display based on dmarc, = that's never been the essence of its motivation. Which is good, because = users are not affected by trust indicators. Really. Not. I agree users are not affected by trust indicators (although see the = .pdf that I linked to in an earlier email that says they are). But I = would argue that much of the marketing and justification around DMARC = has been around end users and improving their trust in brands and = protecting them from phishing.=20 >=20 > It's entirely reasonable to start with the idea that it might (or = should) help end-user evaluation, but human factors don't serve the = master of that kind of logic. To date, online experience is that users = are essentially impervious to trust indicators.(*) >=20 > Rather, DMARC serves to provide some clean data to the receiving = filtering engine, which is the only venue that matters for email safety. = (Well, and originating filtering engines, of course.) Not the MUA. That is not how I=E2=80=99ve seen DMARC being sold. Most of the = marketing I=E2=80=99ve seen about DMARC is all about user experience and = the user being able to trust mail is =E2=80=9Cfrom who it claims to be = from.=E2=80=9D And now people are explicitly layering on another = protocol that is all about what the user sees in the MUA.=20 laura --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_126DC4D3-084C-4CF9-82F8-3512DAFFDC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21 Jul 2020, at 02:33, Dave Crocker <dcrocker@gmail.com> = wrote:

On 7/20/2020 6:18 PM, Murray S. Kucherawy wrote:
I'm not sure we've ever = fully faced the idea that what MUAs choose to display needs to be = factored into the evolution of these protocols.  For as long as = I've been working on this, it's been the opposite.


Although various = people keep citing affecting display based on dmarc, that's never been = the essence of its motivation.  Which is good, because users are = not affected by trust indicators. Really.  Not.

I = agree users are not affected by trust indicators (although see the .pdf = that I linked to in an earlier email that says they are). But I would = argue that much of the marketing and justification around DMARC has been = around end users and improving their trust in brands and protecting them = from phishing. 


It's entirely = reasonable to start with the idea that it might (or should) help = end-user evaluation, but human factors don't serve the master of that = kind of logic. To date, online experience is that users are essentially = impervious to trust indicators.(*)

Rather, = DMARC serves to provide some clean data to the receiving filtering = engine, which is the only venue that matters for email safety.  = (Well, and originating filtering engines, of course.) Not the = MUA.

That is not how = I=E2=80=99ve seen DMARC being sold. Most of the marketing I=E2=80=99ve = seen about DMARC is all about user experience and the user being able to = trust mail is =E2=80=9Cfrom who it claims to be from.=E2=80=9D And now = people are explicitly layering on another protocol that is all about = what the user sees in the MUA. 

laura

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

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

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







= --Apple-Mail=_126DC4D3-084C-4CF9-82F8-3512DAFFDC0F-- From nobody Tue Jul 21 03:51: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 A3D0A3A0A49 for ; Tue, 21 Jul 2020 03:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 c4YBfV_6YIBO for ; Tue, 21 Jul 2020 03:51:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3373A0A36 for ; Tue, 21 Jul 2020 03:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595328664; bh=zQr9KhIko/LFOpGEdIPftrABw135ewMRhdgAu72Nh0M=; l=601; h=To:References:From:Date:In-Reply-To; b=B6cLmpKRs2MXsWWehHB4FLi1qzqKI7FegzidVS9lv5yCJlNkUoDgpVz4jFvnsHgOW goi4eOkqCYLI1LVI9/c6+UW2n4Zp2Ej/EWH1LFhLZh/O5k16tIDgKuicIsZhdNPvH/ 5hoxiHEnHdg7UwUSVqDXomOjWVI3o18kDyrhvsnbXC9zVflnot3za2IsxKmky 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 00000000005DC013.000000005F16C898.000071AD; Tue, 21 Jul 2020 12:51:04 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Tue, 21 Jul 2020 12:51:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 10:51:11 -0000 On Mon 20/Jul/2020 20:36:21 +0200 Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions from the > group for the agenda, otherwise the chairs will choose relevant topics. Items > in tickets or from the past month are all fair game. I think *The fate of From:* can be a fair title for summarizing the WG feelings about relaxing rules in favor of Sender: (#73), as well as other issues about this field, such as multi-address (#74) and the companion Author:. It'd be appropriate to air this topic also in next day's emailcore session. Best Ale -- From nobody Tue Jul 21 04:06: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 2F0043A0A55 for ; Tue, 21 Jul 2020 04:06:08 -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 GaLlvGYjc6ac for ; Tue, 21 Jul 2020 04:06:06 -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 7B03A3A0A50 for ; Tue, 21 Jul 2020 04:06:06 -0700 (PDT) X-ASG-Debug-ID: 1595329565-11fa3107a82d9e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 4eUJYT3bPGY9o4hp (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 21 Jul 2020 07:06:05 -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=BTKO3TgagYwY8Fe52StIveBFoUFwO/sbDO/KuKWkPUY=; b=SQpwaU7+p8/vG0B7K7jfAugKyIJQrGwpe2r7NVY4AFSAMeTUfKOvXgmS+Zry0xZsd cXpiUYlyikPgOUKa4iAX2VljnGkHq7b9pShTr91keqxUf5vvspZGipfDt+k9tnLgA PbRLmyZtv0vUpruWzrsa/to/dqMQKpCvg9c6JkucY= From: "Douglas E. Foster" To: "Murray S. Kucherawy" , "Laura Atkins" CC: "IETF DMARC WG" Date: Tue, 21 Jul 2020 11:05:55 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? Reply-To: fosterd@bayviewphysicians.com Message-ID: <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=21ff3b34e8174c76868031889a61971c In-Reply-To: References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> X-Exim-Id: 74a6fb5f7578452f9080cddb8ebbc8f5 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595329565 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: 5081 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.83353 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 11:06:08 -0000 This is a multipart message in MIME format. --21ff3b34e8174c76868031889a61971c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would like a better understanding of why MUAs are hiding or removing the = FROM address. I have one mail store that formerly used hover-to-view, but recently change= d to always-show. This was done in response to a client request on their = support forum. I have never seen a user ask for the From address to be hid= den or removed. I wonder if this trend is driven only by attempts to optim= ize display space. It would be a shame to weaken our protocols in respons= e to this trend, if the trend lacks a theoretical foundation. I also wonder if the trust indicator research is being over-applied when it= is applied to the From Address. From Address is a unique identifier, wh= ile Friendly Name is not. A trust indicator is like putting a green check= mark next to the From Address as a trust indicator. They have different = levels of relevance. One attack method steals a contact list, then emails people in that contact= list using friendly names of others in that list. Hiding the From Addres= s plays into that attack. This trust-indicator research also promotes despair. The conclusion is tha= t users process information poorly. This result then becomes an excuse to= withhold information from those users, or to allow misleading information = to be presented to them. I am not convinced that those are appropriate r= esponses. "Never" is a hard thing to prove. So it is risky to say users = "Never" use available information correctly, and "cannot be taught" to do b= etter. Attack filtering is designed on a layered defense and a sequence of probabi= lities: What is the probability that this attack will get through my spam filter?Wh= at is the probability that the user will read the message?What is the proba= bility that the user will click on the hostile link?What is the probability= that my web filter will allow access to the hostile website?What is the pr= obability that the web filter will allow the attack to be downloaded?What i= s the probability that my antivirus program will allow the attack to procee= d? The goal is to decrease the probability of a wrong decision at each point i= n the process. All I need is for some people to act smarter on some occas= ions in response to some available clue. But this cannot happen if the cl= ue is not provided.. Doug Foster --21ff3b34e8174c76868031889a61971c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I would like a bet= ter understanding of why MUAs are hiding or removing the FROM address.

I have one mail store that formerly used hover-to-view= , but recently changed to always-show.   This was done in response to = a client request on their support forum.  I have never seen a user ask= for the From address to be hidden or removed.  I wonder if this trend= is driven only by attempts to optimize display space.   It would be a= shame to weaken our protocols in response to this trend, if the trend lack= s a theoretical foundation.

I also wonder if the t= rust indicator research is being over-applied when it is applied to the Fro= m Address.    From Address is a unique identifier, while Friendly= Name is not.   A trust indicator is like putting a green check mark n= ext to the From Address as a trust indicator.   They have different le= vels of relevance.   

One attack method = steals a contact list, then emails people in that contact list using friend= ly names of others in that list.   Hiding the From Address plays into = that attack.

This trust-indicator research also pr= omotes despair.  The conclusion is that users process information poor= ly.   This result then becomes an excuse to withhold information from = those users, or to allow misleading information to be presented to them. &n= bsp;  I am not convinced that those are appropriate responses.   = "Never" is a hard thing to prove.  So it is risky to say users "Never"= use available information correctly, and "cannot be taught" to do better.<= /div>

Attack filtering is designed on a layered defense = and a sequence of probabilities:
  • What is the probability that = this attack will get through my spam filter?
  • What is the probabilit= y that the user will read the message?
  • What is the probability that= the user will click on the hostile link?
  • What is the probability t= hat my web filter will allow access to the hostile website?
  • What is= the probability that the web filter will allow the attack to be downloaded= ?
  • What is the probability that my antivirus program will allow the = attack to proceed?
The goal is to decrease the probability of= a wrong decision at each point in the process.   All I need is for so= me people to act smarter on some occasions in response to some available cl= ue.   But this cannot happen if the clue is not provided..
<= br>
Doug Foster

--21ff3b34e8174c76868031889a61971c-- From nobody Tue Jul 21 08:48: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 A5D173A0B3E for ; Tue, 21 Jul 2020 08:48:17 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 m9gyWjbXV4eF for ; Tue, 21 Jul 2020 08:48:16 -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 3D3423A0B3C for ; Tue, 21 Jul 2020 08:48:15 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2109.outbound.protection.outlook.com [104.47.55.109]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QDT008M7T8ENYA0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 21 Jul 2020 10:48:14 -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.7.21.154217, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.55.109] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZnkWZ1bi7FUCDW6Ow/jsT27ubafEEAJXhGkzGw6zaNlif3uJ5y8+f90/PqxL6QQrV8KxQDJaEeRTLcrCCdHX9njLXkrX/Y+IM82nsY8oxxzcQ6xjlenwQjLhhyll0dqRDYZEYCyax16ae+OF1znq5xqAg964NmsDKXUTdXJRwwpgIi4slSCA1ovb0m/i3ED+e42hv6rHZnC9fnh1JvgzY7WNgAZklCxPxOWCUjHeFHj36Duc4Z+wlh2hPzIFJCqehGI3GbflLowg1OIr48VCSoV5mWq/V07QFQ1FAFcWAKp1KmPVSa6I2zQVC2x9wy2RJ+kub2PMVmh4X2bZRGo2bg== 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=dTGZw9rEPo/eK+TdD+pD+PtBxoR5M4ljYLLBSLACQXw=; b=QxfH+7BhvegKY8wQuEs6Y+0TaZX8wBVftT0O6Z42K91fUkQ1pcTpVmx0HFpturfpoczch/BPJUR9QhbyANlQ8n6lprLN6THpYSbQEq3M7pt6gIyKi5YWPZou9qoDYLitMAlCsWZcZAexUz+jtA7qlmlqvV7ikZKUbHJ4d5wQ5MoSIGOXPgWwoVEKOmdIFK6VAQdts98620R7RW2kT4TB/K6z6LlQ5ZwvjOGY7EBL+GHz7qK9IK/fs1cO23tsHXwate5OiV1rgH8TyXJUeKmbblzBWJeFXMn2tAFuoXGNW/B+2FcP77eftAtOo5OJTtZCYbV8QsX99yKh71BdvGsE7g== 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=dTGZw9rEPo/eK+TdD+pD+PtBxoR5M4ljYLLBSLACQXw=; b=uPnsPdH8VHtNgmcn34bjjWghawnXlOdmm/S9DwnGbt5efrh+O71grfqQ/4bTZLWgwO9VlFnxo7vN2MEYHd0SXUs/b3SmubpNyyWlTdcJluFg+72bt5yzDTHDRDMl5qN+gK8lTCyT5LcEB74vCZDVNHj60RdLMeQKj3Gz287WExg= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR0601MB3783.namprd06.prod.outlook.com (2603:10b6:4:78::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Tue, 21 Jul 2020 15:48:13 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3195.025; Tue, 21 Jul 2020 15:48:13 +0000 To: dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> From: Jesse Thompson Message-id: Date: Tue, 21 Jul 2020 10:48:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR03CA0026.namprd03.prod.outlook.com (2603:10b6:610:59::36) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR03CA0026.namprd03.prod.outlook.com (2603:10b6:610:59::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Tue, 21 Jul 2020 15:48:12 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3dd26494-2d98-46b3-9a18-08d82d8d7a0e X-MS-TrafficTypeDiagnostic: DM5PR0601MB3783: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: w8aUH0kUDg72AaKBWBo1vd5k+shSa5NF32lsUbhE+ahxXTswHVjYAHGZQNMJdsj2ubjlpo6/U5W1uJVrwNmQim1AXjmru7xEe+5BccWDg7YBDZHee1zX029SHgXgqZYhy8xLNayv99LgAHob86ByfJNPjxUs9oBIMfjeakr69N77ASCn1NQo453Kw+eAdec0jxTRKXPlE7j+M7DxykWu+PWeFvVfb3TW2EEv2GnTss+Y4aJ4jVdWf1gpiWH2+vCcmS4SftZeic8CQdeaaNtW7kWGaKEeCmshQR+kEMlp4et18+hDDB+VVMu1DIRdaWcMT5wRnifraqUAqqAg74QUgFXl4zcS8Nn5gAWNAxBvZCqYjNbsYFVme6IZo9ybu2aq+Z62vQ8RRVroGaliLvMLdPNvi8DySJHZfNNp9uPWXTs= 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; SFTY:; SFS:(346002)(376002)(39860400002)(366004)(396003)(136003)(2906002)(44832011)(66556008)(66476007)(66946007)(75432002)(2616005)(478600001)(5660300002)(786003)(15650500001)(316002)(86362001)(16576012)(26005)(8936002)(6916009)(31686004)(8676002)(6706004)(83380400001)(31696002)(16526019)(956004)(6486002)(53546011)(36756003)(186003)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 3EXp/Trz9RLUGZ12gYTJM53rI7Ok2aWJlCFlySzWBR4w4pXfKHDgotzTeHcKkVdif9ghz+x3mLaJv1YP/GtuOnphWAsgWdIZu7KqUiMflgqHDGDfhvrPYWL8IwUqxxG0DGw6s0qaWTRDCCgmpMjbNiUr4cRU2VpqVL0QdoqOkYPiL5JL0gxP6whoE9LgV9+Ep/Nrpn98i47iCnuJs5q53D8zawRz49gOOyStrqIcBSyZd+mBbJzZsiVyEg/NNuyumTeTdfuOK0UHpuWeCXeCETvAZrcy6ncnKskThj7foBCrBgszIIYcB3S6aMIbaekjk1gy8sebJ6cWd0+8fst9Zq3PKTTnURcrnuh0zMhGUfDDpZv/jiUYV/pFl0IemnPhMwea+xws0kPfw9NGgW2Q+xNSNAONSgjwJm8x70yqJFsdOdIxehaUQXiULOJ4c2PTMTJtoXVa/YLtvEXOYoB10N+w4duLaQGe+qvKQQsFvlvPee1y8AbzmehLGlK8BNIP X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 3dd26494-2d98-46b3-9a18-08d82d8d7a0e X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 15:48:13.5810 (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: q7NFWQP7h8yWIzXE5T48CBFdPbpY0UIQnGfb8zC7Ex414pbEGX22NzZmOwMTgLciUndlslWHUEjGgXkIa1VimA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0601MB3783 Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:48:18 -0000 On 7/20/20 7:55 AM, Douglas E. Foster wrote: > I am advocating for MLMs to stop spoofing and make their peace with DMARC. Maybe the recommendation should be that MLMs (or any ESP, for that matter) should never send as a domain they do not directly own unless it's authorized to send aligned mail as that domain. (I say this as I have a distinguished PhD (not of CS) complaining to me that when he sends spoofed email from his Gmail account the messages go into spam because of DMARC. Why do these ESPs even allow it in the first place, putting the domain owner's decision to adopt DMARC as the boogieman?) The DMARC conditional rewriting logic that the MLM providers implement inhibits larger DMARC adoption because it segregates people into two camps, based solely on their domain owner's stance towards DMARC. If a large enough group of stakeholders fall into the camp of "this domain I'm using to subscribe to lists isn't and should never be subjected to DMARC rewriting", they will push back on the domain owner's attempts to publish DMARC. Maybe this ties back into the DMARCbis discussion about pct=0. We use pct=0 specifically to reduce end-user confusion about MLM rewriting behavior. Could the behavior induced by pct=0 be the default, somehow, rather than p=none? Jesse From nobody Tue Jul 21 08: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 16A493A0B43; Tue, 21 Jul 2020 08:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5H4OHbwITuo; Tue, 21 Jul 2020 08:52:02 -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 114993A0B3F; Tue, 21 Jul 2020 08:51:59 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06LFsVat013483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2020 08:54:32 -0700 To: Jesse Thompson , dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 21 Jul 2020 08:51:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:52:03 -0000 On 7/21/2020 8:48 AM, Jesse Thompson wrote: > On 7/20/20 7:55 AM, Douglas E. Foster wrote: >> I am advocating for MLMs to stop spoofing and make their peace with DMARC. > Maybe the recommendation should be that MLMs (or any ESP, for that matter) should never send as a domain they do not directly own unless it's authorized to send aligned mail as that domain. (I say this as I have a distinguished PhD (not of CS) complaining to me that when he sends spoofed email from his Gmail account the messages go into spam because of DMARC. Why do these ESPs even allow it in the first place, putting the domain owner's decision to adopt DMARC as the boogieman?) This being a technical forum, we need to be careful and precise about terminology and history and, well, quite a bit more. The mail is not spoofed.  Consider the definition of the word. Then consider that the MLM is authorized by the user with the address in the original From field. Also then consider that the existing MLM behavior has existed and been useful for roughly 45 years. The problem, here, is DMARC's imposing a change in email semantics. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 21 10:28: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 41BBC3A0C80 for ; Tue, 21 Jul 2020 10:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiiMONQqCbsp for ; Tue, 21 Jul 2020 10:28:25 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B175E3A0C7F for ; Tue, 21 Jul 2020 10:28:25 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id j186so10815308vsd.10 for ; Tue, 21 Jul 2020 10:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6him4gJlv2rtdoZbBFfHK52X9FxbMmlhAgQJuUVWpFA=; b=MRvnwYF3FFRIM5cAlhjRR4qKUuKTZM0uRhv2l7K5cbF7SrjVeppdqzLEKdOJTDp2Yh NfMepk2EGaiElx1VXENsUTasssM5Tu/VS/+f5zn8A1OKjTQIbtf2SXJwy/ENe+Ia7Iqf vQ8CHGDefTnA1BYgm84wVB5cyq8XYU9IQ34O1J2Ff0V2R8hHk3CqNblUkcXKUOWl7s2W Ft0hEAxuXdFjosh+rZ9iDmxG1n1MNB/gLm37wrfMKR+V5Gul5jllv5l3JkTzAPiktqXW qiRiUqGfm4blwfO4Nmmj9aOASKHJIL5sRZlxTpiayzQnnu20oq/y+HonoVXVY8W6ZTcA 4swg== 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=6him4gJlv2rtdoZbBFfHK52X9FxbMmlhAgQJuUVWpFA=; b=kBATYtzP6ujaoS1M9QFTZixiCChq2WE4LIkvnxH5LY3PvNf9WGk0GYpyGqhoisz9WD OGNQ3tMN9XujmahfJ8KYoZkelw581R6+20DT3KY3uGVFuqh3cOT1Z0wO4v/ySoutAtet /LB9dOSLPwODgsJyuFgubeGQrll8JkRSv+5I6BJ5ROfJqI/61LxK6EIUr67OuLzqkbvT 4EG76H159Dp9JTk/ylNPndpW3xliCUMTUUrsSHYQm0UwbEn4CCTmvSksKPd5T/+k90X6 o8OPz3ClFgMI0TRZrpKO4kpVp+uxHWDODc0YSWFW5w55kYGEKRjVHnZ5bL2Z9wsDIpYq wKzA== X-Gm-Message-State: AOAM530clI5G20ZQ33P+v3wpX/a9/jqxPd+6PiR8MTzO7AiKcI4Ckw4H SDY4KfN+ISIkHMODFokIowNoRNaVCml+4FJkIJMD X-Google-Smtp-Source: ABdhPJz5+kLCkkZXaXATfs58M971IdzBHz7EyAkAJ4C+zbVFiDAlgwnRuHWdxvTZbD+ITaWTI6USbjOkiGpuu4J+OXM= X-Received: by 2002:a05:6102:1002:: with SMTP id q2mr21673553vsp.238.1595352504492; Tue, 21 Jul 2020 10:28:24 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> In-Reply-To: <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> From: Brandon Long Date: Tue, 21 Jul 2020 10:28:12 -0700 Message-ID: To: "Douglas E. Foster" Cc: "Murray S. Kucherawy" , Laura Atkins , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000052cca705aaf6f36a" Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 17:28:27 -0000 --00000000000052cca705aaf6f36a Content-Type: text/plain; charset="UTF-8" Do sms/mms programs show the phone number any more? I think there's been a deliberate strategy to make email clients more like other messaging clients, and the technical parts like the actual address are details that most of the time aren't useful to the user... when they're not being spoofed, of course, or otherwise need to differentiate between multiple addresses for the same person. Brandon On Tue, Jul 21, 2020 at 4:06 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > I would like a better understanding of why MUAs are hiding or removing the > FROM address. > > I have one mail store that formerly used hover-to-view, but recently > changed to always-show. This was done in response to a client request on > their support forum. I have never seen a user ask for the From address to > be hidden or removed. I wonder if this trend is driven only by attempts to > optimize display space. It would be a shame to weaken our protocols in > response to this trend, if the trend lacks a theoretical foundation. > > I also wonder if the trust indicator research is being over-applied when > it is applied to the From Address. From Address is a unique identifier, > while Friendly Name is not. A trust indicator is like putting a green > check mark next to the From Address as a trust indicator. They have > different levels of relevance. > > One attack method steals a contact list, then emails people in that > contact list using friendly names of others in that list. Hiding the From > Address plays into that attack. > > This trust-indicator research also promotes despair. The conclusion is > that users process information poorly. This result then becomes an excuse > to withhold information from those users, or to allow misleading > information to be presented to them. I am not convinced that those are > appropriate responses. "Never" is a hard thing to prove. So it is risky > to say users "Never" use available information correctly, and "cannot be > taught" to do better. > > Attack filtering is designed on a layered defense and a sequence of > probabilities: > > - What is the probability that this attack will get through my spam > filter? > - What is the probability that the user will read the message? > - What is the probability that the user will click on the hostile link? > - What is the probability that my web filter will allow access to the > hostile website? > - What is the probability that the web filter will allow the attack to > be downloaded? > - What is the probability that my antivirus program will allow the > attack to proceed? > > The goal is to decrease the probability of a wrong decision at each point > in the process. All I need is for some people to act smarter on some > occasions in response to some available clue. But this cannot happen if > the clue is not provided.. > > Doug Foster > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000052cca705aaf6f36a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do sms/mms programs show the phone number any more?=C2=A0 = I think there's been a deliberate strategy to make email clients more l= ike
other messaging clients, and the technical parts like the actual ad= dress are details that most of the time aren't useful to the user... wh= en
they're not being spoofed, of course, or otherwise need to= differentiate between multiple addresses for the same person.

=
Brandon

On Tue, Jul 21, 2020 at 4:06 AM Douglas E. Fo= ster <fosterd@bayviewph= ysicians.com> wrote:
I would li= ke a better understanding of why MUAs are hiding or removing the FROM addre= ss.

I have one mail store that formerly used hover= -to-view, but recently changed to always-show. =C2=A0 This was done in resp= onse to a client request on their support forum.=C2=A0 I have never seen a = user ask for the From address to be hidden or removed.=C2=A0 I wonder if th= is trend is driven only by attempts to optimize display space. =C2=A0 It wo= uld be a shame to weaken our protocols in response to this trend, if the tr= end lacks a theoretical foundation.

I also wonder = if the trust indicator research is being over-applied when it is applied to= the From Address. =C2=A0 =C2=A0From Address is a unique identifier, while = Friendly Name is not. =C2=A0 A trust indicator is like putting a green chec= k mark next to the From Address as a trust indicator. =C2=A0 They have diff= erent levels of relevance. =C2=A0=C2=A0

One attack= method steals a contact list, then emails people in that contact list usin= g friendly names of others in that list. =C2=A0 Hiding the From Address pla= ys into that attack.

This trust-indicator research= also promotes despair.=C2=A0 The conclusion is that users process informat= ion poorly. =C2=A0 This result then becomes an excuse to withhold informati= on from those users, or to allow misleading information to be presented to = them. =C2=A0 =C2=A0I am not convinced that those are appropriate responses.= =C2=A0 "Never" is a hard thing to prove.=C2=A0 So it is risky to= say users "Never" use available information correctly, and "= ;cannot be taught" to do better.

Attack filte= ring is designed on a layered defense and a sequence of probabilities:
  • What is the probability that this attack will get through my spam = filter?
  • What is the probability that the user will read the message= ?
  • What is the probability that the user will click on the hostile l= ink?
  • What is the probability that my web filter will allow access t= o the hostile website?
  • What is the probability that the web filter = will allow the attack to be downloaded?
  • What is the probability tha= t my antivirus program will allow the attack to proceed?
The = goal is to decrease the probability of a wrong decision at each point in th= e process. =C2=A0 All I need is for some people to act smarter on some occa= sions in response to some available clue. =C2=A0 But this cannot happen if = the clue is not provided..

Doug Foster

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000052cca705aaf6f36a-- From nobody Tue Jul 21 10:58: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 CE56C3A0D38 for ; Tue, 21 Jul 2020 10:58:27 -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=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 Vje_bKSLZAja for ; Tue, 21 Jul 2020 10:58:25 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083AC3A0D37 for ; Tue, 21 Jul 2020 10:58:25 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id j18so3697539wmi.3 for ; Tue, 21 Jul 2020 10:58:24 -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=vaxopxUjPzN2PAVz/2yeU7DhxRNR4iw41Jn7AeVltNM=; b=uTeZc1tniQs7ce6lSu2xbmq4oOrgaCaU2nsUPuwZpThiZf1As8M0WMMJU42HhSxzn6 DvxXELkuWGSIX42ye2IwxJgCC/Wt8v0Q75LahbpLmFY3m1TFO6bzoQNLaPyXZdiSQvsJ xCv1VpfCpJG0HGGNK0Rpetx433l2L6ot5S6pkhLACfU1q02OrJaiq/jJINzAJMjkD3Z2 HUyosOIf+u0QAH741goA1Z3kHghhx8g1hZHg3efUycxeQSD4ioFM6uwRoQ8MxlsOFPTl indDKGCtAS9xXDtwet2EbjZdxwNPs+v6+A44bR/5P8iHCL81TXxSYM4bhCfQaVs1BG7D H4Tg== 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=vaxopxUjPzN2PAVz/2yeU7DhxRNR4iw41Jn7AeVltNM=; b=Y4S8H+cHywErPst3LjmFfoUzbB7ElHo50CdS4HGdZx4Hyr4u4kylPYvJOs+vkAHsSS 4rmRhc/ORTaKcGAV1VRtZ/nOoh36ZPz/Z/c5pkPVrM6albZnm7HYcuxSoKOchAwmugx+ hWR1oy5pWBiMs4BrhxO9tnzUcPEyO/EprXaFGaiKh02LFYYA53mj6SdhhcWIC1C8fHvE vgMh+KqNqsVDI7D8MJf9PHFVwGgcyco9Yje73L6p38yCCrTBkUHGY26I9VcvF0w73FW0 VhSzWvx63QHARME8ThLVVYcDsjhiqqp9XEF/LA9/7+RsisPqVjEaewnhkyL1e5CPUhtt CNOg== X-Gm-Message-State: AOAM532ZFsSXycHIhHT5D9EZWguP9uTkLkMLAbR6N42Whpv6/6HymtkF 4KbbCNfjS0D0ipw8Y3/dp7l1F0JqYUmFtZVxdhW9KA== X-Google-Smtp-Source: ABdhPJx5joz9gZm3d+sW75Y/KbQZz/r8UbJPI02RJQw6EMrKls3Wop2sSe1EcRvYjOHSQZuSuKAIWlrW8/gfERNr8nY= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr4901152wml.36.1595354303585; Tue, 21 Jul 2020 10:58:23 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Tue, 21 Jul 2020 13:58:11 -0400 Message-ID: To: Dave CROCKER Cc: Jesse Thompson , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008e5fbf05aaf75ee5" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 17:58:28 -0000 --0000000000008e5fbf05aaf75ee5 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker wrote: > On 7/21/2020 8:48 AM, Jesse Thompson wrote: > > On 7/20/20 7:55 AM, Douglas E. Foster wrote: > >> I am advocating for MLMs to stop spoofing and make their peace with > DMARC. > > Maybe the recommendation should be that MLMs (or any ESP, for that > matter) should never send as a domain they do not directly own unless it's > authorized to send aligned mail as that domain. (I say this as I have a > distinguished PhD (not of CS) complaining to me that when he sends spoofed > email from his Gmail account the messages go into spam because of DMARC. > Why do these ESPs even allow it in the first place, putting the domain > owner's decision to adopt DMARC as the boogieman?) > > > This being a technical forum, we need to be careful and precise about > terminology and history and, well, quite a bit more. > > The mail is not spoofed. Consider the definition of the word. Then > consider that the MLM is authorized by the user with the address in the > original From field. > > This is an interesting statement and raises a question.. Does a user have the authority to authorize (some) use of a domain in a manner contravening the express statement (p=reject) of the domain owner/administrator? I'm going to have to say no. > Also then consider that the existing MLM behavior has existed and been > useful for roughly 45 years. > > Slavery existed for a long time (still does in some places) and was useful (for some) for a long time. Things change and evolve. > The problem, here, is DMARC's imposing a change in email semantics. > If that is the problem, why did you participate in the original DMARC effort? The issue was clear even back then. Michael Hammer --0000000000008e5fbf05aaf75ee5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 21, 2020 at 11:52 AM Dave= Crocker <dhc@dcrocker.net> w= rote:
On 7/21/20= 20 8:48 AM, Jesse Thompson wrote:
> On 7/20/20 7:55 AM, Douglas E. Foster wrote:
>> I am advocating for MLMs to stop spoofing and make their peace wit= h DMARC.
> Maybe the recommendation should be that MLMs (or any ESP, for that mat= ter) should never send as a domain they do not directly own unless it's= authorized to send aligned mail as that domain.=C2=A0 (I say this as I hav= e a distinguished PhD (not of CS) complaining to me that when he sends spoo= fed email from his Gmail account the messages go into spam because of DMARC= .=C2=A0 Why do these ESPs even allow it in the first place, putting the dom= ain owner's decision to adopt DMARC as the boogieman?)


This being a technical forum, we need to be careful and precise about
terminology and history and, well, quite a bit more.

The mail is not spoofed.=C2=A0 Consider the definition of the word. Then consider that the MLM is authorized by the user with the address in the original From field.

This is an interesting statement and raises a questio= n.. Does a user have the authority to authorize (some) use of a domain in a= manner contravening the express statement (p=3Dreject) of the domain owner= /administrator? I'm going to have to say no.
=C2=A0
Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.

Slavery existed for a long time (still does in some p= laces) and was useful (for some) for a long time. Things change and evolve.= =C2=A0
=C2=A0
The problem, here, is DMARC's imposing a change in email semantics.
=

If that is the problem, why did you partic= ipate in the original DMARC effort? The issue was clear even back then.
=C2=A0
Michael Hammer
--0000000000008e5fbf05aaf75ee5-- From nobody Tue Jul 21 11:05: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 65E293A0D37 for ; Tue, 21 Jul 2020 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bbiw.net header.b=FOCIcNET; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CHUjZ0mY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91uupE9jht3w for ; Tue, 21 Jul 2020 11:05:49 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206BF3A0DB6 for ; Tue, 21 Jul 2020 11:05:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 73E5F5C009A for ; Tue, 21 Jul 2020 14:05:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 21 Jul 2020 14:05:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=Q L79FZntMkBVGX01ow0BFZI+DHHMaW49c0aubOzaAXE=; b=FOCIcNETopVDFT2jM 8sX7r4OOVUo83+85foHcX6ayvMYe2MNZIuJHFVtRCinEkk3CUJZ/lK8sNKCOMGSa 6Eea+2jWGB2hcN3SXlYb1tGNvFVdiiJXlHtdGINbh9rlIqFc8mA0h4YrSi6Iyw1W s2nv0QEKq6/rqVHmLBXduA9HvAsM9+lLUn0AOg6exAzeree3hAu4am3wu8L2S3Ai WMemPIcs6I6+LVSXaWJqbELS/OsBGVcadxcdOhkiaYD3d2YivfTqn/Oy2SGTmYeD 3wI99QKnr/AfsY0/LiFsfG5VkH+3I1GIiTAodORelbdOXJubVeXNZcLYk+cosWl8 nU4CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=QL79FZntMkBVGX01ow0BFZI+DHHMaW49c0aubOzaA XE=; b=CHUjZ0mYL8rIUyKBNpcegiAziJN01uhaRh4lirDlaEOz2tjp8u4dwE6Ny vjlFI9MEcYbr9nESGOLL41lAAffP/KeE0ZQuYUjaB2Qy3FB7TGpf10jmkk8M8Lbd 9MOyFd5mpqbTWaCOtKiEvrjSTJXu/dQD318gKIsIeGCck08BxPdUJ1iXD8+MmTvD T4ldeMa80b5tU9+BKHTOeDdIVDuBgtZBZhTr7+eeNTldPeRWVkBf8dqkpzah8SoG NTJFV7Jyxa7DP5Tv+dkyitTKud3dMGuAGV2CqUOhRX6kE2Kk1qnz0ngQbcEHK7HW bEh84z8QqlAvc8z00AV6eqS/K8QXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgeeigdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeffrghv vgcuvehrohgtkhgvrhcuoegutghrohgtkhgvrhessggsihifrdhnvghtqeenucggtffrrg htthgvrhhnpedtvdefudegheejgfdvffffleelgeduffetvdeujeekueevieeludefhffg vefhjeenucffohhmrghinhepsggsihifrdhnvghtnecukfhppedutdekrddvvdeirdduie dvrdeifeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegutghrohgtkhgvrhessggsihifrdhnvght X-ME-Proxy: Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 158553280064 for ; Tue, 21 Jul 2020 14:05:45 -0400 (EDT) To: IETF DMARC WG References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 21 Jul 2020 11:05:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 18:05:50 -0000 On 7/21/2020 10:58 AM, Dotzero wrote: > > > On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker > wrote: > > The mail is not spoofed.  Consider the definition of the word. Then > consider that the MLM is authorized by the user with the address in the > original From field. > > This is an interesting statement and raises a question.. Does a user > have the authority to authorize (some) use of a domain in a manner > contravening the express statement (p=reject) of the domain > owner/administrator? I'm going to have to say no. The user is authorized to use that address. The problem here is not 'spoofing' but rather an internal personnel problem, with the user not adhering to the policies of the organization that authorized the user. For this case, DMARC externalizes that internal personnel problem. But it does not fit the definition of "spoofing". > > Also then consider that the existing MLM behavior has existed and been > useful for roughly 45 years. > > Slavery existed for a long time (still does in some places) and was > useful (for some) for a long time. Things change and evolve. > > The problem, here, is DMARC's imposing a change in email semantics. > > > If that is the problem, why did you participate in the original DMARC > effort? The issue was clear even back then. The original DMARC effort was, in fact, to detect actual cases of spoofing, namely unauthorized use of a domain name by outside actors. Different problem. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 21 11:08: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 3EBF73A0D5F for ; Tue, 21 Jul 2020 11:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=SQa+TTgS; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=mU2RqoPe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XkOOZCcsqi0 for ; Tue, 21 Jul 2020 11:08:00 -0700 (PDT) Received: from mail.winserver.com (mail.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 B454B3A0D57 for ; Tue, 21 Jul 2020 11:08:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2568; t=1595354871; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7YImzlByKjMvmt+TQ3E25qJipGk=; b=SQa+TTgSUEWjMuxVjpF0rlyZwbzn8q/X5TT+XerZ0pr6XvNT9EiGk0KXOpouEU CfvIx5JthfQUblxo7gTvyqNo2ULK5OhwgLCJ2veqbIkWjmhktX5dmDwc2kbaZTMQ w9z6qTn0nKqcoi0AVoFwFax2g+bYy9yYB/jRwXsiCyM+E= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 21 Jul 2020 14:07:51 -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 1787170166.1.6332; Tue, 21 Jul 2020 14:07:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2568; t=1595354770; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QwOqwSo 9hD60BqopCzBRHt40EnttiLeDRVDupL+U/dw=; b=mU2RqoPe48n6IZ1/t6i4gI2 Y+c6mgkyIVZR5/8UkzibZCeb5ly9qqKsjD0Duct+ZvqrveJPBQxMZgnfC7ZhQd7v xgg1cVIJaaWNR/kymAwuvA8MKinI2lzZFbA/VMucyNGrOVXhDm//IDvumfXE4jQg 3hpfuzgVFa8suuFH/Sv0= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 21 Jul 2020 14:06:10 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1497945453.1.30156; Tue, 21 Jul 2020 14:06:09 -0400 Message-ID: <5F172EF5.7000508@isdg.net> Date: Tue, 21 Jul 2020 14:07:49 -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: dcrocker@bbiw.net, Jesse Thompson , dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 18:08:03 -0000 On 7/21/2020 11:51 AM, Dave Crocker wrote: > Also then consider that the existing MLM behavior has existed and been > useful for roughly 45 years. > > The problem, here, is DMARC's imposing a change in email semantics. Dave, there are different ways of looking at this. I've work with and developed MLM/MLS for as many years, and there are "mail engineering ethics" here to consider. The first is Mail Tampering, which is part of 1986 US ECPA guidelines, Mail Tampering was an exception, not a rule, with the MLM/MLS to allow for body changes. This was not a normal expectation except to allow a very basic overhead level with headers/footers. Absolutely no tampering with the context, the "gist" of the copyrighted messages, is never expected to be altered. It was never expected for the Author field to be changed unless you had a digest or something like it where clearly the mail was not coming from you. In general, it would have been a US ECPA violation. It was not something you often seen done, if ever. The Newspaper Publisher industry is the only industry where legal concept of "Print To Fit" was acceptable for 100+ years. But if a MLM/MLS is considered a publisher, would it be exempt? Even then, the From is not changed in your letter to the editor. Second, DMARC is imposing a new security protocol based on the premise the "From" is not expected to be changed. How will the MLM/MLS fit? It can: 1) Supports the security protocol and the problem is solved. Exclusive domains made a published policy statement for exclusive signing. The Exclusive Domains does not expect its users to be using their domains outside the work place. The policy is honored. 2) Unintentionally ignorant of the security protocol, does nothing. This is your true legacy system. 3) Intentionally ignorant of security protocol while continue to resign mail. This is not a legacy system if it has adapted to resign mail and chose to neglect and ignore the security protocol. 4) Same as #3 but also rewrites From field. #1 and #4 will resolve the problem. The proper protocol engineering fit is with #1. While #4 resolves the issue, it is perpetuating an undesirable design that can have serious mail engineering consequences simply by watering down the value of persistent 5322.From. The #2 and #3 MLM/MLS will be remain as problems until they change or the user is made aware he can't use his exclusive domain on a public forum. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 21 12:09: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 A270C3A07F0 for ; Tue, 21 Jul 2020 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx0ajDmPpx3A for ; Tue, 21 Jul 2020 12:09:02 -0700 (PDT) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 EDE753A07F2 for ; Tue, 21 Jul 2020 12:09:01 -0700 (PDT) Received: from pps.filterd (m0167074.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06LJ0j0g001086 for ; Tue, 21 Jul 2020 15:09:01 -0400 Received: from sendprodmail11.cc.columbia.edu (sendprodmail11.cc.columbia.edu [128.59.72.19]) by mx0b-00364e01.pphosted.com with ESMTP id 32bt4epehc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Jul 2020 15:09:00 -0400 Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by sendprodmail11.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06LJ8x6F010140 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 21 Jul 2020 15:09:00 -0400 Received: by mail-io1-f69.google.com with SMTP id k10so14043992ioh.22 for ; Tue, 21 Jul 2020 12:09:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c6QTbE2R5wajgOTvIpxx5/9qLq6wQESZHYQDc++/OcE=; b=onUD6AnnN0Jnd949LNl3Rjblc7bBweBOUjUAQSmqlKENZyRigmxjvffbNAFFQ7lZ0i hd83+715+ATNU1++ZHMSzCBfNsLvEKdWHGQCrk0lPqdwAuavxc8L3GHuxueDIjistqu4 Zd7iHh8U5jfhXZESSgm19p2oHG1S0d6nS2I126gLc4XwtGAW5gK+uJTaCWsmky3nukdn Bs5NbcwCvlxGF1rHnv2OtVQwOOmMY431PziCS/PUPDauKwyerb8/ChwWFYA6S3SbmfmI 5J3kBWogWO+CTYkLZtqyLaZrGoF4J9wtMln/Z6WBvc+USmjLwBHEDvXRTDgafZsYIEDH LqXg== X-Gm-Message-State: AOAM531DwREhPL4uIMrhHyCMkHHoIZFf8n3/1ungSAHKM0PhB6ZLEKLM 3Hf7wBNbTvT/tSTgDfxWqWRh0EfZYFIu6aRiAHkhuaHcdK7kDN0Inp6xIAu2Prx544XRNurYMMS kfTRr5Dzeh83FqfrFWcUqcY2h4OaFpQ== X-Received: by 2002:a05:6638:11cb:: with SMTP id g11mr32528960jas.14.1595358539483; Tue, 21 Jul 2020 12:08:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxocVI2FaEOUIbPvhLMpnaI7fOIIVY2GkDwTbf9Z3R+MFc5tT4EY5WlrP1JyrqjO7wyqekwiF0sPpmsyk8AxIk= X-Received: by 2002:a05:6638:11cb:: with SMTP id g11mr32528933jas.14.1595358539070; Tue, 21 Jul 2020 12:08:59 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> In-Reply-To: From: Joseph Brennan Date: Tue, 21 Jul 2020 15:08:48 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-21_14:2020-07-21, 2020-07-21 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 19:09:04 -0000 On Tue, Jul 21, 2020 at 1:28 PM Brandon Long wrote: > > Do sms/mms programs show the phone number any more? I think there's been a deliberate strategy to make email clients more like > other messaging clients, and the technical parts like the actual address are details that most of the time aren't useful to the user... when > they're not being spoofed, of course, or otherwise need to differentiate between multiple addresses for the same person. > - I think you're right about how non-email messaging clients have influenced email. But even in email, Microsoft's Outlook, with its roots as an intraoffice memo client, has shown only display name as far back as I know, except when Internet mail comes in with a From header that has no display name to show. For all its quirks, Outlook is the only client I can think of that shows the content of the RFC5322 Sender header, even if it is in the peculiar "x on behalf of y" notation, which shows display name when there is one and address otherwise. But we are digressing into a proposal for an Internet Email Client standard. Joseph Brennan Lead, Email and Systems Applications From nobody Tue Jul 21 12:30:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B8D3A083B for ; Tue, 21 Jul 2020 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kso3fKP9tBd for ; Tue, 21 Jul 2020 12:30:05 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 3D4EB3A0839 for ; Tue, 21 Jul 2020 12:30:05 -0700 (PDT) Received: from pps.filterd (m0167071.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06LJDvdx023028 for ; Tue, 21 Jul 2020 15:30:04 -0400 Received: from sendprodmail11.cc.columbia.edu (sendprodmail11.cc.columbia.edu [128.59.72.19]) by mx0a-00364e01.pphosted.com with ESMTP id 32bx1nhfaj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Jul 2020 15:30:04 -0400 Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by sendprodmail11.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06LJU3ci023145 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 21 Jul 2020 15:30:03 -0400 Received: by mail-io1-f69.google.com with SMTP id l1so14010967ioh.18 for ; Tue, 21 Jul 2020 12:30:03 -0700 (PDT) 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=Qs8Cag+r/XIRl11fQ7QXGjT1bYFY20owEUW7Pra54nk=; b=dzb73lQwAqvESJsD550+d94Syv9jNUf6KXFykV9nXJ9+lE6IM6xGLg3sFzZXMGoh57 uXsblpFntLZdtonG2qJhczdaSUybzA5KR3kuePIWAP2+VWOWRn1lh3RddMTaBqeWmE2o MrRpOKo5eUsXPT/KMkWHilFFO2yUywEj8YHZLRb6z6XWP02k/IH2vAXog9t2myt+cTWx 0yx24rh1QA8o/Ty6V7mHgUL7bMb0fWhh+Jxwc77TKP0MOs4dmXr4+Kp5TFBE3oq8pjDh LCox+A1ER/L0oOzT2JGCTN28HCQ8aPibnJXyrcXaU/Ohj01Eol12gQV2FHJdK2fKbi4h Rj8A== X-Gm-Message-State: AOAM530vbUhcwQceMZgok40ObBD8FHP7iVVs7y/ST3LlMJ5iBOyGwspy emL6VE56OfOslqvGzPnadrVWlJVQqC+ou+YhywAo3b6RaqT50POaZIH9/sk9M81TvT0D7sU7bU0 rKfu//N16a1ddHQlssroissNQ0QJXWA== X-Received: by 2002:a92:c525:: with SMTP id m5mr28374892ili.67.1595359803031; Tue, 21 Jul 2020 12:30:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJjdZDqTcw8/tD7ReI5ce8OqdSi/O32TN/PAyKKX58mTZFOza8Qg7Qn3Gp5rmwGnDu11OduUwW77nzAUJ50Zc= X-Received: by 2002:a92:c525:: with SMTP id m5mr28374867ili.67.1595359802613; Tue, 21 Jul 2020 12:30:02 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <5F172EF5.7000508@isdg.net> In-Reply-To: <5F172EF5.7000508@isdg.net> From: Joseph Brennan Date: Tue, 21 Jul 2020 15:29:51 -0400 Message-ID: To: hsantos@isdg.net Cc: dcrocker@bbiw.net, Jesse Thompson , IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-21_14:2020-07-21, 2020-07-21 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 19:30:06 -0000 On Tue, Jul 21, 2020 at 2:08 PM Hector Santos wrote: > > Second, DMARC is imposing a new security protocol based on the premise > the "From" is not expected to be changed. How will the MLM/MLS fit? > > It can: > > 1) Supports the security protocol and the problem is solved. > Exclusive domains made a published policy statement for exclusive > signing. The Exclusive Domains does not expect its users to be using > their domains outside the work place. The policy is honored. My understanding of DMARC's purpose was to protect transactional messages from sources like banks, credit card issuers, online shopping venues, and the like. It supposed that those messages should pass only directly from the source to the end point, and that that was so important to security that transport through any intermediary should be rejected as possible forgery. For example my bank statements come from a different domain than mail from a person at the bank. What blew it away was Yahoo's implementation of DMARC on end user personal mail. It was at first believed by many that Yahoo would have to roll it back when their users could not contribute to mailing lists or send mail to people who had old-school forwarding. Instead the industry started developing ways to get around DMARC by changing RFC 822 From headers and RFC 821 MAIL commands... which pretty much un-did the DMARC concept of authorization. It has been demonstrated that #1 is not happening, and it's because sheer deliverability of legitimate email is the priority. -- Joseph Brennan Lead, Email and Systems Applications From nobody Tue Jul 21 12:32:26 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 0FA043A0841 for ; Tue, 21 Jul 2020 12:32:24 -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 BhtffvZUDjsh for ; Tue, 21 Jul 2020 12:32:22 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878CC3A0840 for ; Tue, 21 Jul 2020 12:32:22 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 184so4017841wmb.0 for ; Tue, 21 Jul 2020 12:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cfjIiLl1B2w8HO8nRHZZXu+iM6eOUiHKOl9u5odMh/g=; b=Gn2q6gMLNNyhIs8JSJrerb/aO63RJQEkMnsz8QHYOTCoAtwjeOZNTp00K+Dg9/cjDx uSziwtv8UB4gXC3X//1NRE5MED8doXPd3+mMhkeK2ZX4VSKBToEqRipKPjQJy3141wt1 9rTcAAoUxKvhQLg4QyCoWsPxLng6IStYD8FH1fqdOKxQVKtIBDwO+w1+V/n//MkE1l3V hJ3015KCqEJHtsLDa/TWoZ7LnIEJaTDbAn12j34T4FtX1uEVhpGWNh7j3MH+yYJuZPhi xPGdpR+ircGX95cpTrcmQlsuwG0+lPiqyitit6nfNHrdQ9nLnOLNa83KZyFvYIFmBfeH vBCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cfjIiLl1B2w8HO8nRHZZXu+iM6eOUiHKOl9u5odMh/g=; b=BQ4FuIXsePvrOFQGHGX4lUAmdy72NfGdWSz2bREjZqSpAnTYmtSFz1oxPUukjV94aE AhNhETUnELYanSdIMBr8NbgJ+enX9MOxtvHS+CsPY16kNbmBcmMjkEIV9W7STf2PyJNM 62UtHXM+tl6ocVsT2JS9zSxc7bilsQ2zefHxYYTDYlakQAUacocysC/PjnrnnCY+ntss gH2XBF4dk1AOqtokjd3AWdS9rEyoTmHPIYLETakZgHLALR+jCaoj/VfoycQKoc0LJGk2 Ol6W7KUPk+W6fcMQWKCPOFrDK/HKf4zSFq/bJKHja32+wy4maFZRFlytx2KMWVMR/8du K6QQ== X-Gm-Message-State: AOAM533WwlZeLHfQvtjzbySzFk9JfFa3FoM3eG0vvoXcmVGWzC+U2Mw0 5qemSbIRVMf3pNgpCxoYR4OkI6Hagc9ZoqfKaq9HmCpq X-Google-Smtp-Source: ABdhPJwxyIk5qqHDn0bI7KwNwi+AoZJrLVO67rndXGCmxBiwG+0Fxd+mjrfBXiMFIaBrZa7MZmD8hlAurXKdqiJF3Uk= X-Received: by 2002:a7b:c841:: with SMTP id c1mr5732042wml.25.1595359940587; Tue, 21 Jul 2020 12:32:20 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Tue, 21 Jul 2020 15:32:08 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008c350205aaf8ae9a" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 19:32:24 -0000 --0000000000008c350205aaf8ae9a Content-Type: text/plain; charset="UTF-8" On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker wrote: > On 7/21/2020 10:58 AM, Dotzero wrote: > > > > > > On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker > > wrote: > > > > The mail is not spoofed. Consider the definition of the word. Then > > consider that the MLM is authorized by the user with the address in > the > > original From field. > > > > This is an interesting statement and raises a question.. Does a user > > have the authority to authorize (some) use of a domain in a manner > > contravening the express statement (p=reject) of the domain > > owner/administrator? I'm going to have to say no. > > The user is authorized to use that address. The problem here is not > 'spoofing' but rather an internal personnel problem, with the user not > adhering to the policies of the organization that authorized the user. > > For this case, DMARC externalizes that internal personnel problem. > > But it does not fit the definition of "spoofing". > > Please note that I did noy use either the word "spoof" or "spoofing". You wrote "MLM is authorized by the user". Someone without authority cannot authorize. In this case the user externalized the problem, not DMARC. > > > > > Also then consider that the existing MLM behavior has existed and > been > > useful for roughly 45 years. > > > > Slavery existed for a long time (still does in some places) and was > > useful (for some) for a long time. Things change and evolve. > > > > The problem, here, is DMARC's imposing a change in email semantics. > > > > > > If that is the problem, why did you participate in the original DMARC > > effort? The issue was clear even back then. > > > The original DMARC effort was, in fact, to detect actual cases of > spoofing, namely unauthorized use of a domain name by outside actors. > > Different problem. > Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops. Michael Hammer --0000000000008c350205aaf8ae9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2020= at 2:06 PM Dave Crocker <dcrocker@= bbiw.net> wrote:
On 7/21/2020 10:58 AM, Dotzero wrote:
>
>
> On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker <dhc@dcrocker.net
> <mailto:dhc@d= crocker.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0The mail is not spoofed.=C2=A0 Consider the definit= ion of the word. Then
>=C2=A0 =C2=A0 =C2=A0consider that the MLM is authorized by the user wit= h the address in the
>=C2=A0 =C2=A0 =C2=A0original From field.
>
> This is an interesting statement and raises a question.. Does a user <= br> > have the authority to authorize (some) use of a domain in a manner > contravening the express statement (p=3Dreject) of the domain
> owner/administrator? I'm going to have to say no.

The user is authorized to use that address.=C2=A0 The problem here is not <= br> 'spoofing' but rather an internal personnel problem, with the user = not
adhering to the policies of the organization that authorized the user.

For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "= spoof" or "spoofing".=C2=A0 You wrote "MLM is authorize= d by the user". Someone without authority cannot authorize. In this ca= se the user externalized the problem, not DMARC.
=C2=A0

>
>=C2=A0 =C2=A0 =C2=A0Also then consider that the existing MLM behavior h= as existed and been
>=C2=A0 =C2=A0 =C2=A0useful for roughly 45 years.
>
> Slavery existed for a long time (still does in some places) and was > useful (for some) for a long time. Things change and evolve.
>
>=C2=A0 =C2=A0 =C2=A0The problem, here, is DMARC's imposing a change= in email semantics.
>
>
> If that is the problem, why did you participate in the original DMARC =
> effort? The issue was clear even back then.


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of th= e effort was to enable Sending domains to identify their own mail that was = being sent without aligned DKIM signing or from places not authorized throu= gh SPF - in other words, not properly authorized but legitimate, hence feed= back loops.

Michael Hammer
--0000000000008c350205aaf8ae9a-- From nobody Tue Jul 21 12:45: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 0F5F43A08AA for ; Tue, 21 Jul 2020 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 tsDe3ba1f4G2 for ; Tue, 21 Jul 2020 12:45:15 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A443F3A08A9 for ; Tue, 21 Jul 2020 12:45:15 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id h1so24113otq.12 for ; Tue, 21 Jul 2020 12:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3zDKn3GDieUPhCHTZo4j4BT78zHuaFXEuCcMSpGpib8=; b=egy/J+VIpRu7jQVA2ZLxNZJZTpsNvi3TovhRueJiVNA/EFaP0bn2mU6gKrKW/M5qrI Jf5n3IDDVgWXVtBLmklDwixan8k/3y5U1vwMJSleAOzH9bXHk/ocu1NJpJu5a2eGNrTk x0tfa29AdfNDhPF5740JfByEntm0u1jzVoAx/6yIid2rkOknsUrUw+V7Rq7smIlX+bHQ pFVaKnK3xiySdFN6KDb6/eU2tySuL1QOrjpm/6oWr4QQvYnFeuqcFRwR5IOWT/Zt2BKw 3PpsWgrsMQ1kSiv+Oln2ZTO1IbEP/eJTh6VYR8uF7pdG/I7noF5deJvpsWeKO48jUJI4 l0qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3zDKn3GDieUPhCHTZo4j4BT78zHuaFXEuCcMSpGpib8=; b=Uia9dXWCAAUnnSpYx62m/H120b1VrrWMqVm4tCpaYxl8Gdum5ZQg7ELoIDw8mLsz5w 8z6KkKZ1/nmTnilXPqHCWeC8vMYe/8UwjdLkPVzj6e0yirbfodqS3r4xtTAYMSJEA/NO v2Ma0gPVWQZkvWtETs3N2FBzAWvdRkt6t2I9IJUt4SFqIOdFNL6FAKOxRi62EBAFWJAm TiPo6yzP0itYdi6eSU3F9FY8tha1Arf48mjafRH4B9kj2ZN3bkDMnLeC9nRLZMtAsa0X c9QjMjMEBrZt69c66p5sARXXe9pTrfZnQrzLQhW9sGuwt0Lfc21hTIktYJDD/1eP6BKJ GAIw== X-Gm-Message-State: AOAM532sz7QTifR7HQdHSI/Fle07jjkFOJNxMFwlMbIbhesFUTKHtf9g 3rvKwV+c17ru7z9oeyuw/2JbTfB4oOo= X-Google-Smtp-Source: ABdhPJxvUSgARBuXLoRG99NSJHHmcTwfKxbPHRlWfssbG5YWhKwks1q2QIUgduFDzJYRVTrqIP4zHg== X-Received: by 2002:a9d:27e6:: with SMTP id c93mr26604327otb.157.1595360714737; Tue, 21 Jul 2020 12:45:14 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:e05e:30a7:6377:adad? ([2600:1700:a3a0:4c80:e05e:30a7:6377:adad]) by smtp.gmail.com with ESMTPSA id z2sm4831721oix.3.2020.07.21.12.45.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jul 2020 12:45:14 -0700 (PDT) To: Dotzero References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> From: Dave Crocker Cc: IETF DMARC WG Message-ID: <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> Date: Tue, 21 Jul 2020 12:45:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------41EE15DA757E339C92755F68" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 19:45:17 -0000 This is a multi-part message in MIME format. --------------41EE15DA757E339C92755F68 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/2020 12:32 PM, Dotzero wrote: > > > On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker > wrote: > > On 7/21/2020 10:58 AM, Dotzero wrote: > For this case, DMARC externalizes that internal personnel problem. > > But it does not fit the definition of "spoofing". > > Please note that I did noy use either the word "spoof" or "spoofing".  > You wrote "MLM is authorized by the user". Someone without authority > cannot authorize. In this case the user externalized the problem, not > DMARC. That's simple incorrect. I give you my credit card, telling you to use it only for gasoline purchases while running errands for me.  You take the car on a cross-country joyride, running the cc charges for gasoline up.  The stations that  charged the gas to the card did nothing wrong.  The problem is internal, between you and me. The MLM's did not do any spoofing.  They acted appropriately, as they have for 45 years. If the domain owner has a problem with the user's behavior, that's internal, between the domain owner and the user. Using language that casts the MLM as doing something wrong is a fundamental misrepresentation of the situation. > > If that is the problem, why did you participate in the original > DMARC > > effort? The issue was clear even back then. > > > The original DMARC effort was, in fact, to detect actual cases of > spoofing, namely unauthorized use of a domain name by outside actors. > > Different problem. > > > Actually, part of the effort was to enable Sending domains to identify > their own mail that was being sent without aligned DKIM signing or > from places not authorized through SPF - in other words, not properly > authorized but legitimate, hence feedback loops. > This was a point of significant confusing during the initial effort. It is not reasonable to impose a substantial and permanent cost on the external internet, for an organization's inability to monitor and regulate behavior within the organization. Whereas it is entirely reasonable to have a standard that facilitates detecting externally-generated traffic that has unauthorized use of a domain name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------41EE15DA757E339C92755F68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/21/2020 12:32 PM, Dotzero wrote:


On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <dcrocker@bbiw.net> wrote:
On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "spoofing".  You wrote "MLM is authorized by the user". Someone without authority cannot authorize. In this case the user externalized the problem, not DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline purchases while running errands for me.  You take the car on a cross-country joyride, running the cc charges for gasoline up.  The stations that  charged the gas to the card did nothing wrong.  The problem is internal, between you and me.

The MLM's did not do any spoofing.  They acted appropriately, as they have for 45 years.

If the domain owner has a problem with the user's behavior, that's internal, between the domain owner and the user. 

Using language that casts the MLM as doing something wrong is a fundamental misrepresentation of the situation.


> If that is the problem, why did you participate in the original DMARC
> effort? The issue was clear even back then.


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.

This was a point of significant confusing during the initial effort. 

It is not reasonable to impose a substantial and permanent cost on the external internet, for an organization's inability to monitor and regulate behavior within the organization.

Whereas it is entirely reasonable to have a standard that facilitates detecting externally-generated traffic that has unauthorized use of a domain name.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------41EE15DA757E339C92755F68-- From nobody Tue Jul 21 13:43: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 9B2BA3A09E9 for ; Tue, 21 Jul 2020 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hff-BMJnQe6R for ; Tue, 21 Jul 2020 13:43:01 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EB63A09E8 for ; Tue, 21 Jul 2020 13:43:01 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id e15so11121986vsc.7 for ; Tue, 21 Jul 2020 13:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UVCJPhzddx0lRy4o+7J7hHqH8e5TZNGveW7yoqDDpYM=; b=dVK9y8TIybf35Xz4mt+nC6PK7LS06dg07Ch3Kj6WrGMSMAV1Vk7rYFQ0KqkGc1Kwp2 xzlbZN9+4ajdJJX3Rb4bZIdlApM5E+aSB6YoAxQbC7Qp7DtU935nF3vKI36OJ9jF9Kx8 Whcirg22NdGWcmcFSf+yRcwMo4JRjez0KS9pmAwGuJjWC4AJKJIfntnS5vF1AaCKokuB qzQkv0a4TS6sMJQHXp8Ju59PhAYz7NOsfVnTLbi1n8voDkwP1eeR6fn/ImZ+erZodZkv I0u1ORyIacC02S0soSvatdelRhULLHuhsweMmXA+zOYqc6loJkZtLJUoGTKF6k2StbRc QaNA== 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=UVCJPhzddx0lRy4o+7J7hHqH8e5TZNGveW7yoqDDpYM=; b=Mw5ppMSiOwxo7UyZKwMTotu6wyKyDZ5gvLmFKM5fnAob0OZgrlRjXBhtN21hfF+l8/ RXvfce/6mN9eZW88h37C6Oeqq1Qd1eaJSg1zNpN3E+12rnbpfNEjsphcmOIuwyHoEt9P 9wOoiFi9OVJGu39MMNaV02AqFRBeqA2/hsV2jcPF9STpgTL+rHKhVUsPmBZUH0yofvL4 rvIW4OscuzBp6yC93ycIRTv/k9lMaAVk5HBwOqD1QfNJOeBJ0VQx3NvlG+PIJYTznlFn bWcM6IXkDelinJH8qA/AxbruKvP/FU+mBdXQQtwZNEGyyfAIj6N6SIb3USIv1BPfgooA pVxw== X-Gm-Message-State: AOAM53373NmLmFyq2LwLqAzyKeOCR1Zgb+f19sNXanokHdq9VL5Be31W 3227IYEtzYS5OhprepGNA/5GQ05tVBoGUp+LdL16 X-Google-Smtp-Source: ABdhPJx6d6HmY6iIF22z+voxFMtaOafcYQiDSLWcZYBoFEA1ZOVqDWC065sNa9IPBvFTna9Ftp3G4Fe7YXU7+GYGT8s= X-Received: by 2002:a67:643:: with SMTP id 64mr22206885vsg.32.1595364179893; Tue, 21 Jul 2020 13:42:59 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> In-Reply-To: <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> From: Brandon Long Date: Tue, 21 Jul 2020 13:42:47 -0700 Message-ID: To: Dave Crocker Cc: Dotzero , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003b561a05aaf9abd2" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 20:43:03 -0000 --0000000000003b561a05aaf9abd2 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 21, 2020 at 12:45 PM Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: > > > > On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker wrote: > >> On 7/21/2020 10:58 AM, Dotzero wrote: >> For this case, DMARC externalizes that internal personnel problem. >> >> But it does not fit the definition of "spoofing". >> >> Please note that I did noy use either the word "spoof" or "spoofing". > You wrote "MLM is authorized by the user". Someone without authority cannot > authorize. In this case the user externalized the problem, not DMARC. > > That's simple incorrect. > > I give you my credit card, telling you to use it only for gasoline > purchases while running errands for me. You take the car on a > cross-country joyride, running the cc charges for gasoline up. The > stations that charged the gas to the card did nothing wrong. The problem > is internal, between you and me. > > The MLM's did not do any spoofing. They acted appropriately, as they have > for 45 years. > > If the domain owner has a problem with the user's behavior, that's > internal, between the domain owner and the user. > > Using language that casts the MLM as doing something wrong is a > fundamental misrepresentation of the situation. > Yahoo Groups, at least at the time I worked on it, allowed moderators to edit the message before approval. The full scope of that certainly allowed the moderators to effectively spoof the poster. That said, sure, we're not talking about spoofing. We're talking about message changes that prevent strict signature verification. There is nothing in what MLM does that prevent much stronger changes than would be considered expected by the MLM. Stricter validation is not an uncommon addition to protocols over the last 45 years. I'd be curious when MLMs modifying the mail going through them became a thing, I guess I assume it wasn't 45 years ago, but I know it's irrelevant. Brandon --0000000000003b561a05aaf9abd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 21, 2020 at 12:45 PM Dave= Crocker <dcrocker@gmail.com&g= t; wrote:
=20 =20 =20
On 7/21/2020 12:32 PM, Dotzero wrote:
=20


On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <dcrocker@bbiw.net> wrote:
On 7/21/2020 = 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".
Please note that I did noy use either the word "spoof= " or "spoofing".=C2=A0 You wrote "MLM is authori= zed by the user". Someone without authority cannot authorize. In this case the user externalized the problem, not DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline purchases while running errands for me.=C2=A0 You take the c= ar on a cross-country joyride, running the cc charges for gasoline up.=C2=A0 The stations that=C2=A0 charged the gas to the card did not= hing wrong.=C2=A0 The problem is internal, between you and me.

The MLM's did not do any spoofing.=C2=A0 They acted appropriatel= y, as they have for 45 years.

If the domain owner has a problem with the user's behavior, that's internal, between the domain owner and the user.=C2=A0

Using language that casts the MLM as doing something wrong is a fundamental misrepresentation of the situation.


Yahoo Groups, at least at the time I worked on it, all= owed moderators to edit the message before approval.=C2=A0 The full scope o= f that
certainly allowed the moderators to effectively spoof the = poster.

That said, sure, we're not talking abo= ut spoofing.=C2=A0 We're talking about message changes that prevent str= ict signature verification.
There is nothing in what MLM does tha= t prevent much stronger changes than would be considered expected by the ML= M.

Stricter validation is not an uncommon addition= to protocols over the last 45 years.

I'd be c= urious when MLMs modifying the mail going through them became a thing, I gu= ess I assume it wasn't 45 years ago, but I know it's irrelevant.

Brandon=C2=A0
--0000000000003b561a05aaf9abd2-- From nobody Tue Jul 21 13:43:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4793A0A6D for ; Tue, 21 Jul 2020 13:43:09 -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 kyEtqREAS9VE for ; Tue, 21 Jul 2020 13:43:07 -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 F0CE43A09FB for ; Tue, 21 Jul 2020 13:43:06 -0700 (PDT) X-ASG-Debug-ID: 1595364184-11fa3107a843390001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id gDusC5AVEkLeN6hb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 21 Jul 2020 16:43:04 -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=0DBhq8bhJZTYZkVuhtPDmeiRhhv6JGmErwbogTPExtA=; b=OCYMz5sa9cJrTANmIYs7mddX0j+RpIHvpSoFXwSbUNScqyYIkC4YgpTnQA5wHyrTq PsaqvD3AXwWIZ3w5UEGaJXuzN6DdnxkJ8rgZjRAnQr6MJdIHMXV4/yyTlZKYrhqGT hP9p8JpzUzj/lwpgA3OLrPYNpLibFu0ibVCNTESL8= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Tue, 21 Jul 2020 20:42:57 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=cde1f7d77221471fa7b76aa7b2dfef1d In-Reply-To: <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> X-Exim-Id: a6cf105db046455092e05e74308950ed X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595364184 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: 8140 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.83362 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 20:43:15 -0000 This is a multipart message in MIME format. --cde1f7d77221471fa7b76aa7b2dfef1d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Your credit card scenario is one legitimate way of viewing the problem. I= have also been thinking about a credit card scenario, but coming to a diff= erent conclusion: For many years, Bill Smith has been using the credit card of his sister-in-= law, Tracy Jones. This is an informal arrangement because Bill does not w= ant a card of his own. He faithfully pays Tracy for all of his charges. = No cashier has ever asked Bill for any ID other than his credit card. Suddenly, the bank reissues all cards with photos, in an attempt to reduce = card fraud. Cashiers begin looking at the photos and will not let Bill us= e Tracy's credit car anymore. Bill cries foul because he has the cardhold= er's permission. Bill has the trust of Tracy, but he does not have the t= rust of the bank, and as a result, he does not have the trust of the retail= clerk. Should the bank remove those photos to accommodate Bill? DF ---------------------------------------- From: Dave Crocker Sent: 7/21/20 3:45 PM To: Dotzero Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author= -00 security considerations On 7/21/2020 12:32 PM, Dotzero wrote: On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker wrote: On 7/21/2020 10:58 AM, Dotzero wrote: For this case, DMARC externalizes that internal personnel problem. But it does not fit the definition of "spoofing". Please note that I did noy use either the word "spoof" or "spoofing". You = wrote "MLM is authorized by the user". Someone without authority cannot aut= horize. In this case the user externalized the problem, not DMARC. That's simple incorrect. I give you my credit card, telling you to use it only for gasoline purchase= s while running errands for me. You take the car on a cross-country joyrid= e, running the cc charges for gasoline up. The stations that charged the = gas to the card did nothing wrong. The problem is internal, between you an= d me. The MLM's did not do any spoofing. They acted appropriately, as they have = for 45 years. If the domain owner has a problem with the user's behavior, that's internal= , between the domain owner and the user. Using language that casts the MLM as doing something wrong is a fundamental= misrepresentation of the situation. > If that is the problem, why did you participate in the original DMARC > effort? The issue was clear even back then. The original DMARC effort was, in fact, to detect actual cases of spoofing, namely unauthorized use of a domain name by outside actors. Different problem. Actually, part of the effort was to enable Sending domains to identify thei= r own mail that was being sent without aligned DKIM signing or from places = not authorized through SPF - in other words, not properly authorized but le= gitimate, hence feedback loops. This was a point of significant confusing during the initial effort. It is not reasonable to impose a substantial and permanent cost on the exte= rnal internet, for an organization's inability to monitor and regulate beha= vior within the organization. Whereas it is entirely reasonable to have a standard that facilitates detec= ting externally-generated traffic that has unauthorized use of a domain nam= e. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --cde1f7d77221471fa7b76aa7b2dfef1d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Your credit card s= cenario is one legitimate way of viewing the problem.   I have also be= en thinking about a credit card scenario, but coming to a different conclus= ion:

For many years, Bill Smith has been using the= credit card of his sister-in-law, Tracy Jones.   This is an informal = arrangement because Bill does not want a card of his own.    He f= aithfully pays Tracy for all of his charges.   No cashier has ever ask= ed Bill for any ID other than his credit card.

Sud= denly, the bank reissues all cards with photos, in an attempt to reduce car= d fraud.   Cashiers begin looking at the photos and will not let Bill = use Tracy's credit car anymore.   Bill cries foul because he has the c= ardholder's permission.    Bill has the trust of Tracy, but he do= es not have the trust of the bank, and as a result, he does not have the tr= ust of the retail clerk.

Should the bank remove th= ose photos to accommodate Bill?

DF

<= /div>

From: Dave Crocker <dcrocker@gmai= l.com>
Sent: 7/21/20 3:45 PM
To:= Dotzero <dotzero@gmail.com>
Cc: IETF DMARC WG &l= t;dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Response= to a claim in draft-crocker-dmarc-author-00 security considerations=
On 7/21/2020 12:32 PM, Dotzero wrote:<= /div>
<= div dir=3D"ltr">

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker <dcrocker@bbiw.net> = wrote:
On 7/21/2020 10:58 AM, Do= tzero wrote:
For this case, DMARC externalizes that internal personnel p= roblem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "s= poofing".  You wrote "MLM is authorized by the user". Someone without = authority cannot authorize. In this case the user externalized the problem,= not DMARC.

That's simple incorrect.=

I give you my credit card, telling you to use it only for gasoline p= urchases while running errands for me.  You take the car on a cross-co= untry joyride, running the cc charges for gasoline up.  The stations t= hat  charged the gas to the card did nothing wrong.  The problem = is internal, between you and me.

The MLM's did not do any spoofing.&n= bsp; They acted appropriately, as they have for 45 years.

If the doma= in owner has a problem with the user's behavior, that's internal, between t= he domain owner and the user. 

Using language that casts the MLM= as doing something wrong is a fundamental misrepresentation of the situati= on.


> If that is the probl= em, why did you participate in the original DMARC
> effort? The issue= was clear even back then.


The original DMARC effort was, in fac= t, to detect actual cases of
spoofing, namely unauthorized use of a doma= in name by outside actors.

Different problem.

<= /div>
Actually, part of the effort was to enable Sending domains to ide= ntify their own mail that was being sent without aligned DKIM signing or fr= om places not authorized through SPF - in other words, not properly authori= zed but legitimate, hence feedback loops.

<= /div>

This was a point of significant confusing during the i= nitial effort. 

It is not reasonable to impose a substantial and= permanent cost on the external internet, for an organization's inability t= o monitor and regulate behavior within the organization.

Whereas it i= s entirely reasonable to have a standard that facilitates detecting externa= lly-generated traffic that has unauthorized use of a domain name.

d/<= /p>


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--cde1f7d77221471fa7b76aa7b2dfef1d-- From nobody Tue Jul 21 14:14: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 108963A0A94 for ; Tue, 21 Jul 2020 14:14:28 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpLGEbtGzbxY for ; Tue, 21 Jul 2020 14:14:26 -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 2132D3A0A93 for ; Tue, 21 Jul 2020 14:14:26 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06LLGsWv015350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2020 14:16:55 -0700 To: Brandon Long Cc: IETF DMARC WG References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 21 Jul 2020 14:14:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C79F454FF71CD2340EBC1971" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 21:14:28 -0000 This is a multi-part message in MIME format. --------------C79F454FF71CD2340EBC1971 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/21/2020 1:42 PM, Brandon Long wrote: > I'd be curious when MLMs modifying the mail going through them became > a thing, I guess I assume it wasn't 45 years ago, but I know it's > irrelevant. When I said 45 years, I wasn't not kidding... The Subject line and the To: field were modified, here: > Date: 7 JUN 1975 1432-PDT > Sender: FARBER at USC-ISI > Subject: MSGGROUP# 001 TCTALK > From: FARBER at USC-ISI > To: MessageGroup: > Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER> > > > There is a distributed network teleconferencing facility oriented > to networks experimentally avilable called TCTALK. It was the > result of a thesis of Jim Calvin at BBN. It can be accessed at > the ISIA site via TCTALK. questions relative to it > can be answered by Calvin or Geoff at SRI-AI. I would recommend > that you try it if you have not. Improvements are being made on a > time available basis by Calvin. > > The full discription of TCTALK is available via the net and is in > essense Calvins CASE thesis. Contact CAlvin for that. > > Dave -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------C79F454FF71CD2340EBC1971 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7/21/2020 1:42 PM, Brandon Long wrote:
I'd be curious when MLMs modifying the mail going through them became a thing, I guess I assume it wasn't 45 years ago, but I know it's irrelevant.


When I said 45 years, I wasn't not kidding...

The Subject line and the To: field were modified, here:

Date: 7 JUN 1975 1432-PDT
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 001 TCTALK
From: FARBER at USC-ISI
To: MessageGroup:
Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER>


There is a distributed network teleconferencing facility oriented
to networks experimentally  avilable  called  TCTALK.  It was the
result of a thesis of Jim  Calvin  at  BBN. It can be accessed at
the ISIA site via  <network-help>TCTALK. questions relative to it
can be answered by Calvin  or  Geoff at SRI-AI. I would recommend
that you try it if you have not. Improvements are being made on a
time available basis by Calvin.

The full discription of TCTALK is available via the net and is in
essense Calvins CASE thesis. Contact CAlvin for that.

Dave

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------C79F454FF71CD2340EBC1971-- From nobody Tue Jul 21 14:45:14 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 96FD53A0AC2 for ; Tue, 21 Jul 2020 14:45:13 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XMiMGVYdvSfd for ; Tue, 21 Jul 2020 14:45:12 -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 07F763A0969 for ; Tue, 21 Jul 2020 14:45:11 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QDU00JH29R9T8A0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 21 Jul 2020 16:45:09 -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.7.21.213917, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.66.44] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D96iNa9z+HEg+dfWwfgVv3ytzC9AEE3vB9u8qcuHZ1zmnVapE5OFxfuzcm+aYyvuwU52sZx0XGeUuBrzNQNVdiarkxOU7X36ItmzAiPGm0WWMkXYpCpkbtNqujAJNMXJd9v6VLVl2jiWcmw7zw4GHMLS3gcxnFJgYwsQZONZQlkJqFYGHifLyJDOFDxa38lNxRAKO7IdrtI1eMsTE3Alt7QxKp2KUKvRsbJQwpWxmpRP0ml2MDstitB9x5GQbmgaTZCpBT7wcbQtSMln4mlJTVCkbmfTcab1vbYdKh/fbc4ZUluvA/L6gmMwzWBI/tnu0XF0JtEb3xhccAv8b6f66w== 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=ORNNzckZrT/xaG9fUe7nkFh3/fbkAS66jLYq4M51CCo=; b=Dq41I1ecegHVEqc42pz9HH1VEXZ06QPAu+7As3jH/1VnsN3BSy70Wkv8ORXKqUX+yu6jVnQkYN+aOgp3yDrTdrapUAPp17p067E8e4KrTSrUAwYCQcvT+/M1puLrhjpZSqPPUgsH6kynxBA4Bqt/hHHqrUciA0hxqoCv/uE39K5SmD2Fo3Y+UEhp+9uujFkAVHAyXwEzWzA/tM1LeUpml4u0svlE5O68hzbgKGsIhBNBt8emYdeLO30VFDaNbI7KNe0aK2g3w3/3gqPcJF6rMgRBouqXKxY9DPGGHgIPANhGmAV/kebDZukl/tj3AsGWl/+b8+6hGnDPq4mmYP8LYQ== 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=ORNNzckZrT/xaG9fUe7nkFh3/fbkAS66jLYq4M51CCo=; b=hEymQxkUYqylAsSBv6WeBqesrxeEbRDRMrF3VdJpAp7cU1fZApXif+hBP4Ah4dcj5QWjVkN8NtFYRFnB5FbQgcEe4z8kDAQdMlZyf+tBgBMGRMIggtoKgIzjhpDYczeaeHQTAZ1V6+myybOwG86jmx+zSlQ/PfrSLVDrhV5JRM0= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB3130.namprd06.prod.outlook.com (2603:10b6:4:3e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 21:45:08 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3195.025; Tue, 21 Jul 2020 21:45:08 +0000 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> From: Jesse Thompson Message-id: Date: Tue, 21 Jul 2020 16:45:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) 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 CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Tue, 21 Jul 2020 21:45:06 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b9ab6afc-879f-4494-a80b-08d82dbf5563 X-MS-TrafficTypeDiagnostic: DM5PR06MB3130: 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: I67piowZPaBgAaFFxfVvDU0fCoJvmbzr7zEmnZJw7R04RycTkejdT/UHdwm3SjTCb+n4xGx0FaYFIqd4tFcFDtt1sQonuR9q2sSx5lscwgZtJGfw/UYasXmdaqDUDi3h+BaYuI0LK/HQXEIjekvDc1hKFlvhg0oa7ZM2JW6+grKfqeOg2g+toPFXAiqv4RFoqzfMeu4H17lYPlgfA0+SnIR4V/l6AymZBfudYfyg/vgJ1NJmj3AYIB6Hjc48DE/4RaSV8DTeGiHXlkCXCrPmsn9YB5Gdb2ny2kkJc1E1MFRVFx84IrnDkmvnUNLeDxRrv4rhjlBXVCUJhbFbvgPu3XfZlxEAtPjcsRwG0mpnh/fr3bi0aPzVyj0pRt+7oBXx 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; SFTY:; SFS:(396003)(366004)(136003)(376002)(346002)(39860400002)(66946007)(66476007)(83380400001)(66556008)(75432002)(5660300002)(36756003)(6486002)(2906002)(316002)(8676002)(8936002)(2616005)(31696002)(31686004)(956004)(478600001)(16526019)(44832011)(26005)(186003)(53546011)(45080400002)(86362001)(786003)(6916009)(16576012)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: +sD3I9Wv8Ug5obayw7waAQfNigTETyUma+laCZR1S3tTqIsofHIv3+qpsE9lOJm1VaWrGAG33jO5830HVZBmNQrSDNmP38V1SkXZKDswqeGeacnwVrqEQn7Haehqlspg/dynCLTLrun1xPNJNVGaagWGXD/hxXZrfHITLpMtxM3XHzEsIRCCIdgUNvz43ZQL7/ADXzrfyBdL0C2A2blgq2dbdashMYaO2x+sdRvEqfsHEyISWrlGbaeCIgh9RWANkL3mSefYLGhKavWkyK9QPXue4VrTPp5ZrJ/IIFKFr8knWuh1jqG93xlLHh6TyEUHP8Qzz3XdgoEsiEsiu9IUAgrN2NVWXekqJ8Gj2RDBKgyZx1R88CSiriAQKV3SM7CapMWYXhpUdakTD8D633WYFo3VL2ufcb8GCzPo/VnwMtmKSwf4bTqPkOHt60yr7BgHi00AAQOrBJpvobW1s8f7axSdGOrtVAELI67ObadT9YE= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: b9ab6afc-879f-4494-a80b-08d82dbf5563 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 21:45:08.3923 (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: y8T0xYhTfJe4Y7PF5d7MGUNo07GGjlp0zVWwtMeFf2VfLHzQ0h4tkGJ1CGQaLgB+RkTuWbML2gU6S8I+gcbkwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3130 Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 21:45:14 -0000 On 7/21/20 6:05 AM, Douglas E. Foster wrote: > I would like a better understanding of why MUAs are hiding or removing the FROM address. > > I have one mail store that formerly used hover-to-view, but recently changed to always-show.   This was done in response to a client request on their support forum.  I have never seen a user ask for the From address to be hidden or removed.  I wonder if this trend is driven only by attempts to optimize display space.   It would be a shame to weaken our protocols in response to this trend, if the trend lacks a theoretical foundation. > > I also wonder if the trust indicator research is being over-applied when it is applied to the From Address.    From Address is a unique identifier, while Friendly Name is not.   A trust indicator is like putting a green check mark next to the From Address as a trust indicator.   They have different levels of relevance.    > > One attack method steals a contact list, then emails people in that contact list using friendly names of others in that list.   Hiding the From Address plays into that attack. > > This trust-indicator research also promotes despair.  The conclusion is that users process information poorly.   This result then becomes an excuse to withhold information from those users, or to allow misleading information to be presented to them.    I am not convinced that those are appropriate responses.   "Never" is a hard thing to prove.  So it is risky to say users "Never" use available information correctly, and "cannot be taught" to do better. > > Attack filtering is designed on a layered defense and a sequence of probabilities: > > * What is the probability that this attack will get through my spam filter? > * What is the probability that the user will read the message? > * What is the probability that the user will click on the hostile link? > * What is the probability that my web filter will allow access to the hostile website? > * What is the probability that the web filter will allow the attack to be downloaded? > * What is the probability that my antivirus program will allow the attack to proceed? > > The goal is to decrease the probability of a wrong decision at each point in the process.   All I need is for some people to act smarter on some occasions in response to some available clue.   But this cannot happen if the clue is not provided.. I like this way of thinking, and it seems like a good time to mention the following anecdote for the sake of the "end-users can't make security decisions" argument... Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address. It works because now the victims just see "wisc.edu.provost32@gmail.com" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on. I can count on one finger how many people have noticed that we're doing it (it wasn't an end-user, but it was our CRM team who uses friendly from to soft match on contacts) for a population of 150,000 mailboxes. Meanwhile, we get very few people claiming that we aren't somewhat mitigating BEC scams. Note that other institutions are tagging Subjects and bodies with EXTERNAL warnings, either to all external sourced email or based on some conditional rules, but they are not directly addressing the display name spoofing itself. I suspect that people learn to ignore those warnings over time and still fall victim to some well crafted scams from a spoofed VIP in their organization. I can't say with certainty which tactic works better (DKIM signature breakage is a wash), but I think forcing the MUA to reveal the sender's identity is more effective, less disruptive, and dovetails nicely with DMARC and the security marketing of the DMARC vendors. Jesse From nobody Wed Jul 22 06:23: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 67B5E3A0C20 for ; Wed, 22 Jul 2020 06:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1qNZnSsqq3o for ; Wed, 22 Jul 2020 06:23:50 -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 B10323A0919 for ; Wed, 22 Jul 2020 06:23:40 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06MDQDuT024521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Jul 2020 06:26:13 -0700 To: IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <9A436C27-CECC-46DD-B365-1FCF9366E64F@wordtothewise.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 22 Jul 2020 06:23:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9A436C27-CECC-46DD-B365-1FCF9366E64F@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 13:23:54 -0000 On 7/21/2020 1:08 AM, Laura Atkins wrote: > When we’re basing a protocol on “what the user sees” and “what the > user can trust” then I think we have to. DMARC says “users can trust > that mail from @domain.example is really from @domain.example” but if > the user never sees that, how do they know? I think this can be connected to the query about threats that DMARC is intended to respond to, by virtue of suggesting clarity about /where/ the responding takes place. My contention is that it takes place in a receiving filtering engine and does not take place at the user level. Further, it's one more data point in that engine's analysis process, rather than being in any simple way definitive. In any event, work here really should make a point of creating text that is clear about threats DMARC is intended to respond to, and clear about where such responding takes place. To the extent any of that text makes assertions about the performance of end users, it needs to cite the basis for the assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 22 06:39: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 5A4993A0930 for ; Wed, 22 Jul 2020 06:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 k93Gq9hGm203 for ; Wed, 22 Jul 2020 06:39:53 -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 9D26D3A097B for ; Wed, 22 Jul 2020 06:39:48 -0700 (PDT) X-ASG-Debug-ID: 1595425187-11fa3107a84a4e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id FzSPbbB0RGjpiae2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 22 Jul 2020 09:39:47 -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:subject:to:from; bh=xaZ48RCTHsC5GLwR3+EIqABKuOUnRBLqTsCdEj4lXxE=; b=IHhpk2FFQEQ9ObGYeVkMQhy43HmvzvVuj49sOAPFUPSntiGTcmGsla+kv3hR6NG9I j46L4U4LvQcJl7qoC0FME0OSBaBxjY6srrK8vd9PcSxJRHxHLH5ryGfIO3r2HtSOC aOoT07BAEpvbbv9GY5hUiskKBx2asYExkXpGeM/nk= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 22 Jul 2020 09:39:38 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: "'IETF DMARC WG'" References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <9A436C27-CECC-46DD-B365-1FCF9366E64F@wordtothewise.com> In-Reply-To: Date: Wed, 22 Jul 2020 09:39:38 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Message-ID: <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQE4LtKXiz8pli4lbqSKvNALUr56MgJ5g18OAYZ/SGMBZFHX2QEyqW97AhtZsaICLwmy2wEtHGvdAjdD9nEBr+G5YQMbdNCRqbdyS2A= X-Exim-Id: 002201d6602d$8b87dca0$a29795e0$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595425187 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: 2416 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83379 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 13:39:55 -0000 Since the conflict between DMARC and Mailing Lists is related to the = changes that Mailing List apply to a received message, it may be useful = to review the purposes that each of those changes serve, with a goal of = eliminating unnecessary changes. Specifically, this list adds a footer to every message. Is the footer = a "trust indicator" which serves an imaginary purpose, or a necessary = addition for other reasons? If it is added as a trust indicator, = perhaps it could be dropped. I would be willing to format my submissions to IETF specifications, if = it would protect the integrity of my signature. But IETF has not = disclosed a way for that to be done. What I can determine is that the = footer addition is currently unconditional, as evidenced by reply = messages with multiple copies of the footer, and therefore I cannot = prevent my signature from being invalidated. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, July 22, 2020 9:24 AM To: IETF DMARC WG Subject: Re: [dmarc-ietf] Response to a claim in = draft-crocker-dmarc-author-00 security considerations On 7/21/2020 1:08 AM, Laura Atkins wrote: > When we=E2=80=99re basing a protocol on =E2=80=9Cwhat the user = sees=E2=80=9D and =E2=80=9Cwhat the=20 > user can trust=E2=80=9D then I think we have to. DMARC says = =E2=80=9Cusers can trust=20 > that mail from @domain.example is really from @domain.example=E2=80=9D = but if=20 > the user never sees that, how do they know? I think this can be connected to the query about threats that DMARC is=20 intended to respond to, by virtue of suggesting clarity about /where/=20 the responding takes place. My contention is that it takes place in a receiving filtering engine and = does not take place at the user level. Further, it's one more data point in that engine's analysis process,=20 rather than being in any simple way definitive. In any event, work here really should make a point of creating text that = is clear about threats DMARC is intended to respond to, and clear about=20 where such responding takes place. To the extent any of that text makes assertions about the performance of = end users, it needs to cite the basis for the assertions. d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Jul 22 10:05:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE33A0B4B for ; Wed, 22 Jul 2020 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tw2qa9Yb; dkim=pass (1536-bit key) header.d=taugh.com header.b=ug6tRW/a Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW8uMih6HmMQ for ; Wed, 22 Jul 2020 10:05:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448BF3A0B51 for ; Wed, 22 Jul 2020 10:05:16 -0700 (PDT) Received: (qmail 22185 invoked from network); 22 Jul 2020 17:05:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=56a5.5f1871cb.k2007; bh=VgfJD3JeY+cGvfsbUUNgGp/RmAjrokdxa/Ey/TwfmOc=; b=tw2qa9Ybe+ED5PMO9LZx45Cx7K3sy+f9Kdw+XdAkAsL1Xtmzh2LRX2zLc+g2WebPkbiiMO7BpM7IrwLUgJG58eca/rOmabH8yxgMsdGu4sXCZp0uHDz2wkUdrfq0UJX9D8RLt96zKzFaGgqC6NufkVby+UBqys7zUAscprWn5HQNW4VmJHqqdlsfTck//708foktkomuOkGaCupgGo8hitgDFuw4AHAhIWYZDA+GfVdFIo1IpfyEyY6Rnb3ajFDP 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=56a5.5f1871cb.k2007; bh=VgfJD3JeY+cGvfsbUUNgGp/RmAjrokdxa/Ey/TwfmOc=; b=ug6tRW/aNuzSELEIw7aGPf4jVfOvGm0EtWRhRi5859gLHLU1IwGYovQj6wA5En7Cgx5g/3CWaxWEGr2kf4KdXVnboyGWXC/BwM3Xtpmn8z0MZ+JLBd7EqFw8zlXEI9lLtIzLjJfLYmsHhhm1+vOIUgh+9Fvw67AkBhXygG1FOKu1URfI6ESJZ+NaIBGQpC3V6vP1vIs9M6TgT59ktTt0S05/utH4YbAYSWiEd4BCq/mw2qmcFHAC+CeXCmWI7T30 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; 22 Jul 2020 17:05:14 -0000 Received: by ary.qy (Postfix, from userid 501) id 911F21D61BDE; Wed, 22 Jul 2020 13:05:14 -0400 (EDT) Date: 22 Jul 2020 13:05:14 -0400 Message-Id: <20200722170514.911F21D61BDE@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 17:05:19 -0000 In article <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com> you write: >Since the conflict between DMARC and Mailing Lists is related to the changes that Mailing List apply >to a received message, it may be useful to review the purposes that each of those changes serve, with >a goal of eliminating unnecessary changes. I don't believe we have a charter to tell mailing list operators what to do, even if we believed, against all experience, that they would take our advice. As may have been pointed out a few times, mailing lists had been serving their users perfectly well for decades before AOL and Yahoo made them DMARC roadkill. R's, John From nobody Wed Jul 22 15:38: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 0860E3A0896 for ; Wed, 22 Jul 2020 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gd7ceE1vi4Bj for ; Wed, 22 Jul 2020 15:38:30 -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 56A373A0895 for ; Wed, 22 Jul 2020 15:38:29 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2055.outbound.protection.outlook.com [104.47.46.55]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QDW05H7A6W41S40@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 22 Jul 2020 17:38:28 -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.7.22.223317, AntiVirus-Engine: 5.74.0, AntiVirus-Data: 2020.6.18.5740001, SenderIP=[104.47.46.55] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IOC/mDtI9CFZLuEHOdurhfIAnIL8Pun0PWx4r1400FniECE9JPgrzG0JddzuEf4ac7qj2GdPWXaXuaS7EOSW+n/ft4aE7RdUJIjVnBrvOc3W6uzEglbV2LkE6ZbfvYLS+ZfpuqDFjdbISlNh7DN2ctx2MjG9JrTpt2ZVA1cReHVsj9n9sQg//Pq2JoqDTTiY83MC+9j8qCdIdOJ9GCiS4sMzIehFv6mDibIPs9j5tatNEWIiuIuLJM8GOKBjPLR35NuExMRd2UXt8f1ejYisQaiB4ss/2naG+CO2PED0MuMjAsdnjUhkz4LAP+nzDI761bsw52blCm2+VZnTfVqz4w== 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=s5Poe1hKrqBBK/DEZztHSDYUGWwCETQnVaTBSrLyTpE=; b=Q0sB/BSjpLZ9s4pRQcyyCl438Pj0m/HJnYs4Qgm/Y074MzOG8+YxKhztzTo4Jpk5exVDu9TawRZ9pk33BmyP5nliC4X+OQc3DUpK29R6NzjAa/3U+42F3g3PfTRMhuUR2bWZqXXgo4GB+aPHC+yCkXaIjt2ySt+3hj4wPR4jkFoY2YlaURnoZizwvfGXF3G5/5ODlQlXzKtQZg3cZYZFe8xJB+BoH203AYg0S7V47OVn1ls1f3hE9vyURqEe2UWlwTAVXQUDYmvDPr869gZmWoBATK2Pvrrztqgb5TC/s3rfudvxPQem+IaWsR4PCvvmEi3VAs0xE9e/powD6ehUkA== 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=s5Poe1hKrqBBK/DEZztHSDYUGWwCETQnVaTBSrLyTpE=; b=mo/I1tkhqOkiwwKYkfiQIg5aZ5fkrRpfNeTV8OCqo3GPXRAyIMAWRWDpg5SkuCSRpDWP4Z0qrBF4d4s4/wPO3XSlaOe7SjCIhAl6NsgZ4+GRYxoFY+4bOr3NExITYrxceXKlwOiTa7CpFGFFSsOkmuYCCG4yz0X+injvAOicmvM= Received: from CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) by CY4PR06MB2309.namprd06.prod.outlook.com (2603:10b6:903:12::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul 2020 22:38:27 +0000 Received: from CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::3d8e:1435:a4df:c400]) by CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::3d8e:1435:a4df:c400%7]) with mapi id 15.20.3216.021; Wed, 22 Jul 2020 22:38:27 +0000 To: dmarc@ietf.org References: <20200722170514.911F21D61BDE@ary.qy> From: Jesse Thompson Message-id: Date: Wed, 22 Jul 2020 17:38:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <20200722170514.911F21D61BDE@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR10CA0025.namprd10.prod.outlook.com (2603:10b6:610:4c::35) To CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR10CA0025.namprd10.prod.outlook.com (2603:10b6:610:4c::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22 via Frontend Transport; Wed, 22 Jul 2020 22:38:27 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c8d53fc8-82a9-43d7-b8d2-08d82e8ff372 X-MS-TrafficTypeDiagnostic: CY4PR06MB2309: 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: zKiedLKR98oit1NYPBAlB3zE3Ox/+04gXp8EdyUrBR3WZvRDTUAB+RuemNVoe71oH1Y+FGScCuOx2FG5EvTGMSYIOEPph126GF3yJO0cXE4ObnTvK8LFsFQYCBYrQK5rvTEvCRlqAPJil9llkH/PDHvdXQ0hFm+67ZpmYYOKBWwZI+aBP/OOXlQO/AeJ4HVDCY9Us3yT2n+9slME8BRNirUepaVigl2I+yEiGTmooZWu/a9XLq/CiHWr8IU0jE9KNAMQ7mgjBLUxLgDAhZUEyW7jjLRRDkYeWHViKDaKft3LWcHcn4PKwp8eQvstJ0J9gyXydorfZm48DXscQhTmEZCJ6UCO0lJV44dnL23/IkQlQcMsF60cOAEMVueevcVywqMRQ5mqMw8UBWFuHq21LnZOxD5Cgig8W2KeDOTTcFBfFZgTkVrhRjG3myPwVtG9JLYJBKzvtiG0/UJPI31RMg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3668.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(396003)(136003)(366004)(346002)(39860400002)(36756003)(83380400001)(2616005)(956004)(16526019)(478600001)(31696002)(5660300002)(186003)(26005)(8936002)(75432002)(83080400001)(6916009)(86362001)(53546011)(4744005)(44832011)(316002)(966005)(2906002)(66476007)(8676002)(66946007)(786003)(16576012)(66556008)(6486002)(15650500001)(31686004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: G+8M/cj+OIhG23MYWwlMMqhIiQc3Umd1nrdegV2IXJwLzTiDJCfkxVz0wl02oAdSuXG/FuNYM34BaNtTxmIyo2Mq2tTQZg9eVIYPYaY6O3Td75S4AaelQA2uhNdBNtUZ/bu/Xtq5wMzwcKSv9KiXKB8Y41mP+J7Jv7lZt9fHrPExBgfn5c26p/Y4RvcKuN9/B2Q61P/HNSNVsy6RFt6YAuE0hmduTNHeXyePWyW6YwVirKftPETMxMFAY0vIGFVldAg7vNe3cpF/LzG4U6+ebisIO1OZnR+na5IzDsKKtuvdUiAq99PsrZ9yaeRkEgEm7/eoBmHk0iGKw6fl6o3hGo5WsjnogjFbTZ9+aZtrUyLIusBeZhbUEnQ4AsP/MnBHCsBZvZI8ujSYIjzY49CBUAxRaMVxhJM9TBjz8ChDgprHjtzXjEK6NZzI5JI2Iv2Cqkn21AO75FeBPremnRk966Xa/miPGGZucNxQ2YFAqJ8= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: c8d53fc8-82a9-43d7-b8d2-08d82e8ff372 X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3668.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2020 22:38:27.4157 (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: 3v7+bOb00KDX10yx84bfu/Tz8IIWeyF4FX5mVwZFnhmLvRNG3E6SrVxe0Jqcjec0KXHOKwvwjh3EfsHjPoSuNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2309 Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 22:38:32 -0000 On 7/22/20 12:05 PM, John Levine wrote: > I don't believe we have a charter to tell mailing list operators what > to do, even if we believed, against all experience, that they would > take our advice. https://cyber.dhs.gov/bod/18-01/ references https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F Who should be giving them advice? > As may have been pointed out a few times, mailing lists had been > serving their users perfectly well for decades before AOL and Yahoo made them > DMARC roadkill. Given that the email security industry's marketing now shames domain owners for not adopting DMARC, I think that the statute of limitations for AOL and Yahoo has passed. Jesse From nobody Wed Jul 22 15:53: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 2A3173A08B1 for ; Wed, 22 Jul 2020 15:53:37 -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 WWTG-m42QU7d for ; Wed, 22 Jul 2020 15:53:35 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625CE3A08B7 for ; Wed, 22 Jul 2020 15:53:35 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id x5so2737365wmi.2 for ; Wed, 22 Jul 2020 15:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jeVdM1TJ6RIu1jhiJzZb0IKt+6ldciuURoTWZwxYGx4=; b=IQ74MqURTmYOfKkWve9iE/ahCgRYQ91UJKas3KP9yQB9UkMxZ8mfHHDJicXGfH5ylr xf5cv0pReW7wr/SdaPIUE6VYyXpNNuFHkykjvPphg0AqDXASh2PRUfuc771pyeebnsJt VBsJQFKUm/NCzBvS4SgN9UjH6wMFPrvDhY9U1nuB/BchcVPJF1NKOjv9X4jl3qTBFYKY j2QA18MmgW3Y58y/2QQ7da5UDQLwrGNafHPWLoAs+f6hl5gpoGgM/Z0J9v6rA+sJLgwp Pw/j8Qotp2zBXmROYrHzyEdmkE+flrD+2VF0R5kNdpMliJISm4aZyQPUnoEh5+r4R8NG xQhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jeVdM1TJ6RIu1jhiJzZb0IKt+6ldciuURoTWZwxYGx4=; b=DnmXovvycvtCyeo+6f0IDheKToUUg7gewLWOy62vqD0a1w8tHXkeLYplQKOEkdpHcn Yb5E7nSesumN+2dFvlq4AJaJXXr41hMsamBva26RdgYyRX6Vyan/qdpvG+UrPoOYPb3n df3ds+fNPsc8QLS+3AoTJ477dLccRtOne3EC4UFoY0YnEpIU7EHu3vPGZ7E8DXwxbkMM R2+JnBCE1XN5AK3igMmz2ynFyIO85rb3zptFMUNskPYl1sakbBhvJM6upP/6+GBVX1pn S8aiiEBU/IhaGeitXSU1G2f/L1RpCTh8EFhaCHYeNbrYQ0iJJ9dZskuIgRhzgLGhLll2 blcA== X-Gm-Message-State: AOAM533hZz3cJdZ3kBD5GV4/HoChpPawo0qSceAMjGd5UoHP2gMuvGZo 2cjBCaXY35bYe3LVPfdkziS6URTuGlIUmOC8/fGGxw== X-Google-Smtp-Source: ABdhPJz65nmEXOSrYKroYREkKPNGYk4CKFQo4dZn8DAJir30/HIMxh13hyl6fK81UrXCf7P2V8XCoYl98iOEyIKxAo4= X-Received: by 2002:a1c:7402:: with SMTP id p2mr1524335wmc.117.1595458413498; Wed, 22 Jul 2020 15:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20200722170514.911F21D61BDE@ary.qy> In-Reply-To: From: Dotzero Date: Wed, 22 Jul 2020 18:53:22 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fd97ad05ab0f9bff" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 22:53:37 -0000 --000000000000fd97ad05ab0f9bff Content-Type: text/plain; charset="UTF-8" On Wed, Jul 22, 2020 at 6:38 PM Jesse Thompson wrote: > On 7/22/20 12:05 PM, John Levine wrote: > > I don't believe we have a charter to tell mailing list operators what > > to do, even if we believed, against all experience, that they would > > take our advice. > > https://cyber.dhs.gov/bod/18-01/ references > https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F > > Who should be giving them advice? > Probably not a technical standards group. > > > > As may have been pointed out a few times, mailing lists had been > > serving their users perfectly well for decades before AOL and Yahoo made > them > > DMARC roadkill. > > Given that the email security industry's marketing now shames domain > owners for not adopting DMARC, I think that the statute of limitations for > AOL and Yahoo has passed. > Despite my personal opinions regarding mailing lists, DMARC and anti-abuse, this working group is not the running dog for the email security industry's marketing efforts to shame domain owners. Perhaps you would like to submit an Internet Draft on how to resist feeling shamed. I have a feeling it would be informational at best. I would also suggest that this group, lacking significant representation of MUA providers, should also refrain from thinking it reasonable that this group should tell MUA providers how they should go about their business. Michael Hammer --000000000000fd97ad05ab0f9bff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 22, 2020 at 6:38 PM Jesse= Thompson <jesse.thompson=3D40wisc.edu@dmarc.ietf.org> wrote:
On 7/22/20 12:05 PM, John Levine wrote:
> I don't believe we have a charter to tell mailing list operators w= hat
> to do, even if we believed, against all experience, that they would > take our advice.

https://cyber.dhs.gov/bod/18-01/ references https://= dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with= _DMARC.2C_what_should_I_do.3F

Who should be giving them advice?

Proba= bly not a technical standards group.=C2=A0


> As may have been pointed out a few times, mailing lists had been
> serving their users perfectly well for decades before AOL and Yahoo ma= de them
> DMARC roadkill.

Given that the email security industry's marketing now shames domain ow= ners for not adopting DMARC, I think that the statute of limitations for AO= L and Yahoo has passed.

Despite my pers= onal opinions regarding mailing=C2=A0lists, DMARC and anti-abuse, this work= ing group is not the running dog for the email security industry's mark= eting efforts to shame domain owners. Perhaps you would like to submit an I= nternet Draft on how to resist feeling shamed. I have a feeling it would be= informational at best.=C2=A0

I would also suggest= that this group, lacking significant representation of MUA providers, shou= ld also refrain from thinking it reasonable that this group should tell MUA= providers how they should go about their business.

Michael Hammer=C2=A0
--000000000000fd97ad05ab0f9bff-- From nobody Wed Jul 22 15:55:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCD3A08C0 for ; Wed, 22 Jul 2020 15:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7wP1vnhz7OZ for ; Wed, 22 Jul 2020 15:55:13 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21023A08BA for ; Wed, 22 Jul 2020 15:55:13 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:d804:19c4:ed42:ddf5]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06MMtC2w026380 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 22 Jul 2020 15:55:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595458513; bh=fCUy9AUtuk9WOW8Di+pAUeOIcSoo3CITzUSlltvH4NU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UEhHI58dcZ/hDs1Gv3wAZkM6x9LZSsi5RealbLtqhZVyYAAOJLz2Mo4OxiaMwYAEe gkieut28TIYeqMlc3/E3AVVxpvt/TO+PmIVoth/ujzWL5dEkGGIz5xQ29SG5pvK8Y9 ANGw0w8YSz57gWoz0G7H3fyHOyZdOufjt7LAe4Dc= To: dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <5F172EF5.7000508@isdg.net> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG Message-ID: <4c514db5-3f52-0e26-10dc-b7ed849da8d9@bluepopcorn.net> Date: Wed, 22 Jul 2020 15:55:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [dmarc-ietf] DMARC marketing X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Jul 2020 22:55:15 -0000 This: On 7/21/20 12:29 PM, Joseph Brennan wrote: > > My understanding of DMARC's purpose was to protect transactional > messages from sources like banks, credit card issuers, online shopping > venues, and the like. It supposed that those messages should pass only > directly from the source to the end point, and that that was so > important to security that transport through any intermediary should > be rejected as possible forgery. For example my bank statements come > from a different domain than mail from a person at the bank. and: On 7/21/20 1:17 AM, Laura Atkins wrote: > But I would argue that much of the marketing and justification around > DMARC has been around end users and improving their trust in brands > and protecting them from phishing.=C2=A0 > [...] > > That is not how I=E2=80=99ve seen DMARC being sold. Most of the marketi= ng I=E2=80=99ve > seen about DMARC is all about user experience and the user being able > to trust mail is =E2=80=9Cfrom who it claims to be from.=E2=80=9D And n= ow people are > explicitly layering on another protocol that is all about what the > user sees in the MUA. and also: On 7/20/20 5:31 AM, Dotzero wrote: > You have left out one significant way of convincing receiver domains > and their admins. We used to have our CSRs (customer service) tell > people who received spoof emails (resulting in phishing, malware > compromise, etc.) from emails claiming to be from our domains that > they should contact their mail provider or email admin because the > problem could have been avoided if DMARC were being checked. We would > even provide them with the details and a form with all the information > in non-technical terms. It is amazing how quickly a provider pays > attention when their customers/users are complaining to them that the > provider could have prevented the heartache and grief but chose not > to. Again, this was for domains sending transactional mail with only a > limited number (intentionally) of role and support accounts. These get to the heart of the problem: DMARC policy was designed for official mail that is about business transactions. If that was the way it is actually used, we wouldn't be having this problem. But it was oversold, and it is being used in use cases (like on domains that have mailing list users) that were not intended. I'm not convinced that this is a problem that has a satisfactory technical solution. -Jim From nobody Thu Jul 23 06:07: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 E6D3A3A0A88 for ; Thu, 23 Jul 2020 06:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QgMEJB4NjBJ for ; Thu, 23 Jul 2020 06:07:42 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 565E93A0A82 for ; Thu, 23 Jul 2020 06:07:42 -0700 (PDT) Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06NCgVCw026434 for ; Thu, 23 Jul 2020 09:07:41 -0400 Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 32bw8tua1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 23 Jul 2020 09:07:40 -0400 Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06ND7dgx051315 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2020 09:07:39 -0400 Received: by mail-io1-f69.google.com with SMTP id 63so4027398ioy.4 for ; Thu, 23 Jul 2020 06:07:39 -0700 (PDT) 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:content-transfer-encoding; bh=oY+jgFE2s4ZMaGz8+Jumo0LfmLUuGJeXi6Gy7DHYtwE=; b=b2VRTDPb9enNiOxMjL3kpgXVnWUAXdyLHDJObXapawK9FSivIDFnh8cHwpJ00bSPTh DZsGOgBqdoXRNeMw15DhbOGcgN+JUGwpoMkpfl7xfDEQX+RspsIrdQ5GtfkilMm8o3IH 3RO28IfLOlOaYwMdfC6y/qG1/k/1VArY4UcmNmbKD+CY5gCA9cQWMahrp2C1j1e7Deo0 F1C3xWckzC+OXD7JZwI8Ke/9QzadGZ0JDfeyXAeCKy/b9/O08xyecowkEP/rV1HkuhdZ bKOLtoR3KYzC/k1+ZCuMeQSV3WJoOTnFLzFwmr07D2pZS3U5xzxbaToZgeHnXCVnm5eQ //pw== X-Gm-Message-State: AOAM533S0HhKnMrkq3A1IJzvZRO+TZklY9AoOx5eQjNtahwro1Pd/B+N kp3CoxpVSqKJRADAKMKZgF9WkpFUFK5kO4rXrIaXHRtwoYAtcbc3v8ulPrncgWpF79hn5PbtRtc XgXreuH2mjhLfD6AMEASSAkjlNQbsZA== X-Received: by 2002:a92:c703:: with SMTP id a3mr4506577ilp.159.1595509658484; Thu, 23 Jul 2020 06:07:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTQ/1z3ZSwTH3ljG9smnjCYDQSx51142RS0Nlt2sEF9ECJtiq4ZEDpBZtshHoa07WoDGDopB5MouqNSSnqFxM= X-Received: by 2002:a92:c703:: with SMTP id a3mr4506538ilp.159.1595509657961; Thu, 23 Jul 2020 06:07:37 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> In-Reply-To: From: Joseph Brennan Date: Thu, 23 Jul 2020 09:07:27 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_05:2020-07-23, 2020-07-23 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:07:44 -0000 On Mon, Jul 20, 2020 at 6:05 PM Jesse Thompson wrote: > > > > It calls into question whether we (or any domain) should publish DMARC po= licies. Gmail.com doesn't publish a DMARC policy, after all, and many peop= le (such as some on this list) are using gmail.com to subscribe to lists, a= nd they don't have to suffer the consequences of DMARC. I interpret Gmail's approach as a fine marketing decision. It means mail from gmail.com is more deliverable than mail from yahoo and aol. They must be smiling every time some domain rejects end-user mail for DMARC violations. > > I think that we just have to agree that From-munging by MLMs is a permane= nt reality. It needs to be documented more prominently (and promoted as pa= rt of the DMARC marketing) so that implementations are more consistent, so = that un-munging tactics and/or MUA behavior can be consistently implemented= . > I'd be happier for the proposed standard to say that DMARC policy "SHOULD NOT" be compromised by rewriting From lines-- and see how that goes over. My reasoning is that blessing the practice makes it easier for bad actors to craft spoofed mail and get it accepted. The opposite of the purpose of DMARC, isn't it? --=20 Joseph Brennan Lead, Email and Systems Applications From nobody Thu Jul 23 06: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 E76353A0AB4 for ; Thu, 23 Jul 2020 06:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 099YbcEIzP8Q for ; Thu, 23 Jul 2020 06:15:15 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 0A46B3A0AB3 for ; Thu, 23 Jul 2020 06:15:14 -0700 (PDT) Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06NDCJki004580 for ; Thu, 23 Jul 2020 09:15:14 -0400 Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0a-00364e01.pphosted.com with ESMTP id 32bw8tubk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 23 Jul 2020 09:15:14 -0400 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06NDFDPG002208 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2020 09:15:13 -0400 Received: by mail-il1-f197.google.com with SMTP id w10so3430417ilm.16 for ; Thu, 23 Jul 2020 06:15:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YiXa4zO+0l6JAnpxQhXQCC0m/6+S5KX/ruBQWyacvQk=; b=oXfnOKjJjQbwgt/flawqvA+Ma3UigUeLV/nxSwTF4tQ5mtWV8ZMKYY9FCV6hCk1dHB 3VFp+PIB+BWbGS3pWhkdqV4JTzO3xSlp0BZWRpjoH5uebrKYKLAYXUZ9U8Bw5P+C1YlE T8h4pI4JIMERMFpMK0tIl6+gLaTh0PMuFBjcNF+ZIXoCxGYP88Op02Jl3sATYp/ov/Ee Yl/HZUoV9TigHyNRE1WRsmJWEkYp9WNzAt5HRIrC5XCKdfEE836mE3jfhZr3RJLJ0UKr YFSNfjtFB35Vate3EZkGCZLAqkqVWkznts0tl7ap2cwbOCb/8P53wiLw1LJB9wJD6bTI KUfg== X-Gm-Message-State: AOAM530EQoybErP3gdaKexDN7ABAc+YCkQeAiE6LVDja/jGM01Cj4HnE 5/0hehfkwJMFZS1RKIgBCEyegFKDX5Qb19rm7Kri8mq/VrMvLgdE6jZh0uK73y4+D4lB6OOiz3T Jv5A/f+3RgW/9kc2BCZXMtVnkC4sT2Q== X-Received: by 2002:a92:c703:: with SMTP id a3mr4538045ilp.159.1595510112665; Thu, 23 Jul 2020 06:15:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmGFQ4CEXVN7zUBBEJMZEhGD8G00lD9jeGWm1E6oDa3gpjjWkECPZkf2prNSpXPP0vOZsAo8yNnyBz7S3mpIs= X-Received: by 2002:a92:c703:: with SMTP id a3mr4538010ilp.159.1595510112122; Thu, 23 Jul 2020 06:15:12 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> In-Reply-To: From: Joseph Brennan Date: Thu, 23 Jul 2020 09:15:01 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_05:2020-07-23, 2020-07-23 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:15:16 -0000 On Tue, Jul 21, 2020 at 5:45 PM Jesse Thompson wrote: > > Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address. > > It works because now the victims just see "wisc.edu.provost32@gmail.com" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on. > Briliant! I wish we were still using Mimedefang. This wouldn't be hard to code, and the results would be effective. -- Joseph Brennan Lead, Email and Systems Applications From nobody Thu Jul 23 06:15:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3443A0AB3 for ; Thu, 23 Jul 2020 06:15:57 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmL0aZklhsfe for ; Thu, 23 Jul 2020 06:15:54 -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 4676E3A0A56 for ; Thu, 23 Jul 2020 06:15:52 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06NDIMif014450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2020 06:18:22 -0700 To: Joseph Brennan , IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1e38ca7f-2794-52ea-d6d2-e3b2d32f2c8a@dcrocker.net> Date: Thu, 23 Jul 2020 06:15:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DAF3CB280213EF3CE5CDD002" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:15:57 -0000 This is a multi-part message in MIME format. --------------DAF3CB280213EF3CE5CDD002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/23/2020 6:07 AM, Joseph Brennan wrote: >> I think that we just have to agree that From-munging by MLMs is a permanent reality. It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented. >> > I'd be happier for the proposed standard to say that DMARC policy > "SHOULD NOT" be compromised by rewriting From lines-- and see how that > goes over. My reasoning is that blessing the practice makes it easier > for bad actors to craft spoofed mail and get it accepted. The opposite > of the purpose of DMARC, isn't it? Technical specifications are not policy advisories or expressions of opinion.  They definebehavior to be used by actors that are trying to follow the specification.  A specification defines a sandbox.  Normative statements apply to actors that have chosen to be inside the sandbox. So, normative language in specifications is meaningful only when it will be followed.  Giving directives to actors not participating in the topic of the specification is wasteful and likely misleading. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------DAF3CB280213EF3CE5CDD002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/23/2020 6:07 AM, Joseph Brennan wrote:
I think that we just have to agree that From-munging by MLMs is a permanent reality.  It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented.


I'd be happier for the proposed standard to say that DMARC policy
"SHOULD NOT" be compromised by rewriting From lines-- and see how that
goes over. My reasoning is that blessing the practice makes it easier
for bad actors to craft spoofed mail and get it accepted. The opposite
of the purpose of DMARC, isn't it?


Technical specifications are not policy advisories or expressions of opinion.  They definebehavior to be used by actors that are trying to follow the specification.  A specification defines a sandbox.  Normative statements apply to actors that have chosen to be inside the sandbox.

So, normative language in specifications is meaningful only when it will be followed.  Giving directives to actors not participating in the topic of the specification is wasteful and likely misleading.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------DAF3CB280213EF3CE5CDD002-- From nobody Thu Jul 23 06:20: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 9ED423A0AC5 for ; Thu, 23 Jul 2020 06:20:31 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y28evk763DP for ; Thu, 23 Jul 2020 06:20:30 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9506A3A0AA4 for ; Thu, 23 Jul 2020 06:20:30 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 380DB7FB23 for ; Thu, 23 Jul 2020 13:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=269; q=dns/txt; s=default; t=1595510429; h=from : subject : date : to; bh=bMyMZf3VShNI5nHe2B++PeRyMwAPsnL5iBC1r2t4p1E=; b=Kf6Kb+PjFYpYOAwMyFpNlfBPCZbuv/CRVWJZNTqMlqhx0ebivTjPSNJZStEvqekNdmnuC b+ytXIQuRSZpGUPnFLjZ9PdbEJwpH/tbfeQXNd2wv/TkSaMA60biq0KOZigIRBrd/nj5ekU FIlPpqxh4ZLhDrWeqX2Pi0SvawYlhNg= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 19BE77F9D3 for ; Thu, 23 Jul 2020 13:20:29 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 23 Jul 2020 15:20:29 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <708a775465c2765311742e7c2eee34ff@junc.eu> X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:20:32 -0000 Joseph Brennan skrev den 2020-07-23 15:15: > Briliant! I wish we were still using Mimedefang. This wouldn't be > hard to code, and the results would be effective. show the source on how to make this work in mimedefang, or will it completely fail with spampd ? From nobody Thu Jul 23 08:06:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF4F3A087F for ; Thu, 23 Jul 2020 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woA9mCxZ1a_Q for ; Thu, 23 Jul 2020 08:06:23 -0700 (PDT) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 7A4843A08C6 for ; Thu, 23 Jul 2020 08:06:13 -0700 (PDT) Received: from pps.filterd (m0167073.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06NEbg97009360 for ; Thu, 23 Jul 2020 11:06:12 -0400 Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0b-00364e01.pphosted.com with ESMTP id 32bvydubmm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 23 Jul 2020 11:06:12 -0400 Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06NF6BHC002500 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2020 11:06:11 -0400 Received: by mail-io1-f71.google.com with SMTP id f25so4233149ioh.7 for ; Thu, 23 Jul 2020 08:06:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nFZdOOhHIan3/jSSzP6gSVN2oE39Qyhjo3OhK4mnwTI=; b=ELkTQUdi87qmGv0YEQd2snmMFaYfkepQakv6MDleDWI8O3IFmKF4DPO3fV+Pk3zHVJ kSAtF60ilDZP7ivFeeIO3jbToWnwf6oDjDApcsxFaRO2Kcpe5qtzB4dKN5WfjqpaWsw1 QNfFdP9bZP/WC9iaMZsZorP18PCBUOqfHiHpejJHZmOc5l1E6m/oXtdoj324TpQF1K2u aWdF4qBV3wnCIwqGvbtJ4y+UqxhX9TVHJcbLxhklMAqi3k1URIiE4ViJwzanbOcCT9KS 2tBbyZQcyNNvSuNuavCaO7HQgeM3xMDopVk3dhg+6iM25BX2Aq2YWGaKeu2NSwQnMBT1 y1aQ== X-Gm-Message-State: AOAM531x9VWMhbY5TL7GjD+TVz9SIcG+HWNVrJ7DYIEGikXTnkzOhVeT I92XSvkKxBzUNOSM44N4OMJnJkTLf7MC8SnxAWmKam/aqotmNRW2tYLjo1xog2HPrSONxU3KZ3u G9gT2m77DrX0mUz487AMzB8FX2bNRKg== X-Received: by 2002:a02:c903:: with SMTP id t3mr5318487jao.30.1595516771156; Thu, 23 Jul 2020 08:06:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWn7FzJsxs+EtZb8SDQl/zIvPIrQi6UfD9L/nyCctKlryiFbzhAT26ErgGYBsnBbLoR5JAln31l0q+XqRQB0k= X-Received: by 2002:a02:c903:: with SMTP id t3mr5318447jao.30.1595516770698; Thu, 23 Jul 2020 08:06:10 -0700 (PDT) MIME-Version: 1.0 References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> <708a775465c2765311742e7c2eee34ff@junc.eu> In-Reply-To: <708a775465c2765311742e7c2eee34ff@junc.eu> From: Joseph Brennan Date: Thu, 23 Jul 2020 11:05:59 -0400 Message-ID: To: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_06:2020-07-23, 2020-07-23 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 15:06:25 -0000 On Thu, Jul 23, 2020 at 9:20 AM Benny Pedersen wrote: > show the source on how to make this work in mimedefang, or will it > completely fail with spampd ? Since it is off topic, I will give a short answer. If the Header From matches /From: anything , check whether domain is one that needs the rewrite, gmail.com for example, and change the field to be simply /From: string@domain/. In Mimedefang, we created a per-message global hash %Header, and parsed each field (split on :). So for example $Header{from} was the value of the From header field. The hash was used in various rules. MD has a built-in function to replace the content of header fields, which I think is a milter function. -- Joseph Brennan Lead, Email and Systems Applications From nobody Thu Jul 23 08:18: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 100F23A08AF for ; Thu, 23 Jul 2020 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1a4qtKUhQBe for ; Thu, 23 Jul 2020 08:18:26 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F290F3A0898 for ; Thu, 23 Jul 2020 08:18:25 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id 9C4B98016D for ; Thu, 23 Jul 2020 15:18:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=780; q=dns/txt; s=default; t=1595517504; h=from : subject : date : to; bh=sHZAQCiEuMbl3FJX2qBqpPGqgemN++IFfFP/rGQmVUQ=; b=A6QpwJgzAF2oRpmiAEeQ5KY99B7Yk056/kdpmdQTTBu7H7YyMjI2qavJqznTnWle+4+zp o/lGQY8x9TuGaKffCs6ePWpWe2LLhkIY7EClEJyhGaK0cf1qZ9JEYN/phDjnmixKe10lN8j K8r6r1mfBrh4R4c5Hrwc2tYT+xW1rmc= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id 806D67FB0E for ; Thu, 23 Jul 2020 15:18:24 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 23 Jul 2020 17:18:24 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <74a6fb5f7578452f9080cddb8ebbc8f5@bayviewphysicians.com> <708a775465c2765311742e7c2eee34ff@junc.eu> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <2b5f0330e7c8e735dccdf1a892c6bf8a@junc.eu> X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Why are MUAs hiding or removing the From address? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 15:18:27 -0000 Joseph Brennan skrev den 2020-07-23 17:05: > Since it is off topic, I will give a short answer. If the Header From > matches /From: anything , check whether domain is one > that needs the rewrite, gmail.com for example, and change the field to > be simply /From: string@domain/. ok > In Mimedefang, we created a per-message global hash %Header, and > parsed each field (split on :). So for example $Header{from} was the > value of the From header field. The hash was used in various rules. MD > has a built-in function to replace the content of header fields, which > I think is a milter function. but it fails to not break dkim then ietf.org have more ips to spare to make not breaking dkim, sadly so many experts doing the wrong things :( From nobody Thu Jul 23 20:51: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 788AB3A0A01 for ; Thu, 23 Jul 2020 20:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y34chi1nBxco for ; Thu, 23 Jul 2020 20:51:06 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D74E3A09FF for ; Thu, 23 Jul 2020 20:51:06 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:9d11:d677:ba2:487f]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06O3p4WU019519 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 23 Jul 2020 20:51:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595562666; bh=Mte67ILaUtwC6K/9vHP9hAsx8FyjUxTDNhU0oAGK5nE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hBJRwQxJA6sfwyEb+2OiZkD4gEbmNiuFE3AB26/Kyd8AHGPJvsTmZrGcMVjSsR71T SC4cYQis9MjCzcqwPCOu7vZzAKiunsssM4doaa1YGDFH62BC6RmRZIac9KqaOwuemp do7PKTsHoYZJFHvIvMHvmW6MMYuJN2x+AqbSk7Uw= To: dmarc@ietf.org References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <6160eab7-c7e7-f20b-8880-499de9733f30@bluepopcorn.net> Date: Thu, 23 Jul 2020 20:50:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 03:51:07 -0000 On 7/20/20 11:36 AM, Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions > from the group for the agenda, otherwise the chairs will choose > relevant topics. Items in tickets or from the past month are all fair > game. > > Thanks, > > Seth, Tim, and Alexey > I am hoping for a resolution on whether/how to split DMARC into 2 or 3 separate specifications (e.g., aggregated reports, failure reports, policy). I understand the chairs were discussing this. -Jim From nobody Thu Jul 23 21:08:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B183A0AAD for ; Thu, 23 Jul 2020 21:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=O0w2AmuW; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=FMYNIj5/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saCGP2He-A6h for ; Thu, 23 Jul 2020 21:08:47 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D143A0AAA for ; Thu, 23 Jul 2020 21:08:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=810; t=1595563720; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=zUNnRUUBEn6Ph3ikR5MkQL+prxg=; b=O0w2AmuWJIipno1ge8yd9WoeH4gdQIIxL4fVDv1VPANT6Z7ST9oGUOVxfvH18k WE9MxnYT8/TobmqCWR06J9DUidDWRD/nGSmyGhwPXi8VolD182GvA2NAqAF0FgEM NKR31J6FSNXBGiMwGHHiJ1OnNmyFjVw1e1ViIPBHEl5hI= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 24 Jul 2020 00:08:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1996017737.1.6652; Fri, 24 Jul 2020 00:08:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=810; t=1595563616; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FoclBAV aiJp6pT1DY1MGEQGa+nvlhuYA7p/EIWv4a6A=; b=FMYNIj5/XwVZHOqRgcnN9HG /Jfa3CkeM6X+mgBdH+kIFqjkvTbrhkOhWHaSDDh2CRinykSRLlGUrRAUSOz0e5tM XBjpFRtkiYQ5glwO0OmUgJVAXMV7V4hj22aUerIoeHIHfye7H68FBdMzbJiu+CBe Z5WCBp94TEC3pCpqYP1I= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 24 Jul 2020 00:06:56 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1706791562.1.49192; Fri, 24 Jul 2020 00:06:55 -0400 Message-ID: <5F1A5ECB.7000901@isdg.net> Date: Fri, 24 Jul 2020 00:08:43 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <6160eab7-c7e7-f20b-8880-499de9733f30@bluepopcorn.net> In-Reply-To: <6160eab7-c7e7-f20b-8880-499de9733f30@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 04:08:50 -0000 On 7/23/2020 11:50 PM, Jim Fenton wrote: > On 7/20/20 11:36 AM, Seth Blank wrote: >> We have a session on the books for IETF108, and would like suggestions >> from the group for the agenda, otherwise the chairs will choose >> relevant topics. Items in tickets or from the past month are all fair >> game. >> >> Thanks, >> >> Seth, Tim, and Alexey >> > I am hoping for a resolution on whether/how to split DMARC into 2 or 3 > separate specifications (e.g., aggregated reports, failure reports, > policy). I understand the chairs were discussing this. +1. (I believe it will provide necessary focus on a DMARC-BASE spec. Its variables and outputs can be defined, registered for the DKIM-REPORTS specs.) -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jul 24 11:23: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 8639E3A116F for ; Fri, 24 Jul 2020 11:23: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, 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 (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 CiF4dCz57sGD for ; Fri, 24 Jul 2020 11:23:02 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056103A0F03 for ; Fri, 24 Jul 2020 11:23:01 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id a11so7999703ilk.0 for ; Fri, 24 Jul 2020 11:23:01 -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=kd6x/RrxzSvmmBUyP7P9GCMjDBdyyYxUL29QAFRLkbc=; b=J/qy14fyDckvwYhtSYhKpulTKav1W7c0iVezlgHbNRuAqLN0Aq/EQaGlOrzFGkpYEj WCEUe51NBemAYAuOi/hdf4qiurzgYw7iXhLd84QGK9EucnKHHzr1ulaRj+N2tpJv3xQl rOU+hsV1H6AzpiCMhakuBBDGy0yUCfm+0OPww= 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=kd6x/RrxzSvmmBUyP7P9GCMjDBdyyYxUL29QAFRLkbc=; b=SFn4YlgY3ybg0eb/sSEkopja8lPXGzBI8zjJxASu5K8jvuTMMyxfh6DQbSaOpNRi3l e/22D/wpeEDQqf7Zgpil3F2KeSGyGl10Lvz5l1SXewzfIEsvJRFlIvgtilmKF1Cf1auS NW0YNtW0GUemBSeuowP6geyBZoC3w7kluSQgxGuA0J8y4TYw9ztITdAWHFTBQIHNqjnr bMhLJyKaL+wtu4HmaAgAyOfFyD7SngQqFZvl/ODxQYoSiXvB1G+b/GeBRY0oUn7KG37k tTkr2b4qNp+aEb2ex/DPBa0xKPzBCYKHc/cl/HDYN6m67FcxFYDmPerUzlUrLV9Z8U3k crJQ== X-Gm-Message-State: AOAM533YDnHVMGJ90V3j+t3MZLmteHChONyXoWQAfy2BaoedwrvrKWvQ zJU3798Bu9IAojyCoOxNa7Vs/oWM/1pEeMWQg3OV3o3Q4sw= X-Google-Smtp-Source: ABdhPJxc78fq99KsF8LiB/wi9ZgpB8Dh9ZVqMCXZG0mDqDOgVyl0Q73ovBlwkq9gX0GT18EcgNn29hyXoabDOxGbnso= X-Received: by 2002:a92:1b5b:: with SMTP id b88mr4784552ilb.104.1595614975920; Fri, 24 Jul 2020 11:22:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 24 Jul 2020 11:22:43 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000df79fa05ab340fcd" Archived-At: Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 18:23:04 -0000 --000000000000df79fa05ab340fcd Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 11:36 AM Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions > from the group for the agenda, otherwise the chairs will choose relevant > topics. Items in tickets or from the past month are all fair game. > Based on the recent discussions that have been happening, I think that there are two key topics that should be hashed out in the F2F: 1. Jim Fenton's ask to develop a threat model; along with this I think we need to more tightly defined the problem statement 2. Is the goal of this WG to "get DMARC onto the standard track" or is it to "solve the spam problem"? --Kurt --000000000000df79fa05ab340fcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2020 at 11:36 AM Seth Bla= nk <seth=3D40valimail.c= om@dmarc.ietf.org> wrote:
We have a sess= ion on the books for IETF108, and would like suggestions from the group for= the agenda, otherwise the chairs will choose relevant topics. Items in tic= kets or from the past month are all fair game.

<= /div>
Based on the recent discussions that have been happening, I think= that there are two key topics that should be hashed out in the F2F:
<= div>
  1. Jim Fenton's ask to develop a threat model; along with this= I think we need to more tightly defined the problem statement
  2. Is t= he goal of this WG to "get DMARC onto the standard track" or is i= t to "solve the spam problem"?=C2=A0
--Kurt
--000000000000df79fa05ab340fcd-- From nobody Fri Jul 24 11:45: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 F2D203A041A for ; Fri, 24 Jul 2020 11:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SZbgJcnu; dkim=pass (1536-bit key) header.d=taugh.com header.b=VQTTUbaC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku3QaW_G6vtp for ; Fri, 24 Jul 2020 11:45:53 -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 7230A3A03EA for ; Fri, 24 Jul 2020 11:45:53 -0700 (PDT) Received: (qmail 14031 invoked from network); 24 Jul 2020 18:45:52 -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=36cc.5f1b2c60.k2007; bh=Cq29wG1M7ClVHT0STSQGuXAjEnU6UySDi64Glci8YPo=; b=SZbgJcnuzjIfITnghL7JtBK4OZataNKzC20Yf/DzDwP+bFT77V1ScMuWPwcbuvw5yfHWLmrHfmy/midjIXde1C/oQTCZ1xUHxLKWLf80/h+08C+VPJzyizxNMJxtAE9dn/k4heIb4ernKPxGgI5UYOdkP0snR3ZlL6fgtLiN9SFRpjmiSfucbbNk+1C5/nRJEV3lbRH1Hs+bb6smwueTEQ5YUryEZzqHjnUCPEVOLkB9ADr1dI+HNVUYxM0NGfEn 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=36cc.5f1b2c60.k2007; bh=Cq29wG1M7ClVHT0STSQGuXAjEnU6UySDi64Glci8YPo=; b=VQTTUbaCl6I2JcJxB/y8SzUdyM/dI+pmIsyKPXDE2cVRRIhjiKYJPKUGEdURzel+NWpk4uzjSet8/J7ocSMK7za2Rj/tMpEtPjMEgU8x5NLSJfWsEl/BheyMoGsMGa4DX0iz2SSqqt89XPz/aXM/tU7awjmaUe5kPLUM8Y3BB7JSQ7NQRzyJIdh6Al+JwIFkan6cecd8/KERjP0qj3y/aVSlc4mtx61AidpEnOwVLfi0aTKZk8GNhprQ8a1QXF84 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; 24 Jul 2020 18:45:52 -0000 Received: by ary.qy (Postfix, from userid 501) id B52CE1D761D0; Fri, 24 Jul 2020 14:45:51 -0400 (EDT) Date: 24 Jul 2020 14:45:51 -0400 Message-Id: <20200724184551.B52CE1D761D0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 18:45:55 -0000 In article you write: >-=-=-=-=-=- > >On Mon, Jul 20, 2020 at 11:36 AM Seth Blank 40valimail.com@dmarc.ietf.org> wrote: > >> We have a session on the books for IETF108, and would like suggestions >> from the group for the agenda, otherwise the chairs will choose relevant >> topics. Items in tickets or from the past month are all fair game. >> > >Based on the recent discussions that have been happening, I think that >there are two key topics that should be hashed out in the F2F: > > 1. Jim Fenton's ask to develop a threat model; along with this I think > we need to more tightly defined the problem statement > 2. Is the goal of this WG to "get DMARC onto the standard track" or is > it to "solve the spam problem"? I would hope that we'd all agree that the answer to the second question is obvious. R's, John From nobody Fri Jul 24 12:05:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7403A091B for ; Fri, 24 Jul 2020 12:05:18 -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 rorSLHEpXkwY for ; Fri, 24 Jul 2020 12:05:17 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71923A087D for ; Fri, 24 Jul 2020 12:04:40 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id k20so1481208wmi.5 for ; Fri, 24 Jul 2020 12:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Q0Obena+8nE7TYPu9xWIyWhwh2vZuM0NqnCcEiMq9ng=; b=kUNaT0vWtvvSvHbdWLFAIPCZXVqoUm6gRehZmLqjRH3wPSvqYkqgQ0vxoIYnG8dXtB C2mjP+o8zxM9Zs7zZIwqUjhd356N8tTtSe2oTB0nY8/+ZZ1osh56bug5DuCalx1ZKLXC tCzCwzg7ukqEHULXCl+p5Uf1NXPCT5qzRcXJ4NNvkrFKvW5HaNojZiXzr1d2/A/OE+JX InLsFdms0wzwF4dcZoEkx0ZdWRlHiyF3bTXyjRcPt6cD/4C/tiY3tC7pw0bHnsbI47Kp 9e91TqG0pPniLrCbnj0seYj9OgGBdaNV6J2pphR2hfg0qQr2/0VyqalZpa4VRM/NiNVh s57g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Q0Obena+8nE7TYPu9xWIyWhwh2vZuM0NqnCcEiMq9ng=; b=T7koFAOfE+qi3wZNQaYM7S8v4UkAQUlL79/rjugUAsxmf86tXXj4OMz1e9IOouVfWR sYwJ9hcnsTSXQ/WKVTd3q7wMXDJVqx5svR5nc1qhZa4n8eaWOCwB9uvpNoT3Mm2wKtsO 2u8vpMJsZX6WOsDlRQYmbSlhDVx0TPgUS2UvNWmh5wc8ubhzR8pBFYc1lDD8RKmCaz/D u8E4bai1vxGwR+jGtGo3WJCoVAxAj4fN+QVBIsW0ofsmTJnmWMG1sD6kokmCsuljdusM R5GVXFHjfFKH+riJFtzhOHn7+r/u4ZJrkk1f0cbHUrjW1lk0Bxo8tZZSpj6qMDXaNExm ngUQ== X-Gm-Message-State: AOAM530fKTk4lF37ukGVtV0+gO5dQFFydhDsZyM6IKPcC8mkJjnfsJcS 9aBHXgpFbvY4GAbkxykaUibxewXHr1F83ZxCqjDpJw== X-Google-Smtp-Source: ABdhPJzguyeDOBi3ld7dgPuHjfZu6u5CNXM4LdxRj9ncZxZBYW0TLVvUwKSPNPRsmvnzBDWKelmp/qtORMAVCo4vss0= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr9584697wml.36.1595617479180; Fri, 24 Jul 2020 12:04:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Fri, 24 Jul 2020 15:04:29 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000b456805ab34a5dc" Archived-At: Subject: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 19:05:19 -0000 --0000000000000b456805ab34a5dc Content-Type: text/plain; charset="UTF-8" Apologies, I intended on sending this to the group rather than just Seth. ---------- Forwarded message --------- From: Dotzero Date: Fri, Jul 24, 2020 at 3:03 PM Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF To: Seth Blank On Mon, Jul 20, 2020 at 2:36 PM Seth Blank wrote: > We have a session on the books for IETF108, and would like suggestions > from the group for the agenda, otherwise the chairs will choose relevant > topics. Items in tickets or from the past month are all fair game. > I would like to see an agenda item as to whether work around "Display Name" changes are in scope or out of scope for this effort and this working group. It would seem to me that any such efforts are more appropriate for the emailcore working group. I also concur with Kurt Anderson's agenda suggestions. It seems like the discussions are all over the place and it would be useful to have a clearer focus on what we are trying to fix/achieve in our discussions. It would also be nice to get some updates on the status of ARC, which is supposed to address the concerns regarding intermediaries vis a vis DMARC. If it is working as intended is it a deployment issue? If it is working as intended do we need duplicative efforts? I am asking questions, not suggesting answers. Michael Hammer --0000000000000b456805ab34a5dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Apologies, I intended on sending this to the group rat= her than just Seth.
---------- Forwarded message ---------
From: Dotzero <= dotzero@gmail.com>
Da= te: Fri, Jul 24, 2020 at 3:03 PM
Subject: Re: [dmarc-ietf] Agenda reques= ts for Madrid IETF
To: Seth Blank <seth=3D40valimail.com@dmarc.ietf.org>


On Mon, Jul 20, 2020= at 2:36 PM Seth Blank <seth=3D40valimail.com@dmarc.ietf.org> wrote:
<= /div>
We = have a session on the books for IETF108, and would like suggestions from th= e group for the agenda, otherwise the chairs will choose relevant topics. I= tems in tickets or from the past month are all fair game.
=C2=A0
I would like to see an agenda item as to whether= work around "Display Name" changes are in scope or out of scope = for this effort and this working group. It would seem to me that any such e= fforts are more appropriate for the emailcore working group.
=
I also concur with Kurt Anderson's agenda suggestions. I= t seems like the discussions are all over the place and it would be useful = to have a clearer focus on what we are trying to fix/achieve in our discuss= ions.

It would also be nice to get some updates on= the status of ARC, which is supposed to address the concerns regarding int= ermediaries vis a vis DMARC. If it is working as intended is it a deploymen= t issue? If it is working as intended do we need duplicative efforts? I am = asking questions, not suggesting answers.

Michael = Hammer
=C2=A0
--0000000000000b456805ab34a5dc-- From nobody Fri Jul 24 12:24: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 0E83D3A0985 for ; Fri, 24 Jul 2020 12:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoWhUE0mXdTH for ; Fri, 24 Jul 2020 12:24:07 -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 EE4703A0980 for ; Fri, 24 Jul 2020 12:24:06 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06OJQeJn013924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 24 Jul 2020 12:26:41 -0700 To: IETF DMARC WG References: Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <68b8bb2f-6832-a620-332b-2465b985cfc4@dcrocker.net> Date: Fri, 24 Jul 2020 12:24:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 19:24:08 -0000 On 7/24/2020 12:04 PM, Dotzero wrote: > It would also be nice to get some updates on the status of ARC Getting status updates is, of course, useful. However I will strongly suggest that that be done on the mailing list.  Real-time sessions are rare and short, so we should try to budget their time only for things that require real-time interaction. Asking for status updates to be posted before the session leaves open the possibility of raising questions or comments, as follow-on, without taking time for the basic 'presentation'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 25 06:48:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524383A113F for ; Sat, 25 Jul 2020 06:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLQdQ30HFHc1 for ; Sat, 25 Jul 2020 06:48:43 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 4BA9F3A1137 for ; Sat, 25 Jul 2020 06:48:38 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id g4so3903700uaq.10 for ; Sat, 25 Jul 2020 06:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9L6rfPl9EY9a8xm9vGTSO/t0Fd+dEt5+85NypDL3+6I=; b=T2C333UNptfSR7W5Fhsl554tuCofwvZPZpNoo9XGtWAdOcp1KqVac6oKu6+26JJ99r r39GaNASViWTNI53Qysa9WYgZJNgL/CyW5sWMEr06YdBVv0RXKG1wvdSlcnU37CHHT4W K0tSnrRRIAVU1Dfp8BTMlYHd5oAwxiLC/m6reF+3bQYB0ok0JJCgmss/VUasHUev7yb+ voBm0l5qkqN+LbhYwhFlXzG9fRIubPqzEkCtAl5cjE4a6ZDGXvqbCxuHt8h7Di6TalNk tRANukP9/gTpb+SpLF29UL9N3OQYzaUhGQ+H3IZ6FvAxsTRXr77bdo9/bH13FhvNMazg +qJA== 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=9L6rfPl9EY9a8xm9vGTSO/t0Fd+dEt5+85NypDL3+6I=; b=MqI44bOAdo2SHHI+y9w/xnOggw32Fjfg1NuzcunbmYYt5FWiRMyg8N8HBNroZLZgXR juMnnFt5TuLymSuKBxVt65D3+vj6FjEM0dJRYtC5LmFHR3DjruelREjQKYBUz1UJGScu Q4W2ZOZEusnmLZ7lwlcWbSZ5p1L4c4Uton9WOc+Ic2XrURgbwkjIjZwKrka0AlwQmT46 JoRlFS8A0ffU3JBKeV/XWv32dIHm/+AXJIekKkklXVhrIbn1pQgD4R5y6eVKJp/Y8tmP NUmy3qQwyYJxmQNr2NBGJepey4NMdE9AAl55OY2CVPEEEezGQVgGTGRhUBOnokAOYM/+ UCRQ== X-Gm-Message-State: AOAM533tPubaM2vJedW9YzsaR73yKLWDcz+LEoJoFhWBqFCYAwr0yy0P LaP3TyUuV/aHyk/fOCQ5gDsTSlbKxZtDi97lodk= X-Google-Smtp-Source: ABdhPJyLrmDJ7b8wkeClATbvqfgHc9DJlDYw6z13eEfpmoqGywvbwcE1FvkJCLol+ST8CjxGY6rhv/HHngK6C8CWd/I= X-Received: by 2002:a67:f60c:: with SMTP id k12mr11202289vso.8.1595684916972; Sat, 25 Jul 2020 06:48:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 25 Jul 2020 06:48:22 -0700 Message-ID: To: Dotzero Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a64ded05ab44584d" Archived-At: Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 13:48:51 -0000 --000000000000a64ded05ab44584d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: > I would like to see an agenda item as to whether work around "Display > Name" changes are in scope or out of scope for this effort and this working > group. It would seem to me that any such efforts are more appropriate for > the emailcore working group. > A quick read of the current charters suggests to me that it's in scope for neither. That seems to be especially true for emailcore. Do you have such a change to propose? -MSK --000000000000a64ded05ab44584d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 24, 2020 at 12:05 PM Dotzero = <dotzero@gmail.com> wrote:
I would like to see an agenda item as to whethe= r work around "Display Name" changes are in scope or out of scope= for this effort and this working group. It would seem to me that any such = efforts are more appropriate for the emailcore working group.

A quick read of the current charters suggests = to me that it's in scope for neither.=C2=A0 That seems to be especially= true for emailcore.

Do you have such a change= to propose?=C2=A0

-MSK
--000000000000a64ded05ab44584d-- From nobody Sat Jul 25 07:29:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0F93A1358 for ; Sat, 25 Jul 2020 07:29: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=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 ocAPUprZy1ht for ; Sat, 25 Jul 2020 07:29:43 -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 B0B083A11FD for ; Sat, 25 Jul 2020 07:29:23 -0700 (PDT) X-ASG-Debug-ID: 1595687361-11fa3118c715e40001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id r2aU16rxnyE6JBBU (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 25 Jul 2020 10:29:22 -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=28SRI6+XdPPLtsDekGh00KkicriYFhExu9n+QNTfmNE=; b=aEpnvJg+Oc47LuI5FTvpOClR9EZYAvQOOZe314p1ZHW1CaliI1PSC8mcdOGxcMml6 wYtfQ/fDQUmrlWfJrixtYMT+po42vNdbEMnfUeMo5fPjwF19ESdi0BXTs36N3AI9I 43QxOiwHU1UFIqg1wom7ZyE1WAEmY6Y+EoWdKPfMw= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 25 Jul 2020 14:29:13 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=5e82fcaae12c47dab86a98e17297f350 In-Reply-To: References: X-Exim-Id: eb4c1ff1c6b34c60b7f0bb60b183f9f6 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595687362 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: 6568 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.83452 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 14:29:52 -0000 This is a multipart message in MIME format. --5e82fcaae12c47dab86a98e17297f350 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support an initiative to validate other parts of the mail message, to inh= ibit the ability of criminal actors to spoof recipients. The topics that = I think need attention include: Control untrusted content in the Friendly Name. As suggested, a mechanism= is needed to hide or remove untrusted Friendly Names. This seems to requi= re a way to sign the message with and without the Friendly Name included, a= s well as methods to configure policy defintions for Friendly Name trust. Obstruct hijacking of corporate logos. Existing work with Digital Rights = Identifiers seems to be the starting point for this effort. Validate routing paths and detect suspicious routes. ARC seems to provid= e this opportunity. Currently, any Received header, prior to the first o= ne, cannot be fully trusted, because it might be spoofed. This is a sourc= e of concern even if criminals are not yet spoofing this content. ARC pr= ovides the opportunity to distinguish verified Received headers from unveri= fied ones. The potential benefits of this information for spam filtering = are not yet clear, but I believe those opportunities will become evident in= the future. Embrace multiple authorship. We need to provide spam filters, mailing lis= ts, and other intermediaries with the ability to add signed content without= destroying existing signatures,. This will require MUAs that understand t= he multiple authors and can use that knowledge to display the content of di= fferent authors with appropriate identifying information. It will also req= uire supporting protocols to allow incoming gateways and individual users w= ith the ability to control whether an addition is trusted and visible or un= trusted and hidden. These initiatives will add complexity to the email evaluation process. We= know that anything which adds complexity will also create risk that email = gateways will become confused and therefore vulnerable. These initiative= s must be carefully vetted to avoid creating new attack methods. The crim= inals seem to have more imagination than the rest of us, so attack methods = can be difficult to predict. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" Sent: 7/25/20 9:49 AM To: Dotzero Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: I would like to see an agenda item as to whether work around "Display Name"= changes are in scope or out of scope for this effort and this working grou= p. It would seem to me that any such efforts are more appropriate for the e= mailcore working group. A quick read of the current charters suggests to me that it's in scope for = neither. That seems to be especially true for emailcore. Do you have such a change to propose? -MSK --5e82fcaae12c47dab86a98e17297f350 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I support an initi= ative to validate other parts of the mail message, to inhibit the ability o= f criminal actors to spoof recipients.   The topics that I think need = attention include:
  • Control untrusted content in the Friendly N= ame.   As suggested, a mechanism is needed to hide or remove untrusted= Friendly Names.  This seems to require a way to sign the message with= and without the Friendly Name included, as well as methods to configure po= licy defintions for Friendly Name trust.

  • Obstruct hijacking= of corporate logos.   Existing work with Digital Rights Identifiers s= eems to be the starting point for this effort.

  • Validate rou= ting paths and detect suspicious routes.    ARC seems to provide = this opportunity.    Currently, any Received header, prior to the= first one, cannot be fully trusted, because it might be spoofed.   Th= is is a source of concern even if criminals are not yet spoofing this conte= nt.    ARC provides the opportunity to distinguish verified Recei= ved headers from unverified ones.   The potential benefits of this inf= ormation for spam filtering are not yet clear, but I believe those opportun= ities will become evident in the future.

  • Embrace multiple a= uthorship.   We need to provide spam filters, mailing lists, and other= intermediaries with the ability to add signed content without destroying e= xisting signatures,.  This will require MUAs that understand the multi= ple authors and can use that knowledge to display the content of different = authors with appropriate identifying information.  It will also requir= e supporting protocols to allow incoming gateways and individual users with= the ability to control whether an addition is trusted and visible or untru= sted and hidden.
These initiatives will add complexity to the= email evaluation process.   We know that anything which adds complexi= ty will also create risk that email gateways will become confused and there= fore vulnerable.    These initiatives must be carefully vetted to= avoid creating new attack methods.   The criminals seem to have more = imagination than the rest of us, so attack methods can be difficult to pred= ict.

Doug Foster

From: "Murray S. Kucherawy" <= ;superuser@gmail.com>
Sent: 7/25/20 9:49 AM
To: Dotzero <dotzero@gmail.com>
Cc: I= ETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc= -ietf] Fwd: Agenda requests for Madrid IETF
On Fri, Jul 24, 2020 at 12:05 PM Dotzero <dotzero@gmail.com> wrote:
I would like to see an agenda item as to whether wor= k around "Display Name" changes are in scope or out of scope for this effor= t and this working group. It would seem to me that any such efforts are mor= e appropriate for the emailcore working group.

<= /div>
A quick read of the current charters suggests to me that it's in = scope for neither.  That seems to be especially true for emailcore.

Do you have such a change to propose? 

-MSK
--5e82fcaae12c47dab86a98e17297f350-- From nobody Sat Jul 25 09:33:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B453A0C56 for ; Sat, 25 Jul 2020 09:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=KCFapDuf; dkim=pass (1536-bit key) header.d=taugh.com header.b=bqmWTmVP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPPIhlubKC8Q for ; Sat, 25 Jul 2020 09:33:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676E23A0B30 for ; Sat, 25 Jul 2020 09:33:18 -0700 (PDT) Received: (qmail 23446 invoked from network); 25 Jul 2020 16:33:17 -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=5b8c.5f1c5ecd.k2007; bh=KTPLlHiY0qodF/OQegBnW2HAuQxbNT+OijQEpBckhxg=; b=KCFapDufwn4aqyRFfukg4Uf+WMMF5fAtpcxMTRSWpU5zXJSqKzLxQmt6gnuepiIgrpwEX9gdFwvr6jiWR+L4WbQ/qnn701kldEY7F6DHjyq6yziAVhvIaOJGAFq954amIuFFfZh5mqeIDW4wSzIByD3aeSuNLHxGzcWRiJ6wx2hn4Q3vRp34WGDcTKigiwESAM7/dhxct7ezC71jEGnr20VS7NT/GDR5ADoO75bF9ct2itDAR5FeI+WFFLfVlv26 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=5b8c.5f1c5ecd.k2007; bh=KTPLlHiY0qodF/OQegBnW2HAuQxbNT+OijQEpBckhxg=; b=bqmWTmVPxh6cBq5hwMykBDex5OGUBD/mb7TFQV5vt9bdKWLLCBT8uy3YL6QPdZ5+XRZR45c/OzRHWm+bHzErA1v1LLBh6K7Sni6EeV0AE0k0fihqWGaftFKpNdFfoID9lcIQxJjVsCNUHJMqc4zeOGYUj1o2JckU2QpqIdDENg1GRuFi2Gns9zyjB8XLqdUru7xEEQQqxiGQccBVgZmk+LmlRR5jyp60cFCGgN8mTwX7+2DYOqJsSaCafc2miwER 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; 25 Jul 2020 16:33:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 78F321D7CDE3; Sat, 25 Jul 2020 12:33:16 -0400 (EDT) Date: 25 Jul 2020 12:33:16 -0400 Message-Id: <20200725163316.78F321D7CDE3@ary.qy> From: "Not Douglas Foster" To: dmarc@ietf.org 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] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 16:33:20 -0000 In article you write: >-=-=-=-=-=- > >I support an initiative to validate other parts of the mail message, to inhibit the ability of criminal actors to >spoof recipients. I'm reasonbly sure there's no way we can tell in a software protocol whether someone who is sending a message is a criminal, and it is quite clear from recent discussion that there is no agreement about what "spoof" means when applied to e-mail. Neither of these seem like fruitful directions. I can also say that attempting to validate the unstructured name comments is a hopeless swamp if you limit yourself to ASCII and bottomless pit of despair once you remember that for 30 years MIME has let you use any text in any character set. R's, John From nobody Sat Jul 25 19:00: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 2E98D3A0883 for ; Sat, 25 Jul 2020 19:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEwWtaIbVcSZ for ; Sat, 25 Jul 2020 19:00:53 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 08AE83A0881 for ; Sat, 25 Jul 2020 19:00:52 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id a14so11568208wra.5 for ; Sat, 25 Jul 2020 19:00:52 -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=AaqAkaEj93DuC0eaTSCFZKiuo8Bun2Ivwl3HYWkS7g0=; b=HrGteWG6bZJxshmU29UhJNay1HGaeOg5fc636E1gddWcYQ9m+EvH3ECmQTfwnQL03r kp3Fbc/Ndb+d9w3hmy5QgQOQthTbDBxYoZrCiK34xVUoCEHTC+hex7blylXmxNPf0cyO v3ZVtleQd4dMu2bzvPyKnYWydDdKPHhxPC/KTxVvPupUH1Gg3lhkKOwew2Ho+p5YACVI OJ7ARRwGGVH2wGtdSZSWm8g961y1TdxqqXxq7YMBqn/iWf5KtGLJbQBAgIGGPp7AfAvN dAtQpSkKNyVvtmbWB413CpIruSG6+wJK/eJjhq9wbiwy/S624Hqz0bkknIap1HAOumrg kv9g== 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=AaqAkaEj93DuC0eaTSCFZKiuo8Bun2Ivwl3HYWkS7g0=; b=UycHvHoR7yiiI1Rh7ip0E6OoPZ801r7Yu+TzrMVWuo5fphyUIc9fVj/1b8AZVp6d3I XimBlxGkpuQOBRF9xLBr12NjBaAxsxjWW35NrqSb4K7ceG4B1nS1GBp98aDvVDt64Evc FdcDv0WT95+68sqERq2svx7MkcNLLUXIJwhc1Vcxtolaa3HFLS4icYSrqkk9a2p/uDFu TKhO/1cTnbD7DM5oC0xeJ+tXiVv220Dp7J0bG9zvnkowJKRLhvq2X+bgkyXEGdiS2CRv bEbhDoNMmusruXyxStEUgLF+M5beTlrHjVe4UYeE11iV5seTEUhsXuWP4OnddaQvh+Fs Am8w== X-Gm-Message-State: AOAM532bXs/katsysFU11tX+w7m5xa4w0mL5Mzlgu7zPwmoP4hidI9G9 6yxenDA00vg3jPqIFrIu835Wl/ThMD8+lisvKk4= X-Google-Smtp-Source: ABdhPJwY8I73OIid7+NJk2j0VjWFjrzWYKSGFfOb6uRtBfKwc7ED+WYahT677Oc46fThJd44/uH7ElzOYLevaxpR9WU= X-Received: by 2002:adf:9526:: with SMTP id 35mr15367775wrs.326.1595728851358; Sat, 25 Jul 2020 19:00:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Sat, 25 Jul 2020 22:00:40 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000057d92305ab4e938e" Archived-At: Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 02:00:56 -0000 --00000000000057d92305ab4e938e Content-Type: text/plain; charset="UTF-8" On Sat, Jul 25, 2020 at 9:48 AM Murray S. Kucherawy wrote: > On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: > >> I would like to see an agenda item as to whether work around "Display >> Name" changes are in scope or out of scope for this effort and this working >> group. It would seem to me that any such efforts are more appropriate for >> the emailcore working group. >> > > A quick read of the current charters suggests to me that it's in scope for > neither. That seems to be especially true for emailcore. > > Do you have such a change to propose? > > I was hoping for a ruling that such an effort be ruled out of scope for the DMARC effort/working group and further discussions be limited by the Chairs. As "Not Douglas E. Foster" (John Levine) noted, it is a free form field. DMARC has been intended from the start to mitigate direct domain abuse by 3rd parties. I'm hoping that the working group will make better progress by focusing on issues specific to DMARC and not try boiling the ocean by trying to "fix" all forms of abuse through this effort. Display Name abuse is a broader problem that DMARC simply is not in a position to address. This is especially true as most current implementations are at the MTA and MUA providers are not visible among the participants in this working group. My opinion is that trying to address this problem space in this working group is somewhat like trying to push on a rope. If the Chairs are willing to make this call then there is no need to have it as an agenda item for the session given the limited amount of time and the number of other issues that might be better addressed using that limited time. Michael Hammer --00000000000057d92305ab4e938e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jul 25, 2020 at 9:48 AM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Fri, Jul 24, 2020 at 12:05 PM Dotzer= o <dotzero@gmail.= com> wrote:
I would like to see an agend= a item as to whether work around "Display Name" changes are in sc= ope or out of scope for this effort and this working group. It would seem t= o me that any such efforts are more appropriate for the emailcore working g= roup.

A quick read of the current= charters suggests to me that it's in scope for neither.=C2=A0 That see= ms to be especially true for emailcore.

Do you= have such a change to propose?=C2=A0

<= /blockquote>

I was hoping for a ruling that such an effo= rt be ruled out of scope for the DMARC effort/working group and further dis= cussions be limited by the Chairs. As "Not Douglas E. Foster" (Jo= hn Levine)=C2=A0 noted, it is a free form field. DMARC has been intended fr= om the start to mitigate direct domain abuse by 3rd parties. I'm hoping= that the working group will make better progress by focusing on issues spe= cific to DMARC and not try boiling the ocean by trying to "fix" a= ll forms of abuse through this effort. Display Name abuse is a broader prob= lem that DMARC simply is not in a position to address. This is especially t= rue as most current implementations are at the MTA and MUA providers are no= t visible among the participants in this working group. My opinion is that = trying to address this problem space in this working group is somewhat like= trying to push on a rope.

If the Chairs are willing to make this ca= ll then there is no need to have it as an agenda item for the session given= the limited amount of time and the number of other issues that might be be= tter addressed using that limited time.

Michael Ha= mmer
--00000000000057d92305ab4e938e-- From nobody Sun Jul 26 02:45:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB073A0D25 for ; Sun, 26 Jul 2020 02:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2HNSL_gLr-M for ; Sun, 26 Jul 2020 02:45:52 -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 CC7CF3A0D24 for ; Sun, 26 Jul 2020 02:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595756748; bh=Krz+cLCKWcFQLTUipxrHzTeJMzbwT10cpwQ28sqDSeE=; l=2387; h=To:References:From:Cc:Date:In-Reply-To; b=CxBqUGqBYvTxmW1cM6p8nkDAsc13sDAV4D/vivehqrGw4xyV5idKDpOi2pCGylqKY S5+EgpjC0Ak86dL1LHjW3zn94urm6l1F81XgQuF/TB8RPO7QdDeFJQwm47GhtJZiV9 QUiKZ+ptA4DOTCk22OQg+zdZt+3Xh743S+qo+5CIukQRoanZdshhSodRXDFQa 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.000000005F1D50CC.00003061; Sun, 26 Jul 2020 11:45:48 +0200 To: Dotzero , "Murray S. Kucherawy" References: From: Alessandro Vesely Cc: dmarc@ietf.org Message-ID: Date: Sun, 26 Jul 2020 11:45:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 09:45:57 -0000 On Sun 26/Jul/2020 04:00:40 +0200 Dotzero wrote: > On Sat, Jul 25, 2020 at 9:48 AM Murray S. Kucherawy wrote: >> On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: >> >>> I would like to see an agenda item as to whether work around "Display >>> Name" changes are in scope or out of scope for this effort and this working >>> group. It would seem to me that any such efforts are more appropriate for >>> the emailcore working group. >>> >> >> A quick read of the current charters suggests to me that it's in scope for >> neither. That seems to be especially true for emailcore. >> >> Do you have such a change to propose? >> >> > I was hoping for a ruling that such an effort be ruled out of scope for the > DMARC effort/working group and further discussions be limited by the Chairs. > As "Not Douglas E. Foster" (John Levine) noted, it is a free form field. Although out of scope, I'd still propose that display name abuse be explicitly mentioned in one of the specs as an out-of-scope problem that has to be solved at a different level. > DMARC has been intended from the start to mitigate direct domain > abuse by 3rd parties. I'm hoping that the working group will make better > progress by focusing on issues specific to DMARC and not try boiling the > ocean by trying to "fix" all forms of abuse through this effort. Display > Name abuse is a broader problem that DMARC simply is not in a position to > address. This is especially true as most current implementations are at the > MTA and MUA providers are not visible among the participants in this > working group. My opinion is that trying to address this problem space in > this working group is somewhat like trying to push on a rope. Let me add that, for the sake of Murray's dkim-transform, unlike subject tag and footer additions which only need a couple of bits to be undone, display name removal would require the full original header field, as in a (partial) z= tag. BTW, dkim-transform, along with From: rewriting, using To:, using Author:, and giving up any modifications make for an effective solution of the MLM problem. None of them belongs specifically to DMARC, albeit the spec could mention them. Dkim-transform, in particular, looks like an update to RFC 6376. Yet, it might be practical for this WG to adopt it. Shall we discuss that F2F? Best Ale -- From nobody Sun Jul 26 04:33:14 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 785813A0DC5 for ; Sun, 26 Jul 2020 04:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgji2yHuOaPm for ; Sun, 26 Jul 2020 04:33:09 -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 4A2013A0DC2 for ; Sun, 26 Jul 2020 04:33:06 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QBZeMZ031222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 04:35:41 -0700 To: Alessandro Vesely , dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <9e9616aa-ea9e-836c-6319-377e7db80193@dcrocker.net> Date: Sun, 26 Jul 2020 04:32:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:33:13 -0000 On 7/20/2020 1:44 AM, Alessandro Vesely wrote: > On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote: >> The essential point that needs to be made is that standards like this >> MUST NOT be cast in terms of what end users will do.  In practical >> terms, this work has nothing to do with end users. Really.  Nothing. >> [...] >> (*) I've seen one posting here or somewhere else that noted that >> letting bad mail through can lead to end-users being deceived. I'll >> claim that while true, it is not relevant, since the behavior happens >> after DMARC, and the like, are relevant.  That is, DMARC, etc., do >> not inform the end-user behavior. > > Aren't those two paragraphs self-contradictory? No. A specification defines a field of activity.  (A sandbox.) Things outside that field are not relevant to the specification, even though they might be highly relevant from a larger perspective. There is a constant desire to have a specification that involves security-related decision-making include the (human) recipient be an actor within the scope of the specification. The first paragraph, quoted above, is a reminder that we need to resist that desire. The second paragraph, quoted above, is a reminder about a specific example of this, namely about the DMARC specification. It acknowledges that, in general, recipients can be deceived, for the specific From: field protection that DMARC provides, the recipient is not a relevant actor. > If DMARC were dependable, maybe users would learn to trust From:. Or > maybe not.  Avoiding end user considerations cuts both ways. Yet, we > can trust that if we do a well-defined, clear job, then the whole > system will work better. It is expensive and highly risky to create an international standard that relies on such a tenuous hope about future behavior, especially in the face of consistent empirical evidence that it won't happen. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 26 04:40: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 6F8283A0DC3; Sun, 26 Jul 2020 04:40:28 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tadKVrDlKICf; Sun, 26 Jul 2020 04:40:26 -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 AF71C3A0B96; Sun, 26 Jul 2020 04:40:26 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QBh17H031741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 04:43:01 -0700 To: Jesse Thompson References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> Date: Sun, 26 Jul 2020 04:40:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E30D9916A69077083CCF5585" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:40:29 -0000 This is a multi-part message in MIME format. --------------E30D9916A69077083CCF5585 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/20/2020 3:05 PM, Jesse Thompson wrote: > On 7/19/20 1:33 PM,dcrocker@gmail.com wrote: >> The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users.  Really.  Nothing. >> >> To the extent that anyone wants to make an affirmative claim that end-users/are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*) > I'll take a shot (admittedly, I'm having trouble keeping up with all of the points that have been made): > > We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC- ... > ** We have had many complaints from users about the From munging ** My wording was not careful enough.  What I /meant/ was: end-users are not relevant to the /trust-related decision making/ that is the goal of these protection mechanisms. They certainly /are/ relevant to the sorting/searching/presentation issues that are disrupted by having mail authored by the same person contain different From: field data. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------E30D9916A69077083CCF5585 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/20/2020 3:05 PM, Jesse Thompson wrote:
On 7/19/20 1:33 PM, dcrocker@gmail.com wrote:

The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users.  Really.  Nothing.

To the extent that anyone wants to make an affirmative claim that end-users /are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*)

I'll take a shot (admittedly, I'm having trouble keeping up with all of the points that have been made):

We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC-
... 
** We have had many complaints from users about the From munging **


My wording was not careful enough.  What I /meant/ was:  end-users are not relevant to the /trust-related decision making/ that is the goal of these protection mechanisms. 

They certainly /are/ relevant to the sorting/searching/presentation issues that are disrupted by having mail authored by the same person contain different From: field data.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------E30D9916A69077083CCF5585-- From nobody Sun Jul 26 06:42:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791C63A0EBE for ; Sun, 26 Jul 2020 06:42:20 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkd-y4_VBS5a for ; Sun, 26 Jul 2020 06:42:18 -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 584533A0EC0 for ; Sun, 26 Jul 2020 06:42:18 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QDio2O009350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 06:44:51 -0700 To: Dotzero , IETF DMARC WG References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> Date: Sun, 26 Jul 2020 06:42:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BC0D3A26AE2F50888A62ED71" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 13:42:21 -0000 This is a multi-part message in MIME format. --------------BC0D3A26AE2F50888A62ED71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/2020 12:32 PM, Dotzero wrote: > > The original DMARC effort was, in fact, to detect actual cases of > spoofing, namely unauthorized use of a domain name by outside actors. > > Different problem. > > > Actually, part of the effort was to enable Sending domains to identify > their own mail that was being sent without aligned DKIM signing or > from places not authorized through SPF - in other words, not properly > authorized but legitimate, hence feedback loops. As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders. What you describe was,  rather, the basis for the later use, which is what then started causing problems for mail going through Mediators. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------BC0D3A26AE2F50888A62ED71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/21/2020 12:32 PM, Dotzero wrote:
The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.


As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders.

What you describe was,  rather, the basis for the later use, which is what then started causing problems for mail going through Mediators.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------BC0D3A26AE2F50888A62ED71-- From nobody Sun Jul 26 06:50: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 37EA83A0ECA for ; Sun, 26 Jul 2020 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NofXMcOoESH for ; Sun, 26 Jul 2020 06:50:02 -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 2E0173A0EC9 for ; Sun, 26 Jul 2020 06:50:02 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QDqWK0009847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 06:52:32 -0700 To: Brandon Long Cc: Dotzero , IETF DMARC WG References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <2f231818-5c25-eca3-9db6-3af0fba7d5c8@gmail.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 26 Jul 2020 06:49:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 13:50:04 -0000 On 7/21/2020 1:42 PM, Brandon Long wrote: > Stricter validation is not an uncommon addition to protocols over the > last 45 years. If there are examples of adding stricter validation in a way that essentially requires changing the semantics of the payload, in order for the payload to survive, I can't think of any. Not TLS, not DNSSec, not S/MIME or PGP. DMARC essentially enforces a semantic on the From: field as a handling identifier, rather than an author identifier. When activity that has a long history of semantic validity and a continued desire for operation is forced to break the denotational source of authoring information, in order to get the mail delivered, then we are in new territory. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 26 08:17: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 677213A0F45 for ; Sun, 26 Jul 2020 08:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=dMDvr2Mb; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=l3lUkh9j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80FN6XBW1ZsC for ; Sun, 26 Jul 2020 08:17:06 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D983A0F43 for ; Sun, 26 Jul 2020 08:17:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=596; t=1595776620; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=pTqezOJjKSpXjbdTgxEfw+7xiDw=; b=dMDvr2MbjeHtI5qv+or3ZxlVhVCNnbMpGcXVW7R1q4MfEXl1yZTXwFNvniTJnm Ljzm+2Ex6tJ5ktaEsnKJ37K1s57bYevQA1BypuP2U10Klne+b7VEfDVPZHd4Y8G3 f69i0H34NJJ0ZjIJrBiVK8ibSr019Hs7NPx8mFBzfnU2Q= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 11:17:00 -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 2208915047.1.4800; Sun, 26 Jul 2020 11:16:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=596; t=1595776513; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=u4VtEe1 k0Ligjq7o6H4o+kCK+VtFg2cPgNndXubWOkQ=; b=l3lUkh9jw7oX0LJePYhKHjn dVd7b4eP2o7Fa/MeqxOqLqaumjGKs5gXmbY3+mWRc9biPWrTCdlUDwVYkHanCLKd dRvXN9vUnuWOFKA5XhO33yEjnuZi7SXN7jNrRZqCg5wrSP57QTJi6R2qY4Lns6km gTvVtDKiQIOqdktusaP0= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 11:15:13 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1919687890.1.54660; Sun, 26 Jul 2020 11:15:12 -0400 Message-ID: <5F1D9E69.5060605@isdg.net> Date: Sun, 26 Jul 2020 11:16:57 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> In-Reply-To: <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 15:17:08 -0000 On 7/26/2020 7:40 AM, Dave Crocker wrote: > My wording was not careful enough. What I /meant/ was: end-users are > not relevant to the /trust-related decision making/ that is the goal > of these protection mechanisms. This may be a philosophical theory, but in reality, in lieu of having deterministic mechanisms, we do have mail systems who do allow the user to make these type of trust decisions. If a trust-related question is answered wrong by the user, the true victim is the honest sender. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Jul 26 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 CF2E53A0FAF for ; Sun, 26 Jul 2020 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 gdDqGwDR-nLM for ; Sun, 26 Jul 2020 09:12:42 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8E53A0FAE for ; Sun, 26 Jul 2020 09:12:42 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id u24so2461863oiv.7 for ; Sun, 26 Jul 2020 09:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=yt66CbaUBgdO/W63SQ12fa1faOJqiKG4UKQIkJuK/XM=; b=WA/m4yy4/lGbzuhG9AaKmDcixiVV2YRt+ONN6WAW3DVLoLfTM3xj7zFaWn7e8ovt+d S0sYoc6LwKyxCMMv/moQDuqGV2aUuKLaigNI4HEbecWjXAStxeSoLffBrasflDlYn6is cvLN3aXWW+49FLhoeDuc3AwIMKVdk3buO2SWu42DdBieqM1ndd+whntD+RkoFSx8AEwj 7/wFt5HPLTFy8K3S1cfPqjK6sJ7eRB9IzN8luHNqFYC/9cs9tz7GhigTGAcAE0oe78Cb lv/QMkQ1ALuw1Zq8GQdmcfMXBJAlx952vhYznpGr7gvtVYM3BgFpd338RbpRl51zWD7u WuyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yt66CbaUBgdO/W63SQ12fa1faOJqiKG4UKQIkJuK/XM=; b=GSLLQiaZs99zPwjU2P0oslixrwvvlKNPvcojpf9l/8/Kl7yLNn2IcJXk4ysCIcgh+n R1psP/sIXGmYbAJOd80U/ZlBnWLieo43rU+/4lcEetW22N/LiwrzwBgkW5Hp2UfTHM7R YQmYGXK1TW5fj8D1fWnVD7Iotl3AXv23kJLbZJPXJmfbs/BoRvReooEGdTPnv46eKxS9 MpnkpRj6pJPhCOdbsYiK+zmR6vKiLbDcmkVsgLrjwin3ScK3i7XQd333M9ZRo9BrE5Ux /htaJ0WOevwdf1N2jrBPx6Ky2SP4yzCvhC9czBolTGYDW0DFprQiXplN+50J6gvP0Nm9 4OLg== X-Gm-Message-State: AOAM5324vHLVvTZCbcBIplLxinct4CQBQg+ZAbHWid6jSpLHoj3KYX7L W+vd0xG3Jc3OBL/LaSEYbX5XmtbNWvM= X-Google-Smtp-Source: ABdhPJzTbFjokYW5f9sIknEvmaoROV9/ECNkm+qopnl9OCjr2hd1C+j+jj3ABktArBWGasUbJkmVqA== X-Received: by 2002:aca:db82:: with SMTP id s124mr14423742oig.89.1595779961214; Sun, 26 Jul 2020 09:12:41 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:3c93:5031:45cb:cbb7? ([2600:1700:a3a0:4c80:3c93:5031:45cb:cbb7]) by smtp.gmail.com with ESMTPSA id v137sm1551595oia.23.2020.07.26.09.12.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jul 2020 09:12:40 -0700 (PDT) To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> <5F1D9E69.5060605@isdg.net> From: Dave Crocker Message-ID: Date: Sun, 26 Jul 2020 09:12:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F1D9E69.5060605@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 16:12:46 -0000 >> My wording was not careful enough.  What I /meant/ was: end-users are >> not relevant to the /trust-related decision making/ that is the goal >> of these protection mechanisms. > > This may be a philosophical theory, but in reality, in lieu of having > deterministic mechanisms, we do have mail systems who do allow the > user to make these type of trust decisions.  If a trust-related > question is answered wrong by the user, the true victim is the honest > sender. My comment was about observable behavior, not philosophical anything. The issue isn't about was is available to users, but what they actually do.  Behavior. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 26 10:10:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408393A1012 for ; Sun, 26 Jul 2020 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEWZtfGS8elD for ; Sun, 26 Jul 2020 10:10:56 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50183A1011 for ; Sun, 26 Jul 2020 10:10:56 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:4cea:8c51:4a26:ca12]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06QHAs0H017928 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 26 Jul 2020 10:10:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1595783456; bh=gPHH/8gJFyzEcxGLfTBxsunVBPQGtpW4anRoEu3QNE8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NYGg8WL0qbun0nYWvLiX2lFZaFBFe1IVAhLWx6g0J5P0cIRZa3bzr4mety5f2ch3G 45hkfINUu2ykM0jM9ZGwoYCqpR3ni/nkaB1hPIBteESM+XThxjdOis6nX9vgl5J059 XXvQQb++5k32T+O8e3HOlervYHw9vfks1vMkCVSk= To: dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <96f8b438-f88d-f078-8531-7e2ed0c7f2c7@bluepopcorn.net> Date: Sun, 26 Jul 2020 10:10:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> Content-Type: multipart/alternative; boundary="------------56B2BFCBBBB715392983FBA7" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 17:10:58 -0000 This is a multi-part message in MIME format. --------------56B2BFCBBBB715392983FBA7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/26/20 6:42 AM, Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: >> >> The original DMARC effort was, in fact, to detect actual cases of >> spoofing, namely unauthorized use of a domain name by outside acto= rs. >> >> Different problem. >> >> >> Actually, part of the effort was to enable Sending domains to >> identify their own mail that was being sent without aligned DKIM >> signing or from places not authorized through SPF - in other words, >> not properly authorized but legitimate, hence feedback loops. > > > As I recall, this was /not/ part of the original purpose of DMARC, > which was discussed strictly in terms of mail from bulk senders. > > What you describe was,=C2=A0 rather, the basis for the later use, which= is > what then started causing problems for mail going through Mediators. > Just identifying their own mail their own email that was sent...: Yes, that's always been part of the original purpose of DMARC, and is the purpose of the reporting mechanisms. Yes, the reports will contain information on many mediators, but that's just noise in the reports. It also contains information when, for example, the product XYZ marketing department decided to use a new mail sending partner without telling anyone. That's useful. It's the policy mechanism (or more specifically its use by other than transactional domains) that's causing the problem here. -Jim --------------56B2BFCBBBB715392983FBA7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/26/20 6:42 AM, Dave Crocker wrote:

On 7/21/2020 12:32 PM, Dotzero wrote:
The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.


As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders.

What you describe was,  rather, the basis for the later use, which is what then started causing problems for mail going through Mediators.


Just identifying their own mail their own email that was sent...: Yes, that's always been part of the original purpose of DMARC, and is the purpose of the reporting mechanisms. Yes, the reports will contain information on many mediators, but that's just noise in the reports. It also contains information when, for example, the product XYZ marketing department decided to use a new mail sending partner without telling anyone. That's useful.

It's the policy mechanism (or more specifically its use by other than transactional domains) that's causing the problem here.

-Jim


--------------56B2BFCBBBB715392983FBA7-- From nobody Sun Jul 26 10:49:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A613A108C for ; Sun, 26 Jul 2020 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUP2ZKJFt1ys for ; Sun, 26 Jul 2020 10:49:15 -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 BF1813A1089 for ; Sun, 26 Jul 2020 10:49:15 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QHphl3030626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 10:51:44 -0700 To: Jim Fenton References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> <96f8b438-f88d-f078-8531-7e2ed0c7f2c7@bluepopcorn.net> From: Dave Crocker Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <474b56db-4932-8831-fa0e-9d6280e97fc1@dcrocker.net> Date: Sun, 26 Jul 2020 10:49:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <96f8b438-f88d-f078-8531-7e2ed0c7f2c7@bluepopcorn.net> Content-Type: multipart/alternative; boundary="------------1B1963C05DC3129E85550141" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 17:49:18 -0000 This is a multi-part message in MIME format. --------------1B1963C05DC3129E85550141 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/26/2020 10:10 AM, Jim Fenton wrote: > > On 7/26/20 6:42 AM, Dave Crocker wrote: > >> On 7/21/2020 12:32 PM, Dotzero wrote: >>> >>> The original DMARC effort was, in fact, to detect actual cases of >>> spoofing, namely unauthorized use of a domain name by outside >>> actors. >>> >>> Different problem. >>> >>> >>> Actually, part of the effort was to enable Sending domains to >>> identify their own mail that was being sent without aligned DKIM >>> signing or from places not authorized through SPF - in other words, >>> not properly authorized but legitimate, hence feedback loops. >> >> As I recall, this was /not/ part of the original purpose of DMARC, >> which was discussed strictly in terms of mail from bulk senders. >> >> What you describe was,  rather, the basis for the later use, which is >> what then started causing problems for mail going through Mediators. >> > Just identifying their own mail their own email that was sent...: Yes, > that's always been part of the original purpose of DMARC, and is the > purpose of the reporting mechanisms. Yes, > Looking over the original I-D posted for DMARC -- which was written after DMARC was already functioning, from work outside the IETF -- I'm unclear where this goal of "identify[ing] their own mail that was being sent without aligned DKIM signing" is clearly explained.(*) Rather, note: > 2. Introduction ... > This memo defines Domain-based Message Authentication, Reporting and > Compliance (DMARC), a mechanism by which email operators leverage > existing authentication and policy advertisement technologies to > enable both message-stream feedback and enforcement of policies > against unauthenticated email. and > 3.1. High-Level Requirements > > At a high level, DMARC is designed to satisfy the following > requirements: > > o Minimize false positives. ... > o Reduce the amount of successfully delivered phish. (Caveat: None of the text I've excised explicity supports this claimed use.  To the extent someone thinks it or any other text in this draft does demonstrate that intended use, please explain how that interpretation is clear from the text in the draft.) d/ (*) https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/00/?include_text=1 -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------1B1963C05DC3129E85550141 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/26/2020 10:10 AM, Jim Fenton wrote:

On 7/26/20 6:42 AM, Dave Crocker wrote:

On 7/21/2020 12:32 PM, Dotzero wrote:
The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.

As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders.

What you describe was,  rather, the basis for the later use, which is what then started causing problems for mail going through Mediators.

Just identifying their own mail their own email that was sent...: Yes, that's always been part of the original purpose of DMARC, and is the purpose of the reporting mechanisms. Yes,


Looking over the original I-D posted for DMARC -- which was written after DMARC was already functioning, from work outside the IETF -- I'm unclear where this goal of "identify[ing] their own mail that was being sent without aligned DKIM signing" is clearly explained.(*)

Rather, note:

2.  Introduction
...
   This memo defines Domain-based Message Authentication, Reporting and
   Compliance (DMARC), a mechanism by which email operators leverage
   existing authentication and policy advertisement technologies to
   enable both message-stream feedback and enforcement of policies
   against unauthenticated email.

and

3.1.  High-Level Requirements

   At a high level, DMARC is designed to satisfy the following
   requirements:

   o  Minimize false positives.
...
   o  Reduce the amount of successfully delivered phish.


(Caveat: None of the text I've excised explicity supports this claimed use.  To the extent someone thinks it or any other text in this draft does demonstrate that intended use, please explain how that interpretation is clear from the text in the draft.)


d/


(*) https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/00/?include_text=1

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------1B1963C05DC3129E85550141-- From nobody Sun Jul 26 10:57: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 065E13A1206 for ; Sun, 26 Jul 2020 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8lCync3CuWFA for ; Sun, 26 Jul 2020 10:57:44 -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 7079D3A1205 for ; Sun, 26 Jul 2020 10:57:44 -0700 (PDT) X-ASG-Debug-ID: 1595786261-11fa3118c71cb10001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id L3qECevG7Za0JOhs (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 26 Jul 2020 13:57:41 -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=from:message-id:subject:to; bh=9FRYc11sa7cG2PYtTXigMuoqVxtawnxWyao3IgkXYTU=; b=fXMfom9DCc/Dde2CzbaYWrjns4TKjdPVv9T8wY1y5Ub/TbRWwwl+VPzL0MTNhyVgx ULUEAtKUpbOZCXghC8Tqg+eTFYYg+1TOahGAU9AOGcfUSvRK/LlvUYGBL7Njzy4/3 XsvQ4GnBs6JJAkUzAeQ4gAzSED5WEjjsl4wvz4Qfg= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 26 Jul 2020 13:57:32 -0400 To: IETF DMARC WG Date: Sun, 26 Jul 2020 13:57:31 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Message-ID: <5715fe55f18147dc88e153d18999b56b@com> MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=4530ca5c2e524bada00d5e2223f9b49b Importance: normal From: "Douglas E. Foster" X-Exim-Id: 5715fe55f18147dc88e153d18999b56b X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595786261 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: 4428 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83479 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 17:57:46 -0000 This is a multipart message in MIME format. --4530ca5c2e524bada00d5e2223f9b49b Content-Type: multipart/alternative; boundary=9584429383fe4dbb9b884e652f012c88 --9584429383fe4dbb9b884e652f012c88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Recipient domains determine what messages they will accept or reject.Fairne= ss and precedence are not necessarily applicable.I suggest that the DMARC s= tandards track be placed on hold for at least a year.=A0 =A0It is not clear= to me, from this group's membership, that DMARC implementers feel an urgen= t need for standard status, so a delay should be tolerable to them.A Mailin= g List Protection WG should be formed to develop his ideas into an informat= ional or experimental RFC.=A0 =A0Then that RFC can be promoted to see if it= wins over any current users of DMARC=A0Sent from my Verizon, Samsung Galax= y smartphone
-------- Original message --------
=
From: Dave Crocker
Date: 7/26/20 9:50 A= M (GMT-05:00)
To: Brandon Long
Cc= : IETF DMARC WG , Dotzero
Su= bject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-0= 0 security considerations
On 7/21/2020 1:42 PM, Brandon Long wrote: > Stricter validation is not an uncommon addition to protocols over the > last 45 years. If there are examples of adding stricter validation in a way that essentially requires changing the semantics of the payload, in order for the payload to survive, I can't think of any. Not TLS, not DNSSec, not S/MIME or PGP. DMARC essentially enforces a semantic on the From: field as a handling identifier, rather than an author identifier. When activity that has a long history of semantic validity and a continued desire for operation is forced to break the denotational source of authoring information, in order to get the mail delivered, then we are in new territory. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --9584429383fe4dbb9b884e652f012c88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Recipient domains determine what messages they = will accept or reject.
Fairness and precedence are not necessaril= y applicable.

I suggest that the DMARC standards t= rack be placed on hold for at least a year.   It is not clear to = me, from this group's membership, that DMARC implementers feel an urgent ne= ed for standard status, so a delay should be tolerable to them.
<= br>
A Mailing List Protection WG should be formed to develop his = ideas into an informational or experimental RFC.   Then that RFC = can be promoted to see if it wins over any current users of DMARC 



Sent from my Ver= izon, Samsung Galaxy smartphone


-------- Original message --------
Fro= m: Dave Crocker <dhc@dcrocker.net>
Date: 7/26/20 9:50 AM = (GMT-05:00)
To: Brandon Long <blong@google.com>
Cc: IETF DMARC WG <dmarc@ietf.org>, Dotzero <dotzero@gmail.com&g= t;
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocke= r-dmarc-author-00 security considerations

On 7/21/2020= 1:42 PM, Brandon Long wrote:
> Stricter validation is not an uncommon= addition to protocols over the
> last 45 years.


If there = are examples of adding stricter validation in a way that
essentially re= quires changing the semantics of the payload, in order for
the payload = to survive, I can't think of any. Not TLS, not DNSSec, not
S/MIME or PG= P.

DMARC essentially enforces a semantic on the From: field as a han= dling
identifier, rather than an author identifier.

When activit= y that has a long history of semantic validity and a
continued desire f= or operation is forced to break the denotational
source of authoring in= formation, in order to get the mail delivered,
then we are in new terri= tory.

d/

--
Dave Crocker
Brandenburg InternetWorkingbbiw.net

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

--9584429383fe4dbb9b884e652f012c88-- --4530ca5c2e524bada00d5e2223f9b49b-- From nobody Sun Jul 26 11:29:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA823A1380 for ; Sun, 26 Jul 2020 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=QvPfG+/d; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=REAvcAFe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GnnxWtJ2rOv for ; Sun, 26 Jul 2020 11:29:32 -0700 (PDT) Received: from mail.winserver.com (mail.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 EF9403A1050 for ; Sun, 26 Jul 2020 11:29:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2403; t=1595788160; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7Mb0iAHOiUdVIv5PVWzB+guDm6o=; b=QvPfG+/dFGTrg5SMdkQ/fEK2moJ6veMAhnD1RLlC7Vbq+C16e/1w7if/MVhVzV QS1mGQ+b0ePslNF51+di6pJJPL99k3iZVRuS9bAi+A5B+EJtLdR2LmRf2PW3UEmc 4Su4B0y04LLRaeu4S6hd1Y0+Q340Nt/hyZroPKJvOfypA= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 14:29:20 -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 2220455423.1.2324; Sun, 26 Jul 2020 14:29:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2403; t=1595788050; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=I0R+KPM 20FstMGOiU0tAE0KbeB56NLNAs0K9bRW8QIc=; b=REAvcAFerhaqpCiRZI45jWH 2SNDmJ5TsRrMIiY9mR+2SGSVPjFamoH0EeGttVNRNLus0O8dTlkdyijD+DfJoGA1 v4AWrBwGjSvWaVr9TJV0r+HfUWYQoBJVbu9b6jxMJCSz9RNLZYzeXXsQzet6dgaf qeugA5Q1Uv5nSzFHgXWY= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 14:27:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1931225687.1.55328; Sun, 26 Jul 2020 14:27:30 -0400 Message-ID: <5F1DCB7B.8010807@isdg.net> Date: Sun, 26 Jul 2020 14:29:15 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> <5F1D9E69.5060605@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:29:34 -0000 On 7/26/2020 12:12 PM, Dave Crocker wrote:> > My comment was about observable behavior, not philosophical anything. > > The issue isn't about was is available to users, but what they > actually do. Behavior. Dave, for a number of years of practice, depending in the system or service, users have been provided with trust-related decisions . Do you need real examples? Gmail moves spam into Spam box. If you user do not look into their spam box, their inaction is used to give spam weight to false positives. If the user is looking for something, finds it in the spam box, it will see something like this: "What is this message in spam? (specific or vague reason)" "REPORT NOT SPAM" Clicking "REPORT NOT SPAM" it doesn't guarantee it will be moved to an area you can see it. It's been reported as lost, you just can't find it. So it is sent again. The next time another message of the same type is received, it will also be placed in the spam box but this time it says: "What is this message in spam? it is similar to messages identified as spam in past" "REPORT NOT SPAM" Clicking "REPORT NOT SPAM" it doesn't guarantee the next transaction will not be moved into the spam box the next time. There are properly other behaviors the user must make before the message source is "white listed." I am not sure if we can model this behavior based on the different ways it may be done, but let me outline what I have observed with users: - May never check spam box - May check if expecting a message unexpectedly delayed. - Ignore it, it gets weighted as spam. - Click Report not Spam. Cross finger you can see it in-box. - Next similar messages are still moved to spam box It is the last behavior that is concerning because when you are dealing with layman users who may see an message in a spam box but leave it there, it appears GMAIL will keep adding weight to it as a spam, negatively impacting the source identities of the mail. In the end, the positive of SPAM box are lost because now you are forcing the user to scrutinize the Spam Box opening the door to reading and accidental clicks. if REPORT NOT SPAM does not clear it up, there is even more confusion for the purpose of that button or any similar AI learning logic that may be employed. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Jul 26 11:34: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 EDAC53A08AC for ; Sun, 26 Jul 2020 11:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yBUSxUxXYpd for ; Sun, 26 Jul 2020 11:34:51 -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 256783A08AA for ; Sun, 26 Jul 2020 11:34:51 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06QIbPbE003079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 11:37:25 -0700 To: hsantos@isdg.net References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> <5F1D9E69.5060605@isdg.net> <5F1DCB7B.8010807@isdg.net> Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <704d0ee5-8e55-1f4e-f669-32aaf8ff19de@dcrocker.net> Date: Sun, 26 Jul 2020 11:34:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F1DCB7B.8010807@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:34:52 -0000 On 7/26/2020 11:29 AM, Hector Santos wrote: > Dave, for a number of years of practice, depending in the system or > service, users have been provided with trust-related decisions . Do > you need real examples? There is a difference between providing a signal, versus its getting received and use. Please provide objective data that these signals are being perceived and used effectively by end users. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 26 12:07: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 E0E893A13C3 for ; Sun, 26 Jul 2020 12:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=O2XLlfNM; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Fynyplm4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVBnQa9FqM8K for ; Sun, 26 Jul 2020 12:07:22 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885503A13EC for ; Sun, 26 Jul 2020 12:07:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1826; t=1595790440; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=jqmEEtyekpN/PUzvhOfCnz2NcTA=; b=O2XLlfNMncxL+uGQDwsXO+tduj11obA9wjRWddXZ2JG1sa/vfQPYUjIv25jxK6 F+KGttV6AgGAyXqHG7gi88AsA5EmMFQjzTHSR/phOOjfq9CgVjkWZ3LbcK+piaDU pecPFC4uECOdl7nXDg4I/DjMBGvCBFNuCXR3SIQS/mQ0A= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 15:07:20 -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 2222735643.1.1116; Sun, 26 Jul 2020 15:07:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1826; t=1595790331; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qfoe0P0 dOIkz3htNUbRYxRxWEkrvtsMn0xMJZZvzwNE=; b=Fynyplm4e3mJZEXbtfzdOuP hPFAJ8SWjamVnK8A3jmWEB4iwxv5CGWjuLaWWI55g09axqGkLqk2KvfrDtGeYWEJ bM28UaopsbrJc6ZGWRrGbGeA+nmKPCLJTj/py3Q5lmYScq+YP8z9Geulmdn301qO FtXOGf0R965AKr4iCqEE= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 26 Jul 2020 15:05:31 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1933506500.1.56208; Sun, 26 Jul 2020 15:05:30 -0400 Message-ID: <5F1DD464.8030104@isdg.net> Date: Sun, 26 Jul 2020 15:07:16 -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: dcrocker@bbiw.net CC: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <1442df0b-c885-f8da-67f5-93f51a683937@dcrocker.net> <5F1D9E69.5060605@isdg.net> <5F1DCB7B.8010807@isdg.net> <704d0ee5-8e55-1f4e-f669-32aaf8ff19de@dcrocker.net> In-Reply-To: <704d0ee5-8e55-1f4e-f669-32aaf8ff19de@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 19:07:27 -0000 On 7/26/2020 2:34 PM, Dave Crocker wrote: > On 7/26/2020 11:29 AM, Hector Santos wrote: >> Dave, for a number of years of practice, depending in the system or >> service, users have been provided with trust-related decisions . Do >> you need real examples? > > > There is a difference between providing a signal, versus its getting > received and use. > > Please provide objective data that these signals are being perceived > and used effectively by end users. Dave, I made a mistake to preempt the remaining comment by saying "Do you need real examples?" I thought I had removed it. It was rude. Sorry. Please read the remaining part in my previous message with my input explaining how GMAIL provides Trust-Related decision options to the layman user mail reader. There is a lot more to this and I need to go. I think you are correct in suggesting the user has no input in the protocols are are looking for. Its the deterministic vs subjective/learning/heuristics protocols issue again. In reality, we don't have the latter (IETF public domain standard for a non-deterministic filtering engine). Unless we want to include SpamAssasin as the Default EmailCore AVS Engine, it has been a long time missing, desirable part of the total picture. With that engine, users would be a natural part of the equation. Unfortunately, we are not there. But with the former, I always thought these deterministic protocols were targeted for unsolicited, anonymous transactions where only the AUTHOR DOMAIN, the self-signing domain, is the only trusted source. Not the user or even the sender unless IFF there is an Author::Sender association established. Have a good day, off to relax at the safe-distancing pool. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Jul 26 14:49: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 ADCCB3A14CA for ; Sun, 26 Jul 2020 14:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 V3twjddfy5cG for ; Sun, 26 Jul 2020 14:49:27 -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 E0A263A14CB for ; Sun, 26 Jul 2020 14:49:26 -0700 (PDT) X-ASG-Debug-ID: 1595800162-11fa3118c71d4e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id ALlwA7HFvPpuPRdN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sun, 26 Jul 2020 17:49:22 -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=from:message-id:subject:to; bh=gAEW372ULPjJWMgCgJjbSMOtVaEJH4+f7N9yQ0+koTA=; b=EahBDqc3M2v/nKViTuypJSB7amfauAYJ/48I0Tyh/flReY/vEAMzRxqhwK6SLEaZq oaoQT23l4nQLqu8dK538HtpocmFGbe3Ib4JXqBC+uYADt8eU3OssYwcuLYh/6VnLU OMgZ1LVKGlu13bBVXUHoH8rb5fCFwXD4D+Q9W4G3w= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 26 Jul 2020 17:49:15 -0400 To: dcrocker@bbiw.net, hsantos@isdg.net Cc: dmarc@ietf.org Date: Sun, 26 Jul 2020 17:49:13 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations Message-ID: <13d9cde2937a493f8fe4bf7d8640f7c9@com> MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=80187af9ed924cd8bad65cb4ebb93343 Importance: normal From: "Douglas E. Foster" X-Exim-Id: 13d9cde2937a493f8fe4bf7d8640f7c9 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595800162 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: 2643 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83483 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 21:49:29 -0000 This is a multipart message in MIME format. --80187af9ed924cd8bad65cb4ebb93343 Content-Type: multipart/alternative; boundary=593c54f93b4241d789a6d9ee58b70f87 --593c54f93b4241d789a6d9ee58b70f87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The link provided by Laura Atkins on 7/21 is relevant and worth reading.Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: Dave Crocker
Date: 7/26/20 2:35 PM (GMT-05:00)
To: hsantos@isdg.net
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/26/2020 11:29 AM, Hector Santos wrote: > Dave, for a number of years of practice, depending in the system or > service, users have been provided with trust-related decisions . Do > you need real examples? There is a difference between providing a signal, versus its getting received and use. Please provide objective data that these signals are being perceived and used effectively by end users. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --593c54f93b4241d789a6d9ee58b70f87 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The link provided by = Laura Atkins on 7/21 is relevant and worth reading.



Sent from my Verizon, Samsung= Galaxy smartphone


-------- Original message --------
From: Dave Crock= er <dhc@dcrocker.net>
Date: 7/26/20 2:35 PM (GMT-05:00) =
To: hsantos@isdg.net
Cc: dmarc@ietf.org
Su= bject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-0= 0 security considerations

On 7/26/2020 11:29 AM, Hecto= r Santos wrote:
> Dave, for a number of years of practice, depending i= n the system or
> service, users have been provided with trust-relate= d decisions . Do
> you need real examples?


There is a dif= ference between providing a signal, versus its getting
received and use= .

Please provide objective data that these signals are being perceiv= ed and
used effectively by end users.

d/

--
Dave Croc= ker
Brandenburg InternetWorking
bbiw.net

_____________________= __________________________
dmarc mailing list
dmarc@ietf.org
https= ://www.ietf.org/mailman/listinfo/dmarc

--593c54f93b4241d789a6d9ee58b70f87-- --80187af9ed924cd8bad65cb4ebb93343-- From nobody Sun Jul 26 16:45: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 2B5DE3A1560 for ; Sun, 26 Jul 2020 16:45: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 uSI1V5Ki8V4t for ; Sun, 26 Jul 2020 16:45:02 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 46BD53A155D for ; Sun, 26 Jul 2020 16:45:02 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id f7so13100662wrw.1 for ; Sun, 26 Jul 2020 16:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JKf1x1/ZE+Q5rrIk5kkthGZWvk69CaU0MZ8cRLrVvSk=; b=mDoCbpE6p6S8RAXflBDF1mU85O3oHoENyBOcFfrRFf2oW17Z8iqZeEB8az16RFDGAV aXnMTUzgwIsNn2WGhmGXtqyaR3lWRMDfHf5w9ifRxbceCH7Dgyw0g8A/0Hm0SqGGmT1n bN9+XaTlskUCyX+yhizL+Hvi3lHPn5dq2Ej8E/r3WtyDP8VLyn+nNBlvwgw2mQqmnOaF 3YcatKBiyxvZ6sOhtTeIoP7bLieZcfK0J20sJ4m/CoMFFoj9ytJG366ZaAFpg78hqr4k P6vgkMdGeH7sRPfhJXD7KPm+EoeEq3e8pAjZTVooQirJyYoOI3cE0vPf/IlZe/djNoMK 4LbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JKf1x1/ZE+Q5rrIk5kkthGZWvk69CaU0MZ8cRLrVvSk=; b=hCK+uEeuaMyfOHKwfdtrfjyNsO8PS7T0y3Y2o16dpzLT/RFVo1lcpcORdCPfVm8w6/ ASGJ+JliQZI/UFgh4duPBD53JdPyd3DktFl9yAyeO0Hj/5wyLxAI4Az/jEcb85EdemSx Omsh+biJyx+toSG1hMhRWVLjur9QZ9/g4zIIJUvBOGGn+f5CB8Z1o9t/+NZPdQN3LLWi aCow5iG3XACG1VDznDSm6JCvVBg5UWzT8l2vrKetr18u2HH/BmzKYWg0oVu9BSsauiB0 60dQ14Xl20Nefl1EQJcW13G0KkxznuQb4iD2gR7jYvS2TYH/2FqxGREJyXpoGryBkERh JfNA== X-Gm-Message-State: AOAM532pKcuVRhvsrUnjGSj+SV6KbHLS5F0D+y2rQyrfATZMer/ENY9a d4mHUZ1B0fWM6t0fq7HFoqdqwwo36jHcjD50YXqYMA== X-Google-Smtp-Source: ABdhPJw9O4pYkqrAKZcd8gSa0XauBeZvUI1kkJLsVYTZaXD2a9jKP/xSIaj2FbesnfuJgvN42nxwPIUyBEwOkFnx03c= X-Received: by 2002:adf:9526:: with SMTP id 35mr18905019wrs.326.1595807100563; Sun, 26 Jul 2020 16:45:00 -0700 (PDT) MIME-Version: 1.0 References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> In-Reply-To: <800f6d50-847f-b597-5234-34ca3c8d8630@dcrocker.net> From: Dotzero Date: Sun, 26 Jul 2020 19:44:48 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005bf39005ab60cbf1" Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 23:45:04 -0000 --0000000000005bf39005ab60cbf1 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 26, 2020 at 9:42 AM Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: > > The original DMARC effort was, in fact, to detect actual cases of >> spoofing, namely unauthorized use of a domain name by outside actors. >> >> Different problem. >> > > Actually, part of the effort was to enable Sending domains to identify > their own mail that was being sent without aligned DKIM signing or from > places not authorized through SPF - in other words, not properly authorized > but legitimate, hence feedback loops. > > > As I recall, this was /not/ part of the original purpose of DMARC, which > was discussed strictly in terms of mail from bulk senders. > > What you describe was, rather, the basis for the later use, which is what > then started causing problems for mail going through Mediators. > Notice I didn't use the word "users" Many of the sending domains in the original effort had/have a complex number of mail streams for transactional mail from multiple domains (in some cases thousands), including through multiple 3rd parties. This is what I was referring to. Michael Hammer. --0000000000005bf39005ab60cbf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jul 26, 2020 at 9:42 AM Dave = Crocker <dhc@dcrocker.net> wr= ote:
=20 =20 =20
On 7/21/2020 12:32 PM, Dotzero wrote:
The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops.


As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders.

What you describe was,=C2=A0 rather, the basis for the later use, which is what then started causing problems for mail going through Mediators.


Notice I didn= 9;t use the word "users" Many of the sending domains in the origi= nal effort had/have a complex number of mail streams for transactional mail= from multiple domains (in some cases thousands), including through multipl= e 3rd parties. This is what I=C2=A0was referring to.

Michael Hammer.
--0000000000005bf39005ab60cbf1-- From nobody Mon Jul 27 05:14: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 0F7633A1906 for ; Mon, 27 Jul 2020 05:14:41 -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 rNdp4TL24Jg1 for ; Mon, 27 Jul 2020 05:14:39 -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 376783A184A for ; Mon, 27 Jul 2020 05:14:39 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06RCHEgN008106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Jul 2020 05:17:14 -0700 References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> To: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking X-Forwarded-Message-Id: <159585176595.9170.11320655994332663370@ietfa.amsl.com> Message-ID: Date: Mon, 27 Jul 2020 05:14:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159585176595.9170.11320655994332663370@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 12:14:41 -0000 -------- Forwarded Message -------- Subject: New Version Notification for draft-crocker-dmarc-author-01.txt Date: Mon, 27 Jul 2020 05:09:25 -0700 From: internet-drafts@ietf.org To: Dave Crocker A new version of I-D, draft-crocker-dmarc-author-01.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-crocker-dmarc-author Revision: 01 Title: Author Header Field Document date: 2020-07-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-crocker-dmarc-author-01.txt Status: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Htmlized: https://tools.ietf.org/html/draft-crocker-dmarc-author-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-author Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-author-01 Abstract: Internet mail defines the From: field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message. The Sender: field is optional, if it has the same information as the From: field. That is, when the Sender: field is absent, the From: field has conflated semantics, as both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments the current use of the From: field, by specifying the Author: field, which identifies the original author of the message and is not subject to modification by Mediators. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 27 05:17: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 B39213A1912 for ; Mon, 27 Jul 2020 05:17:06 -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 quobDdgG8QAH for ; Mon, 27 Jul 2020 05:17:04 -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 8D3F03A18CF for ; Mon, 27 Jul 2020 05:17:04 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06RCJdca008265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Jul 2020 05:19:39 -0700 References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> To: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking X-Forwarded-Message-Id: <159585216728.2214.8844545419487435807@ietfa.amsl.com> Message-ID: Date: Mon, 27 Jul 2020 05:16:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159585216728.2214.8844545419487435807@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 12:17:07 -0000 -------- Forwarded Message -------- Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt Date: Mon, 27 Jul 2020 05:16:07 -0700 From: internet-drafts@ietf.org To: Dave Crocker A new version of I-D, draft-crocker-dmarc-sender-01.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-crocker-dmarc-sender Revision: 01 Title: DMARC Use of the RFC5322.Sender Header Field Document date: 2020-07-27 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-crocker-dmarc-sender-01.txt Status: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ Htmlized: https://tools.ietf.org/html/draft-crocker-dmarc-sender-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-sender Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-sender-01 Abstract: Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message. The RFC5322.Sender field is optional, if it has the same information as the RFC5322.From field. That is, when the RFC5322.Sender field is absent, the RFC5322.From field has conflated semantics, with both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections. This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the RFC5322.From field has become dominated by its role as a handling identifier. The current specification augments use of the RFC5322.From field, by enhancing DMARC to also use the RFC5322.Sender field. This preserves the utility of RFC5322.From field while also preserving the utility of DMARC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 27 11:14: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 4CBCE3A1B5D for ; Mon, 27 Jul 2020 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3TgddpTXDtDJ for ; Mon, 27 Jul 2020 11:14:33 -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 6D7773A1A0D for ; Mon, 27 Jul 2020 11:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595873671; bh=2Jdm+53KIU14nBsSMKvt9fhQNH/xHmc1uSzc4nps0p4=; l=1595; h=To:References:From:Date:In-Reply-To; b=BJqB9HUSZMTpWoQNUdv31XE5ITmnrj6gW+WxyBTPCsgBfrVaNmaHh+g9EHAd+SFPl BqI4x1uPvH38PyZhzhE8SsYCua0fVL5Q5rrK/0CK/uqZc6xzeBuiItAx3MPW16fGQS F2HW8NV5Agk6Zbd4nFYD1B1F4l6E/iZGr+LR+2cUJgVacmXkXSqEWYTzpT/Ae 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.000000005F1F1987.00003DEE; Mon, 27 Jul 2020 20:14:31 +0200 To: dmarc@ietf.org References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> From: Alessandro Vesely Message-ID: <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> Date: Mon, 27 Jul 2020 20:14:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 18:14:37 -0000 On Mon 27/Jul/2020 14:16:58 +0200 Dave Crocker wrote: > -------- Forwarded Message -------- > Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt > Date: Mon, 27 Jul 2020 05:16:07 -0700 > From: internet-drafts@ietf.org > To: Dave Crocker In various places, the I-D talks about a /domain owner/, but it is not always so clear whose domain owner is meant, in case they differ. For example, in *Domain Owner Actions*: snd: When present, this tag signals that mail originated by the domain owner MAY have a RFC5322.Sender field, as well as a RFC5322.From field and that evaluation MAY be based on the domain name in the RFC5322.Sender field. I understand that as a permission that a domain owner grants (to anyone?) to resend mail from its domain if it is correctly authenticated. However, following instructions give the opposite impression. In *Determine Handling Policy*: Sender: Extract the RFC5322.Sender domain from the message. Query the DNS for a DMARC policy record. Perform remaining, numbered steps, if one is found and it contains an "snd" tag. Let's say I have From: real.bank, and Sender: phisher.example. The above text seems to imply the receiver is looking up _dmarc.phisher.example. Correct? Next step 4 apparently entails that aggregate reports are sent to both From: and Sender:. That sounds solid, but not practical. A MLM needs to apply From: rewriting until it sees that all (or most) receivers look for Sender:. How? A possible solution in my next message. Best Ale -- From nobody Mon Jul 27 11:16: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 CC0303A1B5D for ; Mon, 27 Jul 2020 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 c-vsyiaQCYhL for ; Mon, 27 Jul 2020 11:15:58 -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 6AB713A1A0D for ; Mon, 27 Jul 2020 11:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595873756; bh=afAOKliRiSEUzLLHuInKh6gk+ThYEGVcJ9ICXIwtdYA=; l=1044; h=To:References:From:Date:In-Reply-To; b=C2+hwD9n/s9AG4AtztWewbUxRwJzeyaE6RcXomTju8kBVC2VWsjfqS8etf+noqcs/ bJZRiCmmMaN1m+ck3uG8UweVgPHV0+721LsfyeYnrw6Xlqs9BHkf7HWfuhqCjXO/Vm Kc69LQbugdFZUK+qoIu99XFusBwzOpww4/MafH1Lo3xcftC9Pj5cZQvjOuSXy 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.000000005F1F19DC.00003E27; Mon, 27 Jul 2020 20:15:56 +0200 To: dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> From: Alessandro Vesely Message-ID: <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> Date: Mon, 27 Jul 2020 20:15:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 18:16:00 -0000 On Mon 27/Jul/2020 14:14:32 +0200 Dave Crocker wrote: > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-crocker-dmarc-author-01.txt > Date: Mon, 27 Jul 2020 05:09:25 -0700 > From: internet-drafts@ietf.org > To: Dave Crocker The I-D says: Generally, the handling of the Author: header field needs to receive scrutiny and care comparable to that given to the From: header field. If receivers lookup the Author: domain too, they can evaluate authentication and alignment also with respect to that domain. The evaluation may take into account snd tags, and/or dkim-transforms, or whatever other MLM solution we'll invent. That is to be done in case From: and Sender: domains coincide. The result of evaluating the Author: domain may or may not affect the destiny of the message, but it should be part of the aggregate report. That way, when a MLM receives records saying that Author: domains authenticate all right, it can stop rewriting From:. Best Ale -- From nobody Mon Jul 27 11:52:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768C83A1C30 for ; Mon, 27 Jul 2020 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1W7KF1lG729 for ; Mon, 27 Jul 2020 11:52:01 -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 2A7493A1C64 for ; Mon, 27 Jul 2020 11:52:01 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06RIsafT013126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jul 2020 11:54:36 -0700 To: Alessandro Vesely , dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 27 Jul 2020 11:51:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 18:52:14 -0000 On 7/27/2020 11:15 AM, Alessandro Vesely wrote: > If receivers lookup the Author: domain too, they can evaluate > authentication and alignment also with respect to that domain. Since there is no authentication or alignment associated with the Author field, I don't know how they can be evaluated. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 27 12:03: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 231683A03ED for ; Mon, 27 Jul 2020 12:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1raUvapzsGl for ; Mon, 27 Jul 2020 12:03:13 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567AE3A045B for ; Mon, 27 Jul 2020 12:02:44 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06RJ5JIQ015005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jul 2020 12:05:19 -0700 To: Alessandro Vesely References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> From: Dave Crocker Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <47c7f86c-4cb5-712c-63c5-810b8b630823@dcrocker.net> Date: Mon, 27 Jul 2020 12:02:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 19:03:17 -0000 On 7/27/2020 11:14 AM, Alessandro Vesely wrote: > In various places, the I-D talks about a /domain owner/, but it is not > always so clear whose domain owner is meant, in case they differ. > > For example, in *Domain Owner Actions*: > >    snd:   When present, this tag signals that mail originated by the >       domain owner MAY have a RFC5322.Sender field, as well as a >       RFC5322.From field and that evaluation MAY be based on the domain >       name in the RFC5322.Sender field. This is a parameter for a record under a domain name.  Is it really not clear who is referred to by 'domain owner' here? What other interpretation is plausible? However "originated by" is poor wording and should probably be something like "authorized by". > I understand that as a permission that a domain owner grants (to > anyone?) to resend mail from its domain if it is correctly authenticated. > > However, following instructions give the opposite impression.  In > *Determine Handling Policy*: > >        Sender:   Extract the RFC5322.Sender domain from the message. > >           Query the DNS for a DMARC policy record. > >           Perform remaining, numbered steps, if one is found and it >           contains an "snd" tag. > > Let's say I have From: real.bank, and Sender: phisher.example. The > above text seems to imply the receiver is looking up > _dmarc.phisher.example.  Correct? yes. > > Next step 4 apparently entails that aggregate reports are sent to both > From: and Sender:.  That sounds solid, but not practical.  A MLM needs > to apply From: rewriting until it sees that all (or most) receivers > look for Sender:.  How? The reality associated with that 'until' is what motivated moving this proposal from using Sender as an /alternative/ to From: to instead being /in addition to/.  The heuristic of "until it sees that all (or most) receivers look for Sender:" sounds nice, but is entirely indefinite.  Worse, as you note, the 'how' doesn't have an answer.  So the spec does not suggest any meaningful endpoint. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 27 13:12: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 3F89B3A0B9F for ; Mon, 27 Jul 2020 13:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 DNjyBSabzeTR for ; Mon, 27 Jul 2020 13:12:31 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 19B1E3A0B9D for ; Mon, 27 Jul 2020 13:12:30 -0700 (PDT) Received: from pps.filterd (m0167069.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06RK530r021480 for ; Mon, 27 Jul 2020 16:12:30 -0400 Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 32j0kujdj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 27 Jul 2020 16:12:30 -0400 Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 06RKCTho020753 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 27 Jul 2020 16:12:29 -0400 Received: by mail-il1-f200.google.com with SMTP id l17so12277172ilj.17 for ; Mon, 27 Jul 2020 13:12:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dp1doZYr5c+yG3W6Xa8E2Prs2e6HiokA2LzTpcJQL48=; b=MBwyNSKl20GwNDCAEPPNldUOgwh9RaU5YfSs95Q0lbJZ4w1tl8Q2MIXgQc6X9rxJBE UAkKaSfigWrN7Z6CB5Zx65EhwZmEOLG71PZ/2xCkii6wkbaRBhwNUbTTO5q6N0Rqi4hJ 1eGHUcUTqQo9KZvkSJgoTAwZotzAxidaiwq9CgwsLD8QPdbkYr5IPnVeEEEkNDI36jj2 LC8/mZjs0dc0uk5oR/JJpONdB03L+aGH/nPHtrBHvTy1pHgI+IsHx0SNGKRZE2Oj+TUo /LjBjv7X+KwI/6E3c4CEG+zWcySE1Z8drE2KqYsQM+IzTrIdGalxEJtqp7ormPAvhZjf LXvA== X-Gm-Message-State: AOAM532z39uhrgTTm+0vBbBqgxPMHLfpOU0zwx4QvhSqjnirzsK7EaEQ zi7/vWMvkgzM1p7/KVFTJVPk2l6HCD5/vZsNZmjM4RYhW0q3WNAfW8w5nuiKUKKBieIwJwlM0Iq pGy/1bSMNaJX3S/H2CB+9BSbFiyMEMw== X-Received: by 2002:a05:6638:258a:: with SMTP id s10mr28383129jat.101.1595880748816; Mon, 27 Jul 2020 13:12:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIeufg8wxDr+q9AAi1SAGunarsxDP/xBYf15yIgHxnu2wZUJjSavtU5velmi68kS37eHxfWmN9Ansg4U/N3+w= X-Received: by 2002:a05:6638:258a:: with SMTP id s10mr28383093jat.101.1595880748390; Mon, 27 Jul 2020 13:12:28 -0700 (PDT) MIME-Version: 1.0 References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> <47c7f86c-4cb5-712c-63c5-810b8b630823@dcrocker.net> In-Reply-To: <47c7f86c-4cb5-712c-63c5-810b8b630823@dcrocker.net> From: Joseph Brennan Date: Mon, 27 Jul 2020 16:12:17 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001cb22005ab71f1c5" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_14:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 20:12:32 -0000 --0000000000001cb22005ab71f1c5 Content-Type: text/plain; charset="UTF-8" > On 7/27/2020 11:14 AM, Alessandro Vesely wrote: > > > Let's say I have From: real.bank, and Sender: phisher.example. The > > above text seems to imply the receiver is looking up > > _dmarc.phisher.example. Correct? > Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years. They are just names. Verifying that the message really is from phisher.example is a useful data point. The receiving system can choose to mark it with a warning like "you never had mail before from phisher.example". Consider a DMARC DNS tag for the bank to ask the receiving system to verify the From, while the end-user system would not use that tag. I think this is the distinction that should be made, for mailing lists to work but sensitive data to be more protected than end-user mail. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --0000000000001cb22005ab71f1c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 7/27/2020 11:14 AM, Alessandro Vesely wrote:

> Let's say I have From: real.bank, and Sender: phisher.example. The=
> above text seems to imply the receiver is looking up
> _dmarc.phisher.example.=C2=A0 Correct?

=
Avoiding it by redefining From: to serve the former purpose of Sender:= and creating a new Author: to serve the=C2=A0former purpose of From: seems= to me to start us down a long road of new=C2=A0header fields every couple = of years. They are just names.

Verifying=C2=A0that= the message really is from phisher.example is a useful data point. The rec= eiving system can choose to mark it with a warning like "you never had= mail before from phisher.example".

Consider = a DMARC DNS tag for the bank to ask the receiving system to verify the From= , while the end-user system would=C2=A0not use that tag. I think this is th= e distinction that should be made, for=C2=A0mailing lists to work but sensi= tive data to be more protected than end-user mail.

=C2=A0
--
Joseph Brennan
Lead, Email and Systems Applications
Col= umbia University Information Technology


--0000000000001cb22005ab71f1c5-- From nobody Mon Jul 27 23:54: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 D246F3A0CEB for ; Mon, 27 Jul 2020 23:54:07 -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 (1024-bit key) header.d=agari.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 15uB9gHRqYjN for ; Mon, 27 Jul 2020 23:54:06 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2110.outbound.protection.outlook.com [40.107.92.110]) (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 03D9A3A0CEA for ; Mon, 27 Jul 2020 23:54:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JDR6ffbQtNbSMDWpt+NFkYWuWYgtQ++/aLRPi5smR5e6D163w7wm9gtCuheC/8gfBwfSADiVIOpQ7CgcEKNlsRMAdfjhPq4p0DT2pb6His2TElR1zn5gwbco/EXcc7wSFNoIr/nLGeApanS8LSLmyv1OFoXgpUGcboIRFWdr9Fey+yQZy4oAvG03d7/56CG1P1BtKsAQ/HXb8Q+qLrEc3DT3K9DUVcof1jbu3+0E5p+CHXLmjAAUGg2xgQlUvZ5soORyslabvCdTy8Aoj2JffTWRrOwmUyJ9lPVQDx6B1dgsUK5BkFKXC+it5o7ifFG4c7fcJPkMuC7lM6z0fFfqXw== 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=6TgYCvCg0jmXGYZyGgfpkZbiUrK8pfZvTjEdHZkpsHQ=; b=j4kTA3CkR2ZrQhidEqPNxk6mu3i1eAFrFNJJekL1vE5bWoIaToOghSUSQBKrciNGho+xoHLQUSJueP7a5CY8+N46vC6UfNO6Z5RThwMr6CzmnOYeubO/UDe3zBHxlEbW/qUqlksHGpTQGujvMgEojS5rCmaB95kMuJOHvzTMxILIwtZyYgoSpPlR7ikojWpFV8dhjMREhfncLyDRrdZGrcsC/mi9VrPEr1gOGEkjVwPHNiN4DFw+7egiNqcYLxKXydOswUjzOfwshxYyPzun8IspAvBPuXvnYxYxmTYZp219yOEdPtrIFUni2c2Sa+puvL3Nl6PtQZJzV+W7jK5uNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=agari.com; dmarc=pass action=none header.from=agari.com; dkim=pass header.d=agari.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6TgYCvCg0jmXGYZyGgfpkZbiUrK8pfZvTjEdHZkpsHQ=; b=N7zpZ3WWVKFC6HWiC0S5vnnCrwsxxXg/fVqjoaX6GROXfgo+fOwepUmF2C7QW7mhz9EH2U9+PSBNkNWwtZpMRcxD9G/JQPGekt9c5xsPZbc8J65UuiRAgzItsYdvqv0f4hl1xrAccusNs/lKzXfoAFHDm/E1v5cEW2i82HBprJQ= Received: from BY5PR13MB2999.namprd13.prod.outlook.com (2603:10b6:a03:191::27) by BYAPR13MB2343.namprd13.prod.outlook.com (2603:10b6:a02:c5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.10; Tue, 28 Jul 2020 06:54:02 +0000 Received: from BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f]) by BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f%3]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 06:54:02 +0000 From: Autumn Tyr-Salvia To: "dmarc@ietf.org" Thread-Topic: non-mailing list use case for differing header domains Thread-Index: AQHWZKh8JcOQ838b0UOee1lvwkySbQ== Date: Tue, 28 Jul 2020 06:54:02 +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=agari.com; x-originating-ip: [108.69.133.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5bd5fb11-0059-4959-f8d5-08d832c302eb x-ms-traffictypediagnostic: BYAPR13MB2343: 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: X2HeRp3+se15u9xu09nwdATglNMJziyb5SecBB2CoMIfznwe6HpFmt/IcM/xaMcSYnb+rf5Tsbu0l5NOEmRi7DmnV+ig0T+R23tDwcZcovX8XafIoDhJ3FtdiqkmxYjr+0ID4QL0mpXAKjwpniGf/ErO2p8OTpqu/hXUkZVpk1rGiYLixpRBa9JnmSVpLjFdgNV345FV/6rmijPveMkVRPwQKtmo+V2XkR4hQtOfgGW+DwN9aeLSzrZ2LMVCXpijH45hzC6GkcTwV1PRYJDjgcZvlLa6kiDwhesHesvJdiiZbgaTnZAeSJSIUg52NuODP3rbX8Phz1zB9ctRYkiNzERekon2M5pvXJE8saWFAUOzj7mJbo26b8U1CG2+CBbvb9K404f1idNM11MRMl/LzsMaeDOXAXBTpRNMcgc7zlo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB2999.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(376002)(346002)(136003)(366004)(396003)(83380400001)(8936002)(71200400001)(7696005)(2906002)(55016002)(8676002)(9686003)(6916009)(508600001)(316002)(86362001)(52536014)(5660300002)(26005)(186003)(66946007)(66446008)(6506007)(64756008)(76116006)(33656002)(66476007)(66556008)(19627405001)(130980200001)(223123001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /AkkUgvno1tOnEhZLZWjDnE2ruT5mE66X4udCLpJ7/ApTHWkoav6Fo+3WEXBMMmUtSN1mW+UD95jNx4w2r0XgyINuUkaQmLcvML81YhSuzrLvkYrrXHakBrvZOGR3Hu270hIahlm7kXAkMBccEDNmCkrjd86695WOrwspVXSf6TKgLbOIH286Zupg9ZS57FfgIxCK4/30QwbIZ0XaKWqMPekhi/RfT9uQDqzy7xuQW+eEiIGAwGLYvnCGYTOM79XIbDUGhdU6lVAEy9BJPNeqBXwV4sc/FzGGDUqmLgvYxSXEBNgIGYRZtY48iZQyhlCdtEECUg4GYwCVnVcaJs0/tRnMBXe9sIPOrOgtcNFekHM+yNBO85nvCXhyEsk3SMyLv4ni0Uf57YIAk1wZtNkAQz1Kaoo5EaQ23h51DIan92rNkLGZESBwzkaw91eVkmqikOxn8Kia393bd4g/tihygQBJ/mza94QC05tFZyL2w3W80AhKvEyUreTZ883Oe4MSDNgVdLzegFb1XkfWwSvmKR9Pk9wWHZ09ykg+5S8B4PqcCXYVGKmC8STWPsGxsSs19gvbWlaYe6P0nm+7nBUmbWlQZRX5pYErsL9Ob361lwdet17OZD7aJfg1bLayhiFIxNUHms5W40H5GZZSbImJw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB29998094418C8A6C25902569D7730BY5PR13MB2999namp_" MIME-Version: 1.0 X-OriginatorOrg: agari.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB2999.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5bd5fb11-0059-4959-f8d5-08d832c302eb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 06:54:02.1116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05773123-385e-420d-844e-f01aee5e37ab X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WiPRRZuXKlD+ZH8JTUgwrKqSFK9qtB1Ai8dfqaO7otXtKyYBYPxRjIOjXifzQPA9lvliUDnHMkus7MZ6tdch1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2343 Archived-At: Subject: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 06:54:08 -0000 --_000_BY5PR13MB29998094418C8A6C25902569D7730BY5PR13MB2999namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I recently had a conversation with Dave Crocker about proposed changes for = DMARC, and mentioned a use case to him that is not well served by the curre= nt situation that is not a mailing list. He said it might be useful to shar= e this to this list, so I'm writing it out here. A customer of mine is a large financial services company. Like many in that= field, they have acquired several other companies over the years, and now = operate multiple different brands, which send email using different domains= . While many companies like this maintain one primary domain for corporate = email and others only for marketing purposes, this company maintains multip= le distinct domains even for corporate workplace email. The challenge is that they have many administrative assistants who send out= meeting calendar invitations on behalf of the executives they support, and= the executive and the assistant do not always use the same email domain. T= he resulting messages are not aligned, so they fail DMARC. To put it another way: * assistant@firstbrand.com is organizing a meeting for executive@second= brand.com * assistant@firstbrand.com sends out a calendar invite from their own m= essaging client, using executive@secondbrand.com in the From: field * The resulting message uses executive@secondbrand.com in the friendly = From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the header= s are no longer aligned for SPF. * Both firstbrand.com and secondbrand.com are set to DMARC p=3Dreject. * Messages like this are then rejected by receivers that validate DMARC= results. Whenever possible, they tell me they change the assistant's email domain to= match the executives they support, but as people leave or change departmen= ts, they sometimes end up with assistants supporting executives across mult= iple different domains, so they can't ensure they always have the same doma= in. Maybe the ultimate answer for this customer and others in a similar situati= on is simply that this is a use case that can no longer be supported due to= evolving security needs, and yet if that's the case, I thought it would be= helpful to share a real world scenario that is currently impacted that isn= 't part of the previously existing discussion around mailing lists. Thanks, Autumn Tyr-Salvia atyrsalvia@agari.com Agari Principal Customer Success Engineer --_000_BY5PR13MB29998094418C8A6C25902569D7730BY5PR13MB2999namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

I recently had a conversation with Dave Crocker about proposed changes for = DMARC, and mentioned a use case to him that is not well served by the curre= nt situation that is not a mailing list. He said it might be useful to shar= e this to this list, so I'm writing it out here. 

A customer of mine is a large financial services company. Like many in that= field, they have acquired several other companies over the years, and now = operate multiple different brands, which send email using different domains= . While many companies like this maintain one primary domain for corporate email and others only for market= ing purposes, this company maintains multiple distinct domains even for cor= porate workplace email. 

The challenge is that they have many administrative assistants who send out= meeting calendar invitations on behalf of the executives they support, and= the executive and the assistant do not always use the same email domain. T= he resulting messages are not aligned, so they fail DMARC.

To put it another way:
  • assistant@firstbrand.com is organizing a meeting for executive@secondbr= and.com
  • assistant@firstbrand.com sends out a calendar invite from their ow= n messaging client, using executive@secondbrand.com in the From: field
  • The resulting message uses executive@secondbrand.com in the friend= ly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the hea= ders are no longer aligned for SPF.
  • Both firstbrand.com and secondbrand.com are set to DMARC p=3Drejec= t.
  • Messages like this are then rejected by receivers that validate DM= ARC results.
Whenever possible, they tell me they change the assistant's email domain to= match the executives they support, but as people leave or change departmen= ts, they sometimes end up with assistants supporting executives across mult= iple different domains, so they can't ensure they always have the same domain. 

Maybe the ultimate answer for this customer and others in a similar situati= on is simply that this is a use case that can no longer be supported due to= evolving security needs, and yet if that's the case, I thought it would be= helpful to share a real world scenario that is currently impacted that isn't part of the previously existing disc= ussion around mailing lists.


Thanks,

Autumn Tyr-Salvia
atyrsalvia@agari.com
Agari Principal Customer Success Engineer

--_000_BY5PR13MB29998094418C8A6C25902569D7730BY5PR13MB2999namp_-- From nobody Tue Jul 28 00:27:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87A3A0DEE for ; Tue, 28 Jul 2020 00:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KXzF8zN-zes7 for ; Tue, 28 Jul 2020 00:26:58 -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 0E7A13A0E0A for ; Tue, 28 Jul 2020 00:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595921206; bh=8x3FIGhPkWQsp6S9uAxEl8MFVtVokuexGnEL1Aq2Ep4=; l=813; h=To:References:From:Date:In-Reply-To; b=DOWtf6IwgoDxYbXqwt8mnLNKoMvhkXAIOMlF/IUfoCw9QC0hERrHSv/BLm7JzLjNO RCUnO9OO7XlHTUwWjKl3jHpq4SNGsjblHpZSgO2XxZ+3kY8qGaolkEWdo+5yj9h1D6 FLCjuAdMxUYBn/TSUdgsebS0Doj93oQoJ5zLidNoOu/dVqoqWY0ZlcN1A9TW/ 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.000000005F1FD336.000047D6; Tue, 28 Jul 2020 09:26:46 +0200 To: dcrocker@bbiw.net, dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> From: Alessandro Vesely Message-ID: <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> Date: Tue, 28 Jul 2020 09:26:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 07:27:06 -0000 On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote: > On 7/27/2020 11:15 AM, Alessandro Vesely wrote: >> If receivers lookup the Author: domain too, they can evaluate authentication >> and alignment also with respect to that domain. > > > Since there is no authentication or alignment associated with the Author field, > I don't know how they can be evaluated. Receivers can evaluate the Author: domain just like they would do if it were the From: domain. As a new field, Author: doesn't wear a reliable-id trophy, hence receivers may refrain to apply policy dispositions. However, the result of the evaluation, conveyed through aggregate report, can tell MLMs if rewriting From: was necessary. That's the only kind of strategy I see for limiting From: rewriting horizon. Best Ale -- From nobody Tue Jul 28 00:36: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 A236D3A03EE for ; Tue, 28 Jul 2020 00:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GYqfPnxVfrcG for ; Tue, 28 Jul 2020 00:36:40 -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 102AA3A03F4 for ; Tue, 28 Jul 2020 00:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595921798; bh=k1ScgCd/ZkbOt0dn5cXFxkBI5C0QZlcRy+PZ3TSfR7s=; l=305; h=To:References:From:Date:In-Reply-To; b=AaQ6eZvUT0uST+IIg1/4GDr/R7Lp3Tji9+jOXTPaxW1ujaMPwP1eQwaB143jffZaw gBsbMD8E0G1UvVnNsRyne804dXP8oKE6o3Tso2oFzrw6YOtoNnoUGCoJWAKpO1YdyY zst6IO3PzcIorUDwjxAUfRYtG+6YK6afvIlCSyW52Dgi0+8LERrMBXET3K+tf 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.000000005F1FD586.000048AE; Tue, 28 Jul 2020 09:36:38 +0200 To: "dmarc@ietf.org" References: From: Alessandro Vesely Message-ID: Date: Tue, 28 Jul 2020 09:36:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 07:36:42 -0000 On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote: > # The resulting message uses executive@secondbrand.com in the friendly From: > field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no > longer aligned for SPF. > # Heck, can't they DKIM sign? Best Ale -- From nobody Tue Jul 28 00:51:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9933A05AC for ; Tue, 28 Jul 2020 00:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ng3HBD9yVrhg for ; Tue, 28 Jul 2020 00:51:32 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB7C3A05A7 for ; Tue, 28 Jul 2020 00:51:32 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 184so17185403wmb.0 for ; Tue, 28 Jul 2020 00:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J/lfzD3JXakZwpHInoG4XyYex+ccgOh4dwdaM97rAFE=; b=l6QNfmDC8jHtcnI7helcMZy9xuebzKQ6ZCNz/h/1ZjzEtL6ERxhKGmJx3fkmHHej3j dT5+L7F2ia1P9NWfBaLawTHnkhgykzAHN2icRxhjO3hK6RwWkldHeviuvqL+XxqmUe8e rI0dCM5uVu8VUeVmqk4S+B1Jq38uisGdmblMHdyT1JmpWNX26Xziweo1D6c0OrT0mVWK iEUWNgdPuUF+xnWQeOZPEiZG90bnrvCvKBbZW6ZVgZL2awTSiL7H/dv+YvuAAq+idLFp WEGAlkUx4mL78PcoqZtHvMiHclG1v+h44yEKG4YPdsEV6fSBPQtCOCYPSQ27j/jSk6QF yN/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J/lfzD3JXakZwpHInoG4XyYex+ccgOh4dwdaM97rAFE=; b=H2GNY4ZoW9MueWdoJIFkqSgDev6oNIICnVusG7KLOu5WB3U3/5LtLk1giP8pJW91MK Vg0jg6SABbG3DuoQ8FmmvPm79H77YW+oSWnealzZsBwYYTiAPsQB/MvyERwDl+q4gtGw gI3g6F5fJwaqpQOkd/uoeyDoXA+mqbGbHiHgnjyP5L7Xg4S33UYVacDhjOsiKHLuVGnT OpEr/l292JQfRjmcaC3i+H6n+GFyFCv42S+MNkU6YP4crZ9sBs10AUlC13x3GQspJnO8 aP6RXP5nRF7Y9Y2aZgZB0XUhOyYFrbnm6DE/Zfp0BeVd9dgqOUUZy2zM+n/yreSV98Ba ThqA== X-Gm-Message-State: AOAM533ud7BOCOJ5LY0Xx7+yxzd+rxYCxD9W5w6m+03F8bv+Erxxo5Xf f11TU+kNthqZ6zhvXNoXA8IEEGdH/vPGufFqcd+cyu6d X-Google-Smtp-Source: ABdhPJxjzl6DTP7Fr0fvDNeve5+XTw2fzOHNrFJeec42VWpN7z7tCF21j1kV8wSzQwNc/MEM2qNqYvEB3NMceVeiqow= X-Received: by 2002:a1c:7402:: with SMTP id p2mr2792454wmc.117.1595922690510; Tue, 28 Jul 2020 00:51:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Tue, 28 Jul 2020 03:51:18 -0400 Message-ID: To: Autumn Tyr-Salvia Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000e911d05ab7bb59b" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 07:51:36 -0000 --0000000000000e911d05ab7bb59b Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 2:54 AM Autumn Tyr-Salvia wrote: > Hello, > > I recently had a conversation with Dave Crocker about proposed changes for > DMARC, and mentioned a use case to him that is not well served by the > current situation that is not a mailing list. He said it might be useful to > share this to this list, so I'm writing it out here. > > A customer of mine is a large financial services company. Like many in > that field, they have acquired several other companies over the years, and > now operate multiple different brands, which send email using different > domains.. While many companies like this maintain one primary domain for > corporate email and others only for marketing purposes, this company > maintains multiple distinct domains even for corporate workplace email. > > The challenge is that they have many administrative assistants who send > out meeting calendar invitations on behalf of the executives they support, > and the executive and the assistant do not always use the same email > domain. The resulting messages are not aligned, so they fail DMARC. > > To put it another way: > > - assistant@firstbrand.com is organizing a meeting for > executive@secondbrand.com > - assistant@firstbrand.com sends out a calendar invite from their own > messaging client, using executive@secondbrand.com in the From: field > - The resulting message uses executive@secondbrand.com in the friendly > From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the > headers are no longer aligned for SPF. > - Both firstbrand.com and secondbrand.com are set to DMARC p=reject. > - Messages like this are then rejected by receivers that validate > DMARC results. > > Whenever possible, they tell me they change the assistant's email domain > to match the executives they support, but as people leave or change > departments, they sometimes end up with assistants supporting executives > across multiple different domains, so they can't ensure they always have > the same domain. > > Maybe the ultimate answer for this customer and others in a similar > situation is simply that this is a use case that can no longer be supported > due to evolving security needs, and yet if that's the case, I thought it > would be helpful to share a real world scenario that is currently impacted > that isn't part of the previously existing discussion around mailing lists. > There are several solutions that come to mind fairly quickly considering that this is a financial institution. Both involve a small amount of logic and code. The first is to DKIM sign with signatures for both domains. This involves a relatively small amount of code and logic. Any of the MTAs I've worked with could do this even if there are a large number of domains involved.. The second would be to always make the From and the MailFrom consistent (keying off of the From email address) when passing through the outbound MTAs. Again, a little bit of logic and coding but if this is truly a significant problem for them then it is worth the one time effort to implement either or both of these solutions. I've done similar sorts of logic for outbound mail on Ironport and Momentum (MessageSystems) MTAs. Any of the open source MTAs can easily do the same. I don't view this as something a standard needs to fix but rather something that this particular business needs to address because they want to keep a certain business model and practices but also want the benefits of a "p=reject" policy assertion. Michael Hammer --0000000000000e911d05ab7bb59b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2020= at 2:54 AM Autumn Tyr-Salvia <atyrsalvia=3D40agari.com@dmarc.ietf.org> wrote:
Hello,

I recently had a conversation with Dave Crocker about proposed changes for = DMARC, and mentioned a use case to him that is not well served by the curre= nt situation that is not a mailing list. He said it might be useful to shar= e this to this list, so I'm writing it out here.=C2=A0

A customer of mine is a large financial services company. Like many in that= field, they have acquired several other companies over the years, and now = operate multiple different brands, which send email using different domains= .. While many companies like this maintain one primary domain for corporate email and others only for market= ing purposes, this company maintains multiple distinct domains even for cor= porate workplace email.=C2=A0

The challenge is that they have many administrative assistants who send out= meeting calendar invitations on behalf of the executives they support, and= the executive and the assistant do not always use the same email domain. T= he resulting messages are not aligned, so they fail DMARC.

To put it another way:
Whenever possible, they tell me they change the assistant's email domai= n to match the executives they support, but as people leave or change depar= tments, they sometimes end up with assistants supporting executives across = multiple different domains, so they can't ensure they always have the same domain.=C2=A0

Maybe the ultimate answer for this customer and others in a similar situati= on is simply that this is a use case that can no longer be supported due to= evolving security needs, and yet if that's the case, I thought it woul= d be helpful to share a real world scenario that is currently impacted that isn't part of the previously existing = discussion around mailing lists.

There are several solutions that come to mind fairly quickly considering = that this is a financial institution. Both involve a small amount of logic = and code.=C2=A0

The first=C2=A0is to DKIM sign wit= h signatures for both domains. This involves a relatively small amount of c= ode and logic. Any of the MTAs I've worked with could do this even if t= here are a large number of domains involved..

The = second would be to always make the From and the MailFrom consistent (keying= off of the From email address) when passing through the outbound MTAs.=C2= =A0

Again, a little bit of logic and coding but if= this is truly a significant problem for them then it is worth the one time= effort to implement either or both of these solutions. I've done simil= ar sorts of logic for outbound mail on Ironport and Momentum (MessageSystem= s) MTAs. Any of the open source MTAs can easily do the same. I don't vi= ew this as something a standard needs to fix but rather something that this= particular business needs to address because they want to keep a certain b= usiness model and practices but also want the benefits of a "p=3Drejec= t" policy assertion.

Michael Hammer


--0000000000000e911d05ab7bb59b-- From nobody Tue Jul 28 01:19: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 E54F63A0870 for ; Tue, 28 Jul 2020 01:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 lxyx_gVEsN43 for ; Tue, 28 Jul 2020 01:19:01 -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 700263A0839 for ; Tue, 28 Jul 2020 01:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595924337; bh=QY+ICocBnTu/is61/pWmISRMfalu4UppRvq28hvDH84=; l=1618; h=To:References:From:Date:In-Reply-To; b=CHp5BOW0Z/6KHqFNhggFAG3m1n9KHEy407Jfj+Kno7sOgHn9zaoKkDT7JMqeO61C/ FmgNEiNImOyoY/zv79MYB1y4ROAkr0LKN2EF/oOHsJ2Mov6gB8/+nJ8fcFHnSgBpjj 3aVgC5SshbcP0ms7CGW+BBJsM+fkXqCRpUMKu0p2N7mi10EjhDOjTvdFLvW75 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.000000005F1FDF71.00004DCC; Tue, 28 Jul 2020 10:18:57 +0200 To: dmarc@ietf.org References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> <47c7f86c-4cb5-712c-63c5-810b8b630823@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Tue, 28 Jul 2020 10:18:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 08:19:03 -0000 On Mon 27/Jul/2020 22:12:17 +0200 Joseph Brennan wrote: >> On 7/27/2020 11:14 AM, Alessandro Vesely wrote: >> >>> Let's say I have From: real.bank, and Sender: phisher.example. The >>> above text seems to imply the receiver is looking up >>> _dmarc.phisher.example. Correct? >> > > Avoiding it by redefining From: to serve the former purpose of Sender: and > creating a new Author: to serve the former purpose of From: seems to me to > start us down a long road of new header fields every couple of years. They > are just names. In the pre-DMARC era, we've been mainly using just From:. Sender: is used by Outlook to display "on behalf of" catchphrase, presumably in an attempt to support the historic Sender-Id protocol. Otherwise, Sender: never had traction. DMARC did put an extra accent on From:, thereby projecting the community into a /new territory/, to use Dave's words. Introducing Sender: and Author: can allow to tone down DMARC rules. They were designed presuming that only a few domains, where email is not used for personal correspondence, would use the protocol. For example, messages cannot have multiple authors, and cannot be forwarded with modifications. Somewhat Procrustean for day to day messaging. From: rewriting is an obnoxious hack. Yet it's the only possibility for MLMs, currently. By (re-)introducing those two header fields, we can bevel DMARC rules, paying attention not to pervert the overall shape. Three identifiers allow better tuning than just one. If we do a good job, it won't be necessary to redo it every couple of years... Best Ale -- From nobody Tue Jul 28 02:07:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9813A0928 for ; Tue, 28 Jul 2020 02:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBdj8ZlEaGQZ for ; Tue, 28 Jul 2020 02:07:23 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F03A0923 for ; Tue, 28 Jul 2020 02:07:22 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id A11709F1F7 for ; Tue, 28 Jul 2020 02:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595927242; bh=cHCk9y5mANrdvLm9ecEJ6XGEfewxHnKTJw2gqUiSuW4=; h=From:Subject:Date:References:To:In-Reply-To:From; b=V/O7qM2631ktVOqICNxn1yq5415VYgY8OjbSWB1z036BjDw0YCS1Gl7/Xp43tJ9Rw FL3OjI1n+ublPOYbwHw8bOjc3ZPIhgqCXHNF0LP3dQcrCtQV8kKmqPdhNOXoMxcoYY ynvHEpxjY0o0w2hBN9+acZd7c60Ge3XmnyTgJYTM= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_B2D823DD-C747-4445-8533-93B36E6CECDF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 28 Jul 2020 10:07:19 +0100 References: To: "dmarc@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 09:07:25 -0000 --Apple-Mail=_B2D823DD-C747-4445-8533-93B36E6CECDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2020, at 08:36, Alessandro Vesely wrote: >=20 > On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote: >> # The resulting message uses executive@secondbrand.com in the = friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, = so the headers are no longer aligned for SPF. >> # >=20 > Heck, can't they DKIM sign? This really misses Autumn=E2=80=99s point. The issue she brings up may = be unusual but it a lot more common than folks think. Banks, in = particular, are a host of underlying problems related to DNS and = security. I worked with a bank a few years back. It took 6 weeks to = identify what continent the nameserver controlling DNS for the subdomain = we were trying to authenticate lived on. Then there were weeks of = approvals and security sign offs in order to get a DNS change made so we = could correct a SPF record. 3 or 4 months to get an update done. For the = record, my clients were part of the Canadian organization and the name = servers handling their DNS were located in Australia.=20 Autumn has presented a very real world scenario that demonstrates the = overall complexity of mail management operationally. Your solution = =E2=80=9Csign with DKIM=E2=80=9D has significant barriers to adoption. = For instance, assume that there is code installed on the mailserver that = will grab the 5322.from address and sign with the appropriate DKIM key. = How many domains are involved? How many different mailservers? How long = will this solution take to deploy? Banks do not move quickly and, for = the obvious reasons, any changes to security require multiple reviews = and assurances that the implications are understood. The underlying belief with DMARC is that mail is simple, that companies = are monoliths with only a few brands/domains, that it is possible to = know exactly where every message will come from. These assumptions are = not and have never been true. Inevitably, however, when these types of = issues are pointed out, they=E2=80=99re dismissed with =E2=80=9Csolutions=E2= =80=9D that aren=E2=80=99t actually achievable or maintainable. DMARC = proponents have repeatedly failed to pay attention to folks pointing out = the actual operational challenges and thus have never addressed the = issues in any way. This is, fundamentally, why only 15% of fortune 500 = companies have adopted p=3Dreject and why adoption rates are only = increased by 5% last year.=20 The indirect mail stream issue is real. But it is not the only barrier = to getting to p=3Dreject. The sooner folks start listening to the people = who are presenting real issues where DMARC alignment can=E2=80=99t be = achieved the sooner they=E2=80=99ll be able to address them. The problem = with low DMARC adoption is that it does not adequately address how = companies are using mail in ways that break the DMARC model. Almost a = decade on, and proponents are still suggesting that email usage should = change to comply with their model of how email works. This has not = happened. Maybe proponents need to think harder about why.=20 laura --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_B2D823DD-C747-4445-8533-93B36E6CECDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jul 2020, at 08:36, Alessandro Vesely <vesely@tana.it> = wrote:

On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:
# The resulting message = uses executive@secondbrand.com in the friendly From: field, = but firstbrand.com in = the SMTP MAIL FROM domain, so the headers are no longer aligned for = SPF.
#

Heck, can't they DKIM = sign?

This really misses Autumn=E2=80=99s point. The = issue she brings up may be unusual but it a lot more common than folks = think. Banks, in particular, are a host of underlying problems related = to DNS and security. I worked with a bank a few years back. It took 6 = weeks to identify what continent the nameserver controlling DNS for the = subdomain we were trying to authenticate lived on. Then there were weeks = of approvals and security sign offs in order to get a DNS change made so = we could correct a SPF record. 3 or 4 months to get an update done. For = the record, my clients were part of the Canadian organization and the = name servers handling their DNS were located in = Australia. 

Autumn has = presented a very real world scenario that demonstrates the overall = complexity of mail management operationally. Your solution =E2=80=9Csign = with DKIM=E2=80=9D has significant barriers to adoption. For instance, = assume that there is code installed on the mailserver that will grab the = 5322.from address and sign with the appropriate DKIM key. How many = domains are involved? How many different mailservers? How long will this = solution take to deploy? Banks do not move quickly and, for the obvious = reasons, any changes to security require multiple reviews and assurances = that the implications are understood.

The underlying belief with DMARC is that mail is = simple, that companies are monoliths with only a few brands/domains, = that it is possible to know exactly where every message will come from. = These assumptions are not and have never been true. Inevitably, however, = when these types of issues are pointed out, they=E2=80=99re dismissed = with =E2=80=9Csolutions=E2=80=9D that aren=E2=80=99t actually achievable = or maintainable. DMARC proponents have repeatedly failed to pay = attention to folks pointing out the actual operational challenges and = thus have never addressed the issues in any way. This is, fundamentally, = why only 15% of fortune 500 companies have adopted p=3Dreject and why = adoption rates are only increased by 5% last year. 

The indirect mail stream issue is real. But it is = not the only barrier to getting to p=3Dreject. The sooner folks start = listening to the people who are presenting real issues where DMARC = alignment can=E2=80=99t be achieved the sooner they=E2=80=99ll be able = to address them. The problem with low DMARC adoption is that it does not = adequately address how companies are using mail in ways that break the = DMARC model. Almost a decade on, and proponents are still suggesting = that email usage should change to comply with their model of how email = works. This has not happened. Maybe proponents need to think harder = about why. 

laura

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

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

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







= --Apple-Mail=_B2D823DD-C747-4445-8533-93B36E6CECDF-- From nobody Tue Jul 28 03:36: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 BC2253A0ADE for ; Tue, 28 Jul 2020 03:35:45 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOJ-VVr7RsXu for ; Tue, 28 Jul 2020 03:35:44 -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 4AD2C3A0AE4 for ; Tue, 28 Jul 2020 03:35:44 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SAcINe022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 03:38:19 -0700 To: Joseph Brennan References: <159585216728.2214.8844545419487435807@ietfa.amsl.com> <5c414951-6c24-7af1-7a67-cc31a5390e23@tana.it> <47c7f86c-4cb5-712c-63c5-810b8b630823@dcrocker.net> From: Dave Crocker Cc: IETF DMARC WG Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 28 Jul 2020 03:35:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A9B70C1A064573D1FB239939" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 10:35:53 -0000 This is a multi-part message in MIME format. --------------A9B70C1A064573D1FB239939 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/27/2020 1:12 PM, Joseph Brennan wrote: > Avoiding it by redefining From: to serve the former purpose of Sender: > and creating a new Author: to serve the former purpose of From: seems > to me to start us down a long road of new header fields every couple > of years. Oh?  This is cast essentially as a fear. Your basis for believing this is what? As for the re-defining of From:, the premise of the Author: proposal is that DMARC has already effected that change. > Verifying that the message really is from phisher.example is a useful > data point. The receiving system can choose to mark it with a warning > like "you never had mail before from phisher.example". Mark  it how and for what use? How does that deal with the user-level problems caused by From:-field rewriting? > Consider a DMARC DNS tag for the bank to ask the receiving system to > verify the From, while the end-user system would not use that tag. I > think this is the distinction that should be made, for mailing lists > to work but sensitive data to be more protected than end-user mail. I don't understand what you are suggesting or how it would work usefully. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------A9B70C1A064573D1FB239939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/27/2020 1:12 PM, Joseph Brennan wrote:
Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years.
Oh?  This is cast essentially as a fear. Your basis for believing this is what?

As for the re-defining of From:, the premise of the Author: proposal is that DMARC has already effected that change.


Verifying that the message really is from phisher.example is a useful data point. The receiving system can choose to mark it with a warning like "you never had mail before from phisher.example".

Mark  it how and for what use? How does that deal with the user-level problems caused by From:-field rewriting?


Consider a DMARC DNS tag for the bank to ask the receiving system to verify the From, while the end-user system would not use that tag. I think this is the distinction that should be made, for mailing lists to work but sensitive data to be more protected than end-user mail.

I don't understand what you are suggesting or how it would work usefully.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------A9B70C1A064573D1FB239939-- From nobody Tue Jul 28 03:37: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 748CD3A0AAF for ; Tue, 28 Jul 2020 03:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKxm-m-Sfct6 for ; Tue, 28 Jul 2020 03:37:38 -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 7044C3A0AAC for ; Tue, 28 Jul 2020 03:37:38 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SAeEQn022348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 03:40:14 -0700 To: Alessandro Vesely , dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 28 Jul 2020 03:37:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 10:37:40 -0000 On 7/28/2020 12:26 AM, Alessandro Vesely wrote: > On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote: >> On 7/27/2020 11:15 AM, Alessandro Vesely wrote: >>> If receivers lookup the Author: domain too, they can evaluate >>> authentication and alignment also with respect to that domain. >> >> >> Since there is no authentication or alignment associated with the >> Author field, I don't know how they can be evaluated. > > > Receivers can evaluate the Author: domain just like they would do if it > were the From: domain. So you want to define DMARC as applying to both the From: field and the Author: field? That will defeat the benefit intended for the Author: field. >As a new field, Author: doesn't wear a > reliable-id trophy, hence receivers may refrain to apply policy > dispositions.  However, the result of the evaluation, conveyed through > aggregate report, can tell MLMs if rewriting From: was necessary. How, exactly? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 04:00: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 BA1063A0AB8 for ; Tue, 28 Jul 2020 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jBbnZg6BBzSY for ; Tue, 28 Jul 2020 04:00:33 -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 933CB3A0AB1 for ; Tue, 28 Jul 2020 04:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595934031; bh=S/2rfzEzNt8oKOhEPGRcPUI9ejGvKGjqSt7nAE7L1UA=; l=1599; h=To:References:From:Date:In-Reply-To; b=BE0M3kdEpajCByFJVUXzmFXt0pRqc+5DAFuMJWsBYIryVXqU9v9wtq17qlCkBpP8z bg+mU2C691GGXHBEdUH2NdLqPTQBD7cdl24NmNlrJcs5Jp5ZkXgmEedGuElIIbQcQn ybmktmnE3c8Xy44RrdwnQEwBczM2PBsAEOYv2KGJkx2laYIhQ0dzDMzsRDBTm 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 00000000005DC0B6.000000005F20054F.0000627A; Tue, 28 Jul 2020 13:00:31 +0200 To: dcrocker@bbiw.net, dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> From: Alessandro Vesely Message-ID: <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> Date: Tue, 28 Jul 2020 13:00:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 11:00:36 -0000 On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote: > On 7/28/2020 12:26 AM, Alessandro Vesely wrote: >> On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote: >>> On 7/27/2020 11:15 AM, Alessandro Vesely wrote: >>>> If receivers lookup the Author: domain too, they can evaluate >>>> authentication and alignment also with respect to that domain. >>> >>> >>> Since there is no authentication or alignment associated with the Author >>> field, I don't know how they can be evaluated. >> >> >> Receivers can evaluate the Author: domain just like they would do if it were >> the From: domain. > > So you want to define DMARC as applying to both the From: field and the Author: > field?  That will defeat the benefit intended for the Author: field. Yes. In case of conflict, evaluation of Author: has to be omitted. For example, Author: fields containing multiple mailboxes are not considered. (OT-BTW, DMARC spec will have to consider From: fields with multiple mailboxes, since they're allowed by RFC 5322. Should Sender:, in such cases, have a domain aligned with one of those?) >> As a new field, Author: doesn't wear a reliable-id trophy, hence receivers >> may refrain to apply policy dispositions.  However, the result of the >> evaluation, conveyed through aggregate report, can tell MLMs if rewriting >> From: was necessary. > > How, exactly? Author: and Sender: domains can be included in aggregate reports along with the From: one. The policy_evaluated can also include more items, specifying which evaluations pass or fail. Best Ale -- From nobody Tue Jul 28 04:09: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 975563A0AE5 for ; Tue, 28 Jul 2020 04:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIoTdMg-WxUM for ; Tue, 28 Jul 2020 04:09:35 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E764A3A0AE4 for ; Tue, 28 Jul 2020 04:09:35 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SBCBAm026472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 04:12:11 -0700 To: Alessandro Vesely , dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> Date: Tue, 28 Jul 2020 04:09:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 11:09:39 -0000 On 7/28/2020 4:00 AM, Alessandro Vesely wrote: > On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote: >> On 7/28/2020 12:26 AM, Alessandro Vesely wrote: >>> Receivers can evaluate the Author: domain just like they would do if >>> it were the From: domain. >> >> So you want to define DMARC as applying to both the From: field and >> the Author: field?  That will defeat the benefit intended for the >> Author: field. > > Yes.  In case of conflict, evaluation of Author: has to be omitted.  For > example, Author: fields containing multiple mailboxes are not considered. 1. I don't understand the details you have in mind that would make this useful. 2. Again, this seems to defeat the purpose of having the Author field. > (OT-BTW, DMARC spec will have to consider From: fields with multiple > mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such > cases, have a domain aligned with one of those?) My understanding is that DMARC does not work for From: fields with multiple domain names. In that regard, that's another change to the From: field that DMARC imposes. >>> As a new field, Author: doesn't wear a reliable-id trophy, hence >>> receivers may refrain to apply policy dispositions.  However, the >>> result of the evaluation, conveyed through aggregate report, can tell >>> MLMs if rewriting From: was necessary. >> >> How, exactly? > > > Author: and Sender: domains can be included in aggregate reports along > with the From: one.  The policy_evaluated can also include more items, > specifying which evaluations pass or fail. It will probably help for you to supply detailed specification of the changes to DMARC's reporting, so people can assess its likely costs and benefits more concretely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 06:53: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 4BF223A0CD9 for ; Tue, 28 Jul 2020 06:52:57 -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 nGIIAmrQKsdL for ; Tue, 28 Jul 2020 06:52:54 -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 204C73A0C79 for ; Tue, 28 Jul 2020 06:52:54 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SDtT9d009892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 28 Jul 2020 06:55:30 -0700 Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking To: IETF DMARC WG Message-ID: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> Date: Tue, 28 Jul 2020 06:52:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 13:52:58 -0000 I am not a fan of splitting documents only for an abstract sense of cleanliness. There needs to be justification of improved documentation 'cleanliness' and/or useful removal of fate-sharing -- if separate fates are reasonably expected. DMARC alignment validation is a basic, mechanical process that produces a yes/no response. At that level, it's comparable to the nature of a DKIM validation, except for the From: field domain. DMARC "policy" is fundamentally different. It's not that its mechanism isn't "mechanical" but that its semantics produce more semantic and operational challenges. I think that could reasonably make it worth strongly separating them into two different documents, no matter has small one of the documents might be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 07:08:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1E3A0CA7 for ; Tue, 28 Jul 2020 07:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkS7QRVX_Z-C for ; Tue, 28 Jul 2020 07:08:18 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC083A0CA4 for ; Tue, 28 Jul 2020 07:08:18 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id n4so6527884uae.5 for ; Tue, 28 Jul 2020 07:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=U2J45ZqcrIYRLDQSCVuRkQW7hnMNsUELVJ7tOAizwxE=; b=euiG/ejaZhIFWaXeAT0UwDMS1g9fVWKfPA3z+X6VBxSykRSJX79uyZV204SrSdXAsi WShytdKh6VM1JUfs+sJPZX02FFbuQxbmRymrvLk4NGXhwgHccakgRTH7GP0p5oQWQYa0 v/mIXqy+EwCvK12ewF18lSlbVln+l4Ltex6Wj0kQm2oy0do9pHmExT2EeELBmjep1Lk9 IF7iuODadkeA9XGHAK3S3SA93yk1gf6XXPbYgRCMN/rlHa1Q6xQgRmVLC61ORXQYmkhK djazVigwvqkjDcokorj6vZZ4h/1r6B8GYknaXnlZ/bJVyb7JN3PgPwW11I408J0U+UOy U0jA== 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=U2J45ZqcrIYRLDQSCVuRkQW7hnMNsUELVJ7tOAizwxE=; b=KJHkw41IXIymmgeicJUcl6P+dkUmXFhiJaV12GZwc+NOmlQjZT+8FN10oJcmMdafOs 281dhim8mhz8+VQiPsw+judxpmslXNA0sqn17RuJAb/b63jibXD4xWzuL2P2OPNviJ+/ 9xVX698QvNSMfd9LZ7HzZvNx96cyniQausH7NAg4Y8WanqIWO8CIfryPUKgCAzwPR3vJ VMCifMTaEJJu8PpETSkbjhiHGy6EQ5GXSCl9RCSa2c71OuZ3zQyISO4LwcBQHOP3jpLZ 5cUAAcCQ5FcY8hYxdHz4RoJD1rSqx84w12NNkfWen6n5Y38EOEbALqsCj7IzignyUkLF JjvQ== X-Gm-Message-State: AOAM532mKoiuF7RBB1vx/BFRf3QUDK5kfUJz9evDaMwtMXeSDN6TIIH0 28hYa7ppm3RR8B0/qrZqJ57s6cqeEyxDR0O0MWOsWg== X-Google-Smtp-Source: ABdhPJzeEYfmQ5nayeT3C5MTo/HnNrwgncFJAv2VjhG4YtgHucWmz2soJ1SS7tKOjzR6t655KVpgSLakAn8VuwxA3bM= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr20217040uad.87.1595945286166; Tue, 28 Jul 2020 07:08:06 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 28 Jul 2020 07:07:55 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000dceafc05ab80f775" Archived-At: Subject: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:08:19 -0000 --000000000000dceafc05ab80f775 Content-Type: text/plain; charset="UTF-8" If any of those of you who participated in today's working group session via the Meetecho interface have any thoughts, up or down, about how well that interface did or didn't work for you, we'd love to hear them. You can email the list, the chairs, or me with your thoughts. -MSK, for the first time sporting an Area Director hat in here --000000000000dceafc05ab80f775 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If any of those of you who participated in today'= s working group session via the Meetecho interface have any thoughts, up or= down, about how well that interface did or didn't work for you, we'= ;d love to hear them.=C2=A0 You can email the list, the chairs, or me with = your thoughts.

-MSK, for the first time sporting a= n Area Director hat in here
--000000000000dceafc05ab80f775-- From nobody Tue Jul 28 07:20: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 9484F3A0C4D for ; Tue, 28 Jul 2020 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RgEO8n9bLaYH for ; Tue, 28 Jul 2020 07:19:46 -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 4CBAC3A0D56 for ; Tue, 28 Jul 2020 07:19:08 -0700 (PDT) Received: from [10.10.10.124] (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 06SEIwd8046032 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 28 Jul 2020 14:19:07 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 06SEIwd8046032 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1595945947; bh=oQoTxL1cPUpidaaUAq1WB1nl1/jtmTQqbV7MpaZFyJo=; h=Subject:To:References:From:Date:In-Reply-To; b=KMYnMNy+26riQ99Lk1yC2zx9PeB83XpZQoqpSRl9mXTQ1lkJiFt34hbsynWrKzwQq 17Iw/bd+ksNBeiXVWvhHeghv5E2Bkp5DhCifi/EIX7pto+ba+ARQXQ2F5ilgOhUhoj ULjgQHILcwGqQOUSzZmJKfcOh5Wz1yQrh8nArbp9YBqFsKwkrICFqCig9xFDfV+CnR rUUR1pq0n3O+Gu3K9o3UNKWiRIX80Iwk14wuq81DwGOvSUYkoK742yVDV/C4MgsZ4H vVUNUj1arszFi8PvDNBhVZ8dwQNsLHKC3E5Kv8yyMOTs4vF2W6hYjskvYxtvle+khZ xr0rpOdhgCHPQ== X-Authentication-Warning: segv.crash.com: Host 135-180-118-4.fiber.dynamic.sonic.net [135.180.118.4] (may be forged) claimed to be [10.10.10.124] To: dmarc@ietf.org References: From: Steven M Jones Message-ID: <188ab9f5-6152-65bb-9645-d59dd7463607@crash.com> Date: Tue, 28 Jul 2020 07:18:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Tue, 28 Jul 2020 14:19:07 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:19:49 -0000 On 7/28/20 7:07 AM, Murray S. Kucherawy wrote: > If any of those of you who participated in today's working group > session via the Meetecho interface have any thoughts ...  You can > email the list, the chairs, or me with your thoughts. Having to flip back and forth between the chat column and the queue/participant column was awkward. Assuming I didn't miss a setting: Why can't we have both shown? At least as an option on larger screens/windows/devices. --S. From nobody Tue Jul 28 07:21:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9B73A0C4D for ; Tue, 28 Jul 2020 07:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pWdSEogYvDZT for ; Tue, 28 Jul 2020 07:21:00 -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 9AC1E3A0D34 for ; Tue, 28 Jul 2020 07:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595946058; bh=JzfeqyNTAgP5JTr52x6/qj3N/glLpsKoergTyLLkGtc=; l=3090; h=To:References:From:Date:In-Reply-To; b=AY3VpqzkBeddNFL8f2tbOtqsWuc1lhRoA0lPuGe+1ZSSIZlzcIO6gYa8WVm/64ix3 bHEQ8cgkeYJJ5r9Qhhi7K0fm2WVgWaBa5goC4GOcz2T4u1uujdkcxlQ/gICUkkuG3R AnI56MxM+glRUFogcJLTT2R31akA/DR3VP+YKpdorJENRUS9rp6s+iDoaf9tH 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.000000005F203449.00007B8F; Tue, 28 Jul 2020 16:20:57 +0200 To: dcrocker@bbiw.net, dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> From: Alessandro Vesely Message-ID: <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it> Date: Tue, 28 Jul 2020 16:20:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:21:05 -0000 On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote: > On 7/28/2020 4:00 AM, Alessandro Vesely wrote: >> On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote: >>> On 7/28/2020 12:26 AM, Alessandro Vesely wrote: >>>> Receivers can evaluate the Author: domain just like they would do if it >>>> were the From: domain. >>> >>> So you want to define DMARC as applying to both the From: field and the >>> Author: field?  That will defeat the benefit intended for the Author: field. >> >> Yes.  In case of conflict, evaluation of Author: has to be omitted.  For >> example, Author: fields containing multiple mailboxes are not considered. > > 1. I don't understand the details you have in mind that would make this useful. It is an optional evaluation. It's easy to do, if you already verified DKIM and SPF. It is not terribly useful, admittedly, except that having two or three "pass" makes for a stronger authentication than just the From:. The chief reason for evaluating it is to give feedback to the MLM. > 2. Again, this seems to defeat the purpose of having the Author field. Why? >> (OT-BTW, DMARC spec will have to consider From: fields with multiple >> mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such cases, >> have a domain aligned with one of those?) > > My understanding is that DMARC does not work for From: fields with multiple > domain names.  In that regard, that's another change to the From: field that > DMARC imposes. I don't think such restriction is acceptable for a Standard Track document which should be applicable to all mail. According to RFC 5322, in such cases the Sender: shall be used to disambiguate. Then we need to distinguish between two differing semantics for Sender:, mediator or agent. >>>> As a new field, Author: doesn't wear a reliable-id trophy, hence receivers >>>> may refrain to apply policy dispositions.  However, the result of the >>>> evaluation, conveyed through aggregate report, can tell MLMs if rewriting >>>> From: was necessary. >>> >>> How, exactly? >> >> >> Author: and Sender: domains can be included in aggregate reports along with >> the From: one.  The policy_evaluated can also include more items, specifying >> which evaluations pass or fail. > > It will probably help for you to supply detailed specification of the changes > to DMARC's reporting, so people can assess its likely costs and benefits more > concretely. How about this example: pass fail fail fail pass pass none mailing_list Mailinglist via SPF on ietf.org (IETF mailinglist) ? AFAICS, an pass implies one of three reasons: * MLM added no footer, * text/plain message signed with l=, or * DKIM transformation successfully applied. Best Ale -- From nobody Tue Jul 28 07:30: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 C70DF3A0B9B for ; Tue, 28 Jul 2020 07:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AIZFs47mkODj for ; Tue, 28 Jul 2020 07:30:36 -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 2F8683A0B9C for ; Tue, 28 Jul 2020 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595946633; bh=iFd9VeVHQ8BScFcoyM93f3w+S8X/vCcD5eFO07de5kM=; l=641; h=To:References:From:Date:In-Reply-To; b=DivF8cjeDeittQ5VlLdPzDE/vsy4Nwfr24mrgzmW0m8KsYqoIeLFTXmIM2UXc9HvQ O7yd4yBSrU6dR6bCSdaFog1AIDlMC1S73d3SPk0f/HZGuVisE+5zuaz3rheQr0ADdo 6KwT1vIbAnOHSoi6nQS5vDOzGVieLceHTpWFsjGWwgGfCdm0pDXnMfDfIF+ur 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.000000005F203689.00007C9F; Tue, 28 Jul 2020 16:30:33 +0200 To: IETF DMARC WG References: From: Alessandro Vesely Message-ID: <7fb1b50a-4557-108e-b008-235758d00874@tana.it> Date: Tue, 28 Jul 2020 16:30:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:30:38 -0000 On Tue 28/Jul/2020 16:07:55 +0200 Murray S. Kucherawy wrote: > If any of those of you who participated in today's working group session via > the Meetecho interface have any thoughts, up or down, about how well that > interface did or didn't work for you, we'd love to hear them.  You can email > the list, the chairs, or me with your thoughts. At mine, the audio was disconnected right after your presentation. (I couldn't hear Bron's comment). I tried reloading and reconnecting by the spin icon in the lower right corner, to no avail. The status bar in the codimd editor covers the bottom line of text. Best Ale -- From nobody Tue Jul 28 07:41: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 4C67C3A0E61 for ; Tue, 28 Jul 2020 07:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 aIKQezmUKy3Y for ; Tue, 28 Jul 2020 07:41:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 5FFE03A0E21 for ; Tue, 28 Jul 2020 07:41:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RNRIK6OUY8008T9M@mauve.mrochek.com> for dmarc@ietf.org; Tue, 28 Jul 2020 07:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1595946991; bh=dvV+62jnPyLCqJl59M3jZze3jWZKTQBqSQAAbXYOFFM=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=JTw+fKMNFJhKb9uVBYIF1BNRUuPRVDnTXDGnxn/gLRfmXzPspPN1y9QL8hPsQt7n4 7wWS+NNrynmY8KgBG95JSFMI/KkQCqXrdHZ6bx3/PA6MPeSYaHLf6eBz8UNLK9uVBK 9ZZeBkDPFljEkMXa/5koUgc/oZsqWW1DqZXpiVOE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RNQ8L5UHLC0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 28 Jul 2020 07:36:28 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: IETF DMARC WG Message-id: <01RNRIK4ZEKO0085YQ@mauve.mrochek.com> Date: Tue, 28 Jul 2020 07:03:09 -0700 (PDT) In-reply-to: "Your message dated Tue, 28 Jul 2020 06:52:47 -0700" <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> References: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:41:45 -0000 The MIME document split was, in hindsight, partly successful (separation of media types registration was a really good thing), partly unsuccessful (part five should not have been pulled out of part two), and partly a wash (the cost/benefit of separating parts one and two ended up pretty much equal IMO). The devil is always in the details. The DMARC alignment validation process appears free of policy considerations as currently specified, and is thus a candidate for separation. But are we sure it will remain so, and is the separation of a relatively small part of the specification worth it? Ned > I am not a fan of splitting documents only for an abstract sense of > cleanliness. There needs to be justification of improved documentation > 'cleanliness' and/or useful removal of fate-sharing -- if separate fates > are reasonably expected. > DMARC alignment validation is a basic, mechanical process that produces > a yes/no response. At that level, it's comparable to the nature of a > DKIM validation, except for the From: field domain. > DMARC "policy" is fundamentally different. It's not that its mechanism > isn't "mechanical" but that its semantics produce more semantic and > operational challenges. > I think that could reasonably make it worth strongly separating them > into two different documents, no matter has small one of the documents > might be. > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 28 07:52:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04C3A0D72 for ; Tue, 28 Jul 2020 07:51: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, 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 J7GYqu_ePfpP for ; Tue, 28 Jul 2020 07:51:55 -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 BA7B83A0D98 for ; Tue, 28 Jul 2020 07:51:54 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 3so11557417wmi.1 for ; Tue, 28 Jul 2020 07:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLWNUTFzXK7QL+Zv5zEyVIqXn092J7F0Q+riy0s8McM=; b=uOqF4scQbdThEElV0un4r28VS4nFcgI1Ko/IxpzcUN287TH35OR24IUnU3x7cZbdfW TXXKxiIaUomzJWKffV2Z7IOb4IaoTFrZhn/4bHDjQ+42w1Mw//Wp0FGkJ8aFgREdmkDA hq94CliqhzZvjkHflR4thbxqsmbt3/HJVTkHSnw7YUTU3rde719Nhznkw2pMCVmto0fv ZF5vaY2ejkqEAg8B/BJ7dlPFFZcoep0kEsAf00dlLR+aFg3LPT1za/Qy9KB95lTJfxg8 HOjBGssgO9CrwZONxz+BS5FpvTh/6fXGWfn12cJF0DENRIoFqIR8fSQgtDQ6npY87k8V gPWg== 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=MLWNUTFzXK7QL+Zv5zEyVIqXn092J7F0Q+riy0s8McM=; b=s4TkbUY+lxuZcclaevIxCeK5zbI/ybIlgntcoZ4SIV217qUR7S4dTcVnTdmtaAObWN voyuLjKE6ejeFwm0yiMr39M+EmHFh/oYJQJhxD2yPWNEjRdAuzR3oW10DY1vUQhDhCet CyeWvIH5qpM/zPMb3nYaLJALP/QJ3sp7isJ6D0F/7Zm4FUT6BpifHiz9qOte9gG5aPVo 9wXJtU5d1CcCKL9ErDlo+Lzhg86w1/BnhSZ4Q/SiAez+XHary2Ef9KSrtYU6l2vTfsEl qUKefCJPkCElxMj4LIP4qiRhr7HBvn3z5LzObcs6/tj/GSRwRNNtzOCvzea2OTxjVtFr dIMw== X-Gm-Message-State: AOAM530EVlyQqiONppcL2jRP6B9k4K2qsYUq6ml9vfCYkoWU6NOiydUN GhTXG+bgkb7AJrz0tsz356Jd30Y8wfCsJ82H0Gj4DA== X-Google-Smtp-Source: ABdhPJw5stRuSnrS+z6BalBXnFrxqyslftfK9gGA7299kbyt4cRul7KfJ9vMGpYHmYiQIDsadyuZsJoUpGCvPlTaxws= X-Received: by 2002:a1c:de86:: with SMTP id v128mr4228766wmg.36.1595947913241; Tue, 28 Jul 2020 07:51:53 -0700 (PDT) MIME-Version: 1.0 References: <188ab9f5-6152-65bb-9645-d59dd7463607@crash.com> In-Reply-To: <188ab9f5-6152-65bb-9645-d59dd7463607@crash.com> From: Dotzero Date: Tue, 28 Jul 2020 10:51:42 -0400 Message-ID: To: Steven M Jones Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000072e6db05ab81948d" Archived-At: Subject: Re: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:51:58 -0000 --00000000000072e6db05ab81948d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 10:20 AM Steven M Jones wrote: > > Having to flip back and forth between the chat column and the > queue/participant column was awkward. Assuming I didn't miss a setting: > Why can't we have both shown? At least as an option on larger > screens/windows/devices. > > --S. > I had Pidgen open for the chat on my laptop so didn't have to flip back and forth. This might not be a solution for everyone. I agree that it should be an integral capability. Michael Hammer --00000000000072e6db05ab81948d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 28, 2020 at 10:20 AM Stev= en M Jones <smj@crash.com> wrote= :

Having to flip back and forth between the chat column and the
queue/participant column was awkward. Assuming I didn't miss a setting:=
Why can't we have both shown? At least as an option on larger
screens/windows/devices.

--S.

I had Pidgen open for the chat on = my laptop so didn't have to flip back and forth. This might not be a so= lution for everyone. I agree that it should be an integral capability.

Michael Hammer
--00000000000072e6db05ab81948d-- From nobody Tue Jul 28 08:09: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 ED4663A0D9D for ; Tue, 28 Jul 2020 08:09:14 -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 Q5JGShyuUNeT for ; Tue, 28 Jul 2020 08:09:13 -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 D99A73A0D86 for ; Tue, 28 Jul 2020 08:09:12 -0700 (PDT) X-ASG-Debug-ID: 1595948950-11fa3118c741be0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id qnQufLiy1JzEKQNP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 28 Jul 2020 11:09:10 -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=z/qHIYyljo9KDNIa9fBwa5/5kRm7zlL+tYiiBlF5lrA=; b=k7Ev+HE1/cLG11CVg1LGf0WUmd2nntqHHT6kDrYMVFNjBBGs2p5i1AF3RFLpg7lSn j46X3RaptB2BuYBYR8glWRzPxinI/2bGZov586iVUG8fC3zqBBeKggeh/8pniLMzv 6zNLv7aA8dH80KUz8SE1Gk+IsnYnhUXWZ1AeF4z1g= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Tue, 28 Jul 2020 15:09:02 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=9460d4db56aa429485f552f1171be327 In-Reply-To: References: X-Exim-Id: daaada8589c04001bef36b131924fc35 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595948950 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: 10831 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.83524 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 15:09:17 -0000 This is a multipart message in MIME format. --9460d4db56aa429485f552f1171be327 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Calender invites are a known issue, and the issue is mentioned in RFC 7960. The exact scenario is: User A creates a meeting and invites User B who is in a different email dom= ain.User B forwards the invite to User C, who is in a different administrat= ive domain than User B. The invite is sent using User A as the sender, so = the invite fails DMARC tests. The problem does not occur if User A extends the invite to User C. The problem does not occur if User B and User C are in the same administrat= ive domain,on the assumption that DMARC is not checked or enforced on messa= ges that are internal to the administrative domain. For invitations that are relayed across administrative boundaries within th= e organization, email filtering exceptions should work around the problem. = If not, the organization needs a different email filtering product. For invitations that are relayed outside the organization, the policy of th= e receiving domain will determine whether the message is blocked or allowed= . I would expect that most DMARC enforcers have encountered this problem a= nd have developed a workaround to it. Or course, this WG or a spinoff could investigate ways for cooperating MUAs= , to send invites that do not encounter this problem. As Laura Atkins said, DMARC implementation is not easy. Nonetheless, deplo= yment is slowly increasing, not decreasing. It seems unlikely that DMARC= enforcement will go away. ---------------------------------------- From: atyrsalvia=3D40agari.com@dmarc.ietf.org Sent: 7/28/20 2:54 AM To: "dmarc@ietf.org" Subject: [dmarc-ietf] non-mailing list use case for differing header domain= s Hello, I recently had a conversation with Dave Crocker about proposed changes for = DMARC, and mentioned a use case to him that is not well served by the curre= nt situation that is not a mailing list. He said it might be useful to shar= e this to this list, so I'm writing it out here. A customer of mine is a large financial services company. Like many in that= field, they have acquired several other companies over the years, and now = operate multiple different brands, which send email using different domains= .. While many companies like this maintain one primary domain for corporate= email and others only for marketing purposes, this company maintains multi= ple distinct domains even for corporate workplace email. The challenge is that they have many administrative assistants who send out= meeting calendar invitations on behalf of the executives they support, and= the executive and the assistant do not always use the same email domain. T= he resulting messages are not aligned, so they fail DMARC. To put it another way: assistant@firstbrand.com is organizing a meeting for executive@secondbrand.= comassistant@firstbrand.com sends out a calendar invite from their own mess= aging client, using executive@secondbrand.com in the From: fieldThe resulti= ng message uses executive@secondbrand.com in the friendly From: field, but = firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer a= ligned for SPF.Both firstbrand.com and secondbrand.com are set to DMARC p= =3Dreject.Messages like this are then rejected by receivers that validate D= MARC results. Whenever possible, they tell me they change the assistant's email domain to= match the executives they support, but as people leave or change departmen= ts, they sometimes end up with assistants supporting executives across mult= iple different domains, so they can't ensure they always have the same doma= in. Maybe the ultimate answer for this customer and others in a similar situati= on is simply that this is a use case that can no longer be supported due to= evolving security needs, and yet if that's the case, I thought it would be= helpful to share a real world scenario that is currently impacted that isn= 't part of the previously existing discussion around mailing lists. Thanks, Autumn Tyr-Salvia atyrsalvia@agari.com Agari Principal Customer Success Engineer --9460d4db56aa429485f552f1171be327 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Calender invites a= re a known issue, and the issue is mentioned in RFC 7960.

The exact scenario is:
  • User A creates a meeting and in= vites User B who is in a different email domain.
  • User B forwards th= e invite to User C, who is in a different administrative domain than User B= .  The invite is sent using User A as the sender, so the invite fails = DMARC tests.
The problem does not occur if User A extends the= invite to User C.
The problem does not occur if User B and User = C are in the same administrative domain,on the assumption that DMARC is not= checked or enforced on messages that are internal to the administrative do= main.

For invitations that are relayed across admi= nistrative boundaries within the organization, email filtering exceptions s= hould work around the problem.  If not, the organization needs a diffe= rent email filtering product.

For invitations that= are relayed outside the organization, the policy of the receiving domain w= ill determine whether the message is blocked or allowed.  I would expe= ct that most DMARC enforcers have encountered this problem and have develop= ed a workaround to it.

Or course, this WG or a spi= noff could investigate ways for cooperating MUAs, to send invites that do n= ot encounter this problem.

As Laura Atkins said, D= MARC implementation is not easy.  Nonetheless, deployment is slowly in= creasing, not decreasing.    It seems unlikely that DMARC enforce= ment will go away.



<= br>

Fro= m: atyrsalvia=3D40agari.com@dmarc.ietf.org
Sent: 7/28/20 2:54 AM
To: "dmarc@ietf.org" <dmarc@ietf.= org>
Subject: [dmarc-ietf] non-mailing list use case= for differing header domains
Hel= lo,

I recently had a conversation with Dave Crocker about proposed changes = for DMARC, and mentioned a use case to him that is not well served by the c= urrent situation that is not a mailing list. He said it might be useful to = share this to this list, so I'm writing it out here. 

A customer of m= ine is a large financial services company. Like many in that field, they ha= ve acquired several other companies over the years, and now operate multipl= e different brands, which send email using different domains.. While many c= ompanies like this maintain one primary domain for corporate email and othe= rs only for marketing purposes, this company maintains multiple distinct do= mains even for corporate workplace email. 

The challenge is that they = have many administrative assistants who send out meeting calendar invitatio= ns on behalf of the executives they support, and the executive and the assi= stant do not always use the same email domain. The resulting messages are n= ot aligned, so they fail DMARC.

To put it another way:
  • assistant@firstbrand.com is organizing a meeting for= executive@secondbrand.com
  • assistant@firstbrand.com sends out a cal= endar invite from their own messaging client, using executive@secondbrand.c= om in the From: field
  • The resulting message uses executive@secondbr= and.com in the friendly From: field, but firstbrand.com in the SMTP MAIL FR= OM domain, so the headers are no longer aligned for SPF.
  • Both first= brand.com and secondbrand.com are set to DMARC p=3Dreject.
  • Messages= like this are then rejected by receivers that validate DMARC results.
    • =
Whenever possible, they tell me th= ey change the assistant's email domain to match the executives they support= , but as people leave or change departments, they sometimes end up with ass= istants supporting executives across multiple different domains, so they ca= n't ensure they always have the same domain. 

Maybe the ultimate answe= r for this customer and others in a similar situation is simply that this i= s a use case that can no longer be supported due to evolving security needs= , and yet if that's the case, I thought it would be helpful to share a real= world scenario that is currently impacted that isn't part of the previousl= y existing discussion around mailing lists.


Thanks,

Autumn Tyr-Salvia
atyrs= alvia@agari.com
Agari Principal Customer Success= Engineer

--9460d4db56aa429485f552f1171be327-- From nobody Tue Jul 28 08:15:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD70C3A0DD6 for ; Tue, 28 Jul 2020 08:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 t0SVvswsl45o for ; Tue, 28 Jul 2020 08:15:17 -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 C02163A0E8F for ; Tue, 28 Jul 2020 08:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595949297; bh=uYK1pfDjHvlllCw+RJszjLZhXK/VipraItbo1jMBywc=; l=1441; h=To:References:From:Date:In-Reply-To; b=C6o9YNEcTyHuXvr3PgE4+smcUE2T3854YWb+LY7Iwr3i7BC3AW3ILUV5RTfUsVdL7 XJeSJRwcjTYRr378hJ+i0JLsydoQL/5P6QLz/kBHufT7ReHnFhgb1hysxgb6eRgoVn OVTSX4o3NliBoxBvOuvTgB0JqgeZlYL/8oGPssgB9no1IACJqCFItzV5a4O1G 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 00000000005DC013.000000005F2040F1.00000405; Tue, 28 Jul 2020 17:14:57 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <425a4f5b-3bd7-6c24-b0ea-96bf80947407@tana.it> Date: Tue, 28 Jul 2020 17:14:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 15:15:19 -0000 On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote: >> On 28 Jul 2020, at 08:36, Alessandro Vesely > On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote: >>> # The resulting message uses executive@secondbrand.com in the friendly >>> From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the >>> headers are no longer aligned for SPF. >>> # >> >> Heck, can't they DKIM sign? > > This really misses Autumn’s point. [...] > > Autumn has presented a very real world scenario that demonstrates the > overall complexity of mail management operationally. Your solution “sign > with DKIM” has significant barriers to adoption. For instance, assume that > there is code installed on the mailserver that will grab the 5322.from > address and sign with the appropriate DKIM key. How many domains are > involved? How many different mailservers? How long will this solution take > to deploy? Banks do not move quickly and, for the obvious reasons, any > changes to security require multiple reviews and assurances that the > implications are understood. If the bank delegates a subdomain to each trusted subsidiary, each subsidiary could manage their keys on their local DNS and email servers. If the bank can afford "relaxed" DKIM alignment, they can sign with d=local-branch.bank.example and From: transactions@bank.example. What's the risk of doing so? Best Ale -- From nobody Tue Jul 28 08:22: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 89BCF3A0DC1 for ; Tue, 28 Jul 2020 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YThJWdsi5XXZ for ; Tue, 28 Jul 2020 08:22:44 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5F3A0DB5 for ; Tue, 28 Jul 2020 08:22:44 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 5FB8B9F1F7 for ; Tue, 28 Jul 2020 08:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1595949763; bh=01wpmUsO5M9FHyEfTfForAjCrYOqRDAPk5nHOGqb9fI=; h=From:Subject:Date:References:To:In-Reply-To:From; b=lVVagZvC8XEuPDHmkb/TSTwpZjuGYz1HEP4n0YUAvDdKHDDNzElq0dZImU1JWJ+kE gdxq5ecctugbdsh93FpEMxNp3xwEGLnGkyA1x9XdjufYCjVenzbPsqd7E+DvFnx91W 5aMAK5IdpUvzmFRVNCeztNjB0i3Oq0lznIZvml0w= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_BCB3E012-F5B7-40CC-B3B6-D04EB3F06510" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 28 Jul 2020 16:22:41 +0100 References: <425a4f5b-3bd7-6c24-b0ea-96bf80947407@tana.it> To: IETF DMARC WG In-Reply-To: <425a4f5b-3bd7-6c24-b0ea-96bf80947407@tana.it> Message-Id: <4E0F8EDE-6D3E-427F-960B-D6BA7E426CE7@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 15:22:47 -0000 --Apple-Mail=_BCB3E012-F5B7-40CC-B3B6-D04EB3F06510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2020, at 16:14, Alessandro Vesely wrote: >=20 > On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote: >>> On 28 Jul 2020, at 08:36, Alessandro Vesely >> On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote: >=20 >>>> # The resulting message uses executive@secondbrand.com in the = friendly >>>> From: field, but firstbrand.com in the SMTP MAIL FROM domain, so = the headers are no longer aligned for SPF. >>> # >>>=20 >>> Heck, can't they DKIM sign? >> This really misses Autumn=E2=80=99s point. [...] >> Autumn has presented a very real world scenario that demonstrates the >> overall complexity of mail management operationally. Your solution = =E2=80=9Csign >> with DKIM=E2=80=9D has significant barriers to adoption. For = instance, assume that >> there is code installed on the mailserver that will grab the = 5322.from >> address and sign with the appropriate DKIM key. How many domains are >> involved? How many different mailservers? How long will this solution = take >> to deploy? Banks do not move quickly and, for the obvious reasons, = any >> changes to security require multiple reviews and assurances that the >> implications are understood. >=20 >=20 > If the bank delegates a subdomain to each trusted subsidiary, each = subsidiary could manage their keys on their local DNS and email servers. = If the bank can afford "relaxed" DKIM alignment, they can sign with = d=3Dlocal-branch.bank.example and From: transactions@bank.example. = What's the risk of doing so? That does not address the problem Autumn brought up at all.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_BCB3E012-F5B7-40CC-B3B6-D04EB3F06510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jul 2020, at 16:14, Alessandro Vesely <vesely@tana.it> = wrote:

On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote:
On 28 Jul 2020, at 08:36, Alessandro Vesely <vesely@tana.it wrote:
On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:

# The resulting message uses executive@secondbrand.com in the friendly
From: field, but firstbrand.com  in the SMTP MAIL FROM domain, so the = headers are no longer aligned for SPF. >>> #

Heck, can't they DKIM sign?
This really misses Autumn=E2=80=99s point. = [...]
Autumn has presented a very real world scenario that = demonstrates the
overall complexity of mail management = operationally. Your solution =E2=80=9Csign
with DKIM=E2=80=9D= has significant barriers to adoption. For instance, assume that
there is code installed on the mailserver that will grab the = 5322.from
address and sign with the appropriate DKIM key. = How many domains are
involved? How many different = mailservers? How long will this solution take
to deploy? = Banks do not move quickly and, for the obvious reasons, any
changes to security require multiple reviews and assurances = that the
implications are understood.


If the bank = delegates a subdomain to each trusted subsidiary, each subsidiary could = manage their keys on their local DNS and email servers.  If the = bank can afford "relaxed" DKIM alignment, they can sign with = d=3Dlocal-branch.bank.example and From: transactions@bank.example.  What's the risk of doing = so?

That = does not address the problem Autumn brought up at = all. 

laura 

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

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

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







= --Apple-Mail=_BCB3E012-F5B7-40CC-B3B6-D04EB3F06510-- From nobody Tue Jul 28 08:59: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 7EE553A0E1D for ; Tue, 28 Jul 2020 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ztJosaysa_X2 for ; Tue, 28 Jul 2020 08:59:21 -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 EF3843A0E2A for ; Tue, 28 Jul 2020 08:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595951959; bh=zVKb01L9rCrFeQ0zI3az4AHX3/g4CHxNGCSWvJ5P+7w=; l=1859; h=To:References:From:Date:In-Reply-To; b=DGPvDdP6hY4f9oe0CddPHt4DQwYocDcPUnkicLTyheJcZ9qG4yeesJuiULF4XsPRC KhdP2LkhMlXJ/EP+l4LF4dEifYel28neiWCD6wpYXqXj4Pj41DI/5hfYf1B6KhdPOh +cIOmPcf6Yq+HOTZ/kq9Zc/Jp1FDoKRTTrd2L9dEmPQZ3xt7EaU54fvawnmjC 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.000000005F204B56.000009A0; Tue, 28 Jul 2020 17:59:18 +0200 To: dmarc@ietf.org References: <425a4f5b-3bd7-6c24-b0ea-96bf80947407@tana.it> <4E0F8EDE-6D3E-427F-960B-D6BA7E426CE7@wordtothewise.com> From: Alessandro Vesely Message-ID: <2c8446d6-623f-08ce-b852-c6ac5521b74b@tana.it> Date: Tue, 28 Jul 2020 17:59:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4E0F8EDE-6D3E-427F-960B-D6BA7E426CE7@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 15:59:24 -0000 On Tue 28/Jul/2020 17:22:41 +0200 Laura Atkins wrote: >> On 28 Jul 2020, at 16:14, Alessandro Vesely wrote: >> On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote: >>>> On 28 Jul 2020, at 08:36, Alessandro Vesely wrote: >>>> On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote: >> >>>>> # The resulting message uses executive@secondbrand.com in the >>>>> friendly From: field, but firstbrand.com in >>>>> the SMTP MAIL FROM domain, so the headers are no longer aligned for >>>>> SPF. >>>> >>>> Heck, can't they DKIM sign? >>> This really misses Autumn’s point. [...] >>> Autumn has presented a very real world scenario that demonstrates the >>> overall complexity of mail management operationally. Your solution “sign >>> with DKIM” has significant barriers to adoption. For instance, assume that >>> there is code installed on the mailserver that will grab the 5322.from >>> address and sign with the appropriate DKIM key. How many domains are >>> involved? How many different mailservers? How long will this solution take >>> to deploy? Banks do not move quickly and, for the obvious reasons, any >>> changes to security require multiple reviews and assurances that the >>> implications are understood. >> >> >> If the bank delegates a subdomain to each trusted subsidiary, each >> subsidiary could manage their keys on their local DNS and email servers. >> If the bank can afford "relaxed" DKIM alignment, they can sign with >> d=local-branch.bank.example and From: transactions@bank.example. What's >> the risk of doing so? > > That does not address the problem Autumn brought up at all. I understood the problem is the lack of agility. Delegation to smaller domains using local servers would solve it, wouldn't it? Even with many domains... What am I missing? Best Ale -- From nobody Tue Jul 28 09:05:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC93A0E1D for ; Tue, 28 Jul 2020 09:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Ef7/OUsJ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=GmD6hSDK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgp9H4CDdjPw for ; Tue, 28 Jul 2020 09:05:18 -0700 (PDT) Received: from mail.winserver.com (pop3.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 08D373A0E3E for ; Tue, 28 Jul 2020 09:05:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1256; t=1595952310; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=YWGZXRpGR4xKkxYD1IcK/EzwPHo=; b=Ef7/OUsJtJlbpSk9GAhzM474fy+0Z7qLFZOWABpo/nO44NdBr/joXPGZojYNW4 UwNTtnb0585XE3gC9Tl2jg1e+Dd6MX0B5xu9I6A5HowosqAiErMzmOCANO6pFZGW 05GMFkJEWKfOjwoMy0MR8pFAeTU8kk0HC/EupwHJMVUkQ= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 28 Jul 2020 12:05:10 -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 2384602733.1.5916; Tue, 28 Jul 2020 12:05:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1256; t=1595952198; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IN+EGRK Bq8h94WnlCqIiVUv+1yefyHYbUe2trXwVRmQ=; b=GmD6hSDKaPmK9+rZGIRaN5w cIDFqeWsHuGh5FCgJi0iY/qU7myqinkghJG+/Bt/OBILr/ou9t4LVitIq37aWhBQ WmE9HEmH9zD0JPEqj52DuM2piJpkNnbuqcKlPbfJNnQt5S3V2+5roA5mRq2oyzQL e2GGr+OtxitIRZs8V7Ls= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 28 Jul 2020 12:03:18 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2095372328.1.58736; Tue, 28 Jul 2020 12:03:16 -0400 Message-ID: <5F204CB3.7080404@isdg.net> Date: Tue, 28 Jul 2020 12:05:07 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:05:20 -0000 On 7/28/2020 5:07 AM, Laura Atkins wrote: > > The indirect mail stream issue is real. But it is not the only barrier > to getting to p=reject. The sooner folks start listening to the people > who are presenting real issues where DMARC alignment can’t be achieved > the sooner they’ll be able to address them. The problem with low DMARC > adoption is that it does not adequately address how companies are > using mail in ways that break the DMARC model. Almost a decade on, and > proponents are still suggesting that email usage should change to > comply with their model of how email works. This has not happened. > Maybe proponents need to think harder about why. Well said. It has always been how do we scale a "Lightweight Author::Signer Authorization Protocol" or LASAP methodology. Examples of LASAP are: ATPS TPA Conditional Signatures SPF offers 3rd party (associated, authorized) IP addresses and does not have this problem (administration aside). The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Jul 28 09:09:02 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 C69CD3A0F69 for ; Tue, 28 Jul 2020 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=CBUNxTf7; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=arS4uTss Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hftsela0QqA5 for ; Tue, 28 Jul 2020 09:08:56 -0700 (PDT) Received: from mail.winserver.com (pop3.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 896083A0F3E for ; Tue, 28 Jul 2020 09:08:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=692; t=1595952520; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=HEv2ewXlMNzGB1NE+EET2zfqxow=; b=CBUNxTf7UuXRv7dV2iCpgU1lSoGyuw0wouCy73jnhaGfPPDwmrZjd/QKmLbQH1 rZQ52ipM8l6JHIyIwnD9cplqzpIYGIVFGXHyoqTdBlQLTDeNKevoSPLaiUNHM9hA XPJgRURfJhiBH/xuT1d4ohU1TnZE4/jwXc4iyfBpNt22A= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 28 Jul 2020 12:08:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2384812976.1.2816; Tue, 28 Jul 2020 12:08:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=692; t=1595952407; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zuep64A ThodrxQgugJmaPOZ5z31AeFUD6fcsOZHxNkU=; b=arS4uTssARk354j0GyWRbls iIA3QxxRfZE7rRDgsn0LsoSaBuA3vDMbJkmlGABLVwBA3zjZj4+BwEDnxSZQnvmC aV9x9QwwW9DW3qlrrI76htz7RwomDrfTaJn+wLz+gLrYqKxmZNE1eUJgbaMadeRr +KUPKTd+FHoKij2DN+bw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 28 Jul 2020 12:06:47 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2095582015.1.58896; Tue, 28 Jul 2020 12:06:46 -0400 Message-ID: <5F204D85.2020808@isdg.net> Date: Tue, 28 Jul 2020 12:08:37 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , IETF DMARC WG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:09:01 -0000 Sorry I missed it. Is there a video capture? On 7/28/2020 10:07 AM, Murray S. Kucherawy wrote: > If any of those of you who participated in today's working group > session via the Meetecho interface have any thoughts, up or down, > about how well that interface did or didn't work for you, we'd love to > hear them. You can email the list, the chairs, or me with your thoughts. > > -MSK, for the first time sporting an Area Director hat in here > > > _______________________________________________ > 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 Jul 28 09:37: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 047DF3A0EA1 for ; Tue, 28 Jul 2020 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Kz53qCpaZbxt for ; Tue, 28 Jul 2020 09:37:39 -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 BD9C73A0E85 for ; Tue, 28 Jul 2020 09:37:39 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QE600L7UU6PUHA0@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 28 Jul 2020 11:37:38 -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.7.28.163017, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.55.174] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TeKeWG75qHZNdC8rMT9VpqBqJ7gOLVaL80JvQUaJhn06eBXmF2ChUyJgl3IQrBBqST08eh16qAXMoW7JxBJrl1vluSVdz/9NQQTyToY5DSleAiuI0rpVFhrqCKjk03TCTLFzJadhaxuta6poPU7q68xurqJad9++qQ+wyITIR5QkBFYaKHd9sj7702nH87pS5ltYZRlhmUTXbd2O2rRbn4w+lW3gJN5bcAUoJD2KWkbQfvgRYl5i8ieF5TFPx+t6G0xZdA25S3A8Lq+7jfKilnQdZs2Ai9qk8zZ0LpD7yJVv+jor48ZYmOYAg5t3wES4P4hf1XThPGNOBP3Dp54T6Q== 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=5BA5QwvvmDhV6iql0OCoHCukxQdr4UL6h/B8fqVMvSs=; b=mjrsO0RddvMkCxy9uqIB60HzX5e1Nc7FjxTNP/n4wrS7XR6a17sF7qheKszf6GPRiKbWDH7ly3MRxgMj7tiHj7PjOQxkEhwJEWDNS3Ir7pBPQDa5U3LBLBhw/k98EWmCN7Zynjx6hsjlhkGUu5AzhPIyiGxGfwCIw4wPVeiqSKAxf26fAQ5fc2xqpmr+MBKAFAaFg+a+3CoNYipH563akT4F3KlVZ0qveRkYCRe/NxypihUdvEBQ9p3TF6lg1etUcoDTrxAVSrbJ99hiLzLEXY1cARVczBHd8BcLpX202XiLjhBNbcXrTVrZhxFgJ9yEobcqtTyV+RfMAklqRBuBdg== 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=5BA5QwvvmDhV6iql0OCoHCukxQdr4UL6h/B8fqVMvSs=; b=gdrVfcvR/OLiZ4jLb7lTxbKkikw1pf1n+vCgsNnorfwdYeH68ZnP3fBZyTeFt2L5h0bc3XhDeWpZaUAxkiTfuKQBYU+d208Bo4CojPKnJRj01RFdZBnltZDRBY2crrWrNFJofdoF9adW4Ty3pl4k4AmvuiKRXrIkRrx55ZfSFKQ= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB5849.namprd06.prod.outlook.com (2603:10b6:5:1a5::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Tue, 28 Jul 2020 16:37:37 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 16:37:37 +0000 To: dmarc@ietf.org References: <87zh7ur069.fsf@orion.amorsen.dk> <3829fac4748a48d0b752403450843bd5@bayviewphysicians.com> <5F172EF5.7000508@isdg.net> <4c514db5-3f52-0e26-10dc-b7ed849da8d9@bluepopcorn.net> From: Jesse Thompson Message-id: <369ea706-1f0d-2214-29b3-75ad9e6b5055@wisc.edu> Date: Tue, 28 Jul 2020 11:37:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <4c514db5-3f52-0e26-10dc-b7ed849da8d9@bluepopcorn.net> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 X-ClientProxiedBy: CH2PR17CA0005.namprd17.prod.outlook.com (2603:10b6:610:53::15) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR17CA0005.namprd17.prod.outlook.com (2603:10b6:610:53::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Tue, 28 Jul 2020 16:37:36 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3a3681c7-926f-48b9-87d8-08d83314896a X-MS-TrafficTypeDiagnostic: DM6PR06MB5849: 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: dkvMAZOd31ZJv4tF3iUkn+kgb4mRIpWrvyqNc181WjiXyucNX/0GjiEQKhPktfQGUx2qV+G4xJQwa5H8aXW/uXVGeAoHQ3lBJ+Nsz04CWhzyxiT4PcAnRfLuIp+EzD9GnOuA3u/eKlAyTbCXsZjDKxqFGHCmm5HmH8zHo9lEqWBlxlpGmHTDc6BeoQo5EfDMthdyIz42/C5/I4Ey5ZH/eOGScmidOIb5NK8XoE+7ieIT9W42MkSJ5iYrmSUrut+k6WTe0Ivj1Rto/ZppRsdxWr0r5OM94Z4e/pb8m2uL2YdQD0Rpez6TVezsBdeZgJyUiuKBcsqeEvc6ctZT+N+mN4UQlSL7mWpjzUNQtXdhmRBADs+tjqhaXUglpXeY8zxumQy/y66Gh3TQLMusothxxlbzM+q5VqEbrxGZXBdormk= 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; SFTY:; SFS:(39860400002)(346002)(376002)(366004)(136003)(396003)(2906002)(66946007)(66476007)(66556008)(6486002)(478600001)(26005)(6916009)(6706004)(16576012)(2616005)(8936002)(786003)(45080400002)(956004)(36756003)(186003)(16526019)(316002)(5660300002)(8676002)(53546011)(75432002)(83380400001)(31686004)(86362001)(31696002)(44832011)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: xUCt/gPn5fy9l703uG5CI08FCxNSYn3WzbgRCyfFuoZKIL9E3eO8ObZUAdu+AH/PnFzVWWGbA5YIX9G0K9liTkIG9J54Wh0HutRaJmllSHNTvugB2aRtTZeFYcjmkqFWAR3htHw0zuE5yNeZkYqPP0s7JT9x65hpFw6Xcc2KgRoL3iZne/Dnvw8FUkChbE5E52CP2z2MkJiUKuZ+MCMx3Rm73nq6/JfyOt0DjTo76EkqcNVnGaWoSomnFJ6RXj4A30ORJmIKzkihmQYlKqaNqxsEAKIg6oC8fnUOj3xc9IKUq9SORopWqDY3RWIjWpIpnKficvrAYplUiMo+Iz+/5rK/yp4jHNRo5RGpBd+uQ0Gm0hCUVFvV/z4wZhPCuUkopppNhAu/GsCFf+lWrajnEGyXkdc21l/imzwoOPQsQDhmrfXAteOd/RENPH4pWG44XYUH3cv/VAXreScpV3sfFQzz7akEITZSuZlnpurFzphlZWpGzi8yu2xHMlQWiMGg X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 3a3681c7-926f-48b9-87d8-08d83314896a X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 16:37:37.2416 (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: dubnn7vcM1I3NAx42urzn88+ZDk/NvodWFX3ytvTONUuZt2wUxxj+GjNMMlTr9eaZbZo3gu2IPYvGkKmIu3cAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5849 Archived-At: Subject: Re: [dmarc-ietf] DMARC marketing X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:37:42 -0000 T24gNy8yMi8yMCA1OjU1IFBNLCBKaW0gRmVudG9uIHdyb3RlOg0KPiBUaGVzZSBnZXQgdG8gdGhl IGhlYXJ0IG9mIHRoZSBwcm9ibGVtOiBETUFSQyBwb2xpY3kgd2FzIGRlc2lnbmVkIGZvcg0KPiBv ZmZpY2lhbCBtYWlsIHRoYXQgaXMgYWJvdXQgYnVzaW5lc3MgdHJhbnNhY3Rpb25zLiBJZiB0aGF0 IHdhcyB0aGUgd2F5DQo+IGl0IGlzIGFjdHVhbGx5IHVzZWQsIHdlIHdvdWxkbid0IGJlIGhhdmlu ZyB0aGlzIHByb2JsZW0uIEJ1dCBpdCB3YXMNCj4gb3ZlcnNvbGQsIGFuZCBpdCBpcyBiZWluZyB1 c2VkIGluIHVzZSBjYXNlcyAobGlrZSBvbiBkb21haW5zIHRoYXQgaGF2ZQ0KPiBtYWlsaW5nIGxp c3QgdXNlcnMpIHRoYXQgd2VyZSBub3QgaW50ZW5kZWQuIA0KDQpZZXMuICBUaGUgY3liZXJzZWN1 cml0eSBJVCBjb21tdW5pdHkgKGF0IGxlYXN0LCBpbiBIaS1FZCkgbGFyZ2VseSBkb24ndCBrbm93 IG11Y2ggYWJvdXQgZW1haWwncyB0ZWNobmljYWwgbnVhbmNlcy4gIEJ1dCB0aGV5IHRoZXkga25v dyB0aGF0IGVtYWlsIHBoaXNoaW5nIGlzIGEgcHJvYmxlbSwgYW5kIENJU09zIGRlbWFuZCBhIHNv bHV0aW9uLiAgVGhleSBoYXZlIHRoZWlyIGluZm9ybWF0aW9uIHNoYXJpbmcgY29tbXVuaXRpZXMg KElTQUNzKSwgd2hlcmUgZW1haWwgc3BlY2lhbGlzdHMgYXJlIGdlbmVyYWxseSBub3QgaW5jbHVk ZWQsIHRvIHNoYXJlIGtub3dsZWRnZSBhbmQgY29udGludWUgZ3Jhc3BpbmcgZm9yIHNvbHV0aW9u cyB0byBwaGlzaGluZy4gIEVudGVyIERNQVJDIG1hcmtldGluZzogcGhpc2hpbmcgaXMgYSBzcG9v ZmluZyBwcm9ibGVtIGFuZCB5b3UncmUgdnVsbmVyYWJsZSB1bmxlc3MgeW91IHByb3RlY3QgeW91 ciBkb21haW4gd2l0aCBETUFSQy4gIEN5YmVyc2VjdXJpdHkgSVQgdGVuZCB0byBzZWUgdGhpbmdz IGxpa2UgRE1BUkMgYXMgYSBjaGVja2JveCB0b3dhcmRzIGNvbXBsaWFuY2UuICBPbmNlIHRoYXQg Ym94IGlzIGNoZWNrZWQgKHZhcnlpbmcgZGVmaW5pdGlvbnMpID09IGpvYiBjb21wbGV0ZSAoZW1h aWwgc3BlY2lhbGlzdHMgYXJlIGxlZnQgdG8gY2xlYW4gdXAgdGhlIG1lc3MpLiAgU2luY2UgRE1B UkMgd2FzIG9zdGVuc2libHkgaW52ZW50ZWQgYnkgdGhlIGVtYWlsIGNvbW11bml0eSwgdGhlcmUn cyBub3QgbXVjaCByb29tIGZvciBsb2NhbCBlbWFpbCBzcGVjaWFsaXN0cyB0byBjb252ZXkgdGhh dCBpdCdzIG5vdCBhIGNvbXBsZXRlIHNvbHV0aW9uIGZvciBwaGlzaGluZywgYW5kIG1heSBub3Qg YmUgd29ydGggaW1wbGVtZW50aW5nIG9uIGRvbWFpbnMgdXNlZCBieSBlbmQtdXNlcnMuICBNb21l bnR1bSBzdWdnZXN0cyB0aGF0IGl0J3MgZWFzaWVyIHRvIGp1c3Qgam9pbiB0aGUgYmFuZHdhZ29u LCBtb3ZlIGZvcndhcmQgd2l0aCBETUFSQyBmb3IgZXZlcnkgZG9tYWluICh0byB0YWtlIGFkdmFu dGFnZSBvZiB0aGUgYmVuZWZpdHMgaXQgb2ZmZXJzKSwgYW5kIGhvcGUgdGhhdCBJbnRlcm1lZGlh cmllcyBjYW4gZmluZCBhIHNvbHV0aW9uLg0KDQoNCj4gSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0 aGlzIGlzIGEgcHJvYmxlbSB0aGF0IGhhcyBhIHNhdGlzZmFjdG9yeSB0ZWNobmljYWwgc29sdXRp b24uDQoNCkkgdGhpbmsgdGhlcmUgbWF5IGJlIHRlY2huaWNhbCBhbmQgbm9uLXRlY2huaWNhbCB0 ZWNobmlxdWVzIHRoYXQgY2FuIGJlIHBpZWNlZCB0b2dldGhlciB0byBhcnJpdmUgYXQgYSBzYXRp c2ZhY3Rvcnkgc29sdXRpb24sIGRlcGVuZGluZyBvbiB0aGUgaW5kaXZpZHVhbC9ldm9sdmluZyBj aXJjdW1zdGFuY2VzLiAgV2hhdCdzIGxhY2tpbmcgaXMgY2xlYXIgZ3VpZGFuY2UgZm9yIEludGVy bWVkaWFyaWVzOyBib3RoIGZvciBwZW9wbGUgd2hvIHByb3ZpZGUgc29mdHdhcmUvcGxhdGZvcm1z LCBhbmQgZm9yIHRob3NlIGluc3RhbGxpbmcgYW5kIGNvbmZpZ3VyaW5nIHRoZW0uICBXaGF0IGlz IHRoZSBiZXN0IGF2ZW51ZSBmb3IgcHJvdmlkaW5nIGd1aWRhbmNlPw0KDQpJIG1lYW4sIHRoaXMg aXNuJ3QganVzdCBhIHByb2JsZW0gZm9yIE1MTXMuICBPZmZpY2UgMzY1IHV0dGVybHkgZmFpbHMg YXQgbWFpbGJveC1sZXZlbCBmb3J3YXJkaW5nIGluIGEgRE1BUkMgZnJpZW5kbHkgZmFzaGlvbi4g IFRoZWlyIGxhdGVzdCBhbm5vdW5jZW1lbnQgdG8gdGVuYW50IGFkbWlucyBzdWdnZXN0IHRoYXQg dGhleSdyZSBtb3JlIGxpa2VseSB0byBjb2VyY2UgdGhlaXIgY3VzdG9tZXJzJyBlbmQtdXNlcnMg dXNlcnMgdG8gc3RvcCBmb3J3YXJkaW5nIHZpYSBTTVRQIGFsdG9nZXRoZXIuICBNYXliZSB0aGF0 J3MgdGhlIG9ubHkgZ2VuZXJpYyBzb2x1dGlvbiBmb3IgdGhhdCB0eXBlIG9mIEludGVybWVkaWFy eSAod2hlcmVieSBBUkMgbWlnaHQgYmUgYW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gdG8gZm9yd2Fy ZGluZyBiZXR3ZWVuIHRydXN0ZWQgaW5zdGl0dXRpb25zKS4gIElzIGl0IHNhdGlzZmFjdG9yeT8g IE5vdCB0byBlbmQtdXNlcnMgd2hvIHdhbnQgdG8gZm9yd2FyZCB0aGVpciBlbWFpbC4gIA0KDQpN YXliZSB0aGUgY29uY2x1c2lvbiBpcyB0aGF0IFNNVFAgaXNuJ3QgZXZlbiBhcHByb3ByaWF0ZSBm b3IgbWFueSB0eXBlcyBvZiBmb3J3YXJkaW5nIGFueW1vcmUsIGJ1dCByYXRoZXIgcHVsbC1iYXNl ZCBPQXV0aCBzb2x1dGlvbnMgYXJlIG1vcmUgc3VzdGFpbmFibGUuICBUaGlzIHNvbHV0aW9uIGlz IGluY3JlYXNpbmdseSBjb21wYXRpYmxlIHdpdGggdGhlIG1haWxib3ggaG9zdGluZyBwbGF0Zm9y bXMsIGJ1dCBpc24ndCB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgdGhlIHJlY2VpdmluZyBlbmQgb2Yg dGhlIGVxdWF0aW9uLiAgSXMgdGhlcmUgYW55IHBvaW50IGluIHJlY29tbWVuZGluZyBzb21ldGhp bmcgbGlrZSB0aGF0IGFzIGEgc29sdXRpb24gYXMgYSB3YXkgdG8gbW92ZSB0aGUgaW5kdXN0cnkg aW4gdGhhdCBkaXJlY3Rpb24/ICANCg0KT3IgZG9lcyBzb21ldGhpbmcgbGlrZSB0aGlzIGp1c3Qg dGVuZCB0byBzb3J0IGl0c2VsZiBvdXQ/DQoNCkplc3NlDQo= From nobody Tue Jul 28 09:57:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76503A0EB0 for ; Tue, 28 Jul 2020 09:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY5NWSVRF8lv for ; Tue, 28 Jul 2020 09:57:27 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD783A0EA9 for ; Tue, 28 Jul 2020 09:57:26 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id 1so5885841vsl.1 for ; Tue, 28 Jul 2020 09:57: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=stHcsQn7P+jb3Tm3A8eepC2rC14EIeBvyPnJmTpfk9Y=; b=WHqrF0V/f0CqoI1YNnJgMVr6ROL0m0ZYcdD1gaZJWqaNScFA4Do3MS64DGtvQWNg+x Agg3WiEXNKtHYvOSnC68MpFP7xDjl+OGCdVyyujWXCET0KabwKHzNqlPTlShlFQsEafO cua7PIbvU1l2H8bcgw0VlRHIr4TMPf+BYG1ppVN80njDlTAtTY0ZAAWZSs6VWvT90JXr kaBwhVv2UJoG5GC9YcMEfGHBM0nJh97l2eRyat607vI72p4rIVMLwKM/pfO1w9zXXu5V wxuFx8U/t81GY+ihsDa5mAbI+V9HMF4n8ItsrY+ayyZ8sHmM1RBkkQGFEQ5k7k4TjI0L PUnw== 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=stHcsQn7P+jb3Tm3A8eepC2rC14EIeBvyPnJmTpfk9Y=; b=nnpIVeBZPYA9bvOCvk+uilWz0t9HuhP+pJB9Ma5sOofr5aQ5NDKMV4CDolFITLNNuF duLR4QEF0HgP1jPMKHlRW3jdpj6HWtdTyIaucFhu1HzkjVoWbxas76m9LFbyJoT2oihU ++0QvzIz83vSBecQP28bOpwcVaom86nUt86fVA13yU10z6+BmfFQM8I8YOaLRtmDOJQm On7BQKkjAiAm5IEei3DwRYWW9wRODPJ6ElDafNZzt+s8WhaOlJqF8z5LTB/H19yj4eCJ rroI9LkVfdMcdnf6XNnm3+6NQowKoU+CJLMxkaKNKjxm44H9NfOVpVXFw38675ALkVZE aCOg== X-Gm-Message-State: AOAM530HPqpjAInRIGWuC/7d/YI1eza1wO6GXnYrGXhJxk1uUDEqv5+3 WOXBz3n6x1RX9g/JK3ogB5szlEsG80jIFAZE+AlZVA== X-Google-Smtp-Source: ABdhPJwcUz29FUmfQH22TDsB8BuQcwutRdm7C8X6UI8bVYBI1W4TdMAujMP7CMipv8fFFG0wZvtiqrYgu0MrPhHmNCA= X-Received: by 2002:a67:f60c:: with SMTP id k12mr20831169vso.8.1595955445587; Tue, 28 Jul 2020 09:57:25 -0700 (PDT) MIME-Version: 1.0 References: <5F204D85.2020808@isdg.net> In-Reply-To: <5F204D85.2020808@isdg.net> From: "Murray S. Kucherawy" Date: Tue, 28 Jul 2020 09:57:14 -0700 Message-ID: To: Hector Santos Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006963a305ab83558b" Archived-At: Subject: Re: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:57:34 -0000 --0000000000006963a305ab83558b Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 9:08 AM Hector Santos wrote: > Sorry I missed it. > > Is there a video capture? > It's standard practice to make the audio stream available afterwards. I don't know offhand if they're planning to make the video presentation available. I'll find out and report back. -MSK --0000000000006963a305ab83558b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 9:08 AM Hector Sa= ntos <hsantos@isdg.net> wrote= :
Sorry I missed it.

Is there a video capture?

It's stan= dard practice to make the audio stream available afterwards.=C2=A0 I don= 9;t know offhand if they're planning to make the video presentation ava= ilable.=C2=A0 I'll find out and report back.

-= MSK
--0000000000006963a305ab83558b-- From nobody Tue Jul 28 09:59:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB93A0D8C for ; Tue, 28 Jul 2020 09:59:51 -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 brfH-CI_l5Kt for ; Tue, 28 Jul 2020 09:59:49 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 253623A0CEE for ; Tue, 28 Jul 2020 09:59:49 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id j186so10524904vsd.10 for ; Tue, 28 Jul 2020 09:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Y4HVY88HimZ9204OAB7VXSxHV3i2OEhr20/l3olfxk=; b=lBF8idb9U/plkRceSNdgA7TTro1l6YyYsOQtwrc4CtAc9BGg8KY2JFLNxulYywpRY1 F25uV0cY0jX1xskzFCUqJ/FZmr/KKlsW67Ub2hfxEhBHYeR3W4o7mn0300YoUeCY7ME5 NNKvNTSWUmGfLk6hSdgsv5hN2lEekBFiutg5byKVzki+Eyuz7BB6cFwhOTui0vujAk/o Dwj/koIO82NhDxygJl0OVVSISqrUktNLEfibpxWDQjYrXvxRwRNqRmnwMHmx8Yh9O13H qoCZQj6qYiy4Jz2Yhzz2+n5HKXfmWlsSFTgEH72Dnc0+Aci0nnTAefYcFbmAFwZZQgrC /Fiw== 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=3Y4HVY88HimZ9204OAB7VXSxHV3i2OEhr20/l3olfxk=; b=kge2KZLN577AqPmVuu9Dl33jLGoypKCOtXXSJDUiZaVYMNsU4NdVBpx6owujefdsN4 jEY/vNs3URcAThxm+bsnTEwmHWI9hW0Ux4VNLsyxr7GJ359gX+vODq1CpvkFMp8l9ObR eEOUNHt28ch0qE1uTPiK8JZrr5+UTD87l1nPnVv9Tbyw5QFOQNZKHCq+cajwXW8aoe02 XJc5jjmcDuhd6YAg22J6+FUDQ+QKu4prQfU2H/hW31gs+I4N3bfU+KHSDVtcF2zEpt6v jYO7FhtPq1rmAWakZdpzIisDGdoGBM8YME89HOWm0KJmRB9mEZzES/I83XPrraXRos3E pCOQ== X-Gm-Message-State: AOAM530hCLXJuYK83w2jV3NN1vogPT3mmt3v2Qz/poLRqz51XErOOxHE NqHUCLa6nIBjE4eALFBkapbfCykp+fmoQ7NR2xXcig== X-Google-Smtp-Source: ABdhPJy6IAUfiBi0w0Dn2/itUCXIY/JTHp7Kyc5MyvGEH5UT/V2iEjcYDwpYKdz/bblg9L2FIifUcytdcA4b6MvECGQ= X-Received: by 2002:a05:6102:31bb:: with SMTP id d27mr20329369vsh.175.1595955588051; Tue, 28 Jul 2020 09:59:48 -0700 (PDT) MIME-Version: 1.0 References: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> In-Reply-To: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> From: "Murray S. Kucherawy" Date: Tue, 28 Jul 2020 09:59:37 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e7364505ab835dcc" Archived-At: Subject: Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:59:53 -0000 --000000000000e7364505ab835dcc Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 6:53 AM Dave Crocker wrote: > I am not a fan of splitting documents only for an abstract sense of > cleanliness. There needs to be justification of improved documentation > 'cleanliness' and/or useful removal of fate-sharing -- if separate fates > are reasonably expected. > > > DMARC alignment validation is a basic, mechanical process that produces > a yes/no response. At that level, it's comparable to the nature of a > DKIM validation, except for the From: field domain. > > DMARC "policy" is fundamentally different. It's not that its mechanism > isn't "mechanical" but that its semantics produce more semantic and > operational challenges. > > > I think that could reasonably make it worth strongly separating them > into two different documents, no matter has small one of the documents > might be. > I think it was you that suggested having the determination of the Organizational Domain be its own distinct process. Would that fit into the first document, or should that also be something external? -MSK --000000000000e7364505ab835dcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 6:53 AM Dave Croc= ker <dhc@dcrocker.net> wrote:=
I am not a fan of splitting documents only for an abstract sens= e of
cleanliness.=C2=A0 There needs to be justification of improved documentatio= n
'cleanliness' and/or useful removal of fate-sharing -- if separate = fates
are reasonably expected.


DMARC alignment validation is a basic, mechanical process that produces a yes/no response.=C2=A0 At that level, it's comparable to the nature o= f a
DKIM validation, except for the From: field domain.

DMARC "policy" is fundamentally different.=C2=A0 It's not tha= t its mechanism
isn't "mechanical" but that its semantics produce more semant= ic and
operational challenges.


I think that could reasonably make it worth strongly separating them
into two different documents, no matter has small one of the documents
might be.

I think it was you that sugge= sted having the determination of the Organizational Domain be its own disti= nct process.=C2=A0 Would that fit into the first document, or should that a= lso be something external?

-MSK
--000000000000e7364505ab835dcc-- From nobody Tue Jul 28 10:08: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 6B1833A0ECD for ; Tue, 28 Jul 2020 10:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu-29j-7wAds for ; Tue, 28 Jul 2020 10:08:32 -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 5B2B03A0EC9 for ; Tue, 28 Jul 2020 10:08:32 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SHB8n1028979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 10:11:08 -0700 To: Alessandro Vesely , dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Reply-To: dcrocker@bbiw.net Message-ID: <6dc2bf95-6f0b-13d5-49cb-1ab0b9a6a37c@dcrocker.net> Date: Tue, 28 Jul 2020 10:08:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:08:34 -0000 On 7/28/2020 7:20 AM, Alessandro Vesely wrote: > On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote: >> On 7/28/2020 4:00 AM, Alessandro Vesely wrote: >>> On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote: >>>> On 7/28/2020 12:26 AM, Alessandro Vesely wrote: >>>>> Receivers can evaluate the Author: domain just like they would do >>>>> if it were the From: domain. >>>> >>>> So you want to define DMARC as applying to both the From: field and >>>> the Author: field?  That will defeat the benefit intended for the >>>> Author: field. >>> >>> Yes.  In case of conflict, evaluation of Author: has to be omitted. >>> For example, Author: fields containing multiple mailboxes are not >>> considered. >> >> 1. I don't understand the details you have in mind that would make >> this useful. > > > It is an optional evaluation.  It's easy to do, if you already verified > DKIM and SPF.  It is not terribly useful, admittedly, except that having > two or three "pass" makes for a stronger authentication than just the > From:.  The chief reason for evaluating it is to give feedback to the MLM. There is no specification for doing this. It means that there is no basis for the creator of the Author field to expect such an interpretation and no basis for a receiver to apply it an expect it to be valid. An interoperability standard require a shared definition of action and meaning. The sharing is among the actors participating in that standard. For one side to choose a behavior or an interpretation that is not documented and shared by the other participants is to pretend that a heuristic is more than that. > >> 2. Again, this seems to defeat the purpose of having the Author field. > > > Why? The field is intended to be free of the problematic treatment the From: field is now getting. You appear to want to encumber it, so that it experiences those same problems. >>>>> As a new field, Author: doesn't wear a reliable-id trophy, hence >>>>> receivers may refrain to apply policy dispositions.  However, the >>>>> result of the evaluation, conveyed through aggregate report, can >>>>> tell MLMs if rewriting From: was necessary. >>>> >>>> How, exactly? >>> >>> Author: and Sender: domains can be included in aggregate reports >>> along with the From: one.  The policy_evaluated can also include more >>> items, specifying which evaluations pass or fail. Yes, one could modify DMARC to have its reporting include additional information. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 10:20: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 B59033A0D61 for ; Tue, 28 Jul 2020 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gdIDhdMtC_Mw for ; Tue, 28 Jul 2020 10:20:00 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB8D3A0C59 for ; Tue, 28 Jul 2020 10:20:00 -0700 (PDT) X-ASG-Debug-ID: 1595956798-11fa3118c745220001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id MA5qBKim33YCllGk (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 28 Jul 2020 13:19:59 -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:subject:to:from; bh=lblp0YmVPUOn0zmEprO2mL2tcXTDjsGP/Q70DQBv+F0=; b=CJzX4kmJ7dfCWhCly2FHMXUh+Apz1WTICFsGZO9ZraBw+vupVwNQRc2Sn1nSparpl qctTP6v6fX23Vf1adf/HP4AFtYA0VwxfGMZXWj0VOPx6bJYVFv96WGrpKhFZKMsmw 3vMUFUe7GvxvcqcV2PgMiervTGLl83JYwbEom9VqE= Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 28 Jul 2020 13:19:50 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.108 To: , References: <5F204CB3.7080404@isdg.net> In-Reply-To: <5F204CB3.7080404@isdg.net> Date: Tue, 28 Jul 2020 13:19:50 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] non-mailing list use case for differing header domains Message-ID: <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHpygXkweDZoazBxZSoCWqrH1jAwK4lOz+AZq86VYCK6Xr9qoGv4mw Content-Language: en-us X-Exim-Id: 000001d66503$4d447e50$e7cd7af0$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1595956799 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: 638 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83526 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:20:02 -0000 Hector, I do not understand this comment: "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd = party domains. DMARC did not address the problem and reason ADSP was = abandoned. Hence the on-going dilemma." Domains that participate with a mailing list have the option of = including the ML servers in their SPF record, or delegating them a DKIM = scope and key. But to obtain that authorization from the sending = domain, someone would have to ask for it, and might not receive the = desired answer. The goal of this discussion is to find a way to coerce trust. We do = not lack ways to grant trust on request. From nobody Tue Jul 28 10:37:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B93A0A4D for ; Tue, 28 Jul 2020 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3nNJU0o-P_W for ; Tue, 28 Jul 2020 10:37:16 -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 AB4EB3A0A49 for ; Tue, 28 Jul 2020 10:37:16 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SHdpUt031835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 10:39:51 -0700 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <579385ce-b67d-9db0-0a9d-fdce9fece75d@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 28 Jul 2020 10:37:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Separating DMARC alignment validation from DMARC policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:37:18 -0000 On 7/28/2020 9:59 AM, Murray S. Kucherawy wrote: > I think it was you that suggested having the determination of the > Organizational Domain be its own distinct process.  Would that fit into > the first document, or should that also be something external? I'd wish for that to be entirely outside of DMARC, because the issue and the mechanism are not specific to DMARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 10:37:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7319B3A0A53 for ; Tue, 28 Jul 2020 10:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HI9WVSeZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=F2BgghYH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCDUAsQSxYpv for ; Tue, 28 Jul 2020 10:37:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86FB3A0A49 for ; Tue, 28 Jul 2020 10:37:17 -0700 (PDT) Received: (qmail 79491 invoked from network); 28 Jul 2020 17:37:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13680.5f20624c.k2007; bh=lVH+uu98EjCJkVhzWKhe0LhYVvO74AeBpjXfmq2bBOk=; b=HI9WVSeZVc6EgAgDVoqtxnzZvRg/akOCDrrHu6W4VHzj1iINbSKzxs++uI+0ry6f5u9DwF0WOA8N2MW0a59E1LCeMtPlINzbk0utlKq5ZS2jI5km6MaXOIExdbWi/kyqwMwIlDH7XTxgFXVIcObljXca73R89FuX+vzUsV0E1GEDmSKS80+Sp+9jy0ayO5JaEWIE616VImn61qs/PdunwRA10Iu8n9EOpzdLl78vG1Xblfq/oZmTGt4j9q7ouXIr 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=13680.5f20624c.k2007; bh=lVH+uu98EjCJkVhzWKhe0LhYVvO74AeBpjXfmq2bBOk=; b=F2BgghYHI+vZI17dcI2T4uSF0/9yisSyR9GnFKbE65AwuYx8ZON02NzB4jT9ja3blYQwozvOjyLSe0ZNaR9U9gSc/dcfI14CQIkMM4sP3e7kv/TbcKXdcZ5KynAZEGcap5Vpnm0p4F7CTj6aAhGGVUsliAafHiycgkNwPEzK/FfpnvkNL7xnmy7naYwAntglHO+gLRrJtrAiujfiJc04P/aCx2ZM50k9rKs1M9UOL6ElgslLFYWb5eh5J0bJrTdV 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; 28 Jul 2020 17:37:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 068CB1D9840C; Tue, 28 Jul 2020 13:37:16 -0400 (EDT) Date: 28 Jul 2020 13:37:16 -0400 Message-Id: <20200728173716.068CB1D9840C@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: atyrsalvia@agari.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:37:20 -0000 In article you write: >To put it another way: > > * assistant@firstbrand.com is organizing a meeting for executive@secondbrand.com > * assistant@firstbrand.com sends out a calendar invite from their own messaging client, using >executive@secondbrand.com in the From: field > * The resulting message uses executive@secondbrand.com in the friendly From: field, but firstbrand.com in the >SMTP MAIL FROM domain, so the headers are no longer aligned for SPF. > * Both firstbrand.com and secondbrand.com are set to DMARC p=reject. > * Messages like this are then rejected by receivers that validate DMARC results. This sounds like an excellent use case for Dave's draft-crocker-dmarc-sender proposal. The canonical example of different From and Sender is exactly this: Sender is an assistant working for and sending mail for From. R's, John From nobody Tue Jul 28 10:41: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 16A6C3A0A66 for ; Tue, 28 Jul 2020 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GF3QBgDv; dkim=pass (1536-bit key) header.d=taugh.com header.b=txwperV3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18NQpWUekZde for ; Tue, 28 Jul 2020 10:41:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59213A0A64 for ; Tue, 28 Jul 2020 10:41:36 -0700 (PDT) Received: (qmail 80839 invoked from network); 28 Jul 2020 17:41:35 -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=13bc3.5f20634f.k2007; bh=0bOU9/gxeTXPZUZoNx4cRumZp+/r7Z3HDfdppQByDrY=; b=GF3QBgDvgAag0Io8cHJ1Ki61HnQop3sEu6IVGjMYQ2lUAf/2KA7fxG0RagYdLynYuStfI8DI782AM04cFJN+FGe73yV2hYc/5sMjP3MVWhVX4PsINYKFY6Q5lsEKZ7r5Ywl9FEU0og+YXGZ0LOZM03izTCUdFx1xJQvJU2CX1tEoEagO2RuciN1pxx91riT03T5BhlSOcPu5FdyYriqNFFOWrjLcsHA4bJ5skyVk8yefKNUPJj73Fi5oZqFm1h0/ 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=13bc3.5f20634f.k2007; bh=0bOU9/gxeTXPZUZoNx4cRumZp+/r7Z3HDfdppQByDrY=; b=txwperV3O4bY7sj1lJqxrDylgky6ni2LV3iHgI2zGzwaQbAiVa50bEshUa3m4YpU9hywDrgOplMeRhZIi9tAF75OkhExl0gsJGlba4WY9AnqMuJzOjmeouYXOI2slMcGdof0eNk2V6RMi9MnQnhxEpUlfXJ74qQiN1Xch64yvhn56B/7vRcmiXd6FfcfNI6Nn3Tf0F0uMOHYm9CnIE4qFjZLZN9UIxvSyS5zsPtulbYysQXrAI8h1yBPn1dq5ti8 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; 28 Jul 2020 17:41:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 72B2A1D98455; Tue, 28 Jul 2020 13:41:34 -0400 (EDT) Date: 28 Jul 2020 13:41:34 -0400 Message-Id: <20200728174134.72B2A1D98455@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it 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] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:41:38 -0000 In article you write: >In the pre-DMARC era, we've been mainly using just From:. Sender: is used by >Outlook to display "on behalf of" catchphrase, presumably in an attempt to >support the historic Sender-Id protocol. Sorry, no. That is completely wrong. The Sender field has been part of e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along until the 2000s. Outlook's annoying "on behalf of" at least matches the intention of the Sender field. This might be a good time to read up on mail history rather than guessing. R's, John From nobody Tue Jul 28 10:49: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 2BFEC3A0B0B for ; Tue, 28 Jul 2020 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LdgBPCTA; dkim=pass (1536-bit key) header.d=taugh.com header.b=Hhok6d7I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEJolv9JbkKW for ; Tue, 28 Jul 2020 10:49:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2413A0B85 for ; Tue, 28 Jul 2020 10:49:25 -0700 (PDT) Received: (qmail 83089 invoked from network); 28 Jul 2020 17:49:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1448d.5f206524.k2007; bh=FEXMxQcjzMqZXU1mvbe72D2m2Fl1DYrgl+1kHE9kbB0=; b=LdgBPCTAEKqCQGcwKQe2nhm43GEehIQztaracp+c+bn3Wfzuynp76QzsZrswRSkCTuJU3LO6v4UrExkQcmmcjKEFy/29hAOMU6NyfqXfHjd9LFLS9ED8v40WGvDuTxAKLXH8EAJHtoGvSw1Hv38cV5GrDntoBEUrjtzNSt6Bt6Ln79Nnfo2bwjXgYYpttDVPhKBeW/D+X9F3VIARYAAiiXXR/AhaA427oZFmTaZcTdUsy5cb0I3RLjuSG8cFZSgt 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=1448d.5f206524.k2007; bh=FEXMxQcjzMqZXU1mvbe72D2m2Fl1DYrgl+1kHE9kbB0=; b=Hhok6d7IufpgOlkswk9pWBKn5dJfAs00rfvLRUO+ddPvAE0jvrk4vOEjjEJXYcK/YTBlJKp+suILxo5/B/NeGjUmUwsBfVgnmetABzvN6Wkk++8m9Y/FI1bN3EseoRUMl58Jv0eLoZUScugxLXz9sKkrKUC6U+nP+Evqmyos7WvA/4/Fr0y5g4diH3PUJrWiCLGhmBDHg03EZGxnxOqmbwjTHqmFGiiz4Y4Ep0thQglGT0U6X4lkaVWuvkJoQOsJ 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; 28 Jul 2020 17:49:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 905741D984A1; Tue, 28 Jul 2020 13:49:23 -0400 (EDT) Date: 28 Jul 2020 13:49:23 -0400 Message-Id: <20200728174923.905741D984A1@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: smj@crash.com In-Reply-To: <188ab9f5-6152-65bb-9645-d59dd7463607@crash.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] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:49:44 -0000 In article <188ab9f5-6152-65bb-9645-d59dd7463607@crash.com> you write: >Having to flip back and forth between the chat column and the >queue/participant column was awkward. Assuming I didn't miss a setting: >Why can't we have both shown? At least as an option on larger >screens/windows/devices. I think just about everyone has a separate jabber client open and leaves the queue visible in Meetecho. It wouldn't be very hard to provide an option to pop one or the other out into a separate window. Also, I found it hard to tell when my mike was live. (For video at least I could see myself.) The hint is that my name turns green at the top of the queue column and there are some icons next to it, but I could use clearer unobscured hints. To repeat a point a zillion other people have been made, the tool tips should look like they do in every other web site rather than all appearing in a box nowhere near what you're mousing over. From nobody Tue Jul 28 10:51:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C493A0A8F for ; Tue, 28 Jul 2020 10:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OF6eFsDT; dkim=pass (1536-bit key) header.d=taugh.com header.b=Pbx/DsFm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11VWA6VfI4HM for ; Tue, 28 Jul 2020 10:51:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541613A0A64 for ; Tue, 28 Jul 2020 10:51:23 -0700 (PDT) Received: (qmail 85479 invoked from network); 28 Jul 2020 17:51:22 -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=14de5.5f20659a.k2007; bh=SGTLGjS38Ndxr/AI2e0rkSNTGUlDKU1lfUSJah6ExvY=; b=OF6eFsDT9IBdvPzdOvoLtq2/fJx+nGHwyVXXYwwigX03EXxvsAVTzc66aKOopxx6BA7YW8Zun6kRa8+2l4atrKNm4/jrd+JoIn27SGcUjHFvb9LEDs9RKt57Sw+Uv9R/Yk+NIk48Yo28SRmSw2/89wZRj/CHzC2Tt33HDoJSDrXkC+/Jqc32zTl2AkTiMcvWgsxpmZxcYaCJENJkihRGWt8ZiEsf1cVPFzE5JaO7wtQWFdMrpCWJK328h7hOXesM 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=14de5.5f20659a.k2007; bh=SGTLGjS38Ndxr/AI2e0rkSNTGUlDKU1lfUSJah6ExvY=; b=Pbx/DsFmUkh+LMhmqmbQ9LkDYwp4iwSLfOvJakJMmwUiH3Qj57h6FsHFAe1HLbT2Vj+ghzhuU+gMYUaYed12jhumkPHLeOXL8eYg1QwiX1tBw4Cb20bgpXw4mXSskk52Q0g0VlumLfdeWVRQe1vvmcCijVhwtPYFPeVYpnjQdPVIJ7ZQVkx/rwyL8lc3COko6G7Ue9jYmpyyyo+OKQe/84fkGR8diNvA9Kve7rOKDK2TWj69PZgIPgnepLFRTtcU 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; 28 Jul 2020 17:51:21 -0000 Received: by ary.qy (Postfix, from userid 501) id 56B9A1D984AD; Tue, 28 Jul 2020 13:51:21 -0400 (EDT) Date: 28 Jul 2020 13:51:21 -0400 Message-Id: <20200728175121.56B9A1D984AD@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: <7fb1b50a-4557-108e-b008-235758d00874@tana.it> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Meetecho at IETF 108 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 17:51:25 -0000 In article <7fb1b50a-4557-108e-b008-235758d00874@tana.it> you write: >At mine, the audio was disconnected right after your presentation. (I couldn't >hear Bron's comment). I tried reloading and reconnecting by the spin icon in >the lower right corner, to no avail. Dunno how hard this would be without breaking the crypto, but it would be nice they could adjust the sound levels so everyone's voice is about the same loudness. That's a standard technical trick, we had a box that did it automagically when I was doing student radio in the 1970s. From nobody Tue Jul 28 11:01:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FBD3A0CD7 for ; Tue, 28 Jul 2020 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UuoLrvXe; dkim=pass (1536-bit key) header.d=taugh.com header.b=RHssMtXD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzcVXqobnx69 for ; Tue, 28 Jul 2020 11:01:26 -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 A33DB3A0C1D for ; Tue, 28 Jul 2020 11:00:55 -0700 (PDT) Received: (qmail 88630 invoked from network); 28 Jul 2020 18:00:54 -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=15a33.5f2067d6.k2007; bh=XNMl9ru9XfWpM/85RGqQZw92Jb2t8Geh9GZhL7kAlXg=; b=UuoLrvXeUUHhGrmGXTlqvp05YKLLFzF6eTyYXqLLeWoNwpCaWsRgh+nO6SfySksTAnFrpAEHDx6c362AJ48K4z8MmMPwOVBZV13M94lgdZ8KhXhf9FykUzLxlq78X+6DCqiKWApfbb3UNPW2av9pBDZXzxc09T0qheEJFmBmg1FUqnweg5j078mfuafH0xuP6HzTEXCaIlcaN/hrzmzO649KCNXolsQXdJd3xZ6UGdZQvdfsfVzB5UTU4b5vjVKZ 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=15a33.5f2067d6.k2007; bh=XNMl9ru9XfWpM/85RGqQZw92Jb2t8Geh9GZhL7kAlXg=; b=RHssMtXDTu9dGShl262TrmBWsLh75yIlKHqRJDEkdCc8Bk6Ac9JA9o96ssJpGancBQMJPib7+dukhNXYfO+fFLWFYK5uG1EzTeu+8gkMOo0izHjV+JU+SpKncWiS4mDKSts6Gqqqtmmkt6tFEiaQ2I84/18CNpSpBKFjWz5g3FbxzQHHqCIv5hn+D3ONIX2IcX6KAfKlxUfmx9QFzZ+TayubJ6mO1kmCB/KvLpz0WZ0K+DvlMzA8uAd3NsdiHFvV 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; 28 Jul 2020 18:00:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 44C901D98571; Tue, 28 Jul 2020 14:00:53 -0400 (EDT) Date: 28 Jul 2020 14:00:53 -0400 Message-Id: <20200728180053.44C901D98571@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net 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] Separating DMARC alignment validation from DMARC policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 18:01:33 -0000 In article you write: >On 7/28/2020 9:59 AM, Murray S. Kucherawy wrote: >> I think it was you that suggested having the determination of the >> Organizational Domain be its own distinct process.  Would that fit into >> the first document, or should that also be something external? > >I'd wish for that to be entirely outside of DMARC, because the issue and >the mechanism are not specific to DMARC. Unfortunately, we all know where to find DBOUND. I suppose now that the smoke has somewhat cleared we might take another run at the PSL problem, trying harder not to boil the ocean. R's, John PS: https://github.com/jrlevine/bound From nobody Tue Jul 28 12:52: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 9ED983A0BEE for ; Tue, 28 Jul 2020 12:52:39 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 N4AfmCtY_m0Q for ; Tue, 28 Jul 2020 12:52:38 -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 D991F3A0BF0 for ; Tue, 28 Jul 2020 12:52:37 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QE700J9R37O0B00@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 28 Jul 2020 14:52:37 -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.7.28.194817, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.66.43] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g6H7XYOyiC/x4Wpea6hsoTBu4blq3CdhLizK7zLcGirXJ7vDvtK/kRC1cf+sJ3eOFzupp+9/V0kB/cR8AaJ2jt3C/S/NTvPl29PPpPcesn4U51yt8G+gEwz9LSdknswolWyhPyAPgC6FCm90LbCGHq/KNvNFE/TgupTiMCH3zbG3OI1cYGOLFqicLMGL1kZM7qpmPXZZeYrxgSexJGclYVR3PENUZTqq0tWSZHMjGkIXTNVD1b7IoJzNx0flroOdGY7kxThNr8U4sz1IMJC2r6BEYJ14HEuW3k62x7BffIHh/UJ+92PSoXCTikXdT4HuHb1AGWz3Q4vjFuJ2kFfsWw== 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=W9htfAC8xSHQwB3h3pOpBOomL6T8nZa350a+KDSHZR0=; b=S9tMCeelSiY/sAPRzACIqpQoFD9onjWarUBPtK6dzAYZVqj1zWJWtneIa8y5kXiEsA3SClpJ3//41lNTGky10cRZlJ33kAt91IfCplU1EmommnGtiZdYEN1m7w0PlIvVgpXBo8wr1htcztTjMhh6mPXLrtEYadgACuWuk+WnZF8RQgwKUKohqG50opHCVIjDYaFcAJZW/TikeKa+mKs33qa5jZWPjUTZSkJqkDv5BUzveWWP12mpQfCkJWo2WcJSk9ap5bXfvRd9/OFIWkZEo3CHs9tRZmMERq9Zy6VC0Zqa6NQqMc9GUC5ecbQdPRjVhFAaq1+24p0MFUYikYCCUw== 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=W9htfAC8xSHQwB3h3pOpBOomL6T8nZa350a+KDSHZR0=; b=NrfUWADuphOW6UEMXmn2k9ulE3CKtv1DFY++zk6uPbbefMX/hr/IutKeRoygcbN9CwYXCaZHUpX+KUB3Jnj1jJYjztleuynBpWjxdis8CILUeOcQO5kmUvO+zmhgEujl/BBm1g1gTG4UywYKC52OYfRpiffkg4GvHq+NgwZzN6I= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB6089.namprd06.prod.outlook.com (2603:10b6:5:1b0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Tue, 28 Jul 2020 19:52:35 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 19:52:35 +0000 To: dmarc@ietf.org References: <425a4f5b-3bd7-6c24-b0ea-96bf80947407@tana.it> <4E0F8EDE-6D3E-427F-960B-D6BA7E426CE7@wordtothewise.com> <2c8446d6-623f-08ce-b852-c6ac5521b74b@tana.it> From: Jesse Thompson Message-id: <6a5bf1dc-15f6-291b-c99a-6f1145da3eda@wisc.edu> Date: Tue, 28 Jul 2020 14:52:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <2c8446d6-623f-08ce-b852-c6ac5521b74b@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR04CA0001.namprd04.prod.outlook.com (2603:10b6:610:52::11) 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 CH2PR04CA0001.namprd04.prod.outlook.com (2603:10b6:610:52::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 28 Jul 2020 19:52:35 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 14e9eeca-69a3-47af-f859-08d8332fc62f X-MS-TrafficTypeDiagnostic: DM6PR06MB6089: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2887; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xr8DyqaFtEF6kMKFlxHhbfuJ+Mqh7osQPQ2Jnc0n+oGj+vJQUw/Y0zEzEQQA6wPPsDQmx64MU9mLXMOmJC4Bw2mS5uIm6AS7OjpBDnNbI87D8KQUzLD7AO7UDXUxGJCjMZzMJ/TTW6zcZeN/wAqGb6B1/CdG/uorPUZGgS5Lo8s5s8qM+zlbqIFTsAOfL5/8CHHtuNUMyHMEtvJsekHBwVBqup/b5kz4cEC7WivRLQ1DYD+T6KCw8eRIxVcOGle6yKR35/gaOCWiA5igAFEHffNyWw7uY3kRu+G/d0tlXYHE0kUN8ljsen03YwMrw+tl4qOggiDngxo0Y8qFd2jAJ/lV5nM144Az9tlNABQvQFUAUHp+U6PFzftZVvCaYIzfomgAv5rg5J44vMTfJ/5tfKDGYFjukiJtLeD0ie4EXA5Hme+0sVuYKG/R7Duswxbi 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; SFTY:; SFS:(136003)(366004)(396003)(346002)(376002)(39860400002)(31686004)(86362001)(36756003)(4744005)(8936002)(44832011)(6486002)(5660300002)(2906002)(75432002)(31696002)(66946007)(8676002)(478600001)(53546011)(26005)(2616005)(786003)(186003)(956004)(316002)(16526019)(66556008)(16576012)(66476007)(6916009)(130980200001)(43740500002)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: UuTFkC60OhdzQdogpy6+sbSjBn7QwIFqkusotYudaDu4ZsO2G6MXS5EH1gw+L2rHk8D7vX0LkeoxdYWFlrxiSbW+KSCF6m1hYOP1iFSvp/EA6+6I1EJgttw23XNgWJJcvgcOBh9HXD+dc+z88flEQS9OQjGpKZm5pGvnk+xKElcfWyKTSdkk27NLWPA+CIFh/0orFTMfEymS2fkm0V6rYeuesY8Gr1Hg8t6cw+1MtCmoyKKGbsp+aVSRL8fC+SMvALYpoyM1YojB+f/o5gGyYBu/Po6TaH51hB/9ciqE5DHoKRJH/66VTTNYlNbG+Ih/HO2mQQpNQt7kr9G6QzTzgBAjCCPsCtfqoJ55NOkFuuKyZYXDAtSBlg9nM/W/kvkwEk2qFJwMVfIG9X0RhRxPw8mY0YmZBH9/0cdrMhAJ1cCDTw6i+J85gPXYimkbofcAUbO4o3u6gQVERRdXES9I9nZQ8tjGyPNfDGjQ3BKUzPM= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 14e9eeca-69a3-47af-f859-08d8332fc62f X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 19:52:35.6186 (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: nkd2VWfJDfZGiSmqVNhAwyD4ZZOARSmlHMkMpSuxcx7ILEtKmlDJKTFQabm2gdF1zOSFrm7YLxlTsfFd+96rsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6089 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:52:40 -0000 On 7/28/20 10:59 AM, Alessandro Vesely wrote: > I understood the problem is the lack of agility.  Delegation to smaller domains using local servers would solve it, wouldn't it?  Even with many domains... > > What am I missing? It's assuming there are local servers in the mix, which is becoming less common with the shift to the cloud. e.g, I am fairly certain that O365 doesn't have the DKIM flexibility you're talking about. Jesse From nobody Tue Jul 28 13:13: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 C417A3A0BF3 for ; Tue, 28 Jul 2020 13:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM5ZD1V3IZ7i for ; Tue, 28 Jul 2020 13:13:53 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 DA5DC3A0BF1 for ; Tue, 28 Jul 2020 13:13:52 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id y11so6784341qvl.4 for ; Tue, 28 Jul 2020 13:13:52 -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=rKBe/3rHwhAXJbXUxthuBtohf6RxPnVdOHaaOcw17GY=; b=JU7n6irUuWHmeUFgR+ssYg4xg3xE+4PEN3PK7bAqH9Sl533avpEO4Zr1YMG2pCOCb5 mYHEfxwYi8SFo4FoUKT7GZntzWdTmDnHk2RDDsZQcj9Si1RPZZ9RhsKBgCpWvtiJrirz nYCBX6Ud4NmptPGOBAWcsXD6liz43DjFKXKgNzIAytb/iZoIHKs3QwY1bbH7bEF37aR+ NnjULZeuuEZqRqO6bZ2eTXJTX3OuSDwFiFth0Od+0puMFeLp9/5GxDrhr0Ji8tIPCPWq d4u11Vkp2EuYEgVUt81b1EUwkLdKUNMLdBEPEkfb/Q3kKbx5/kLHrPtDma/7YplPi07J ClBQ== 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=rKBe/3rHwhAXJbXUxthuBtohf6RxPnVdOHaaOcw17GY=; b=PLoXZsAsghlXjZgx7UO4J3YA9jrHd0DKK9PRy5feMg9MV2P1a612mG9BGzSSh/Jz50 RIMnemhq56IFMGoinyjxH6DeQVyTDaCG3FaCfToUKMhdRsI99hWolAa8RXuNOVrWNdn3 WAxpLyj5BjWnRbMIYn92ac5g+sT5bcCE/f8DwlRr6yB19EFwuXtp1rzsoC+RzMoWY54M 1qaqTAQS27gX6EjP3Vzq3EIhHuc5z+M0xcLRA7vYf6uK3fZoc4hd3CDLvc94wyJobAAc mUeQ2GK/8JJ2QbYg0vmnTE9sjfghFCPIuz7a7APbVI+xpDmXt6GJzG7E74wKUwy3e3Cm ZgrQ== X-Gm-Message-State: AOAM531XDSNMT7v1blgUcUoiV/21/NCDIroo8TAeLXTp9mrLGTWqvtDJ uDoNCD1OWbut6QkfUYXTg63abnQju72+5xtx4FfLXw== X-Google-Smtp-Source: ABdhPJz5Q8Jf5XFtepYrc0JLNq77oWTLCNN0fF+3VC8A/f97QHmHlH5DM+4PUPQUMZsalJFFrQZfV70708pHRXoPl5Y= X-Received: by 2002:a0c:a306:: with SMTP id u6mr29450208qvu.88.1595967231680; Tue, 28 Jul 2020 13:13:51 -0700 (PDT) MIME-Version: 1.0 References: <20200728173716.068CB1D9840C@ary.qy> In-Reply-To: <20200728173716.068CB1D9840C@ary.qy> From: Todd Herr Date: Tue, 28 Jul 2020 16:13:40 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG , atyrsalvia@agari.com Content-Type: multipart/alternative; boundary="000000000000eaf78405ab8613c9" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:13:55 -0000 --000000000000eaf78405ab8613c9 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 1:37 PM John Levine wrote: > In article < > BY5PR13MB29998094418C8A6C25902569D7730@BY5PR13MB2999.namprd13.prod.outlook.com> > you write: > >To put it another way: > > > > * assistant@firstbrand.com is organizing a meeting for > executive@secondbrand.com > > * assistant@firstbrand.com sends out a calendar invite from their > own messaging client, using > >executive@secondbrand.com in the From: field > > * The resulting message uses executive@secondbrand.com in the > friendly From: field, but firstbrand.com in the > >SMTP MAIL FROM domain, so the headers are no longer aligned for SPF. > > * Both firstbrand.com and secondbrand.com are set to DMARC p=reject. > > * Messages like this are then rejected by receivers that validate > DMARC results. > > This sounds like an excellent use case for Dave's > draft-crocker-dmarc-sender proposal. > > The canonical example of different From and Sender is exactly this: > Sender is an assistant working for and sending mail for From. > > > This is also precisely the situation I asked about during the session on Dave's sender proposal. Using the Sender header and the "snd" bits in the DMARC policy for firstbrand.com, DMARC would pass for the Sender domain and fail for the >From domain. Which verdict gets applied to the message? -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000eaf78405ab8613c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 28, 2020 at 1:37 PM John Levi= ne <johnl@taugh.com> wrote:
In article <BY5PR13MB29998094418C8A6C25902569D773= 0@BY5PR13MB2999.namprd13.prod.outlook.com> you write:
>To put it another way:
>
>=C2=A0 *=C2=A0 =C2=A0assistant@firstbrand.com is organizing a meeting for executive@secondbr= and.com
>=C2=A0 *=C2=A0 =C2=A0assistant@firstbrand.com sends out a calendar invite from t= heir own messaging client, using
>executiv= e@secondbrand.com in the From: field
>=C2=A0 *=C2=A0 =C2=A0The resulting message uses executive@secondbrand.com in th= e friendly From: field, but firstbrand.com in the
>SMTP MAIL FROM domain, so the headers are no longer aligned for SPF. >=C2=A0 *=C2=A0 =C2=A0Both firstbrand.com and secondbrand.com are set t= o DMARC p=3Dreject.
>=C2=A0 *=C2=A0 =C2=A0Messages like this are then rejected by receivers = that validate DMARC results.

This sounds like an excellent use case for Dave's draft-crocker-dmarc-s= ender proposal.

The canonical example of different From and Sender is exactly this:
Sender is an assistant working for and sending mail for From.



This is also precisely the situation I as= ked about during the session on Dave's sender proposal.=C2=A0

<= /div>
Using the Sender header and the "snd" bits in the DMARC= policy for firstbrand.com, DMARC wou= ld pass for the Sender domain and fail for the From domain.

<= /div>
Which verdict gets applied to the message?
=
--

Todd Herr | Sr. Technical Program Manager
p: 703.220.4153 <= span>


This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div>
--000000000000eaf78405ab8613c9-- From nobody Tue Jul 28 13:28: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 5E1343A0B5B; Tue, 28 Jul 2020 13:28:16 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPWJLCH1n9Gu; Tue, 28 Jul 2020 13:28:14 -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 18B363A0B5A; Tue, 28 Jul 2020 13:28:11 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SKUiZg018602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 13:30:44 -0700 To: Todd Herr , John Levine Cc: IETF DMARC WG , atyrsalvia@agari.com References: <20200728173716.068CB1D9840C@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <15707aaf-2bb0-8413-f88f-1be432e5e183@dcrocker.net> Date: Tue, 28 Jul 2020 13:28:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D9BB5F38824874CE44E1EBD6" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:28:17 -0000 This is a multi-part message in MIME format. --------------D9BB5F38824874CE44E1EBD6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/28/2020 1:13 PM, Todd Herr wrote: > > On Tue, Jul 28, 2020 at 1:37 PM John Levine > wrote: > > The canonical example of different From and Sender is exactly this: > Sender is an assistant working for and sending mail for From. > > This is also precisely the situation I asked about during the session > on Dave's sender proposal. And it is exactly the reason RFC 733 defined two different header fields. > Using the Sender header and the "snd" bits in the DMARC policy for > firstbrand.com , DMARC would pass for the > Sender domain and fail for the From domain. > > Which verdict gets applied to the message? DMARC is written with the view that receivers will follow the directive in the domain owner's DMARC record, but really the receiver has complete discretion, and many receivers exercise that interpretive freedom. So the answer to your question needs to be: the receiver needs to juggle these bits of information and decide what action to take. It's what they do, anyhow. This isn't something that has a simple, obvious answer that is always correct.  So leave it as a matter of receiver discretion. Especially since that's what it actually is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------D9BB5F38824874CE44E1EBD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/28/2020 1:13 PM, Todd Herr wrote:

On Tue, Jul 28, 2020 at 1:37 PM John Levine <johnl@taugh.com> wrote:
The canonical example of different From and Sender is exactly this:
Sender is an assistant working for and sending mail for From.

This is also precisely the situation I asked about during the session on Dave's sender proposal.

And it is exactly the reason RFC 733 defined two different header fields.


Using the Sender header and the "snd" bits in the DMARC policy for firstbrand.com, DMARC would pass for the Sender domain and fail for the From domain.

Which verdict gets applied to the message?

DMARC is written with the view that receivers will follow the directive in the domain owner's DMARC record, but really the receiver has complete discretion, and many receivers exercise that interpretive freedom. 

So the answer to your question needs to be: the receiver needs to juggle these bits of information and decide what action to take.  It's what they do, anyhow. 

This isn't something that has a simple, obvious answer that is always correct.  So leave it as a matter of receiver discretion.  Especially since that's what it actually is.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------D9BB5F38824874CE44E1EBD6-- From nobody Tue Jul 28 13:30: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 9EC1E3A0B65 for ; Tue, 28 Jul 2020 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ljLHcwfW; dkim=pass (1536-bit key) header.d=taugh.com header.b=SZsSV/Vq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypl-edHsX3dk for ; Tue, 28 Jul 2020 13:30:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF723A0B62 for ; Tue, 28 Jul 2020 13:30:51 -0700 (PDT) Received: (qmail 37491 invoked from network); 28 Jul 2020 20:30:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=9271.5f208af8.k2007; i=johnl-iecc.com@submit.iecc.com; bh=gEJoxBTjJE+eg1oOGv85HYv13Adsx6m+YWs6VT5/Gqg=; b=ljLHcwfW2+6KYIOBxBeulZg9Q5PJBPAjDpKftzyhOkXPYyyjRtcG5d1H3CwFnSizwwPlZF+IIQyxNCt0Bs32gAy0HbNxL7jGvhgLOqcu+ti5SZXVTbEQ+LGy3DOdCZi/JGcgRj5sZXzSLcUjYOnEmBYFG6pU23RYt62CeI3v8kV4+uTrVPBxd30s0Q4/Sisj7CyGDVT4GDAZvDA5g4e91zCsYZSb1iGBdsB3tlReW0rVGQBpSlmz+ILRSTj+jyyJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=9271.5f208af8.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=gEJoxBTjJE+eg1oOGv85HYv13Adsx6m+YWs6VT5/Gqg=; b=SZsSV/VqzOJBBuL4+KYh1yR5vNKQ4qsgRWir/pNaes7G7T605Lds3rNvtzlX6v5N9AhHWtV8/pT+TngCHc086VFckfgg9f/TeQMACjsucR0nbL45XfNCbya1MMWpA09hb7ZKrgTAvvyx4deqRcHFxC+D9kZso5sF6yUmRM6wKJlWNUA2B7H7Y8qqYnRYe0UlPzadXDxP3UIEv0xMO6WoGqz8rXtVGjetVRxYMAkSsUn2oJDPhhFf4xpdVC9PUhsb Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 Jul 2020 20:30:48 -0000 Date: 28 Jul 2020 16:30:47 -0400 Message-ID: <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> From: "John R Levine" To: "Todd Herr" Cc: "IETF DMARC WG" In-Reply-To: References: <20200728173716.068CB1D9840C@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:30:54 -0000 On Tue, 28 Jul 2020, Todd Herr wrote: > Using the Sender header and the "snd" bits in the DMARC policy for > firstbrand.com, DMARC would pass for the Sender domain and fail for the > From domain. > > Which verdict gets applied to the message? I believe the reasoanble answer is both, and the filtering engine evaluates both based on their reputations. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 28 13:58: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 6EB1A3A040F for ; Tue, 28 Jul 2020 13:58:42 -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 dkOlOPyFSKOE for ; Tue, 28 Jul 2020 13:58:40 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 895C03A0407 for ; Tue, 28 Jul 2020 13:58:40 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id l13so3466827qvt.10 for ; Tue, 28 Jul 2020 13:58:40 -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=Oa6mN7NuXlqyOAuljguNVdavYcd4WIBl1ORhB6Z5jYw=; b=UJrp6P9rXGSkLKgabuANGdTsPCoOM/GnOEfBgnAezpbjN8tPuBMeQWaA6C0wmYve8e RqeHNnfGKr0CVwR8bk+i6vD49qXpsI7+s/f/1IP69hK9uHzoNMtoQpljMg3FO43ceaxV 7PfzyDWafclg6DpCkQ71xsRPROwl8DGybaj+IbD+/gTFaQzMWVqqFs8XgJHMwTwe0CK+ v87aRZaMIRswge0fO/1f0ksXH8S7YpA/8mFqd7gQZO7Xb2x2r+dwmxWGNcKSp3aALlnt Cntx8p5x+QudyjVcfVX5zNBJ3EUkYAPohBaxeSz6RakOn3b0sbSuNm4LLIeKCpDurzP6 WLaw== 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=Oa6mN7NuXlqyOAuljguNVdavYcd4WIBl1ORhB6Z5jYw=; b=oDEKAEyDL6CiF3bq1v+X6pO6QINUt2aPAd3UYGFadbYnesjj6S4esy3AbSk6v+gSv6 kRHwY6Ndd9/JTUoyeMkhwlZBnhGyl3qyIgTMC3Qsc2RUsLC+WbN8j6jhlK77T90bLmGm 7L5KYfJorzSU4yXiw+y2UiBVjJuzVvPYaZNaTJW85nU4FVb7QxJKs86c1H0k66lMlyY7 b9aMiLUeEG8N7oBD9JuYLF0C64WFBrF/tXNf9Xa8lq34dUMLMdZUkZ2vKWfs4geX0y1H 1GVQyPXI4tsPXCNrCIax3I1toSx1SSm2oTSS21VEutthvHA3dcFi/eYpsqdKvexG/yLv DWKA== X-Gm-Message-State: AOAM531+3xMN4IKHKd6uVVlrP1emXao2VxdB7OZ3vGBFb5b9TVBYN+oA KGMRzlHBtUCGcwboKauBsIRCvtiPDFT9kZOZTpgU4gJcd+Y= X-Google-Smtp-Source: ABdhPJzbfzwLBui9jAHcaSE1NccQc5LyW0J4onwzViGLkePfyVdvK8zW8U3Qcc4RF/FY8a3dj/o6AP0uc2Ax3RHMStI= X-Received: by 2002:a0c:ab16:: with SMTP id h22mr9481476qvb.72.1595969919517; Tue, 28 Jul 2020 13:58:39 -0700 (PDT) MIME-Version: 1.0 References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> In-Reply-To: <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> From: Todd Herr Date: Tue, 28 Jul 2020 16:58:28 -0400 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000201cc405ab86b4c1" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:58:43 -0000 --000000000000201cc405ab86b4c1 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 4:30 PM John R Levine wrote: > On Tue, 28 Jul 2020, Todd Herr wrote: > > Using the Sender header and the "snd" bits in the DMARC policy for > > firstbrand.com, DMARC would pass for the Sender domain and fail for the > > From domain. > > > > Which verdict gets applied to the message? > > I believe the reasoanble answer is both, and the filtering engine > evaluates both based on their reputations. > > Two responses, two different but equally valid answers, the other (Dave's) being "receiver discretion", which *could* be an umbrella term to include John's answer, but would certainly also include other applications of rules for this scenario. Note that I'm not at all opposed to the idea put forth in https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ but I do believe that there will have to evolve a very limited set of known and expected possibilities for how such messages will be handled, or else wails will be wailed, teeth will be gnashed, and garments will be rent, especially among those trying to do the right thing when sending email and the deliverability people they employ. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000201cc405ab86b4c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 28, 2020 at 4:30 PM John = R Levine <johnl@taugh.com> wro= te:
On Tue, 28 J= ul 2020, Todd Herr wrote:
> Using the Sender header and the "snd" bits in the DMARC poli= cy for
> firstbrand.com, DMARC would pass for the Sender domain and fail for th= e
> From domain.
>
> Which verdict gets applied to the message?

I believe the reasoanble answer is both, and the filtering engine
evaluates both based on their reputations.


Two responses, two different but equal= ly valid answers, the other (Dave's) being "receiver discretion&qu= ot;, which *could* be an umbrella term to include John's answer, but wo= uld certainly also include other applications of rules for this scenario.


-- <= br>

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


This email and all data transmitted with it contains confidential and/= or proprietary information intended solely for the use of individual(s) aut= horized 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 unla= wful. Please immediately notify the sender by replying to this email and th= en delete it from your system.

--000000000000201cc405ab86b4c1-- From nobody Tue Jul 28 14:08: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 4611D3A07E2 for ; Tue, 28 Jul 2020 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 tjnsLUCBOcVR for ; Tue, 28 Jul 2020 14:08:44 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 17F503A07D6 for ; Tue, 28 Jul 2020 14:08:44 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id u24so8940792oiv.7 for ; Tue, 28 Jul 2020 14:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=k1qQv2pipolgMkVPfQ85uVjnoqg08QQ8nfNnFHrCLZU=; b=skVFRfEAojDsDFHKLMq8leJlgQaESVbtlfs0EE1Yri1PUdg/+0JFNf/mXqlpihNId3 ZNBCLjxSLOuWFMBUE/3N/E7n2DrPd88ZNLswvNBl10rFM94o22K3wLl1oYosIjFY/6yD efvNv/DM7mplw9XFyY8jD6A6br544gnWUuhCYpLSgLguOccUAeHHxWHv6MQ6/sVd0+fp INMe5y9SOrLSpe2TLiHTrwNkYj+YEWSRs7Pplvx6e/weNxfAGfy1x6vlW/bbKybNI5ch Wgi8y5G5j6utJYNqcASldN6fnovc2Pa8ktMTrkxyr1DBdc8Rzfch7G0xlcEowpk9Ohse Wc5A== 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=k1qQv2pipolgMkVPfQ85uVjnoqg08QQ8nfNnFHrCLZU=; b=Tzd481kV7KKahhC8C35SnXpEh+paTyFfViF15kbYPCFN88civnZz0Pz3loKVF3esFR 46p0d/3CncmJgVGgjLUKSZkxToh4HdhHuWRHjVJSUQQ1c76qetVU9YAtZO9OHAxAn8/W ZK6ef21AYpZmFpR1daN/nzmYn/jr28UzDPZT05hCgmNO0TIY7ZxwmSeRGYctfuZdFYM/ UzXZW4T8YRQm38Z8Us8//vg3ZhteI+IaoLwOMWY3G5180VnuyZV0QDkVnGAW2O5u0+vR KnoYuo0KltkcrKsOfRbBk6f9E1Iy72uybRxryxGBta4hTfSZz79zbPSltATTJpfFYjpg /KaQ== X-Gm-Message-State: AOAM531lF3ab5RXeR+zEnHxzZEtwDpdgAQNPCoDfcWFHnN4bmvDU6equ vYCUssZJLJMYyxSY8a7OlSxkN+CvXOU= X-Google-Smtp-Source: ABdhPJxsYlNSuW1SK9LK09x5iPdiFnwC7RmnVYQUXjXH1j21vpACgBgzRf9f9A/Ao2Y4CZvYxP/rFg== X-Received: by 2002:aca:2313:: with SMTP id e19mr5108412oie.67.1595970523319; Tue, 28 Jul 2020 14:08:43 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:cd4f:32f9:55f5:1a99? ([2600:1700:a3a0:4c80:cd4f:32f9:55f5:1a99]) by smtp.gmail.com with ESMTPSA id l68sm1395oig.51.2020.07.28.14.08.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 14:08:42 -0700 (PDT) To: Todd Herr , John R Levine Cc: IETF DMARC WG References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> From: Dave Crocker Message-ID: <545dc868-948f-392a-2f2e-2d3bd79c4d9a@gmail.com> Date: Tue, 28 Jul 2020 14:08:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:08:45 -0000 On 7/28/2020 1:58 PM, Todd Herr wrote: > but I do believe that there will have to evolve a very limited set of > known and expected possibilities for how such messages will be > handled, or else wails will be wailed, teeth will be gnashed, and > garments will be rent, especially among those trying to do the right > thing when sending email and the deliverability people they employ. Here is another case of two different answers: 1. What is done with a validated DKIM signature?  The answer is essentially:  lots of different things that are not specified in any standards document but that receivers find useful.  That's the same, benign answer that should be applied here. 2. There are always wails wailed, teeth gnashed, and garments rent (or purchased).  Worrying about that isn't ever helpful.  So don't. d/ ps. I thought my previous answer and John's were essentially the same, but am fine having his treated as a subordinate case of mine.  And that's a view I'm fine having be applicable pretty much any time. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 14:11:17 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 7D39C3A07EC for ; Tue, 28 Jul 2020 14:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.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 vRcrkhvSyoQ0 for ; Tue, 28 Jul 2020 14:11:13 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::726]) (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 B96223A07D6 for ; Tue, 28 Jul 2020 14:11:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n9KQmPbQJ6+9o5vsKsl3YFbajxH7o5RLSTWNhyIolEtdY8Irjw41V1LoS0V7oD7Jp3srV3Mt8wXYBF5QkzD8cjfHaWLZEav7ajkxT9wsc3tTjEg+zIN61ryfitWImnixMTNvGHlzE3Sukf9py47Ki8gWuUhNZT1AjYjP1Havc5VLyB3zhcAGCoYLZF7f+ouTX7ENCxYkpg2W8bumj5cb3+CM8WF1F846V5p7oTRwxMyLrS8+JwEWgonjEyW9ZiFdTvB8IrFM4nZo02s2bgAG2jpICBsJZaXcnhXr0217zDWKh2s16wrk8h8Kq+JXcljKWOQP8mqzR1Bv31KmEK1vuw== 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=K2Qqsuq+TSLuLZxFC/NarxXaeaoFynRr3b1PBOU+oYg=; b=VwQXZ/mtm/Tp1E/QRPStlS2S40H6G/698+S3wJ/W/ArD7TDKbGBHdmOqEixU/v4C8YYworWCuV+CqwE4jCQu7pVYOCZyfiaeWTY3LP2he0S5qxFrwQ5itZmdH1yT/M1rt1ZGHsSzaVwzoc9sMYp6aSDq+k+Ae8zcCtbVROUYdkFJFtC1Owu3tgtg1c89QqOmSqpHyUeFxCtxiTLzX7YccfPCb/Cwj6n2zOxtzQY3PKw1+7tLrT51q29f2+ozyh0F+zzE9bIWfMmFZQkeAtmzbg5U6fmMKH8XrCBurc7ZmBgPdUtsFzfCA/roymEJGjpoRLbVchO8j9irAyXXEsxN5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=agari.com; dmarc=pass action=none header.from=agari.com; dkim=pass header.d=agari.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K2Qqsuq+TSLuLZxFC/NarxXaeaoFynRr3b1PBOU+oYg=; b=RHiD3OKlr3pCwDrHD2p5wfRoWWkTB7ksxDJNJksDNwTVFJ1vWidF1/rXMc6i0GQGxcUibGcOctWq+T4EBfU4yCAN4NnWTB1M5AT6hVc01EZ8gOGR++ohITP9g9sNgSLHQY65YvWR3IdDmJo0cNzHuH16H+KCHR3LLKHNxkVUKx8= Received: from BY5PR13MB2999.namprd13.prod.outlook.com (2603:10b6:a03:191::27) by BY5PR13MB3777.namprd13.prod.outlook.com (2603:10b6:a03:219::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.13; Tue, 28 Jul 2020 21:11:12 +0000 Received: from BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f]) by BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f%3]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 21:11:12 +0000 From: Autumn Tyr-Salvia To: Todd Herr , John R Levine CC: IETF DMARC WG Thread-Topic: [dmarc-ietf] non-mailing list use case for differing header domains Thread-Index: AQHWZKh8JcOQ838b0UOee1lvwkySbakdQicAgAArsgCAAATJgIAAB7wAgAAC0js= Date: Tue, 28 Jul 2020 21:11:12 +0000 Message-ID: References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=agari.com; x-originating-ip: [108.69.133.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72c9c2b9-979e-40a2-a887-08d8333ac1ab x-ms-traffictypediagnostic: BY5PR13MB3777: 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: SnwFJxBplexZH+8bXtxfNsLtQ+HLWIlcaKPyhKmJTd49zYSI7LpMslxMaRhyziX/ZEO3duBZ2sB4PAi3GIae9yex5jPStyjz1/irmMMImRh2RbHRwlni/gOK+M0CDQED4QEBfedH0QDjnour+WyhzRSY2Nz9oRJj71hJt4d/Bt6PKL5G/EYYAfdx4lni6KVuKianPjtSwLQGJnikOJYO8uQyM1qLoiwnhv9iYdFN9QG6JS3CtylEgrJgVhS1990vfPyDgEcPzWYbuce24gXu4TJGuQFh9yFLZwKV4YobQ01YDuPqZbcVwLQ3VwS/KK8YyEXxCVlcAXPW24+tmOzeEM9IvwXYkuA0G9t44PrupEJzT8Tgu61QAjLC0H4hhEvkPNcgVTTt1nB9iNEO0LG3qdjdcHdcDc1Y2J4doApkOlUy9nxOLDJ1lpPhT4hw9bpu66cnx28g0OULTqOpfV0s7M4QOjNLVg0jyegiotGoP7s= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB2999.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(136003)(396003)(376002)(346002)(366004)(2906002)(52536014)(55016002)(8676002)(66946007)(66476007)(66446008)(66556008)(19627405001)(76116006)(71200400001)(64756008)(53546011)(6506007)(7696005)(316002)(966005)(9686003)(110136005)(508600001)(5660300002)(26005)(8936002)(86362001)(33656002)(186003)(166002)(83380400001)(4326008)(223123001)(130980200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ciNZvTBzm2rR4y+Cvd9n5dc10o0x17uoZiyDZyuCZPNmjPc8g4xsxPitd7kspWU58LhPcOZFFXcmB8On5Fp+9FY3caInpUYXC8Qeo5cKe5yiEoh3NOBC5SxUrwk7aNeRNqjGfPTi8ULaTwFIrYbM1CU5L0OgIP5qtKi6GuB1AfaTle8HLwHep/DVwh3s2ds87Ovf7TqVb6QqLBfIn5STLI0iaxcSfsIGVO7JLL1AN6OfSmiqyvYnU6FKtJ+GB6FzhpDdkMS38kCH0aIRQFlnUTZSYY3qoKYJ35qgkj9t6lwjHOpdhxH6Ct3Z+xtzrGSQSZNFuIwUZBG+HTpNP3h1NKif0MdwEffZA6cNtGCkVeKRYLHhdz4LmXcO7mmRgzmpGIN5hH8ucnLfNS3Q5Qj3z6frV61C1gRll2fOOTnnGvao/OgFIz/hKKQWMjbHndDs9/2j69jVmO/tGB0Tu2wzLn9lCr2iaQoIKBkRP7L3lNlsbKLMiowZl6bOVlXuo66nZRi/jMin25aSCakfZU6vHLBIMBqpGzVPrK2V/crqp74zYs5HjUzJx3AHwjvNaK/dlPYzQUKeAM0Y+jukfv2pTIT6ZsgXs9t2UjKFRajJVu/ZHqxxA3Haf9ZKTLFFzyB6b62X8jGs33SL1zBQBuQDJg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB29993AD874B3A34BA088D87BD7730BY5PR13MB2999namp_" MIME-Version: 1.0 X-OriginatorOrg: agari.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB2999.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72c9c2b9-979e-40a2-a887-08d8333ac1ab X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 21:11:12.1758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05773123-385e-420d-844e-f01aee5e37ab X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UKfYYvwrGFtUH+9N5edu2klKHVjdIby5Y8319KC6LiUkDxR0hi58iYGAGaJjDGs5p/k/DwnIig1D11wOHn/agQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3777 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:11:16 -0000 --_000_BY5PR13MB29993AD874B3A34BA088D87BD7730BY5PR13MB2999namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To Todd's point, I think the answer on which policy would be applied at lea= st needs to be predictable. If one receiver chooses one policy and a differ= ent receiver chooses the other policy, that is going to make it significant= ly more complicated for complex organizations to implement a DMARC p=3Dreje= ct or even p=3Dquarantine policy. Thanks, Autumn Tyr-Salvia atyrsalvia@agari.com Agari Principal Customer Success Engineer ________________________________ From: dmarc on behalf of Todd Herr Sent: Tuesday, July 28, 2020 1:58 PM To: John R Levine Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On Tue, Jul 28, 2020 at 4:30 PM John R Levine > wrote: On Tue, 28 Jul 2020, Todd Herr wrote: > Using the Sender header and the "snd" bits in the DMARC policy for > firstbrand.com, DMARC would pass for the Sender domain and fail for the > From domain. > > Which verdict gets applied to the message? I believe the reasoanble answer is both, and the filtering engine evaluates both based on their reputations. Two responses, two different but equally valid answers, the other (Dave's) = being "receiver discretion", which *could* be an umbrella term to include J= ohn's answer, but would certainly also include other applications of rules = for this scenario. Note that I'm not at all opposed to the idea put forth in https://datatrack= er.ietf.org/doc/draft-crocker-dmarc-sender/ but I do believe that there will have to evolve a very limited set = of known and expected possibilities for how such messages will be handled, = or else wails will be wailed, teeth will be gnashed, and garments will be r= ent, especially among those trying to do the right thing when sending email= and the deliverability people they employ. -- Todd Herr | Sr. Technical Program Manager e: todd.herr@valimail.com p: 703.220.4153 [https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS= 0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT= 2x5EcZV3rjz19-Dx9rESL] This email and all data transmitted with it contains confidential and/or pr= oprietary information intended solely for the use of individual(s) authoriz= ed to receive it. If you are not an intended and authorized recipient you a= re hereby notified of any use, disclosure, copying or distribution of the i= nformation included in this transmission is prohibited and may be unlawful.= Please immediately notify the sender by replying to this email and then de= lete it from your system. --_000_BY5PR13MB29993AD874B3A34BA088D87BD7730BY5PR13MB2999namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To Todd's point, I think the answer on which policy would be applied at lea= st needs to be predictable. If one receiver chooses one policy and a differ= ent receiver chooses the other policy, that is going to make it significant= ly more complicated for complex organizations to implement a DMARC p=3Dreject or even p=3Dquarantine polic= y. 


Thanks,

Autumn Tyr-Salvia
atyrsalvia@agari.com
Agari Principal Customer Success Engineer


From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Todd Herr <todd.herr=3D40valimail.com@dmarc= .ietf.org>
Sent: Tuesday, July 28, 2020 1:58 PM
To: John R Levine <johnl@taugh.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing he= ader domains
 


On Tue, Jul 28, 2020 at 4:30 PM Joh= n R Levine <johnl@taugh.com> w= rote:
On Tue, 28 Jul 2020, Todd Herr wrote:
> Using the Sender header and the "snd" bits in the DMARC poli= cy for
> firstbrand.com, DMARC would pass for the Sender domain and fail for the=
> From domain.
>
> Which verdict gets applied to the message?

I believe the reasoanble answer is both, and the filtering engine
evaluates both based on their reputations.


Two responses, two different but equally valid answers, the other (Dav= e's) being "receiver discretion", which *could* be an umbrella te= rm to include John's answer, but would certainly also include other applica= tions of rules for this scenario.

Note that I'm not at all opposed to the idea put forth in https://datatracker.ietf.org/doc/draft-crocker-dmarc-sende= r/ but I do believe that there will have to evolve a very limited set of known an= d expected possibilities for how such messages will be handled, or else wai= ls will be wailed, teeth will be gnashed, and garments will be rent, especi= ally among those trying to do the right thing when sending email and the deliverability people they employ.<= /div>

--

Todd Herr | Sr. Technical Program Manager
p: 703.220.4153


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

--_000_BY5PR13MB29993AD874B3A34BA088D87BD7730BY5PR13MB2999namp_-- From nobody Tue Jul 28 14:15: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 4B1143A0824 for ; Tue, 28 Jul 2020 14:15:37 -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 SsfMbxVXjBIA for ; Tue, 28 Jul 2020 14:15:35 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 7D03E3A0808 for ; Tue, 28 Jul 2020 14:15:35 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id l23so20242237qkk.0 for ; Tue, 28 Jul 2020 14:15:35 -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=HPtMlFOtjUnfF8HuUkTct8Gfb3qJk4frg+DiZOg6aXY=; b=cWWAw+dmq4lUkinnhK7z7zRPxyWg34N1KfzHkxM3fGBa5zegJVclr/sQl+hll5T1/t temM+vktB8cUeFjaUu57n3S67dA7/XNBJPHMra7Eu0CHN3ZyXhY4Ikej6eRdy/JH01vP IIXjoTsCqEBa9MHWTZ2qg2yjvW8DL5KN+enr2n+v/tUGA5YkrSMGe7LG0OZlGS4IVHMw 0XF+NF0dlDMS7f7+ySCSGiwEUA/5oYvcs0WA0TiL9/ivf6ZT1zwgcHFE/+ygwIDU8zhz 60ib6ZZf2Ka6R/u7Vf2Ik5HeJjlvYfp8vYikU5U64lEv3o+4K+jxKdkQdZrntNmf/4wH g+Tg== 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=HPtMlFOtjUnfF8HuUkTct8Gfb3qJk4frg+DiZOg6aXY=; b=unUf3U7aJZ0gz4E580QD3lTLVcW9qLotW2r8VyPUmFSs0Ft646S4FwsHBkST+x+rZ6 JgLvpOC+CV9ny78w2kBjADtj79uNZ79YrUBVNcxfUk6uAV9q2KJ0jSnMbG/cTRMy9F2F PtK+Sea5mUwGKLTCZiGz7AmHu5s85MW4d7x/cBX2HCrg+vl6i5Jt8Ms2xY29Js5jtVTA b0iMYncPc1YIDC+dEk9ibtLA3bAt7EsQGk4vLTsr1QhICHF8vTopVBz1xeSsfbpz9o8S rHhy1WLYjPogAWTzsB8A7Uefb6H3VvrV9KmZbp84+5u0TRdhfEw8f0bWaC9rNWFZFkh0 v7gw== X-Gm-Message-State: AOAM533wKZ8Q/Y2bbLm57adGykSookh7FEvXmjmyIcZ4pcIiRjWY1FZM KHZQ8yuCWduCXqc0qAxDoemOynuuomlRnALgErVKl6lO X-Google-Smtp-Source: ABdhPJzCkRaLRTxrWIavlsW2z4WENEqbFmvE3Qb5FzC4tEby04IxSvb+Q0fr1kIHjQcbEvz+NnPThs63VEA/QzrGBVU= X-Received: by 2002:a05:620a:230:: with SMTP id u16mr28022644qkm.387.1595970934576; Tue, 28 Jul 2020 14:15:34 -0700 (PDT) MIME-Version: 1.0 References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> In-Reply-To: From: Todd Herr Date: Tue, 28 Jul 2020 17:15:23 -0400 Message-ID: To: Autumn Tyr-Salvia Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a0b94a05ab86f0e7" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:15:37 -0000 --000000000000a0b94a05ab86f0e7 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 5:11 PM Autumn Tyr-Salvia wrote: > To Todd's point, I think the answer on which policy would be applied at > least needs to be predictable. If one receiver chooses one policy and a > different receiver chooses the other policy, that is going to make it > significantly more complicated for complex organizations to implement a > DMARC p=reject or even p=quarantine policy. > > Yes, yes it very much will. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a0b94a05ab86f0e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 28, 2020 at 5:11 PM Autumn Ty= r-Salvia <atyrsalvia=3D40a= gari.com@dmarc.ietf.org> wrote:
To Todd's point, I think the answer on which policy would be applied at= least needs to be predictable. If one receiver chooses one policy and a di= fferent receiver chooses the other policy, that is going to make it signifi= cantly more complicated for complex organizations to implement a DMARC p=3Dreject or even p=3Dquarantine polic= y.=C2=A0


Yes, ye= s it very much will.

--

Todd Herr | Sr. Technical Progra= m Manager
p: 703.220.4153


=

This email and all d= ata transmitted with it contains confidential and/or proprietary informatio= n 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 o= f 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 sy= stem.

--000000000000a0b94a05ab86f0e7-- From nobody Tue Jul 28 14:16:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404A3A0824; Tue, 28 Jul 2020 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgqOq3p_easR; Tue, 28 Jul 2020 14:16:20 -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 02B593A0808; Tue, 28 Jul 2020 14:16:19 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SLIthB024241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 14:18:55 -0700 To: Autumn Tyr-Salvia , Todd Herr , John R Levine Cc: IETF DMARC WG References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <69e3de6c-6e71-9399-eda9-63c92e7bf672@dcrocker.net> Date: Tue, 28 Jul 2020 14:16:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:16:21 -0000 On 7/28/2020 2:11 PM, Autumn Tyr-Salvia wrote: > To Todd's point, I think the answer on which policy would be applied > at least needs to be predictable. If one receiver chooses one policy > and a different receiver chooses the other policy, that is going to > make it significantly more complicated for complex organizations to > implement a DMARC p=reject or even p=quarantine policy. I'll suggest that this needs to be less a normative specification and more a best practices write-up. First, as I've noted, receivers will do whatever they want. Second is that I believe we don't yet know the better answers. (And so, really, I don't mean a BCP, but rather a 'considerations' doc.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 28 14:23: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 5AA4D3A088A for ; Tue, 28 Jul 2020 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=br8ZMfx7; dkim=pass (1536-bit key) header.d=taugh.com header.b=LrLcQeiZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdGO34mbZ-zf for ; Tue, 28 Jul 2020 14:23:26 -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 8A84F3A0883 for ; Tue, 28 Jul 2020 14:23:26 -0700 (PDT) Received: (qmail 51251 invoked from network); 28 Jul 2020 21:23:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=c830.5f20974d.k2007; i=johnl-iecc.com@submit.iecc.com; bh=0X/7KJNcZ/kDiegPJkeuoV/6jfQo98VfDSwa7VD5r4s=; b=br8ZMfx7kBIssBQzWHRKL8VV+ETGUelz/pXgLjxLVhg97oCtCCqUaObfqTlqBWi27SQOaO+cRV2p8zJ9JmYK0MWivejLfxN5VT/dUx4S+iSg5tWfqI5Ii0yQ70cIEl5yM5OwzuZjTXqlge/yMuhhrQj11iHD1dJJofyoFrup0md6vSjFpY5rTo0gZaPV390svURZ8QyQRrAioAywMVJ3gyC8oal7wrHiv/C5ZKMCcvAIKDBe2Uf/nPf4hx18JPta DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=c830.5f20974d.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=0X/7KJNcZ/kDiegPJkeuoV/6jfQo98VfDSwa7VD5r4s=; b=LrLcQeiZJn4xARo1iVYqOFCG/8tz34ZOZCdFs+GuQUn7qPTm7PSEHyuLezc31sl2FSGO6TZIoltIQ04HmRJinR+g0vHLYtnhE4pnSGyRvKR4LMnxXNzDdUa/EwsL+2Y7wDt1h6NzSF344D6OTGJ+XgoSALiTxSWtj5u4l5uGAE4L+auOUMvs2wb3Nhyp1CrUbygKvcdh90tolo9yxFEVNeX+GWJwoYllfQZmFfFrD/ZA4kpA9CoKQyfDlxFYZiWA Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 Jul 2020 21:23:24 -0000 Date: 28 Jul 2020 17:23:24 -0400 Message-ID: From: "John R Levine" To: "Autumn Tyr-Salvia" Cc: "IETF DMARC WG" In-Reply-To: References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com>, MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:23:29 -0000 > To Todd's point, I think the answer on which policy would be applied at > least needs to be predictable. If one receiver chooses one policy and a > different receiver chooses the other policy, that is going to make it > significantly more complicated for complex organizations to implement a > DMARC p=reject or even p=quarantine policy. But it's not predictable now. Some receivers follow p=reject all the time, some follow it sometimes, some follow it never (me.) I think that in practice the situations where someone else is going to resign your mail with a Sender DMARC policy are narrow enough that most IT departments wouldn't even notice. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 28 15:55:14 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 C4CBD3A0A35 for ; Tue, 28 Jul 2020 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ufSO9mM+; dkim=pass (1536-bit key) header.d=taugh.com header.b=bjW6GoAy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFu1mnfOwBbJ for ; Tue, 28 Jul 2020 15:55:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6233B3A0A12 for ; Tue, 28 Jul 2020 15:54:49 -0700 (PDT) Received: (qmail 75764 invoked from network); 28 Jul 2020 22:54:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=127f2.5f20acb7.k2007; i=johnl-iecc.com@submit.iecc.com; bh=TuBD+RFDz8yV0plY3R7xvjTfOxfha++Ql8uZMgMgKvs=; b=ufSO9mM+N0PjmEFgF7FsI++UfAFwsPt72SppXURPkFRQZRM4YVeVlnLQlMwoCQHLuE1yDczk4hK4LkZh5Dj6Bb8pc5EFriI0splXnE+j8wtQLoI+SNy8y0USmXDPql1B26BmEbUxo01HLVsjpYmxzhUPShPW5arDV/ihlomPnEDxegCOXwGSbdIA0hpGAA91FI0+o86xP9xGWoD6+et5rpZkbj1ZqQG9Z+hzveDoTSNbCWFuJMV9T0PrD/O7wqMD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=127f2.5f20acb7.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=TuBD+RFDz8yV0plY3R7xvjTfOxfha++Ql8uZMgMgKvs=; b=bjW6GoAyiHVYX9OQMv2opXFgHt1ii6oCWTDuCgmkqahbPAyOxffhNOFyWjkX8LE4jqkXuyDh7ass+OMMcu7SPcvXEAzxt8uH7iI+64q8AM42lsMkO7d54eGrpQqhwWGKG3BDh/X7mM94TxjX7Ko45jswCQQfZwpQdcrLRxp1JnjxN/1A4yCbhiXzkud+TwyMTjxjxO847mWfIRVm28JJog0cQDATk+TCpUBCkGMzZ64NR2hucrBv1kwqXQiqzjnn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 Jul 2020 22:54:47 -0000 Date: 28 Jul 2020 18:54:46 -0400 Message-ID: From: "John R Levine" To: "Todd Herr" , "John R Levine" Cc: "IETF DMARC WG" In-Reply-To: References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 22:55:13 -0000 >>> Which verdict gets applied to the message? >> >> I believe the reasoanble answer is both, and the filtering engine >> evaluates both based on their reputations. >> > Two responses, two different but equally valid answers, the other (Dave's) > being "receiver discretion", which *could* be an umbrella term to include > John's answer, but would certainly also include other applications of rules > for this scenario. I think Dave and I are agreeing here. Assume I mean reputation in a very broad sense. > will be wailed, teeth will be gnashed, and garments will be rent, > especially among those trying to do the right thing when sending email and > the deliverability people they employ. I said to Autumn, I expect the number of people sending mail with Sender DMARC will be so small that the deliverability people won't notice. And, of course, receivers will continue to do as they d* please, same as we've done for 40 years. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 28 16:41: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 221563A0B91 for ; Tue, 28 Jul 2020 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Xeho5ZMq; dkim=pass (1536-bit key) header.d=taugh.com header.b=Iq3mMh3c Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYBNMStT3SSp for ; Tue, 28 Jul 2020 16:41:48 -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 24EF83A0B8F for ; Tue, 28 Jul 2020 16:41:47 -0700 (PDT) Received: (qmail 90451 invoked from network); 28 Jul 2020 23:41:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=16150.5f20b7ba.k2007; i=johnl-iecc.com@submit.iecc.com; bh=2wcn6PeXtt+QIlE3ihcCwGHctnX1ErNVktc64zOlWko=; b=Xeho5ZMqoJdPo5+0OUS6s/ayXH2KgqaszRIA1xcNhnE3mMcdzasWpTGOfOE2F2xuHVyroeGP3cp8Mv4HXFF5GmXdLGYDMs7zysv36p3iOJbK4MJS03Z+nY60AUsIYO+v+gv2RUSblvHAefwvHYCSnT2Hu/TV6hrWwBh3gbev8kKjmxV3q9mjs5MMkDanKBIqiGgdVgo3vtTP5mDyI/BkMBO4Ar/OzEjM5t1+rGYiebfssQ1Raj6UWlgwBRnLWjOJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=16150.5f20b7ba.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=2wcn6PeXtt+QIlE3ihcCwGHctnX1ErNVktc64zOlWko=; b=Iq3mMh3c9X56ZsIeM49F1MtHMMfJQvLGekY3Sjlq3wCgdN9t2sPW6dl8wKW7ZCmXQ68ZQ6V+4EhJFyVo7E/Yi0lfhA/PDTQSRJebKThSLcam42h0aa4ewHiDUkMJWsMCMhUIhQprk8PVkLRnh5IGY+2oiLk76mjY9YuzL8mMmlkUH3YJ0PpUX12+7vufaMpzpj8jqc6ao9HZHeNoT3p5edKYg9svDNUXk813ipz4ZEoycCZEqPg/yZ9JRq6NSNfg Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 Jul 2020 23:41:45 -0000 Date: 28 Jul 2020 19:41:45 -0400 Message-ID: <32bc14d3-81b8-4b49-8fb2-597eba19d1be@taugh.com> From: "John R Levine" To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dmarc-ietf] Apropos of the de-munging 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: Tue, 28 Jul 2020 23:41:50 -0000 [ sent last week but got stuck due to a laptop upgrade which helpfully reset all my mail settings to the defaults ] >I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. >In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary >receiver will trust their non-munged mail. Giving the receivers a way to un-munge (if they >can and/or want and/or trust) would be a productive path forward out of this situation. We already have a couple of ways to do reversible message munging, starting with MIME message wrapping. In principle it works fine, in practice it's awful because MUAs don't show wrapped messages consistently and often in ways that are painful, e.g., you can see the original author address but there's no button you can push to respond to it. Unwrapping a MIME attachment is a lot easier than the proposed DKIM unmunging but I doubt either is going to show up in MUAs any time soon. Perhaps you could do it in a mail gateway. R's, John From nobody Wed Jul 29 01:44: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 E4A5C3A10D9 for ; Wed, 29 Jul 2020 01:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VRFvirIQHnGw for ; Wed, 29 Jul 2020 01:44:05 -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 09E6C3A10D8 for ; Wed, 29 Jul 2020 01:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596012241; bh=XL4mJkUVRK8URXKbfaia/WIYwqzCyrig8qGmrTXy6vM=; l=3618; h=To:References:From:Date:In-Reply-To; b=AJjzOW5O0M4NsZYSJXAoINQGgIUYrOElLpecFf9PHLCShsfx0CxpbmY6k766sCeH1 exhkFZlXFnpg5NN00A+sU3N6gjCQEORbSnLJMutUpVR0ryS5AjQNSuH+I9QgbsI1Uk PLASfMqqsea6PU16QDoXMQ0lgqYRXPdbN09+Y+8GJomHecKOepTsj+DPrVKUm 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 00000000005DC056.000000005F2136D1.00002AD6; Wed, 29 Jul 2020 10:44:01 +0200 To: dcrocker@bbiw.net, dmarc@ietf.org References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it> <6dc2bf95-6f0b-13d5-49cb-1ab0b9a6a37c@dcrocker.net> From: Alessandro Vesely Message-ID: <02a61a75-2713-aa29-2741-eefdaaf6d756@tana.it> Date: Wed, 29 Jul 2020 10:44:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6dc2bf95-6f0b-13d5-49cb-1ab0b9a6a37c@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:44:07 -0000 On Tue 28/Jul/2020 19:08:25 +0200 Dave Crocker wrote: > On 7/28/2020 7:20 AM, Alessandro Vesely wrote: >> On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote: >>> On 7/28/2020 4:00 AM, Alessandro Vesely wrote: >>>> On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote: >>>>> On 7/28/2020 12:26 AM, Alessandro Vesely wrote: >>>>>> Receivers can evaluate the Author: domain just like they would do if it >>>>>> were the From: domain. >>>>> >>>>> So you want to define DMARC as applying to both the From: field and the >>>>> Author: field?  That will defeat the benefit intended for the Author: field. >>>> >>>> Yes.  In case of conflict, evaluation of Author: has to be omitted. For >>>> example, Author: fields containing multiple mailboxes are not considered. >>> >>> 1. I don't understand the details you have in mind that would make this useful. >> >> >> It is an optional evaluation.  It's easy to do, if you already verified DKIM >> and SPF.  It is not terribly useful, admittedly, except that having two or >> three "pass" makes for a stronger authentication than just the From:.  The >> chief reason for evaluating it is to give feedback to the MLM. > > There is no specification for doing this.  It means that there is no basis for > the creator of the Author field to expect such an interpretation and no basis > for a receiver to apply it and expect it to be valid. It'd be enough to state that the "scrutiny and care comparable to that given to the From: header field" include evaluating the domain —if unique— against validated identifiers. > An interoperability standard require a shared definition of action and > meaning.  The sharing is among the actors participating in that standard. > > For one side to choose a behavior or an interpretation that is not documented > and shared by the other participants is to pretend that a heuristic is more > than that. If the aggregate report format (see below) includes provisions for transmitting the result of those evaluations, the circle is closed. >> >>> 2. Again, this seems to defeat the purpose of having the Author field. >> >> >> Why? > > The field is intended to be free of the problematic treatment the From: field > is now getting.  You appear to want to encumber it, so that it experiences > those same problems. One of the DMARC specs might suggest what dispositions make sense according to the evaluations and the various DMARC records found. A "fail" result on the Author: domain should not compromise delivery (unless the domain is the same as the one in From:.) I understand that asking to perform an evaluation for the sole purpose of transmitting the result may sound presumptuous. However, it's not gonna be the only change affecting DMARC software, and it is an easy one to code and a lightweight one to run, and, if the Author: domain is significant, its results can be interesting for the receiver as well as for the sender. >>>>>> As a new field, Author: doesn't wear a reliable-id trophy, hence >>>>>> receivers may refrain to apply policy dispositions.  However, the result >>>>>> of the evaluation, conveyed through aggregate report, can tell MLMs if >>>>>> rewriting From: was necessary. >>>>> >>>>> How, exactly? >>>> >>>> Author: and Sender: domains can be included in aggregate reports along with >>>> the From: one.  The policy_evaluated can also include more items, >>>> specifying which evaluations pass or fail. > > Yes, one could modify DMARC to have its reporting include additional information. Best Ale -- From nobody Wed Jul 29 01:46: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 001813A10E0 for ; Wed, 29 Jul 2020 01:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 eXOdw46w_qAG for ; Wed, 29 Jul 2020 01:46:45 -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 4A5323A111D for ; Wed, 29 Jul 2020 01:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596012342; bh=26dl4Z3A9VCu+fNO+bDRUXssX9GBE+xqwjuCHnthYVs=; l=824; h=To:References:From:Date:In-Reply-To; b=BYEWkr2orNw/dTaojRJsdGxSDzH3MyXzFIlY2V9Vd3Q/LQNlCx57Z3dKKR+geaCjS cQqWprLh2yYmMk6wOckwZclS6pIr2sZ0YEg3f1udtllbfduCZmDV6ejC2DyPwyweuT 2hC61/iZueyWcXpW2rMxzuNSO7DZAArvDo6DgSf4a0h/Jjwo6PZZZYExD+grA 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 00000000005DC056.000000005F213736.00002B36; Wed, 29 Jul 2020 10:45:42 +0200 To: John Levine , dmarc@ietf.org References: <20200728174134.72B2A1D98455@ary.qy> From: Alessandro Vesely Message-ID: <6e17ad92-f7ec-49ca-5bb8-2b9a1c4b4582@tana.it> Date: Wed, 29 Jul 2020 10:45:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200728174134.72B2A1D98455@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:46:47 -0000 On Tue 28/Jul/2020 19:41:34 +0200 John Levine wrote: > In article you write: >> In the pre-DMARC era, we've been mainly using just From:. Sender: is used by >> Outlook to display "on behalf of" catchphrase, presumably in an attempt to >> support the historic Sender-Id protocol. > > Sorry, no. That is completely wrong. The Sender field has been part of > e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along > until the 2000s. Outlook's annoying "on behalf of" at least matches the > intention of the Sender field. You're right. Outlook was using "on behalf of" even before Marid.[*] So perhaps Sender-ID derived from that usage, rather than the other way around. Best Ale -- [*] https://bugzilla.mozilla.org/show_bug.cgi?id=221054 From nobody Wed Jul 29 01:49: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 6FC303A0C38 for ; Wed, 29 Jul 2020 01:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gAqczrafLY7l for ; Wed, 29 Jul 2020 01:49:53 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EF03A0A3F for ; Wed, 29 Jul 2020 01:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596012591; bh=GpViQP27ievK4MKltSJKt2d6gWc2r7xmp/GStjGDLCc=; l=1028; h=To:References:From:Date:In-Reply-To; b=B/pcZxEYvzYGDprAqL/OhPhtjHjN7ALcsUP+vsyukdzNQSVSBPbNJzJSvJGjl+QHu kbNKggaM283e7YGmGLYYgNglOB1fllnSJ8Xv2YLHEqmHyWld8nyREdQDHIonU/2B7L EibrLEai0bOv6Z4cS5KS3ntoK3a5HLHDuKHgUHkxQS9WWBUhKIZuYwQRc3tu2 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 00000000005DC056.000000005F21382E.00002B9C; Wed, 29 Jul 2020 10:49:50 +0200 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> From: Alessandro Vesely Message-ID: <99275d09-dbdf-1167-11c6-8a42a09789b0@tana.it> Date: Wed, 29 Jul 2020 10:49:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:49:56 -0000 On Tue 28/Jul/2020 19:19:50 +0200 Doug Foster wrote: > Hector, I do not understand this comment: > >> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma." > > Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key. But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer. It is difficult, even for smallish domains, to get a complete list of MLMs which legitimately distribute messages From: their users. > The goal of this discussion is to find a way to coerce trust. We do not lack ways to grant trust on request. Right, a possible approach is to outsource trust. If you lookup my SPF record[*] you can see an example. Best Ale -- [*] "v=spf1 +ip4:62.94.243.226 ?exists:%{ir}.list.dnswl.org -all" From nobody Wed Jul 29 01:54: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 263063A0C3F for ; Wed, 29 Jul 2020 01:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 V81GbuWRSWc9 for ; Wed, 29 Jul 2020 01:54:08 -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 9A55F3A0836 for ; Wed, 29 Jul 2020 01:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596012846; bh=pxh0gPhdEigKzZizueSAIhX+v4LPqnggmmXsDyhlX+Y=; l=1518; h=To:References:From:Date:In-Reply-To; b=BSXo6cbb6WrYdfQBgUAnhd77RJxxolNZHXdZHXH2gWMKaowiWeXDmvpaEEcGeiDY0 VpBHUr0Mgj844ThoXfi0pVcUK3Vav38Ati1InqaAK6F11IloGzVzJVKh40twxsWdKY 8jgfYFgxxHxK+0YcKdzJrF6GCBbB2uqKgzHMcnWu/vL2xnrXTM+ucRH1LTGL8 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.000000005F21392E.00002C82; Wed, 29 Jul 2020 10:54:06 +0200 To: dmarc@ietf.org References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> From: Alessandro Vesely Message-ID: Date: Wed, 29 Jul 2020 10:54:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:54:10 -0000 On Tue 28/Jul/2020 23:23:24 +0200 John R Levine wrote, quoting Autumn: >> To Todd's point, I think the answer on which policy would be applied at least >> needs to be predictable. If one receiver chooses one policy and a different >> receiver chooses the other policy, that is going to make it significantly >> more complicated for complex organizations to implement a DMARC p=reject or >> even p=quarantine policy. > > But it's not predictable now.  Some receivers follow p=reject all the time, > some follow it sometimes, some follow it never (me.) I follow it sometimes, but it would be easier to follow it always. If it were set up correctly, the latter would also be more reliable. To suggest disposition, I'd add an "snd=" tag in the From: domain's DMARC record, having one of the following values: *none*: Sender: field shall not be considered for messages From: this domain. This should be the default, for compatibility with existing settings. *any*: Accept messages forwarded by any Sender:, provided it validates. */reputation domain/*: Supply a domain to be looked up for Sender: reputation. If Sender: validates and has a positive reputation, then accept the message. > I think that in practice the situations where someone else is going to resign > your mail with a Sender DMARC policy are narrow enough that most IT departments > wouldn't even notice. Except if setting Sender: to the next trash domain becomes an attack path for phishing. Best Ale -- From nobody Wed Jul 29 03:54:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419563A08C0 for ; Wed, 29 Jul 2020 03:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm04qg-avgsv for ; Wed, 29 Jul 2020 03:54:47 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 789833A08A5 for ; Wed, 29 Jul 2020 03:54:47 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 2154D9F1F7 for ; Wed, 29 Jul 2020 03:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1596020086; bh=KOMFqTwUla9BndKms/xz4lWsLTerCHBLRL4BB56ZctA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=PUH2eiosdcBdoYLyyNiqCU/i7+QbHdzPxabkvE28Jlm0KwXdLa33FjkULKYzzn8jx M9WdtR9zwiahcbSbRnvsgWsUIPgZn7grFIYMFIifausaA+bT8nq1sDM3sarV786JQg 4R6OYoh+EYZjCGn+XYfXCadTarFGX9UwrBjbuEyo= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_A50EE9B1-620E-4B03-853E-ADBB745CA5AC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 29 Jul 2020 11:54:44 +0100 References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> To: IETF DMARC WG In-Reply-To: Message-Id: <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:54:49 -0000 --Apple-Mail=_A50EE9B1-620E-4B03-853E-ADBB745CA5AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2020, at 23:54, John R Levine wrote: >=20 >>>> Which verdict gets applied to the message? >>>=20 >>> I believe the reasoanble answer is both, and the filtering engine >>> evaluates both based on their reputations. >>>=20 >> Two responses, two different but equally valid answers, the other = (Dave's) >> being "receiver discretion", which *could* be an umbrella term to = include >> John's answer, but would certainly also include other applications of = rules >> for this scenario. >=20 > I think Dave and I are agreeing here. Assume I mean reputation in a = very broad sense. >=20 >> will be wailed, teeth will be gnashed, and garments will be rent, >> especially among those trying to do the right thing when sending = email and >> the deliverability people they employ. >=20 > I said to Autumn, I expect the number of people sending mail with = Sender DMARC will be so small that the deliverability people won't = notice. And, of course, receivers will continue to do as they d* = please, same as we've done for 40 years. I=E2=80=99m not sure why deliverability people are even mentioned here. = The problems with DMARC primarily affect one-to-one or one-to-few mails, = not bulk mails. The breakage DMARC causes doesn=E2=80=99t really affect = marketing, newsletters or anything else sent through automated systems. = I mean, yeah, some folks aren=E2=80=99t going to get their bulk mails = because of DMARC failures but mail fails all the times for lots of = different reasons.=20 DMARC broke how a lot of people and corporations use email as a = communication medium and I, for one, welcome the attempts to finally = address the fallout. I think if these issues are addressed more = comprehensively you=E2=80=99ll see a much bigger adoption for DMARC, = particularly among larger companies.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_A50EE9B1-620E-4B03-853E-ADBB745CA5AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jul 2020, at 23:54, John R Levine <johnl@taugh.com> = wrote:

Which verdict gets = applied to the message?

I = believe the reasoanble answer is both, and the filtering engine
evaluates both based on their reputations.

Two responses, two different but equally valid = answers, the other (Dave's)
being "receiver discretion", = which *could* be an umbrella term to include
John's = answer, but would certainly also include other applications of rules
for this scenario.

I = think Dave and I are agreeing here.  Assume I mean reputation in a = very broad sense.

will be wailed, teeth will be gnashed, and garments will be = rent,
especially among those trying to do the right thing = when sending email and
the deliverability people they = employ.

I said to Autumn, I = expect the number of people sending mail with Sender DMARC will be so = small that the deliverability people won't notice.  And, of course, = receivers will continue to do as they d* please, same as we've done for = 40 years.

I=E2=80=99m not sure why deliverability people are = even mentioned here. The problems with DMARC primarily affect one-to-one = or one-to-few mails, not bulk mails. The breakage DMARC causes doesn=E2=80= =99t really affect marketing, newsletters or anything else sent through = automated systems. I mean, yeah, some folks aren=E2=80=99t going to get = their bulk mails because of DMARC failures but mail fails all the times = for lots of different reasons. 

DMARC broke how a lot of people and corporations = use email as a communication medium and I, for one, welcome the attempts = to finally address the fallout. I think if these issues are addressed = more comprehensively you=E2=80=99ll see a much bigger adoption for = DMARC, particularly among larger companies. 

laura 

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

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

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







= --Apple-Mail=_A50EE9B1-620E-4B03-853E-ADBB745CA5AC-- From nobody Wed Jul 29 05:48: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 B172E3A0AF9 for ; Wed, 29 Jul 2020 05:46:59 -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 YhTZHzuyIaXP for ; Wed, 29 Jul 2020 05:46:57 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 268E53A0AE9 for ; Wed, 29 Jul 2020 05:46:57 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id h7so21981965qkk.7 for ; Wed, 29 Jul 2020 05:46:57 -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=45EYyouG8lxQ98MZEBluYLRHCXpCNb93eE2HLv530NY=; b=Z3Ud3ISffC40DvPlAd8bT0Z1Xzakor9/p0BT4XTLc4aBBBBCVgPkJAMP5c8r11UFWM JhbWSa9U6zJK4/6pg1ne3ol5ljVjzrhwwYPEo9t3hb4IozKV053q909CcUw0zSyX0gTm tDJTfpXYHSCfY22VY5HJ0M4QBh4Iq2eRcYyVFHskj8ikwyFVke4mbCQw7npl2VKSct0X XFz3THfQWNMfMNGO3HG0irbMCysfZlWKCYzZ/Qcgd248PX+AMZNMoCFvoQiZrDDIwOvW lB/cyiDMLGTmsTR6XmAsKbTwR7fqRPntfSXVtMCCBB8GHVfJ2OQlIgy1zpV9+0GbqYlu 20tQ== 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=45EYyouG8lxQ98MZEBluYLRHCXpCNb93eE2HLv530NY=; b=UBj4RYUhYWCRKYMx5tMJVI8D5dI4mn1Yke/FJ9/iYZPl7JfyH8jTNaRmp/b1VOCt0q 8mR1JWTK81glrmJOocRgLDj6jtV5lYjVeQpsPmyTMIWsimtAqP+SBmrxbQJ968Iy8U0c JRV73UZkDF+CBlhvVy7As9TTbOqUqO71oESoD6xCk8OadkjqvXCI8JqxTDcPI9XPkHor ElSksXE/WrRAKn5iE6TKhhGKiNrpYq4S1NwCu01rfmOyHEbk7IzO9YgYCoSMW6bzoiiA 3V71LxanKQiMasmtjHmGfhPuZLwrCEGMHfXNGTOrIVQwU6vGKJ/x87Ry7Hc43nt5vF9E ex1w== X-Gm-Message-State: AOAM5303W7KzR1SL+H2vYS5t4HzTJRgUVigpvK7otYuwtP5U4LcLkJaI E9RKp9oo90BTYjgHyZeZ1WcGh7bVJkxtOwx5sReinPsA X-Google-Smtp-Source: ABdhPJxWRkia65rNSYcWyJ9ETbS7ZU0WCX5t29/eh97w/tmGOKciuSiSWlRL6IVQiUFSgzanjcACS6SygVl1BoPymd8= X-Received: by 2002:a37:556:: with SMTP id 83mr32496544qkf.208.1596026816057; Wed, 29 Jul 2020 05:46:56 -0700 (PDT) MIME-Version: 1.0 References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> In-Reply-To: <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> From: Todd Herr Date: Wed, 29 Jul 2020 08:46:44 -0400 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006c6bc905ab93f358" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 12:47:06 -0000 --0000000000006c6bc905ab93f358 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins wrote: > > I=E2=80=99m not sure why deliverability people are even mentioned here. T= he > problems with DMARC primarily affect one-to-one or one-to-few mails, not > bulk mails. The breakage DMARC causes doesn=E2=80=99t really affect marke= ting, > newsletters or anything else sent through automated systems. I mean, yeah= , > some folks aren=E2=80=99t going to get their bulk mails because of DMARC = failures > but mail fails all the times for lots of different reasons. > > > Perhaps Autumn's use case and its mention of a bank that can't do DKIM signing lead me down a path that may never be followed. Where my mind went was to a place where an ESP was employed by a brand to send mail, either bulk or transactional (or both), and such mail was sent with the ESP domain as the domain in the "Sender:" field and the brand's domain as the domain in the "From:" field (or vice versa), with each domain publishing DMARC records. In such a scenario, it's possible that conflicting DMARC validation results could occur, leading to the concern over how such things might be handled. If this is not a possible use case for these header fields, then please accept my apologies for bringing deliverability into the discussion. --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000006c6bc905ab93f358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 29, 2020 at 6:55 AM Laura= Atkins <laura@wordtothewise.= com> wrote:

I=E2=80=99= m not sure why deliverability people are even mentioned here. The problems = with DMARC primarily affect one-to-one or one-to-few mails, not bulk mails.= The breakage DMARC causes doesn=E2=80=99t really affect marketing, newslet= ters or anything else sent through automated systems. I mean, yeah, some fo= lks aren=E2=80=99t going to get their bulk mails because of DMARC failures = but mail fails all the times for lots of different reasons.=C2=A0



Perhaps Au= tumn's use case and its mention of a bank that can't do DKIM signin= g lead me down a path that may never be followed.

= Where my mind went was to a place where an ESP was employed by a brand to s= end mail, either bulk or transactional (or both), and such mail was sent wi= th the ESP domain as the domain in the "Sender:" field and the br= and's domain as the domain in the "From:" field (or vice vers= a), with each domain publishing DMARC records. In such a scenario, it's= possible that conflicting DMARC validation=C2=A0results could occur, leadi= ng to the concern over how such things might be handled.

If this is not a possible use case for these header=C2=A0fields, the= n please accept my apologies for bringing deliverability into the discussio= n.

--

Todd H= err | Sr. Technical Program Manager
p: 70= 3.220.4153


This email and all data transmitted wi= th it contains confidential and/or proprietary information intended solely = for the use of individual(s) authorized to receive it. If you are not an in= tended and authorized recipient you are hereby notified of any use, disclos= ure, copying or distribution of the information included in this transmissi= on is prohibited and may be unlawful. Please immediately notify the sender = by replying to this email and then delete it from your system.

--0000000000006c6bc905ab93f358-- From nobody Wed Jul 29 07:12: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 69E163A0B74 for ; Wed, 29 Jul 2020 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWMxpT1tZzPM for ; Wed, 29 Jul 2020 07:12:00 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB4C3A0B72 for ; Wed, 29 Jul 2020 07:11:59 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 089689F1F7 for ; Wed, 29 Jul 2020 07:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1596031919; bh=TYLLoA2CdJDJcVPNslM9PzJoMf10odtbWWIyObEhwt4=; h=From:Subject:Date:References:To:In-Reply-To:From; b=ROuzdEA4d2xG/q0TlyEewUN+MAw4Yd5T5zNmCUQ6aUfV1BLerbxdyelJBOrVyNcms JzGBK/txVmpYZB95R9HP/w2DwwzGva2qNcKclMjrlYvbcyTnAMRcjNRB+jUBga9d20 /79BM+yyDsMPJ2lfZPLKoYKig+1BOH8mPV1XKw0E= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_F851EA61-248D-4DE5-9FDF-67EF7C680F98" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 29 Jul 2020 15:11:55 +0100 References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <2F20C6B2-001E-477F-A60E-F371042F8103@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 14:12:03 -0000 --Apple-Mail=_F851EA61-248D-4DE5-9FDF-67EF7C680F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jul 2020, at 13:46, Todd Herr = wrote: >=20 >=20 >=20 > On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins > wrote: >=20 > I=E2=80=99m not sure why deliverability people are even mentioned = here. The problems with DMARC primarily affect one-to-one or one-to-few = mails, not bulk mails. The breakage DMARC causes doesn=E2=80=99t really = affect marketing, newsletters or anything else sent through automated = systems. I mean, yeah, some folks aren=E2=80=99t going to get their bulk = mails because of DMARC failures but mail fails all the times for lots of = different reasons.=20 >=20 > Perhaps Autumn's use case and its mention of a bank that can't do DKIM = signing lead me down a path that may never be followed. I don=E2=80=99t think the bank is sending mail that isn=E2=80=99t DKIM = signed, I think DKIM signatures have the same inherent alignment failure = of SPF - where the admin assistant sends out a MTA for their business = unit/domain but uses the From: address of an executive of a different = business unit. That MTA signs for the domain it is supposed to sign for. = Possible my assumption was incorrect.=20 =20 > Where my mind went was to a place where an ESP was employed by a brand = to send mail, either bulk or transactional (or both), and such mail was = sent with the ESP domain as the domain in the "Sender:" field and the = brand's domain as the domain in the "From:" field (or vice versa), with = each domain publishing DMARC records. In such a scenario, it's possible = that conflicting DMARC validation results could occur, leading to the = concern over how such things might be handled. There will possibly be places where folks will choose to use Sender for = ESPs, but most ESPs are currently willing and able to provide alignment = for their customers. I can=E2=80=99t really see the ESP wanting to step = into the sender role here particularly when their customers are already = aligned. I can also envision a situation where the ESP doesn=E2=80=99t = want to be the sender because that may impact their legal liability and = responsibilities.=20 Longer term, though, this could actually be really beneficial for = companies who are using ESPs but can=E2=80=99t, for whatever reason, = align their mail at the ESP. The ESP can step in as =E2=80=9Csender=E2=80=9D= (where sender is customername@espalignmentdomain.example) and have that = DMARC align. Right now it=E2=80=99s not an issue as there is no delivery = hit for sending mail without a DMARC policy statement. But, if we ever = get to the point where p=3Dquarantine or p=3Dreject is required for = delivery, the ESP can handle that for their customers using the Sender: = header.=20 On the other hand, this would solve the problem where so many small = business owners and ad hoc groups got shut out of using ESPs when Yahoo! = sprung p=3Dreject on the world. The ESP could use the Sender: field and = it doesn=E2=80=99t matter that the mail wouldn=E2=80=99t align with = Yahoo. I do remember hearing at one point some of the big commercial = groups were including ESP outbounds in their SPF records to compensate, = so this would be less overhead.=20 Need to think about that a little bit because I can see some potential = attack vectors.=20 > If this is not a possible use case for these header fields, then = please accept my apologies for bringing deliverability into the = discussion. I hadn=E2=80=99t thought about this for ESP mediated mail. But you have = made me think a little harder about it.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_F851EA61-248D-4DE5-9FDF-67EF7C680F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Jul 2020, at 13:46, Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> = wrote:



On Wed, Jul 29, 2020 at 6:55 AM Laura = Atkins <laura@wordtothewise.com> wrote:

I=E2=80=99m not sure why deliverability people are even = mentioned here. The problems with DMARC primarily affect one-to-one or = one-to-few mails, not bulk mails. The breakage DMARC causes doesn=E2=80=99= t really affect marketing, newsletters or anything else sent through = automated systems. I mean, yeah, some folks aren=E2=80=99t going to get = their bulk mails because of DMARC failures but mail fails all the times = for lots of different reasons. 

Perhaps Autumn's use = case and its mention of a bank that can't do DKIM signing lead me down a = path that may never be = followed.

I don=E2=80=99t think the bank is sending mail = that isn=E2=80=99t DKIM signed, I think DKIM signatures have the same = inherent alignment failure of SPF - where the admin assistant sends out = a MTA for their business unit/domain but uses the From: address of an = executive of a different business unit. That MTA signs for the domain it = is supposed to sign for. Possible my assumption was = incorrect. 
 
Where my mind went was to a place where an ESP was employed = by a brand to send mail, either bulk or transactional (or both), and = such mail was sent with the ESP domain as the domain in the "Sender:" = field and the brand's domain as the domain in the "From:" field (or vice = versa), with each domain publishing DMARC records. In such a scenario, = it's possible that conflicting DMARC validation results could = occur, leading to the concern over how such things might be = handled.

There will possibly be places where folks will = choose to use Sender for ESPs, but most ESPs are currently willing and = able to provide alignment for their customers. I can=E2=80=99t really = see the ESP wanting to step into the sender role here particularly when = their customers are already aligned. I can also envision a situation = where the ESP doesn=E2=80=99t want to be the sender because that may = impact their legal liability and responsibilities. 

Longer term, though, this could actually be really = beneficial for companies who are using ESPs but can=E2=80=99t, for = whatever reason, align their mail at the ESP. The ESP can step in as = =E2=80=9Csender=E2=80=9D (where sender is customername@espalignmentdomain.example) and have that = DMARC align. Right now it=E2=80=99s not an issue as there is no delivery = hit for sending mail without a DMARC policy statement. But, if we ever = get to the point where p=3Dquarantine or p=3Dreject is required for = delivery, the ESP can handle that for their customers using the Sender: = header. 

On the other hand, = this would solve the problem where so many small business owners and ad = hoc groups got shut out of using ESPs when Yahoo! sprung p=3Dreject on = the world. The ESP could use the Sender: field and it doesn=E2=80=99t = matter that the mail wouldn=E2=80=99t align with Yahoo. I do remember = hearing at one point some of the big commercial groups were including = ESP outbounds in their SPF records to compensate, so this would be less = overhead. 

Need to think about = that a little bit because I can see some potential attack = vectors. 

If this is not a possible use case for these = header fields, then please accept my apologies for bringing = deliverability into the = discussion.

I= hadn=E2=80=99t thought about this for ESP mediated mail. But you have = made me think a little harder about it. 

laura 

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

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

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







= --Apple-Mail=_F851EA61-248D-4DE5-9FDF-67EF7C680F98-- From nobody Wed Jul 29 10:35: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 CC22A3A0C2A for ; Wed, 29 Jul 2020 10:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=ITA8HjQ/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=kJ9ksFTe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luag4pD5yUWE for ; Wed, 29 Jul 2020 10:34:57 -0700 (PDT) Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2E83A0DE1 for ; Wed, 29 Jul 2020 10:34:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3356; t=1596044088; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=FkrbJAburRqRpbkjRb0HVPaog6g=; b=ITA8HjQ/+Zq2Thi6mEFKDSaHm+RWB9ipmdeVqM6o+QRwXa47PE1Jjh4dPaUSfb QXAJ+VFTyyJ4Pd8v4OB82LKwgyAOQZm5m6WuzLIHZn0y+1DF+Hl1BMEKlMKBKIrx K9kebz54XhXS/xccdbHJNu4CxSklfINg6s1WhmS1CUPBQ= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 29 Jul 2020 13:34:47 -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 2476379291.1.4892; Wed, 29 Jul 2020 13:34:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3356; t=1596043974; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vu8OJzm bmms9AOTfstE9VZiU15M+MEHugNwfWPyL1Nc=; b=kJ9ksFTe1xWmQ1SVCypNm/N RUf8v0y2CJ55EAMNasuOSyfM0FjJpMGreI79po9XVNk7Qi9vQ2vkH34wUSUlrw9D 0yRC8fjJui6Sv9WLfcTFjkYM1KWpDiVMohmFz4yoqxEgTXbuX2Ht3NKFUMdgsG0y E7AReZpDQVti6s1/5WX0= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 29 Jul 2020 13:32:54 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2187149546.1.60784; Wed, 29 Jul 2020 13:32:53 -0400 Message-ID: <5F21B338.8000700@isdg.net> Date: Wed, 29 Jul 2020 13:34:48 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Doug Foster , dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> In-Reply-To: <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 17:35:02 -0000 On 7/28/2020 1:19 PM, Doug Foster wrote: > Hector, I do not understand this comment: > > "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma." > SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model. The problem we have with DMARC was the same with SSP which was replaced by ADSP which attempted to ignore the problem. Generally, as it often done with ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep it open ended, etc. It just wasn't resolved and ADSP was abandoned but returned as DMARC but it also kept the same 3rd party ignorance as ADSP did. If this issue is not resolved for DMARC, I see an interesting situation during DMARCBis Last Call explaining how we abandoned ADSP for having problem XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ. > Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key. But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer. > > The goal of this discussion is to find a way to coerce trust. We do not lack ways to grant trust on request. This issue is not about the known, but the unknown. We don't have an issue with proactive authorization and whitelisting methods. I've been in this DKIM project for 15+ years, and to me, the goal has also been to find a reasonable, scalable deterministic protocol that will handle unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a bad sense, unknown that you don't know anything about them. So you ask the author, "Hey, is this 3rd party signer ok?" SPF allows 3rd party IP declarations. DKIM POLICY model does not offer this capability. We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a deterministic method to associate the author domain with 3rd party signer domains. This authorization is defined by the Originating, Author Domain. Look at my DMARC record for my isdg.net domain: v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net; The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain signature: Author Domain IS NOT EQUAL TO Signer Domain Then it can do a ATPS look: base32(sha1(SIGNER-DOMAIN))._atps.isdg.net So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I would go to the wizard https://secure.winserver.com/public/wcdmarc, enter your domain in the list of authorized signers, click Zone Record and I get a record I can add to my isdg.net zone: e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps TXT ("v=atps01; d=bayviewphysicians.com;") So anyone out there can see that I authorized bayviewphysicians.com to sign for isdg.net It is really sample. Whether we can "coerce" receivers to honor any of this is a different situation. In general, all you can do create a PROTOCOL that makes good engineering sense and usable by the IETF community. If not, then generally systems will ignore it. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Jul 29 14:00:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5418D3A0DEF for ; Wed, 29 Jul 2020 14:00:56 -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 F2jA0tPi9qDM for ; Wed, 29 Jul 2020 14:00:54 -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 8CC083A0DC6 for ; Wed, 29 Jul 2020 14:00:54 -0700 (PDT) X-ASG-Debug-ID: 1596056452-11fa3118c76bb90001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id kYvPAVvTPTuEgLS9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 29 Jul 2020 17:00: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=CQFMbUFGdmzcVk0gzuwys6SWyaU/MfbCYSJRy5nRs0c=; b=QH26F9oQ9ok3lDPdOkKsqItseSB1ZlNQqD9tz6KKJhptVctVvj1IhAd41fNbisJGP l3rq4unuyGcKhCtagyJSuQOwf9xtL0I+c5YFvCy6K+1rTVkZlpYZm2WAHa+J3BXCb a2+H+0Uy/TVL/7l3s/Yjj7NTwVrKKnYDZMTRycikI= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Wed, 29 Jul 2020 21:00:45 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=7136fd3e9e9749eca778740aaf9db759 In-Reply-To: <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> References: <20200728173716.068CB1D9840C@ary.qy> <655df0e7-4fef-e441-9a57-df4a10aa1fa3@taugh.com> <31514812-902B-4AF1-9747-51ACA8D58DD9@wordtothewise.com> X-Exim-Id: e290d28b91c74346bb89fd968910d877 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596056452 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: 4477 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.83554 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:00:56 -0000 This is a multipart message in MIME format. --7136fd3e9e9749eca778740aaf9db759 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On the issue of spoofing, only two security postures are possible in the in= coming mail gateway: We allow spoofing by default, then block problematic spoofing as detected, = on a case-by-case basis.We disallow spoofing by default, then allow desired= mail as needed, on a case-by-case basis. Only the second security posture is credible in a security audit. DMARC v= 1 is the most effective tool for implementing that security posture. The = proposed "new" DMARC returns us to the first security posture. Incoming email can be divided into these categories: Messages that have confirmed identitiesMessages that appear to be spoofing = but actually contain desired content from valued senders.Messages that appe= ar to be spoofing and are unwanted.Messages where spoofing cannot be evalua= ted. Security posture 2 will be associated with these policies: Message category 1 will be allowed or blocked on other criteria. In part= icular, confirmed identity allows preferred message handling to be implemen= ted safely.Message category 2 will be handled through the receiving organiz= ation's exception process. Message category 3 will always be blocked. = Message category 4 may be reviewed, as time permits, to determine a local p= olicy which moves it into category 1 or 3. If there are category 2 problem cannot be solved between a recipient user a= nd his email security team, we need to document when and why this is happen= ing, However, the expectation is that senders in category 2 and 4 will have ince= ntive to move into category 1 over time. To the extent that this has not = happened, it is a great misfortune. An excess of category 2 messages can contribute to an organization choosing= to delay or abandon implementation of security posture 2. This increases= their risk. Indirectly, category 2 messages serve to facilitate the dirt= y work of category 3 messages, in exactly the same way that a large enough = crowd can become an enabler for looters and arsonists. DF --7136fd3e9e9749eca778740aaf9db759 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On the issue of sp= oofing, only two security postures are possible in the incoming mail gatewa= y:
  1. We allow spoofing by default, then block problematic spoofi= ng as detected, on a case-by-case basis.
  2. We disallow spoofing by de= fault, then allow desired mail as needed, on a case-by-case basis.
    3. Only the second security posture is credible in a security audit. &nb= sp; DMARC v1 is the most effective tool for implementing that security post= ure.   The proposed "new" DMARC returns us to the first security postu= re.

    Incoming email can be divided into these categ= ories:
    1. Messages that have confirmed identities
    2. Message= s that appear to be spoofing but actually contain desired content from valu= ed senders.
    3. Messages that appear to be spoofing and are unwanted.
    4. Messages where spoofing cannot be evaluated.
    Security = posture 2 will be associated with these policies:
    • Message cate= gory 1 will be allowed or blocked on other criteria.    In partic= ular, confirmed identity allows preferred message handling to be implemente= d safely.
    • Message category 2 will be handled through the receiving = organization's exception process.   
    • Message category 3 w= ill always be blocked.    
    • Message category 4 may be revi= ewed, as time permits, to determine a local policy which moves it into cate= gory 1 or 3. 
    If there are category 2 problem cannot be = solved between a recipient user and his email security team, we need to doc= ument when and why this is happening, 

    Howeve= r, the expectation is that senders in category 2 and 4 will have incentive = to move into category 1 over time.   To the extent that this has not h= appened, it is a great misfortune.

    An excess of ca= tegory 2 messages can contribute to an organization choosing to delay or ab= andon implementation of security posture 2.   This increases their ris= k.   Indirectly, category 2 messages serve to facilitate the dirty wor= k of category 3 messages, in exactly the same way that a large enough crowd= can become an enabler for looters and arsonists.

    = DF



--7136fd3e9e9749eca778740aaf9db759-- From nobody Thu Jul 30 03:40:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CFD3A1066 for ; Thu, 30 Jul 2020 03:40:05 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=4T5x9+3c; dkim=pass (2048-bit key) header.d=wizmail.org header.b=czjRh69j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZEY2p_ElnpG for ; Thu, 30 Jul 2020 03:40:03 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 66FAD3A1064 for ; Thu, 30 Jul 2020 03:40:02 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :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:Autocrypt; bh=2JqxMc5tPiWEzxvzLsQj3DTfUm3e8vnpWCwcM60TKkc=; b=4T5x9+3cNJIVBAV8M5r/dxM4kx A+0HAiJzivXZke0m3iHmH7norbPK+kwgNP3uhxornfS5Red4F9IWTy98KoBQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject: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:Autocrypt; bh=2JqxMc5tPiWEzxvzLsQj3DTfUm3e8vnpWCwcM60TKkc=; b=czjRh69jGPJz3DV6Yg1fY10McU y3jH/HqWPk8h4YOHAUHvOw50dva9TQ/7czTtKPQ8PYnRYPX0dDcdZPyrM161B8g+rj6pJL/BDygIS NTxJEFs7mp9OJ6A1hW9u8/8CMGrCc1iBbQptkKr5NlPjoXNv5hP/g7KEbiRFnozHT8qafob72/ZVD rwimnNdLeUPJw/N2c4H27vidwQlzwkI1dRYC3zWyRb+tM/U+lTUIMJLvGrNMmeQguwZZhAGlqc066 aWr3ak6+Kg+MQ6zsY7WNtRY45gGPuGQhuiPiVThOHVx1qvdmz0MwXChtmr6SxmjDjqxFTrMKGUZy7 AwL5uENQ==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.103) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1k15yh-00GrWk-Ff for dmarc@ietf.org (return-path ); Thu, 30 Jul 2020 10:39:59 +0000 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: Date: Thu, 30 Jul 2020 11:39:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F21B338.8000700@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 10:40:06 -0000 On 29/07/2020 18:34, Hector Santos wrote: > Look at my DMARC record for my isdg.net domain: > > v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; > ruf=mailto:dmarc-ruf@isdg.net; > > The atps=y [...] > So anyone out there can see that I authorized bayviewphysicians.com to > sign for isdg.net > > It is really sample. That works at a domain-controlled level. But people sign up for, and write to, mailinglists on an individual level. Mismatch. -- Cheers, Jeremy From nobody Thu Jul 30 04:57:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5325A3A0A43 for ; Thu, 30 Jul 2020 04:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 oZzcnMX5MDQH for ; Thu, 30 Jul 2020 04:57:18 -0700 (PDT) Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3422E3A108F for ; Thu, 30 Jul 2020 04:57:17 -0700 (PDT) Received: from localhost [127.0.0.1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1596110235; bh=ExGIQ5d72UlevYUtMi3d9YJEKePZ4z4YDNCVvqOdRvE=; h=Subject:To:References:From:Date:In-Reply-To; b=wWXKydoCQf81KSZoe9lgTd6mpbhINUiK/nypDchlgOYv6KMvLF9VeF+GnuXAjkdII M+WinwV06eMLMBBGl7TtYJp9Wfizy62EZGL+/2GKdK9+kTOIe0fhJjklbCjwdXuAnd MHdhOPbabKQw2VRXCZP1mDBXKnDQCv4N62KAsFOI= To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> From: Ken O'Driscoll Organization: We Monitor Email Message-ID: Date: Thu, 30 Jul 2020 12:57:14 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 11:57:20 -0000 On 30/07/2020 11:39, Jeremy Harris wrote: > That works at a domain-controlled level. But people sign up for, > and write to, mailinglists on an individual level. Mismatch. To be fair, this thread is specifically about a non-MLM use case at an organisational level. But, I believe that any improvements to how DMARC might handle use cases like mailing lists will likely have to be at the domain-controlled level for there to be any chance of widespread adoption. >From experience, the type of organisations that are deploying DMARC (in p=reject) are not interested in allowing individual senders to delegate which third-parties can send on their behalf. Banks etc. don't care about mailing lists, most have HR policies that prevent employees from interacting on external discussion groups so it's not on the radar. However,  the use case presented in this thread - executive assistants sending on behalf of multiple DMARC protected brand domains - is not that uncommon and I think a policy solution to that would be warmly welcomed. Ken. From nobody Thu Jul 30 05:50: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 262A23A10DB for ; Thu, 30 Jul 2020 05:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MTfIbPzB; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=MKcSjVQf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXiiRRHqqZXB for ; Thu, 30 Jul 2020 05:50:24 -0700 (PDT) Received: from mail.winserver.com (groups.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 0E2FB3A10CE for ; Thu, 30 Jul 2020 05:50:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1390; t=1596113415; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=4gP1rSzy9LiQhLo9tU5HYua3Qyw=; b=MTfIbPzBDOeuicINQQN8GFwe2IYsv9eFcEy7dJ8uDa63WEqmMGZ1uu+WWQ77lY lI8sOvEifDKQ9LV+K0BtTL1K88uZ0jycCBD5UN7e038GBqq1EBpB/ePYaF9+4OWl 9BGdbgAbU+PhEmy26eshD1oPrIC8SmChjHd4UoVlDDRUU= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 30 Jul 2020 08:50:15 -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 2545705449.1.3984; Thu, 30 Jul 2020 08:50:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1390; t=1596113300; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ssjRwqL LLoaG4nGfI38rReQe5Bxv4dfDSKb6t3jbtiQ=; b=MKcSjVQfPkgsWloD029ZLlo NblwRxSX0gnRrGB0VIKRJ0ySzgL6qVwTuOOo4ciHT5o0TxWdAvZNAGHlpqRTfL9u EL0bJTpE1RvRQztsbV/3aL1RySZxbRIeIbdis4TEMBR0hqyPpT+LWdYD1S8jkV6S prVt1IlMBE4ymJaY3uKU= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 30 Jul 2020 08:48:20 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2256475546.1.60492; Thu, 30 Jul 2020 08:48:19 -0400 Message-ID: <5F22C209.5040509@isdg.net> Date: Thu, 30 Jul 2020 08:50:17 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:50:26 -0000 On 7/30/2020 6:39 AM, Jeremy Harris wrote: > On 29/07/2020 18:34, Hector Santos wrote: >> Look at my DMARC record for my isdg.net domain: >> >> v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; >> ruf=mailto:dmarc-ruf@isdg.net; >> >> The atps=y [...] >> So anyone out there can see that I authorized bayviewphysicians.com to >> sign for isdg.net >> >> It is really [simple.] > > That works at a domain-controlled level. But people sign up for, > and write to, mailinglists on an individual level. Mismatch. Very true. The authoring domain will need to have a way to add ATPS records defining who has explicit authorizing to sign/resign on behalf of the authorizing domain. This will immediately help resolve a number of the scenarios for Authorized Third Party Signatures. The individual user mailing list issue continues because of the use of restrictive domains in a public arena where there are no controls. There are two ways to deal with this: 1) Domain Organization policy. Does it allow its domain users to freely use their corporate, company domains in a public professional environment? 2) The MLM supported of a DKIM+DMARC+ATPS will restrict domains that it can not resign. The MLM needs to be updated to support restrictive DKIM Policy domains. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Jul 30 05:51: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 364B93A10F3 for ; Thu, 30 Jul 2020 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=fVmjoRMr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=SqyN8NN8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ySIY-oAkV46 for ; Thu, 30 Jul 2020 05:51:23 -0700 (PDT) Received: from mail.winserver.com (groups.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 9B1F63A10DB for ; Thu, 30 Jul 2020 05:51:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1220; t=1596113479; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=LD0aH0m2JE1sN/X2tLkTBpTfn/c=; b=fVmjoRMr2Zb1vNz2bLUVlmlb+Pl8OosZj36BYrkr/KbOwDM+teV9+SRxx972Wa RFr5/JoG7madZ6nrFL4BO7Wa3fITa8agiKbZacGp1hZ4Y0l2CvTrJkeii2+LPwdn /oWEQJ7zGLLQZZ6NrCTKm7egzVlP+sBAM9sL7ePM+ycTQ= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 30 Jul 2020 08:51:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2545770548.1.3888; Thu, 30 Jul 2020 08:51:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1220; t=1596113362; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=N6Wwy+N mhTQtnrtHNChSJiVLqMnY7D8ptWdinAO2qrc=; b=SqyN8NN8hM4YsESOIYmFtUP PqZv8HaJtYFW4elg3+cZWNKccdjyUYu2LJV7NBKatgbgkR1iJyPjZdgbKQtHAtQn OykqXRsh30N/GzdqW8kClPrwAi/XVdOVm6aVDuyZ4B3O9us/sX+mF8wOG8Xl2YI5 oOMHWc1xGprcyaSdkXgs= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Thu, 30 Jul 2020 08:49:22 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2256537343.1.60928; Thu, 30 Jul 2020 08:49:21 -0400 Message-ID: <5F22C246.1060309@isdg.net> Date: Thu, 30 Jul 2020 08:51:18 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:51:26 -0000 On 7/30/2020 7:57 AM, Ken O'Driscoll wrote: > On 30/07/2020 11:39, Jeremy Harris wrote: >> That works at a domain-controlled level. But people sign up for, >> and write to, mailinglists on an individual level. Mismatch. > > To be fair, this thread is specifically about a non-MLM use case at an > organisational level. But, I believe that any improvements to how DMARC > might handle use cases like mailing lists will likely have to be at the > domain-controlled level for there to be any chance of widespread adoption. > > From experience, the type of organisations that are deploying DMARC (in > p=reject) are not interested in allowing individual senders to delegate > which third-parties can send on their behalf. Banks etc. don't care > about mailing lists, most have HR policies that prevent employees from > interacting on external discussion groups so it's not on the radar. > However, the use case presented in this thread - executive assistants > sending on behalf of multiple DMARC protected brand domains - is not > that uncommon and I think a policy solution to that would be warmly > welcomed. +1 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Jul 30 10:26:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F133A0FDE for ; Thu, 30 Jul 2020 10:26:20 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QlJdGi3cgghU for ; Thu, 30 Jul 2020 10:26:17 -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 2147F3A1419 for ; Thu, 30 Jul 2020 10:25:00 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEA05HY2LN68320@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 30 Jul 2020 12:23:31 -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.7.30.171818, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.59.172] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UDMvHxfUbN9h+ncI1KZZfzPyiNDdgyiTO3/CBlAkvff9fbkHBl01LEq4t4BbDoQrfqVIBNXSxLWH6JSGldJJ0caAmFvDrE9fSKv+b2KD/Bk5hFzdahH89SiUYFJWiv1OzLdCNNjVWs+Fucgjfz9A57WqK/w+u1by4xYd0SOHIgP6FA8rPmz5ql8e2pSYK4obJvEunw+3ZOUxGpEFmk8VKDZPoMrckFonXp+cIEiM48ieV4I8z+fL/LTVg3JUWIXzht93qW39WXhxQjoqnRH7Zh3C5ve3nXxEFLEsYtWSlD6SHFdDlq+dUttM5T4mID94akJAa/Q+hEtY6vpZcj1zSQ== 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=CRtWLgzmcU9mpMj4/1PfXDsCzAnjTpvYBwBiy/3j+jg=; b=FFkwDTjtRDP5EtwuXFC0bv8iWqLt5knxvlLeuh4l9epYF1Tap0OAdV918oj9i/WQXa4H64wFXYFwGADn4EKNk8s6CQMFp7N5u3qejzc7s/do3au2twQCOaGhSSDbPnQIu5fUy6Y2xywzvEXnA1T01+m4PgepM1R+PR9BMJ3DCQdah4qgCl96k5rEDMtleAuKN6qwLmcptU7lHXnlx5OSHB++4UtIbs97x3B0LdGKx/ingu+Nu5OQsrTv/j2g8iNbsvHiYAYKKP71JEqsSD0Ys0qzRZsao2NRS1qGXj3z2JEtU20wuttJBRXZ5mg6Xz0ykMO7p+DaXu/T3JsmjhnpCQ== 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=CRtWLgzmcU9mpMj4/1PfXDsCzAnjTpvYBwBiy/3j+jg=; b=ql4/OtWwABTaUf9U2AyWDwi6R/qcp6ZuHjXWD0rfWayA2tslJZ+NsJK6T6TfsGkmDViMZRhx0vRN/rXsLDZlpyUZ4IaSvT2scLS2mNeqMu/+twVc02rKWJTe1YKWn1+MTtDUPdj4tIS9N/mPHrHomhCcQRBbibhuBieXPZfkw7k= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB3915.namprd06.prod.outlook.com (2603:10b6:5:8e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Thu, 30 Jul 2020 17:23:30 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Thu, 30 Jul 2020 17:23:30 +0000 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> From: Jesse Thompson Message-id: <542c8309-de14-330a-cfe9-26a03191dc84@wisc.edu> Date: Thu, 30 Jul 2020 12:23:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <5F21B338.8000700@isdg.net> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR12CA0010.namprd12.prod.outlook.com (2603:10b6:610:57::20) 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 CH2PR12CA0010.namprd12.prod.outlook.com (2603:10b6:610:57::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Thu, 30 Jul 2020 17:23:29 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8011511e-5f3a-400a-2ef6-08d834ad471b X-MS-TrafficTypeDiagnostic: DM6PR06MB3915: 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: cN3fhnfVJxwz372fyNX9lDttq0R/bN1W72kyEIjiCKAF9pTDsU0Oj9zhjkrNgHao43RMlEK9pg7+JzkGpSEmkwKdf80+h3/8aTlN/+EPpZ8+yZ/SJEaIQIzTj066jCYFZTqwrS6RE/4QIkTBJa749adb/ZnHzcLo6lZKStFaP5/DFUznA/O8yqfS6v90+/V/8wt3a9N3byPvW+yYUC8AZvBf7vQvfuF48VrGVPQEcReUcLO/dVP8ihLnyHJXInPBef+a4umfeR3CneOB3MQUMdaYey/CIJ34duajh2kxqKRIU1nOe6gFn34sxceqr7JeMDxAGaXA30YRf7HZnn4ctW07sTB/mSepoKeNWCM5qPao2m7GRGqJ7QHeFwE9qsiUda+yPNOST5i+pNw46EWXNSCZhDH7cbA+3Y98bTG89l0HmJMy60/SV0L/LcDrjTknKYRAjdKbXrjlUnJY3ThOqWdUuuVYiKcgEMEgtK8StiY= 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; SFTY:; SFS:(366004)(346002)(396003)(39860400002)(136003)(376002)(8936002)(75432002)(786003)(16576012)(5660300002)(86362001)(26005)(8676002)(316002)(66946007)(44832011)(66556008)(66476007)(966005)(2616005)(66574015)(83380400001)(6486002)(6916009)(36756003)(16526019)(478600001)(53546011)(956004)(31696002)(2906002)(31686004)(186003)(223123001)(43740500002)(130980200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: AtoOy/f7rEL5/obA49P3qP6vp86PSzEOGkjHPKIcYZrbbOOnVP/FgSzs1ZnsG2XzPc1rxioyzfVl4q1GADEfYDsifOWLuokcCAHoR45QfX8sOUf+jqQgMS1jhU/BeIuBvWsb1+qjqTVhQ+k7PyJb2/K5StUIxUYhuOFcc9/IRIsT1FWybD1arsHwnC70uZKVEJ6mZ0UFN4XSkUZco8l7sqj4Au2OYhpxmDnbCrcuVsN/A4p688D6qCIx9WFzp1KmhrgdVN/yLvTlKsUHb+KEf7y+z4vOAYM8S/gRY2i9QNtXJF0pnMMYxUz2J2clsFqCbGVauZFYzrq0D9dPRnavCydzavuYVauPKAljT5H2PRY8L85zun08/cHduiDM8LiyvoBpX6t0elLXpAwnt9EZXZaFsgq6mA3SwUsgDksV7OvLB9mILo6vBQRYUnbJiqlZIRox7njby/B6kFt9tq+IjMjzTCjzfSaMOGhCDU8b9Fg= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 8011511e-5f3a-400a-2ef6-08d834ad471b X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2020 17:23:30.2024 (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: A92JtVlsvJ644xIXUu2wc4voZjunevGzC94TC91z+VZU+PWD4ej7RMJZF7oYo+2UWf35OLf/P/ttFSf4jrtBbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB3915 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 17:26:20 -0000 On 7/29/20 12:34 PM, Hector Santos wrote: > On 7/28/2020 1:19 PM, Doug Foster wrote: >> Hector, I do not understand this comment: >> >> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma." >> > > SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model. > > The problem we have with DMARC was the same with SSP which was replaced by ADSP which attempted to ignore the problem. Generally, as it often done with ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep it open ended, etc.  It just wasn't resolved and ADSP was abandoned but returned as DMARC but it also kept the same 3rd party ignorance as ADSP did.   If this issue is not resolved for DMARC, I see an interesting situation during DMARCBis Last Call explaining how we abandoned ADSP for having problem XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ. > >> Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key.    But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer. >> >> The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request. > > This issue is not about the known, but the unknown. We don't have an issue with proactive authorization and whitelisting methods. > > I've been in this DKIM project for 15+ years, and to me, the goal has also been to find a reasonable, scalable deterministic protocol that will handle unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a bad sense, unknown that you don't know anything about them. So you ask the author, "Hey, is this 3rd party signer ok?" > > SPF allows 3rd party IP declarations.  DKIM POLICY model does not offer this capability. > > We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a deterministic method to associate the author domain with 3rd party signer domains.   This authorization is defined by the Originating, Author Domain. > > Look at my DMARC record for my isdg.net domain: > > v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net; > > The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain signature: > >   Author Domain IS NOT EQUAL TO Signer Domain > > Then it can do a ATPS look: > >    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net > > So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your domain in the list of authorized signers, click Zone Record and I get a record I can add to my isdg.net zone: > > e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; d=bayviewphysicians.com;") > > So anyone out there can see that I authorized bayviewphysicians.com to sign for isdg.net > > It is really sample. > > Whether we can "coerce" receivers to honor any of this is a different situation.  In general, all you can do create a PROTOCOL that makes good engineering sense and usable by the IETF community. If not, then generally systems will ignore it. I admittedly know nothing about ATPS, but I think its fundamental problem is that it authorizes 3rd parties at the domain level and that makes it not much better than SPF, just different. Email domains that have more than a few users don't want to authorize every potential 3rd party (converges quickly to all of them, for large/complex organizations) to sign as every user/address in the domain. Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put every 3rd party into our domains' SPF records. I'd essentially be authorizing most of the [legitimate] internet to use the domains. Ironically, you'll notice some domains actually doing this via SPF record flattening and macros specifically because they do not even want to attempt to solve the 3rd party authorization problem (look at umich.edu). On the other hand, something like ATPS might be a partial solution for the MLM header munging problem, at least for intra-organizational email leveraging 3rd party platforms. e.g. If I authorize only mlm.wisc.edu (and not every subdomain, so aspf=r is not an option) to send as wisc.edu (and potentially all of our ~480 domains which aren't all subdomains of wisc.edu), then the MLM platform should know that it doesn't need to rewrite the From header for messages from users in those domains. It's kind of the inverse of the ARC dillemma. ARC is missing a mechanism to tell an Intermediary if it will be safe to *not* rewrite the From header, and the lack of having a mechanism to convey historical or intended trust means that Intermediaries will always need to munge all email, by default. Jesse From nobody Thu Jul 30 12: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 0E28E3A0C06 for ; Thu, 30 Jul 2020 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 69JAphHrC1Iw for ; Thu, 30 Jul 2020 12:47:52 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 214D43A0BFA for ; Thu, 30 Jul 2020 12:47:51 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id p27so4782785uaa.12 for ; Thu, 30 Jul 2020 12:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=490iad+Pl5BvJbBYKIpB7E14N/qox819NI21d/lAP4U=; b=pcSXQp095S0CUjKli7c5Js51CcSqYBXAkIkIxh1i/ciHCRY37AFq0T/G+9t5Y0VHcJ SKAmVMmjMCgC9OOr8gPoLdFfiDWMCa7GfFm9o18AK/BkcChEbCyk/kNBeHMOaPmrEOR+ R8ikqwgAV2RoKjkfh+qa846HrxEzkEszwaXPK3RCncmcvkYS5rhT2LConYV77mLP8J/t 45kuExgaKirWLTlAgH0JAWQgViJHT8DJ7yiwelw/6bB76O8Yk7gMCi02zRj0RQr1jWs7 lVe3g7ByQzMzY3OBEGr6Y5tf/UxPpFH4RWRiCBxATuT2KPRrM9WNV5rmBct3bYEYK0kX Se+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=490iad+Pl5BvJbBYKIpB7E14N/qox819NI21d/lAP4U=; b=EtBksJ85fokxgyxpw6IpnZURrujKxYqLZg61nIrv40+M8uEOyYcHJWpyiS0K3nOHV+ q4SdLoDpLvdkpbCKcQorwpTBaIbDtolurORNPJughG+5/IXnlHwO3DWxOIhkNMlDbRxT n+6Ql+/1cIvSLKn12nnhPR6oTQ39Nx50NX6fXZlDQ/2nJzty976exvToIUsy9HmacBm9 Yp1xgdTnolFP/ZBnsZfZZafipNi7SDK4nQDeZLUnGI2fRATLzPRj95Z05LGlhvSjooci +E0anAGE3YUnf8HfS8+/b45WARgOgAaqil7VMaeV9N67HGvmBCgLEVY9f073JFmmN95p mn3Q== X-Gm-Message-State: AOAM5312jM6XBhaGxRMpJp3+hBFDcBjO1uF245ra2m2+on0AD+1YXjXB /t9xwRTut/NDiCCqSYATwzZNuxwUXPB9XOkEbqs= X-Google-Smtp-Source: ABdhPJwXIKKJOFiBQPmSSE3nHIx0QCUk/NP4t5U1N82GLDaTCxWNml5vRvSN5swYozs55kZXGJr9HWenysPybTV+WKo= X-Received: by 2002:a9f:26a5:: with SMTP id 34mr275026uay.67.1596138470784; Thu, 30 Jul 2020 12:47:50 -0700 (PDT) MIME-Version: 1.0 References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> <542c8309-de14-330a-cfe9-26a03191dc84@wisc.edu> In-Reply-To: <542c8309-de14-330a-cfe9-26a03191dc84@wisc.edu> From: "Murray S. Kucherawy" Date: Thu, 30 Jul 2020 12:47:39 -0700 Message-ID: To: Jesse Thompson Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000090419a05abadf233" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 19:47:55 -0000 --00000000000090419a05abadf233 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 30, 2020 at 10:26 AM Jesse Thompson wrote: > I admittedly know nothing about ATPS, but I think its fundamental problem > is that it authorizes 3rd parties at the domain level and that makes it not > much better than SPF, just different. > Translated into IETF-ese: "I have not read your document but I do have an opinion about it..." ;-) Seriously though, yes, that's correct. Note that its status is Experimental; the goal was to see if this was a useful thing to implement and upon which to iterate if the experiment yielded positive results. But I think there were only ever about two implementations. Email domains that have more than a few users don't want to authorize every > potential 3rd party (converges quickly to all of them, for large/complex > organizations) to sign as every user/address in the domain. Even if SPF > didn't have the 10 DNS lookup limitation, I would not choose put every 3rd > party into our domains' SPF records. I'd essentially be authorizing most > of the [legitimate] internet to use the domains. > Yes, it has this scaling problem. Had it been shown to be effective at dealing with the indirect mail flows issues that DMARC forced to be front-and-center a few years later, I imagine we could've revised ATPS to be more scalable. -MSK --00000000000090419a05abadf233 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 30, 2020 at 10:26 AM Jesse Th= ompson <jesse.thompson=3D40= wisc.edu@dmarc.ietf.org> wrote:
=
I admittedly know nothing= about ATPS, but I think its fundamental problem is that it authorizes 3rd = parties at the domain level and that makes it not much better than SPF, jus= t different.=C2=A0

Translated into IET= F-ese: "I have not read your document but I do have an opinion about i= t..." =C2=A0 ;-)

Seriously though, yes, that&= #39;s correct.=C2=A0 Note that its status is Experimental; the goal was to = see if this was a useful thing to implement and upon which to iterate if th= e experiment yielded positive results.=C2=A0 But I think there were only ev= er about two implementations.

Email domains that have more than a few users don't want to authorize e= very potential 3rd party (converges quickly to all of them, for large/compl= ex organizations) to sign as every user/address in the domain.=C2=A0 Even i= f SPF didn't have the 10 DNS lookup limitation, I would not choose put = every 3rd party into our domains' SPF records.=C2=A0 I'd essentiall= y be authorizing most of the [legitimate] internet to use the domains.
<= /blockquote>

Yes, it has this scaling problem.=C2=A0 Had= it been shown to be effective at dealing with the indirect mail flows issu= es that DMARC forced to be front-and-center a few years later, I imagine we= could've revised ATPS to be more scalable.

-M= SK
--00000000000090419a05abadf233-- From nobody Thu Jul 30 13:44: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 3B9AE3A0CA1 for ; Thu, 30 Jul 2020 13:44:44 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 dbrWcA4arVav for ; Thu, 30 Jul 2020 13:44:42 -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 D98063A0CA0 for ; Thu, 30 Jul 2020 13:44:42 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEA00K93UXYNAA0@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 30 Jul 2020 15:44:23 -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.7.30.203317, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.66.41] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J8YeutVktqRXztTDmr46OVE/xPaKtksHlv3piG1I92rvknBHrtdo0UPeOl09HphlrUG54e3E4u6PQIsqQK56tRbj3b/NNcJDU9hFMUSsHJHpBG32LkU1sZ/tBhouqgE4lHyZdGyiTb262pQDlrbVja1D/MHuwE28QylzX2h3fX5W5dzvh9IXUk06diuQsk4h7aE4g2INvUMIAHasvA279/iVImQNS73iWilD9Hj7bQBEqTO+SFIubB+3z4EFJdiJ9Y5gncu+igyS05UF5EyMcTkAQOd6uAhHg++ZkBDsz+Me1Xtsx/Z1UZl+XMKgSnqqINOovvXxRgTMjkqfhb5YcA== 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=WaaydHt5BeEBmjiFsMBX/q3g3Fu4FDQNwN8Y1L92wvY=; b=XkQ0TjWDj2/+Z64iOWN7aKiaL69/tFXVc86KJrFyQBMUcymvCIUqSOkA22KsowQDQBMkpdLy/oUoehIEQE+0ZpvuZ6hZ/JVljET0fPW8B7D/+Ox18eeHtpXESzvrPDeZRLymQKiB6zAOb/QU7A7yxG1de7f8s+yjgj0XXxUU8Z/jaFXOjDpE88O5BF0gFqgYeSKto3s8LUDu5pjZdGtVTNARU28BSzf8pTCp9OI6r7fLjW27J2I+IdC33EyncjedWTIyv3mAdRS52bbAlr2Qaw4E4aQ3SMN/UmqjZheCYgsO/vMMvQvaZ2QfILgmbCLLVeXetHcX4/z9LqSbhJl8Vg== 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=WaaydHt5BeEBmjiFsMBX/q3g3Fu4FDQNwN8Y1L92wvY=; b=hR4XZvaOq1pWc9jVQqPtpZdjN7IRQN6hRS+Z5K2i8vnMpILVTS3Vc0IiNugg3/bclZXjaE4vvzYSBMLXSdK+6uxYvzwKHjdDfi9Ei5oOxxZ9RmeTjMoVkb7/wmbvD3rvXUQFn6uC1h70PM21q5PsIMYSj6eSf4mU5HKDgwBlB6w= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR0601MB3670.namprd06.prod.outlook.com (2603:10b6:4:78::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Thu, 30 Jul 2020 20:44:22 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Thu, 30 Jul 2020 20:44:22 +0000 To: superuser@gmail.com Cc: IETF DMARC WG References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> <542c8309-de14-330a-cfe9-26a03191dc84@wisc.edu> From: Jesse Thompson Message-id: Date: Thu, 30 Jul 2020 15:44:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR12CA0003.namprd12.prod.outlook.com (2603:10b6:610:57::13) 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 CH2PR12CA0003.namprd12.prod.outlook.com (2603:10b6:610:57::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Thu, 30 Jul 2020 20:44:21 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7f086bfb-542f-4727-b26d-08d834c95690 X-MS-TrafficTypeDiagnostic: DM5PR0601MB3670: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uztFc7YooDPTuvzMYYAL1wa+Ai13SvZK0WIyNEXJE6isHU5V4COHv7sqPikQRxgJvci0Ta0yOPMxpThx6aFob/1D6dymvI4NT9pNFiXre5Z+XkRlQ1JNkyc12zNMaUpSy4qW/ZyvoBfSITN5RILl5m6U1C9JQkvdsiRc5c275BL9A67Y2BksdWv2d41WHNPfXEe/CG/cm77WIYnKFxcTEDB9MtQ4Hj9DU/4BdxgvUYy1ab0cmXIElzYb0fRCjEyrfUsiyTDKRKDpw6p/bTJ0QFGEj28p9vMV1Rk9LAROgUrgzAKlErbMwbic2oVu1MIng/kzVCBqI0Amg1DIPah2TOnI6BEq0X2gmlEfHcstzm8LyXpsCB/r5TIgOdDeBiiopN/QHg0No7mETNGkYn5eqcTPPnQO2DOxwIN3IrIxmJ5xU1/VAJSSoOKteN3bGcOr 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; SFTY:; SFS:(136003)(366004)(39860400002)(376002)(396003)(346002)(66476007)(478600001)(36756003)(4326008)(66556008)(26005)(44832011)(31686004)(66946007)(8676002)(6916009)(53546011)(186003)(5660300002)(2906002)(316002)(86362001)(8936002)(16576012)(75432002)(31696002)(6486002)(2616005)(956004)(16526019)(786003)(4744005)(130980200001)(43740500002)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: YIFJbSoKjchTSSTDRhZ4VPiCKv00x4yg6DCIUJmoPc6q4rGiheukyH7JSEk/bIkdmiGd1ubnieE4Krzj5p+7UpuqUGG+Vh5b6hRFOthe7dpEO+wwhYJLAqV7Cc1AaAtRArw8Bv7lWXhHlLMltqS5OxKt8ewjYJLrCXqnV2YfEB9FMeDCjW1K1cMxMJqDiK7XldPSBy8rdhW4nbnTrk3dqsn3DjftKB4bfRLxOiUDkMlUhFkjEigdQghGLpVn6x9pnK/VmRfc/Xm+e+Z2gGqeOH32ynd+vBsfLxER+I8Zli7gUPKXj2hYSp93yIKLcpxjPWBbx4/7C8t30n/tynFYzKFmhJ2Y6wyqbVApzExUr/UysjxiaBsBFijfPL6RA/6vnNHcanzarB4FLMkrc1D89xXdWI1oSicqIEpyZyT8L4x1N9wt1UODJn4ccjtqIlGHStKbgqSq2bJaOiHZQvh9IpOF1ypKZqbq4ygI5hZPwd8= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 7f086bfb-542f-4727-b26d-08d834c95690 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2020 20:44:22.1417 (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: UySNawHmAusJ3zVjSr7VDSJaoR7XXUvCQG/GRKNnhuO3btf/ie0MENwSlFvqy0tQt872oagAnND+xhgC1avxAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0601MB3670 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:44:44 -0000 On 7/30/20 2:47 PM, superuser@gmail.com wrote: > Translated into IETF-ese: "I have not read your document but I do have an opinion about it..."   ;-) Yeah, Dave sent me that feedback too. I was just trying to make it clear that I only have $0.02 to give, rather than trying to sound like I'm an expert on ATSP. I'll avoid the cliche next time. From nobody Thu Jul 30 13:46:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943153A0CF0 for ; Thu, 30 Jul 2020 13:46:43 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tgq3ZnjW_Ovb for ; Thu, 30 Jul 2020 13:46:42 -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 4C4A53A0CB4 for ; Thu, 30 Jul 2020 13:46:41 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2170.outbound.protection.outlook.com [104.47.58.170]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEA01K1WV1SORB0@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 30 Jul 2020 15:46:40 -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.7.30.203917, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.58.170] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WJGGw6/v1pxm6VAjjlu8YI/gr8hU/Ik3uJzuHtQ+7Kf4SnZPHO8JXYJWaCUTWxM9bSR0evcDx496xwCiF4SJnRgS1IH3qgTqTqcq0S3/TCLEYlEFPQ1PpkdyDdksfU+cPiEYzoB41jW+Yqoe7Afy34AMYGvp8SPCYZvFSeiWlYPKBhMDYus1qZ+ugrveJb46keBm8AqOAHLLLHJdEQZtsAFjvozI6VG7ywqmfFR8nrQtkE1I8zo+ttTvhf1rnIeFyrBwVwxZAjPb3D68bUY3JDK4EK+uP31SqjMP70eM1IEZLSurhQ/zAvGHoX2csh2o0F8w0DM30KvJ2tLcQKWLcA== 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=TQSR6wgpfmuSQJ9b9t/MpMKCMv0WwFCFQdkpDgAQPgs=; b=ed7nAg/N41vmp8PSd63yX1nY5xE8ZJgpX0qUPbQ/u2P262r7e0/Cs1RHDU/YcHQ9ByGrmMHs9f/fYSUOC7IbcwGP1vFYLPDAfFLZYq0qVlBsVLvK3BqFrFPR9+CDoYO/mLht7yAqWM+mR1liFQlE/QexjOlBdv6iVucO5Fmr7g+5wgdAYhQ7sL8Wue8+mn7w0MdbJfP78Yt6TWksj0FI+TE3HnWo2CEW08FJ/aIJxAnY2xfmiczSgRta3t8vefC+u1r+4fnFmOPSdcFKrxDUf8KgQcGAfQFdmRQKf/Ieo00gOWJQI/LU8bsYSzXaeQeMP9l7NOEJJIGrIyHfaIsFtw== 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=TQSR6wgpfmuSQJ9b9t/MpMKCMv0WwFCFQdkpDgAQPgs=; b=DHvNuEJYvXuHZMUN5obz7/buRXlFG0DsT6DIeeoWzMK0AWJdtAa85sc2VWWClUWKhkj2kCDc2wyyly9icuPGFJLSZI2Rfwp9lZZgJds3JbrypefbxStbIcJiGheX+HzK63VfHLKkvrlcex2K5DEBC5912yuYBqnd+8kW13NEIKo= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4426.namprd06.prod.outlook.com (2603:10b6:5:25::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Thu, 30 Jul 2020 20:46:39 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Thu, 30 Jul 2020 20:46:39 +0000 To: superuser@gmail.com Cc: IETF DMARC WG References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> <542c8309-de14-330a-cfe9-26a03191dc84@wisc.edu> From: Jesse Thompson Message-id: <27fc7dc6-2912-e5db-8019-d7dee8ec64bf@wisc.edu> Date: Thu, 30 Jul 2020 15:46:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR10CA0015.namprd10.prod.outlook.com (2603:10b6:610:4c::25) 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 CH2PR10CA0015.namprd10.prod.outlook.com (2603:10b6:610:4c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.19 via Frontend Transport; Thu, 30 Jul 2020 20:46:38 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1ad24f05-a98c-42a0-c0a3-08d834c9a86f X-MS-TrafficTypeDiagnostic: DM6PR06MB4426: 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: vAXpN2cJSUx916820OQgzCmtocbzyH2jImHs8reYZZEdeoZ7Fq2KoKXTVZOGpRSpBL3hBKo1Ee+Q++ZlsR496vqoymdIFPPWbHZcPlROicc5mLSlz5oVGrNKqOwlfkxPyjbLImSBykfyozsmYCnON6hII1niYDIpZrh26Ho3ALQwLPgPnAsJ2Kyod6mcjd0JskCWkJ8fy9MTNeLX0zuF01JjzU6R3NfZHt7/hlmRXoe9wpnwgAodGNfB3QFTsE1JUFM1X49xEJ7jAUIzfOV5Ml4Frl1di37tE1dWF8wQWSfstyNMsqGQCqvJXOpZ2r+XmlLTtZgXMGIgtkeoUlk3AAla9yXiGWGRadgGIXsXHWM+smsNlOwbcGenA9KjebNPxWD4HsIdMOasw3ZSqHX8bwaXQafo/K9Osb7x+VR6pZV8KVBRDbIF12e0sR4wFC7o 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; SFTY:; SFS:(366004)(396003)(376002)(39860400002)(346002)(136003)(53546011)(31696002)(16526019)(36756003)(83380400001)(66476007)(8936002)(66556008)(66574015)(66946007)(26005)(5660300002)(786003)(86362001)(316002)(16576012)(186003)(31686004)(75432002)(8676002)(2616005)(956004)(44832011)(4744005)(2906002)(6486002)(4326008)(6916009)(478600001)(43740500002)(223123001)(130980200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: chNto3nntedCZ4FfPiiHG8Kg4XebnWrRch5coTqQiTGE5fanr4oeWUEcVaUPP5zgpitBJ0rxievPIYwPRYJo/3APmRcD6TkMbrKDiERZR+AwiIreg2ZUSm4s+O/9eNOm9ZKz41n3jNZjgxUmW+NmC1lNETTisNagIaYIV+in4NPCSazy3yEEWMU3YE+HDo6K7KLSq+TtSkA2LJ2WgLGTpKmZsMiE2sSZ5JJ3qdoW42BqOV6QZFYJ7LNHvNA0B8FcyDKHWySdfOynrA6LZT0ewWWp8plzox1uqUiHoyYEtjHCJFxICjCZr8whVWx4kHwMwAxgF0TE5VjdzjFsDDALFx8t3gNHOV/bSPivHcOQClC3TreaW3jInJhE11LWqzKUPyfaC+lIaQH0aC3boNgEiZMxfgdlqHlQYReUH+VbT60nrZ54sdLYqGRUz3gXov3AW1NPx2Di8olM/qW2kQ/JOYA6Vy3CL2guLbPt/yPnouPEZACYwpGQzrwvDC88qtJlWSYwl1TfLh2t1EDZU0H8huMtkrUATIT9uEv5jvhW0xsNQ3vt1MWWg7Mca/CfW7Du6h0qOBHUhkRvAnEFjOI8pZgcjpgGQxC/idiJ4IORMhiMIlHPM3GjB3e4oiEWd0UGHyb1UxKSwnhw+WnjsZ1OKg== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 1ad24f05-a98c-42a0-c0a3-08d834c9a86f X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2020 20:46:39.3591 (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: LHBmsxyQ3eda50BiqVvdRGihxVxr35U4PtYmTbULpxXoQ6TGky9MWuC9norP17MTKtovYV3hyVIH0Mlib1DZFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4426 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 20:46:49 -0000 On 7/30/20 2:47 PM, superuser@gmail.com wrote: > Email domains that have more than a few users don't want to authorize every potential 3rd party (converges quickly to all of them, for large/complex organizations) to sign as every user/address in the domain.  Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put every 3rd party into our domains' SPF records.  I'd essentially be authorizing most of the [legitimate] internet to use the domains. > > > Yes, it has this scaling problem.  Had it been shown to be effective at dealing with the indirect mail flows issues that DMARC forced to be front-and-center a few years later, I imagine we could've revised ATPS to be more scalable. I almost suggested that an address-level authorization mechanism would be useful, but that seems un-scalable for manageability reasons. Jesse From nobody Thu Jul 30 15:53: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 CC61D3A0C6C for ; Thu, 30 Jul 2020 15:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK6N0ODvMugz for ; Thu, 30 Jul 2020 15:53:05 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88103A0AEE for ; Thu, 30 Jul 2020 15:53:05 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:b4e8:628f:2119:e45a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06UMr3id016674 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 30 Jul 2020 15:53:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1596149585; bh=eaTQ1VCAYW1esjd++FCGR8sUCc63ap/w0EPYv+HHMtA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T+vkUelEKsgVLAHo1qFatBNwl1GUDcmGMX4uPr/GYKm4tShjODz9+7m7+vjN6/VIW 9O7LgBDSYQr+ismNUZGcfOyQH3TBeu9uT4VUHh/EJCsQeQw8KWCt4DNhktVtD4HT2u 7889qc3YELJkrru1uxBZOzqKNWWAFHWC4wqKfDc0= To: dmarc@ietf.org References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Thu, 30 Jul 2020 15:52:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 22:53:08 -0000 On 7/28/20 2:07 AM, Laura Atkins wrote: > The underlying belief with DMARC is that mail is simple, that > companies are monoliths with only a few brands/domains, that it is > possible to know exactly where every message will come from. These > assumptions are not and have never been true. Inevitably, however, > when these types of issues are pointed out, they=E2=80=99re dismissed w= ith > =E2=80=9Csolutions=E2=80=9D that aren=E2=80=99t actually achievable or = maintainable. DMARC > proponents have repeatedly failed to pay attention to folks pointing > out the actual operational challenges and thus have never addressed > the issues in any way. This is, fundamentally, why only 15% of fortune > 500 companies have adopted p=3Dreject and why adoption rates are only > increased by 5% last year.=C2=A0 > > The indirect mail stream issue is real. But it is not the only barrier > to getting to p=3Dreject. The sooner folks start listening to the peopl= e > who are presenting real issues where DMARC alignment can=E2=80=99t be a= chieved > the sooner they=E2=80=99ll be able to address them. The problem with lo= w DMARC > adoption is that it does not adequately address how companies are > using mail in ways that break the DMARC model. Almost a decade on, and > proponents are still suggesting that email usage should change to > comply with their model of how email works. This has not happened. > Maybe proponents need to think harder about why.=C2=A0 There's an underlying assumption here that I don't agree with: that DMARC adoption equates to the publication of a p=3Dreject DMARC policy, and that everyone (or at least all Fortune 500 companies) should be doing that. p=3Dreject should only be used when the usage patterns of the= domain support that policy. I'm more inclined to say that 85% of Fortune 500 companies are savvy enough not to publish a policy that doesn't fit their usage patterns. As RFC 7489 says, "DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions)." If the statistic were instead, "only 15% of domains used exclusively for transactional email publish p=3Dreject," I'd agree that's= a statistic that should be improved. -Jim From nobody Thu Jul 30 18:02: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 1C0393A093A for ; Thu, 30 Jul 2020 18:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 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, FROM_SUSPICIOUS_NTLD=0.499, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_IADB_DK=-0.095, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_RDNS=-0.235, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.059, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lem.click Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twoiJmCsLM05 for ; Thu, 30 Jul 2020 18:02:00 -0700 (PDT) Received: from libertad.link (ns1.libertad.link [192.241.161.190]) (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 A94B63A0870 for ; Thu, 30 Jul 2020 18:01:59 -0700 (PDT) X-Virus-Scanned: FWTK at libertad.link Authentication-Results: libertad.link; spf=softfail (domain owner discourages use of this host) smtp.mailfrom=lem.click (client-ip=70.181.75.239; helo=ip70-181-75-239.oc.oc.cox.net; envelope-from=dmarc-ietf.org@lem.click; receiver=) Received: from [192.168.1.61] (ip70-181-75-239.oc.oc.cox.net [70.181.75.239]) (authenticated bits=0) by libertad.link (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06V11tZZ021020 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jul 2020 01:01:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lem.click; s=s1; t=1596157317; bh=5WjZwP9eEpmgETJzqtv5VYidinWpEarW9glP9t1qoOA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZHcua0sturnvq5C7EuxVAETPHAwy3lR9XgRm7tIxWc8zau9I7WjOTtP/Xy4glXsNF iPwnwpEtiKvnydomVwOWHLQzTqfpFPlAWJCR7k2kp16E6SL7uiXCdk54Vz5yTqo3/n K8YEkGQ4CZb6PeGTDowzzTkloeON2ireeSBwAsXI= From: "Luis E. =?utf-8?q?Mu=C3=B1oz?=" To: dmarc@ietf.org Date: Thu, 30 Jul 2020 18:01:54 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: <95C85860-4C8E-4593-90B1-C9800D919E05@lem.click> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0C244EFD-B2A8-4BBA-B6E2-57415B9E1B7D_=" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 01:02:10 -0000 --=_MailMate_0C244EFD-B2A8-4BBA-B6E2-57415B9E1B7D_= Content-Type: text/plain; format=flowed; markup=markdown On 30 Jul 2020, at 15:52, Jim Fenton wrote: > There's an underlying assumption here that I don't agree with: that > DMARC adoption equates to the publication of a p=reject DMARC policy, > and that everyone (or at least all Fortune 500 companies) should be > doing that. p=reject should only be used when the usage patterns of > the > domain support that policy. I'm more inclined to say that 85% of > Fortune > 500 companies are savvy enough not to publish a policy that doesn't > fit > their usage patterns. I am currently observing ~215.5 million domain names. Out of those, ~64 million have a seemingly _valid_ SPF record and ~113 million with at least one MX record. This is a current breakdown of the (valid) DMARC records I am observing over the general domain population above. This amounts to an adoption rate of ~1.7%. | p | count | | :--------- | ------: | | none | 2715614 | | quarantine | 238584 | | reject | 726045 | It is interesting that roughly half of those are not taking advantage of the reporting. Here are the counts for those with neither `rua=` nor `ruf=` in the DMARC records: | p | count | | :--------- | ------: | | none | 1092990 | | quarantine | 107767 | | reject | 307614 | I do not have a definitive list of Fortune 500 domain names, but I compile a rolling list of domain names with most traffic using multiple sources, which currently holds ~1.8 million unique domain names. The breakdown of DMARC records from that high-traffic population is shown below, and it amounts to about 6.3%. | p | count | | :--------- | ----: | | none | 79367 | | quarantine | 18094 | | reject | 15875 | For completeness, here is the same report, counting only those that have neither `rua=` nor `ruf=` in the DMARC record. The ratio of _silent_ `p=quarantine` and `p=reject` seems around half as in the case of the general population. | p | count | | :--------- | ----: | | none | 32561 | | quarantine | 4534 | | reject | 2760 | It would seem that those high-traffic domains are ~5x more likely to adopt DMARC. To me, these numbers speaks of thoughtful and deliberate deployment that outpaces the general domain name registrations. That said, I cannot claim whether the list of high-traffic domains is actually a good proxy for the domain portfolio of the Fortune 500 companies. Best regards -lem --=_MailMate_0C244EFD-B2A8-4BBA-B6E2-57415B9E1B7D_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 30 Jul 2020, at 15:52, Jim Fenton wrote:

There's an underlying assumption here that I don't agree = with: that
DMARC adoption equates to the publication of a p=3Dreject DMARC policy, and that everyone (or at least all Fortune 500 companies) should be
doing that. p=3Dreject should only be used when the usage patterns of the=
domain support that policy. I'm more inclined to say that 85% of Fortune<= br> 500 companies are savvy enough not to publish a policy that doesn't fit their usage patterns.

I am currently observing ~215.5 million domain names. Out= of those, ~64
million have a seemingly valid SPF record and ~113 million with= at least one MX record.

This is a current breakdown of the (valid) DMARC records = I am observing over the general domain population above. This amounts to = an adoption rate of ~1.7%.

p count
none 27= 15614
quarantine 23= 8584
reject 72= 6045

It is interesting that roughly half of those are not taki= ng advantage of the reporting. Here are the counts for those with neither= rua=3D nor ruf=3D in the DMARC records:

p count
none 10= 92990
quarantine 10= 7767
reject 30= 7614

I do not have a definitive list of Fortune 500 domain nam= es, but I compile a rolling list of domain names with most traffic using = multiple sources, which currently holds ~1.8 million unique domain names.=

The breakdown of DMARC records from that high-traffic pop= ulation is shown below, and it amounts to about 6.3%.

p count
none 79= 367
quarantine 18= 094
reject 15= 875

For completeness, here is the same report, counting only = those that have neither rua=3D nor ruf=3D in th= e DMARC record. The ratio of silent p=3Dquarantine = and p=3Dreject seems around half as in the case of the gener= al population.

p count
none 32= 561
quarantine 45= 34
reject 27= 60

It would seem that those high-traffic domains are ~5x mor= e likely to adopt DMARC. To me, these numbers speaks of thoughtful and de= liberate deployment that outpaces the general domain name registrations.<= /p>

That said, I cannot claim whether the list of high-traffi= c domains is actually a good proxy for the domain portfolio of the Fortun= e 500 companies.

Best regards

-lem

--=_MailMate_0C244EFD-B2A8-4BBA-B6E2-57415B9E1B7D_=-- From nobody Fri Jul 31 01:06: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 B97CA3A106E for ; Fri, 31 Jul 2020 01:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SPOOF_COM2COM=0.001, SPOOF_COM2OTH=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 xqRtoozNR4eu for ; Fri, 31 Jul 2020 01:06:08 -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 DB0C63A106D for ; Fri, 31 Jul 2020 01:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596182764; bh=QFzdVyTU8wvEK9Hzou87FRi6Babr3XuF9KATWFsoSIk=; l=3003; h=To:References:From:Date:In-Reply-To; b=AyDLw/mbvL62tv1teIuNxGjmnnNeEwvAx4/ypK3+YkE49ClNhZWugabfjeBxf8BGg D1N5+USTNsRsFJMVwJHTRUGUyrAXtCoS6Z7RYx+o/pULFxcDRfgVn4EyaEWEOtbXBZ PY6vgbAmjkcyZb5cC0gEkRGDiWUO7ydqMl9/9UxYQFm3MuH6Jrr6PjKI3JA1a 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.000000005F23D0EC.0000519F; Fri, 31 Jul 2020 10:06:04 +0200 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> From: Alessandro Vesely Message-ID: <5d3dc8f8-2b89-54df-7698-b5c2ab341ab9@tana.it> Date: Fri, 31 Jul 2020 10:06:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F21B338.8000700@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 08:06:10 -0000 On Wed 29/Jul/2020 19:34:48 +0200 Hector Santos wrote: > On 7/28/2020 1:19 PM, Doug Foster wrote: >> Hector, I do not understand this comment: >> >> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party >> domains. DMARC did not address the problem and reason ADSP was abandoned. >> Hence the on-going dilemma." >> > > [...] > > We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a > deterministic method to associate the author domain with 3rd party signer > domains.   This authorization is defined by the Originating, Author Domain. > > Look at my DMARC record for my isdg.net domain: > > v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; > ruf=mailto:dmarc-ruf@isdg.net; > > The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain > signature: > >   Author Domain IS NOT EQUAL TO Signer Domain > > Then it can do a ATPS look: > >    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net > > So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I > would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your > domain in the list of authorized signers, click Zone Record and I get a record > I can add to my isdg.net zone: > > e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; d=bayviewphysicians.com;") > > So anyone out there can see that I authorized bayviewphysicians.com to sign for > isdg.net Isn't that overly complicated? Why SHA1? An alternative method to authorize 3rd parties is RHSWLs, see my previous post[*]. By comparison with the above quote, assume we have: From: someone@example.com Sender: auto@example.net The DMARC record at example.com: v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:rua@example.com; The snd=lst.rhswl.example tells a compliant receiver that if it sees a 3rd party authentication (either SPF or DKIM) of the Sender domain:, where: From: domain IS NOT EQUAL TO Sender: domain Then it can do a right-hand side whitelist lookup: example.net.lst.rhswl.example If the record exists, then example.net is authorized to send on behalf of example.com. Features: * Absence of cryptographic stuff (sha1) makes it simpler. * A multi-domain bank (Autumn's example) can easily build its own RHSWL containing all and only their domains, e.g.: firstbrand.com.lst.mainbrand.com IN A 127.0.0.2 secondbrand.com.lst.mainbrand.com IN A 127.0.0.2 * Large free-email domains can build their own RHSWL so as to avoid the MLM problem. * Lazy mail domains can easily point to a public RHSWL which lists almost all the legitimate Internet. * Strictly transactional domains can still keep snd=none (the default). * Experimenting domains can have p=none; snd=lst.in-progress.example; while they monitor aggregate reports to see how their list is doing. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/jQlUhE-ijiWeb1CybKy6367eVn8 From nobody Fri Jul 31 09:58:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A093A09EF for ; Fri, 31 Jul 2020 09:57:59 -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, SPF_PASS=-0.001, SPOOF_COM2COM=0.001, SPOOF_COM2OTH=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=jECG7PVE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=MLfgTVhc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5fSzpFKhEI3 for ; Fri, 31 Jul 2020 09:57:56 -0700 (PDT) Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEA93A090B for ; Fri, 31 Jul 2020 09:57:55 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3965; t=1596214667; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=QFOdK8yL8x/7yZa9YrwPQjWESDo=; b=jECG7PVEttQU1d8hNb7jELeJg9A8MH5gKqGHSCVibf5k+ztdwvQG+hxTPSjviO /qlD+AN0exXBD4CZSt3oXI2oG2BifLfyp41+GcEjeyNHT3j6N7YyDsjiRlw1Xmyb kk9HiaOByZLpULT6aNF08BdLbaQg3SVfmS/oHA+Jv2aUc= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 31 Jul 2020 12:57:47 -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 2646957274.1.4280; Fri, 31 Jul 2020 12:57:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3965; t=1596214552; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=10iV7rW kslISePbVapDWVGooGxNf8LEVdETeALJFtIc=; b=MLfgTVhcV4VHjwUoUIBwyPT oaPWFllHlBeLE6L9x6abHmQBG/T2uwf0U1FM7X5xpJKP3G3g6ArAKA4LZs3i+cai pOFUUx2pMgKfLvn5s5HMua2jIDcgfD+QrGQFlgEDJj7mNitR9/TIOjCBhZHk+obw /AjVnC9e3/TfnGFnKObE= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Fri, 31 Jul 2020 12:55:52 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2357727109.1.62476; Fri, 31 Jul 2020 12:55:51 -0400 Message-ID: <5F244D90.4040201@isdg.net> Date: Fri, 31 Jul 2020 12:57:52 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5F204CB3.7080404@isdg.net> <000001d66503$4d447e50$e7cd7af0$@bayviewphysicians.com> <5F21B338.8000700@isdg.net> <5d3dc8f8-2b89-54df-7698-b5c2ab341ab9@tana.it> In-Reply-To: <5d3dc8f8-2b89-54df-7698-b5c2ab341ab9@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] LSAP - Lightweight Signer Authorization Protocol methodology X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 16:57:59 -0000 On 7/31/2020 4:06 AM, Alessandro Vesely wrote: >> hector wrote: >> >> base32(sha1(SIGNER-DOMAIN))._atps.isdg.net > Isn't that overly complicated? I don't think so, but sure, it is not 100% "Low Code." A hash "calculator" is needed. > Why SHA1? The intent was for a lightweight hashing that won't produce long hashing tags or labels or subdomains. Whats the maximum length of a domain? But mainly because Murray's ATPS was based off Doug Otis's TPA-LABEL which used the same hashing algorithm. DKIM Third-Party Authorization Label https://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 Doug provided a portable C-based TPA-Label calculator source code in Appendix B. ATPS was the "simpler" version of TPA-Label. TPA-label was a little complex for a period when it was extremely challenging in the DKIM WG to get a Author::Signer relationship endorsed. Remember, we were dealing with push back even the 1st party DNS lookup policy. There was general agreement TPA-Label offer more scalability. ATPS was just simpler to plug and play, explore and test the proof of concept and that it did. > An alternative method to authorize 3rd parties is RHSWLs, Let me (re)state I believe in a "Black Box" functional design and engineering. I am not stuck on ATPS. It is about the functional methodology for an Author::Signer association, a "Lightweight Signer Authorization Protocol" or LSAP. We had the same with LMAP "Lightweight MTA Authorization Protocol." Maybe LSAP can do for DMARC, what LMAP did for SPF. But imo, we need to get consensus with a LSAP methodology. With consensus, a specific method can be worked out. > see my previous post[*]. By > comparison with the above quote, assume we have: > > From: someone@example.com > Sender: auto@example.net > > The DMARC record at example.com: > > v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:rua@example.com; > > The snd=lst.rhswl.example tells a compliant receiver that if it sees a > 3rd party authentication (either SPF or DKIM) of the Sender domain:, > where: > > From: domain IS NOT EQUAL TO Sender: domain > > Then it can do a right-hand side whitelist lookup: > > example.net.lst.rhswl.example > > If the record exists, then example.net is authorized to send on behalf > of example.com. Sure, again, imo, we need a BLACK BOX "LSAP" methodology to be work out. see below. > Features: > > * Absence of cryptographic stuff (sha1) makes it simpler. > > * A multi-domain bank (Autumn's example) can easily build its own > RHSWL containing all and only their domains, e.g.: > > firstbrand.com.lst.mainbrand.com IN A 127.0.0.2 > secondbrand.com.lst.mainbrand.com IN A 127.0.0.2 > > * Large free-email domains can build their own RHSWL so as to avoid > the MLM problem. > > * Lazy mail domains can easily point to a public RHSWL which lists > almost all the legitimate Internet. > > * Strictly transactional domains can still keep snd=none (the default). > > * Experimenting domains can have p=none; snd=lst.in-progress.example; > while they monitor aggregate reports to see how their list is doing. Do you have a I-D? If not, why not write up the draft proposal so it can better reviewed and maybe even explored? Based on discussions, it sounds this LSAP model would include author, signer, sender identities: Authorized := LSAP(Author, Signer, Sender) This was the same idea with LMAP for SPF. Authorized := LMAP(IP, Domain) In SPF, the LMAP function is called Check_Host() with arguments: - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Jul 31 11:11:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061FF3A0C27 for ; Fri, 31 Jul 2020 11:11:05 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Gd2kjvcoWtOC for ; Fri, 31 Jul 2020 11:11:02 -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 3B9FD3A0C25 for ; Fri, 31 Jul 2020 11:11:01 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2105.outbound.protection.outlook.com [104.47.58.105]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEC05OFGIIC1820@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 31 Jul 2020 13:11:01 -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.7.31.180017, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.58.105] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GgHPbm+Y4j7L4ug77reKAqop09xtlsN2PHaxyJw+UbeCIErYdWby9rEysESJyu2FUUi7qsMeCnaW+w0JQuGSQOPWfoffN+5EtIQ2ciZbD2sEpkAaiN4+vBdCLhPrrK/Izd75CQvE+L9SRizSyYmqi/JoCT2oKIsWH7yTUqmKrVnhvt+RFPR9HmT1aMsypu4bS2gdc672mQugyfxH5/R2qlAEAXdgt8SQKOXqY7a9V9TaEaCbmrjlQV5WN9R9z6eSNYPhhfY9NHWmqisePnfpY0WYq3K1OCdEp80zVkXuSxs3uVoAfRQI/TnG2r/QVksU5mkeBrCkMWLW6xR3iur6gg== 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=A5HQkQCiYfRuCsYiB/7TYJBsutcRNqCR9KE+JMXy9YI=; b=f0betLt/ZN3ORnmi3vL76HvQn9dV8l2peWvxtsfpL4kB5RSTHqvw8iymbA4CrqB6PbAjQaLSblF0UJRex3o372M3FkWMkAVbMRh6DDJSW7LX+4/pqw3FJ+B4Ga+/WQSk1qveOGet8BOEZ166MR19wBTjN22nvpzwub/jL7LqIy9tHpSAdwCk3M4SHZfzmoeUzmgVCDAAJ+Jxt60qi7nA7Ihw2ob2L0WIdL8xDXnptIxBqAhCd6xM8npgER6GW7W47hdvt8Dcxbiaf46SdMheLjYRqa4YJBBykMIqmLucLCKaH4ASeLCxaRYXVa0f7OYlN8OJjUMSMDDQrgK9II7KSA== 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=A5HQkQCiYfRuCsYiB/7TYJBsutcRNqCR9KE+JMXy9YI=; b=pfYUKO2N+ZcTRgYHGWL4tkEiFpfGGEuPpIVsYhGHVO5+8dAVuJn+qhUHt+uB/pZrGAfviAuA4ATBw4f5aJfHrCUtLlIwrrSF4Ab0y8RKhzx7ZElnYWRtJDBX2WpkQ0ILHUJsSaUfBVNv0LjMYMzrldMbXFoPdCRM8wAUx0DwpA8= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB3259.namprd06.prod.outlook.com (2603:10b6:4:3e::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Fri, 31 Jul 2020 18:11:00 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Fri, 31 Jul 2020 18:11:00 +0000 To: dmarc@ietf.org References: From: Jesse Thompson Message-id: Date: Fri, 31 Jul 2020 13:10:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR07CA0032.namprd07.prod.outlook.com (2603:10b6:610:20::45) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR07CA0032.namprd07.prod.outlook.com (2603:10b6:610:20::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.18 via Frontend Transport; Fri, 31 Jul 2020 18:10:59 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: cbb8c1a4-b946-4f10-cb17-08d8357d143a X-MS-TrafficTypeDiagnostic: DM5PR06MB3259: 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: OPiST3wyHW4g0uSDEEPRV49F8CoLYTJkhyj4tNr9tb+Mxffx54zuZ0Lcj+IuOSYGScgNo8qHASOZLCC8JcbiA7V1mZZRZJi6cT3gCm7+8FFbgnzarsJo4Zu2TXhW97BkciewAvSy+zwh0PRNDluqhObfPvm1TLpZKFKKWoUfYMiMGTpNSXdnKJ436gxnaD1S+LcYjwfsvTYjmDmCJv/3hUcd2gxvTqktdHBBdn99rTIB2bnIPF8Uznu/u1Hww/9FCQrxz6SvICGNTsb3nab1equntyG5neRONU5TsqMRAjKyS1ggvxvxgNlwz3+tUElolUtNoRSdrG1kYo+FyMpV7itsFHaU77Je7tLv+pAs1jprUC4XxnShobAJZBsQt+4Kproyc9nwQtIPbts5ECjeGaTzZuwihrqgHu7IOYmfw/DR9AhD3cNZHAbz1YDT1+hBYM3LNkFcgBv2NpumCPTptLvx8Sba0Tv9MgjLjJHjaNo= 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; SFTY:; SFS:(396003)(346002)(376002)(39860400002)(136003)(366004)(44832011)(316002)(786003)(53546011)(16526019)(16576012)(2616005)(26005)(8676002)(956004)(31686004)(36756003)(6486002)(186003)(75432002)(8936002)(2906002)(6916009)(4744005)(5660300002)(6706004)(66556008)(66476007)(66946007)(478600001)(31696002)(86362001)(3940600001)(130980200001)(223123001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: pFi6PZAEy9utrhgREUXSOyKPTHGO6pswiFbVY1PE+TEd7Ck9HfCW7zUuIiznTL63N0J4rBxUlaeRFjfK2ZyuJJ3Ojxo+eTLxwaDukyaU/8XRipq+TRXRb3zt5YTew7li8wkaEmzgjPuSJmVA7iuQ7I5QFvA+R4dG7D2j71Kfs+h4n2h2WcRUxHtHtaVNuR7461/zfZcGtmS2cGbbuB+quK5KO9oFpziEHMd0C9VAHmLu1Kao7qMBtR1TbUE7k+TZkhHLF4jXnApJMZ8s2FqHm3UkVKYoudmD929+QAYY6J0AFWbfmU8v00o23gAiG6KwaVNqToVs8cPnVRFxRvaLHvKjreSuwCJWMC6Cj3YiqzooV8wOkXltE800EEUzwnOBlvdlPZKjKuS6OQYRxqTOAwOXyGbUK7O3MlmLjoUvReuQzcvxZQhYg0bzPvsp7HFCa5qtx3J76qB3p1Q8ihXQ3QEK+tIW2t1sKNiQKEC81ARtlyiCXq4BE7ho13YlA3/k X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: cbb8c1a4-b946-4f10-cb17-08d8357d143a X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2020 18:11:00.0576 (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: +0SWKeIg+2+c90VuNUrNM92SfXc36OFxwGySCIGXYXxbxF4eoSd8dt2tiuF197titKy1DevWJ8RldpM1wSZPew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3259 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 18:11:05 -0000 On 7/30/20 5:52 PM, Jim Fenton wrote: > There's an underlying assumption here that I don't agree with: that > DMARC adoption equates to the publication of a p=reject DMARC policy, > and that everyone (or at least all Fortune 500 companies) should be > doing that. p=reject should only be used when the usage patterns of the > domain support that policy. I'm more inclined to say that 85% of Fortune > 500 companies are savvy enough not to publish a policy that doesn't fit > their usage patterns. I think you're right, and isn't the market indicating that there is demand for DMARC designed for other usage patterns? e.g. Would the CEO of any of those fortune 500 companies like the idea of their personal address being spoofed? Jesse From nobody Fri Jul 31 12:30: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 467263A0816 for ; Fri, 31 Jul 2020 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=a9n6UDxs; dkim=pass (1536-bit key) header.d=taugh.com header.b=qWkpN2pP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_spMrHCd6sD for ; Fri, 31 Jul 2020 12:30:44 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C533A0808 for ; Fri, 31 Jul 2020 12:30:43 -0700 (PDT) Received: (qmail 50677 invoked from network); 31 Jul 2020 19:30:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=c5f3.5f247161.k2007; bh=ch7WQktnRuBiABT6M3N+kTebURJS9pyX4yk4OWAhLFI=; b=a9n6UDxsy6jDFdJBQXpoiwbBBvYMI1Dlw18gPTmGrnBjVdMRmETJVroKaRnDdDA1+WqmSqGizxiLGhE1Sg7mn+tAUq+OSoIl5wF1cSVo82DBjW+kOXAInfkACakZlHaGUrK9wAvLZrIBLYRsi4Vmf3YyFBAFxeLFhEoF6jJ/KjAo8y/mEbwN8jD4dCI5zKz7ZLkwyYMzvuMySYSrhVOwByla2Fq0fsqiAZaY1UzOW6+NPEVlmlm3bS63usV4BXIe 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=c5f3.5f247161.k2007; bh=ch7WQktnRuBiABT6M3N+kTebURJS9pyX4yk4OWAhLFI=; b=qWkpN2pPK9d4TS5B5m1QpTtHrgCnqzHImb0mJYpIjbdkkaZLjJKGxL/Tsj/AVmdMSyl9/7PjiupmABpX0mahxKjZKWBBu35RvM7qvWASBVtzBhkHG5iy7ZVhPvFwuy4XZKCdLdpL8hFJwZ7nDZ6dlgb3EPm9Y/AvA7Kb5u/9jwWiAgFchUDQ5se5DiTxG8urmngV7T2lBCdJiE+CftnKbKf+LrFsseKU4qhieMGsMoOMJt/dPNZUxBGspcc4j2hu 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; 31 Jul 2020 19:30:40 -0000 Received: by ary.qy (Postfix, from userid 501) id AAF8B1DB2410; Fri, 31 Jul 2020 15:30:40 -0400 (EDT) Date: 31 Jul 2020 15:30:40 -0400 Message-Id: <20200731193040.AAF8B1DB2410@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] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:30:46 -0000 In article you write: >I think you're right, and isn't the market indicating that there is demand for DMARC designed for other usage patterns? e.g. >Would the CEO of any of those fortune 500 companies like the idea of their personal address being spoofed? I dunno. Would they like the idea of mail their assistants send out for them being silently discarded because it's falsely tagged as being "spoofed"? R's, John From nobody Fri Jul 31 13:33: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 8A4323A0B74 for ; Fri, 31 Jul 2020 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8mzWy5ZwoSDm for ; Fri, 31 Jul 2020 13:32:35 -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 8AC6E3A0B68 for ; Fri, 31 Jul 2020 13:32:35 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2175.outbound.protection.outlook.com [104.47.57.175]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEC01LRYP29IY30@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 31 Jul 2020 15:32:34 -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.7.31.202717, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.57.175] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eiEo/vRLnkO8dJXkQsckxia6wJqF4zQx8m4nVqAnHQmNCTkuXD57VysFibCeN41rqaTFbL6E0HmtREWUknxPCeY52Jl59deFq5BIh23UibEhFAWNyYjirAdyO6V4z2VI6yMhfoRVoBgry92bD0HNS/morTrCvSMojb3lvKu3v1VbKB1sX68niqzcX5khqrPSwboJER4HuKpXPUjyXm/QcOfPAk2X6NmQF9XsOq4OVqDF3uhXJ0NcMirvbYSYhdY5aFYoHXCK9o0VQF9nSZKqKWxb5iaecwvchbD3Sw7LjcFw4TD4BYv3mXASSvpJi/opIsWwVvNo7fWGGrd84h9/AQ== 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=p4Tft53WzSMxnsgJIdFsDVEnyWfJ8LJ9t+4EiXzqHfQ=; b=I8KQp4WVzHcPxJxPnXRGzevzpPrbBESwnr+PXBaXGD7BHqbgfgF1qaw81oGNx6nWyDNdpmJU4LelgMwUTrSfwu9jJE927FETLD+s3pkFgVluVFK3WvHCjU/0Z1AI9neIrrTs3SO73LPylF0BPU9GLi4v0YMAD2sXVn6Hq3VWWNjqVu87/0JW5dy9tbtQoomjFh9j7w+krb8YByOL6Jrwi2DMk3XOU2mwOBcKPtcy+ZsFX72EqyQsxJSLju5O7LYiBg5UCJEqgQfPsEb2/bR+Yq+laGQyjox+llecznNMuYK5qq4woGctbWfhkETpTr5ENL2/ioQ+9S9x8xB9LPJykA== 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=p4Tft53WzSMxnsgJIdFsDVEnyWfJ8LJ9t+4EiXzqHfQ=; b=EY0HZvWOxvJCmStbXOw9G51DnQUGPcGad9P9PmE8iTfFm0Hss5KU+Vwkuokz3vYFCl/F7sTLV64fReVYtqjA5SNTDTApsEIBgF9Am0e81quni9mf5xzHFvMrUk1PSRVxTI2h/AJwLR4/0ENtuEQa2pTFD5ajNuEup0KiB7vSIt8= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DS7PR06MB6759.namprd06.prod.outlook.com (2603:10b6:5:2d3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Fri, 31 Jul 2020 20:32:33 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Fri, 31 Jul 2020 20:32:33 +0000 To: John Levine , dmarc@ietf.org References: <20200731193040.AAF8B1DB2410@ary.qy> From: Jesse Thompson Message-id: <01c53fdc-342b-e2d3-16dc-f1161913d656@wisc.edu> Date: Fri, 31 Jul 2020 15:32:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: <20200731193040.AAF8B1DB2410@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR07CA0004.namprd07.prod.outlook.com (2603:10b6:610:20::17) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR07CA0004.namprd07.prod.outlook.com (2603:10b6:610:20::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Fri, 31 Jul 2020 20:32:32 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1fea183c-471b-4856-49fe-08d83590da54 X-MS-TrafficTypeDiagnostic: DS7PR06MB6759: 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: VWEh0jjn+GCbVJBl9XQoCf8Dnuz+CffuS93YHZVQ+jTJVfQkynDWlYLt9g4OxXYqWQiJFJZai9N57Vml+rWhXTzPgPvwNNQZ30sZsvKA87TUDBoXNfCJ6BhAqOybDSG6WrTABAUVYiScelc6b9kyWK3oof5RLUyXCFpXEY11mv6m5MZqdPrDp6gWd4WdokQ87YP2OoUmmoD2fvf4WfxCaAavN3T2SEcKgdhWDyzTdpR68nLuZYthIw0nutOD6P4VgmEdJtQPWpIJ1angha92H5frTuITBu4nGjNEJGfEbNaFq4w1rvYIa/Mj3wDYUWxG8M/k0jLgpOe2TEKQVbUZBSGLsvfGbFbqRFOB5KRBrPRd/IfELEDxe/OyE4DueSdEiuOIgBuOtYxVm1ce7gU1a7niae5Dalf/O5wRV2MDRhDmH8bFSyJKtewxxQbxP2eiCHAUYZXs2Ccw9ZuScMIWOoYknUkOGyQ0PiVKHEvioMk= 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; SFTY:; SFS:(396003)(136003)(39860400002)(346002)(376002)(366004)(26005)(2906002)(16526019)(186003)(8936002)(66476007)(53546011)(786003)(66946007)(75432002)(66556008)(478600001)(44832011)(8676002)(86362001)(316002)(16576012)(2616005)(956004)(31696002)(36756003)(5660300002)(31686004)(6486002)(6706004)(3940600001)(43740500002)(130980200001)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: nig4kPqblIRr+m0lVbVCXh3eV7Z4Re+Pywv7DyU0QbS8chZVTE8iXiruwjfbUg5ssCbmkRwO5aa6VkKCyPPgHNQ7i4Q4HT3892GS+dGMFf9yHsCcfD/DvrMax70G5ikfBMjn7mgL88wCGWcN7kkYi5rVZ5Zbo/Y1ovXTwy/jDq7rUfUJJe4E0YX6PyxVOd/YrYOb/Qb7TI2n+nN92VsWQVyngeQLZZTfRHe5chxyYQYzUfx7BGpBcx6rGNdA9aIn5U/i1qNlGN+1BPB5EUw52OFD93TOIpvkxwuQOfM13R2qdqhObhC+hJRZVdq2+mPjMSUmjXQhTjCJCXCVPrN8SWxfDEtZ+pVJTU7kjG+lqxfvvftzpEEaPLPcnl8N4TMrRBGp6qHWj6A9t8BuT0k1yrVS40tOAcFpptSqwZKpssEBCX3SfV9NkTgxV7yXb7GEoYGk36DpYF7yYgOthozBFw/UwkMD2lfzHAJM5qvXQWuRl49duLQM/4jvkh8d97OVW8LzH8UZSnJ+kzJeu60P0QSoDjnleVgxLqCz+t/wly4w/uVyD2dvfVpIKOtdbIg2Der8yFgFuefEFEWkIZM9QokMMzf63UiPujtzzcuQlO918LK9quyTARL1okfafzBvSW6/K5r9c5ryDAAEdxSCRw== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 1fea183c-471b-4856-49fe-08d83590da54 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2020 20:32:33.1292 (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: kFS6yzBINUs8lV+aE4oOLmK5s9eAsFPCX5bMoHMEpJ1Sa3vJPmHKdHoJae/Uvk/2Iu6l7nJ9wMJ3VIGrXnWL/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR06MB6759 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 20:32:44 -0000 On 7/31/20 2:30 PM, John Levine wrote: > In article you write: >> I think you're right, and isn't the market indicating that there is demand for DMARC designed for other usage patterns? e.g. >> Would the CEO of any of those fortune 500 companies like the idea of their personal address being spoofed? > > I dunno. Well, they are probably unaware when the spoofing occurs (ignorance is bliss), but I know from experience that they (people important enough to complain top-down through management) don't like being the victim of backscatter floods as a result of spoofed return-paths. Same for list bombing (which seems to be increasingly weaponized against our VIPs). It isn't spoofing but list bombing seems to create a similar amount of consternation when I tell them that there's not much that can be done to prevent or mitigate it. > Would they like the idea of mail their assistants send out for them being silently discarded because it's falsely tagged as being "spoofed"? That's the dilemma. They also don't like their address being changed by mailing lists, but that's what we're stuck with giving them. I think they want their IT staff to deploy an email system and policies that work the way they would expect. They want their organization to be seen as secure, so they don't want to be on the Buzzfeed list of Fortune 500 companies that have neglected to secure their domains with DMARC. Jesse From nobody Fri Jul 31 13:42: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 889183A0BF0 for ; Fri, 31 Jul 2020 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=JYnYLLlY; dkim=pass (1536-bit key) header.d=taugh.com header.b=PYAXDDzi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vfZJXunQne7 for ; Fri, 31 Jul 2020 13:42: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 880303A0BCA for ; Fri, 31 Jul 2020 13:42:06 -0700 (PDT) Received: (qmail 69250 invoked from network); 31 Jul 2020 20:42:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=10e7e.5f24821c.k2007; i=johnl-iecc.com@submit.iecc.com; bh=LW4mm1Txg5dhIj8QW2ibcSY2MyrHEfRilovi8oIOzC4=; b=JYnYLLlYDlHuJzIdbeXkoQgsAZ8E2o+/JWFOJj6XhoYvg+IXD8SWEupdXPnHzHTkztCimVMTiFfAKKQ48W8+T1Xx41K6Wr4kohxawyUxawNDHeg9HuxtOsR6BhgMQ5sdI6IAFU/3PlkTEmgUr/hmoRjxOfRgICmH69L3NeWjgGzLgi0V1OfFeFf7o7MQOpyq3cIWcYVeGS4Y/irZWvsTi4tXLNzkeCuOQg8Kpm4pH6oPWt7PdUZ1cm5/Gi7gtBDV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=10e7e.5f24821c.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=LW4mm1Txg5dhIj8QW2ibcSY2MyrHEfRilovi8oIOzC4=; b=PYAXDDzibQGCxxOMXrouMb1I4bY06yvsyPTb0QhcabToekZOHRzhDjKyWDDjJRaRM1GDlShua46/CEvWnD4Bz9vUchJRcboRdAl6w1Uyhsh2OVn7DMJJ3aRyL6/67dot4roio3OwLFb3JF114rW0Npje8sWJEdO8/wiwaEIz0w/+eI8vT6KlZ55OADc97Lsp3lqICt/ooTkU82HLKKqllkYIGbyyHxlg2q5xxPvGJ3R5cZLkRK/SAGCUL4nfLH+L Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 Jul 2020 20:42:04 -0000 Date: 31 Jul 2020 16:42:04 -0400 Message-ID: <3d2ff5d5-31fe-e265-6fee-b6f11be616b2@taugh.com> From: "John R Levine" To: "Jesse Thompson" , dmarc@ietf.org In-Reply-To: <01c53fdc-342b-e2d3-16dc-f1161913d656@wisc.edu> References: <20200731193040.AAF8B1DB2410@ary.qy> <01c53fdc-342b-e2d3-16dc-f1161913d656@wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 20:42:14 -0000 On Fri, 31 Jul 2020, Jesse Thompson wrote: > I think they want their IT staff to deploy an email system and policies that work the way they would expect. They want their organization to be seen as secure, so they don't want to be on the Buzzfeed list of Fortune 500 companies that have neglected to secure their domains with DMARC. Well, that's the problem, isn't it? If your expectations for e-mail are shaped by experience with paper mail and you don't realize how different an organization's internal highly controlled mail system is from e-mail on the outside, you're inevitably going to be surprised, sometimes unpleasantly. I would like for us to avoid the Yes Minister Tautology: We must do something, this is something, therefore we must do this. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 31 15:00:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78E3A0C5D for ; Fri, 31 Jul 2020 15:00: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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Rdi6mDvBqsIV for ; Fri, 31 Jul 2020 15:00:42 -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 75B703A0C5C for ; Fri, 31 Jul 2020 15:00:41 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEC0096IT54F520@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 31 Jul 2020 17:00:41 -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.7.31.215118, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.70.101] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+oRHHASE47ywQ4eUnG1UewNc1YAWLyYlNPtarswnzhASJyjraVxBhLxcGyeF0GqpoJ7HWRDXHOqIf/13BtXkKXqmRGp30X06q1Ja0un2OvuvjwFdyvmCyZqvrgUsKlQ+BIlc/MXQtPXQgzt9Vh97I40R6CPQi11M/1rzW22qIuUP0JJpCYwxgNw+QJZgFsWKzw7Elh9APUmJtqdj2mJzx/EaWuBediTepOHrCBipgzYWsYISbWFpiLRYC5ud4nPc/gy/yTnsotEB3rEcx8UTEcRqS6Oc2FCAIH2e60dex8HyaoulZJ3sE/iTpLvJy15UAjXEVhWa5i/RaAUMdgREA== 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=dBAt8aknoYpSpLRyH4LF4TIeKBQTL2BJwFOa5aoh7CA=; b=HwLWj2fTn1wMJHgy0/7j4Nll+NsBPJWang+6RT9A/6LL7c79uDjaxUg2XCTiKSRcQ/TGeDY6QycmmSgqzeEZVPrkWLQEe7eLfmhNJJ9dJErkTesWVKMNQMXPiazZlqcDBfexBNKcQc1ip81vqlQjKfsAZbM1/Qk6gvLelCQftzIV/UET0GrfH4DPWyY/81lv9cV8uSRCP3rjr1SBgu1BNILv7TJemQANAm1ytMhRoFrroGEyXVeFiOyE8oeBLne2EA5qvfTIp/fccvjj/iIjLT1oFIcBYi92pOjBF6NSpna03+dtxRST6E7+x9DjarbV9vfJMDUwzWeev1QoHlMjUw== 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=dBAt8aknoYpSpLRyH4LF4TIeKBQTL2BJwFOa5aoh7CA=; b=w7mBVX6XnXFv0d2yvNxjJA0QwXAjM40VDXIEhzrAWtxhgtyovTD091Oek+Mcu2lkkPI2jXBSzab00n9t95PndUUgfNgLuaOPfbGxdIztyET3Vrx48Dh6jW3KMZ7kxD6iqdxfiwnVsgzv18hDspmOjYX/1ms7PDQCXj3y6FQ8e0s= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4810.namprd06.prod.outlook.com (2603:10b6:5:e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.28; Fri, 31 Jul 2020 22:00:39 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3216.033; Fri, 31 Jul 2020 22:00:39 +0000 To: dmarc@ietf.org References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Jesse Thompson Message-id: Date: Fri, 31 Jul 2020 17:00:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Thunderbird/80.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR18CA0042.namprd18.prod.outlook.com (2603:10b6:610:55::22) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR18CA0042.namprd18.prod.outlook.com (2603:10b6:610:55::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Fri, 31 Jul 2020 22:00:39 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 65003788-0002-4af4-78db-08d8359d297f X-MS-TrafficTypeDiagnostic: DM6PR06MB4810: 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: cZ3ytxjekmYOS8REUfcWRn3807+SOUMoTFtk/PFPxyhAyHboC/BjpTT9NGoKge0K7B//BfF76GUR6GHk6AIbWvtml8rrNHz5GxaiIsFwiaZ4GJOuLgXMt6ZJ/4XeS2cJzly7fy9oeuJDARSrMvMVrRqOUWq1H4uayxHn6seXOOLOLqxJs1VxOfJzsJY08CF1V/b5XbI4IduIUMSxQTZo0b4a5GlTa0TvQEJFkEBAtnI70IPiQgK9jjkoooGaQtZrCfV2vodBGKW9PJAc4XjQbNm/xxZUjDHwRwogC5HYq3oa8abb+5vP93C9HPbsuiItuscpsvl7i+5gxj6r/1kJL6ev2G4YmjEggP9MTwZSzjZwZjiatWXGcpfRCOo1pFVDUQRL+Dd/8KmF1SISDEPpadSG6hxVwqKyumVIGvDd2xc= 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; SFTY:; SFS:(376002)(39860400002)(346002)(366004)(396003)(136003)(16526019)(186003)(6486002)(2906002)(31696002)(15650500001)(31686004)(83380400001)(44832011)(8936002)(956004)(86362001)(2616005)(75432002)(478600001)(53546011)(26005)(316002)(6706004)(66946007)(66476007)(66556008)(5660300002)(6916009)(16576012)(786003)(8676002)(36756003)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 6UUysPbdEQfr5ddCYkfyyBAz9dDliG9+812Du6PZQrSpdfFIfyf0f8Cyh3Blm8cu4fCzEEsg3T0mp/Dea8UkIjuwevIqIUxEXw9rio8I1aGZC9UzePhHs+nm48Md9XTMp2ddU8Tl3AHHZaX7v5+ZxQJOMwTLCvfCVI15eO9t/Aq0qD4gHQn2pmY67GmeBKZXpcAP7Cl+SNB8YRK/yGaVHuSaD+cQsn2lmkB0kDWigPE6QuIJokzO1af4bqz/hqOYRgwDOAqLigZEIg660HjHsTSYLNqZugJWKAIMF+3iAAY2qoPKMs/lRc1vHlKa+vXz4dDyOSm7AlVevvdVmGqBTpwbhCQ5/sUWO0/BC2iAotKMD7OIvyvLpEXmF2wnmaKQCyAft3ZWurz13SdO2u9wT9Lk0pdEGDdTyrqVIJ9UoKF51lmxkr2J/K2koxYyUTUroMxddm0uWUy0M5OnWQSym4mTPzcihJBjMcYJRTTQiGsH4GIddpwZH+LkybiQprkP X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 65003788-0002-4af4-78db-08d8359d297f X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2020 22:00:39.7331 (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: a/6VF7iDs+V37HsFGRW4P7ESwZVxgLPhcZXLGvu5l0WHjE5SX16zxV/5vMk644a6A6BVoPLPXwrIysVrt/QNMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4810 Archived-At: Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 22:00:46 -0000 On 7/23/20 8:07 AM, Joseph Brennan wrote: >> I think that we just have to agree that From-munging by MLMs is a permanent reality. It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented. >> > I'd be happier for the proposed standard to say that DMARC policy > "SHOULD NOT" be compromised by rewriting From lines-- and see how that > goes over. My reasoning is that blessing the practice makes it easier > for bad actors to craft spoofed mail and get it accepted. The opposite > of the purpose of DMARC, isn't it? (sorry, I forgot to reply earlier) I realize that your worry is valid if anyone attempted to un-munge the messages and then use the un-munged state somehow to validate authenticity. I assume that un-munging would only be attempted locally if the message passes DMARC and is trusted by local policy. (Similarly, as I've suggested in other contexts, it would be nice if the Receiver could preemptively communicate this trust to the Intermediary so that the munging didn't need to occur in the first place and ARC could come to fuition, but I digress.) As others have said, munged messages sent via a MLM aren't much different than someone posting to a web form and it then distributing the post to a set of email recipients. That web form isn't expecting to be able to use the author's domain, and the pattern it uses in the Friendly From is somewhat arbitrary and could be co-opted by spammers. I don't think that bad actors crafting is a huge worry since I think that in both scenarios it would just fall back on the reputation of the domain (and other factors). (just spit balling... it's getting late on a Friday...) Perhaps an interesting local policy enforcement (to get at your concern) would be to require that messages with certain Friendly From patterns to be DMARC aligned (regardless of policy) since I could assume that any MLM (that I care about) that's DMARC aware enough to munge would also have aligned SPF and/or DKIM results. Jesse From nobody Fri Jul 31 15:41: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 972F03A0764 for ; Fri, 31 Jul 2020 15:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpneFIL2cX9i for ; Fri, 31 Jul 2020 15:41:50 -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 DB7503A0746 for ; Fri, 31 Jul 2020 15:41:50 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06VMiQWo028117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2020 15:44:27 -0700 Reply-To: dcrocker@bbiw.net To: Joseph Brennan , IETF DMARC WG References: <20200717210053.674D61D2C431@ary.qy> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <37ae27f2-449a-feb9-c07b-460a9189bcae@dcrocker.net> Date: Fri, 31 Jul 2020 15:41:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.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] Response to a claim in draft-crocker-dmarc-author-00 security considerations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 22:41:55 -0000 On 7/23/2020 6:07 AM, Joseph Brennan wrote: > I'd be happier for the proposed standard to say that DMARC policy > "SHOULD NOT" be compromised by rewriting From lines-- and see how that > goes over. Consider coming along, in the middle of a 45-year practice and suddenly declaring the an independent entity, with whom you have no business relationship and who has been doing legal things for those 45 years, should now stop their legal practices because you've decide to impose a new policy on them. Forget technology. Consider the inter-organization implications here. MLMs are independent. They take delivery of a message. Delivery, not simple relaying. The post a new message. You've suddenly made their existing practice fail and so, as is common and famous for the Internet, they start routing around the breakage you've created. Please explain how this "should not" you want is reasonable. Then please explain how it is likely to be effective. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net